Définition de la compatibilité avec Android 9

1. Introduction

Ce document énonce les exigences à respecter pour que les appareils soient compatibles avec Android 9.

L'utilisation des termes "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" et "OPTIONAL" est conforme à la norme IETF définie dans la RFC 2119.

Dans ce document, un "implémentateur d'appareils" ou "implémentateur" désigne une personne ou une organisation qui développe une solution matérielle/logicielle exécutant Android 9. Une "implémentation d'appareil" ou "implémentation" est la solution matérielle/logicielle ainsi développée.

Pour être considérées comme compatibles avec Android 9, les implémentations d'appareils DOIVENT respecter les exigences présentées dans cette définition de compatibilité, y compris les documents incorporés par référence.

Lorsque cette définition ou les tests logiciels décrits dans la section 10 sont silencieux, ambigus ou incomplets, il incombe à l'implémentateur de l'appareil de s'assurer de la compatibilité avec les implémentations existantes.

C'est pourquoi le Projet Android Open Source est à la fois l'implémentation de référence et l'implémentation privilégiée d'Android. Il est vivement recommandé aux implémentateurs d'appareils de 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, il est FORTEMENT RECOMMANDÉ de ne pas suivre cette pratique, car réussir les tests logiciels deviendra beaucoup plus difficile. Il est de la responsabilité de l'implémentateur de s'assurer d'une compatibilité comportementale totale 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.

De nombreuses ressources auxquelles ce document fait référence sont dérivées directement ou indirectement du SDK Android et seront fonctionnellement identiques aux informations de la documentation de ce SDK. Dans tous les cas où cette définition de la compatibilité ou la suite de tests de compatibilité ne sont pas conformes à la documentation du SDK, la documentation du SDK est considérée comme faisant autorité. Toutes les informations techniques fournies dans les ressources associées de ce document sont considérées comme faisant partie de cette définition de la compatibilité.

1.1 Structure du document

1.1.1. Exigences par type d'appareil

La section 2 contient toutes les exigences qui s'appliquent à un type d'appareil spécifique. Chaque sous-section de la section 2 est dédiée à un type d'appareil spécifique.

Toutes les autres exigences, qui s'appliquent universellement à toutes les implémentations d'appareils Android, sont listées dans les sections qui suivent la section 2. Ces exigences sont référencées sous le nom "Exigences de base" dans ce document.

1.1.2. ID de l'exigence

Un ID de contrainte est attribué aux contraintes obligatoires.

  • L'ID est attribué uniquement pour les exigences obligatoires.
  • Les exigences FORTEMENT RECOMMANDÉES sont marquées comme [SR], mais aucun ID n'est attribué.
  • L'ID se compose de trois parties : l'ID de type d'appareil, l'ID de condition et l'ID de l'exigence (par exemple, C-0-1).

Chaque ID est défini comme suit:

  • ID de type d'appareil (voir 2. Types d'appareils)
    • C: Core (exigences appliquées à toutes les implémentations d'appareils Android)
    • H: Appareil portable Android
    • T: Appareil Android Television
    • A: Implémentation d'Android Automotive
    • Onglet: Implémentation sur tablette Android
  • ID de la condition
    • Lorsque l'exigence est inconditionnelle, cet ID est défini sur 0.
    • Lorsque l'exigence est conditionnelle, le nombre 1 est attribué à la première condition, et le nombre augmente de 1 dans la même section et pour le même type d'appareil.
  • ID de la condition requise
    • Cet ID commence à 1 et augmente de 1 dans la même section et la même condition.

1.1.3. ID de l'exigence dans la section 2

L'ID de l'exigence dans la section 2 commence par l'ID de la section correspondante, suivi de l'ID de l'exigence décrit ci-dessus.

  • L'ID de la section 2 se compose de : ID de section / ID de type d'appareil - ID de condition - ID d'exigence (par exemple, 7.4.3/A-0-1).

2. Types d'appareils

Bien que le projet Android Open Source fournisse une pile logicielle pouvant être utilisée pour différents types d'appareils et facteurs de forme, certains types d'appareils disposent d'un écosystème de distribution d'applications relativement mieux établi.

Cette section décrit ces types d'appareils, ainsi que les exigences et recommandations supplémentaires applicables à chacun d'eux.

Toutes les implémentations d'appareils Android qui ne correspondent à aucun des types d'appareils décrits DOIVENT respecter toutes les exigences des autres sections de cette définition de compatibilité.

2.1 Configurations de l'appareil

Pour connaître les principales différences de configuration matérielle en fonction du type d'appareil, consultez les exigences spécifiques à chaque appareil dans la section suivante.

2.2. Exigences concernant les appareils portables

Un appareil Android portable désigne une implémentation d'appareil Android qui est généralement utilisée en le tenant dans la main, comme un lecteur MP3, un téléphone ou une tablette.

Les implémentations d'appareils Android sont classées comme appareils portables si elles remplissent tous les critères suivants:

  • disposer d'une source d'alimentation mobile, comme une batterie ;
  • Avoir une diagonale de l'écran physique comprise entre 6,3 et 20,3 cm.

Les exigences supplémentaires du reste de cette section sont spécifiques aux implémentations d'appareils Android portables.

Remarque:Les exigences qui ne s'appliquent pas aux tablettes Android sont signalées par un astérisque (*).

2.2.1. Matériel

Implémentations pour les appareils mobiles:

  • [7.1.1.1/H-0-1] L'écran doit mesurer au moins 6,3 cm de diagonale.
  • [7.1.1.3/H-SR] Il est FORTEMENT RECOMMANDÉ de fournir aux utilisateurs une affordance leur permettant de modifier la taille de l'écran (densité de l'écran).

Si les implémentations d'appareils portables indiquent la prise en charge des écrans HDR via Configuration.isScreenHdr() , elles:

  • [7.1.4.5/H-1-1] DOIT indiquer la prise en charge des extensions EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace et VK_EXT_hdr_metadata.

Implémentations pour les appareils mobiles:

  • [7.1.5/H-0-1] DOIT inclure la prise en charge de l'ancien mode de compatibilité des applications tel qu'implémenté par le code Open Source Android en amont. Autrement dit, les implémentations d'appareils NE DOIVENT PAS modifier les déclencheurs ou les seuils à partir desquels le mode de compatibilité est activé, ni le comportement du mode de compatibilité lui-même.
  • [7.2.1/H-0-1] L'application doit prendre en charge les applications tierces d'éditeur de mode de saisie (IME).
  • [7.2.3/H-0-1] DOIT fournir les fonctions Accueil, Récents et Retour.
  • [7.2.3/H-0-2] DOIT envoyer à l'application de premier plan l'événement de pression normale et de pression prolongée de la fonction Retour (KEYCODE_BACK). Ces événements NE DOIVENT PAS être consommés par le système et PEUVENT être déclenchés en dehors de l'appareil Android (par exemple, par un clavier matériel externe connecté à l'appareil Android).
  • [7.2.4/H-0-1] DOIT prendre en charge la saisie par écran tactile.
  • [7.2.4/H-SR] Il est FORTEMENT RECOMMANDÉ de lancer l'application d'assistance sélectionnée par l'utilisateur, c'est-à-dire l'application qui implémente VoiceInteractionService, ou une activité qui gère le ACTION_ASSIST lors d'un appui prolongé sur KEYCODE_MEDIA_PLAY_PAUSE ou KEYCODE_HEADSETHOOK si l'activité de premier plan ne gère pas ces événements d'appui prolongé.
  • [7.3.1/H-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un accéléromètre 3 axes.

Si les implémentations d'appareils portables incluent un accéléromètre à trois axes, elles:

  • [7.3.1/H-1-1] DOIT pouvoir signaler des événements jusqu'à une fréquence d'au moins 100 Hz.

Si les implémentations d'appareils portables incluent un gyroscope, elles:

  • [7.3.4/H-1-1] DOIT pouvoir signaler des événements jusqu'à une fréquence d'au moins 100 Hz.

Implémentations d'appareils portables pouvant passer un appel vocal et indiquant une valeur autre que PHONE_TYPE_NONE dans getPhoneType:

  • [7.3.8/H] DOIT inclure un capteur de proximité.

Implémentations pour les appareils mobiles:

  • [7.3.12/H-SR] Recommandé pour prendre en charge le capteur de position à six degrés de liberté.
  • [7.4.3/H] La plate-forme DOIT prendre en charge le Bluetooth et le Bluetooth LE.

Si les implémentations d'appareils portables incluent une connexion limitée, elles:

  • [7.4.7/H-1-1] DOIT fournir le mode Économiseur de données.

Implémentations pour les appareils mobiles:

  • [7.6.1/H-0-1] 4 Go de stockage non volatile minimum doivent être disponibles pour les données privées de l'application (également appelée partition "/data").
  • [7.6.1/H-0-2] DOIT renvoyer "true" pour ActivityManager.isLowRamDevice() lorsqu'il y a moins de 1 Go de mémoire disponible pour le noyau et l'espace utilisateur.

Si les implémentations d'appareils portables ne déclarent la prise en charge que d'une ABI 32 bits:

  • [7.6.1/H-1-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 416 Mo si l'écran par défaut utilise des résolutions de tampon de trame jusqu'à qHD (par exemple, FWVGA).

  • [7.6.1/H-2-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 592 Mo si l'écran par défaut utilise des résolutions de framebuffer jusqu'à HD+ (par exemple, HD, WSVGA).

  • [7.6.1/H-3-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 896 Mo si l'écran par défaut utilise des résolutions de tampon de trame jusqu'à FHD (par exemple, WSXGA+).

  • [7.6.1/H-4-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 344 Mo si l'écran par défaut utilise des résolutions de tampon de trame jusqu'à QHD (par exemple, QWXGA).

Si les implémentations d'appareils portables déclarent prendre en charge une ABI 64 bits (avec ou sans ABI 32 bits):

  • [7.6.1/H-5-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 816 Mo si l'écran par défaut utilise des résolutions de tampon d'affichage jusqu'à qHD (par exemple, FWVGA).

  • [7.6.1/H-6-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 944 Mo si l'écran par défaut utilise des résolutions de framebuffer jusqu'à HD+ (par exemple, HD, WSVGA).

  • [7.6.1/H-7-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 280 Mo si l'écran par défaut utilise des résolutions de framebuffer jusqu'à FHD (par exemple, WSXGA+).

  • [7.6.1/H-8-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 824 Mo si l'affichage par défaut utilise des résolutions de tampon d'affichage jusqu'à QHD (par exemple, QWXGA).

Notez que la "mémoire disponible pour le kernel et l'espace utilisateur" ci-dessus fait référence à l'espace mémoire fourni en plus de la mémoire déjà dédiée aux composants matériels tels que la radio, la vidéo, etc., qui ne sont pas sous le contrôle du kernel pour les implémentations d'appareils.

Si les implémentations d'appareils portables incluent moins de 1 Go de mémoire disponible pour le noyau et l'espace utilisateur, elles:

  • [7.6.1/H-9-1] DOIT déclarer le flag de fonctionnalité android.hardware.ram.low.
  • [7.6.1/H-9-2] DOIT disposer d'au moins 1,1 Go de stockage non volatile pour les données privées de l'application (également appelée partition "/data").

Si les implémentations d'appareils portables incluent plus de 1 Go de mémoire disponible pour le noyau et l'espace utilisateur, elles:

  • [7.6.1/H-10-1] 4 Go de stockage non volatile doivent être disponibles pour les données privées de l'application (également appelée partition "/data").
  • DOIT déclarer le commutateur de fonctionnalité android.hardware.ram.normal.

Implémentations pour les appareils mobiles:

  • [7.6.2/H-0-1] NE DOIT PAS fournir un espace de stockage partagé d'application inférieur à 1 Go.
  • [7.7.1/H] Un port USB compatible avec le mode périphérique DOIT être inclus.

Si les implémentations d'appareils portables incluent un port USB compatible avec le mode périphérique, elles:

  • [7.7.1/H-1-1] DOIT implémenter l'API Android Open Accessory (AOA).

Implémentations pour les appareils mobiles:

  • [7.8.1/H-0-1] DOIT inclure un micro.
  • [7.8.2/H-0-1] DOIT disposer d'une sortie audio et déclarer android.hardware.audio.output.

Si les implémentations d'appareils portables sont capables de répondre à toutes les exigences de performances pour prendre en charge le mode VR et qu'elles le font, elles:

  • [7.9.1/H-1-1] DOIT déclarer le flag de fonctionnalité android.hardware.vr.high_performance.
  • [7.9.1/H-1-2] DOIT inclure une application implémentant android.service.vr.VrListenerService qui peut être activée par les applications de réalité virtuelle via android.app.Activity#setVrModeEnabled.

2.2.2. Multimédia

Les implémentations d'appareils portables DOIVENT prendre en charge l'encodage audio suivant:

  • [5.1.1/H-0-1] AMR-NB
  • [5.1.1/H-0-2] AMR-WB
  • [5.1.1/H-0-3] Profil MPEG-4 AAC (AAC LC)
  • [5.1.1/H-0-4] Profil MPEG-4 HE AAC (AAC+)
  • [5.1.1/H-0-5] AAC ELD (AAC à faible latence amélioré)

Les implémentations d'appareils portables DOIVENT prendre en charge le décodage audio suivant:

  • [5.1.2/H-0-1] AMR-NB
  • [5.1.2/H-0-2] AMR-WB

Les implémentations d'appareils portables DOIVENT prendre en charge l'encodage vidéo suivant et le mettre à la disposition des applications tierces:

  • [5.2/H-0-1] H.264 AVC
  • [5.2/H-0-2] VP8

Les implémentations d'appareils portables DOIVENT prendre en charge le décodage vidéo suivant:

  • [5.3/H-0-1] H.264 AVC
  • [5.3/H-0-2] H.265 HEVC
  • [5.3/H-0-3] MPEG-4 SP
  • [5.3/H-0-4] VP8
  • [5.3/H-0-5] VP9

2.2.3. Logiciel

Implémentations pour les appareils mobiles:

  • [3.2.3.1/H-0-1] Une application doit gérer les intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE et ACTION_CREATE_DOCUMENT, comme décrit dans les documents du SDK, et fournir à l'utilisateur la possibilité d'accéder aux données du fournisseur de documents à l'aide de l'API DocumentsProvider.
  • [3.4.1/H-0-1] DOIT fournir une implémentation complète de l'API android.webkit.Webview.
  • [3.4.2/H-0-1] DOIT inclure une application de navigateur autonome pour la navigation Web des utilisateurs.
  • [3.8.1/H-SR] Nous vous RECOMMANDONS vivement d'implémenter un lanceur par défaut compatible avec l'épinglage de raccourcis, de widgets et de widgetFeatures dans l'application.
  • [3.8.1/H-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter un lanceur par défaut qui permet d'accéder rapidement aux raccourcis supplémentaires fournis par les applications tierces via l'API ShortcutManager.
  • [3.8.1/H-SR] Il est FORTEMENT RECOMMANDÉ d'inclure une application de lanceur par défaut qui affiche des badges pour les icônes d'application.
  • [3.8.2/H-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge les widgets d'applications tierces.
  • [3.8.3/H-0-1] Les applications tierces doivent être autorisées à informer les utilisateurs d'événements notables via les classes d'API Notification et NotificationManager.
  • [3.8.3/H-0-2] DOIT prendre en charge les notifications enrichies.
  • [3.8.3/H-0-3] DOIT prendre en charge les notifications heads-up.
  • [3.8.3/H-0-4] DOIT inclure une barre de notification permettant à l'utilisateur de contrôler directement les notifications (par exemple, répondre, répéter, ignorer, bloquer) via des affordances utilisateur telles que des boutons d'action ou le panneau de contrôle tel qu'implémenté dans l'AOSP.
  • [3.8.3/H-0-5] DOIT afficher les choix fournis via RemoteInput.Builder setChoices() dans le volet des notifications.
  • [3.8.3/H-SR] Il est FORTEMENT RECOMMANDÉ d'afficher le premier choix fourni via RemoteInput.Builder setChoices() dans la barre de notification sans interaction utilisateur supplémentaire.
  • [3.8.3/H-SR] Il est FORTEMENT RECOMMANDÉ d'afficher tous les choix fournis via RemoteInput.Builder setChoices() dans le volet des notifications lorsque l'utilisateur développe toutes les notifications dans le volet des notifications.
  • [3.8.4/H-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter un assistant sur l'appareil pour gérer l'action d'assistance.

Si les implémentations d'appareils portables sont compatibles avec l'action d'assistance, elles:

  • [3.8.4/H-SR] Nous vous RECOMMANDONS vivement d'utiliser l'appui prolongé sur la touche HOME comme interaction désignée pour lancer l'application d'assistance, comme décrit dans la section 7.2.3. DOIT lancer l'application d'assistance sélectionnée par l'utilisateur, c'est-à-dire l'application qui implémente VoiceInteractionService , ou une activité qui gère l'intent ACTION_ASSIST.

Si les implémentations d'appareils Android portables sont compatibles avec un écran de verrouillage, elles:

  • [3.8.10/H-1-1] DOIT afficher les notifications de l'écran de verrouillage, y compris le modèle de notification multimédia.

Si les implémentations d'appareils portables sont compatibles avec un écran de verrouillage sécurisé, elles:

  • [3.9/H-1-1] DOIT implémenter l'ensemble des stratégies d'administration des appareils définies dans la documentation du SDK Android.
  • [3.9/H-1-2] DOIT déclarer la prise en charge des profils gérés via le flag de fonctionnalité android.software.managed_users, sauf lorsque l'appareil est configuré pour s'enregistrer comme un appareil à faible quantité de RAM ou pour qu'il alloue de l'espace de stockage interne (non amovible) en tant qu'espace de stockage partagé.

Implémentations pour les appareils mobiles:

  • [3.10/H-0-1] DOIT prendre en charge les services d'accessibilité tiers.
  • [3.10/H-SR] Il est FORTEMENT RECOMMANDÉ de précharger sur l'appareil des services d'accessibilité comparables ou supérieurs aux fonctionnalités des services d'accessibilité Switch Access et TalkBack (pour les langues prises en charge par le moteur de synthèse vocale préinstallé), comme indiqué dans le projet Open Source talkback.
  • [3.11/H-0-1] DOIT prendre en charge l'installation de moteurs de synthèse vocale tiers.
  • [3.11/H-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un moteur de synthèse vocale compatible avec les langues disponibles sur l'appareil.
  • [3.13/H-SR] Il est vivement recommandé d'inclure un composant d'UI de paramètres rapides.

Si les implémentations d'appareils portables Android déclarent la prise en charge de FEATURE_BLUETOOTH ou FEATURE_WIFI, elles:

  • [3.16/H-1-1] DOIT prendre en charge la fonctionnalité d'association d'appareils associés.

2.2.4. Performances et puissance

  • [8.1/H-0-1] Latence des images cohérente. La latence des images incohérente ou le délai de rendu des images NE DOIVENT PAS se produire plus de cinq fois par seconde et DOIVENT être inférieurs à une fois par seconde.
  • [8.1/H-0-2] Latence de l'interface utilisateur. Les implémentations d'appareils DOIVENT garantir une expérience utilisateur à faible latence en faisant défiler une liste de 10 000 entrées, comme défini par la suite de tests de compatibilité Android (CTS), en moins de 36 secondes.
  • [8.1/H-0-3] Changement de tâche. Lorsque plusieurs applications ont été lancées, le redémarrage d'une application déjà en cours d'exécution doit prendre moins d'une seconde.

Implémentations pour les appareils mobiles:

  • [8.2/H-0-1] DOIT garantir des performances d'écriture séquentielle d'au moins 5 Mo/s.
  • [8.2/H-0-2] DOIT garantir des performances d'écriture aléatoire d'au moins 0,5 Mo/s.
  • [8.2/H-0-3] DOIT assurer des performances de lecture séquentielle d'au moins 15 Mo/s.
  • [8.2/H-0-4] DOIT garantir des performances de lecture aléatoire d'au moins 3,5 Mo/s.

Si les implémentations d'appareils portables incluent des fonctionnalités d'amélioration de la gestion de l'alimentation de l'appareil qui sont incluses dans AOSP ou qui étendent les fonctionnalités incluses dans AOSP, elles:

  • [8.3/H-1-1] L'utilisateur doit pouvoir activer et désactiver la fonctionnalité Économiseur de batterie.
  • [8.3/H-1-2] L'application DOIT fournir une affordance permettant à l'utilisateur d'afficher toutes les applications exemptées des modes d'économie d'énergie App Standby et Doze.

Implémentations pour les appareils mobiles:

  • [8.4/H-0-1] DOIT fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle pour chaque composant matériel et l'épuisement approximatif de la batterie causé par les composants au fil du temps, comme indiqué sur le site du projet Open Source Android.
  • [8.4/H-0-2] Toutes les valeurs de consommation d'énergie DOIVENT être exprimées en milliampères-heures (mAh).
  • [8.4/H-0-3] DOIT indiquer la consommation d'énergie du processeur par UID de chaque processus. Le projet Android Open Source répond à cette exigence grâce à l'implémentation du module de noyau uid_cputime.
  • [8.4/H-0-4] Le développeur de l'application DOIT pouvoir accéder à cette consommation d'énergie via la commande shell adb shell dumpsys batterystats.
  • [8.4/H] DOIT être attribué au composant matériel lui-même si vous ne parvenez pas à attribuer la consommation d'énergie du composant matériel à une application.

Si les implémentations d'appareils portables incluent un écran ou une sortie vidéo, elles:

2.2.5. Modèle de sécurité

Implémentations pour les appareils mobiles:

  • [9.1/H-0-1] DOIT autoriser les applications tierces à accéder aux statistiques d'utilisation via l'autorisation android.permission.PACKAGE_USAGE_STATS et fournir un mécanisme accessible par l'utilisateur pour accorder ou révoquer l'accès à ces applications en réponse à l'intent android.settings.ACTION_USAGE_ACCESS_SETTINGS.

Lorsque les implémentations d'appareils portables sont compatibles avec un écran de verrouillage sécurisé, elles:

  • [9.11/H-1-1] L'appareil DOIT permettre à l'utilisateur de choisir le délai de mise en veille le plus court, c'est-à-dire un temps de transition de l'état déverrouillé à l'état verrouillé, de 15 secondes ou moins.
  • [9.11/H-1-2] DOIT fournir à l'utilisateur la possibilité de masquer les notifications et de désactiver toutes les formes d'authentification, à l'exception de l'authentification principale décrite dans la section 9.11.1 Écran de verrouillage sécurisé. L'AOSP répond à cette exigence en tant que mode de verrouillage.

2.3. Exigences concernant les téléviseurs

Un appareil Android TV désigne une implémentation d'appareil Android qui est une interface de divertissement permettant de consommer des contenus multimédias numériques, des films, des jeux, des applications et/ou de la télévision en direct pour les utilisateurs assis à environ trois mètres (interface utilisateur "relax" ou "10 pieds").

Les implémentations d'appareils Android sont classées comme téléviseurs si elles répondent à l'ensemble des critères suivants:

  • Vous avez fourni un mécanisme permettant de contrôler à distance l'interface utilisateur affichée sur un écran situé à 3 mètres de l'utilisateur.
  • Avoir un écran intégré dont la diagonale est supérieure à 60 cm OU inclure un port de sortie vidéo, tel que VGA, HDMI, DisplayPort ou un port sans fil pour l'affichage.

Les exigences supplémentaires du reste de cette section sont spécifiques aux implémentations d'appareils Android TV.

2.3.1. Matériel

Implémentations d'appareils TV:

  • [7.2.2/T-0-1] La croix directionnelle doit être prise en charge.
  • [7.2.3/T-0-1] DOIT fournir les fonctions "Accueil" et "Retour".
  • [7.2.3/T-0-2] DOIT envoyer à l'application au premier plan l'événement de pression normale et de pression prolongée de la fonction Retour (KEYCODE_BACK).
  • [7.2.6.1/T-0-1] DOIT inclure la prise en charge des manettes de jeu et déclarer l'indicateur de fonctionnalité android.hardware.gamepad.
  • [7.2.7/T] DOIT fournir une télécommande à partir de laquelle les utilisateurs peuvent accéder aux entrées de navigation non tactile et des touches de navigation principales.

Si les implémentations d'appareils de télévision incluent un gyroscope, elles:

  • [7.3.4/T-1-1] DOIT pouvoir signaler des événements jusqu'à une fréquence d'au moins 100 Hz.

Implémentations d'appareils TV:

  • [7.4.3/T-0-1] DOIT prendre en charge Bluetooth et Bluetooth LE.
  • [7.6.1/T-0-1] 4 Go de stockage non volatile minimum doivent être disponibles pour les données privées de l'application (également appelée partition "/data").

Si les implémentations d'appareils de télévision incluent un port USB compatible avec le mode hôte, elles:

  • [7.5.3/T-1-1] DOIT être compatible avec une caméra externe qui se connecte via ce port USB, mais qui n'est pas nécessairement toujours connectée.

Si les implémentations de l'appareil TV sont 32 bits:

  • [7.6.1/T-1-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 896 Mo si l'une des densités suivantes est utilisée:

    • 400 dpi ou plus sur les écrans de petite/moyenne taille
    • xhdpi ou version ultérieure sur les grands écrans
    • tvdpi ou version ultérieure sur les écrans très grands

Si les implémentations de l'appareil TV sont 64 bits:

  • [7.6.1/T-2-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 280 Mo si l'une des densités suivantes est utilisée:

    • 400 dpi ou plus sur les écrans de petite/moyenne taille
    • xhdpi ou version ultérieure sur les grands écrans
    • tvdpi ou version ultérieure sur les écrans très grands

Notez que la "mémoire disponible pour le kernel et l'espace utilisateur" ci-dessus fait référence à l'espace mémoire fourni en plus de la mémoire déjà dédiée aux composants matériels tels que la radio, la vidéo, etc., qui ne sont pas sous le contrôle du kernel pour les implémentations d'appareils.

Implémentations d'appareils TV:

  • [7.8.1/T] DOIT inclure un micro.
  • [7.8.2/T-0-1] DOIT comporter une sortie audio et déclarer android.hardware.audio.output.

2.3.2. Multimédia

Les implémentations d'appareils de télévision DOIVENT prendre en charge les formats d'encodage audio suivants:

  • [5.1/T-0-1] Profil MPEG-4 AAC (AAC LC)
  • [5.1/T-0-2] Profil MPEG-4 HE AAC (AAC+)
  • [5.1/T-0-3] AAC ELD (AAC à faible latence améliorée)

Les implémentations d'appareils de télévision DOIVENT prendre en charge les formats d'encodage vidéo suivants:

  • [5.2/T-0-1] H.264
  • [5.2/T-0-2] VP8

Implémentations d'appareils TV:

  • [5.2.2/T-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'encodage H.264 des vidéos en résolution 720p et 1080p à 30 images par seconde.

Les implémentations d'appareils de télévision DOIVENT prendre en charge les formats de décodage vidéo suivants:

Il est vivement recommandé que les implémentations d'appareils de télévision soient compatibles avec les formats de décodage vidéo suivants:

Les implémentations d'appareils de télévision DOIVENT prendre en charge le décodage H.264, comme indiqué dans la section 5.3.4, aux fréquences d'images et résolutions vidéo standards jusqu'à:

  • [5.3.4.4/T-1-1] HD 1080p à 60 images par seconde avec le profil de référence
  • [5.3.4.4/T-1-2] HD 1080p à 60 images par seconde avec le profil principal
  • [5.3.4.4/T-1-3] HD 1080p à 60 images par seconde avec High Profile Level 4.2

Les implémentations d'appareils de télévision avec des décodeurs matériels H.265 DOIVENT prendre en charge le décodage H.265, comme indiqué dans la section 5.3.5, aux fréquences d'images et résolutions vidéo standards jusqu'à:

  • [5.3.5.4/T-1-1] HD 1080p à 60 images par seconde avec le profil principal de niveau 4.1

Si les implémentations d'appareils de télévision avec des décodeurs matériels H.265 prennent en charge le décodage H.265 et le profil de décodage UHD, elles:

  • [5.3.5.5/T-2-1] DOIT prendre en charge le profil de décodage UHD à 60 images par seconde avec le profil de niveau 5 du niveau principal Main10.

Les implémentations d'appareils de télévision DOIVENT prendre en charge le décodage VP8, comme indiqué dans la section 5.3.6, aux fréquences d'images et résolutions vidéo standards jusqu'à:

  • [5.3.6.4/T-1-1] Profil de décodage HD 1080p à 60 images par seconde

Les implémentations d'appareils de télévision avec des décodeurs matériels VP9 DOIVENT prendre en charge le décodage VP9, comme indiqué dans la section 5.3.7, aux fréquences d'images et résolutions vidéo standards jusqu'à:

  • [5.3.7.4/T-1-1] HD 1080p à 60 images par seconde avec le profil 0 (profondeur de couleur de 8 bits)

Si les implémentations d'appareils de télévision avec des décodeurs matériels VP9 prennent en charge le décodage VP9 et le profil de décodage UHD, elles:

  • [5.3.7.5/T-2-1] DOIT prendre en charge le profil de décodage UHD à 60 images par seconde avec le profil 0 (profondeur de couleur de 8 bits).
  • [5.3.7.5/T-2-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge le profil de décodage UHD à 60 images par seconde avec le profil 2 (profondeur de couleur de 10 bits).

Implémentations d'appareils TV:

  • [5.5.3/T-0-1] L'appareil DOIT prendre en charge le volume principal du système et l'atténuation du volume de sortie audio numérique sur les sorties compatibles, à l'exception de la sortie de passthrough audio compressé (où aucun décodage audio n'est effectué sur l'appareil).
  • [5.8/T-0-1] Le mode de sortie HDMI doit être défini pour sélectionner la résolution maximale compatible avec une fréquence d'actualisation de 50 Hz ou 60 Hz pour tous les écrans filaires.
  • [5.8/T-SR] Il est FORTEMENT RECOMMANDÉ de fournir un sélecteur de fréquence d'actualisation HDMI configurable par l'utilisateur pour tous les écrans filaires.
  • [5.8/T-SR] FORTEMENT RECOMMANDÉ pour prendre en charge le décodage simultané des flux sécurisés. Le décodage simultané de deux flux est FORTEMENT RECOMMANDÉ.
  • [5.8] La fréquence d'actualisation du mode de sortie HDMI doit être définie sur 50 Hz ou 60 Hz, en fonction de la fréquence d'actualisation vidéo de la région dans laquelle l'appareil est vendu, pour tous les écrans filaires.

Si les implémentations d'appareils de télévision sont compatibles avec le décodage UHD et les écrans externes, elles:

  • [5.8/T-1-1] La prise en charge de la norme HDCP 2.2 est OBLIGATOIRE.

Si les implémentations d'appareils de télévision ne sont pas compatibles avec le décodage UHD, mais qu'elles sont compatibles avec les écrans externes, elles:

  • [5.8/T-2-1] DOIT prendre en charge HDCP 1.4

2.3.3. Logiciel

Implémentations d'appareils TV:

  • [3/T-0-1] DOIT déclarer les fonctionnalités android.software.leanback et android.hardware.type.television.
  • [3.4.1/T-0-1] DOIT fournir une implémentation complète de l'API android.webkit.Webview.

Si les implémentations d'appareils Android TV sont compatibles avec un écran de verrouillage,elles:

  • [3.8.10/T-1-1] DOIT afficher les notifications de l'écran de verrouillage, y compris le modèle de notification multimédia.

Implémentations d'appareils TV:

  • [3.8.14/T-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge le mode multifenêtre Picture-in-picture (PIP).
  • [3.10/T-0-1] DOIT prendre en charge les services d'accessibilité tiers.
  • [3.10/T-SR] Il est FORTEMENT RECOMMANDÉ de précharger sur l'appareil des services d'accessibilité comparables ou supérieurs aux services d'accessibilité Switch Access et TalkBack (pour les langues compatibles avec le moteur de synthèse vocale préinstallé) tels que fournis dans le projet Open Source talkback.

Si les implémentations d'appareils de télévision signalent la fonctionnalité android.hardware.audio.output, elles:

  • [3.11/T-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un moteur de synthèse vocale compatible avec les langues disponibles sur l'appareil.
  • [3.11/T-1-1] DOIT prendre en charge l'installation de moteurs de synthèse vocale tiers.

Implémentations d'appareils TV:

  • [3.12/T-0-1] DOIT prendre en charge le TV Input Framework.

2.3.4. Performances et puissance

  • [8.1/T-0-1] Latence des images cohérente. La latence des images incohérente ou le délai de rendu des images NE DOIVENT PAS se produire plus de cinq fois par seconde et DOIVENT être inférieurs à une fois par seconde.
  • [8.2/T-0-1] DOIT garantir des performances d'écriture séquentielle d'au moins 5 Mo/s.
  • [8.2/T-0-2] DOIT garantir des performances d'écriture aléatoire d'au moins 0,5 Mo/s.
  • [8.2/T-0-3] DOIT assurer des performances de lecture séquentielle d'au moins 15 Mo/s.
  • [8.2/T-0-4] DOIT garantir des performances de lecture aléatoire d'au moins 3,5 Mo/s.

Si les implémentations d'appareils de télévision incluent des fonctionnalités d'amélioration de la gestion de l'alimentation de l'appareil qui sont incluses dans AOSP ou qui étendent les fonctionnalités incluses dans AOSP, elles:

  • [8.3/T-1-1] DOIT fournir une affordance utilisateur pour activer et désactiver la fonctionnalité Économiseur de batterie.
  • [8.3/T-1-2] L'application doit permettre à l'utilisateur d'afficher toutes les applications qui sont exemptées des modes d'économie d'énergie App Standby et Doze.

Implémentations d'appareils TV:

  • [8.4/T-0-1] DOIT fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle pour chaque composant matériel et l'épuisement approximatif de la batterie causé par les composants au fil du temps, comme indiqué sur le site du projet Open Source Android.
  • [8.4/T-0-2] DOIT indiquer toutes les valeurs de consommation d'énergie en milliampères-heure (mAh).
  • [8.4/T-0-3] DOIT indiquer la consommation d'énergie du processeur par UID de chaque processus. Le projet Android Open Source répond à cette exigence grâce à l'implémentation du module de noyau uid_cputime.
  • [8.4/T] DOIT être attribué au composant matériel lui-même si vous ne parvenez pas à attribuer la consommation d'énergie du composant matériel à une application.
  • [8.4/T-0-4] Le développeur de l'application DOIT pouvoir accéder à cette consommation d'énergie via la commande shell adb shell dumpsys batterystats.

2.4. Configuration requise pour la montre

Un appareil Android Watch désigne une implémentation d'appareil Android destinée à être portée sur le corps, par exemple au poignet.

Les implémentations d'appareils Android sont classées comme montres si elles remplissent tous les critères suivants:

  • Avoir un écran dont la diagonale physique est comprise entre 1,1 et 2,5 pouces.
  • être porté sur le corps ;

Les exigences supplémentaires du reste de cette section sont spécifiques aux implémentations d'appareils Android Watch.

2.4.1. Matériel

Implémentations des appareils de visionnage:

  • [7.1.1.1/W-0-1] L'écran doit avoir une diagonale physique comprise entre 1,1 et 2,5 pouces.

  • [7.2.3/W-0-1] La fonction "Accueil" et la fonction "Retour" doivent être disponibles pour l'utilisateur, sauf lorsqu'il se trouve dans UI_MODE_TYPE_WATCH.

  • [7.2.4/W-0-1] DOIT prendre en charge la saisie par écran tactile.

  • [7.3.1/W-SR] Il est vivement recommandé d'inclure un accéléromètre à trois axes.

  • [7.4.3/W-0-1] DOIT prendre en charge la technologie Bluetooth.

  • [7.6.1/W-0-1] Un minimum de 1 Go de stockage non volatile doit être disponible pour les données privées de l'application (également appelée partition "/data").

  • [7.6.1/W-0-2] Le noyau et l'espace utilisateur doivent disposer d'au moins 416 Mo de mémoire.

  • [7.8.1/W-0-1] DOIT inclure un micro.

  • [7.8.2/W] La sortie audio peut être présente, mais ne doit pas l'être.

2.4.2. Multimédia

Aucune autre condition requise.

2.4.3. Logiciel

Implémentations des appareils de visionnage:

  • [3/W-0-1] Vous devez déclarer la fonctionnalité android.hardware.type.watch.
  • [3/W-0-2] DOIT prendre en charge uiMode = UI_MODE_TYPE_WATCH.

Implémentations des appareils de visionnage:

  • [3.8.4/W-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter un assistant sur l'appareil pour gérer l'action d'assistance.

Observez les implémentations d'appareils qui déclarent l'indicateur de fonctionnalité android.hardware.audio.output:

  • [3.10/W-1-1] DOIT prendre en charge les services d'accessibilité tiers.
  • [3.10/W-SR] Il est FORTEMENT RECOMMANDÉ de précharger sur l'appareil des services d'accessibilité comparables ou supérieurs aux fonctionnalités des services d'accessibilité Switch Access et TalkBack (pour les langues prises en charge par le moteur de synthèse vocale préinstallé) tels que fournis dans le projet Open Source talkback.

Si les implémentations d'appareils de montre signalent la fonctionnalité android.hardware.audio.output, elles:

  • [3.11/W-SR] Il est vivement recommandé d'inclure un moteur de synthèse vocale compatible avec les langues disponibles sur l'appareil.

  • [3.11/W-0-1] DOIT prendre en charge l'installation de moteurs de synthèse vocale tiers.

2.4.4. Performances et puissance

Si les implémentations d'appareils connectés incluent des fonctionnalités de gestion de l'alimentation de l'appareil incluses dans AOSP ou qui en étendent les fonctionnalités, elles:

  • [8.3/W-SR] Il est FORTEMENT RECOMMANDÉ de fournir aux utilisateurs une affordance pour afficher toutes les applications qui sont exemptées des modes d'économie d'énergie App Standby et Doze.
  • [8.3/W-SR] Il est FORTEMENT RECOMMANDÉ de fournir aux utilisateurs une affordance leur permettant d'activer et de désactiver la fonctionnalité Économiseur de batterie.

Implémentations des appareils de visionnage:

  • [8.4/W-0-1] DOIT fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle pour chaque composant matériel et l'épuisement approximatif de la batterie causé par les composants au fil du temps, comme indiqué sur le site du projet Open Source Android.
  • [8.4/W-0-2] Toutes les valeurs de consommation d'énergie doivent être indiquées en milliampères-heures (mAh).
  • [8.4/W-0-3] DOIT indiquer la consommation d'énergie du processeur par UID de chaque processus. Le projet Android Open Source répond à cette exigence grâce à l'implémentation du module de noyau uid_cputime.
  • [8.4/W-0-4] Le développeur de l'application DOIT pouvoir accéder à cette consommation d'énergie via la commande shell adb shell dumpsys batterystats.
  • [8,4 W] DOIT être attribué au composant matériel lui-même si vous ne parvenez pas à attribuer la consommation d'énergie du composant matériel à une application.

2.5. Exigences pour le secteur automobile

L'implémentation d'Android Automotive désigne une unité principale de véhicule qui utilise Android comme système d'exploitation pour une partie ou la totalité du système et/ou des fonctionnalités d'infoloisirs.

Les implémentations d'appareils Android sont classées comme Automotive si elles déclarent la fonctionnalité android.hardware.type.automotive ou si elles répondent à tous les critères suivants.

  • Ils sont intégrés à un véhicule automobile ou peuvent y être branchés.
  • Utilise un écran sur la rangée du siège conducteur comme écran principal.

Les exigences supplémentaires du reste de cette section sont spécifiques aux implémentations d'appareils Android Automotive.

2.5.1. Matériel

Implémentations d'appareils automobiles:

  • [7.1.1.1/A-0-1] L'écran doit mesurer au moins 6 pouces de diagonale physique.

  • [7.1.1.1/A-0-2] La disposition de la taille de l'écran doit être d'au moins 750 dp x 480 dp.

  • [7.2.3/A-0-1] DOIT fournir la fonction "Accueil" et PEUT fournir les fonctions "Retour" et "Récents".

  • [7.2.3/A-0-2] DOIT envoyer à l'application au premier plan l'événement de pression normale et de pression prolongée de la fonction Retour (KEYCODE_BACK).

  • [7.3.1/A-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un accéléromètre à trois axes.

Si les implémentations d'appareils Automotive incluent un accéléromètre à trois axes, elles:

Si les implémentations d'appareils Automotive incluent un gyroscope, elles:

  • [7.3.4/A-1-1] DOIT pouvoir signaler des événements jusqu'à une fréquence d'au moins 100 Hz.

Implémentations d'appareils automobiles:

  • [7.3.11/A-0-1] DOIT indiquer l'équipement actuel sous la forme SENSOR_TYPE_GEAR.

Implémentations d'appareils automobiles:

  • [7.3.11.2/A-0-1] DOIT prendre en charge le mode jour/nuit défini comme SENSOR_TYPE_NIGHT.
  • [7.3.11.2/A-0-2] La valeur de l'indicateur SENSOR_TYPE_NIGHT DOIT être cohérente avec le mode jour/nuit du tableau de bord et DOIT être basée sur l'entrée du capteur de lumière ambiante.

  • Le capteur de luminosité ambiante sous-jacent PEUT être le même que le photomètre.

  • [7.3.11.4/A-0-1] DOIT indiquer la vitesse du véhicule telle que définie par SENSOR_TYPE_CAR_SPEED.

  • [7.3.11.5/A-0-1] DOIT indiquer l'état du frein à main tel que défini par SENSOR_TYPE_PARKING_BRAKE.

  • [7.4.3/A-0-1] L'appareil DOIT être compatible avec le Bluetooth et DEVRAIT être compatible avec le Bluetooth LE.

  • [7.4.3/A-0-2] Les implémentations Android Auto doivent prendre en charge les profils Bluetooth suivants :
    • Appels téléphoniques via le profil mains libres (HFP)
    • Lecture de contenus multimédias via le profil de distribution audio (A2DP)
    • Contrôle de la lecture de contenus multimédias via le profil de télécommande (AVRCP).
    • Partage de contacts à l'aide du profil d'accès au carnet d'adresses (PBAP)

  • [7.4.3/A-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge le profil d'accès aux messages (MAP).

  • [7.4.5/A] DOIT prendre en charge la connectivité de données basée sur un réseau mobile.

  • [7.4.5/A] PEUT utiliser la constante NetworkCapabilities#NET_CAPABILITY_OEM_PAID de l'API système pour les réseaux qui doivent être disponibles pour les applications système.

  • [7.6.1/A-0-1] 4 Go de stockage non volatile minimum doivent être disponibles pour les données privées de l'application (également appelée partition "/data").

Implémentations d'appareils automobiles:

  • [7.6.1/A] Le système DOIT formater la partition de données pour améliorer les performances et la longévité du stockage flash, par exemple à l'aide du système de fichiers f2fs.

Si les implémentations d'appareils Automotive fournissent un stockage externe partagé via une partie de l'espace de stockage interne non amovible, elles:

  • [7.6.1/A-SR] FORTEMENT RECOMMANDÉ pour réduire les coûts d'E/S sur les opérations effectuées sur le stockage externe, par exemple en utilisant SDCardFS.

Si les implémentations d'appareils Automotive sont 32 bits:

  • [7.6.1/A-1-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 512 Mo si l'une des densités suivantes est utilisée:

    • 280 dpi ou moins sur les écrans de petite/moyenne taille
    • ldpi ou moins sur les écrans très grands formats
    • mdpi ou moins sur les grands écrans

  • [7.6.1/A-1-2] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 608 Mo si l'une des densités suivantes est utilisée:

    • xhdpi ou version ultérieure sur les écrans de petite/moyenne taille
    • hdpi ou version ultérieure sur les grands écrans
    • mdpi ou plus sur les écrans très grands

  • [7.6.1/A-1-3] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 896 Mo si l'une des densités suivantes est utilisée:

    • 400 dpi ou plus sur les écrans de petite/moyenne taille
    • xhdpi ou version ultérieure sur les grands écrans
    • tvdpi ou version ultérieure sur les écrans très grands

  • [7.6.1/A-1-4] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 344 Mo si l'une des densités suivantes est utilisée:

    • 560 dpi ou plus sur les écrans de petite/moyenne taille
    • 400 dpi ou plus sur les grands écrans
    • xhdpi ou version ultérieure sur les écrans très grands

Si les implémentations d'appareils Automotive sont 64 bits:

  • [7.6.1/A-2-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 816 Mo si l'une des densités suivantes est utilisée:

    • 280 dpi ou moins sur les écrans de petite/moyenne taille
    • ldpi ou moins sur les écrans très grands formats
    • mdpi ou moins sur les grands écrans

  • [7.6.1/A-2-2] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 944 Mo si l'une des densités suivantes est utilisée:

    • xhdpi ou version ultérieure sur les écrans de petite/moyenne taille
    • hdpi ou version ultérieure sur les grands écrans
    • mdpi ou plus sur les écrans très grands

  • [7.6.1/A-2-3] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 280 Mo si l'une des densités suivantes est utilisée:

    • 400 dpi ou plus sur les écrans de petite/moyenne taille
    • xhdpi ou version ultérieure sur les grands écrans
    • tvdpi ou version ultérieure sur les écrans très grands

  • [7.6.1/A-2-4] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 824 Mo si l'une des densités suivantes est utilisée:

    • 560 dpi ou plus sur les écrans de petite/moyenne taille
    • 400 dpi ou plus sur les grands écrans
    • xhdpi ou version ultérieure sur les écrans très grands

Notez que la "mémoire disponible pour le kernel et l'espace utilisateur" ci-dessus fait référence à l'espace mémoire fourni en plus de la mémoire déjà dédiée aux composants matériels tels que la radio, la vidéo, etc., qui ne sont pas sous le contrôle du kernel pour les implémentations d'appareils.

Implémentations d'appareils automobiles:

  • [7.7.1/A] Un port USB compatible avec le mode périphérique DOIT être inclus.

Implémentations d'appareils automobiles:

  • [7.8.1/A-0-1] DOIT inclure un micro.

Implémentations d'appareils automobiles:

  • [7.8.2/A-0-1] DOIT disposer d'une sortie audio et déclarer android.hardware.audio.output.

2.5.2. Multimédia

Les implémentations d'appareils automobiles DOIVENT prendre en charge l'encodage audio suivant:

  • [5.1/A-0-1] Profil MPEG-4 AAC (AAC LC)
  • [5.1/A-0-2] Profil MPEG-4 HE AAC (AAC+)
  • [5.1/A-0-3] AAC ELD (AAC à faible latence améliorée)

Les implémentations d'appareils automobiles DOIVENT prendre en charge l'encodage vidéo suivant:

  • [5.2/A-0-1] H.264 AVC
  • [5.2/A-0-2] VP8

Les implémentations d'appareils automobiles DOIVENT prendre en charge le décodage vidéo suivant:

  • [5.3/A-0-1] H.264 AVC
  • [5.3/A-0-2] MPEG-4 SP
  • [5.3/A-0-3] VP8
  • [5.3/A-0-4] VP9

Il est vivement recommandé que les implémentations d'appareils automobiles soient compatibles avec le décodage vidéo suivant:

  • [5.3/A-SR] H.265 HEVC

2.5.3. Logiciel

Implémentations d'appareils automobiles:

  • [3/A-0-1] Vous DEVEZ déclarer la fonctionnalité android.hardware.type.automotive.

  • [3/A-0-2] DOIT prendre en charge uiMode = UI_MODE_TYPE_CAR.

  • [3/A-0-3] DOIT prendre en charge toutes les API publiques de l'espace de noms android.car.*.

  • [3.4.1/A-0-1] DOIT fournir une implémentation complète de l'API android.webkit.Webview.

  • [3.8.3/A-0-1] DOIT afficher les notifications qui utilisent l'API Notification.CarExtender lorsque cela est demandé par des applications tierces.

  • [3.8.4/A-SR] Il est fortement recommandé d'implémenter un assistant sur l'appareil pour gérer l'action d'assistance.

  • [3.13/A-SR] Il est vivement recommandé d'inclure un composant d'UI des paramètres rapides.

Si les implémentations d'appareils Automotive incluent un bouton PTT:

  • [3.8.4/A-1-1] L'interaction désignée pour lancer l'application d'assistance sélectionnée par l'utilisateur (autrement dit, l'application qui implémente VoiceInteractionService) DOIT être un appui bref sur le bouton PTT.

Implémentations d'appareils automobiles:

  • [3.14/A-0-1] DOIT inclure un framework d'UI pour prendre en charge les applications tierces qui utilisent les API multimédias, comme décrit dans la section 3.14.

2.5.4. Performances et puissance

Si les implémentations d'appareils Automotive incluent des fonctionnalités d'amélioration de la gestion de l'alimentation de l'appareil qui sont incluses dans AOSP ou qui étendent les fonctionnalités incluses dans AOSP, elles:

  • [8.3/A-1-1] DOIT fournir à l'utilisateur une affordance lui permettant d'activer et de désactiver la fonctionnalité Économiseur de batterie.
  • [8.3/A-1-2] L'application DOIT fournir une affordance permettant à l'utilisateur d'afficher toutes les applications qui sont exemptées des modes d'économie d'énergie App Standby et Doze.

Implémentations d'appareils automobiles:

  • [8.2/A-0-1] DOIT indiquer le nombre d'octets lus et écrits dans un stockage non volatile par UID de chaque processus afin que les statistiques soient disponibles pour les développeurs via l'API système android.car.storagemonitoring.CarStorageMonitoringManager. Le projet Android Open Source répond à cette exigence via le module du noyau uid_sys_stats.
  • [8.4/A-0-1] DOIT fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle pour chaque composant matériel et l'épuisement approximatif de la batterie causé par les composants au fil du temps, comme indiqué sur le site du projet Android Open Source.
  • [8.4/A-0-2] Toutes les valeurs de consommation d'énergie doivent être indiquées en milliampères-heures (mAh).
  • [8.4/A-0-3] DOIT indiquer la consommation d'énergie du processeur par UID de chaque processus. Le projet Android Open Source répond à cette exigence grâce à l'implémentation du module de noyau uid_cputime.
  • [8.4/A] DOIT être attribué au composant matériel lui-même si vous ne parvenez pas à attribuer la consommation d'énergie du composant matériel à une application.
  • [8.4/A-0-4] Le développeur de l'application DOIT pouvoir accéder à cette consommation d'énergie via la commande shell adb shell dumpsys batterystats.

2.5.5. Modèle de sécurité

Si les implémentations d'appareils Automotive sont compatibles avec plusieurs utilisateurs, elles:

  • [9.5/A-1-1] DOIT inclure un compte invité qui permet d'accéder à toutes les fonctions fournies par le système du véhicule sans que l'utilisateur ait à se connecter.

Si les implémentations d'appareils Automotive sont compatibles avec un écran de verrouillage sécurisé, elles:

Implémentations d'appareils automobiles:

  • [9.14/A-0-1] DOIT contrôler les messages provenant des sous-systèmes du véhicule du framework Android, par exemple en ajoutant à la liste d'autorisation les types et sources de messages autorisés.
  • [9.14/A-0-2] Le système doit surveiller les attaques de déni de service provenant du framework Android ou d'applications tierces. Cela permet de se protéger contre les logiciels malveillants qui inondent le réseau du véhicule de trafic, ce qui peut entraîner un dysfonctionnement des sous-systèmes du véhicule.

2.6. Conditions requises pour les tablettes

Un appareil Android Tablet désigne une implémentation d'appareil Android qui répond à tous les critères suivants:

  • Généralement tenu dans les deux mains.
  • Ne propose pas de configuration en mode clamshell ou convertible.
  • Toute implémentation de clavier physique utilisée avec l'appareil DOIT se connecter via une connexion standard.
  • dispose d'une source d'alimentation qui permet de le déplacer, comme une batterie ;
  • La taille de l'écran physique (diagonale) est comprise entre 7 et 18 pouces.

Les implémentations d'appareils de tablette ont des exigences similaires à celles des implémentations d'appareils portables. Les exceptions sont indiquées par un astérisque * dans cette section et sont indiquées à titre de référence dans cette section.

2.4.1. Matériel

Taille de l'écran

  • [7.1.1.1/Tab-0-1] L'écran doit mesurer entre 7 et 18 pouces.

Mémoire et stockage minimums (section 7.6.1)

Les densités d'écran indiquées pour les écrans de petite/moyenne taille dans les exigences concernant les appareils portables ne s'appliquent pas aux tablettes.

Mode périphérique USB (section 7.7.1)

Si les implémentations d'appareils de tablette incluent un port USB compatible avec le mode périphérique, elles:

  • [7.7.1/Onglet] PEUT implémenter l'API Android Open Accessory (AOA).

Mode réalité virtuelle (section 7.9.1)

Réalité virtuelle hautes performances (section 7.9.2)

Les exigences liées à la réalité virtuelle ne s'appliquent pas aux tablettes.

3. Logiciel

3.1. Compatibilité avec les API gérées

L'environnement d'exécution de bytecode Dalvik géré est le principal moyen de transport des applications Android. L'API Android est l'ensemble d'interfaces de la plate-forme Android exposées aux applications exécutées dans l'environnement d'exécution géré.

Implémentations de l'appareil:

  • [C-0-1] DOIT fournir des implémentations complètes, y compris tous les comportements documentés, de toute API documentée exposée par le SDK Android ou de toute API décorée avec le repère "@SystemApi" dans le code source Android en amont.

  • [C-0-2] DOIT prendre en charge/conserver toutes les classes, méthodes et éléments associés marqués par l'annotation TestApi (@TestApi).

  • [C-0-3] NE DOIT PAS omettre d'API gérées, modifier les interfaces ou les signatures d'API, s'écarter du comportement documenté ni inclure de no-ops, sauf dans les cas spécifiquement autorisés par cette définition de compatibilité.

  • [C-0-4] Les API doivent toujours être présentes et se comporter de manière raisonnable, même lorsque certaines fonctionnalités matérielles pour lesquelles Android inclut des API sont omises. Pour connaître les exigences spécifiques à ce scénario, consultez la section 7.

  • [C-0-5] DOIT restreindre l'utilisation des API masquées par les applications tierces, définies comme des API dans l'espace de noms Android décorées avec l'annotation @hidden, mais pas avec @SystemAPI ou @TestApi, comme décrit dans les documents du SDK et fournies avec chaque API masquée dans les mêmes listes de restriction que celles fournies via la liste provisoire et les fichiers de liste de refus dans le chemin prebuilts/runtime/appcompat/ pour la branche de niveau d'API appropriée dans l'AOSP. Toutefois, ils:

    • PEUT, si une API masquée est absente ou implémentée différemment sur l'implémentation de l'appareil, ajouter l'API masquée à la liste de blocage ou l'omettre de toutes les listes de restriction.
    • POURRA, si une API masquée n'existe pas déjà dans l'AOSP, ajouter l'API masquée à l'une des listes de restrictions.
    • PEUT implémenter un mécanisme de mise à jour dynamique qui déplace une API masquée d'une liste restreinte vers une liste moins restrictive, à l'exception de la liste d'autorisation.

3.1.1. Extensions Android

Android prend en charge l'extension des API gérées tout en conservant le même niveau d'API.

  • [C-0-1] Les implémentations d'appareils Android DOIVENT précharger l'implémentation AOSP de la bibliothèque partagée ExtShared et des services ExtServices avec des versions supérieures ou égales aux versions minimales autorisées pour chaque niveau d'API. Par exemple, les implémentations d'appareils Android 7.0 exécutant le niveau d'API 24 DOIVENT inclure au moins la version 1.

3.1.2. Bibliothèque Android

En raison de l'abandon du client HTTP Apache, les implémentations d'appareils:

  • [C-0-1] NE DOIT PAS placer la bibliothèque org.apache.http.legacy dans le bootclasspath.
  • [C-0-2] Vous devez ajouter la bibliothèque org.apache.http.legacy au chemin d'accès des classes de l'application uniquement lorsque l'application remplit l'une des conditions suivantes :
    • Cible le niveau d'API 28 ou inférieur.
    • Déclarer dans son fichier manifeste qu'il a besoin de la bibliothèque en définissant l'attribut android:name de <uses-library> sur org.apache.http.legacy.

L'implémentation AOSP répond à ces exigences.

3.2. Compatibilité des API avec une compatibilité douce

En plus des API gérées de la section 3.1, Android inclut également une API "soft" importante, uniquement au moment de l'exécution, sous la forme d'intents, d'autorisations et d'aspects similaires des applications Android qui ne peuvent pas être appliqués au moment de la compilation de l'application.

3.2.1. Autorisations

  • [C-0-1] 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. Notez que la section 9 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 destinées à décrire l'appareil actuel.

  • [C-0-1] Pour fournir des valeurs cohérentes et significatives dans les implémentations d'appareils, le tableau ci-dessous inclut des restrictions supplémentaires sur les formats de ces valeurs auxquelles les implémentations d'appareils DOIVENT se conformer.
Paramètre Détails
VERSION.RELEASE Version du système Android actuellement en cours d'exécution, au format lisible. Ce champ DOIT contenir l'une des valeurs de chaîne définies dans 9.
VERSION.SDK Version du système Android en cours d'exécution, dans un format accessible au code d'application tiers. Pour Android 9, ce champ DOIT avoir la valeur entière 9_INT.
VERSION.SDK_INT Version du système Android en cours d'exécution, dans un format accessible au code d'application tiers. Pour Android 9, ce champ DOIT avoir la valeur entière 9_INT.
VERSION.INCREMENTAL 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 les différents builds mis à la disposition des utilisateurs finaux. Ce champ est généralement utilisé pour 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 requise concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni contenir la chaîne vide ("").
JEUX DE SOCIÉTÉ Valeur choisie par l'implémentateur de l'appareil pour identifier le matériel interne spécifique utilisé par l'appareil, au format lisible par l'homme. Ce champ peut être utilisé pour indiquer la révision spécifique de la carte alimentant l'appareil. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$".
MARQUE Valeur reflétant le nom de la marque associé à l'appareil tel que connu des utilisateurs finaux. DOIT être au format lisible par l'humain et DOIT représenter le fabricant de l'appareil ou la marque de l'entreprise sous laquelle l'appareil est commercialisé. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$".
SUPPORTED_ABIS Nom de l'ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives.
SUPPORTED_32_BIT_ABIS Nom de l'ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives.
SUPPORTED_64_BIT_ABIS Nom du deuxième ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives.
CPU_ABI Nom de l'ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives.
CPU_ABI2 Nom du deuxième ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives.
APPAREIL Valeur choisie par l'implémentateur de l'appareil contenant le nom de développement ou le nom de code identifiant la configuration des fonctionnalités matérielles et la conception industrielle de l'appareil. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$". Ce nom d'appareil NE DOIT PAS changer pendant la durée de vie du produit.
FINGERPRINT Chaîne qui identifie de manière unique ce build. Il DOIT être raisonnablement lisible par l'humain. Il DOIT respecter ce modèle:

$(BRAND)/$(PRODUCT)/
    $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

Exemple :

acme/myproduct/
    mydevice:9/LMYXX/3359:userdebug/test-keys

L'empreinte ne doit PAS inclure d'espaces blancs. Si d'autres champs inclus dans le modèle ci-dessus contiennent des caractères d'espacement, ils DOIVENT être remplacés dans l'empreinte de compilation par un autre caractère, tel que le trait de soulignement ("_"). La valeur de ce champ DOIT être encodable en ASCII 7 bits.

MATÉRIEL Nom du matériel (à partir de la ligne de commande du kernel ou de /proc). Il DOIT être raisonnablement lisible par l'humain. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$".
ORGANISATEUR Chaîne qui identifie de manière unique l'hôte sur lequel le build a été créé, au format lisible par l'utilisateur. Aucune exigence n'est requise concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni contenir la chaîne vide ("").
ID Identifiant choisi par l'implémentateur de l'appareil pour faire référence à une version spécifique, au format lisible par l'utilisateur. Ce champ peut être identique à android.os.Build.VERSION.INCREMENTAL, mais DOIT être une valeur suffisamment significative pour que les utilisateurs finaux puissent distinguer les builds logiciels. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9._-]+$".
FABRICANT Nom commercial du fabricant d'équipement d'origine (OEM) du produit. Aucune exigence n'est imposée concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni contenir la chaîne vide (""). Ce champ NE DOIT PAS changer pendant la durée de vie du produit.
MODÈLE Valeur choisie par l'implémentateur de l'appareil contenant le nom de l'appareil tel que connu par l'utilisateur final. Il doit s'agir du même nom que celui sous lequel l'appareil est commercialisé et vendu aux utilisateurs finaux. Aucune exigence n'est imposée concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni contenir la chaîne vide (""). Ce champ NE DOIT PAS changer pendant la durée de vie du produit.
PRODUIT Valeur choisie par l'implémentateur de l'appareil contenant le nom de développement ou le nom de code du produit spécifique (code SKU) qui DOIT être unique au sein de la même marque. DOIT être lisible par l'utilisateur, mais n'est pas nécessairement destiné à être vu par les utilisateurs finaux. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$". Ce nom de produit NE DOIT PAS changer pendant la durée de vie du produit.
SERIAL DOIT renvoyer "UNKNOWN".
TAGS Liste de tags choisis par l'implémentateur de l'appareil, séparés par une virgule, qui permet de distinguer davantage le build. Ce champ DOIT contenir l'une des valeurs correspondant aux trois configurations de signature de la plate-forme Android standards : "release-keys", "dev-keys" et "test-keys".
DURÉE Valeur représentant le code temporel de la compilation.
MACH Valeur choisie par l'implémentateur de l'appareil, spécifiant la configuration d'exécution du build. Ce champ DOIT contenir l'une des valeurs correspondant aux trois configurations d'exécution Android typiques: user, userdebug ou eng.
UTILISATEUR Nom ou ID utilisateur de l'utilisateur (ou de l'utilisateur automatique) qui a généré le build. Aucune exigence n'est requise concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni contenir la chaîne vide ("").
SECURITY_PATCH Valeur indiquant le niveau du correctif de sécurité d'un build. Il doit indiquer que le build n'est en aucun cas vulnérable à l'un des problèmes décrits dans le bulletin de sécurité public Android désigné. Elle doit être au format [AAAA-MM-JJ] et correspondre à une chaîne définie dans le Bulletin de sécurité public Android ou dans l'Avis de sécurité Android, par exemple "2015-11-01".
BASE_OS Valeur représentant le paramètre FINGERPRINT de la version, qui est par ailleurs identique à cette version, à l'exception des correctifs fournis dans le bulletin de sécurité publique Android. Il DOIT indiquer la valeur correcte. S'il n'existe pas de build correspondant, une chaîne vide ("") doit être renvoyée.
BOOTLOADER Valeur choisie par l'implémentateur de l'appareil pour identifier la version spécifique du bootloader interne utilisée dans l'appareil, au format lisible par l'utilisateur. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9._-]+$".
getRadioVersion() DOIT (être ou renvoyer) une valeur choisie par l'implémentateur de l'appareil qui identifie la version radio/modem interne spécifique utilisée dans l'appareil, au format lisible par l'homme. Si un appareil ne dispose pas de radio/modem interne, il DOIT renvoyer NULL. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9._-,]+$".
getSerial() DOIT (être ou renvoyer) un numéro de série matériel, qui DOIT être disponible et unique pour tous les appareils du même MODÈLE et du même FABRICANT. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9._-,]+$".

3.2.3. Compatibilité des intents

3.2.3.1. Intents d'application principaux

Les intents Android permettent aux composants d'application de demander des fonctionnalités à d'autres composants Android. Le projet Android upstream inclut une liste d'applications considérées comme des applications Android principales, qui implémentent plusieurs modèles d'intent pour effectuer des actions courantes.

  • [C-0-1] Les implémentations d'appareils DOIVENT précharger une ou plusieurs applications ou composants de service avec un gestionnaire d'intent, pour tous les modèles de filtre d'intent publics définis par les applications Android principales suivantes dans AOSP:

    • Horloge de bureau
    • Navigateur
    • Agenda
    • Contacts
    • Galerie
    • GlobalSearch
    • Lanceur d'applications
    • Musique
    • Paramètres
3.2.3.2. Résolution des intents

  • [C-0-1] Étant donné qu'Android est une plate-forme extensible, les implémentations d'appareils DOIVENT autoriser chaque modèle d'intent référencé dans la section 3.2.3.1 , à l'exception de "Paramètres", à être remplacé par des applications tierces. L'implémentation Open Source d'Android en amont permet cela par défaut.

  • [C-0-2] Les implémentateurs d'appareils NE DOIVENT PAS associer des droits spéciaux à l'utilisation de ces modèles d'intent par les applications système, ni empêcher les applications tierces de s'y associer et de les contrôler. Cette interdiction inclut spécifiquement, mais sans s'y limiter, la désactivation de l'interface utilisateur "Chooser" qui permet à l'utilisateur de choisir parmi plusieurs applications qui gèrent toutes le même modèle d'intent.

  • [C-0-3] Les implémentations d'appareils DOIVENT fournir une interface utilisateur permettant aux utilisateurs de modifier l'activité par défaut des intents.

  • 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) lorsque l'activité par défaut fournit un attribut plus spécifique pour l'URI de données. Par exemple, un format de filtre d'intent spécifiant l'URI de données "http://www.android.com" est plus spécifique que le format d'intent principal du navigateur pour "http://".

Android inclut également un mécanisme permettant aux applications tierces de déclarer un comportement d'association d'application par défaut fiable pour certains types d'intents d'URI Web. Lorsque de telles déclarations faisant autorité sont définies dans les modèles de filtre d'intent d'une application, les implémentations d'appareils:

  • [C-0-4] DOIT essayer de valider tous les filtres d'intent en effectuant les étapes de validation définies dans la spécification Digital Asset Links, telles qu'implémentées par le gestionnaire de paquets dans le projet Open Source Android en amont.
  • [C-0-5] DOIT tenter de valider les filtres d'intent lors de l'installation de l'application et définir tous les filtres d'intent d'URI validés avec succès comme gestionnaires d'application par défaut pour leurs URI.
  • PEUT définir des filtres d'intent URI spécifiques comme gestionnaires d'application par défaut pour leurs URI, s'ils sont correctement validés, mais que d'autres filtres d'URI candidats ne le sont pas. Si une implémentation d'appareil le fait, elle DOIT fournir à l'utilisateur les forçages de modèle par URI appropriés dans le menu des paramètres.
  • DOIT fournir à l'utilisateur des commandes de liens d'application par application dans les paramètres, comme suit :
    • [C-0-6] L'utilisateur DOIT pouvoir remplacer de manière globale le comportement par défaut des liens d'application pour qu'une application soit toujours ouverte, toujours demander ou ne jamais s'ouvrir, ce qui doit s'appliquer de manière égale à tous les filtres d'intent URI candidats.
    • [C-0-7] L'utilisateur DOIT pouvoir consulter une liste des filtres d'intent URI candidats.
    • L'implémentation de l'appareil PEUT permettre à l'utilisateur de remplacer des filtres d'intent URI candidats spécifiques qui ont été validés, sur la base de chaque filtre d'intent.
    • [C-0-8] L'implémentation de l'appareil DOIT permettre aux utilisateurs d'afficher et de remplacer des filtres d'intent d'URI candidats spécifiques si l'implémentation de l'appareil permet à certains filtres d'intent d'URI candidats de réussir la validation, tandis que d'autres peuvent échouer.
3.2.3.3. Espaces de noms d'intent
  • [C-0-1] Les implémentations d'appareils NE DOIVENT PAS inclure de composant Android qui respecte les nouveaux modèles d'intent ou d'intent de diffusion à l'aide d'une ACTION, d'une CATEGORIE ou d'une autre chaîne de clé dans l'espace de noms android. ou com.android..
  • [C-0-2] 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.
  • [C-0-3] Les implémentateurs d'appareils NE DOIVENT PAS modifier ni étendre les modèles d'intent utilisés par les applications principales listées dans la section 3.2.3.1.
  • Les implémentations d'appareils PEUVENT inclure des modèles d'intent utilisant des espaces de noms clairement et évidemment 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.

Implémentations de l'appareil:

  • [C-0-1] DOIT diffuser les intents de diffusion publique en réponse aux événements système appropriés, comme décrit dans la documentation du SDK. Notez que cette exigence n'entre pas en conflit avec la section 3.5, car la limite applicable aux applications en arrière-plan est également décrite dans la documentation du SDK.
3.2.3.5. Paramètres de l'application par défaut

Android inclut des paramètres qui permettent aux utilisateurs de sélectionner facilement leurs applications par défaut, par exemple pour l'écran d'accueil ou les SMS.

Lorsque cela est pertinent, les implémentations d'appareils DOIVENT fournir un menu de paramètres similaire et être compatibles avec le modèle de filtre d'intent et les méthodes d'API décrits dans la documentation du SDK, comme indiqué ci-dessous.

Si les implémentations d'appareils signalent android.software.home_screen, elles:

  • [C-1-1] DOIT respecter l'intent android.settings.HOME_SETTINGS pour afficher un menu de paramètres d'application par défaut pour l'écran d'accueil.

Si les implémentations d'appareils signalent android.hardware.telephony, elles:

  • [C-2-1] DOIT fournir un menu de paramètres qui appelle l'intent android.provider.Telephony.ACTION_CHANGE_DEFAULT pour afficher une boîte de dialogue permettant de modifier l'application de SMS par défaut.

  • [C-2-2] DOIT respecter l'intent android.telecom.action.CHANGE_DEFAULT_DIALER pour afficher une boîte de dialogue permettant à l'utilisateur de modifier l'application Téléphone par défaut.

    • DOIT utiliser l'UI de l'application Téléphone par défaut sélectionnée par l'utilisateur pour les appels entrants et sortants, à l'exception des appels d'urgence, qui utilisent l'application Téléphone préinstallée.

  • [C-2-3] DOIT respecter l'intent android.telecom.action.CHANGE_PHONE_ACCOUNTS pour fournir à l'utilisateur la possibilité de configurer le ConnectionServices associé au PhoneAccounts, ainsi qu'un PhoneAccount par défaut que le fournisseur de services de télécommunications utilisera pour passer des appels sortants. L'implémentation AOSP répond à cette exigence en incluant un menu "Options de compte d'appel" dans le menu des paramètres "Appels".

Si les implémentations d'appareils signalent android.hardware.nfc.hce, elles:

Si les implémentations de l'appareil sont compatibles avec VoiceInteractionService et qu'elles ont installé plusieurs applications utilisant cette API en même temps, elles:

3.2.4. Activités sur les écrans secondaires

Si les implémentations de l'appareil permettent de lancer des activités Android normales sur les écrans secondaires, elles:

  • [C-1-1] Vous devez définir le flag de fonctionnalité android.software.activities_on_secondary_displays.
  • [C-1-2] DOIT garantir une compatibilité des API semblable à celle d'une activité exécutée sur l'écran principal.
  • [C-1-3] DOIT placer la nouvelle activité sur le même écran que l'activité qui l'a lancée, lorsque la nouvelle activité est lancée sans spécifier d'écran cible via l'API ActivityOptions.setLaunchDisplayId().
  • [C-1-4] DOIT détruire toutes les activités lorsqu'un affichage avec l'indicateur Display.FLAG_PRIVATE est supprimé.
  • [C-1-5] DOIT redimensionner en conséquence toutes les activités sur un VirtualDisplay si l'écran lui-même est redimensionné.
  • PEUT afficher un IME (éditeur de méthode d'entrée, une commande utilisateur permettant aux utilisateurs de saisir du texte) sur l'écran principal lorsqu'un champ de saisie de texte est sélectionné sur un écran secondaire.
  • DOIT implémenter la sélection de l'entrée sur l'écran secondaire indépendamment de l'écran principal, lorsque les entrées tactiles ou par clavier sont prises en charge.
  • DOIT comporter android.content.res.Configuration, qui correspond à cet écran, pour s'afficher, fonctionner correctement et assurer la compatibilité si une activité est lancée sur un écran secondaire.

Si les implémentations de l'appareil permettent de lancer des activités Android normales sur des écrans secondaires et que les écrans principaux et secondaires ont des android.util.DisplayMetrics différents:

  • [C-2-1] Les activités non redimensionnables (qui contiennent resizeableActivity=false dans AndroidManifest.xml) et les applications ciblant le niveau d'API 23 ou inférieur NE DOIVENT PAS être autorisées sur les écrans secondaires.

Si les implémentations de l'appareil permettent de lancer des activités Android normales sur des écrans secondaires et qu'un écran secondaire possède l'indicateur android.view.Display.FLAG_PRIVATE:

  • [C-3-1] Seul le propriétaire de l'écran, du système et des activités qui s'y trouvent déjà doit pouvoir y lancer des activités. Tout le monde peut lancer une application sur un écran doté du flag android.view.Display.FLAG_PUBLIC.

3.3. Compatibilité avec les API natives

La compatibilité du code natif est difficile. Par conséquent, les implémentateurs d'appareils:

  • [SR] Nous vous recommandons vivement d'utiliser les implémentations des bibliothèques listées ci-dessous à partir du projet Open Source Android en amont.

3.3.1. Interfaces binaires d'application

Le bytecode Dalvik géré peut appeler le code natif fourni dans le fichier .apk de l'application en tant que fichier .so ELF compilé pour l'architecture matérielle de l'appareil appropriée. Étant donné que 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.

Implémentations de l'appareil:

  • [C-0-1] DOIT être compatible avec une ou plusieurs ABI définies et implémenter la compatibilité avec le NDK Android.
  • [C-0-2] 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 l'interface Java Native Interface (JNI).
  • [C-0-3] DOIT être compatible avec la source (c'est-à-dire avec l'en-tête) et avec le binaire (pour l'ABI) de chaque bibliothèque requise de la liste ci-dessous.
  • [C-0-5] DOIT indiquer précisément l'interface binaire d'application (ABI) native prise en charge par l'appareil, via les paramètres android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS et android.os.Build.SUPPORTED_64_BIT_ABIS, chacun étant une liste d'ABI séparée par une virgule, de la plus à la moins préférée.

  • [C-0-6] DOIT signaler, via les paramètres ci-dessus, un sous-ensemble de la liste suivante d'ABI et NE DOIT PAS signaler d'ABI qui ne figure pas dans la liste.

    • armeabi
    • armeabi-v7a
    • arm64-v8a
    • x86
    • x86-64

    • [C-0-7] Vous DEVEZ mettre toutes les bibliothèques suivantes, qui fournissent des API natives, à la disposition des applications qui incluent du code natif:

    • libaaudio.so (prise en charge de l'audio natif AAudio)

    • libandroid.so (prise en charge des activités Android natives)
    • libc (bibliothèque C)
    • libcamera2ndk.so
    • libdl (lecteur de liens dynamique)
    • libEGL.so (gestion des surfaces OpenGL natives)
    • libGLESv1_CM.so (OpenGL ES 1.x)
    • libGLESv2.so (OpenGL ES 2.0)
    • libGLESv3.so (OpenGL ES 3.x)
    • libicui18n.so
    • libicuuc.so
    • libjnigraphics.so
    • liblog (journalisation Android)
    • libmediandk.so (compatibilité avec les API multimédias natives)
    • libm (bibliothèque mathématique)
    • libneuralnetworks.so (API Neural Networks)
    • libOpenMAXAL.so (compatibilité avec OpenMAX AL 1.0.1)
    • libOpenSLES.so (compatibilité audio OpenSL ES 1.0.1)
    • libRS.so
    • libstdc++ (compatibilité minimale avec C++)
    • libvulkan.so (Vulkan)
    • libz (compression zlib)
    • Interface JNI

  • [C-0-8] Vous NE DEVEZ PAS ajouter ni supprimer les fonctions publiques des bibliothèques natives listées ci-dessus.

  • [C-0-9] DOIT lister les bibliothèques non AOSP supplémentaires exposées directement aux applications tierces dans /vendor/etc/public.libraries.txt.
  • [C-0-10] NE DOIT PAS exposer d'autres bibliothèques natives, implémentées et fournies dans AOSP en tant que bibliothèques système, aux applications tierces ciblant le niveau d'API 24 ou version ultérieure, car elles sont réservées.
  • [C-0-11] DOIT exporter tous les symboles de fonction OpenGL ES 3.1 et du pack d'extensions Android, tels que définis dans le NDK, via la bibliothèque libGLESv3.so. Notez que, bien que tous les symboles DOIVENT être présents, la section 7.1.4.1 décrit plus en détail les exigences concernant le moment où l'implémentation complète de chaque fonction correspondante est attendue.
  • [C-0-12] DOIT exporter les symboles de fonction pour les symboles de fonction principaux de Vulkan 1.0, ainsi que les extensions VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 et VK_KHR_get_physical_device_properties2 via la bibliothèque libvulkan.so. Notez que, bien que tous les symboles DOIVENT être présents, la section 7.1.4.2 décrit plus en détail les exigences concernant le moment où l'implémentation complète de chaque fonction correspondante est attendue.
  • DOIT être compilé à l'aide du code source et des fichiers d'en-tête disponibles dans le projet Open Source Android en amont

Notez que les futures versions d'Android pourront prendre en charge d'autres ABI.

3.3.2. Compatibilité du code natif ARM 32 bits

Si les implémentations d'appareils signalent la prise en charge de l'ABI armeabi, elles:

  • [C-3-1] DOIT également prendre en charge armeabi-v7a et signaler sa prise en charge, car armeabi n'est destiné qu'à la rétrocompatibilité avec les anciennes applications.

Si les implémentations d'appareils signalent la prise en charge de l'ABI armeabi-v7a, les applications qui utilisent cette ABI:

  • [C-2-1] DOIT inclure les lignes suivantes dans /proc/cpuinfo et NE DOIT PAS modifier les valeurs sur le même appareil, même lorsqu'elles sont lues par d'autres ABI.

    • Features:, suivi d'une liste des fonctionnalités de processeur ARMv7 facultatives compatibles avec l'appareil.
    • CPU architecture:, suivi d'un entier décrivant l'architecture ARM la plus compatible de l'appareil (par exemple, "8" pour les appareils ARMv8).

  • [C-2-2] DOIT toujours maintenir les opérations suivantes disponibles, même si l'ABI est implémentée sur une architecture ARMv8, soit via la prise en charge native du processeur, soit via l'émulation logicielle:

    • Instructions SWP et SWPB
    • Instruction SETEND.
    • Opérations de barrière CP15ISB, CP15DSB et CP15DMB.

  • [C-2-3] DOIT inclure la compatibilité avec l'extension Advanced SIMD (également appelée NEON).

3.4. Compatibilité Web

3.4.1. Compatibilité avec WebView

Si les implémentations de l'appareil fournissent une implémentation complète de l'API android.webkit.Webview, elles:

  • [C-1-1] DOIT signaler android.software.webview.
  • [C-1-2] Vous devez utiliser la version du projet Chromium à partir du projet Open Source Android en amont sur la branche Android 9 pour l'implémentation de l'API android.webkit.WebView.

  • [C-1-3] La chaîne user-agent signalée par la WebView DOIT être au format suivant:

    Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

    • La valeur de la chaîne $(VERSION) DOIT être identique à celle d'android.os.Build.VERSION.RELEASE.
    • La chaîne $(MODEL) PEUT être vide, mais si elle ne l'est pas, elle DOIT avoir la même valeur que android.os.Build.MODEL.
    • "Build/$(BUILD)" peut être omis, mais si cette valeur est présente, la chaîne $(BUILD) DOIT être identique à la valeur d'android.os.Build.ID.
    • La valeur de la chaîne $(CHROMIUM_VER) DOIT correspondre à la version de Chromium dans le projet Open Source Android en amont.
    • Les implémentations d'appareils PEUVENT omettre "Mobile" dans la chaîne user-agent.

  • Le composant WebView DOIT prendre en charge autant de fonctionnalités HTML5 que possible et, s'il le fait, DOIT respecter la spécification HTML5.

3.4.2. Compatibilité avec les navigateurs

Si les implémentations d'appareils incluent une application de navigateur autonome pour la navigation Web générale, elles:

  • [C-1-1] DOIT prendre en charge chacune des API associées à HTML5 :
  • [C-1-2] DOIT être compatible avec l'API WebStorage HTML5/W3C et DEVRAIT être compatible avec l'API IndexedDB HTML5/W3C. Notez que, à mesure que les organismes de normalisation du développement Web passent à IndexedDB plutôt qu'à WebStorage, IndexedDB devrait devenir un composant obligatoire dans une prochaine version d'Android.
  • PEUT fournir une chaîne user-agent personnalisée dans l'application de navigateur autonome.
  • DOIT implémenter la compatibilité avec autant de HTML5 que possible dans l'application de navigateur autonome (qu'elle soit basée sur l'application de navigateur WebKit en amont ou sur un remplacement tiers).

Toutefois, si les implémentations d'appareils n'incluent pas d'application de navigateur autonome, elles:

  • [C-2-1] DOIT toujours prendre en charge les schémas d'intent publics, comme décrit dans la section 3.2.3.1.

3.5. Compatibilité du comportement des API

Implémentations de l'appareil:

  • [C-0-9] DOIT s'assurer que la compatibilité comportementale de l'API est appliquée à toutes les applications installées, sauf si elles sont limitées comme décrit dans la section 3.5.1.
  • [C-0-10] NE DOIT PAS implémenter l'approche d'autorisation de liste qui garantit la compatibilité comportementale de l'API uniquement pour les applications sélectionnées par les implémentateurs d'appareils.

Les comportements de chacun des types d'API (gérée, souple, native et Web) doivent être cohérents avec l'implémentation privilégiée du projet Open Source Android en amont. Voici quelques domaines de compatibilité spécifiques:

  • [C-0-1] Les appareils NE DOIVENT PAS modifier le comportement ni la sémantique d'un intent standard.
  • [C-0-2] Les appareils NE DOIVENT PAS modifier le cycle de vie ou la sémantique du cycle de vie d'un type particulier de composant système (tel que Service, Activity, ContentProvider, etc.).
  • [C-0-3] Les appareils NE DOIVENT PAS modifier la sémantique d'une autorisation standard.
  • Les appareils NE DOIVENT PAS modifier les limites appliquées aux applications en arrière-plan. Plus précisément, pour les applications en arrière-plan :
    • [C-0-4] Ils DOIVENT arrêter l'exécution des rappels enregistrés par l'application pour recevoir les sorties de GnssMeasurement et GnssNavigationMessage.
    • [C-0-5] Ils DOIVENT limiter la fréquence des mises à jour fournies à l'application via la classe d'API LocationManager ou la méthode WifiManager.startScan().
    • [C-0-6] Si l'application cible le niveau d'API 25 ou version ultérieure, elle NE DOIT PAS autoriser l'enregistrement de broadcast receivers pour les diffusions implicites d'intents Android standards dans le fichier manifeste de l'application, sauf si l'intent de diffusion nécessite une autorisation "signature" ou "signatureOrSystem" protectionLevel ou si l'application figure sur la liste d'exemptions.
    • [C-0-7] Si l'application cible le niveau d'API 25 ou une version ultérieure, elle DOIT arrêter les services en arrière-plan de l'application, comme si l'application avait appelé la méthode stopSelf() des services, sauf si l'application est placée sur une liste d'autorisation temporaire pour gérer une tâche visible par l'utilisateur.
    • [C-0-8] Si l'application cible le niveau d'API 25 ou une version ultérieure, elle DOIT libérer les wakelocks qu'elle détient.
  • [C-0-9] Les appareils DOIVENT renvoyer les fournisseurs de solutions de sécurité suivants comme sept premières valeurs de tableau de la méthode Security.getProviders(), dans l'ordre indiqué et avec les noms et les classes donnés (tels que renvoyés par Provider.getName()), sauf si l'application a modifié la liste via insertProviderAt() ou removeProvider(). Les appareils peuvent renvoyer d'autres fournisseurs après la liste de fournisseurs spécifiée ci-dessous.
    1. AndroidNSSP : android.security.net.config.NetworkSecurityConfigProvider
    2. AndroidOpenSSL : com.android.org.conscrypt.OpenSSLProvider
    3. CertPathProvider : sun.security.provider.CertPathProvider
    4. AndroidKeyStoreBCWorkaround : android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
    5. BC : com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
    6. HarmonyJSSE : com.android.org.conscrypt.JSSEProvider
    7. AndroidKeyStore : android.security.keystore.AndroidKeyStoreProvider

La liste ci-dessus n'est pas exhaustive. La suite de tests de compatibilité (CTS) vérifie la compatibilité comportementale de certaines parties importantes de la plate-forme, mais pas de toutes. Il incombe à l'implémentateur de s'assurer de la compatibilité comportementale avec le projet Android Open Source. C'est pourquoi les implémentateurs d'appareils DOIVENT utiliser le code source disponible via le projet Android Open Source dans la mesure du possible, plutôt que de réimplémenter des parties importantes du système.

3.5.1. Restriction en arrière-plan

Si les implémentations d'appareils implémentent les restrictions d'application incluses dans AOSP ou les étendent, elles:

  • [C-SR] Il est FORTEMENT RECOMMANDÉ de fournir une affordance permettant à l'utilisateur de voir la liste des applications limitées.
  • [C-1-2] L'utilisateur doit pouvoir activer / désactiver les restrictions pour chaque application.
  • [C-1-3] Le système NE DOIT PAS appliquer automatiquement de restrictions sans preuve d'un mauvais état du système, mais PEUT appliquer des restrictions aux applications en cas de détection d'un mauvais état du système, comme des wakelocks bloqués, des services de longue durée et d'autres critères. Les critères PEUVENT être déterminés par les implémentateurs de l'appareil, mais DOIVENT être liés à l'impact de l'application sur l'état du système. D'autres critères qui ne sont pas purement liés à l'état du système, tels que le manque de popularité de l'application sur le marché, NE DOIVENT PAS être utilisés.
  • [C-1-4] NE DOIT PAS appliquer automatiquement des restrictions d'application aux applications lorsqu'un utilisateur a désactivé manuellement les restrictions d'application. PEUT suggérer à l'utilisateur d'appliquer des restrictions d'application.
  • [C-1-5] DOIT informer les utilisateurs si des restrictions sont appliquées automatiquement à une application.
  • [C-1-6] DOIT renvoyer true pour ActivityManager.isBackgroundRestricted() lorsque l'application limitée appelle cette API.
  • [C-1-7] NE DOIT PAS limiter l'application de premier plan utilisée explicitement par l'utilisateur.
  • [C-1-8] DOIT suspendre les restrictions sur une application qui devient l'application de premier plan principale lorsque l'utilisateur commence explicitement à utiliser l'application qui était auparavant soumise à des restrictions.

3.6. Espaces de noms d'API

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

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

En d'autres termes:

  • [C-0-1] Vous NE DEVEZ PAS modifier les API publiques exposées sur la plate-forme Android en modifiant les signatures de méthode ou de classe, ni en supprimant des classes ou des champs de classe.
  • [C-0-2] Vous NE DEVEZ PAS ajouter d'éléments exposés publiquement (tels que des classes ou des interfaces, ou des champs ou des méthodes pour des classes ou des interfaces existantes) ni d'API de test ou système aux API des espaces de noms 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.

Les implémentateurs d'appareils PEUVENT modifier l'implémentation sous-jacente des API, mais ces modifications:

  • [C-0-3] NE DOIT PAS avoir d'incidence sur le comportement déclaré et la signature en langage Java de toute API exposée publiquement.
  • [C-0-4] NE DOIVENT PAS être annoncés ni exposés aux développeurs.

Toutefois, les implémentateurs d'appareils PEUVENT ajouter des API personnalisées en dehors de l'espace de noms Android standard, mais les API personnalisées:

  • [C-0-5] NE DOIT PAS se trouver dans un espace de noms appartenant à une autre organisation ou faisant référence à une autre organisation. Par exemple, les implémentateurs d'appareils NE DOIVENT PAS ajouter d'API à l'espace de noms com.google.* ou à un espace de noms similaire: seul Google peut le faire. De même, Google NE DOIT PAS ajouter d'API aux espaces de noms d'autres entreprises.
  • [C-0-6] DOIVENT être empaquetées dans une bibliothèque partagée Android afin que seules les applications qui les utilisent explicitement (via le mécanisme <uses-library>) soient affectées par l'augmentation de l'utilisation de la mémoire de ces API.

Si un implémentateur d'appareil propose d'améliorer l'un des espaces de noms de package ci-dessus (par exemple, en ajoutant une nouvelle fonctionnalité utile à une API existante ou en ajoutant une nouvelle API), il DOIT accéder à source.android.com et commencer le processus d'envoi de modifications et de code, conformément aux informations disponibles sur ce site.

Notez que les restrictions ci-dessus correspondent aux conventions standards de dénomination des API dans le langage de programmation Java. Cette section vise simplement à renforcer ces conventions et à les rendre contraignantes en les incluant dans cette définition de compatibilité.

3.7. Compatibilité avec l'environnement d'exécution

Implémentations de l'appareil:

  • [C-0-1] DOIT être compatible avec le format Dalvik Executable (DEX) complet et la spécification et la sémantique du bytecode Dalvik.

  • [C-0-2] Vous devez configurer les environnements d'exécution Dalvik pour qu'ils allouent de la mémoire conformément à la plate-forme Android en amont et comme indiqué dans le tableau suivant. (Consultez la section 7.1.1 pour connaître les définitions de la taille et de la densité de l'écran.)

  • DOIT utiliser Android Runtime (ART), l'implémentation en amont de référence du format Dalvik Executable et le système de gestion des paquets de l'implémentation de référence.

  • DOIT exécuter des tests de fuzz dans différents modes d'exécution et architectures cibles pour assurer la stabilité de l'environnement d'exécution. Consultez JFuzz et DexFuzz sur le site Web du projet Android Open Source.

Notez que les valeurs de mémoire spécifiées ci-dessous sont considérées comme des valeurs minimales, et que les implémentations d'appareils PEUVENT allouer plus de mémoire par application.

Mise en page de l'écran Densité d'écran Mémoire minimale de l'application
Montre Android 120 PPP (ldpi) 32 Mo
160 ppp (mdpi)
213 ppp (tvdpi)
240 ppp (hdpi) 36 Mo
280 ppp (280 dpi)
320 ppp (xhdpi) 48 Mo
360 dpi (360 dpi)
400 ppp (400 dpi) 56 Mo
420 ppp (420dpi) 64 Mo
480 dpi (xxhdpi) 88 Mo
560 ppp (560dpi) 112 Mo
640 ppp (xxxhdpi) 154 Mo
petite/normale 120 PPP (ldpi) 32 Mo
160 ppp (mdpi)
213 ppp (tvdpi) 48 Mo
240 ppp (hdpi)
280 ppp (280 dpi)
320 ppp (xhdpi) 80 Mo
360 dpi (360 dpi)
400 ppp (400 dpi) 96 Mo
420 ppp (420dpi) 112 Mo
480 dpi (xxhdpi) 128 Mo
560 ppp (560dpi) 192 Mo
640 ppp (xxxhdpi) 256 Mo
grande 120 PPP (ldpi) 32 Mo
160 ppp (mdpi) 48 Mo
213 ppp (tvdpi) 80 Mo
240 ppp (hdpi)
280 ppp (280 dpi) 96 Mo
320 ppp (xhdpi) 128 Mo
360 dpi (360 dpi) 160 Mo
400 ppp (400 dpi) 192 Mo
420 ppp (420dpi) 228 Mo
480 dpi (xxhdpi) 256 Mo
560 ppp (560dpi) 384 Mo
640 ppp (xxxhdpi) 512 Mo
xlarge 120 PPP (ldpi) 48 Mo
160 ppp (mdpi) 80 Mo
213 ppp (tvdpi) 96 Mo
240 ppp (hdpi)
280 ppp (280 dpi) 144 Mo
320 ppp (xhdpi) 192 Mo
360 dpi (360 dpi) 240 Mo
400 ppp (400 dpi) 288 Mo
420 ppp (420dpi) 336 Mo
480 dpi (xxhdpi) 384 Mo
560 ppp (560dpi) 576 Mo
640 ppp (xxxhdpi) 768 Mo

3.8. Compatibilité de l'interface utilisateur

3.8.1. Lanceur (écran d'accueil)

Android inclut une application de lanceur (écran d'accueil) et est compatible avec des applications tierces pour remplacer le lanceur de l'appareil (écran d'accueil).

Si les implémentations de l'appareil permettent aux applications tierces de remplacer l'écran d'accueil de l'appareil, elles:

  • [C-1-1] Vous DEVEZ déclarer la fonctionnalité de plate-forme android.software.home_screen.
  • [C-1-2] DOIT renvoyer l'objet AdaptiveIconDrawable lorsque l'application tierce utilise la balise <adaptive-icon> pour fournir son icône et que les méthodes PackageManager sont appelées pour récupérer les icônes.

Si les implémentations d'appareils incluent un lanceur d'applications par défaut compatible avec l'épinglage de raccourcis dans l'application, elles:

À l'inverse, si les implémentations de l'appareil ne sont pas compatibles avec l'épinglage de raccourcis dans l'application, elles:

Si les implémentations d'appareils implémentent un lanceur d'applications par défaut qui permet d'accéder rapidement aux raccourcis supplémentaires fournis par les applications tierces via l'API ShortcutManager, elles:

  • [C-4-1] DOIT prendre en charge toutes les fonctionnalités de raccourcis documentées (par exemple, les raccourcis statiques et dynamiques, les raccourcis d'épinglage) et implémenter entièrement les API de la classe d'API ShortcutManager.

Si les implémentations d'appareils incluent une application de lanceur par défaut qui affiche des badges pour les icônes d'application, elles:

  • [C-5-1] DOIT respecter la méthode d'API NotificationChannel.setShowBadge(). En d'autres termes, affichez une affordance visuelle associée à l'icône de l'application si la valeur est définie sur true, et n'affichez aucun schéma de badging d'icône d'application lorsque la valeur est définie sur false pour tous les canaux de notification de l'application.
  • PEUT remplacer les badges d'icône d'application par son propre système de badges propriétaires lorsque les applications tierces indiquent la prise en charge de ce système à l'aide d'API propriétaires, mais DOIT utiliser les ressources et les valeurs fournies par les API de badges de notification décrites dans le SDK, telles que l'API Notification.Builder.setNumber() et l'API Notification.Builder.setBadgeIconType().

3.8.2. Widgets

Android est compatible avec les widgets d'application tiers en définissant un type de composant, une API et un cycle de vie correspondants qui permettent aux applications d'exposer un "AppWidget" à l'utilisateur final.

Si les implémentations d'appareils sont compatibles avec les widgets d'applications tierces, elles:

  • [C-1-1] DOIT déclarer la prise en charge de la fonctionnalité de plate-forme android.software.app_widgets.
  • [C-1-2] DOIT 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 d'applications.
  • [C-1-3] DOIT être capable 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.
  • PEUT prendre en charge les widgets d'application sur l'écran de verrouillage.

Si les implémentations de l'appareil sont compatibles avec les widgets d'applications tierces et l'épinglage de raccourcis dans l'application, elles:

3.8.3. Notifications

Android inclut les API Notification et NotificationManager qui permettent aux développeurs d'applications tierces d'avertir les utilisateurs d'événements notables et d'attirer leur attention à l'aide des composants matériels (son, vibration et lumière, par exemple) et des fonctionnalités logicielles (par exemple, la barre de notification et la barre système) de l'appareil.

3.8.3.1. Présentation des notifications

Si les implémentations de l'appareil autorisent les applications tierces à avertir les utilisateurs d'événements notables, elles:

  • [C-1-1] DOIT 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. Ce comportement est décrit plus en détail dans la section 7.
  • [C-1-2] DOIT afficher correctement toutes les ressources (icônes, fichiers d'animation, etc.) fournies dans les API ou dans le guide de style des icônes de la barre d'état/système, bien qu'elles PUISSENT offrir une expérience utilisateur alternative pour les notifications que celle fournie par l'implémentation Android Open Source de référence.
  • [C-1-3] DOIT respecter et implémenter correctement les comportements décrits pour les API afin de mettre à jour, supprimer et regrouper les notifications.
  • [C-1-4] DOIT fournir le comportement complet de l'API NotificationChannel documentée dans le SDK.
  • [C-1-5] DOIT fournir une affordance utilisateur permettant de bloquer et de modifier les notifications d'une application tierce par canal et par niveau de package d'application.
  • [C-1-6] DOIT également fournir une affordance utilisateur pour afficher les canaux de notification supprimés.
  • [C-1-7] DOIT afficher correctement toutes les ressources (images, autocollants, icônes, etc.) fournies via Notification.MessagingStyle avec le texte de la notification, sans interaction supplémentaire de l'utilisateur. Par exemple, vous devez afficher toutes les ressources, y compris les icônes fournies via android.app.Person dans une conversation de groupe définie via setGroupConversation.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de proposer automatiquement une affordance utilisateur pour bloquer la notification d'une application tierce par canal et par niveau de package d'application après que l'utilisateur a ignoré cette notification plusieurs fois.
  • DOIT prendre en charge les notifications enrichies.
  • DOIT présenter certaines notifications de priorité plus élevée sous forme de notifications prioritaires.
  • DOIT comporter une affordance permettant à l'utilisateur de répéter les notifications.
  • NE DOIT GÉRER QUE la visibilité et le moment où les applications tierces peuvent avertir les utilisateurs d'événements notables afin de réduire les problèmes de sécurité tels que la distraction du conducteur.

Si les implémentations de l'appareil sont compatibles avec les notifications enrichies, elles:

  • [C-2-1] DOIT utiliser les ressources exactes fournies via la classe d'API Notification.Style et ses sous-classes pour les éléments de ressources présentés.
  • DOIT présenter chaque élément de ressource (par exemple, icône, titre et texte récapitulatif) défini dans la classe d'API Notification.Style et ses sous-classes.

Si les implémentations de l'appareil sont compatibles avec les notifications prioritaires :

  • [C-3-1] Vous DEVEZ utiliser la vue et les ressources de notification prioritaire, comme décrit dans la classe d'API Notification.Builder lorsque des notifications prioritaires sont présentées.
  • [C-3-2] DOIT afficher les actions fournies via Notification.Builder.addAction() avec le contenu de la notification sans interaction utilisateur supplémentaire, comme décrit dans le SDK.
3.8.3.2. Service de notification de l'auditeur

Android inclut les API NotificationListenerService qui permettent aux applications (une fois activées explicitement par l'utilisateur) de recevoir une copie de toutes les notifications lorsqu'elles sont publiées ou mises à jour.

Si les implémentations d'appareils signalent le flag de fonctionnalité android.hardware.ram.normal, elles:

  • [C-1-1] DOIT mettre à jour correctement et rapidement l'intégralité des notifications pour tous les services d'écouteur installés et activés par l'utilisateur, y compris toutes les métadonnées associées à l'objet Notification.
  • [C-1-2] DOIT respecter l'appel d'API snoozeNotification(), ignorer la notification et effectuer un rappel après la durée de répétition définie dans l'appel d'API.

Si les implémentations d'appareils disposent d'une affordance permettant à l'utilisateur de suspendre les notifications:

  • [C-2-1] DOIT refléter correctement l'état de la notification différée via les API standards telles que NotificationListenerService.getSnoozedNotifications().
  • [C-2-2] L'affordance utilisateur doit permettre de différer les notifications de chaque application tierce installée, sauf si elles proviennent de services persistants/de premier plan.
3.8.3.3. Ne pas déranger

Si les implémentations de l'appareil sont compatibles avec la fonctionnalité de mode Ne pas déranger, elles:

  • [C-1-1] DOIT implémenter une activité qui répond à l'intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS. Pour les implémentations avec UI_MODE_TYPE_NORMAL, il DOIT s'agir d'une activité dans laquelle l'utilisateur peut accorder ou refuser à l'application l'accès aux configurations de règles de non-dérangeance.
  • [C-1-2] L'appareil doit afficher les règles de mode Ne pas déranger automatiques créées par les applications ainsi que les règles prédéfinies et créées par l'utilisateur lorsque l'implémentation de l'appareil a fourni un moyen pour l'utilisateur d'autoriser ou d'interdire aux applications tierces d'accéder à la configuration des règles de mode Ne pas déranger.
  • [C-1-3] DOIT respecter les valeurs suppressedVisualEffects transmises via NotificationManager.Policy. Si une application a défini l'un des indicateurs SUPPRESSED_EFFECT_SCREEN_OFF ou SUPPRESSED_EFFECT_SCREEN_ON, elle DOIT indiquer à l'utilisateur que les effets visuels sont supprimés dans le menu des paramètres du mode Ne pas déranger.

Android inclut des API qui permettent aux développeurs d'intégrer la recherche dans leurs applications et d'exposer les données de leur application dans la recherche système globale. En général, cette fonctionnalité consiste en une interface utilisateur unique, à l'échelle du système, qui permet aux utilisateurs de saisir des requêtes, d'afficher des suggestions au fur et à mesure de la saisie et d'afficher des résultats. Les API Android permettent aux développeurs de réutiliser cette interface pour fournir une recherche dans leurs propres applications et de fournir des résultats à l'interface utilisateur de recherche globale commune.

  • Les implémentations d'appareils Android DOIVENT inclure une recherche globale, une interface utilisateur de recherche unique, partagée et à l'échelle du système, capable de proposer des suggestions en temps réel en réponse à l'entrée utilisateur.

Si les implémentations d'appareils implémentent l'interface de recherche globale, elles:

  • [C-1-1] DOIT implémenter les API qui permettent aux applications tierces d'ajouter des suggestions dans le champ de recherche lorsqu'il est exécuté en mode recherche globale.

Si aucune application tierce n'est installée qui utilise la recherche globale:

  • Le comportement par défaut DOIT être l'affichage des résultats et des suggestions du moteur de recherche sur le Web.

Android inclut également les API Assist, qui permettent aux applications de choisir la quantité d'informations du contexte actuel à partager avec l'assistant sur l'appareil.

Si les implémentations de l'appareil sont compatibles avec l'action d'assistance, elles:

  • [C-2-1] DOIT indiquer clairement à l'utilisateur final quand le contexte est partagé, par :
    • Chaque fois que l'application d'assistance accède au contexte, elle affiche une lumière blanche autour des bords de l'écran qui correspond ou dépasse la durée et la luminosité de l'implémentation du projet Android Open Source.
    • Pour l'application d'assistance préinstallée, fournir une affordance utilisateur à moins de deux navigations du menu de paramètres par défaut de la saisie vocale et de l'application d'assistance, et ne partager le contexte que lorsque l'application d'assistance est explicitement appelée par l'utilisateur via un mot clé ou une saisie de touche de navigation d'assistance.
  • [C-2-2] L'interaction désignée pour lancer l'application d'assistance, comme décrit dans la section 7.2.3, DOIT lancer l'application d'assistance sélectionnée par l'utilisateur, c'est-à-dire l'application qui implémente VoiceInteractionService ou une activité qui gère l'intent ACTION_ASSIST.

3.8.5. Alertes et notifications toast

Les applications peuvent utiliser l'API Toast pour afficher des chaînes courtes non modales à l'utilisateur final qui disparaissent après un court laps de temps, et l'API de type de fenêtre TYPE_APPLICATION_OVERLAY pour afficher des fenêtres d'alerte en superposition sur d'autres applications.

Si les implémentations d'appareils incluent un écran ou une sortie vidéo, elles:

  • [C-1-1] DOIT fournir une affordance utilisateur pour empêcher une application d'afficher des fenêtres d'alerte qui utilisent TYPE_APPLICATION_OVERLAY . L'implémentation AOSP répond à cette exigence en proposant des commandes dans la barre de notification.

  • [C-1-2] DOIT respecter l'API Toast et afficher les toasts des applications aux utilisateurs finaux de manière très visible.

3.8.6. Thèmes

Android fournit des "thèmes" qui permettent aux applications d'appliquer des styles à l'ensemble d'une activité ou d'une application.

Android inclut une famille de thèmes "Holo" et "Material" sous la forme d'un 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.

Si les implémentations d'appareils incluent un écran ou une sortie vidéo, elles:

  • [C-1-1] Vous NE DEVEZ PAS modifier les attributs du thème Holo exposés aux applications.
  • [C-1-2] DOIT être compatible avec la famille de thèmes "Material" et NE DOIT PAS modifier les attributs du thème Material ni les éléments exposés aux applications.

Android inclut également une famille de thèmes "Par défaut de l'appareil", qui est un 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.

Android est compatible avec un thème de variante avec des barres système transparentes, ce qui permet aux développeurs d'applications de remplir la zone derrière la barre d'état et la barre de navigation avec le contenu de leur application. Pour offrir une expérience de développement cohérente dans cette configuration, il est important que le style des icônes de la barre d'état soit conservé sur les différentes implémentations d'appareils.

Si les implémentations d'appareils incluent une barre d'état du système, elles:

  • [C-2-1] Vous devez utiliser le blanc pour les icônes d'état du système (telles que l'intensité du signal et le niveau de la batterie) et les notifications émises par le système, sauf si l'icône indique un état problématique ou qu'une application demande une barre d'état claire à l'aide de l'indicateur SYSTEM_UI_FLAG_LIGHT_STATUS_BAR.
  • [C-2-2] Les implémentations d'appareils Android DOIVENT changer la couleur des icônes d'état du système en noir (pour en savoir plus, consultez R.style) lorsqu'une application demande une barre d'état claire.

3.8.7. 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. 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 de manière fiable des fonds d'écran animés s'il peut exécuter tous les fonds d'écran animés, sans aucune limitation de fonctionnalité, à une fréquence d'images raisonnable et sans effet négatif sur d'autres applications. Si des limites matérielles provoquent le plantage ou le dysfonctionnement des fonds d'écran et/ou des applications, ou qu'elles consomment une quantité excessive d'énergie de la batterie ou du processeur, ou qu'elles s'exécutent à une fréquence d'images inacceptablement faible, le matériel est considéré comme incapable d'exécuter un fond d'écran animé. Par exemple, certains fonds d'écran animés peuvent utiliser un contexte OpenGL 2.0 ou 3.x pour afficher leur contenu. Le fond d'écran animé ne s'exécute pas de manière fiable sur du matériel qui n'est pas compatible avec plusieurs contextes OpenGL, car l'utilisation d'un contexte OpenGL par le fond d'écran animé peut entrer en conflit avec d'autres applications qui utilisent également un contexte OpenGL.

  • Les implémentations d'appareils capables d'exécuter des fonds d'écran animés de manière fiable, comme décrit ci-dessus, DOIVENT implémenter des fonds d'écran animés.

Si les implémentations d'appareils implémentent des fonds d'écran animés, elles:

  • [C-1-1] DOIT signaler le flag de fonctionnalité de plate-forme android.software.live_wallpaper.

3.8.8. Changement d'activité

Le code source Android en amont inclut l'écran d'aperçu, une interface utilisateur au niveau du système permettant de changer de tâche et d'afficher les activités et tâches récemment consultées à 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 incluant la touche de navigation de la fonctionnalité "Récents", comme indiqué dans la section 7.2.3, PEUVENT modifier l'interface.

Si les implémentations d'appareils incluant la touche de navigation de la fonctionnalité "Récents", comme indiqué dans la section 7.2.3, modifient l'interface, elles:

  • [C-1-1] DOIT prendre en charge au moins sept activités affichées.
  • DOIT afficher au moins le titre de quatre activités à la fois.
  • [C-1-2] DOIT implémenter le comportement d'épinglage de l'écran et fournir à l'utilisateur un menu de paramètres pour activer ou désactiver la fonctionnalité.
  • DOIT afficher la couleur de surbrillance, l'icône et le titre de l'écran dans les éléments récents.
  • DOIT afficher une affordance de fermeture ("x"), mais PEUT retarder cette action jusqu'à ce que l'utilisateur interagisse avec les écrans.
  • DOIT implémenter un raccourci pour passer facilement à l'activité précédente.
  • DOIT déclencher l'action de commutation rapide entre les deux applications les plus récemment utilisées lorsque la touche de fonction "Récents" est enfoncée deux fois.
  • DOIT déclencher le mode multifenêtre en écran partagé, le cas échéant, lorsque la touche de fonction "Récents" est enfoncée de manière prolongée.
  • PEUT afficher les éléments récents associés sous forme de groupe qui se déplace ensemble.
  • [SR] Il est FORTEMENT RECOMMANDÉ d'utiliser l'interface utilisateur Android en amont (ou une interface basée sur des miniatures similaire) pour l'écran d'aperçu.

3.8.9. Gestion des entrées

Android est compatible avec la gestion des entrées et les éditeurs de modes de saisie tiers.

Si les implémentations de l'appareil permettent aux utilisateurs d'utiliser des modes de saisie tiers sur l'appareil, elles:

  • [C-1-1] DOIT déclarer la fonctionnalité de plate-forme android.software.input_methods et prendre en charge les API IME, comme défini dans la documentation du SDK Android.
  • [C-1-2] DOIT fournir un mécanisme accessible à l'utilisateur pour ajouter et configurer des modes de saisie tiers en réponse à l'intent android.settings.INPUT_METHOD_SETTINGS.

Si les implémentations d'appareils déclarent l'indicateur de fonctionnalité android.software.autofill, elles:

3.8.10. Contrôle des contenus multimédias sur l'écran de verrouillage

L'API Client de télécommande est obsolète à partir d'Android 5.0 et est remplacée par le modèle de notification multimédia, qui permet aux applications multimédias de s'intégrer aux commandes de lecture affichées sur l'écran de verrouillage.

3.8.11. Économiseurs d'écran (anciennement "Dreams")

Android est compatible avec les écrans de veille interactifs, auparavant appelés Dreams. Les écrans de veille permettent aux utilisateurs d'interagir avec les applications lorsqu'un appareil connecté à une source d'alimentation est inactif ou posé sur une station d'accueil. Les appareils Android Watch PEUVENT implémenter des économiseurs d'écran, mais les autres types d'implémentations d'appareils DOIVENT prendre en charge les économiseurs d'écran et fournir une option de paramètres permettant aux utilisateurs de les configurer en réponse à l'intent android.settings.DREAM_SETTINGS.

3.8.12. Position

Si les implémentations d'appareils incluent un capteur matériel (par exemple, un GPS) capable de fournir les coordonnées de localisation,

3.8.13. Unicode et police

Android est compatible avec les caractères emoji définis dans Unicode 10.0.

Si les implémentations d'appareils incluent un écran ou une sortie vidéo, elles:

  • [C-1-1] La plate-forme DOIT être capable d'afficher ces caractères emoji sous forme de glyphes en couleur.
  • [C-1-2] DOIT inclure la prise en charge des éléments suivants :
    • Police Roboto 2 avec différents épaisseurs : sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light pour les langues disponibles sur l'appareil.
    • Couverture complète de l'alphabet latin, grec et cyrillique dans Unicode 7.0, y compris les plages Latin Extended A, B, C et D, ainsi que tous les glyphes du bloc des symboles de devises d'Unicode 7.0.
  • DOIT être compatible avec les emoji de couleur de peau et de famille variés, comme indiqué dans le rapport technique Unicode 51.

Si les implémentations d'appareils incluent un IME, elles:

  • DOIT fournir à l'utilisateur une méthode d'entrée pour ces caractères emoji.

3.8.14. Multifenêtre

Si les implémentations d'appareils peuvent afficher plusieurs activités en même temps, elles:

  • [C-1-1] DOIT implémenter ces modes multifenêtre conformément aux comportements d'application et aux API décrits dans la documentation de compatibilité du mode multifenêtre du SDK Android, et respecter les exigences suivantes:
  • [C-1-2] Les applications peuvent indiquer si elles peuvent fonctionner en mode multifenêtre dans le fichier AndroidManifest.xml, soit explicitement en définissant l'attribut android:resizeableActivity sur true, soit implicitement en définissant la valeur targetSdkVersion > 24. Les applications qui définissent explicitement cet attribut sur false dans leur fichier manifeste NE DOIVENT PAS être lancées en mode multifenêtre. Les applications plus anciennes dont la version cible est inférieure à 24 et qui n'ont pas défini cet attribut android:resizeableActivity PEUVENT être lancées en mode multifenêtre, mais le système DOIT envoyer un avertissement indiquant que l'application risque de ne pas fonctionner comme prévu en mode multifenêtre.
  • [C-1-3] NE DOIT PAS proposer de mode fractionné ou de mode libre si la hauteur de l'écran est inférieure à 440 dp et la largeur de l'écran est inférieure à 440 dp.
  • Les implémentations d'appareils avec une taille d'écran xlarge DOIVENT être compatibles avec le mode Format libre.

Si les implémentations de l'appareil sont compatibles avec le ou les modes multifenêtre et le mode Écran partagé, elles:

  • [C-2-1] DOIT précharger un lanceur redimensionnable par défaut.
  • [C-2-2] L'activité ancrée d'un mode multifenêtre en écran partagé DOIT être recadrée, mais elle DOIT afficher une partie de son contenu si l'application Launcher est la fenêtre sélectionnée.
  • [C-2-3] DOIT respecter les valeurs AndroidManifestLayout_minWidth et AndroidManifestLayout_minHeight déclarées de l'application de lanceur tiers et ne pas remplacer ces valeurs lors de l'affichage d'un contenu de l'activité ancrée.

Si les implémentations de l'appareil sont compatibles avec le ou les modes multifenêtre et le mode multifenêtre Picture-in-picture, elles:

  • [C-3-1] DOIT lancer des activités en mode multifenêtre Picture-in-picture lorsque l'application: * cible le niveau d'API 26 ou supérieur et déclare android:supportsPictureInPicture * cible le niveau d'API 25 ou inférieur et déclare à la fois android:resizeableActivity et android:supportsPictureInPicture.
  • [C-3-2] DOIT exposer les actions dans son SystemUI, comme spécifié par l'activité PIP actuelle via l'API setActions().
  • [C-3-3] DOIT prendre en charge les formats supérieurs ou égaux à 1:2,39 et inférieurs ou égaux à 2,39:1, comme spécifié par l'activité PIP via l'API setAspectRatio().
  • [C-3-4] Vous devez utiliser KeyEvent.KEYCODE_WINDOW pour contrôler la fenêtre PIP. Si le mode PIP n'est pas implémenté, la clé doit être disponible pour l'activité de premier plan.
  • [C-3-5] DOIT fournir une affordance utilisateur pour empêcher l'affichage d'une application en mode PIP. L'implémentation AOSP répond à cette exigence en disposant de commandes dans la barre de notification.
  • [C-3-6] DOIT allouer une largeur et une hauteur minimales de 108 dp pour la fenêtre PIP, et une largeur minimale de 240 dp et une hauteur de 135 dp pour la fenêtre PIP lorsque Configuration.uiMode est configuré en tant que UI_MODE_TYPE_TELEVISION.

3.8.15. Encoche

Android est compatible avec les découpes d'écran, comme décrit dans la documentation du SDK. L'API DisplayCutout définit une zone sur le bord de l'écran qui n'est pas fonctionnelle pour l'affichage de contenu.

Si les implémentations de l'appareil incluent une ou plusieurs découpes d'écran:

  • [C-1-1] Les découpes ne doivent se trouver que sur les bords courts de l'appareil. À l'inverse, si le format de l'appareil est 1,0 (1:1), il NE DOIT PAS comporter de découpe.
  • [C-1-2] Il ne doit pas y avoir plus d'une découpe par arête.
  • [C-1-3] DOIT respecter les indicateurs de découpe d'affichage définis par l'application via l'API WindowManager.LayoutParams, comme décrit dans le SDK.
  • [C-1-4] DOIT indiquer des valeurs correctes pour toutes les métriques de découpage définies dans l'API DisplayCutout.

3.9. Gestion de l'appareil

Android inclut des fonctionnalités qui permettent aux applications axées sur la sécurité d'effectuer des fonctions d'administration d'appareils au niveau du système, telles que l'application de règles de mot de passe ou l'effacement à distance, via l'API Android Device Administration.

Si les implémentations d'appareils implémentent l'ensemble des règles d'administration des appareils définies dans la documentation du SDK Android, elles:

  • [C-1-1] Vous devez déclarer android.software.device_admin.
  • [C-1-2] DOIT prendre en charge le provisionnement du propriétaire de l'appareil, comme décrit dans les sections 3.9.1 et 3.9.1.1.

3.9.1 Préparation de l'appareil

3.9.1.1 Provisionnement du propriétaire de l'appareil

Si les implémentations d'appareils déclarent android.software.device_admin, elles:

  • [C-1-1] DOIT prendre en charge l'enregistrement d'un client Device Policy (DPC) en tant qu'application propriétaire de l'appareil, comme décrit ci-dessous :
  • [C-1-2] L'utilisateur doit impérativement effectuer une action affirmative pendant le processus de provisionnement pour autoriser l'application à être définie comme propriétaire de l'appareil. Le consentement peut être obtenu par action de l'utilisateur ou par des moyens programmatiques lors du provisionnement, mais il NE DOIT PAS être encodé en dur ni empêcher l'utilisation d'autres applications appartenant à l'administrateur de l'appareil.

Si les implémentations d'appareils déclarent android.software.device_admin, mais incluent également une solution de gestion propriétaire du propriétaire de l'appareil et fournissent un mécanisme permettant de promouvoir une application configurée dans leur solution en tant qu'"équivalent du propriétaire de l'appareil" par rapport au propriétaire de l'appareil standard reconnu par les API Android DevicePolicyManager standards, elles:

  • [C-2-1] DOIT mettre en place un processus permettant de vérifier que l'application spécifique promue appartient à une solution de gestion des appareils d'entreprise légitime et qu'elle a déjà été configurée dans la solution propriétaire pour disposer des droits équivalents à ceux d'un "propriétaire d'appareil".
  • [C-2-2] DOIT afficher le même communiqué de consentement du propriétaire de l'appareil AOSP que le flux lancé par android.app.action.PROVISION_MANAGED_DEVICE avant d'enregistrer l'application DPC en tant que "Propriétaire de l'appareil".
  • PEUT avoir des données utilisateur sur l'appareil avant d'enregistrer l'application DPC en tant que "Propriétaire de l'appareil".
3.9.1.2 Provisionnement de profils gérés

Si les implémentations d'appareils déclarent android.software.managed_users, elles:

  • [C-1-1] DOIT implémenter les API permettant à une application de contrôle des règles relatives aux appareils (DPC) de devenir le propriétaire d'un nouveau profil géré.

  • [C-1-2] L'expérience utilisateur du processus de provisionnement de profil géré (flux lancé par android.app.action.PROVISION_MANAGED_PROFILE) DOIT être conforme à l'implémentation AOSP.

  • [C-1-3] DOIT fournir les affordances utilisateur suivantes dans les paramètres pour indiquer à l'utilisateur quand une fonction système particulière a été désactivée par le contrôleur de stratégie d'appareil (DPC):

    • Une icône cohérente ou une autre affordance utilisateur (par exemple, l'icône d'informations AOSP en amont) pour indiquer qu'un paramètre particulier est limité par un administrateur d'appareil.
    • Brève explication fournie par l'administrateur de l'appareil via setShortSupportMessage.
    • Icône de l'application DPC.

3.9.2 Prise en charge des profils gérés

Si les implémentations d'appareils déclarent android.software.managed_users, elles:

  • [C-1-1] DOIT prendre en charge les profils gérés via les API android.app.admin.DevicePolicyManager.
  • [C-1-2] DOIT permettre de créer un seul profil géré.
  • [C-1-3] DOIT utiliser un badge d'icône (similaire au badge de travail en amont d'AOSP) pour représenter les applications et widgets gérés, ainsi que d'autres éléments d'interface utilisateur avec badge, comme "Récents" et "Notifications".
  • [C-1-4] DOIT afficher une icône de notification (similaire au badge professionnel en amont d'AOSP) pour indiquer quand l'utilisateur se trouve dans une application de profil géré.
  • [C-1-5] DOIT afficher un toast indiquant que l'utilisateur se trouve dans le profil géré si et quand l'appareil se réveille (ACTION_USER_PRESENT) et que l'application de premier plan se trouve dans le profil géré.
  • [C-1-6] Lorsqu'un profil géré existe, le "sélecteur d'intents" doit afficher une affordance visuelle pour permettre à l'utilisateur de transférer l'intent du profil géré vers l'utilisateur principal ou inversement, si cette fonctionnalité est activée par le contrôleur de règles d'appareil.
  • [C-1-7] Lorsqu'un profil géré existe, il DOIT exposer les affordances utilisateur suivantes à la fois pour l'utilisateur principal et le profil géré :
    • Comptabilisation distincte de l'utilisation de la batterie, de la position, des données mobiles et de l'espace de stockage pour l'utilisateur principal et le profil géré.
    • Gestion indépendante des applications VPN installées dans l'utilisateur principal ou le profil géré.
    • Gestion indépendante des applications installées dans l'utilisateur principal ou le profil géré.
    • Gestion indépendante des comptes dans le profil utilisateur principal ou géré.
  • [C-1-8] DOIT s'assurer que les applications préinstallées du clavier, des contacts et de la messagerie peuvent rechercher et consulter les informations sur l'appelant du profil géré (le cas échéant) ainsi que celles du profil principal, si le contrôleur de stratégie de l'appareil l'autorise.
  • [C-1-9] DOIT s'assurer qu'il répond à toutes les exigences de sécurité applicables à un appareil avec plusieurs utilisateurs activés (voir la section 9.5), même si le profil géré n'est pas comptabilisé comme un autre utilisateur en plus de l'utilisateur principal.
  • [C-1-10] DOIT permettre de spécifier un écran de verrouillage distinct répondant aux exigences suivantes pour accorder l'accès aux applications exécutées dans un profil géré.
    • Les implémentations d'appareils DOIVENT respecter l'intent DevicePolicyManager.ACTION_SET_NEW_PASSWORD et afficher une interface permettant de configurer des identifiants d'écran de verrouillage distincts pour le profil géré.
    • Les identifiants de l'écran de verrouillage du profil géré DOIVENT utiliser les mêmes mécanismes de stockage et de gestion des identifiants que le profil parent, comme indiqué sur le site du projet Open Source Android.
    • Les règles de mot de passe du DPC DOIVENT s'appliquer uniquement aux identifiants de l'écran de verrouillage du profil géré, sauf si elles sont appelées sur l'instance DevicePolicyManager renvoyée par getParentProfileInstance.
  • Lorsque les contacts du profil géré s'affichent dans le journal des appels préinstallé, l'interface utilisateur de l'appel, les notifications d'appel en cours et manqués, les applications de contacts et de messagerie, ils DOIVENT être associés au même badge que celui utilisé pour indiquer les applications du profil géré.

3.9.3 Assistance utilisateur gérée

Si les implémentations d'appareils déclarent android.software.managed_users, elles:

  • [C-1-1] DOIT fournir une affordance utilisateur permettant de se déconnecter de l'utilisateur actuel et de revenir à l'utilisateur principal dans une session multi-utilisateur lorsque isLogoutEnabled renvoie true. L'affordance utilisateur DOIT être accessible depuis l'écran de verrouillage sans déverrouiller l'appareil.

3.10. Accessibilité

Android fournit une couche d'accessibilité qui aide les utilisateurs ayant un handicap à naviguer plus facilement sur leurs appareils. De plus, Android 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 retour, tels que la synthèse vocale, le retour haptique et la navigation avec le pavé tactile/le pavé directionnel.

Si les implémentations d'appareils sont compatibles avec des services d'accessibilité tiers, elles:

  • [C-1-1] DOIT fournir une implémentation du framework d'accessibilité Android, comme décrit dans la documentation du SDK sur les API d'accessibilité.
  • [C-1-2] DOIT générer des événements d'accessibilité et transmettre le AccessibilityEvent approprié à toutes les implémentations AccessibilityService enregistrées, comme indiqué dans le SDK.
  • [C-1-3] DOIT respecter l'intent android.settings.ACCESSIBILITY_SETTINGS pour fournir un mécanisme accessible à l'utilisateur permettant d'activer et de désactiver les services d'accessibilité tiers en plus des services d'accessibilité préinstallés.
  • [C-1-4] DOIT ajouter un bouton dans la barre de navigation du système permettant à l'utilisateur de contrôler le service d'accessibilité lorsque les services d'accessibilité activés déclarent AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON . Notez que cette exigence n'est pas applicable aux implémentations d'appareils sans barre de navigation système, mais les implémentations d'appareils DOIVENT fournir une affordance utilisateur pour contrôler ces services d'accessibilité.

Si les implémentations de l'appareil incluent des services d'accessibilité préinstallés, elles:

  • [C-2-1] Vous DEVEZ implémenter ces services d'accessibilité préinstallés en tant qu'applications compatibles avec le démarrage direct lorsque le stockage de données est chiffré avec le chiffrement basé sur les fichiers (FBE).
  • DOIT fournir un mécanisme dans le flux de configuration prêt à l'emploi permettant aux utilisateurs d'activer les services d'accessibilité pertinents, ainsi que des options permettant d'ajuster la taille de la police, la taille de l'écran et les gestes d'agrandissement.

3.11. Synthèse vocale

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

Si les implémentations d'appareils signalent la fonctionnalité android.hardware.audio.output, elles:

Si les implémentations d'appareils acceptent l'installation de moteurs TTS tiers, elles:

  • [C-2-1] DOIT fournir une affordance utilisateur permettant à l'utilisateur de sélectionner un moteur de synthèse vocale à utiliser au niveau du système.

3.12. TV Input Framework

Le framework d'entrée Android TV (TIF) simplifie la diffusion de contenus en direct sur les appareils Android TV. TIF fournit une API standard pour créer des modules d'entrée qui contrôlent les appareils Android TV.

Si les implémentations de l'appareil sont compatibles avec le TIF:

  • [C-1-1] Vous DEVEZ déclarer la fonctionnalité de plate-forme android.software.live_tv.
  • [C-1-2] DOIT prendre en charge toutes les API TIF afin qu'une application qui utilise ces API et le service d'entrées tierces basées sur TIF puisse être installée et utilisée sur l'appareil.

3.13. Les réglages rapides

Android fournit un composant d'UI de configuration rapide qui permet d'accéder rapidement aux actions fréquemment utilisées ou nécessaires de toute urgence.

Si les implémentations de l'appareil incluent un composant d'UI des paramètres rapides, elles:

  • [C-1-1] DOIT permettre à l'utilisateur d'ajouter ou de supprimer les cartes fournies via les API quicksettings à partir d'une application tierce.
  • [C-1-2] NE DOIT PAS ajouter automatiquement une carte d'une application tierce directement aux Réglages rapides.
  • [C-1-3] DOIT afficher toutes les cartes ajoutées par l'utilisateur à partir d'applications tierces, ainsi que les cartes de réglages rapides fournies par le système.

3.14. Interface utilisateur multimédia

Si les implémentations d'appareils incluent le framework d'UI compatible avec les applications tierces qui dépendent de MediaBrowser et de MediaSession , elles:

3.15. Applis instantanées

Les implémentations d'appareils DOIVENT répondre aux exigences suivantes:

  • [C-0-1] Les applications instantanées ne doivent être autorisées qu'à utiliser les autorisations dont la valeur android:protectionLevel est définie sur "instant".
  • [C-0-2] Les applications instantanées NE DOIVENT PAS interagir avec les applications installées via des intents implicites, sauf si l'une des conditions suivantes est remplie :
    • Le filtre de modèle d'intent du composant est exposé et comporte CATEGORY_BROWSABLE.
    • L'action est ACTION_SEND, ACTION_SENDTO ou ACTION_SEND_MULTIPLE.
    • La cible est exposée explicitement avec android:visibleToInstantApps
  • [C-0-3] Les applications instantanées NE DOIVENT PAS interagir explicitement avec les applications installées, sauf si le composant est exposé via android:visibleToInstantApps.
  • [C-0-4] Les applications installées NE DOIVENT PAS voir les informations sur les applications instantanées sur l'appareil, sauf si l'application instantanée se connecte explicitement à l'application installée.

3.16. Association d'un appareil associé

Android est compatible avec l'association d'appareils associés pour gérer plus efficacement l'association avec les appareils associés. Il fournit l'API CompanionDeviceManager pour que les applications puissent accéder à cette fonctionnalité.

Si les implémentations d'appareils sont compatibles avec la fonctionnalité d'association de l'appareil associé, elles:

  • [C-1-1] Vous DEVEZ déclarer le flag de fonctionnalité FEATURE_COMPANION_DEVICE_SETUP .
  • [C-1-2] DOIT s'assurer que les API du package android.companion sont entièrement implémentées.
  • [C-1-3] DOIT fournir des affordances permettant à l'utilisateur de sélectionner/confirmer qu'un appareil associé est présent et opérationnel.

3.17. Applications lourdes

Si les implémentations de l'appareil déclarent la fonctionnalité FEATURE_CANT_SAVE_STATE, elles:

  • [C-1-1] Une seule application installée doit spécifier cantSaveState en cours d'exécution dans le système à la fois. Si l'utilisateur quitte une telle application sans la quitter explicitement (par exemple, en appuyant sur "Accueil" lorsqu'il quitte une activité active du système, au lieu d'appuyer sur "Retour" alors qu'il n'y a plus d'activités actives dans le système), les implémentations de l'appareil DOIVENT donner la priorité à cette application dans la RAM, comme elles le font pour les autres éléments qui doivent rester en cours d'exécution, tels que les services de premier plan. Même si une telle application est en arrière-plan, le système peut toujours lui appliquer des fonctionnalités de gestion de l'alimentation, telles que la limitation de l'accès au processeur et au réseau.
  • [C-1-2] DOIT fournir une affordance d'UI pour choisir l'application qui ne participera pas au mécanisme de sauvegarde/restauration d'état normal une fois que l'utilisateur lance une deuxième application déclarée avec l'attribut cantSaveState.
  • [C-1-3] NE DOIT PAS appliquer d'autres modifications de règles aux applications qui spécifient cantSaveState, telles que la modification des performances du processeur ou de la priorité de planification.

Si les implémentations de l'appareil ne déclarent pas la fonctionnalité FEATURE_CANT_SAVE_STATE, elles:

  • [C-1-1] DOIT ignorer l'attribut cantSaveState défini par les applications et NE DOIT PAS modifier le comportement de l'application en fonction de cet attribut.

4. Compatibilité du packaging d'applications

Implémentations des appareils:

  • [C-0-1] DOIT être capable d'installer et d'exécuter les fichiers ".apk" Android générés par l'outil "aapt" inclus dans le SDK Android officiel.
  • Étant donné que l'exigence ci-dessus peut s'avérer difficile, il est RECOMMANDÉ d'utiliser le système de gestion des paquets de l'implémentation de référence AOSP pour les implémentations d'appareils.

Implémentations de l'appareil:

  • [C-0-2] DOIT être compatible avec la validation des fichiers ".apk" à l'aide du schéma de signature des APK v3 , du schéma de signature des APK v2 et de la signature JAR.
  • [C-0-3] NE DOIT PAS étendre les formats .apk, Android Manifest, bytecode Dalvik ou bytecode RenderScript de manière à empêcher l'installation et l'exécution correcte de ces fichiers sur d'autres appareils compatibles.

  • [C-0-4] NE DOIT PAS autoriser les applications autres que l'installateur enregistré actuel du package à désinstaller l'application en mode silencieux sans confirmation de l'utilisateur, comme indiqué dans le SDK pour l'autorisation DELETE_PACKAGE. Les seules exceptions sont l'application de vérification des paquets système qui gère l'intent PACKAGE_NEEDS_VERIFICATION et l'application de gestion de l'espace de stockage qui gère l'intent ACTION_MANAGE_STORAGE.

  • [C-0-5] Une activité doit gérer l'intent android.settings.MANAGE_UNKNOWN_APP_SOURCES.

  • [C-0-6] NE DOIT PAS installer de packages d'application à partir de sources inconnues, sauf si l'application qui demande l'installation répond à toutes les exigences suivantes:

    • Il DOIT déclarer l'autorisation REQUEST_INSTALL_PACKAGES ou définir android:targetSdkVersion sur 24 ou moins.
    • L'utilisateur doit avoir autorisé l'installation d'applications provenant de sources inconnues.

  • DOIT fournir une affordance utilisateur permettant d'accorder/de révoquer l'autorisation d'installer des applications à partir de sources inconnues par application, mais PEUT choisir de l'implémenter comme une opération sans effet et de renvoyer RESULT_CANCELED pour startActivityForResult(), si l'implémentation de l'appareil ne souhaite pas permettre aux utilisateurs de faire ce choix. Toutefois, même dans ce cas, ils DOIVENT indiquer à l'utilisateur pourquoi aucun choix de ce type n'est proposé.

  • [C-0-7] DOIT afficher une boîte de dialogue d'avertissement avec la chaîne d'avertissement fournie à l'utilisateur via l'API système PackageManager.setHarmfulAppWarning avant de lancer une activité dans une application qui a été marquée par la même API système PackageManager.setHarmfulAppWarning comme potentiellement dangereuse.

  • DOIT fournir une affordance permettant à l'utilisateur de choisir de désinstaller ou de lancer une application dans la boîte de dialogue d'avertissement.

5. Compatibilité multimédia

Implémentations de l'appareil:

  • [C-0-1] DOIT prendre en charge les formats multimédias, les encodeurs, les décodeurs, les types de fichiers et les formats de conteneur définis dans la section 5.1 pour chaque codec déclaré par MediaCodecList.
  • [C-0-2] DOIT déclarer et signaler la prise en charge des encodeurs et des décodeurs disponibles pour les applications tierces via MediaCodecList.
  • [C-0-3] DOIT être en mesure de décoder et de mettre à la disposition des applications tierces tous les formats qu'il peut encoder. Cela inclut tous les flux de bits générés par ses encodeurs et les profils signalés dans son CamcorderProfile.

Implémentations de l'appareil:

  • DOIVENT viser une latence de codec minimale. En d'autres termes, ils doivent :
    • NE DOIT PAS consommer et stocker les tampons d'entrée, et ne doit les renvoyer qu'une fois traités.
    • NE DOIT PAS conserver les tampons décodés plus longtemps que spécifié par la norme (par exemple, SPS).
    • NE DOIT PAS conserver les tampons encodés plus longtemps que nécessaire par la structure GOP.

Tous les codecs listés dans la section ci-dessous sont fournis en tant qu'implémentations logicielles dans l'implémentation Android préférée du projet Android Open Source.

Veuillez noter que ni Google ni l'Open Handset Alliance ne font aucune déclaration selon laquelle ces codecs sont exempts de 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.

5.1. Codecs multimédias

5.1.1. Encodage audio

Pour en savoir plus, consultez la section 5.1.3. "Détails des codecs audio".

Si les implémentations d'appareils déclarent android.hardware.microphone, elles DOIVENT prendre en charge l'encodage audio suivant:

  • [C-1-1] PCM/WAVE

5.1.2. Décodage audio

Pour en savoir plus, consultez la section 5.1.3. "Détails des codecs audio".

Si les implémentations d'appareils déclarent la prise en charge de la fonctionnalité android.hardware.audio.output, elles doivent prendre en charge le décodage des formats audio suivants:

  • [C-1-1] Profil MPEG-4 AAC (AAC LC)
  • [C-1-2] Profil MPEG-4 HE AAC (AAC+)
  • [C-1-3] Profil MPEG-4 HE AACv2 (AAC+ amélioré)
  • [C-1-4] AAC ELD (AAC à faible latence amélioré)
  • [C-1-11] xHE-AAC (profil HE AAC étendu ISO/IEC 23003-3, qui inclut le profil de référence USAC et le profil de contrôle de la plage dynamique ISO/IEC 23003-4)
  • [C-1-5] FLAC
  • [C-1-6] MP3
  • [C-1-7] MIDI
  • [C-1-8] Vorbis
  • [C-1-9] PCM/WAVE
  • [C-1-10] Opus

Si les implémentations de l'appareil prennent en charge le décodage des tampons d'entrée AAC des flux multicanaux (c'est-à-dire plus de deux canaux) en PCM via le décodeur audio AAC par défaut de l'API android.media.MediaCodec, les éléments suivants DOIVENT être pris en charge:

  • [C-2-1] Le décodage DOIT être effectué sans downmix (par exemple, un flux AAC 5.0 doit être décodé en cinq canaux PCM, un flux AAC 5.1 doit être décodé en six canaux PCM).
  • [C-2-2] Les métadonnées de plage dynamique DOIVENT être conformes à la section "Contrôle de la plage dynamique (DRC)" de la norme ISO/CEI 14496-3, ainsi qu'aux clés DRC android.media.MediaFormat pour configurer les comportements liés à la plage dynamique du décodeur audio. Les clés AAC DRC ont été introduites dans l'API 21. Il s'agit de: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL et KEY_AAC_ENCODED_TARGET_LEVEL.

Lors du décodage de l'audio USAC, MPEG-D (ISO/IEC 23003-4):

  • [C-3-1] Les métadonnées de niveau sonore et de DRC DOIVENT être interprétées et appliquées conformément au profil de contrôle de la plage dynamique MPEG-D DRC de niveau 1.
  • [C-3-2] Le décodeur DOIT se comporter conformément à la configuration définie avec les clés android.media.MediaFormat suivantes: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL et KEY_AAC_DRC_EFFECT_TYPE.

Décodeurs de profil MPEG-4 AAC, HE AAC et HE AACv2:

  • PEUT être compatible avec le contrôle du volume et de la plage dynamique à l'aide du profil de contrôle de la plage dynamique ISO/CEI 23003-4.

Si la norme ISO/CEI 23003-4 est prise en charge et si les métadonnées ISO/CEI 23003-4 et ISO/CEI 14496-3 sont présentes dans un flux de bits décodé, alors:

  • Les métadonnées ISO/CEI 23003-4 doivent prévaloir.

5.1.3. Détails des codecs audio

Format/Codec Détails Types de fichiers/Formats de conteneurs compatibles
Profil MPEG-4 AAC
(AAC LC) 		Compatibilité avec les contenus mono/stéréo/5.0/5.1 avec des taux d'échantillonnage standards de 8 à 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
  • AAC brut ADTS (.aac, ADIF non compatible)
  • MPEG-TS (.ts, non accessible en lecture)
Profil MPEG-4 HE AAC (AAC+) Compatibilité avec les contenus mono/stéréo/5.0/5.1 avec des taux d'échantillonnage standards de 16 à 48 kHz.
Profil MPEG-4 HE AACv2
(AAC+ amélioré) 		Compatibilité avec les contenus mono/stéréo/5.0/5.1 avec des taux d'échantillonnage standards de 16 à 48 kHz.
AAC ELD (AAC à faible latence amélioré) Compatibilité avec le contenu mono/stéréo avec des taux d'échantillonnage standards de 16 à 48 kHz.
USAC Compatibilité avec les contenus mono/stéréo avec des taux d'échantillonnage standards compris entre 7,35 et 48 kHz. MPEG-4 (.mp4, .m4a)
AMR-NB 4,75 à 12,2 kbit/s échantillonnés à 8 kHz 3GPP (.3gp)
AMR-WB 9 débits de 6,60 kbit/s à 23,85 kbit/s échantillonnés à 16 kHz
FLAC Mono/Stéréo (pas de multicanaux) Taux d'échantillonnage jusqu'à 48 kHz (mais jusqu'à 44,1 kHz RECOMMANDÉ sur les appareils avec sortie 44,1 kHz, car le convertisseur 48 kHz vers 44,1 kHz n'inclut pas de filtre passe-bas). 16 bits RECOMMANDÉ ; aucun bruit de fond appliqué pour 24 bits. FLAC (.flac) uniquement
MP3 Mono/Stéréo 8-320 kbit/s constant (CBR) ou débit variable (VBR) MP3 (.mp3)
MIDI Types MIDI 0 et 1 Versions 1 et 2 de DLS XMF et Mobile XMF. Compatibilité avec les formats de sonnerie RTTTL/RTX, OTA et iMelody
  • Types 0 et 1 (.mid, .xmf, .mxmf)
  • RTTTL/RTX (.rtttl, .rtx)
  • OTA (.ota)
  • iMelody (.imy)
Vorbis
  • Ogg (.ogg)
  • Matroska (.mkv, Android 4.0 et versions ultérieures)
PCM/WAVE PCM linéaire 16 bits (débits jusqu'à la limite du matériel). Les appareils DOIVENT être compatibles avec les taux d'échantillonnage pour l'enregistrement PCM brut aux fréquences de 8 000, 11 025, 16 000 et 44 100 Hz. WAVE (.wav)
Opus Matroska (.mkv), Ogg(.ogg)

5.1.4. Encodage d'image

Pour en savoir plus, consultez la section 5.1.6. Codecs d'image.

Les implémentations d'appareils DOIVENT prendre en charge l'encodage des images suivantes:

  • [C-0-1] JPEG
  • [C-0-2] PNG
  • [C-0-3] WebP

5.1.5. Décodage d'image

Pour en savoir plus, consultez la section 5.1.6. Codecs d'image.

Les implémentations d'appareils DOIVENT prendre en charge le décodage de l'encodage d'image suivant:

  • [C-0-1] JPEG
  • [C-0-2] GIF
  • [C-0-3] PNG
  • [C-0-4] BMP
  • [C-0-5] WebP
  • [C-0-6] Brut
  • [C-0-7] HEIF (HEIC)

5.1.6. Détails des codecs d'image

Format/Codec Détails Types de fichiers/Formats de conteneurs compatibles
JPEG Base+progressive JPEG (.jpg)
GIF GIF (.gif)
PNG PNG (.png)
BMP BMP (.bmp)
WebP WebP (.webp)
Brute ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF Image, collection d'images, séquence d'images HEIF (.heif), HEIC (.heic)

5.1.7. Codecs vidéo

  • Pour une qualité acceptable du streaming vidéo Web et des services de visioconférence, les implémentations d'appareils DOIVENT utiliser un codec VP8 matériel qui répond aux exigences.

Si les implémentations de l'appareil incluent un décodeur ou un encodeur vidéo:

  • [C-1-1] Les codecs vidéo DOIVENT prendre en charge des tailles de tampon d'octets de sortie et d'entrée adaptées au plus grand frame compressé et non compressé possible, comme dicté par la norme et la configuration, mais aussi ne pas surallouer.

  • [C-1-2] Les encodeurs et décodeurs vidéo DOIVENT prendre en charge le format de couleur flexible YUV420 (COLOR_FormatYUV420Flexible).

Si les implémentations d'appareils annoncent la compatibilité avec le profil HDR via Display.HdrCapabilities, elles:

  • [C-2-1] DOIT être compatible avec l'analyse et la gestion des métadonnées statiques HDR.

Si les implémentations d'appareils annoncent la prise en charge de l'actualisation intra via FEATURE_IntraRefresh dans la classe MediaCodecInfo.CodecCapabilities, elles:

  • [C-3-1] DOIT prendre en charge les périodes d'actualisation comprises entre 10 et 60 images et fonctionner avec une précision de 20% de la période d'actualisation configurée.

5.1.8. Liste des codecs vidéo

Format/Codec Détails Types de fichiers/
Formats de conteneurs compatibles
H.263
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
H.264 AVC Pour en savoir plus, consultez les sections 5.2 et 5.3.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • MPEG-2 TS (.ts, audio AAC uniquement, non accessible par recherche, Android 3.0 ou version ultérieure)
H.265 HEVC Pour en savoir plus, consultez la section 5.3. MPEG-4 (.mp4)
MPEG-2 Main Profile MPEG2-TS
MPEG-4 SP 3GPP (.3gp)
VP8 Pour en savoir plus, consultez les sections 5.2 et 5.3.
VP9 Pour en savoir plus, consultez la section 5.3.

5.2. Encodage vidéo

Si les implémentations d'appareils sont compatibles avec un encodeur vidéo et le rendent disponible pour les applications tierces, elles:

  • NE DOIT PAS dépasser ~15% du débit entre les intervalles d'intraframe (I-frame) sur deux fenêtres glissantes.
  • NE DOIT PAS dépasser ~100% du débit sur une fenêtre glissante de 1 seconde.

Si les implémentations d'appareils incluent un écran intégré dont la diagonale mesure au moins 6,3 cm, ou incluent un port de sortie vidéo, ou déclarent la prise en charge d'une caméra via le flag de fonctionnalité android.hardware.camera.any, elles:

  • [C-1-1] DOIT prendre en charge au moins l'un des encodeurs vidéo VP8 ou H.264, et le rendre disponible pour les applications tierces.
  • DOIT être compatible avec les encodeurs vidéo VP8 et H.264, et les mettre à la disposition des applications tierces.

Si les implémentations de l'appareil sont compatibles avec l'un des encodeurs vidéo H.264, VP8, VP9 ou HEVC et les mettent à la disposition des applications tierces, elles:

  • [C-2-1] DOIT prendre en charge les débits configurables dynamiquement.
  • DOIT prendre en charge les fréquences d'images variables, où l'encodeur vidéo DOIT déterminer la durée instantanée des images en fonction des codes temporels des tampons d'entrée et allouer son bucket de bits en fonction de cette durée.

Si les implémentations d'appareils sont compatibles avec l'encodeur vidéo MPEG-4 SP et le rendent disponible pour les applications tierces, elles:

  • DOIT prendre en charge les débits configurables de manière dynamique pour l'encodeur compatible.

5.2.1. H.263

Si les implémentations d'appareils sont compatibles avec les encodeurs H.263 et les mettent à la disposition des applications tierces, elles:

  • [C-1-1] DOIT être compatible avec le niveau de profil de référence 45.
  • DOIT prendre en charge les débits configurables de manière dynamique pour l'encodeur compatible.

5.2.2. H-264

Si les implémentations de l'appareil sont compatibles avec le codec H.264, elles:

  • [C-1-1] DOIT prendre en charge le profil de référence de niveau 3. Toutefois, la prise en charge de l'ordre des tranches arbitraire (ASO, Arbitrary Slice Ordering), de l'ordre des macroblocs flexible (FMO, Flexible Macroblock Ordering) et des tranches redondantes (RS, Redundant Slices) est FACULTATIVE. De plus, pour assurer la compatibilité avec d'autres appareils Android, il est RECOMMANDÉ que les encodeurs n'utilisent pas ASO, FMO et RS pour le profil de référence.
  • [C-1-2] DOIT prendre en charge les profils d'encodage vidéo SD (définition standard) du tableau suivant.
  • DOIT prendre en charge le profil principal de niveau 4.
  • DOIT prendre en charge les profils d'encodage vidéo HD (haute définition) indiqués dans le tableau suivant.

Si les implémentations d'appareils signalent la prise en charge de l'encodage H.264 pour les vidéos en résolution 720p ou 1080p via les API multimédias, elles:

  • [C-2-1] DOIT prendre en charge les profils d'encodage du tableau suivant.
SD (basse qualité) SD (haute qualité) HD – 720p HD – 1080p
Résolution vidéo 320 x 240 px 720 x 480 px 1 280 x 720 px 1 920 x 1 080 px
Fréquence d'images de la vidéo 20 fps 30 ips 30 ips 30 ips
Débit vidéo 384 kbit/s 2 Mbit/s 4 Mbit/s 10 Mbit/s

5.2.3. VP8

Si les implémentations de l'appareil sont compatibles avec le codec VP8, elles:

  • [C-1-1] DOIT prendre en charge les profils d'encodage vidéo SD.
  • DOIT prendre en charge les profils d'encodage vidéo HD (haute définition) suivants.
  • DOIT être compatible avec l'écriture de fichiers WebM Matroska.
  • DOIT utiliser un codec VP8 matériel conforme aux exigences de codage matériel RTC du projet WebM pour garantir une qualité acceptable des services de streaming vidéo et de visioconférence sur le Web.

Si les implémentations d'appareils indiquent la prise en charge de l'encodage VP8 pour les vidéos en résolution 720p ou 1080p via les API multimédias, elles:

  • [C-2-1] DOIT prendre en charge les profils d'encodage du tableau suivant.
SD (basse qualité) SD (haute qualité) HD – 720p HD – 1080p
Résolution vidéo 320 x 180 px 640 x 360 px 1 280 x 720 px 1 920 x 1 080 px
Fréquence d'images de la vidéo 30 ips 30 ips 30 ips 30 ips
Débit vidéo 800 Kbit/s 2 Mbit/s 4 Mbit/s 10 Mbit/s

5.2.4. VP9

Si les implémentations de l'appareil sont compatibles avec le codec VP9, elles:

  • DOIT être compatible avec l'écriture de fichiers WebM Matroska.

5.3. Décodage vidéo

Si les implémentations de l'appareil sont compatibles avec les codecs VP8, VP9, H.264 ou H.265, elles:

  • [C-1-1] DOIT prendre en charge la résolution vidéo dynamique et le changement de fréquence d'images via les API Android standards dans le même flux pour tous les codecs VP8, VP9, H.264 et H.265 en temps réel et jusqu'à la résolution maximale prise en charge par chaque codec sur l'appareil.

Si les implémentations d'appareils déclarent la prise en charge du décodeur Dolby Vision via HDR_TYPE_DOLBY_VISION , elles:

  • [C-2-1] DOIT fournir un extracteur compatible avec Dolby Vision.
  • [C-2-2] DOIT afficher correctement le contenu Dolby Vision sur l'écran de l'appareil ou sur un port de sortie vidéo standard (par exemple, (HDMI, par exemple).
  • [C-2-3] L'indice de piste de la ou des couches de base rétrocompatibles (le cas échéant) DOIT être identique à celui de la couche Dolby Vision combinée.

5.3.1. MPEG-2

Si les implémentations d'appareils sont compatibles avec les décodeurs MPEG-2, elles:

  • [C-1-1] DOIT prendre en charge le profil principal de niveau élevé.

5.3.2. H.263

Si les implémentations d'appareils sont compatibles avec les décodeurs H.263, elles:

  • [C-1-1] DOIT être compatible avec les profils de référence de niveau 30 et de niveau 45.

5.3.3. MPEG-4

Si les implémentations d'appareils sont équipées de décodeurs MPEG-4:

  • [C-1-1] DOIT être compatible avec le profil simple de niveau 3.

5.3.4. H.264

Si les implémentations d'appareils sont compatibles avec les décodeurs H.264, elles:

  • [C-1-1] DOIT prendre en charge le profil principal de niveau 3.1 et le profil de référence. La prise en charge de l'ordre des tranches arbitraire (ASO, Arbitrary Slice Ordering), de l'ordre des macroblocs flexible (FMO, Flexible Macroblock Ordering) et des tranches redondantes (RS, Redundant Slices) est FACULTATIVE.
  • [C-1-2] DOIT être capable de décoder les vidéos avec les profils SD (Standard Definition) listés dans le tableau suivant et encodés avec le profil de référence et le profil principal de niveau 3.1 (y compris 720p30).
  • DOIT être en mesure de décoder les vidéos avec les profils HD (haute définition) indiqués dans le tableau suivant.

Si la hauteur indiquée par la méthode Display.getSupportedModes() est égale ou supérieure à la résolution vidéo, les implémentations de l'appareil:

  • [C-2-1] DOIT prendre en charge les profils de décodage vidéo HD 720p indiqués dans le tableau suivant.
  • [C-2-2] DOIT prendre en charge les profils de décodage vidéo HD 1080p indiqués dans le tableau suivant.
SD (basse qualité) SD (haute qualité) HD – 720p HD – 1080p
Résolution vidéo 320 x 240 px 720 x 480 px 1 280 x 720 px 1 920 x 1 080 px
Fréquence d'images de la vidéo 30 ips 30 ips 60 FPS 30 FPS (60 FPS pour la télévision)
Débit vidéo 800 Kbit/s 2 Mbit/s 8 Mbit/s 20 Mbit/s

5.3.5. H.265 (HEVC)

Si les implémentations de l'appareil sont compatibles avec le codec H.265, elles:

  • [C-1-1] DOIT prendre en charge le niveau 3 du profil principal et les profils de décodage vidéo SD, comme indiqué dans le tableau suivant.
  • DOIT prendre en charge les profils de décodage HD indiqués dans le tableau suivant.
  • [C-1-2] DOIT être compatible avec les profils de décodage HD indiqués dans le tableau suivant en cas de présence d'un décodeur matériel.

Si la hauteur indiquée par la méthode Display.getSupportedModes() est égale ou supérieure à la résolution vidéo, procédez comme suit:

  • [C-2-1] Les implémentations d'appareils DOIVENT prendre en charge au moins l'un des formats de décodage H.265 ou VP9 des profils 720p, 1080p et UHD.
SD (basse qualité) SD (haute qualité) HD – 720p HD – 1080p UHD
Résolution vidéo 352 x 288 px 720 x 480 px 1 280 x 720 px 1 920 x 1 080 px 3 840 x 2 160 px
Fréquence d'images de la vidéo 30 ips 30 ips 30 ips 30/60 FPS (60 FPS pour les téléviseurs avec décodage matériel H.265) 60 FPS
Débit vidéo 600 Kbits/s 1,6 Mbit/s 4 Mbit/s 5 Mbit/s 20 Mbit/s

5.3.6. VP8

Si les implémentations de l'appareil sont compatibles avec le codec VP8, elles:

  • [C-1-1] DOIT prendre en charge les profils de décodage SD du tableau suivant.
  • DOIT utiliser un codec VP8 matériel qui répond aux exigences.
  • DOIT prendre en charge les profils de décodage HD du tableau suivant.

Si la hauteur indiquée par la méthode Display.getSupportedModes() est égale ou supérieure à la résolution vidéo, procédez comme suit:

  • [C-2-1] Les implémentations d'appareils DOIVENT prendre en charge les profils 720p du tableau suivant.
  • [C-2-2] Les implémentations d'appareils DOIVENT prendre en charge les profils 1080p du tableau suivant.
SD (basse qualité) SD (haute qualité) HD – 720p HD – 1080p
Résolution vidéo 320 x 180 px 640 x 360 px 1 280 x 720 px 1 920 x 1 080 px
Fréquence d'images de la vidéo 30 ips 30 ips 30 FPS (60 FPS pour la télévision) 30 (60 images par secondeTélévision)
Débit vidéo 800 Kbit/s 2 Mbit/s 8 Mbit/s 20 Mbit/s

5.3.7. VP9

Si les implémentations de l'appareil sont compatibles avec le codec VP9, elles:

  • [C-1-1] DOIT prendre en charge les profils de décodage vidéo SD indiqués dans le tableau suivant.
  • DOIT prendre en charge les profils de décodage HD indiqués dans le tableau suivant.

Si les implémentations de l'appareil sont compatibles avec le codec VP9 et un décodeur matériel:

  • [C-2-1] DOIT prendre en charge les profils de décodage HD indiqués dans le tableau suivant.

Si la hauteur indiquée par la méthode Display.getSupportedModes() est égale ou supérieure à la résolution vidéo, procédez comme suit:

  • [C-3-1] Les implémentations d'appareils DOIVENT prendre en charge au moins l'un des formats de décodage VP9 ou H.265 des profils 720p, 1080p et UHD.
SD (basse qualité) SD (haute qualité) HD – 720p HD – 1080p UHD
Résolution vidéo 320 x 180 px 640 x 360 px 1 280 x 720 px 1 920 x 1 080 px 3 840 x 2 160 px
Fréquence d'images de la vidéo 30 ips 30 ips 30 ips 30 FPS (60 FPS sur les téléviseurs avec décodage matériel du format VP9) 60 FPS
Débit vidéo 600 Kbits/s 1,6 Mbit/s 4 Mbit/s 5 Mbit/s 20 Mbit/s

5.4. Enregistrement audio

Bien que certaines des exigences décrites dans cette section soient listées comme "RECOMMANDÉ" depuis Android 4.3, la définition de la compatibilité pour les futures versions prévoit de les remplacer par "OBLIGATOIRE". Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux respectent ces exigences listées comme "DOIT", sinon ils ne pourront pas être compatibles avec Android lors de la mise à niveau vers la future version.

5.4.1. Capture audio RAW

Si les implémentations d'appareils déclarent android.hardware.microphone, elles:

  • [C-1-1] DOIT permettre la capture de contenu audio brut avec les caractéristiques suivantes:

    • Format: PCM linéaire, 16 bits
    • Taux d'échantillonnage: 8 000, 11 025, 16 000 et 44 100 Hz
    • Canaux: mono

  • [C-1-2] DOIT capturer à des taux d'échantillonnage supérieurs sans mise à l'échelle.

  • [C-1-3] DOIT inclure un filtre anticrénelage approprié lorsque les taux d'échantillonnage indiqués ci-dessus sont capturés avec un sous-échantillonnage.

  • DOIT permettre la capture de contenu audio brut en qualité radio AM et DVD, ce qui implique les caractéristiques suivantes:

    • Format: PCM linéaire, 16 bits
    • Taux d'échantillonnage: 22 050, 48 000 Hz
    • Canaux: stéréo

Si les implémentations d'appareils permettent de capturer des contenus audio bruts en qualité radio AM et DVD, elles:

  • [C-2-1] L'appareil doit enregistrer sans mise à l'échelle à un format supérieur à 16 000:22 050 ou 44 100:48 000.
  • [C-2-2] DOIT inclure un filtre anticrénelage approprié pour tout suréchantillonnage ou sous-échantillonnage.

5.4.2. Enregistrer pour la reconnaissance vocale

Si les implémentations d'appareils déclarent android.hardware.microphone, elles:

  • [C-1-1] DOIT capturer la source audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION à l'un des taux d'échantillonnage, 44 100 ou 48 000.
  • [C-1-2] DOIT, par défaut, désactiver tout traitement audio de réduction du bruit lors de l'enregistrement d'un flux audio à partir de la source audio AudioSource.VOICE_RECOGNITION.
  • [C-1-3] DOIT, par défaut, désactiver toute commande de gain automatique lors de l'enregistrement d'un flux audio à partir de la source audio AudioSource.VOICE_RECOGNITION.
  • DOIT enregistrer le flux audio de reconnaissance vocale avec des caractéristiques d'amplitude à fréquence plate, à savoir ±3 dB, de 100 Hz à 4 000 Hz.
  • DOIT enregistrer le flux audio de reconnaissance vocale avec une sensibilité d'entrée définie de sorte qu'une source de niveau de puissance acoustique (SPL) de 90 dB à 1 000 Hz génère une valeur efficace de 2 500 pour les échantillons 16 bits.
  • DOIT enregistrer le flux audio de reconnaissance vocale de sorte que les niveaux d'amplitude PCM suivent de manière linéaire les variations du niveau de pression acoustique d'entrée sur une plage d'au moins 30 dB, allant de -18 dB à +12 dB par rapport à 90 dB SPL au niveau du micro.
  • DOIT enregistrer le flux audio de reconnaissance vocale avec un taux de distorsion harmonique totale (THD) inférieur à 1% pour 1 kHz à un niveau d'entrée de 90 dB SPL au niveau du micro.

Si les implémentations d'appareils déclarent des technologies android.hardware.microphone et de suppression (réduction) du bruit optimisées pour la reconnaissance vocale, elles:

  • [C-2-1] DOIT permettre de contrôler cet effet audio avec l'API android.media.audiofx.NoiseSuppressor.
  • [C-2-2] Chaque implémentation de technologie de suppression du bruit doit être identifiée de manière unique via le champ AudioEffect.Descriptor.uuid.

5.4.3. Capture pour le redirignement de la lecture

La classe android.media.MediaRecorder.AudioSource inclut la source audio REMOTE_SUBMIX.

Si les implémentations d'appareils déclarent à la fois android.hardware.audio.output et android.hardware.microphone, elles:

  • [C-1-1] DOIT implémenter correctement la source audio REMOTE_SUBMIX afin que, lorsqu'une application utilise l'API android.media.AudioRecord pour enregistrer à partir de cette source audio, elle capture un mix de tous les flux audio, à l'exception des éléments suivants:

    • AudioManager.STREAM_RING
    • AudioManager.STREAM_ALARM
    • AudioManager.STREAM_NOTIFICATION

5.5. Lecture audio

Android permet aux applications de lire de l'audio via le périphérique de sortie audio, comme défini dans la section 7.8.2.

5.5.1. Lecture audio brute

Si les implémentations d'appareils déclarent android.hardware.audio.output, elles:

  • [C-1-1] DOIT permettre la lecture de contenu audio brut présentant les caractéristiques suivantes:

    • Format: PCM linéaire, 16 bits, 8 bits, flottant
    • Canaux: mono, stéréo, configurations multicanaux valides avec jusqu'à huit canaux
    • Taux d'échantillonnage (en Hz) :
      • 8 000, 11 025, 16 000, 22 050, 32 000, 44 100 et 48 000 pour les configurations de canaux listées ci-dessus
      • 96 000 Hz en mono et stéréo

  • DOIT autoriser la lecture de contenu audio brut avec les caractéristiques suivantes:

    • Taux d'échantillonnage: 24 000, 48 000

5.5.2. Effets audio

Android fournit une API pour les effets audio pour les implémentations d'appareils.

Si les implémentations d'appareil déclarent la fonctionnalité android.hardware.audio.output, elles:

  • [C-1-1] DOIT prendre en charge les implémentations EFFECT_TYPE_EQUALIZER et EFFECT_TYPE_LOUDNESS_ENHANCER contrôlables via les sous-classes AudioEffect Equalizer, LoudnessEnhancer.
  • [C-1-2] DOIT prendre en charge l'implémentation de l'API Visualizer, qui peut être contrôlée via la classe Visualizer.
  • [C-1-3] DOIT prendre en charge l'implémentation EFFECT_TYPE_DYNAMICS_PROCESSING contrôlable via la sous-classe AudioEffect DynamicsProcessing.
  • DOIT prendre en charge les implémentations EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB et EFFECT_TYPE_VIRTUALIZER contrôlables via les sous-classes BassBoost, EnvironmentalReverb, PresetReverb et Virtualizer de AudioEffect.

5.5.3. Volume de sortie audio

Implémentations d'appareils automobiles:

  • DOIT permettre d'ajuster le volume audio séparément pour chaque flux audio à l'aide du type de contenu ou de l'utilisation définis par AudioAttributes et de l'utilisation de l'audio de la voiture telle que définie publiquement dans android.car.CarAudioManager.

5.6. Latence audio

La latence audio correspond au délai de transmission d'un signal audio dans un système. De nombreuses classes d'applications s'appuient sur des latences courtes pour obtenir des effets sonores en temps réel.

Aux fins de cette section, utilisez les définitions suivantes:

  • latence de sortie ; Intervalle entre le moment où une application écrit un frame de données encodé en PCM et le moment où le son correspondant est présenté à l'environnement via un transducteur sur l'appareil ou qu'un signal quitte l'appareil via un port et peut être observé en externe.
  • Latence de sortie à froid Latence de sortie pour le premier frame, lorsque le système de sortie audio était inactif et éteint avant la requête.
  • latence de sortie continue. La latence de sortie pour les frames suivants, une fois que l'appareil lit de l'audio.
  • latence d'entrée ; Intervalle entre le moment où un son est présenté par l'environnement à l'appareil via un transducteur ou un signal qui y entre via un port, et le moment où une application lit le frame correspondant de données codées PCM.
  • perte d'entrée. Portion initiale d'un signal d'entrée inutilisable ou indisponible.
  • Latence d'entrée à froid Somme du temps d'entrée perdu et de la latence d'entrée pour le premier frame, lorsque le système d'entrée audio était inactif et éteint avant la requête.
  • latence d'entrée continue ; Latence d'entrée pour les images suivantes lorsque l'appareil capture l'audio.
  • jitter de sortie à froid. Variabilité entre les mesures distinctes des valeurs de latence de sortie à froid.
  • jitter d'entrée à froid. Variabilité entre les mesures distinctes des valeurs de latence d'entrée à froid.
  • latence aller-retour continue ; Somme de la latence d'entrée continue, de la latence de sortie continue et d'une période de tampon. La période de tampon permet à l'application de traiter le signal et de réduire la différence de phase entre les flux d'entrée et de sortie.
  • API de file d'attente de tampon PCM OpenSL ES Ensemble des API OpenSL ES liées au PCM dans le NDK Android.
  • API audio native AAudio Ensemble des API AAudio du NDK Android.
  • Code temporel. Paire composée d'une position de frame relative dans un flux et de l'heure estimée à laquelle ce frame entre ou quitte le pipeline de traitement audio sur le point de terminaison associé. Consultez également AudioTimestamp.

Si les implémentations d'appareils déclarent android.hardware.audio.output, il est FORTEMENT RECOMMANDÉ de respecter les exigences suivantes ou de les dépasser:

  • [C-SR] Latence de sortie à froid de 100 ms ou moins
  • [C-SR] Latence de sortie continue de 45 millisecondes ou moins
  • [C-SR] Minimiser le jitter de sortie à froid
  • [C-SR] Le code temporel de sortie renvoyé par AudioTrack.getTimestamp et AAudioStream_getTimestamp est précis à +/- 1 ms.

Si les implémentations de l'appareil répondent aux exigences ci-dessus, après tout calibrage initial, lorsque vous utilisez à la fois la file d'attente de tampon PCM OpenSL ES et les API audio natives AAudio, pour la latence de sortie continue et la latence de sortie à froid sur au moins un appareil de sortie audio compatible, elles sont les suivantes:

Si les implémentations d'appareils ne répondent pas aux exigences d'audio à faible latence via la file d'attente de tampon PCM OpenSL ES et les API audio natives AAudio, elles:

  • [C-1-1] NE DOIT PAS signaler la prise en charge de l'audio à faible latence.

Si les implémentations d'appareils incluent android.hardware.microphone, il est FORTEMENT RECOMMANDÉ de respecter ces exigences concernant l'entrée audio:

  • [C-SR] Latence d'entrée à froid de 100 ms ou moins.
  • [C-SR] Latence d'entrée continue de 30 millisecondes ou moins.
  • [C-SR] Latence aller-retour continue de 50 ms ou moins.
  • [C-SR] Minimisez le jitter d'entrée à froid.
  • [C-SR] Limitez l'erreur dans les codes temporels d'entrée, tels que renvoyés par AudioRecord.getTimestamp ou AAudioStream_getTimestamp, à +/- 1 ms.

5.7. Protocoles de réseau

Les implémentations d'appareils DOIVENT être compatibles avec les protocoles de réseau multimédia pour la lecture audio et vidéo, comme indiqué dans la documentation du SDK Android.

Si les implémentations de l'appareil incluent un décodeur audio ou vidéo, elles:

  • [C-1-1] DOIT prendre en charge tous les codecs et formats de conteneur requis de la section 5.1 via HTTP(S).

  • [C-1-2] DOIT être compatible avec les formats de segments multimédias indiqués dans le tableau "Formats de segments multimédias" ci-dessous sur le protocole de streaming HLS, version 7.

  • [C-1-3] DOIT prendre en charge le profil audio/vidéo RTP et les codecs associés suivants dans le tableau RTSP ci-dessous. Pour connaître les exceptions, veuillez consulter les notes de bas de page du tableau de la section 5.1.

Formats de segments multimédias

Formats de segments Référence(s) Compatibilité avec les codecs requise
MPEG-2 Transport Stream ISO 13818 Codecs vidéo :
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
Pour en savoir plus sur les formats H.264 AVC, MPEG-2-4 SP et MPEG-2,consultez la section 5.1.3.

Codecs audio:

  • AAC
Pour en savoir plus sur l'AAC et ses variantes, consultez la section 5.1.1.
AAC avec cadrage ADTS et tags ID3 ISO 13818-7 Pour en savoir plus sur l'AAC et ses variantes, consultez la section 5.1.1.
WebVTT WebVTT

RTSP (RTP, SDP)

Nom du profil Référence(s) Compatibilité avec les codecs requise
H264 AVC RFC 6184 Pour en savoir plus sur le format H264 AVC, consultez la section 5.1.3.
MP4A-LATM RFC 6416 Pour en savoir plus sur l'AAC et ses variantes, consultez la section 5.1.1.
H263-1998 RFC 3551
RFC 4629
RFC 2190 		Pour en savoir plus sur le format H.263, consultez la section 5.1.3.
H263-2000 RFC 4629 Pour en savoir plus sur le format H.263, consultez la section 5.1.3.
AMR RFC 4867 Pour en savoir plus sur AMR-NB, consultez la section 5.1.1.
AMR-WB RFC 4867 Pour en savoir plus sur AMR-WB, consultez la section 5.1.1.
MP4V-ES RFC 6416 Pour en savoir plus sur le format MPEG-4 SP, consultez la section 5.1.3.
mpeg4-generic RFC 3640 Pour en savoir plus sur l'AAC et ses variantes, consultez la section 5.1.1.
MP2T RFC 2250 Pour en savoir plus, consultez la section MPEG-2 Transport Stream sous HTTP Live Streaming.

5.8. Secure Media

Si les implémentations d'appareils sont compatibles avec la sortie vidéo sécurisée et les surfaces sécurisées, elles:

  • [C-1-1] DOIT déclarer la prise en charge de Display.FLAG_SECURE.

Si les implémentations d'appareils déclarent être compatibles avec Display.FLAG_SECURE et le protocole d'affichage sans fil, elles:

  • [C-2-1] DOIT sécuriser la liaison avec un mécanisme cryptographique puissant tel que HDCP 2.x ou version ultérieure pour les écrans connectés via des protocoles sans fil tels que Miracast.

Si les implémentations d'appareils déclarent être compatibles avec Display.FLAG_SECURE et avec un écran externe filaire, elles:

  • [C-3-1] DOIT être compatible avec HDCP 1.2 ou version ultérieure pour tous les écrans externes connectés via un port filaire accessible à l'utilisateur.

5.9. MIDI (Musical Instrument Digital Interface)

Si les implémentations d'appareils signalent la prise en charge de la fonctionnalité android.software.midi via la classe android.content.pm.PackageManager, elles:

  • [C-1-1] DOIT prendre en charge le MIDI sur tous les transports matériels compatibles avec le MIDI pour lesquels ils fournissent une connectivité générique non MIDI, où ces transports sont:

  • [C-1-2] DOIT prendre en charge le transport logiciel MIDI inter-application (appareils MIDI virtuels)

5.10. Audio professionnel

Si les implémentations de l'appareil signalent la prise en charge de la fonctionnalité android.hardware.audio.pro via la classe android.content.pm.PackageManager, elles:

  • [C-1-1] DOIT indiquer la prise en charge de la fonctionnalité android.hardware.audio.low_latency.
  • [C-1-2] La latence audio aller-retour continue, telle que définie dans la section 5.6 Latence audio, DOIT être de 20 ms ou moins et DEVRAIT être de 10 ms ou moins sur au moins un chemin pris en charge.
  • [C-1-3] DOIT inclure un ou plusieurs ports USB compatibles avec le mode hôte USB et le mode périphérique USB.
  • [C-1-4] DOIT indiquer la prise en charge de la fonctionnalité android.software.midi.
  • [C-1-5] DOIT respecter les latences et les exigences audio USB à l'aide de la file d'attente de tampon PCM OpenSL ES et des API audio natives AAudio.
  • [SR] FORTEMENT RECOMMANDÉ pour fournir un niveau de performances de processeur cohérent lorsque l'audio est actif et que la charge du processeur varie. Cela doit être testé à l'aide du commit 1bd6391 de SimpleSynth. L'application SimpleSynth doit être exécutée avec les paramètres ci-dessous et ne générer aucun sous-dépassement au bout de 10 minutes :
    • Cycles de travail: 200 000
    • Charge variable: ACTIVÉE (la valeur des cycles de travail passe entre 100% et 10% toutes les deux secondes. Cette option est conçue pour tester le comportement du gouverneur de processeur.)
    • Charge stabilisée: OFF
  • DOIT minimiser l'imprécision et la dérive de l'horloge audio par rapport à l'heure normale.
  • DOIT minimiser la dérive de l'horloge audio par rapport à l'CLOCK_MONOTONIC du processeur lorsque les deux sont actifs.
  • DOIT minimiser la latence audio sur les transducteurs de l'appareil.
  • DOIT réduire la latence audio via l'audio numérique USB.
  • DOIT documenter les mesures de la latence audio sur tous les chemins.
  • DOIT réduire le jitter dans les temps d'entrée du rappel de finalisation du tampon audio, car cela affecte le pourcentage utilisable de la bande passante du processeur par le rappel.
  • DOIT fournir zéro sous-dépassement audio (sortie) ou dépassement audio (entrée) en utilisation normale avec la latence indiquée.
  • DOIT fournir une différence de latence intercanal nulle.
  • DOIT réduire la latence moyenne MIDI sur tous les transports.
  • DOIT minimiser la variabilité de la latence MIDI sous charge (jitter) sur tous les transports.
  • DOIT fournir des codes temporels MIDI précis sur tous les transports.
  • DOIT réduire le bruit du signal audio sur les transducteurs de l'appareil, y compris la période immédiatement après le démarrage à froid.
  • DOIT fournir une différence de horloge audio nulle entre les côtés d'entrée et de sortie des points de terminaison correspondants, lorsque les deux sont actifs. Le micro et le haut-parleur intégrés à l'appareil, ou l'entrée et la sortie du connecteur audio sont des exemples de points de terminaison correspondants.
  • DOIT gérer les rappels d'achèvement du tampon audio pour les côtés d'entrée et de sortie des points de terminaison correspondants sur le même thread lorsque les deux sont actifs, et entrer dans le rappel de sortie immédiatement après le retour du rappel d'entrée. Si vous ne pouvez pas gérer les rappels sur le même thread, saisissez le rappel de sortie peu de temps après le rappel d'entrée pour permettre à l'application de définir un timing cohérent entre les côtés d'entrée et de sortie.
  • DOIT minimiser la différence de phase entre la mise en mémoire tampon audio HAL pour les côtés d'entrée et de sortie des points de terminaison correspondants.
  • DOIT réduire la latence tactile.
  • DOIT minimiser la variabilité de la latence tactile sous charge (jitter).
  • La latence entre l'entrée tactile et la sortie audio doit être inférieure ou égale à 40 ms.

Si les implémentations de l'appareil répondent à toutes les exigences ci-dessus, elles:

  • [SR] Nous vous recommandons vivement de signaler la prise en charge de la fonctionnalité android.hardware.audio.pro via la classe android.content.pm.PackageManager.

Si les implémentations d'appareils incluent un connecteur audio 3,5 mm à quatre conducteurs, elles:

Si les implémentations d'appareils omettent une prise audio 3,5 mm à quatre conducteurs et incluent un ou plusieurs ports USB compatibles avec le mode hôte USB, elles:

  • [C-3-1] DOIT implémenter la classe audio USB.
  • [C-3-2] La latence audio aller-retour continue doit être de 20 millisecondes ou moins sur le port en mode hôte USB à l'aide de la classe audio USB.
  • La latence audio aller-retour continue DOIT être de 10 millisecondes ou moins sur le port en mode hôte USB à l'aide de la classe audio USB.

Si les implémentations d'appareils incluent un port HDMI, elles:

  • [C-4-1] DOIT prendre en charge la sortie en stéréo et en huit canaux à une profondeur de 20 bits ou 24 bits et 192 kHz, sans perte de profondeur de bits ni reéchantillonnage, dans au moins une configuration.

5.11. Capturer pour Unprocessed

Android est compatible avec l'enregistrement d'audio non traité via la source audio android.media.MediaRecorder.AudioSource.UNPROCESSED. Dans OpenSL ES, vous pouvez y accéder avec le préréglage d'enregistrement SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Si les implémentations d'appareils visent à prendre en charge la source audio non traitée et à la mettre à la disposition des applications tierces, elles:

  • [C-1-1] DOIT indiquer la prise en charge via la propriété android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

  • [C-1-2] DOIT présenter des caractéristiques d'amplitude par rapport à la fréquence à peu près plates dans la plage de fréquences moyennes: plus précisément ±10 dB de 100 Hz à 7 000 Hz pour chaque micro utilisé pour enregistrer la source audio non traitée.

  • [C-1-3] DOIT présenter des niveaux d'amplitude dans la plage de fréquences basses: plus précisément, de ±20 dB entre 5 Hz et 100 Hz par rapport à la plage de fréquences moyennes pour chaque micro utilisé pour enregistrer la source audio non traitée.

  • [C-1-4] DOIT présenter des niveaux d'amplitude dans la plage de fréquences hautes: plus précisément, de ±30 dB de 7 000 Hz à 22 kHz par rapport à la plage de fréquences moyennes pour chaque micro utilisé pour enregistrer la source audio non traitée.

  • [C-1-5] DOIT définir la sensibilité d'entrée audio de sorte qu'une source de tonalité sinusoïdale de 1 000 Hz lue à un niveau de pression acoustique (SPL) de 94 dB génère une réponse avec une RMS de 520 dB pour les échantillons 16 bits (ou -36 dB à pleine échelle pour les échantillons à virgule flottante/double précision) pour chaque micro utilisé pour enregistrer la source audio non traitée.

  • [C-1-6] Le rapport signal/bruit (SNR) doit être d'au moins 60 dB pour chaque micro utilisé pour enregistrer la source audio non traitée. (alors que le rapport signal/bruit est mesuré comme la différence entre 94 dB SPL et le niveau de pression acoustique équivalent du bruit propre, pondéré A).

  • [C-1-7] Le taux de distorsion harmonique totale (THD) doit être inférieur à 1% pour 1 kHz à un niveau d'entrée de 90 dB SPL pour chaque micro utilisé pour enregistrer la source audio non traitée.

  • Le chemin ne doit comporter aucun autre traitement du signal (par exemple, contrôle automatique du gain, filtre passe-haut ou suppression de l'écho) que le multiplicateur de niveau pour ajuster le niveau à la plage souhaitée. Autrement dit :

  • [C-1-8] Si un traitement du signal est présent dans l'architecture pour une raison quelconque, il DOIT être désactivé et ne doit pas entraîner de retard ni de latence supplémentaire dans le chemin du signal.
  • [C-1-9] Le multiplicateur de niveau, bien qu'il soit autorisé sur le chemin, NE DOIT PAS entraîner de retard ni de latence sur le chemin du signal.

Toutes les mesures de niveau de pression acoustique sont effectuées directement à côté du micro testé. Pour les configurations multimicro, ces exigences s'appliquent à chaque micro.

Si les implémentations d'appareils déclarent android.hardware.microphone, mais ne sont pas compatibles avec la source audio non traitée, elles:

  • [C-2-1] DOIT renvoyer null pour la méthode d'API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED), afin d'indiquer correctement l'absence de prise en charge.
  • [SR] Il est toujours FORTEMENT RECOMMANDÉ de respecter autant que possible les exigences concernant le chemin du signal pour la source d'enregistrement non traitée.

6. Compatibilité des outils et options pour les développeurs

6.1. Outils pour les développeurs

Implémentations de l'appareil:

  • [C-0-1] DOIT être compatible avec les outils de développement Android fournis dans le SDK Android.

  • Android Debug Bridge (adb)

    • [C-0-2] DOIT prendre en charge adb, comme indiqué dans le SDK Android et les commandes shell fournies dans l'AOSP, qui peuvent être utilisées par les développeurs d'applications, y compris dumpsys et cmd stats.
    • [C-0-3] NE DOIT PAS modifier le format ni le contenu des événements système de l'appareil (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) enregistrés via la commande dumpsys.
    • [C-0-10] DOIT enregistrer, sans omission, et rendre les événements suivants accessibles et disponibles pour la commande shell cmd stats et la classe d'API système StatsManager.
      • ActivityForegroundStateChanged
      • AnomalyDetected
      • AppBreadcrumbReported
      • AppCrashOccurred
      • AppStartOccurred
      • BatteryLevelChanged
      • BatterySaverModeStateChanged
      • BleScanResultReceived
      • BleScanStateChanged
      • ChargingStateChanged
      • DeviceIdleModeStateChanged
      • ForegroundServiceStateChanged
      • GpsScanStateChanged
      • JobStateChanged
      • PluggedStateChanged
      • ScheduledJobStateChanged
      • ScreenStateChanged
      • SyncStateChanged
      • SystemElapsedRealtime
      • UidProcessStateChanged
      • WakelockStateChanged
      • WakeupAlarmOccurred
      • WifiLockStateChanged
      • WifiMulticastLockStateChanged
      • WifiScanStateChanged
    • [C-0-4] Le daemon adb côté appareil doit être inactif par défaut, et un mécanisme accessible par l'utilisateur doit être disponible pour activer Android Debug Bridge.
    • [C-0-5] DOIT prendre en charge adb sécurisé. Android est compatible avec adb sécurisé. adb sécurisé active adb sur les hôtes authentifiés connus.

    • [C-0-6] DOIT fournir un mécanisme permettant à adb de se connecter à partir d'une machine hôte. Exemple :

      • Les implémentations d'appareils sans port USB compatible avec le mode périphérique DOIVENT implémenter adb via un réseau local (tel qu'Ethernet ou Wi-Fi).
      • DOIT fournir des pilotes pour Windows 7, 9 et 10, permettant aux développeurs de se connecter à l'appareil à l'aide du protocole adb.

  • Service Dalvik Debug Monitor (ddms)

    • [C-0-7] DOIT être compatible avec toutes les fonctionnalités ddms, comme indiqué dans le SDK Android. Comme ddms utilise adb, la prise en charge de ddms DOIT être inactive par défaut, mais DOIT être prise en charge chaque fois que l'utilisateur a activé Android Debug Bridge, comme indiqué ci-dessus.
  • Singe
    • [C-0-8] DOIT inclure le framework Monkey et le mettre à la disposition des applications.
  • SysTrace
    • [C-0-9] DOIT être compatible avec l'outil systrace, comme indiqué dans le SDK Android. Systrace doit être inactif par défaut, et un mécanisme accessible par l'utilisateur doit être disponible pour l'activer.

Si les implémentations de l'appareil signalent la prise en charge de Vulkan 1.0 ou version ultérieure via les indicateurs de fonctionnalité android.hardware.vulkan.version, elles:

  • [C-1-1] Le développeur de l'application DOIT pouvoir activer/désactiver les couches de débogage GPU.
  • [C-1-2] Lorsque les couches de débogage du GPU sont activées, le programme doit énumérer les couches dans les bibliothèques fournies par des outils externes (c'est-à-dire qui ne font pas partie du package de plate-forme ou d'application) trouvées dans le répertoire de base des applications débogables pour prendre en charge les méthodes d'API vkEnumerateInstanceLayerProperties() et vkCreateInstance().

6.2. Options pour les développeurs

Android permet aux développeurs de configurer des paramètres liés au développement d'applications.

Les implémentations d'appareils doivent fournir une expérience cohérente pour les options pour les développeurs. Elles doivent:

  • [C-0-1] DOIT respecter l'intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS pour afficher les paramètres liés au développement d'applications. L'implémentation Android en amont masque le menu "Options pour les développeurs" par défaut et permet aux utilisateurs de le lancer après avoir appuyé sept (7) fois sur l'élément de menu Settings > About Device > Build Number (Paramètres > À propos de l'appareil > Numéro de version).
  • [C-0-2] Les options pour les développeurs doivent être masquées par défaut.
  • [C-0-3] DOIT fournir un mécanisme clair qui n'accorde pas de traitement préférentiel à une application tierce par rapport à une autre pour activer les options pour les développeurs. Vous devez fournir un document ou un site Web public qui explique comment activer les options pour les développeurs. Ce document ou ce site Web DOIT être accessible depuis les documents du SDK Android.
  • DOIT envoyer une notification visuelle continue à l'utilisateur lorsque les options pour les développeurs sont activées et que la sécurité de l'utilisateur est préoccupante.
  • PEUT limiter temporairement l'accès au menu "Options pour les développeurs" en le masquant ou en le désactivant visuellement afin d'éviter toute distraction dans les cas où la sécurité de l'utilisateur est préoccupante.

7. Compatibilité matérielle

Si un appareil inclut un composant matériel particulier associé à une API pour les développeurs tiers:

  • [C-0-1] L'implémentation de l'appareil DOIT implémenter cette API comme décrit dans la documentation du SDK Android.

Si une API du SDK interagit avec un composant matériel déclaré comme facultatif et que l'implémentation de l'appareil ne dispose pas de ce composant:

  • [C-0-2] Les définitions complètes des classes (telles que documentées par le SDK) des API de composant DOIVENT toujours être présentées.
  • [C-0-3] Les comportements de l'API DOIVENT être implémentés comme des opérations sans action de manière raisonnable.
  • [C-0-4] Les méthodes d'API DOIVENT renvoyer des valeurs nulles lorsque la documentation du SDK l'autorise.
  • [C-0-5] Les méthodes d'API DOIVENT renvoyer des implémentations sans opération de classes pour lesquelles les valeurs nulles ne sont pas autorisées par la documentation du SDK.
  • [C-0-6] Les méthodes d'API NE DOIVENT PAS générer d'exceptions non documentées dans la documentation du SDK.
  • [C-0-7] Les implémentations d'appareils DOIVENT systématiquement fournir des informations de configuration matérielle précises via les méthodes getSystemAvailableFeatures() et hasSystemFeature(String) de la classe android.content.pm.PackageManager pour le même identifiant de compilation.

L'API Telephony est un exemple typique de scénario où ces exigences s'appliquent: même sur les appareils autres que des téléphones, ces API doivent être implémentées comme des opérations sans opération raisonnables.

7.1. Écran et graphismes

Android inclut des fonctionnalités qui ajustent automatiquement les composants d'application et les mises en page de l'interface utilisateur en fonction de l'appareil afin de s'assurer que les applications tierces fonctionnent correctement sur différentes configurations matérielles. 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:

  • la taille diagonale physique ; Distance en pouces entre deux coins opposés de la partie éclairée de l'écran.
  • points par pouce (ppp). Nombre de pixels compris dans une plage linéaire horizontale ou verticale de 1 pouce. Lorsque des valeurs de PPP sont indiquées, les PPP horizontaux et verticaux doivent se trouver dans la plage.
  • format. Rapport entre les pixels de la dimension la plus longue et la dimension la plus courte de l'écran. Par exemple, un écran de 480 x 854 pixels correspond à 854/480 = 1,779, soit environ "16:9".
  • pixels indépendants de la densité (dp). Unité de pixel virtuel normalisée à un écran de 160 ppp, calculée comme suit: pixels = dps * (densité/160).

7.1.1. Configuration de l'écran

7.1.1.1. Taille et forme de l'écran

Le framework d'UI Android est compatible avec différentes tailles de mise en page d'écran logiques et permet aux applications de interroger la taille de mise en page d'écran de la configuration actuelle via Configuration.screenLayout avec SCREENLAYOUT_SIZE_MASK et Configuration.smallestScreenWidthDp.

Implémentations de l'appareil:

  • [C-0-1] DOIT indiquer la taille de mise en page correcte pour le Configuration.screenLayout, comme défini dans la documentation du SDK Android. Plus précisément, les implémentations d'appareils DOIVENT indiquer les dimensions d'écran logiques en pixels indépendants de la densité (dp) correctes, comme indiqué ci-dessous:

    • Les appareils dont la valeur Configuration.uiMode est définie sur une valeur autre que UI_MODE_TYPE_WATCH et qui indiquent une taille small pour Configuration.screenLayout DOIVENT avoir une taille d'au moins 426 dp x 320 dp.
    • Les appareils qui indiquent une taille normal pour le Configuration.screenLayout DOIVENT avoir une taille d'au moins 480 dp x 320 dp.
    • Les appareils qui indiquent une taille large pour le Configuration.screenLayout DOIVENT avoir une taille d'au moins 640 dp x 480 dp.
    • Les appareils qui indiquent une taille xlarge pour le Configuration.screenLayout DOIVENT avoir une taille d'au moins 960 dp x 720 dp.

  • [C-0-2] DOIT respecter correctement la compatibilité déclarée des applications avec les tailles d'écran via l'attribut <supports-screens> dans le fichier AndroidManifest.xml, comme décrit dans la documentation du SDK Android.

  • Peut avoir un écran aux coins arrondis.

Si les implémentations d'appareils sont compatibles avec UI_MODE_TYPE_NORMAL et incluent un écran aux coins arrondis, elles:

  • [C-1-1] Vous devez vous assurer que le rayon des coins arrondis est inférieur ou égal à 38 dp.
  • DOIT inclure une affordance utilisateur pour passer au mode d'affichage avec les coins rectangulaires.
7.1.1.2. Format d'écran

Bien qu'il n'y ait aucune restriction concernant la valeur du format de l'écran physique, le format de l'écran logique dans lequel les applications tierces sont affichées, comme indiqué par les valeurs de hauteur et de largeur signalées via les API view.Display et l'API Configuration, DOIT respecter les exigences suivantes:

  • [C-0-1] Les implémentations d'appareils pour lesquels Configuration.uiMode est défini sur UI_MODE_TYPE_NORMAL DOIVENT avoir un format compris entre 1,3333 (4:3) et 1,86 (environ 16:9), sauf si l'application peut être considérée comme prête à être étirée en remplissant l'une des conditions suivantes:

    • L'application a déclaré qu'elle était compatible avec un format d'écran plus grand via la valeur de métadonnées android.max_aspect.
    • L'application déclare qu'elle peut être redimensionnée via l'attribut android:resizeableActivity.
    • L'application cible le niveau d'API 24 ou supérieur et ne déclare pas de android:MaxAspectRatio qui limiterait le format autorisé.

  • [C-0-2] Les implémentations d'appareils pour lesquels Configuration.uiMode est défini sur UI_MODE_TYPE_WATCH DOIVENT avoir une valeur de format définie sur 1,0 (1:1).

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

  • [C-0-1] Par défaut, les implémentations d'appareils DOIVENT ne signaler qu'une seule des densités logiques du framework Android suivantes via l'API DENSITY_DEVICE_STABLE, et cette valeur NE DOIT PAS changer à tout moment. Toutefois, l'appareil PEUT signaler une densité arbitraire différente en fonction des modifications de configuration de l'écran apportées par l'utilisateur (taille de l'écran, par exemple) après le démarrage initial.

    • 120 PPP (ldpi)
    • 160 ppp (mdpi)
    • 213 ppp (tvdpi)
    • 240 ppp (hdpi)
    • 260 ppp (260 dpi)
    • 280 ppp (280 dpi)
    • 300 ppp (300 dpi)
    • 320 ppp (xhdpi)
    • 340 PPP (340dpi)
    • 360 dpi (360 dpi)
    • 400 ppp (400 dpi)
    • 420 ppp (420dpi)
    • 480 dpi (xxhdpi)
    • 560 ppp (560dpi)
    • 640 ppp (xxxhdpi)

  • Les implémentations d'appareils DOIVENT définir la densité de framework Android standard la plus proche numériquement 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é du 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é du framework Android standard la plus basse.

Si une affordance permet de modifier la taille d'affichage de l'appareil:

  • [C-1-1] La taille de l'écran NE DOIT PAS être agrandie de plus de 1,5 fois la densité native ni produire une dimension d'écran minimale effective inférieure à 320 dp (équivalent au qualificatif de ressource sw320dp), selon la première éventualité.
  • [C-1-2] La taille de l'écran NE DOIT PAS être réduite à moins de 0,85 fois la densité native.
  • Pour assurer une bonne usabilité et des tailles de police cohérentes, nous vous RECOMMANDONS de fournir la mise à l'échelle suivante des options d'affichage natif (tout en respectant les limites spécifiées ci-dessus) :
  • Petite: 0,85x
  • Par défaut: 1x (échelle d'affichage native)
  • Grande: 1,15 x
  • Plus grand: x 1,3
  • Plus grande : x 1,45

7.1.2. Métriques sur le Réseau Display

Si les implémentations d'appareils incluent un écran ou une sortie vidéo, elles:

Si les implémentations d'appareils n'incluent pas d'écran intégré ni de sortie vidéo, elles:

  • [C-2-1] DOIT indiquer des valeurs raisonnables pour toutes les métriques d'affichage définies dans l'API android.util.DisplayMetrics pour l'view.Display par défaut émulé.

7.1.3. Orientation de l'écran

Implémentations de l'appareil:

  • [C-0-1] DOIT indiquer les orientations d'écran compatibles (android.hardware.screen.portrait et/ou android.hardware.screen.landscape) et DOIT indiquer au moins une orientation compatible. Par exemple, un appareil doté d'un écran en mode paysage fixe, comme un téléviseur ou un ordinateur portable, DOIT uniquement indiquer android.hardware.screen.landscape.
  • [C-0-2] DOIT indiquer la valeur correcte pour l'orientation actuelle de l'appareil, chaque fois qu'il est interrogé via les API android.content.res.Configuration.orientation, android.view.Display.getOrientation() ou d'autres.

Si les implémentations de l'appareil sont compatibles avec les deux orientations d'écran, elles:

  • [C-1-1] Les applications doivent être compatibles avec l'orientation dynamique en mode portrait ou paysage. Autrement dit, l'appareil doit respecter la demande de l'application concernant une orientation d'écran spécifique.
  • [C-1-2] NE DOIT PAS modifier la taille ou la densité de l'écran indiquées lorsque l'orientation change.
  • PEUT sélectionner l'orientation portrait ou paysage par défaut.

7.1.4. Accélération graphique 2D et 3D

7.1.4.1 OpenGL ES

Implémentations de l'appareil:

  • [C-0-1] DOIT identifier correctement les versions OpenGL ES compatibles (1.1, 2.0, 3.0, 3.1, 3.2) via les API gérées (par exemple, via la méthode GLES10.getString()) et les API natives.
  • [C-0-2] DOIT inclure la prise en charge de toutes les API gérées et API natives correspondantes pour toutes les versions d'OpenGL ES qu'il a identifiées comme compatibles.

Si les implémentations d'appareils incluent un écran ou une sortie vidéo, elles:

  • [C-1-1] DOIT être compatible avec OpenGL ES 1.1 et 2.0, comme indiqué et détaillé dans la documentation du SDK Android.
  • [SR] est FORTEMENT RECOMMANDÉ pour la prise en charge d'OpenGL ES 3.1.
  • DOIT être compatible avec OpenGL ES 3.2.

Si les implémentations de l'appareil sont compatibles avec l'une des versions d'OpenGL ES, elles:

  • [C-2-1] DOIT signaler via les API gérées OpenGL ES et les API natives toutes les autres extensions OpenGL ES qu'il a implémentées, et inversement NE DOIT PAS signaler les chaînes d'extension qu'il n'est pas compatible.
  • [C-2-2] DOIT prendre en charge les extensions EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage et EGL_ANDROID_recordable.
  • [SR] Il est FORTEMENT RECOMMANDÉ d'accepter EGL_KHR_partial_update.
  • DOIT signaler avec précision, via la méthode getString(), tout format de compression de texture compatible, qui est généralement spécifique au fournisseur.

Si les implémentations de l'appareil déclarent être compatibles avec OpenGL ES 3.0, 3.1 ou 3.2, elles:

  • [C-3-1] DOIT exporter les symboles de fonction correspondants pour ces versions en plus des symboles de fonction OpenGL ES 2.0 dans la bibliothèque libGLESv2.so.

Si les implémentations de l'appareil sont compatibles avec OpenGL ES 3.2, elles:

  • [C-4-1] DOIT être compatible avec l'intégralité du pack d'extensions Android OpenGL ES.

Si les implémentations de l'appareil sont entièrement compatibles avec le pack d'extensions Android OpenGL ES, elles:

  • [C-5-1] Vous devez indiquer la prise en charge via l'indicateur de fonctionnalité android.hardware.opengles.aep.

Si les implémentations d'appareils exposent la prise en charge de l'extension EGL_KHR_mutable_render_buffer, elles:

  • [C-6-1] DOIT également prendre en charge l'extension EGL_ANDROID_front_buffer_auto_refresh.
7.1.4.2 Vulkan

Android est compatible avec Vulkan, une API multiplate-forme simple d'utilisation pour les graphismes 3D hautes performances.

Si les implémentations de l'appareil sont compatibles avec OpenGL ES 3.1, elles:

  • [SR] Nous vous RECOMMANDONS vivement d'inclure la prise en charge de Vulkan 1.1.

Si les implémentations d'appareils incluent un écran ou une sortie vidéo, elles:

  • DOIT inclure la compatibilité avec Vulkan 1.1.

Si les implémentations de l'appareil incluent la prise en charge de Vulkan 1.0, elles:

  • [C-1-1] DOIT indiquer la valeur entière correcte avec les indicateurs de fonctionnalité android.hardware.vulkan.level et android.hardware.vulkan.version.
  • [C-1-2] DOIT énumérer au moins un VkPhysicalDevice pour l'API native Vulkan vkEnumeratePhysicalDevices() .
  • [C-1-3] DOIT implémenter entièrement les API Vulkan 1.0 pour chaque VkPhysicalDevice énuméré.
  • [C-1-4] DOIT énumérer les calques, contenus dans des bibliothèques natives nommées libVkLayer*.so dans le répertoire de bibliothèques natives du package d'application, via les API natives Vulkan vkEnumerateInstanceLayerProperties() et vkEnumerateDeviceLayerProperties() .
  • [C-1-5] NE DOIT PAS énumérer les calques fournis par des bibliothèques en dehors du package d'application, ni fournir d'autres moyens de suivre ou d'intercepter l'API Vulkan, sauf si l'attribut android:debuggable de l'application est défini sur true.
  • [C-1-6] DOIT signaler toutes les chaînes d'extension qu'il prend en charge via les API natives Vulkan et, inversement, NE DOIT PAS signaler les chaînes d'extension qu'il ne prend pas correctement en charge.
  • [C-1-7] DOIT être compatible avec les extensions VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain et VK_KHR_incremental_present.

Si les implémentations de l'appareil ne sont pas compatibles avec Vulkan 1.0, elles:

  • [C-2-1] NE DOIT PAS déclarer l'un des commutateurs de fonctionnalité Vulkan (par exemple, android.hardware.vulkan.level, android.hardware.vulkan.version).
  • [C-2-2] NE DOIT PAS énumérer de VkPhysicalDevice pour l'API native Vulkan vkEnumeratePhysicalDevices().

Si les implémentations de l'appareil incluent la prise en charge de Vulkan 1.1, elles:

  • [C-3-1] DOIT exposer la compatibilité avec les types de sémaphores et de poignées externes SYNC_FD.
  • [SR] Nous vous RECOMMANDONS vivement de prendre en charge l'extension VK_ANDROID_external_memory_android_hardware_buffer.
7.1.4.3 RenderScript
  • [C-0-1] Les implémentations d'appareils DOIVENT être compatibles avec Android RenderScript, comme indiqué dans la documentation du SDK Android.
7.1.4.4 Accélération graphique 2D

Android 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 manifeste android:hardwareAccelerated ou d'appels d'API directs.

Implémentations de l'appareil:

  • [C-0-1] DOIT activer l'accélération matérielle par défaut et DOIT 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 View Android.
  • [C-0-2] DOIT présenter un comportement conforme à la documentation du SDK Android sur l'accélération matérielle.

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

Implémentations de l'appareil:

  • [C-0-3] DOIT prendre en charge l'API TextureView et DOIT présenter un comportement cohérent avec l'implémentation Android en amont.
7.1.4.5 Écrans à large gamme de couleurs

Si les implémentations d'appareils indiquent la prise en charge des écrans à large gamme de couleurs via Configuration.isScreenWideColorGamut() , elles:

  • [C-1-1] L'écran doit être CALIBRÉ.
  • [C-1-2] L'écran doit couvrir entièrement la gamme de couleurs sRVB dans l'espace xyY CIE 1931.
  • [C-1-3] L'écran doit avoir une gamme dont la surface est d'au moins 90% de la gamme DCI-P3 dans l'espace xyY CIE 1931.
  • [C-1-4] DOIT être compatible avec OpenGL ES 3.1 ou 3.2 et le signaler correctement.
  • [C-1-5] DOIT indiquer la prise en charge des extensions EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3 et EGL_KHR_gl_colorspace_display_p3.
  • [SR] Nous vous RECOMMANDONS vivement de prendre en charge GL_EXT_sRGB.

À l'inverse, si les implémentations d'appareils ne sont pas compatibles avec les écrans à large gamme de couleurs, elles:

  • [C-2-1] DOIT couvrir au moins 100% de l'espace sRVB dans l'espace xyY CIE 1931, bien que la gamme de couleurs de l'écran ne soit pas définie.

7.1.5. Ancien mode de compatibilité des applications

Android spécifie un "mode de compatibilité" dans lequel le framework fonctionne en mode équivalent à une taille d'écran "normale" (largeur de 320 dp) pour les anciennes applications qui n'ont pas été développées pour les anciennes versions d'Android antérieures à l'indépendance de la taille d'écran.

7.1.6. Technologie d'affichage

La plate-forme Android inclut des API qui permettent aux applications d'afficher des éléments graphiques riches. Les appareils DOIVENT être compatibles avec toutes ces API telles que définies par le SDK Android, sauf si cela est spécifiquement autorisé dans ce document.

Implémentations de l'appareil:

  • [C-0-1] DOIT prendre en charge les écrans capables de générer des graphiques couleur 16 bits.
  • DOIT être compatible avec les écrans capables d'afficher des graphiques couleur 24 bits.
  • [C-0-2] DOIT être compatible avec les écrans capables d'afficher des animations.
  • [C-0-3] DOIT utiliser la technologie d'affichage dont le format de pixel (PAR) est compris entre 0,9 et 1,15. Autrement dit, le format de pixel DOIT être proche du carré (1,0) avec une tolérance de 10 à 15 %.

7.1.7. Écrans secondaires

Android est compatible avec les écrans secondaires pour permettre le partage de contenus multimédias et les API pour les développeurs afin d'accéder aux écrans externes.

Si les implémentations d'appareils sont compatibles avec un écran externe via une connexion filaire, sans fil ou intégrée, elles:

  • [C-1-1] DOIT implémenter le service système et l'API DisplayManager comme décrit dans la documentation du SDK Android.

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

Implémentations de l'appareil:

7.2.1. Clavier

Si les implémentations d'appareils sont compatibles avec des applications tierces d'éditeur de mode de saisie (IME), elles:

Implémentations de l'appareil: * [C-0-1] NE DOIT PAS inclure de clavier physique qui ne correspond pas à l'un des formats spécifiés dans android.content.res.Configuration.keyboard (QWERTY ou 12 touches). * DOIT inclure des implémentations de clavier virtuel supplémentaires. * Peut inclure un clavier physique.

7.2.2. Navigation non tactile

Android est compatible avec le pavé directionnel, le trackball et la molette comme mécanismes de navigation non tactile.

Implémentations de l'appareil:

Si les implémentations d'appareils ne proposent pas de navigation non tactile, elles:

  • [C-1-1] 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. L'implémentation Open Source d'Android en amont inclut un mécanisme de sélection adapté aux appareils qui ne disposent pas de commandes de navigation non tactiles.

7.2.3. Touches de navigation

Les fonctions Accueil, Récents et Retour, généralement fournies via une interaction avec un bouton physique dédié ou une partie distincte de l'écran tactile, sont essentielles au paradigme de navigation Android et, par conséquent, aux implémentations d'appareils:

  • [C-0-1] DOIT fournir une affordance utilisateur pour lancer les applications installées qui ont une activité avec <intent-filter> défini sur ACTION=MAIN et CATEGORY=LAUNCHER ou CATEGORY=LEANBACK_LAUNCHER pour les implémentations d'appareils de télévision. La fonction "Accueil" DOIT être le mécanisme de cette affordance utilisateur.
  • DOIT fournir des boutons pour les fonctions "Recents" (Actions récentes) et "Back" (Retour).

Si les fonctions Accueil, Récents ou Retour sont fournies, elles:

  • [C-1-1] DOIVENT être accessibles par une seule action (par exemple, appuyer, double-cliquer ou effectuer un geste) si l'une d'elles est accessible.
  • [C-1-2] DOIT indiquer clairement quelle action déclenchera chaque fonction. Une icône visible imprimée sur le bouton, une icône logicielle affichée dans la partie de la barre de navigation de l'écran ou un flux de démonstration guidé par étapes lors de la configuration prête à l'emploi sont des exemples d'indications de ce type.

Implémentations de l'appareil:

  • [SR] Il est FORTEMENT RECOMMANDÉ de ne pas fournir le mécanisme d'entrée pour la fonction Menu, car elle est obsolète depuis Android 4.0 et remplacée par la barre d'action.

Si les implémentations d'appareils fournissent la fonction Menu, elles:

  • [C-2-1] Le bouton de menu à développer doit s'afficher chaque fois que le pop-up du menu à développer n'est pas vide et que la barre d'action est visible.
  • [C-2-2] NE DOIT PAS modifier la position du pop-up à développer d'actions affiché en sélectionnant le bouton à développer dans la barre d'action, mais PEUT afficher le pop-up à développer d'actions à une position modifiée à l'écran lorsqu'il est affiché en sélectionnant la fonction Menu.

Si les implémentations d'appareils ne fournissent pas la fonction Menu, pour assurer la rétrocompatibilité, elles: * [C-3-1] DOIVENT mettre la fonction Menu à la disposition des applications lorsque targetSdkVersion est inférieur à 10, soit par un bouton physique, une touche logicielle ou des gestes. Cette fonction de menu doit être accessible, sauf si elle est masquée avec d'autres fonctions de navigation.

Si les implémentations de l'appareil fournissent la fonction d'assistance: * [C-4-1] DOIVENT rendre la fonction d'assistance accessible en une seule action (par exemple, appuyer, double-cliquer ou effectuer un geste) lorsque d'autres touches de navigation sont accessibles. * [SR] Nous vous RECOMMANDONS vivement d'utiliser l'appui prolongé sur la fonction HOME comme interaction désignée.

Si les implémentations d'appareils utilisent une partie distincte de l'écran pour afficher les touches de navigation, elles:

  • [C-5-1] Les touches de navigation DOIVENT utiliser une partie distincte de l'écran, qui n'est pas disponible pour les applications. Elles NE DOIVENT PAS masquer ni interférer avec la partie de l'écran disponible pour les applications.
  • [C-5-2] DOIT mettre à disposition une partie de l'écran pour les applications qui répondent aux exigences définies dans la section 7.1.1.
  • [C-5-3] DOIT respecter les indicateurs définis par l'application via la méthode d'API View.setSystemUiVisibility(), afin que cette partie distincte de l'écran (également appelée barre de navigation) soit correctement masquée, comme indiqué dans le SDK.

7.2.4. Saisie par écran tactile

Android est compatible avec divers systèmes d'entrée par pointeur, tels que les écrans tactiles, les pavés tactiles et les faux périphériques d'entrée tactile. Les implémentations d'appareils à écran tactile sont associées à un écran de sorte que l'utilisateur ait l'impression de manipuler directement les éléments à l'écran. Étant donné que l'utilisateur touche directement l'écran, le système n'a pas besoin d'affordances supplémentaires pour indiquer les objets manipulés.

Implémentations de l'appareil:

  • DOIT disposer d'un système d'entrée de pointeur (souris ou tactile).
  • DOIT prendre en charge les pointeurs entièrement suivis de manière indépendante.

Si les implémentations d'appareils incluent un écran tactile (à un ou plusieurs points de contact), elles:

  • [C-1-1] DOIT indiquer TOUCHSCREEN_FINGER pour le champ d'API Configuration.touchscreen.
  • [C-1-2] DOIT signaler les indicateurs de fonctionnalité android.hardware.touchscreen et android.hardware.faketouch.

Si les implémentations d'appareils incluent un écran tactile capable de suivre plusieurs gestes, elles:

  • [C-2-1] DOIT indiquer les indicateurs de fonctionnalité appropriés android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct et android.hardware.touchscreen.multitouch.jazzhand correspondant au type d'écran tactile spécifique de l'appareil.

Si les implémentations d'appareils n'incluent pas d'écran tactile (et ne reposent que sur un pointeur) et répondent aux exigences de l'interface tactile simulée de la section 7.2.5, elles:

  • [C-3-1] NE DOIT PAS signaler de flag de fonctionnalité commençant par android.hardware.touchscreen et DOIT signaler uniquement android.hardware.faketouch.

7.2.5. Saisie tactile fictive

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'apparente à l'écran tactile, mais l'utilisateur doit d'abord pointer ou sélectionner un élément, puis cliquer. De nombreux périphériques d'entrée, comme la souris, le pavé tactile, la souris sans fil à gyroscope, le pointeur à gyroscope, le joystick et le pavé tactile multipoint, peuvent prendre en charge les interactions tactiles simulées. Android inclut la constante de fonctionnalité android.hardware.faketouch, qui correspond à un périphérique d'entrée non tactile (basé sur un pointeur) haute fidélité, tel qu'une souris ou un pavé tactile, qui peut émuler de manière adéquate la saisie 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.

Si les implémentations d'appareils n'incluent pas d'écran tactile, mais un autre système d'entrée par pointeur qu'ils souhaitent mettre à disposition, ils doivent:

  • DOIT déclarer la prise en charge du flag de fonctionnalité android.hardware.faketouch.

Si les implémentations d'appareils déclarent la compatibilité avec android.hardware.faketouch, elles:

  • [C-1-1] DOIT indiquer les positions X et Y absolues de l'écran de l'emplacement du pointeur et afficher un pointeur visuel à l'écran.
  • [C-1-2] DOIT signaler l'événement tactile avec le code d'action qui spécifie le changement d'état qui se produit lorsque le pointeur descend ou monte sur l'écran.
  • [C-1-3] DOIT prendre en charge le pointeur vers le bas et vers le haut sur un objet à l'écran, ce qui permet aux utilisateurs d'émuler un appui sur un objet à l'écran.
  • [C-1-4] DOIT prendre en charge les gestes de pointage vers le bas, de pointage vers le haut, de pointage vers le bas, puis de pointage vers le haut au même endroit sur un objet à l'écran dans un délai donné, ce qui permet aux utilisateurs d'émuler le double appui sur un objet à l'écran.
  • [C-1-5] DOIT prendre en charge le pointeur vers le bas sur un point arbitraire de l'écran, le déplacement du pointeur vers un autre point arbitraire de l'écran, suivi d'un pointeur vers le haut, ce qui permet aux utilisateurs d'émuler un glissement tactile.
  • [C-1-6] DOIT prendre en charge le pointeur vers le bas, puis permettre aux utilisateurs de déplacer rapidement l'objet vers une autre position à l'écran, puis de pointer vers le haut de l'écran, ce qui leur permet de lancer un objet à l'écran.
  • [C-1-7] DOIT indiquer TOUCHSCREEN_NOTOUCH pour le champ de l'API Configuration.touchscreen.

Si les implémentations d'appareils déclarent la compatibilité avec android.hardware.faketouch.multitouch.distinct, elles:

  • [C-2-1] DOIT déclarer la prise en charge de android.hardware.faketouch.
  • [C-2-2] DOIT permettre le suivi distinct de deux entrées de pointeur indépendantes ou plus.

Si les implémentations d'appareils déclarent la compatibilité avec android.hardware.faketouch.multitouch.jazzhand, elles:

  • [C-3-1] DOIT déclarer la prise en charge de android.hardware.faketouch.
  • [C-3-2] DOIT prendre en charge le suivi distinct de cinq (suivi d'une main avec cinq doigts) ou de plusieurs entrées de pointeur de manière totalement indépendante.

7.2.6. Compatibilité avec les manettes de jeu

7.2.6.1. Mappages des boutons

Si les implémentations d'appareils déclarent l'indicateur de fonctionnalité android.hardware.gamepad, elles:

  • [C-1-1] DOIT intégrer un contrôleur ou être livré avec un contrôleur distinct dans la boîte, qui permettra de saisir tous les événements listés dans les tableaux ci-dessous.
  • [C-1-2] DOIT être capable de mapper les événements HID sur les constantes Android view.InputEvent associées, comme indiqué dans les tableaux ci-dessous. L'implémentation Android en amont inclut une implémentation pour les contrôleurs de jeu qui répond à cette exigence.
Bouton Utilisation de l'HID2 Bouton Android
A1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 0x09 0x0004 KEYCODE_BUTTON_X (99)
Y1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
Croix directionnelle vers le haut1
Croix directionnelle vers le bas1 		0x01 0x00393 AXIS_HAT_Y4
Pavé directionnel vers la gauche1
Pavé directionnel vers la droite1 		0x01 0x00393 AXIS_HAT_X4
Bouton de l'épaule gauche1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
Bouton de l'épaule droite1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
Clic sur le stick gauche1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
Clic sur le stick droit1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
Accueil1 0x0c 0x0223 KEYCODE_HOME (3)
Retour1 0x0c 0x0224 KEYCODE_BACK (4)

1 KeyEvent

2 Les utilisations HID ci-dessus doivent être déclarées dans une autorité de certification de manette de jeu (0x01 0x0005).

3 Cette utilisation doit avoir une valeur minimale logique de 0, une valeur maximale logique de 7, une valeur minimale physique de 0, une valeur maximale physique de 315, des unités en degrés et une taille de rapport de 4. La valeur logique est définie comme étant la rotation dans le sens des aiguilles d'une montre, à partir de l'axe vertical. Par exemple, une valeur logique de 0 représente une absence de rotation et la pression sur le bouton "Haut", tandis qu'une valeur logique de 1 représente une rotation de 45 degrés et la pression sur les touches "Haut" et "Gauche".

4 MotionEvent

Commandes analogiques1 Utilisation des périphériques HID Bouton Android
Gauche 0x02 0x00C5 AXIS_LTRIGGER
Gauche 0x02 0x00C4 AXIS_RTRIGGER
Stick gauche 0x01 0x0030
0x01 0x0031 		AXIS_X
AXIS_Y
Stick droit 0x01 0x0032
0x01 0x0035 		AXIS_Z
AXIS_RZ

1 MotionEvent

7.2.7. Télécommande

Pour connaître les exigences spécifiques à l'appareil, consultez la section 2.3.1.

7.3. Capteurs

Si les implémentations d'appareils incluent un type de capteur particulier associé à une API 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 et la documentation Open Source Android sur les capteurs.

Implémentations de l'appareil:

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

Si les implémentations d'appareils incluent un type de capteur particulier associé à une API pour les développeurs tiers, ils:

  • [C-1-1] DOIT signaler toutes les mesures des capteurs à l'aide des valeurs du système international d'unités (métriques) appropriées pour chaque type de capteur, comme défini dans la documentation du SDK Android.
  • [C-1-2] DOIT signaler les données des capteurs avec une latence maximale de 100 millisecondes + 2 * sample_time pour le cas d'un capteur en streaming avec une latence minimale requise de 5 ms + 2 * sample_time lorsque le processeur d'application est actif. Ce délai n'inclut pas les délais de filtrage.
  • [C-1-3] DOIT signaler le premier échantillon du capteur dans les 400 millisecondes + 2 * sample_time de l'activation du capteur. Une précision de 0 est acceptable pour cet exemple.

  • [SR] DOIT signaler l'heure de l'événement en nanosecondes, comme défini dans la documentation du SDK Android. Cette valeur représente l'heure à laquelle l'événement s'est produit et est synchronisée avec l'horloge SystemClock.elapsedRealtimeNano(). Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin qu'ils puissent passer aux futures versions de la plate-forme, où ce composant pourrait devenir OBLIGATOIRE. L'erreur de synchronisation DOIT être inférieure à 100 millisecondes.

  • [C-1-4] Pour toute API indiquée par la documentation du SDK Android comme étant un capteur continu, les implémentations d'appareils DOIVENT fournir en continu des échantillons de données périodiques dont le jitter DOIT être inférieur à 3%, où le jitter est défini comme l'écart type de la différence entre les valeurs de code temporel signalées entre les événements consécutifs.

  • [C-1-5] Le flux d'événements du capteur DOIT empêcher le processeur de l'appareil d'entrer dans un état de suspension ou de se réveiller d'un état de suspension.

  • Lorsque plusieurs capteurs sont activés, la consommation d'énergie NE DOIT PAS dépasser la somme de la consommation d'énergie indiquée pour chaque capteur.

La liste ci-dessus n'est pas exhaustive. Le comportement documenté du SDK Android et des documentations Open Source Android sur les capteurs doit être considéré comme faisant autorité.

Certains types de capteurs sont composites, 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).

Implémentations de l'appareil:

  • DOIT implémenter ces types de capteurs lorsqu'ils incluent les capteurs physiques requis, comme décrit dans la section Types de capteurs.

Si les implémentations d'appareils incluent un capteur composite, elles:

  • [C-2-1] DOIT implémenter le capteur comme décrit dans la documentation Open Source Android sur les capteurs composites.

7.3.1. Accéléromètre

  • Les implémentations d'appareils DOIVENT inclure un accéléromètre à trois axes.

Si les implémentations d'appareils incluent un accéléromètre à trois axes, elles:

  • [C-1-1] DOIT pouvoir signaler des événements jusqu'à une fréquence d'au moins 50 Hz.
  • [C-1-2] DOIT implémenter et signaler le capteur TYPE_ACCELEROMETER.
  • [C-1-3] DOIT respecter le système de coordonnées des capteurs Android, comme indiqué dans les API Android.
  • [C-1-4] DOIT être capable de mesurer la chute libre jusqu'à quatre fois la gravité(4 g) ou plus sur n'importe quel axe.
  • [C-1-5] La résolution doit être d'au moins 12 bits.
  • [C-1-6] DOIT avoir une écart type inférieur ou égal à 0,05 m/s^, où l'écart type doit être calculé par axe sur des échantillons collectés sur une période d'au moins trois secondes au taux d'échantillonnage le plus rapide.
  • [SR] est FORTEMENT RECOMMANDÉ d'implémenter le capteur composite TYPE_SIGNIFICANT_MOTION.
  • [SR] Il est vivement recommandé d'implémenter le capteur TYPE_ACCELEROMETER_UNCALIBRATED si le calibrage de l'accéléromètre en ligne est disponible.
  • DOIT implémenter les capteurs composites TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR et TYPE_STEP_COUNTER comme décrit dans le document du SDK Android.
  • DOIT signaler les événements jusqu'à au moins 200 Hz.
  • DOIT avoir une résolution d'au moins 16 bits.
  • DOIT être calibré pendant l'utilisation si les caractéristiques changent au cours du cycle de vie et être compensé, et doit conserver les paramètres de compensation entre les redémarrages de l'appareil.
  • DOIT être compensé en température.
  • DOIT également implémenter le capteur TYPE_ACCELEROMETER_UNCALIBRATED.

Si les implémentations d'appareils incluent un accéléromètre à trois axes et que l'un des capteurs composites TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR ou TYPE_STEP_COUNTER est implémenté:

  • [C-2-1] La somme de leur consommation d'énergie DOIT toujours être inférieure à 4 mW.
  • DOIVENT être inférieurs à 2 mW et 0,5 mW lorsque l'appareil est dans un état dynamique ou statique.

Si les implémentations de l'appareil incluent un accéléromètre à trois axes et un capteur de gyroscope:

  • [C-3-1] Vous DEVEZ implémenter les capteurs composites TYPE_GRAVITY et TYPE_LINEAR_ACCELERATION.
  • DOIT implémenter le capteur composite TYPE_GAME_ROTATION_VECTOR.
  • [SR] Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur TYPE_GAME_ROTATION_VECTOR sur les appareils Android existants et nouveaux.

Si les implémentations de l'appareil incluent un accéléromètre à trois axes, un capteur de gyroscope et un capteur de magnétomètre:

  • [C-4-1] DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR.

7.3.2. Magnétomètre

  • Les implémentations d'appareils DOIVENT inclure un magnétomètre (boussole) à trois axes.

Si les implémentations d'appareils incluent un magnétomètre à trois axes, elles:

  • [C-1-1] Le capteur TYPE_MAGNETIC_FIELD DOIT être implémenté.
  • [C-1-2] DOIT pouvoir signaler des événements jusqu'à une fréquence d'au moins 10 Hz et DEVRAIT pouvoir signaler des événements jusqu'à au moins 50 Hz.
  • [C-1-3] DOIT respecter le système de coordonnées des capteurs Android, comme indiqué dans les API Android.
  • [C-1-4] DOIT être capable de mesurer entre -900 µT et +900 µT sur chaque axe avant de saturer.
  • [C-1-5] Le magnétomètre DOIT avoir une valeur de décalage par fer dur inférieure à 700 µT et DEVRAIT avoir une valeur inférieure à 200 µT, en le plaçant loin des champs magnétiques dynamiques (induits par le courant) et statiques (induits par les aimants).
  • [C-1-6] La résolution doit être égale ou plus dense que 0,6 µT.
  • [C-1-7] DOIT prendre en charge le calibrage et la compensation en ligne du biais de fer dur, et conserver les paramètres de compensation entre les redémarrages de l'appareil.
  • [C-1-8] La compensation du fer doux DOIT être appliquée. L'étalonnage peut être effectué pendant l'utilisation ou lors de la fabrication de l'appareil.
  • [C-1-9] L'écart type, calculé par axe sur les échantillons collectés sur une période d'au moins trois secondes au taux d'échantillonnage le plus rapide, DOIT être inférieur à 1,5 µT. L'écart type DOIT être inférieur à 0,5 µT.
  • DOIT implémenter le capteur TYPE_MAGNETIC_FIELD_UNCALIBRATED.
  • [SR] Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur TYPE_MAGNETIC_FIELD_UNCALIBRATED sur les appareils Android existants et nouveaux.

Si les implémentations de l'appareil incluent un magnétomètre à trois axes, un capteur d'accéléromètre et un capteur de gyroscope:

  • [C-2-1] DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR.

Si les implémentations d'appareils incluent un magnétomètre à trois axes et un accéléromètre, elles:

  • PEUT implémenter le capteur TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Si les implémentations d'appareils incluent un magnétomètre à trois axes, un accéléromètre et un capteur TYPE_GEOMAGNETIC_ROTATION_VECTOR, elles:

  • [C-3-1] DOIT consommer moins de 10 mW.
  • DOIT consommer moins de 3 mW lorsque le capteur est enregistré pour le mode par lot à 10 Hz.

7.3.3. GPS

Implémentations de l'appareil:

  • DOIT inclure un récepteur GPS/GNSS.

Si les implémentations d'appareils incluent un récepteur GPS/GNSS et signalent la fonctionnalité aux applications via le flag de fonctionnalité android.hardware.location.gps, elles:

  • [C-1-1] DOIT prendre en charge les sorties de position à une fréquence d'au moins 1 Hz lorsqu'elles sont demandées via LocationManager#requestLocationUpdate.
  • [C-1-2] DOIT être en mesure de déterminer la position en conditions d'espace dégagé (signaux forts, multichemin négligeable, HDOP < 2) sous 10 secondes (temps de première correction rapide), lorsqu'il est connecté à une connexion Internet d'au moins 0,5 Mbit/s. Cette exigence est généralement satisfaite par l'utilisation d'une forme de technique GPS/GNSS assistée ou prédictive pour réduire le temps de verrouillage GPS/GNSS (les données d'assistance incluent l'heure de référence, l'emplacement de référence et l'éphéméride/l'horloge du satellite).
    • [C-1-6] Après avoir effectué un tel calcul de position, les implémentations d'appareils DOIVENT déterminer sa position, en plein air, dans un délai de cinq secondes, lorsque les requêtes de localisation sont redémarrées, jusqu'à une heure après le calcul de position initial, même lorsque la requête ultérieure est effectuée sans connexion de données et/ou après un cycle d'alimentation.

  • En plein air, après avoir déterminé l'emplacement, à l'arrêt ou en mouvement avec une accélération inférieure à 1 mètre par seconde au carré:

    • [C-1-3] DOIT pouvoir déterminer la position à 20 mètres près et la vitesse à 0, 5 mètre par seconde près, au moins 95% du temps.
    • [C-1-4] DOIT suivre et signaler simultanément via GnssStatus.Callback au moins huit satellites d'une constellation.
    • DOIT pouvoir suivre simultanément au moins 24 satellites de plusieurs constellations (par exemple, GPS + au moins un de GLONASS, BeiDou ou Galileo).
    • [C-1-5] DOIT indiquer la génération de la technologie GNSS via l'API de test "getGnssYearOfHardware".
    • [SR] Continuer à fournir des sorties de position GPS/GNSS normales lors d'un appel téléphonique d'urgence.
    • [SR] Signaler les mesures GNSS de toutes les constellations suivies (comme indiqué dans les messages GnssStatus), à l'exception de SBAS.
    • [SR] Signaler l'AGC et la fréquence de mesure GNSS.
    • [SR] Enregistrez toutes les estimations de précision (y compris la direction, la vitesse et la verticale) pour chaque position GPS/GNSS.
    • [SR] Nous vous RECOMMANDONS vivement de respecter autant que possible les exigences obligatoires supplémentaires pour les appareils qui indiquent l'année "2016" ou "2017" via l'API de test LocationManager.getGnssYearOfHardware().

Si les implémentations d'appareils incluent un récepteur GPS/GNSS et signalent la fonctionnalité aux applications via le flag de fonctionnalité android.hardware.location.gps, et que l'API de test LocationManager.getGnssYearOfHardware() indique l'année "2016" ou une année ultérieure, elles:

  • [C-2-1] DOIT signaler les mesures GNSS dès qu'elles sont détectées, même si une position calculée à partir du GPS/GNSS n'est pas encore signalée.
  • [C-2-2] DOIT indiquer les pseudo-distances et les taux de pseudo-distance GNSS qui, dans des conditions d'ensoleillement après avoir déterminé la position, à l'arrêt ou en mouvement avec une accélération inférieure à 0, 2 m/s², sont suffisants pour calculer la position à 20 m près et la vitesse à 0, 2 m/s près, au moins 95% du temps.

Si les implémentations d'appareils incluent un récepteur GPS/GNSS et signalent la fonctionnalité aux applications via le flag de fonctionnalité android.hardware.location.gps, et que l'API de test LocationManager.getGnssYearOfHardware() indique l'année "2017" ou une année ultérieure, elles:

  • [C-3-1] DOIT continuer à fournir des sorties de position GPS/GNSS normales lors d'un appel téléphonique d'urgence.
  • [C-3-2] DOIT indiquer les mesures GNSS de toutes les constellations suivies (comme indiqué dans les messages GnssStatus), à l'exception de SBAS.
  • [C-3-3] DOIT indiquer l'AGC et la fréquence de mesure GNSS.
  • [C-3-4] DOIT indiquer toutes les estimations de précision (y compris la direction, la vitesse et la verticale) pour chaque position GPS/GNSS.

Si les implémentations d'appareils incluent un récepteur GPS/GNSS et signalent la fonctionnalité aux applications via le flag de fonctionnalité android.hardware.location.gps, et que l'API de test LocationManager.getGnssYearOfHardware() indique l'année "2018" ou une année ultérieure, elles:

  • [C-4-1] DOIT continuer à fournir des sorties GPS/GNSS normales aux applications lors d'un appel de session d'urgence déclenché par le réseau basé sur une station mobile.
  • [C-4-2] DOIT signaler les positions et les mesures aux API du fournisseur de position GNSS.

7.3.4. Gyroscope

Implémentations de l'appareil:

  • DOIT inclure un gyroscope (capteur de changement angulaire).
  • NE DOIT PAS inclure de capteur de gyroscope, sauf si un accéléromètre à trois axes est également inclus.

Si les implémentations d'appareils incluent un gyroscope, elles:

  • [C-1-1] DOIT pouvoir signaler des événements jusqu'à une fréquence d'au moins 50 Hz.
  • [C-1-2] Vous DEVEZ implémenter le capteur TYPE_GYROSCOPE et DEVREZ également implémenter le capteur TYPE_GYROSCOPE_UNCALIBRATED.
  • [C-1-3] DOIT être capable de mesurer les changements d'orientation jusqu'à 1 000 degrés par seconde.
  • [C-1-4] DOIT avoir une résolution de 12 bits ou plus et DEVRAIT avoir une résolution de 16 bits ou plus.
  • [C-1-5] DOIT être compensé en température.
  • [C-1-6] DOIT être calibré et compensé pendant son utilisation, et conserver les paramètres de compensation entre les redémarrages de l'appareil.
  • [C-1-7] La variance ne doit pas dépasser 1e-7 rad² / s² par Hz (variance par Hz, ou rad² / s). La variance peut varier avec le taux d'échantillonnage, mais elle DOIT être limitée par cette valeur. En d'autres termes, si vous mesurez la variance du gyro à un taux d'échantillonnage de 1 Hz, elle NE DOIT PAS dépasser 1e-7 rad^2/s^2.
  • [SR] Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur SENSOR_TYPE_GYROSCOPE_UNCALIBRATED sur les appareils Android existants et nouveaux.
  • [SR] Nous vous recommandons vivement de vous assurer que l'erreur de calibrage est inférieure à 0,01 rad/s lorsque l'appareil est à l'arrêt à température ambiante.
  • DOIT signaler les événements jusqu'à au moins 200 Hz.

Si les implémentations de l'appareil incluent un gyroscope, un accéléromètre et un magnétomètre:

  • [C-2-1] DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR.

Si les implémentations de l'appareil incluent un gyroscope et un accéléromètre:

  • [C-3-1] Vous DEVEZ implémenter les capteurs composites TYPE_GRAVITY et TYPE_LINEAR_ACCELERATION.
  • [SR] Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur TYPE_GAME_ROTATION_VECTOR sur les appareils Android existants et nouveaux.
  • DOIT implémenter le capteur composite TYPE_GAME_ROTATION_VECTOR.

7.3.5. Le baromètre

  • Les implémentations d'appareils DOIVENT inclure un baromètre (capteur de pression de l'air ambiant).

Si les implémentations d'appareils incluent un baromètre, elles:

  • [C-1-1] DOIT implémenter et signaler le capteur TYPE_PRESSURE.
  • [C-1-2] DOIT être en mesure de diffuser des événements à 5 Hz ou plus.
  • [C-1-3] DOIT être compensé en température.
  • [SR] Il est vivement recommandé de pouvoir enregistrer des mesures de pression comprises entre 300 hPa et 1 100 hPa.
  • DOIT avoir une précision absolue de 1 hPa.
  • DOIT avoir une précision relative de 0,12 hPa sur une plage de 20 hPa (équivalent à une précision d'environ 1 m sur une variation d'environ 200 m au niveau de la mer).

7.3.6. Thermomètre

Implémentations de l'appareil: * POURRA inclure un thermomètre ambiant (capteur de température). * Peut inclure un capteur de température du processeur, mais NE DOIT PAS.

Si les implémentations d'appareils incluent un thermomètre ambiant (capteur de température), elles:

  • [C-1-1] DOIT être défini comme SENSOR_TYPE_AMBIENT_TEMPERATURE et DOIT mesurer la température ambiante (pièce/habitacle du véhicule) à partir de laquelle l'utilisateur interagit avec l'appareil en degrés Celsius.
  • [C-1-2] DOIT être défini comme SENSOR_TYPE_TEMPERATURE.
  • [C-1-3] DOIT mesurer la température du processeur de l'appareil.
  • [C-1-4] NE DOIT PAS mesurer d'autre température.

Notez que le type de capteur SENSOR_TYPE_TEMPERATURE a été abandonné dans Android 4.0.

7.3.7. Photomètre

  • Les implémentations d'appareils PEUVENT inclure un photomètre (capteur de luminosité ambiante).

7.3.8. Capteur de proximité

  • Les implémentations d'appareils PEUVENT inclure un capteur de proximité.

Si les implémentations d'appareils incluent un capteur de proximité, elles:

  • [C-1-1] DOIT mesurer la proximité d'un objet dans la même direction que l'écran. Autrement dit, le capteur de proximité DOIT être orienté pour détecter les objets proches de l'écran, car l'objectif principal de ce type de capteur est de détecter un téléphone utilisé par l'utilisateur. Si les implémentations d'appareils incluent un capteur de proximité avec une autre orientation, il NE DOIT PAS être accessible via cette API.
  • [C-1-2] Doit avoir une précision d'au moins 1 bit.

7.3.9. Capteurs haute fidélité

Si les implémentations d'appareils incluent un ensemble de capteurs de meilleure qualité, comme défini dans cette section, et les mettent à la disposition d'applications tierces, elles:

  • [C-1-1] Vous devez identifier la fonctionnalité via le flag de fonctionnalité android.hardware.sensor.hifi_sensors.

Si les implémentations d'appareils déclarent android.hardware.sensor.hifi_sensors, elles:

  • [C-2-1] DOIT comporter un capteur TYPE_ACCELEROMETER qui:

    • Doit avoir une plage de mesure d'au moins -8 g à +8 g, et DEVRAIT avoir une plage de mesure d'au moins -16 g à +16 g.
    • DOIT avoir une résolution de mesure d'au moins 2 048 LSB/g.
    • Doit avoir une fréquence de mesure minimale de 12,5 Hz ou moins.
    • DOIT avoir une fréquence de mesure maximale de 400 Hz ou plus ; DOIT prendre en charge le RATE_VERY_FAST SensorDirectChannel.
    • Le bruit de mesure doit être inférieur à 400 μg/√Hz.
    • DOIT implémenter une forme de ce capteur sans réveil avec une capacité de mise en mémoire tampon d'au moins 3 000 événements de capteur.
    • La consommation d'énergie de la mise en lot doit être inférieure ou égale à 3 mW.
    • [C-SR] Il est FORTEMENT RECOMMANDÉ d'avoir une bande passante de mesure de 3 dB d'au moins 80% de la fréquence de Nyquist et un spectre de bruit blanc dans cette bande passante.
    • L'accélération doit être inférieure à 30 μg √Hz, testée à température ambiante.
    • Le changement de biais par rapport à la température doit être ≤ +/- 1 mg/°C.
    • La non-linéarité de la ligne d'ajustement doit être inférieure ou égale à 0,5%, et la variation de la sensibilité en fonction de la température doit être inférieure ou égale à 0,03%/°C.
    • DOIT avoir une sensibilité croisée de moins de 2,5 % et une variation de la sensibilité croisée de moins de 0,2% dans la plage de température de fonctionnement de l'appareil.

  • [C-2-2] DOIT avoir un TYPE_ACCELEROMETER_UNCALIBRATED avec les mêmes exigences de qualité que TYPE_ACCELEROMETER.

  • [C-2-3] DOIT comporter un capteur TYPE_GYROSCOPE qui:

    • DOIT avoir une plage de mesure d'au moins -1 000 et +1 000 dps.
    • Doit avoir une résolution de mesure d'au moins 16 LSB/dps.
    • Doit avoir une fréquence de mesure minimale de 12,5 Hz ou moins.
    • DOIT avoir une fréquence de mesure maximale de 400 Hz ou plus ; DOIT prendre en charge le RATE_VERY_FAST SensorDirectChannel.
    • DOIT avoir un bruit de mesure inférieur à 0,014°/s/√Hz.
    • [C-SR] Il est FORTEMENT RECOMMANDÉ d'avoir une bande passante de mesure de 3 dB d'au moins 80% de la fréquence de Nyquist et un spectre de bruit blanc dans cette bande passante.
    • La marche aléatoire de la fréquence doit être inférieure à 0,001 °/s √Hz, testée à température ambiante.
    • Le biais doit changer de ≤ +/- 0,05 °/ s / °C en fonction de la température.
    • La sensibilité doit changer de ≤ 0,02% / °C en fonction de la température.
    • La non-linéarité de la droite d'ajustement optimal doit être inférieure ou égale à 0,2%.
    • DOIT avoir une densité de bruit de ≤ 0,007 °/s/√Hz.
    • L'erreur d'étalonnage doit être inférieure à 0,002 rad/s dans la plage de température de 10 à 40 °C lorsque l'appareil est à l'arrêt.
    • La sensibilité à la gravité doit être inférieure à 0,1 °/s/g.
    • La sensibilité croisée doit être inférieure à 4 % et la variation de la sensibilité croisée inférieure à 0,3% dans la plage de température de fonctionnement de l'appareil.

  • [C-2-4] DOIT avoir un TYPE_GYROSCOPE_UNCALIBRATED avec les mêmes exigences de qualité que TYPE_GYROSCOPE.

  • [C-2-5] DOIT comporter un capteur TYPE_GEOMAGNETIC_FIELD qui:

    • DOIT avoir une plage de mesure d'au moins -900 et +900 μT.
    • Doit avoir une résolution de mesure d'au moins 5 LSB/uT.
    • Doit avoir une fréquence de mesure minimale de 5 Hz ou moins.
    • DOIT avoir une fréquence de mesure maximale de 50 Hz ou plus.
    • Le bruit de mesure doit être inférieur à 0,5 uT.

  • [C-2-6] DOIT disposer d'un TYPE_MAGNETIC_FIELD_UNCALIBRATED avec les mêmes exigences de qualité que TYPE_GEOMAGNETIC_FIELD, et en outre:

    • DOIT implémenter une forme non réveillée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 600 événements de capteur.
    • [C-SR] Il est FORTEMENT RECOMMANDÉ d'avoir un spectre de bruit blanc compris entre 1 Hz et au moins 10 Hz lorsque la fréquence de rapport est de 50 Hz ou plus.

  • [C-2-7] DOIT comporter un capteur TYPE_PRESSURE qui:

    • DOIT avoir une plage de mesure d'au moins 300 et 1 100 hPa.
    • DOIT avoir une résolution de mesure d'au moins 80 LSB/hPa.
    • Doit avoir une fréquence de mesure minimale de 1 Hz ou moins.
    • DOIT avoir une fréquence de mesure maximale de 10 Hz ou plus.
    • Le bruit de mesure doit être inférieur à 2 Pa/√Hz.
    • DOIT implémenter une forme non réveillée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 300 événements de capteur.
    • La consommation d'énergie de la mise en lot doit être inférieure ou égale à 2 mW.
  • [C-2-8] DOIT comporter un capteur TYPE_GAME_ROTATION_VECTOR qui :
    • DOIT implémenter une forme non réveillée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 300 événements de capteur.
    • La consommation d'énergie de la mise en lot doit être inférieure ou égale à 4 mW.
  • [C-2-9] DOIT comporter un capteur TYPE_SIGNIFICANT_MOTION qui :
    • DOIT avoir une consommation d'énergie inférieure à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsqu'il est en mouvement.
  • [C-2-10] DOIT comporter un capteur TYPE_STEP_DETECTOR qui :
    • DOIT implémenter une forme non réveillée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 100 événements de capteur.
    • DOIT avoir une consommation d'énergie inférieure à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsqu'il est en mouvement.
    • La consommation d'énergie de la mise en lot doit être inférieure ou égale à 4 mW.
  • [C-2-11] DOIT comporter un capteur TYPE_STEP_COUNTER qui :
    • DOIT avoir une consommation d'énergie inférieure à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsqu'il est en mouvement.
  • [C-2-12] DOIT comporter un capteur TILT_DETECTOR qui :
    • DOIT avoir une consommation d'énergie inférieure à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsqu'il est en mouvement.
  • [C-2-13] L'horodatage de l'événement physique identique signalé par l'accéléromètre, le gyroscope et le magnétomètre DOIT être compris dans une tolérance de 2, 5 millisecondes. L'horodatage de l'événement physique identique signalé par l'accéléromètre et le gyroscope DOIT être compris dans une tolérance de 0,25 milliseconde.
  • [C-2-14] Les codes temporels des événements du capteur gyroscopique doivent être basés sur la même base temporelle que le sous-système de la caméra et présenter une erreur inférieure à 1 milliseconde.
  • [C-2-15] DOIT envoyer des échantillons aux applications dans les cinq millisecondes à compter du moment où les données sont disponibles sur l'un des capteurs physiques ci-dessus.
  • [C-2-16] La consommation d'énergie ne doit PAS dépasser 0,5 mW lorsque l'appareil est statique et 2,0 mW lorsque l'appareil est en mouvement lorsque l'une des combinaisons suivantes de capteurs est activée :
    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS
  • [C-2-17] Un capteur TYPE_PROXIMITY peut être présent, mais s'il l'est, il doit avoir une capacité de mémoire tampon minimale de 100 événements de capteur.

Notez que toutes les exigences de consommation d'énergie de cette section n'incluent pas la consommation d'énergie du processeur d'application. Il comprend la puissance consommée par l'ensemble de la chaîne de capteurs (capteur, circuits de support, système de traitement de capteur dédié, etc.).

Si les implémentations d'appareils incluent la prise en charge directe des capteurs, elles:

  • [C-3-1] DOIT déclarer correctement la prise en charge des types de canaux directs et du niveau des taux de rapports directs via les API isDirectChannelTypeSupported et getHighestDirectReportRateLevel.
  • [C-3-2] DOIT prendre en charge au moins l'un des deux types de canaux directs pour les capteurs pour tous les capteurs qui déclarent prendre en charge le canal direct pour les capteurs.
  • DOIT prendre en charge la création de rapports sur les événements via le canal direct du capteur pour le capteur principal (variante sans réveil) des types suivants :
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Capteurs biométriques

7.3.10.1. Lecteurs d'empreinte digitale

Si les implémentations de l'appareil incluent un écran de verrouillage sécurisé, elles:

  • DOIT inclure un lecteur d'empreinte digitale.

Si les implémentations de l'appareil incluent un lecteur d'empreinte digitale et le mettent à la disposition des applications tierces, elles:

  • [C-1-1] DOIT déclarer la prise en charge de la fonctionnalité android.hardware.fingerprint.
  • [C-1-2] DOIT implémenter entièrement l'API correspondante, comme décrit dans la documentation du SDK Android.
  • [C-1-3] Le taux de faux rejets ne doit pas dépasser 0,002%.
  • [SR] Nous vous RECOMMANDONS vivement de ne pas dépasser 7 % de taux d'acceptation des faux et des imposteurs.
  • [C-1-4] DOIT indiquer que ce mode peut être moins sécurisé qu'un code, un schéma ou un mot de passe sécurisés, et énumérer clairement les risques de l'activer si les taux d'acceptation des attaques par hameçonnage et par usurpation d'identité sont supérieurs à 7%.
  • [C-1-5] Le système doit limiter les tentatives pendant au moins 30 secondes après cinq tentatives incorrectes de validation de l'empreinte digitale.
  • [C-1-6] DOIT disposer d'une implémentation de keystore basée sur le matériel et effectuer la mise en correspondance des empreintes digitales dans un environnement d'exécution sécurisé (TEE) ou sur une puce avec un canal sécurisé vers le TEE.
  • [C-1-7] Toutes les données d'empreinte identifiables DOIVENT être chiffrées et authentifiées de manière cryptographique afin qu'elles ne puissent pas être acquises, lues ni modifiées en dehors du TEE, ou être stockées sur une puce avec un canal sécurisé vers le TEE, comme indiqué dans les consignes d'implémentation sur le site du projet Android Open Source.
  • [C-1-8] DOIT empêcher l'ajout d'une empreinte digitale sans d'abord établir une chaîne de confiance en demandant à l'utilisateur de confirmer des identifiants d'appareil existants ou d'en ajouter de nouveaux (code/schéma/mot de passe) sécurisés par le TEE. L'implémentation du projet Android Open Source fournit le mécanisme dans le framework pour ce faire.
  • [C-1-9] NE DOIT PAS permettre aux applications tierces de distinguer les empreintes individuelles.
  • [C-1-10] DOIT respecter l'indicateur DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
  • [C-1-11] Lors de la mise à niveau à partir d'une version antérieure à Android 6.0, les données d'empreinte digitale doivent être migrées de manière sécurisée pour répondre aux exigences ci-dessus ou supprimées.
  • [C-1-12] Vous DEVEZ supprimer complètement toutes les données d'empreinte digitale identifiables d'un utilisateur lorsque son compte est supprimé (y compris via une réinitialisation d'usine).
  • [C-1-13] Le processeur d'application NE DOIT PAS autoriser l'accès non chiffré aux données d'empreinte identifiables ni à toute donnée dérivée de celles-ci (telles que les représentations vectorielles continues).
  • [SR] Il est vivement recommandé que le taux de faux rejet soit inférieur à 10%, mesuré sur l'appareil.
  • [SR] Il est FORTEMENT RECOMMANDÉ de définir une latence inférieure à une seconde, mesurée à partir du moment où le lecteur d'empreinte digitale est touché jusqu'au déverrouillage de l'écran, pour un doigt enregistré.
  • DOIT utiliser l'icône d'empreinte digitale Android fournie dans le projet Android Open Source.
7.3.10.2. Autres capteurs biométriques

Si les implémentations d'appareils incluent un ou plusieurs capteurs biométriques autres que les lecteurs d'empreinte digitale et les mettent à la disposition d'applications tierces, elles:

  • [C-1-1] Le taux de faux rejets ne doit pas dépasser 0,002%.
  • [C-SR] Nous vous RECOMMANDONS vivement de ne pas dépasser 7 % de taux d'acceptation des attaques par hameçonnage et usurpation d'identité.
  • [C-1-2] DOIT indiquer que ce mode peut être moins sécurisé qu'un code, un schéma ou un mot de passe sécurisés, et énumérer clairement les risques de l'activer si les taux d'acceptation des usurpations d'identité et des accès frauduleux sont supérieurs à 7%.
  • [C-1-3] Le système doit limiter les tentatives pendant au moins 30 secondes après cinq tentatives incorrectes pour la validation biométrique. Une tentative incorrecte est une tentative avec une qualité de capture adéquate (ACQUIRED_GOOD) qui ne correspond pas à une empreinte biométrique enregistrée.
  • [C-1-4] DOIT disposer d'une implémentation de keystore basée sur du matériel et effectuer la mise en correspondance biométrique dans un TEE ou sur une puce avec un canal sécurisé vers le TEE.
  • [C-1-5] Toutes les données identifiables doivent être chiffrées et authentifiées de manière cryptographique afin qu'elles ne puissent pas être acquises, lues ni modifiées en dehors du TEE, ou comporter une puce avec un canal sécurisé vers le TEE, comme indiqué dans les consignes d'implémentation sur le site du projet Android Open Source.
  • [C-1-6] DOIT empêcher l'ajout de nouvelles données biométriques sans d'abord établir une chaîne de confiance en demandant à l'utilisateur de confirmer des identifiants d'appareil existants ou d'en ajouter de nouveaux (code/schéma/mot de passe) sécurisés par le TEE. L'implémentation du projet Android Open Source fournit le mécanisme dans le framework pour ce faire.
  • [C-1-7] Les applications tierces NE DOIVENT PAS être autorisées à distinguer les enregistrements biométriques.
  • [C-1-8] DOIT respecter l'indicateur individuel pour cette empreinte biométrique (par exemple, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE ou DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
  • [C-1-9] Vous DEVEZ supprimer complètement toutes les données biométriques identifiables d'un utilisateur lorsque son compte est supprimé (y compris via une réinitialisation d'usine).
  • [C-1-10] Le processeur d'applications ne doit PAS autoriser l'accès non chiffré aux données biométriques identifiables ni à toute donnée dérivée de celles-ci (telles que les représentations vectorielles continues) en dehors du contexte du TEE.
  • [C-SR] Il est vivement recommandé que le taux de faux rejet soit inférieur à 10%, mesuré sur l'appareil.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de définir une latence inférieure à une seconde, mesurée à partir du moment où l'identifiant biométrique est détecté jusqu'au déverrouillage de l'écran, pour chaque identifiant biométrique enregistré.

7.3.11. Capteurs Android Automotive uniquement

Les capteurs spécifiques au secteur automobile sont définis dans le fichier android.car.CarSensorManager API.

7.3.11.1. Engrenage actuel

Pour connaître les exigences spécifiques à l'appareil, consultez la section 2.5.1.

7.3.11.2. Mode Jour/Nuit

Pour connaître les exigences spécifiques à l'appareil, consultez la section 2.5.1.

7.3.11.3. État de la conduite

Cette exigence est obsolète.

7.3.11.4. Vitesse de rotation des roues

Pour connaître les exigences spécifiques à l'appareil, consultez la section 2.5.1.

7.3.11.5. Frein à main

Pour connaître les exigences spécifiques à l'appareil, consultez la section 2.5.1.

7.3.12. Capteur de position

Implémentations de l'appareil:

  • Peut être compatible avec un capteur de position à six degrés de liberté.

Si les implémentations d'appareils sont compatibles avec un capteur de position à six degrés de liberté, elles:

  • [C-1-1] DOIT implémenter et signaler le capteur TYPE_POSE_6DOF.
  • [C-1-2] DOIT être plus précis que le vecteur de rotation seul.

7.4. Connectivité des données

7.4.1. Téléphonie

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

  • Android peut être utilisé sur des appareils qui n'incluent pas de matériel de téléphonie. Autrement dit, Android est compatible avec des appareils autres que des téléphones.

Si les implémentations d'appareils incluent la téléphonie GSM ou CDMA, elles:

  • [C-1-1] DOIT déclarer l'option de fonctionnalité android.hardware.telephony et les autres options de sous-fonctionnalités en fonction de la technologie.
  • [C-1-2] DOIT implémenter une compatibilité complète avec l'API de cette technologie.

Si les implémentations d'appareils n'incluent pas de matériel de téléphonie, elles:

  • [C-2-1] Vous DEVEZ implémenter l'ensemble des API en tant que no-ops.
7.4.1.1. Compatibilité du blocage de numéros

Si les implémentations d'appareils signalent android.hardware.telephony feature, elles:

  • [C-1-1] DOIT inclure la fonctionnalité de blocage des numéros
  • [C-1-2] DOIT implémenter entièrement BlockedNumberContract et l'API correspondante, comme décrit dans la documentation du SDK.
  • [C-1-3] DOIT bloquer tous les appels et messages provenant d'un numéro de téléphone dans "BlockedNumberProvider" sans aucune interaction avec les applications. La seule exception est lorsque le blocage de numéro est temporairement levé, comme décrit dans la documentation du SDK.
  • [C-1-4] NE DOIT PAS écrire au fournisseur de journaux d'appels de la plate-forme pour un appel bloqué.
  • [C-1-5] NE DOIT PAS écrire au fournisseur de téléphonie pour un message bloqué.
  • [C-1-6] DOIT implémenter une UI de gestion des numéros bloqués, qui est ouverte avec l'intent renvoyé par la méthode TelecomManager.createManageBlockedNumbersIntent().
  • [C-1-7] Les utilisateurs secondaires NE DOIVENT PAS pouvoir afficher ni modifier les numéros bloqués sur l'appareil, car la plate-forme Android suppose que l'utilisateur principal a le contrôle total des services de téléphonie, une seule instance, sur l'appareil. L'interface utilisateur liée au blocage DOIT être masquée pour les utilisateurs secondaires, et la liste de blocage DOIT toujours être respectée.
  • Les numéros bloqués devraient être migrés vers le fournisseur lorsqu'un appareil passe à Android 7.0.
7.4.1.2. API Telecom

Si les implémentations d'appareils signalent android.hardware.telephony, elles:

  • [C-1-1] DOIT prendre en charge les API ConnectionService décrites dans le SDK.
  • [C-1-2] DOIT afficher un nouvel appel entrant et fournir à l'utilisateur la possibilité d'accepter ou de refuser l'appel entrant lorsque l'utilisateur est en ligne avec une application tierce qui n'est pas compatible avec la fonctionnalité de mise en attente spécifiée via CAPABILITY_SUPPORT_HOLD.

  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'informer l'utilisateur que répondre à un appel entrant mettra fin à un appel en cours.

    L'implémentation AOSP répond à ces exigences par une notification d'avertissement indiquant à l'utilisateur que répondre à un appel entrant entraînera la fin de l'autre appel.

  • [C-SR] Nous vous RECOMMANDONS vivement de précharger l'application de numérotation par défaut qui affiche une entrée de journal des appels et le nom d'une application tierce dans son journal des appels lorsque l'application tierce définit la clé d'extras EXTRA_LOG_SELF_MANAGED_CALLS sur son PhoneAccount sur true.

  • [C-SR] Il est FORTEMENT RECOMMANDÉ de gérer les événements KEYCODE_MEDIA_PLAY_PAUSE et KEYCODE_HEADSETHOOK du casque audio pour les API android.telecom comme suit :
    • Appelez Connection.onDisconnect() lorsqu'un appui bref sur l'événement de touche est détecté pendant un appel en cours.
    • Appelez Connection.onAnswer() lorsqu'un appui bref sur l'événement de touche est détecté lors d'un appel entrant.
    • Appelez Connection.onReject() lorsqu'un appui prolongé sur l'événement de touche est détecté lors d'un appel entrant.
    • Activez/Désactivez le son de CallAudioState.

7.4.2. IEEE 802.11 (Wi-Fi)

Implémentations de l'appareil:

  • DOIT inclure la prise en charge d'une ou de plusieurs formes de 802.11.

Si les implémentations d'appareils sont compatibles avec la norme 802.11 et exposent la fonctionnalité à une application tierce, elles:

  • [C-1-1] DOIT implémenter l'API Android correspondante.
  • [C-1-2] DOIT signaler l'indicateur de fonctionnalité matérielle android.hardware.wifi.
  • [C-1-3] Vous DEVEZ implémenter l'API multicast comme décrit dans la documentation du SDK.
  • [C-1-4] DOIT prendre en charge le DNS multicast (mDNS) et NE DOIT PAS filtrer les paquets mDNS (224.0.0.251) à tout moment de l'opération, y compris :
    • Même lorsque l'écran n'est pas actif.
    • Pour les implémentations d'appareils Android TV, même en mode veille.
  • [C-1-5] NE DOIT PAS traiter l'appel de la méthode d'API WifiManager.enableNetwork() comme une indication suffisante pour changer le Network actuellement actif, qui est utilisé par défaut pour le trafic de l'application et est renvoyé par les méthodes d'API ConnectivityManager telles que getActiveNetwork et registerDefaultNetworkCallback. En d'autres termes, ils ne peuvent désactiver l'accès à Internet fourni par un autre fournisseur de réseau (par exemple, les données mobiles) que s'ils vérifient que le réseau Wi-Fi fournit un accès à Internet.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ, lorsque la méthode d'API ConnectivityManager.reportNetworkConnectivity() est appelée, de réévaluer l'accès à Internet sur le Network et, une fois que l'évaluation a déterminé que le Network actuel ne fournit plus d'accès à Internet, de passer à un autre réseau disponible (par exemple, les données mobiles) qui fournit un accès à Internet.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de randomiser l'adresse MAC source et le numéro de séquence des trames de requête de sonde, une fois au début de chaque analyse, lorsque l'appareil STA est déconnecté.
    • Chaque groupe de trames de requête d'exploration comprenant une analyse doit utiliser une adresse MAC cohérente (L'adresse MAC NE DOIT PAS être générée de manière aléatoire à mi-chemin d'une analyse).
    • Le numéro de séquence de la requête de sonde doit s'itérer normalement (séquentiellement) entre les requêtes de sonde d'une analyse.
    • Le numéro de séquence de la requête de sonde doit être aléatoire entre la dernière requête de sonde d'une analyse et la première requête de sonde de l'analyse suivante.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ, lorsque l'appareil STA est déconnecté, de n'autoriser que les éléments suivants dans les trames de requête de sonde :
    • Ensemble de paramètres SSID (0)
    • Ensemble de paramètres DS (3)

Si les implémentations d'appareils sont compatibles avec le Wi-Fi et l'utilisent pour la recherche de position, elles:

7.4.2.1. Wi-Fi Direct

Implémentations de l'appareil:

  • DOIT inclure la prise en charge de Wi-Fi Direct (Wi-Fi peer-to-peer).

Si les implémentations d'appareils sont compatibles avec Wi-Fi Direct, elles:

  • [C-1-1] DOIT implémenter l'API Android correspondante, comme décrit dans la documentation du SDK.
  • [C-1-2] DOIT signaler la fonctionnalité matérielle android.hardware.wifi.direct.
  • [C-1-3] DOIT être compatible avec le fonctionnement normal du Wi-Fi.
  • [C-1-4] DOIT prendre en charge les opérations Wi-Fi et Wi-Fi Direct simultanément.

Implémentations de l'appareil:

Si les implémentations de l'appareil prennent en charge TDLS et que TDLS est activé par l'API WiFiManager, elles:

  • [C-1-1] DOIT déclarer la prise en charge de TDLS via WifiManager.isTdlsSupported.
  • Vous DEVEZ utiliser TDLS uniquement lorsque c'est possible ET avantageux.
  • DOIT avoir une heuristique et NE PAS utiliser TDLS lorsque ses performances peuvent être inférieures à celles du point d'accès Wi-Fi.
7.4.2.3. Wi-Fi Aware

Implémentations de l'appareil:

Si les implémentations de l'appareil sont compatibles avec Wi-Fi Aware et exposent la fonctionnalité aux applications tierces, elles:

  • [C-1-1] Vous DEVEZ implémenter les API WifiAwareManager comme décrit dans la documentation du SDK.
  • [C-1-2] Vous DEVEZ déclarer l'option de fonctionnalité android.hardware.wifi.aware.
  • [C-1-3] DOIT prendre en charge les opérations Wi-Fi et Wi-Fi Aware simultanément.
  • [C-1-4] L'adresse de l'interface de gestion Wi-Fi Aware DOIT être générée de manière aléatoire à des intervalles de 30 minutes maximum et chaque fois que Wi-Fi Aware est activé.

Si les implémentations de l'appareil sont compatibles avec Wi-Fi Aware et Wi-Fi Location, comme décrit dans la section 7.4.2.5, et qu'elles exposent ces fonctionnalités aux applications tierces, elles:

7.4.2.4. Wi-Fi Passpoint

Implémentations de l'appareil:

Si les implémentations d'appareils sont compatibles avec Wi-Fi Passpoint, elles:

  • [C-1-1] DOIT implémenter les API WifiManager liées à Passpoint, comme décrit dans la documentation du SDK.
  • [C-1-2] DOIT être compatible avec la norme IEEE 802.11u, en particulier en ce qui concerne la découverte et la sélection de réseaux, tels que le service d'annonces génériques (GAS, Generic Advertisement Service) et le protocole ANQP (Access Network Query Protocol).

À l'inverse, si les implémentations d'appareils ne sont pas compatibles avec Wi-Fi Passpoint:

  • [C-2-1] L'implémentation des API WifiManager liées à Passpoint DOIT générer une UnsupportedOperationException.
7.4.2.5. Position Wi-Fi (délai aller-retour Wi-Fi - RTT)

Implémentations de l'appareil:

Si les implémentations de l'appareil sont compatibles avec la position Wi-Fi et exposent cette fonctionnalité aux applications tierces, elles:

  • [C-1-1] Vous DEVEZ implémenter les API WifiRttManager comme décrit dans la documentation du SDK.
  • [C-1-2] Vous DEVEZ déclarer l'option de fonctionnalité android.hardware.wifi.rtt.
  • [C-1-3] L'adresse MAC source doit être RANDOMisée pour chaque rafale RTT exécutée lorsque l'interface Wi-Fi sur laquelle le RTT est exécuté n'est pas associée à un point d'accès.

7.4.3. Bluetooth

Si les implémentations de l'appareil sont compatibles avec le profil Bluetooth Audio, elles:

  • DOIT être compatible avec les codecs audio avancés et les codecs audio Bluetooth (par exemple, LDAC).

Si les implémentations de l'appareil sont compatibles avec HFP, A2DP et AVRCP:

  • DOIT être compatible avec au moins cinq appareils connectés au total.

Si les implémentations d'appareils déclarent la fonctionnalité android.hardware.vr.high_performance, elles:

  • [C-1-1] DOIT être compatible avec Bluetooth 4.2 et l'extension de la longueur des données Bluetooth LE.

Android est compatible avec le Bluetooth et le Bluetooth à basse consommation.

Si les implémentations de l'appareil prennent en charge le Bluetooth et le Bluetooth à basse consommation:

  • [C-2-1] Vous DEVEZ déclarer les fonctionnalités de plate-forme pertinentes (android.hardware.bluetooth et android.hardware.bluetooth_le respectivement) et implémenter les API de la plate-forme.
  • DOIT implémenter les profils Bluetooth pertinents tels que A2DP, AVRCP, OBEX, HFP, etc., en fonction de l'appareil.

Si les implémentations de l'appareil prennent en charge le Bluetooth à basse consommation, elles:

  • [C-3-1] DOIT déclarer la fonctionnalité matérielle android.hardware.bluetooth_le.
  • [C-3-2] DOIT activer les API Bluetooth basées sur le GATT (Generic Attribute Profile) comme décrit dans la documentation du SDK et dans android.bluetooth.
  • [C-3-3] DOIT indiquer la valeur correcte pour BluetoothAdapter.isOffloadedFilteringSupported() afin d'indiquer si la logique de filtrage des classes d'API ScanFilter est implémentée.
  • [C-3-4] DOIT indiquer la valeur correcte pour BluetoothAdapter.isMultipleAdvertisementSupported() afin de savoir si la publicité à faible consommation d'énergie est prise en charge.
  • DOIT prendre en charge le transfert de la logique de filtrage vers le chipset Bluetooth lors de l'implémentation de l'API ScanFilter.
  • DOIT prendre en charge le transfert de l'analyse groupée vers le chipset Bluetooth.

  • DOIT être compatible avec les annonces multiples avec au moins quatre emplacements.

  • [SR] Nous vous RECOMMANDONS vivement d'implémenter un délai d'inactivité de l'adresse privée résoluble (RPA) de 15 minutes maximum et de faire tourner l'adresse à l'expiration du délai pour protéger la confidentialité des utilisateurs.

Si les implémentations d'appareils sont compatibles avec le Bluetooth LE et utilisent le Bluetooth LE pour la détection de position, elles:

  • [C-4-1] DOIT fournir une affordance utilisateur pour activer/désactiver la valeur lue via l'API système BluetoothAdapter.isBleScanAlwaysAvailable().

7.4.4. Communication en champ proche

Implémentations de l'appareil:

  • DOIT inclure un émetteur-récepteur et le matériel associé pour la technologie NFC (communication en champ proche).
  • [C-0-1] Les API android.nfc.NdefMessage et android.nfc.NdefRecord DOIVENT être implémentées, même si elles n'incluent pas la compatibilité avec la technologie NFC ni ne déclarent la fonctionnalité android.hardware.nfc, car les classes représentent un format de représentation des données indépendant du protocole.

Si les implémentations d'appareils incluent du matériel NFC et prévoient de le mettre à la disposition d'applications tierces, elles doivent:

  • [C-1-1] Vous DEVEZ enregistrer la fonctionnalité android.hardware.nfc à partir de la méthode android.content.pm.PackageManager.hasSystemFeature().
  • DOIT être capable de lire et d'écrire des messages NDEF via les normes NFC suivantes:
  • [C-1-2] DOIT être capable de fonctionner comme lecteur/enregistreur NFC Forum (tel que défini par la spécification technique NFC Forum NFCForum-TS-DigitalProtocol-1.0) via les normes NFC suivantes :
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS X 6319-4)
    • IsoDep (ISO 14443-4)
    • Types de tags NFC Forum 1, 2, 3, 4 et 5 (définis par le forum NFC)

  • [SR] Il est fortement recommandé de pouvoir lire et écrire des messages NDEF ainsi que des données brutes via les normes NFC suivantes. Notez que les normes NFC sont définies comme "FORTEMENT RECOMMANDÉES", mais que la définition de la compatibilité pour une future version prévoit de les remplacer par "OBLIGATOIRE". Ces normes sont facultatives dans cette version, mais elles seront obligatoires dans les versions ultérieures. Nous vous recommandons vivement de respecter ces exigences dès maintenant sur les appareils existants et nouveaux exécutant cette version d'Android afin qu'ils puissent passer aux futures versions de la plate-forme.

  • [C-1-3] DOIT être capable de transmettre et de recevoir des données via les normes et protocoles peer-to-peer suivants:

    • ISO 18092
    • LLCP 1.2 (défini par le NFC Forum)
    • SDP 1.0 (défini par le forum NFC)
    • Protocole NDEF Push
    • SNEP 1.0 (défini par le forum NFC)
  • [C-1-4] DOIT être compatible avec Android Beam et DOIT activer Android Beam par défaut.
  • [C-1-5] L'appareil DOIT pouvoir envoyer et recevoir des contenus à l'aide d'Android Beam lorsque cette fonctionnalité est activée ou qu'un autre mode P2P NFC propriétaire est activé.
  • [C-1-6] 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 d'Android Beam dans les paramètres NE DOIT PAS désactiver l'envoi du message NDEF entrant.
  • [C-1-7] DOIT respecter l'intent android.settings.NFCSHARING_SETTINGS pour afficher les paramètres de partage NFC.
  • [C-1-8] Le serveur NPP doit être implémenté. Les messages reçus par le serveur NPP doivent être traités de la même manière que le serveur par défaut SNEP.
  • [C-1-9] DOIT implémenter un client SNEP et tenter d'envoyer un NDEF P2P sortant au serveur SNEP par défaut lorsque la fonctionnalité Android Beam est activée. Si aucun serveur SNEP par défaut n'est trouvé, le client DOIT tenter d'envoyer un message à un serveur NPP.
  • [C-1-10] DOIT autoriser les activités de premier plan à définir le message NDEF P2P sortant à l'aide de android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback et android.nfc.NfcAdapter.enableForegroundNdefPush.
  • DOIT utiliser un geste ou une confirmation à l'écran, comme "Appuyer pour transférer", avant d'envoyer des messages NDEF P2P sortants.
  • [C-1-11] L'appareil DOIT prendre en charge le transfert de connexion NFC vers le Bluetooth lorsque le profil Bluetooth Object Push Profile est pris en charge.
  • [C-1-12] DOIT prendre en charge le transfert de connexion vers le Bluetooth lors de l'utilisation de android.nfc.NfcAdapter.setBeamPushUris, en implémentant les spécifications Connection Handover version 1.2 (Transfert de connexion version 1.2) et Bluetooth Secure Simple Pairing Using NFC version 1.0 (Association simple sécurisée Bluetooth à l'aide de la technologie NFC version 1.0) du NFC Forum. Une telle implémentation DOIT implémenter le service LLCP de transfert avec le nom de service "urn:nfc:sn:handover" pour échanger la requête de transfert/sélectionner les enregistrements via NFC, et DOIT utiliser le profil Bluetooth Object Push Profile pour le transfert de données Bluetooth. Pour des raisons d'ancienneté (pour rester compatible avec les appareils Android 4.1), l'implémentation DOIT toujours accepter les requêtes GET SNEP pour échanger la requête de transfert/sélectionner des enregistrements via NFC. Toutefois, une implémentation elle-même NE DOIT PAS envoyer de requêtes GET SNEP pour effectuer la passation de connexion.
  • [C-1-13] DOIT interroger toutes les technologies compatibles en mode découverte NFC.
  • DOIT être en mode découverte NFC lorsque l'appareil est actif, que l'écran est allumé et que l'écran de verrouillage est déverrouillé.
  • DOIT être en mesure de lire le code-barres et l'URL (si encodés) des produits Thinfilm NFC Barcode.

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

Android est compatible avec le mode NFC Host Card Emulation (HCE).

Si les implémentations d'appareils incluent un chipset de contrôleur NFC compatible avec la technologie HCE (pour NfcA et/ou NfcB) et prennent en charge le routage de l'ID d'application (AID), elles:

  • [C-2-1] DOIT indiquer la constante de fonctionnalité android.hardware.nfc.hce.
  • [C-2-2] DOIT être compatible avec les API NFC HCE telles que définies dans le SDK Android.

Si les implémentations d'appareils incluent un chipset de contrôleur NFC compatible avec la technologie HCE pour NfcF et implémentent la fonctionnalité pour les applications tierces, elles:

  • [C-3-1] DOIT indiquer la constante de fonctionnalité android.hardware.nfc.hcef.
  • [C-3-2] DOIT implémenter les API d'émulation de carte NfcF telles que définies dans le SDK Android.

Si les implémentations d'appareils incluent la compatibilité NFC générale décrite dans cette section et les technologies MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF sur MIFARE Classic) dans le rôle de lecteur/écrivain, elles:

  • [C-4-1] DOIT implémenter les API Android correspondantes, comme indiqué dans la documentation du SDK Android.
  • [C-4-2] DOIT signaler la fonctionnalité com.nxp.mifare à partir de la méthode android.content.pm.PackageManager.hasSystemFeature(). Notez qu'il ne s'agit pas d'une fonctionnalité Android standard et qu'elle n'apparaît donc pas en tant que constante dans la classe android.content.pm.PackageManager.

7.4.5. Capacité réseau minimale

Implémentations de l'appareil:

  • [C-0-1] DOIT 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 transmettre 200 kbit/s ou plus. Voici quelques exemples de technologies qui répondent à cette exigence : EDGE, HSPA, EV-DO, 802.11g, Ethernet et PAN Bluetooth.
  • DOIT également prendre en charge au moins une norme de données sans fil courante, telle que 802.11 (Wi-Fi), lorsqu'une norme de réseau physique (telle qu'Ethernet) est la connexion de données principale.
  • PEUT implémenter plusieurs formes de connectivité de données.
  • [C-0-2] DOIT inclure une pile réseau IPv6 et prendre en charge la communication IPv6 à l'aide des API gérées, telles que java.net.Socket et java.net.URLConnection, ainsi que des API natives, telles que les sockets AF_INET6.
  • [C-0-3] Vous devez activer IPv6 par défaut.
  • DOIT s'assurer que la communication IPv6 est aussi fiable qu'IPv4, par exemple :
    • [C-0-4] Le système DOIT maintenir la connectivité IPv6 en mode veille.
    • [C-0-5] La limitation de débit NE DOIT PAS entraîner la perte de connectivité IPv6 de l'appareil sur un réseau conforme à la norme IPv6 qui utilise des durées de vie RA d'au moins 180 secondes.
  • [C-0-6] DOIT fournir aux applications tierces une connectivité IPv6 directe au réseau lorsqu'elles sont connectées à un réseau IPv6, sans aucune forme de traduction d'adresse ou de port localement sur l'appareil. Les API gérées telles que Socket#getLocalAddress ou Socket#getLocalPort, ainsi que les API NDK telles que getsockname() ou IPV6_PKTINFO DOIVENT renvoyer l'adresse IP et le port réellement utilisés pour envoyer et recevoir des paquets sur le réseau.

Le niveau de compatibilité IPv6 requis dépend du type de réseau, comme indiqué dans les exigences suivantes.

Si les implémentations de l'appareil sont compatibles avec le Wi-Fi, elles:

  • [C-1-1] DOIT être compatible avec le fonctionnement en double pile et en IPv6 uniquement sur le Wi-Fi.

Si les implémentations de l'appareil sont compatibles avec Ethernet, elles:

  • [C-2-1] DOIT prendre en charge l'opération à double pile sur Ethernet.

Si les implémentations de l'appareil sont compatibles avec les données mobiles, elles:

  • DOIT prendre en charge le fonctionnement IPv6 (IPv6 uniquement et éventuellement double pile) sur le réseau mobile.

Si les implémentations d'appareils sont compatibles avec plusieurs types de réseaux (par exemple, Wi-Fi et données mobiles), ils:

  • [C-3-1] L'appareil DOIT simultanément respecter les exigences ci-dessus sur chaque réseau lorsqu'il est connecté simultanément à plusieurs types de réseaux.

7.4.6. Paramètres de synchronisation

Implémentations de l'appareil:

  • [C-0-1] Le paramètre de synchronisation automatique maître doit être activé par défaut pour que la méthode getMasterSyncAutomatically() renvoie "true".

7.4.7. Économiseur de données

Si les implémentations d'appareils incluent une connexion limitée, elles sont:

  • [SR] FORTEMENT RECOMMANDÉ de fournir le mode Économie de données.

Si les implémentations de l'appareil fournissent le mode Économiseur de données, elles:

Si les implémentations de l'appareil ne fournissent pas le mode Économiseur de données, elles:

  • [C-2-1] DOIT renvoyer la valeur RESTRICT_BACKGROUND_STATUS_DISABLED pour ConnectivityManager.getRestrictBackgroundStatus()
  • [C-2-2] NE DOIT PAS diffuser ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.
  • [C-2-3] Une activité doit gérer l'intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, mais elle peut l'implémenter en tant que "no-op".

7.4.8. Composants sécurisés

Si les implémentations d'appareils sont compatibles avec les éléments sécurisés compatibles avec l'API Open Mobile et les mettent à la disposition des applications tierces, elles:

7.5. Caméras

Si les implémentations d'appareils incluent au moins une caméra, elles:

  • [C-1-1] Vous DEVEZ déclarer le commutateur de fonctionnalité android.hardware.camera.any.
  • [C-1-2] Une application doit pouvoir allouer simultanément trois bitmaps RGBA_8888 égaux à la taille des images produites par le capteur d'appareil photo de la plus haute résolution de l'appareil, lorsque l'appareil photo est ouvert à des fins d'aperçu de base et de capture d'image.

7.5.1. Caméra arrière

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.

Implémentations de l'appareil:

  • DOIT inclure une caméra arrière.

Si les implémentations d'appareils incluent au moins une caméra arrière, elles:

  • [C-1-1] DOIT signaler les indicateurs de fonctionnalité android.hardware.camera et android.hardware.camera.any.
  • [C-1-2] DOIT avoir une résolution d'au moins 2 mégapixels.
  • Le pilote de l'appareil photo doit implémenter la mise au point automatique matérielle ou logicielle (transparente pour le logiciel d'application).
  • POURRAIENT avoir un matériel à mise au point fixe ou à profondeur de champ étendue (EDOF, Extended Depth of Field).
  • POURRA inclure un flash.

Si la caméra inclut un flash:

  • [C-2-1] Le flash ne doit PAS être allumé lorsqu'une instance android.hardware.Camera.PreviewCallback a été enregistrée sur une surface d'aperçu de l'appareil photo, sauf si l'application a explicitement activé le flash en activant les attributs FLASH_MODE_AUTO ou FLASH_MODE_ON d'un objet Camera.Parameters. Notez que cette contrainte ne s'applique pas à l'application d'appareil photo système intégrée de l'appareil, mais uniquement aux applications tierces qui utilisent Camera.PreviewCallback.

7.5.2. Caméra avant

Une caméra avant est une caméra située du même côté de l'appareil que l'écran. C'est-à-dire 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.

Implémentations de l'appareil:

  • POURRAIENT inclure une caméra avant.

Si les implémentations d'appareils incluent au moins une caméra avant, elles:

  • [C-1-1] DOIT signaler les indicateurs de fonctionnalité android.hardware.camera.any et android.hardware.camera.front.
  • [C-1-2] DOIT avoir une résolution d'au moins VGA (640 x 480 pixels).
  • [C-1-3] NE DOIT PAS utiliser une caméra avant par défaut pour l'API Camera et NE DOIT PAS configurer l'API pour qu'elle traite une caméra avant comme une caméra arrière par défaut, même si elle est la seule caméra de l'appareil.
  • [C-1-4] L'aperçu de l'appareil photo DOIT être mis en miroir horizontalement par rapport à l'orientation spécifiée par l'application lorsque l'application actuelle a explicitement demandé que l'écran de l'appareil photo soit pivoté via un appel à la méthode android.hardware.Camera.setDisplayOrientation(). À l'inverse, l'aperçu DOIT être mis en miroir le long de l'axe horizontal par défaut de l'appareil lorsque l'application en cours n'exige pas explicitement que l'écran de l'appareil photo soit pivoté via un appel à la méthode android.hardware.Camera.setDisplayOrientation().
  • [C-1-5] NE DOIT PAS refléter les flux d'images fixes ou vidéo capturés renvoyés aux rappels d'application ou enregistrés dans le stockage multimédia.
  • [C-1-6] DOIT refléter l'image affichée par le postview de la même manière que le flux d'images d'aperçu de la caméra.
  • PEUVENT inclure des fonctionnalités (comme l'autofocus, le flash, etc.) disponibles pour les caméras arrière, comme décrit dans la section 7.5.1.

Si les implémentations d'appareils peuvent être pivotées par l'utilisateur (par exemple, automatiquement via un accéléromètre ou manuellement via une entrée utilisateur):

  • [C-2-1] L'aperçu de l'appareil photo DOIT être mis en miroir horizontalement par rapport à l'orientation actuelle de l'appareil.

7.5.3. Caméra externe

Implémentations de l'appareil:

  • PEUT inclure la compatibilité avec une caméra externe qui n'est pas nécessairement toujours connectée.

Si les implémentations de l'appareil sont compatibles avec une caméra externe, elles:

  • [C-1-1] Vous DEVEZ déclarer les indicateurs de fonctionnalité de la plate-forme android.hardware.camera.external et android.hardware camera.any.
  • [C-1-2] DOIT être compatible avec la classe vidéo USB (UVC 1.0 ou version ultérieure) si la caméra externe se connecte via le port hôte USB.
  • [C-1-3] L'appareil doit réussir les tests CTS de la caméra avec une caméra externe physique connectée. Pour en savoir plus sur les tests CTS de l'appareil photo, consultez source.android.com.
  • DOIT prendre en charge les compressions vidéo telles que MJPEG pour permettre le transfert de flux non encodés de haute qualité (c'est-à-dire des flux d'images bruts ou compressés indépendamment).
  • Peut être compatible avec plusieurs caméras.
  • PEUT prendre en charge l'encodage vidéo basé sur la caméra.

Si l'encodage vidéo basé sur l'appareil photo est compatible:

  • [C-2-1] Un flux non encodé / MJPEG simultané (résolution VGA ou supérieure) DOIT être accessible à l'implémentation de l'appareil.

7.5.4. Comportement de l'API Camera

Android inclut deux packages d'API pour accéder à l'appareil photo. La nouvelle API android.hardware.camera2 expose à l'application un contrôle de l'appareil photo de niveau inférieur, y compris des flux de streaming/rafale sans copie efficaces et des commandes par frame de l'exposition, du gain, des gains de balance des blancs, de la conversion des couleurs, du bruit, de l'accentuation, etc.

L'ancien package d'API, android.hardware.Camera, est marqué comme obsolète dans Android 5.0, mais il devrait toujours être disponible pour les applications. Les implémentations d'appareils Android DOIVENT assurer la compatibilité continue de l'API, comme décrit dans cette section et dans le SDK Android.

Toutes les fonctionnalités communes entre la classe android.hardware.Camera obsolète et le package android.hardware.camera2 plus récent DOIVENT avoir des performances et une qualité équivalentes dans les deux API. Par exemple, avec des paramètres équivalents, la vitesse et la précision du mode autofocus doivent être identiques, et la qualité des images capturées doit être la même. Les fonctionnalités qui dépendent des différentes sémantiques des deux API ne sont pas tenues d'avoir la même vitesse ni la même qualité, mais DOIVENT correspondre le plus possible.

Les implémentations d'appareils DOIVENT implémenter les comportements suivants pour les API liées à la caméra, pour toutes les caméras disponibles. Implémentations de l'appareil:

  • [C-0-1] Vous devez utiliser android.hardware.PixelFormat.YCbCr_420_SP pour les données d'aperçu fournies aux rappels d'application lorsqu'une application n'a jamais appelé android.hardware.Camera.Parameters.setPreviewFormat(int).
  • [C-0-2] Les données doivent également être au format d'encodage NV21 lorsqu'une application enregistre une instance android.hardware.Camera.PreviewCallback et que le système appelle la méthode onPreviewFrame() et que le format d'aperçu est YCbCr_420_SP, les données du byte[] transmises à onPreviewFrame(). Autrement dit, NV21 DOIT être la valeur par défaut.
  • [C-0-3] DOIT 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 pour android.hardware.Camera. (L'encodeur 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 en YV12.)
  • [C-0-4] DOIT prendre en charge les formats android.hardware.ImageFormat.YUV_420_888 et android.hardware.ImageFormat.JPEG en sortie via l'API android.media.ImageReader pour les appareils android.hardware.camera2 qui annoncent la fonctionnalité REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE dans android.request.availableCapabilities.
  • [C-0-5] Vous devez toujours implémenter l'API Camera complète incluse dans la documentation du SDK Android, que l'appareil inclue ou non un autofocus matériel ou d'autres fonctionnalités. Par exemple, les appareils photo qui ne disposent pas d'autofocus DOIVENT toujours appeler les instances android.hardware.Camera.AutoFocusCallback enregistrées (même si cela n'a aucune pertinence pour un appareil photo sans autofocus). Notez que cela s'applique aux caméras avant. Par exemple, même si la plupart des caméras avant ne sont pas compatibles avec la mise au point automatique, les rappels d'API doivent toujours être "faussés" comme décrit.
  • [C-0-6] DOIT reconnaître et respecter chaque nom de paramètre défini comme constante dans la classe android.hardware.Camera.Parameters. À l'inverse, les implémentations d'appareils NE DOIVENT PAS respecter ni reconnaître les constantes de chaîne transmises à la méthode android.hardware.Camera.setParameters(), sauf celles documentées en tant que constantes sur android.hardware.Camera.Parameters. Autrement dit, les implémentations d'appareils DOIVENT prendre en charge tous les paramètres d'appareil photo standards si le matériel le permet, et NE DOIVENT PAS prendre en charge les types de paramètres d'appareil photo personnalisés. Par exemple, les implémentations d'appareils compatibles avec la capture d'images à l'aide de techniques d'imagerie HDR (High Dynamic Range) DOIVENT prendre en charge le paramètre de l'appareil photo Camera.SCENE_MODE_HDR.
  • [C-0-7] DOIT indiquer le niveau de compatibilité approprié avec la propriété android.info.supportedHardwareLevel, comme décrit dans le SDK Android, et indiquer les options de fonctionnalité du framework appropriées.
  • [C-0-8] DOIT également déclarer les fonctionnalités de caméra individuelles de android.hardware.camera2 via la propriété android.request.availableCapabilities et déclarer les options de fonctionnalité appropriées. DOIT définir l'option de fonctionnalité si l'une de ses caméras connectées est compatible avec la fonctionnalité.
  • [C-0-9] DOIT 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 store multimédia.
  • [C-0-10] DOIT 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 store multimédia.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge un appareil photo logique qui liste la capacité CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, pour les appareils dotés de plusieurs caméras orientées dans la même direction, composées de chaque caméra physique orientée dans cette direction, à condition que le type de caméra physique soit compatible avec le framework et que CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL pour les caméras physiques soit LIMITED, FULL ou LEVEL_3.

7.5.5. Orientation de l'appareil photo

Si les implémentations de l'appareil comportent une caméra avant ou arrière, la ou les caméras :

  • [C-1-1] DOIT être orienté de sorte à faire correspondre la dimension longue de l'appareil photo à la dimension longue de l'écran. Autrement dit, lorsque l'appareil est tenu en mode paysage, les appareils photo DOIVENT capturer des images en mode paysage. Cela s'applique quelle que soit l'orientation naturelle de l'appareil, c'est-à-dire aux appareils en mode paysage et en mode portrait.

7.6. Mémoire et stockage

7.6.1. Mémoire et stockage minimums

Implémentations de l'appareil:

  • [C-0-1] DOIT inclure un gestionnaire de téléchargement que les applications PEUVENT utiliser pour télécharger des fichiers de données. Elles DOIVENT être capables de télécharger des fichiers individuels d'au moins 100 Mo à l'emplacement par défaut du "cache".

7.6.2. Stockage partagé de l'application

Implémentations de l'appareil:

  • [C-0-1] DOIT proposer un espace de stockage à partager entre les applications, souvent appelé "stockage externe partagé", "stockage partagé par les applications" ou par le chemin d'accès Linux "/sdcard" sur lequel il est installé.
  • [C-0-2] DOIT être configuré avec un espace de stockage partagé installé par défaut, c'est-à-dire "prêt à l'emploi", que le stockage soit implémenté sur un composant de stockage interne ou sur un support de stockage amovible (par exemple, un port de carte Secure Digital).
  • [C-0-3] DOIT monter le stockage partagé de l'application directement sur le chemin d'accès Linux sdcard ou inclure un lien symbolique Linux de sdcard au point d'installation réel.
  • [C-0-4] Vous devez appliquer l'autorisation android.permission.WRITE_EXTERNAL_STORAGE à cet espace de stockage partagé, comme indiqué dans le SDK. Sinon, l'espace de stockage partagé DOIT être accessible en écriture par toute application qui obtient cette autorisation.

Les implémentations d'appareils PEUVENT répondre aux exigences ci-dessus en utilisant l'une des méthodes suivantes:

  • Un espace de stockage amovible accessible à l'utilisateur, tel qu'un port de carte Secure Digital (SD).
  • Partie du stockage interne (non amovible) implémentée dans le projet Android Open Source (AOSP).

Si les implémentations d'appareils utilisent un stockage amovible pour répondre aux exigences ci-dessus, elles:

  • [C-1-1] L'interface utilisateur doit comporter un message toast ou pop-up avertissant l'utilisateur lorsqu'aucun support de stockage n'est inséré dans le port.
  • [C-1-2] DOIT inclure un support de stockage au format FAT (par exemple, une carte SD) ou indiquer sur la boîte et sur tout autre document disponible au moment de l'achat que le support de stockage doit être acheté séparément.

Si les implémentations d'appareils utilisent une partie de l'espace de stockage non amovible pour répondre aux exigences ci-dessus, elles:

  • DOIT utiliser l'implémentation AOSP du stockage partagé de l'application interne.
  • PEUT partager l'espace de stockage avec les données privées de l'application.

Si les implémentations d'appareils incluent plusieurs chemins de stockage partagés (par exemple, un emplacement pour carte SD et un stockage interne partagé), elles:

  • [C-2-1] NE DOIT AUTORISER QUE les applications Android préinstallées et privilégiées disposant de l'autorisation WRITE_EXTERNAL_STORAGE à écrire sur le stockage externe secondaire, sauf lorsqu'elles écrivent dans leurs répertoires spécifiques au package ou dans le URI renvoyé par le déclenchement de l'intent ACTION_OPEN_DOCUMENT_TREE.

Si les implémentations d'appareils disposent d'un port USB compatible avec le mode périphérique USB, elles:

  • [C-3-1] DOIT fournir un mécanisme permettant d'accéder aux données du stockage partagé de l'application à partir d'un ordinateur hôte.
  • DOIT exposer le contenu des deux chemins d'accès de stockage de manière transparente via le service d'analyseur multimédia d'Android et android.provider.MediaStore.
  • Peut utiliser le stockage de masse USB, mais DOIT utiliser le protocole Media Transfer pour répondre à cette exigence.

Si les implémentations d'appareils disposent d'un port USB avec mode périphérique USB et sont compatibles avec le protocole de transfert multimédia, elles:

  • DOIT être compatible avec l'hôte MTP Android de référence, Android File Transfer.
  • DOIT indiquer une classe d'appareil USB de 0x00.
  • DOIT indiquer un nom d'interface USB de "MTP".

7.6.3. Stockage adoptable

Si l'appareil est censé être mobile, contrairement à la télévision, les implémentations sont les suivantes:

  • [SR] Nous vous recommandons vivement d'implémenter le stockage adoptable dans un emplacement stable à long terme, car une déconnexion accidentelle peut entraîner une perte ou une corruption de données.

Si le port de l'appareil de stockage amovible se trouve dans un emplacement stable à long terme, comme dans le compartiment de la batterie ou sous une autre protection, les implémentations de l'appareil sont les suivantes:

7.7. USB

Si les implémentations d'appareils disposent d'un port USB, elles:

  • DOIT être compatible avec le mode périphérique USB et DOIT être compatible avec le mode hôte USB.

7.7.1. Mode périphérique USB

Si les implémentations de l'appareil incluent un port USB compatible avec le mode périphérique:

  • [C-1-1] Le port DOIT être connectable à un hôte USB doté d'un port USB Type-A ou Type-C standard.
  • [C-1-2] DOIT indiquer la valeur correcte de iSerialNumber dans le descripteur d'appareil standard USB via android.os.Build.SERIAL.
  • [C-1-3] DOIT détecter les chargeurs 1,5 A et 3 A conformément à la norme de résistance Type-C et DOIT détecter les modifications de la publicité s'ils sont compatibles avec l'USB Type-C.
  • [SR] Le port DOIT utiliser le facteur de forme USB micro-B, micro-AB ou Type-C. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin qu'ils puissent passer aux futures versions de la plate-forme.
  • [SR] Le port DOIT se trouver en bas de l'appareil (selon l'orientation naturelle) ou permettre 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. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin qu'ils puissent passer aux futures versions de la plate-forme.
  • [SR] LE Contrôleur DOIT être compatible avec le courant de 1,5 A pendant le chirp HS et le trafic, comme spécifié dans la spécification de recharge de la batterie USB, version 1.2. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin qu'ils puissent passer aux futures versions de la plate-forme.
  • [SR] Il est vivement recommandé de ne pas prendre en charge les méthodes de recharge propriétaires qui modifient la tension Vbus au-delà des niveaux par défaut ou qui modifient les rôles de source/récepteur, car cela peut entraîner des problèmes d'interopérabilité avec les chargeurs ou les appareils compatibles avec les méthodes de recharge USB standard. Bien que cette fonctionnalité soit "FORTEMENT RECOMMANDÉE", dans les futures versions d'Android, nous pourrons exiger que tous les appareils Type-C soient compatibles avec l'interopérabilité complète avec les chargeurs Type-C standards.
  • [SR] Il est vivement recommandé de prendre en charge la distribution d'alimentation pour le transfert de données et le changement de rôle d'alimentation lorsqu'ils sont compatibles avec l'USB Type-C et le mode hôte USB.
  • DOIT être compatible avec la recharge haute tension et les modes alternatifs tels que la sortie d'écran.
  • DOIT implémenter l'API et la spécification Android Open Accessory (AOA) comme indiqué dans la documentation du SDK Android.

Si les implémentations d'appareils incluent un port USB et implémentent la spécification AOA, elles:

  • [C-2-1] DOIT déclarer la compatibilité avec la fonctionnalité matérielle android.hardware.usb.accessory.
  • [C-2-2] La classe de stockage de masse USB DOIT inclure la chaîne "android" à la fin de la chaîne iInterface de la description de l'interface de stockage de masse USB.

7.7.2. Mode hôte USB

Si les implémentations d'appareils incluent un port USB compatible avec le mode hôte, elles:

  • [C-1-1] DOIT implémenter l'API hôte USB Android comme indiqué dans le SDK Android et DOIT déclarer la prise en charge de la fonctionnalité matérielle android.hardware.usb.host.
  • [C-1-2] DOIVENT prendre en charge la connexion de périphériques USB standards. En d'autres termes, ils DOIVENT :
    • être équipé d'un port de type C sur l'appareil ou être fourni avec un ou plusieurs câbles permettant d'adapter un port propriétaire de l'appareil à un port USB de type C standard (appareil USB de type C) ;
    • être équipé d'un port de type A sur l'appareil ou être fourni avec un ou plusieurs câbles permettant d'adapter un port propriétaire de l'appareil à un port USB de type A standard ;
    • disposer d'un port micro-AB sur l'appareil, qui DOIT être fourni avec un câble permettant de le connecter à un port Type-A standard ;
  • [C-1-3] NE DOIT PAS être livré avec un adaptateur permettant de convertir les ports USB Type-A ou micro-AB en port Type-C (récepteur).
  • [SR] Il est vivement recommandé d'implémenter la classe audio USB, comme indiqué dans la documentation du SDK Android.
  • DOIT prendre en charge la recharge de l'appareil périphérique USB connecté en mode hôte, en annonçant un courant de source d'au moins 1,5 A, comme indiqué dans la section "Paramètres de terminaison" de la spécification de la version 1.2 du câble et du connecteur USB Type-C pour les connecteurs USB Type-C ou en utilisant la plage de courant de sortie du port en aval de recharge(CDP) comme indiqué dans les spécifications de recharge de la batterie USB, version 1.2 pour les connecteurs Micro-AB.
  • DOIT implémenter et prendre en charge les normes USB Type-C.

Si les implémentations d'appareils incluent un port USB compatible avec le mode hôte et la classe audio USB, elles:

  • [C-2-1] DOIT être compatible avec la classe USB HID.
  • [C-2-2] DOIT prendre en charge la détection et le mappage des champs de données HID suivants spécifiés dans les tables d'utilisation USB HID et la requête d'utilisation des commandes vocales aux constantes KeyEvent comme indiqué ci-dessous :
    • Page d'utilisation (0xC) ID d'utilisation (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
    • Page d'utilisation (0xC) ID d'utilisation (0x0E9): KEYCODE_VOLUME_UP
    • Page d'utilisation (0xC) ID d'utilisation (0x0EA): KEYCODE_VOLUME_DOWN
    • Page d'utilisation (0xC) ID d'utilisation (0x0CF): KEYCODE_VOICE_ASSIST

Si les implémentations d'appareils incluent un port USB compatible avec le mode hôte et le Storage Access Framework (SAF), elles:

  • [C-3-1] DOIT reconnaître tous les appareils MTP (Media Transfer Protocol) connectés à distance et rendre leurs contenus accessibles via les intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT et ACTION_CREATE_DOCUMENT. .

Si les implémentations d'appareils incluent un port USB compatible avec le mode hôte et USB Type-C, elles:

  • [C-4-1] DOIT implémenter la fonctionnalité de port à double rôle telle que définie par la spécification USB Type-C (section 4.5.1.3.3).
  • [SR] Il est vivement recommandé de prendre en charge DisplayPort, et de prendre en charge les débits de données USB SuperSpeed. Il est également vivement recommandé de prendre en charge la distribution d'alimentation pour le transfert de données et le changement de rôle d'alimentation.
  • [SR] Nous vous recommandons vivement de NE PAS prendre en charge le mode accessoire de l'adaptateur audio, comme décrit dans l'annexe A de la spécification de la version 1.2 du câble et du connecteur USB Type-C.
  • DOIT implémenter le modèle Try.* le plus adapté au facteur de forme de l'appareil. Par exemple, un appareil portable DOIT implémenter le modèle Try.SNK.

7.8. Audio

7.8.1. Micro

Si les implémentations d'appareils incluent un micro, elles:

  • [C-1-1] DOIT indiquer la constante de fonctionnalité android.hardware.microphone.
  • [C-1-2] DOIT respecter les exigences concernant l'enregistrement audio de la section 5.4.
  • [C-1-3] DOIT respecter les exigences de latence audio de la section 5.6.
  • [SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'enregistrement par ultrasons, comme décrit dans la section 7.8.3.

Si les implémentations d'appareils omettent un micro, elles:

  • [C-2-1] NE DOIT PAS signaler la constante de fonctionnalité android.hardware.microphone.
  • [C-2-2] L'API d'enregistrement audio doit être implémentée au moins en tant que no-ops, conformément à la section 7.

7.8.2. Sortie audio

Si les implémentations d'appareils incluent un haut-parleur ou un port de sortie audio/multimédia pour un périphérique de sortie audio tel qu'une prise audio 3,5 mm à quatre conducteurs ou un port en mode hôte USB utilisant la classe audio USB, elles:

  • [C-1-1] DOIT indiquer la constante de fonctionnalité android.hardware.audio.output.
  • [C-1-2] DOIT respecter les exigences de lecture audio de la section 5.5.
  • [C-1-3] DOIT respecter les exigences de latence audio de la section 5.6.
  • [SR] Il est vivement recommandé de prendre en charge la lecture proche des ultrasons, comme décrit dans la section 7.8.3.

Si les implémentations d'appareils n'incluent pas de haut-parleur ni de port de sortie audio, elles:

  • [C-2-1] NE DOIT PAS signaler la fonctionnalité android.hardware.audio.output.
  • [C-2-2] Les API liées à la sortie audio doivent être implémentées en tant que no-ops au moins.

Aux fins de cette section, un "port de sortie" est une interface physique telle qu'une prise audio 3, 5 mm, un port HDMI ou un port en mode hôte USB avec classe audio USB. La prise en charge de la sortie audio via des protocoles radio tels que le Bluetooth, le Wi-Fi ou le réseau mobile ne peut pas être considérée comme incluant un "port de sortie".

7.8.2.1. Ports audio analogiques

Pour être compatibles avec les casques et autres accessoires audio utilisant la prise audio 3,5 mm dans l'écosystème Android, si les implémentations d'appareils incluent un ou plusieurs ports audio analogiques, elles doivent:

  • [C-SR] Il est FORTEMENT RECOMMANDÉ que l'un des ports audio soit un connecteur audio 3,5 mm à quatre conducteurs.

Si les implémentations d'appareils sont dotées d'une prise audio 3,5 mm à quatre conducteurs, elles:

  • [C-1-1] DOIT être compatible avec la lecture audio sur des casques stéréo et des casques stéréo avec micro.
  • [C-1-2] DOIT être compatible avec les connecteurs audio TRRS avec la séquence de broches CTIA.
  • [C-1-3] DOIT prendre en charge la détection et le mappage sur les codes de touche pour les trois plages d'impédance équivalente suivantes entre le micro et les conducteurs de terre sur la prise audio :
    • 70 ohms ou moins: KEYCODE_HEADSETHOOK
    • 210-290 ohms: KEYCODE_VOLUME_UP
    • 360-680 ohms: KEYCODE_VOLUME_DOWN
  • [C-1-4] DOIT déclencher ACTION_HEADSET_PLUG lors de l'insertion d'une prise, mais uniquement après que tous les contacts de la prise ont touché leurs segments correspondants sur la prise.
  • [C-1-5] DOIT être capable de générer au moins 150 mV ± 10% de tension de sortie sur une impédance d'enceinte de 32 ohms.
  • [C-1-6] La tension de polarisation du micro doit être comprise entre 1,8 V et 2,9 V.
  • [C-1-7] DOIT détecter et mapper sur le code de touche la plage d'impédance équivalente suivante entre les conducteurs du micro et de la terre sur la prise audio :
    • 110 à 180 ohms:KEYCODE_VOICE_ASSIST
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge les prises audio avec la séquence de broches OMTP.
  • [C-SR] Nous vous RECOMMANDONS vivement de prendre en charge l'enregistrement audio à partir de casques stéréo avec micro.

Si les implémentations d'appareils disposent d'un connecteur audio 3,5 mm à quatre conducteurs et sont compatibles avec un micro, et qu'elles diffusent android.intent.action.HEADSET_PLUG avec la valeur supplémentaire du micro définie sur 1, elles:

  • [C-2-1] L'appareil DOIT prendre en charge la détection du micro sur l'accessoire audio branché.

7.8.3. Ultrasons proches

L'audio proche des ultrasons correspond à la bande de fréquences de 18,5 kHz à 20 kHz.

Implémentations de l'appareil:

  • DOIT indiquer correctement la prise en charge de la fonctionnalité audio à ultrasons via l'API AudioManager.getProperty comme suit:

Si PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND est défini sur "true", les sources audio VOICE_RECOGNITION et UNPROCESSED DOIVENT répondre aux exigences suivantes:

  • [C-1-1] La réponse moyenne en puissance du micro dans la bande de fréquences de 18,5 kHz à 20 kHz DOIT être inférieure de 15 dB à la réponse à 2 kHz.
  • [C-1-2] Le rapport signal/bruit non pondéré du micro entre 18,5 kHz et 20 kHz pour un son de 19 kHz à -26 dBFS DOIT être d'au moins 50 dB.

Si PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND est "true":

  • [C-2-1] La réponse moyenne de l'enceinte dans la plage de fréquences 18,5 kHz à 20 kHz DOIT être inférieure de 40 dB à la réponse à 2 kHz.

7.9. Réalité virtuelle

Android inclut des API et des outils permettant de créer des applications de "réalité virtuelle" (RV), y compris des expériences de RV mobile de haute qualité. Les implémentations d'appareils DOIVENT implémenter correctement ces API et ces comportements, comme indiqué dans cette section.

7.9.1. Mode réalité virtuelle

Android est compatible avec le mode VR, une fonctionnalité qui gère le rendu stéréoscopique des notifications et désactive les composants d'interface utilisateur du système monoculaire lorsqu'une application de RV est en mode plein écran.

7.9.2. Mode Réalité virtuelle : hautes performances

Si les implémentations d'appareils sont compatibles avec le mode VR, elles:

  • [C-1-1] Le processeur doit comporter au moins deux cœurs physiques.
  • [C-1-2] Vous DEVEZ déclarer la fonctionnalité android.hardware.vr.high_performance.
  • [C-1-3] DOIT prendre en charge le mode Performances soutenues.
  • [C-1-4] DOIT être compatible avec OpenGL ES 3.2.
  • [C-1-5] DOIT prendre en charge android.hardware.vulkan.level 0.
  • DOIT être compatible avec la version 1 de android.hardware.vulkan.level ou ultérieure.
  • [C-1-6] DOIT implémenter EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content et EGL_EXT_image_gl_colorspace, et exposer les extensions dans la liste des extensions EGL disponibles.
  • [C-1-8] DOIT implémenter GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture et GL_EXT_protected_textures, et exposer les extensions dans la liste des extensions GL disponibles.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter GL_EXT_external_buffer, GL_EXT_EGL_image_array et d'exposer les extensions dans la liste des extensions GL disponibles.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge Vulkan 1.1.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing et VK_KHR_shared_presentable_image, et de les exposer dans la liste des extensions Vulkan disponibles.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'exposer au moins une famille de files d'attente Vulkan où flags contient à la fois VK_QUEUE_GRAPHICS_BIT et VK_QUEUE_COMPUTE_BIT, et où queueCount est au moins égal à 2.
  • [C-1-7] Le GPU et l'écran DOIVENT pouvoir synchroniser l'accès au tampon d'affichage partagé de sorte que le rendu alterné des contenus VR à 60 FPS avec deux contextes de rendu soit affiché sans artefacts de déchirure visibles.
  • [C-1-9] DOIT prendre en charge les indicateurs AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA et AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT de AHardwareBuffer, comme décrit dans le NDK.
  • [C-1-10] DOIT implémenter la prise en charge des AHardwareBuffer avec n'importe quelle combinaison des indicateurs d'utilisation AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT pour au moins les formats suivants: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
  • [C-SR] FORTEMENT RECOMMANDÉ pour prendre en charge l'allocation de AHardwareBuffer avec plusieurs calques, ainsi que les indicateurs et formats spécifiés dans C-1-10.
  • [C-1-11] DOIT prendre en charge le décodage H.264 d'au moins 3 840 x 2 160 à 30 FPS, compressé à une moyenne de 40 Mbit/s (équivalent à 4 instances de 1 920 x 1 080 à 30 FPS-10 Mbit/s ou 2 instances de 1 920 x 1 080 à 60 FPS-20 Mbit/s).
  • [C-1-12] DOIT être compatible avec HEVC et VP9, DOIT être capable de décoder au moins 1 920 x 1 080 à 30 FPS compressé à une moyenne de 10 Mbit/s et DOIT être capable de décoder 3 840 x 2 160 à 30 FPS-20 Mbit/s (équivalent à 4 instances de 1 920 x 1 080 à 30 FPS-5 Mbit/s).
  • [C-1-13] DOIT prendre en charge l'API HardwarePropertiesManager.getDeviceTemperatures et renvoyer des valeurs précises pour la température de la peau.
  • [C-1-14] DOIT comporter un écran intégré dont la résolution DOIT être d'au moins 1 920 x 1 080 pixels.
  • [C-SR] Nous vous RECOMMANDONS vivement d'utiliser une résolution d'affichage d'au moins 2 560 x 1 440 pixels.
  • [C-1-15] L'écran doit se mettre à jour à au moins 60 Hz en mode VR.
  • [C-1-17] L'écran DOIT prendre en charge un mode à faible persistance avec une persistance de 5 millisecondes maximum, la persistance étant définie comme la durée pendant laquelle un pixel émet de la lumière.
  • [C-1-18] DOIT être compatible avec Bluetooth 4.2 et l'extension de la longueur des données Bluetooth LE (section 7.4.3).
  • [C-1-19] DOIT prendre en charge et signaler correctement le type de canal direct pour tous les types de capteurs par défaut suivants :
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [C-SR] Nous vous RECOMMANDONS vivement de prendre en charge le type de canal direct TYPE_HARDWARE_BUFFER pour tous les types de canaux directs listés ci-dessus.
  • [C-1-21] DOIT respecter les exigences liées au gyroscope, à l'accéléromètre et au magnétomètre pour android.hardware.hifi_sensors, comme indiqué dans la section 7.3.9.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge la fonctionnalité android.hardware.sensor.hifi_sensors.
  • [C-1-22] La latence de mouvement à photon de bout en bout doit être inférieure à 28 millisecondes.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de ne pas dépasser 20 millisecondes de latence de mouvement à photon de bout en bout.
  • [C-1-23] Le ratio de la première image, qui correspond au ratio entre la luminosité des pixels de la première image après une transition du noir au blanc et la luminosité des pixels blancs à l'état stable, doit être d'au moins 85%.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'avoir un ratio de première image d'au moins 90%.
  • PEUT fournir un cœur exclusif à l'application de premier plan et PEUT prendre en charge l'API Process.getExclusiveCores pour renvoyer les numéros des cœurs de processeur exclusifs à l'application de premier plan principale.

Si le cœur exclusif est compatible, le cœur:

  • [C-2-1] NE DOIT PAS autoriser l'exécution d'autres processus d'espace utilisateur (à l'exception des pilotes d'appareils utilisés par l'application), mais PEUT autoriser l'exécution de certains processus de noyau si nécessaire.

8. Performances et puissance

Certains critères de performances et d'alimentation minimaux sont essentiels à l'expérience utilisateur et ont un impact sur les hypothèses de référence que les développeurs doivent prendre en compte lorsqu'ils développent une application.

8.1. Cohérence de l'expérience utilisateur

Une interface utilisateur fluide peut être fournie à l'utilisateur final si certaines conditions minimales sont respectées pour garantir une fréquence d'images et des temps de réponse cohérents pour les applications et les jeux. Selon le type d'appareil, les implémentations peuvent avoir des exigences mesurables concernant la latence de l'interface utilisateur et le changement de tâche, comme décrit dans la section 2.

8.2. Performances d'accès aux E/S de fichiers

Fournir une référence commune pour des performances d'accès aux fichiers cohérentes sur le stockage de données privées de l'application (partition /data) permet aux développeurs d'applications de définir des attentes appropriées qui faciliteront la conception de leur logiciel. Selon le type d'appareil, les implémentations d'appareil peuvent être soumises à certaines exigences décrites dans la section 2 pour les opérations de lecture et d'écriture suivantes:

  • Performances d'écriture séquentielle Mesuré en écrivant un fichier de 256 Mo à l'aide d'une mémoire tampon d'écriture de 10 Mo.
  • Performances d'écriture aléatoire Mesuré en écrivant un fichier de 256 Mo à l'aide d'une mémoire tampon d'écriture de 4 ko.
  • Performances de lecture séquentielle Mesure effectuée en lisant un fichier de 256 Mo à l'aide d'une mémoire tampon d'écriture de 10 Mo.
  • Performances de lecture aléatoire Mesuré en lisant un fichier de 256 Mo à l'aide d'une mémoire tampon d'écriture de 4 Ko.

8.3. Modes d'économie d'énergie

Si les implémentations d'appareils incluent des fonctionnalités de gestion de l'alimentation de l'appareil incluses dans AOSP ou qui en étendent les fonctionnalités, elles:

  • [C-1-1] NE DOIT PAS s'écarter de l'implémentation AOSP pour les algorithmes de déclenchement, de maintenance et de réveil, ainsi que pour l'utilisation des paramètres système globaux des modes d'économie d'énergie App Standby et Doze.
  • [C-1-2] NE DOIT PAS s'écarter de l'implémentation AOSP pour l'utilisation de paramètres globaux afin de gérer le débit des tâches, de l'alarme et du réseau pour les applications de chaque bucket en mode veille de l'application.
  • [C-1-3] Le nombre de buckets App Standby utilisés pour App Standby NE DOIT PAS différer de l'implémentation AOSP.
  • [C-1-4] DOIT implémenter les buckets de mise en veille des applications et le mode Doze comme décrit dans la section Gestion de l'alimentation.
  • [C-1-5] DOIT renvoyer true pour PowerManager.isPowerSaveMode() lorsque l'appareil est en mode Économie d'énergie.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de fournir à l'utilisateur une affordance lui permettant d'activer et de désactiver la fonctionnalité Économiseur de batterie.
  • [C-SR] Il est vivement recommandé de fournir à l'utilisateur la possibilité d'afficher toutes les applications qui sont exemptées des modes d'économie d'énergie App Standby et Doze.

En plus des modes d'économie d'énergie, les implémentations d'appareils Android PEUVENT implémenter l'un ou l'ensemble des quatre états d'alimentation en veille définis par l'interface ACPI (Advanced Configuration and Power Interface).

Si les implémentations d'appareils implémentent les états d'alimentation S4 tels que définis par l'ACPI, elles:

  • [C-1-1] L'appareil NE DOIT PAS entrer dans cet état tant que l'utilisateur n'a pas effectué une action explicite pour le mettre en veille (par exemple, en fermant un couvercle qui fait physiquement partie de l'appareil ou en éteignant un véhicule ou un téléviseur) et avant que l'utilisateur ne réactive l'appareil (par exemple, en ouvrant le couvercle ou en rallumant le véhicule ou le téléviseur).

Si les implémentations d'appareils implémentent les états d'alimentation S3 tels que définis par l'ACPI, elles:

  • [C-2-1] DOIT respecter C-1-1 ci-dessus, ou DOIT passer à l'état S3 uniquement lorsque les applications tierces n'ont pas besoin des ressources système (par exemple, l'écran, le processeur).

    À l'inverse, vous devez quitter l'état S3 lorsque des applications tierces ont besoin des ressources système, comme décrit dans ce SDK.

    Par exemple, lorsque les applications tierces demandent à maintenir l'écran allumé via FLAG_KEEP_SCREEN_ON ou à maintenir le processeur en cours d'exécution via PARTIAL_WAKE_LOCK, l'appareil NE DOIT PAS entrer en état S3, sauf si, comme décrit dans C-1-1, l'utilisateur a pris une mesure explicite pour mettre l'appareil en état inactif. À l'inverse, lorsqu'une tâche implémentée par des applications tierces via JobScheduler est déclenchée ou que Firebase Cloud Messaging est envoyé à des applications tierces, l'appareil DOIT quitter l'état S3, sauf si l'utilisateur a mis l'appareil en état inactif. Il ne s'agit pas d'exemples exhaustifs, et AOSP implémente des signaux de réveil étendus qui déclenchent un réveil à partir de cet état.

8.4. Comptabilisation de la consommation d'énergie

Une comptabilisation et une création de rapports plus précises de la consommation d'énergie fournissent au développeur d'applications les incitations et les outils nécessaires pour optimiser le modèle d'utilisation de l'énergie de l'application.

Implémentations de l'appareil:

  • [SR] Nous vous recommandons vivement de fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle pour chaque composant matériel et l'épuisement approximatif de la batterie causé par les composants au fil du temps, comme indiqué sur le site du projet Android Open Source.
  • [SR] Nous vous recommandons vivement de déclarer toutes les valeurs de consommation d'énergie en milliampères-heure (mAh).
  • [SR] FORTEMENT RECOMMANDÉ de signaler la consommation d'énergie du processeur par UID de chaque processus. Le projet Android Open Source répond à cette exigence grâce à l'implémentation du module de noyau uid_cputime.
  • [SR] Il est vivement recommandé de rendre cette consommation d'énergie disponible via la commande shell adb shell dumpsys batterystats pour le développeur de l'application.
  • DOIT être attribué au composant matériel lui-même si vous ne parvenez pas à attribuer la consommation d'énergie du composant matériel à une application.

8.5. Performances cohérentes

Les performances peuvent fluctuer de manière importante pour les applications de longue durée hautes performances, soit en raison des autres applications exécutées en arrière-plan, soit en raison du débit limité du processeur en raison de limites de température. Android inclut des interfaces programmatiques afin que, lorsque l'appareil est compatible, l'application de premier plan puisse demander au système d'optimiser l'allocation des ressources pour faire face à ces fluctuations.

Implémentations de l'appareil:

Si les implémentations d'appareils signalent la prise en charge du mode Performances soutenues, elles:

  • [C-1-1] DOIT fournir à l'application de premier plan un niveau de performances cohérent pendant au moins 30 minutes, lorsque l'application le demande.
  • [C-1-2] DOIT respecter l'API Window.setSustainedPerformanceMode() et les autres API associées.

Si les implémentations d'appareils incluent deux cœurs de processeur ou plus, elles:

  • DOIT fournir au moins un cœur exclusif pouvant être réservé par l'application de premier plan.

Si les implémentations d'appareils permettent de réserver un cœur exclusif pour l'application de premier plan, elles:

  • [C-2-1] DOIT indiquer via la méthode d'API Process.getExclusiveCores() les numéros d'ID des cœurs exclusifs pouvant être réservés par l'application de premier plan supérieure.
  • [C-2-2] Le kernel DOIT empêcher l'exécution de tout processus d'espace utilisateur, à l'exception des pilotes d'appareils utilisés par l'application sur les cœurs exclusifs, mais PEUT autoriser l'exécution de certains processus de noyau si nécessaire.

Si les implémentations de l'appareil ne sont pas compatibles avec un cœur exclusif, elles:

9. Compatibilité des modèles de sécurité

Implémentations de l'appareil:

  • [C-0-1] DOIT implémenter un modèle de sécurité conforme au modèle de sécurité de la plate-forme Android, tel que défini dans le document de référence sur la sécurité et les autorisations des API dans la documentation destinée aux développeurs Android.

  • [C-0-2] DOIT permettre l'installation d'applications autosignées sans nécessiter d'autorisations/certificats supplémentaires de la part de tiers/autorités. Plus précisément, les appareils compatibles DOIVENT prendre en charge les mécanismes de sécurité décrits dans les sous-sections suivantes.

9.1. Autorisations

Implémentations de l'appareil:

  • [C-0-1] DOIT prendre en charge le modèle d'autorisations Android tel que défini dans la documentation destinée aux développeurs Android. Plus précisément, ils DOIVENT appliquer chaque autorisation définie comme décrit dans la documentation du SDK. Aucune autorisation ne peut être omise, modifiée ou ignorée.

  • PEUT 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.\*.

  • [C-0-2] Les autorisations avec un protectionLevel de PROTECTION_FLAG_PRIVILEGED DOIVENT être accordées uniquement aux applications préinstallées dans le ou les chemins privilégiés de l'image système et dans le sous-ensemble des autorisations explicitement autorisées pour chaque application. L'implémentation AOSP répond à cette exigence en lisant et en respectant les autorisations de la liste d'autorisation pour chaque application à partir des fichiers du chemin etc/permissions/ et en utilisant le chemin system/priv-app comme chemin privilégié.

Les autorisations dont le niveau de protection est dangereux sont des autorisations d'exécution. Les applications avec targetSdkVersion > 22 les demandent au moment de l'exécution.

Implémentations de l'appareil:

  • [C-0-3] DOIT afficher une interface dédiée permettant à l'utilisateur de décider d'accorder les autorisations d'exécution demandées et fournir une interface permettant à l'utilisateur de gérer les autorisations d'exécution.
  • [C-0-4] Il doit y avoir une seule et unique implémentation des deux interfaces utilisateur.
  • [C-0-5] Vous NE DEVEZ PAS accorder d'autorisations d'exécution aux applications préinstallées, sauf si :
    • Le consentement de l'utilisateur peut être obtenu avant que l'application ne l'utilise.
    • Les autorisations d'exécution sont associées à un modèle d'intent pour lequel l'application préinstallée est définie comme gestionnaire par défaut.
  • [C-0-6] Vous devez accorder l'autorisation android.permission.RECOVER_KEYSTORE uniquement aux applications système qui enregistrent un agent de récupération correctement sécurisé. Un agent de récupération correctement sécurisé est défini comme un agent logiciel sur l'appareil qui se synchronise avec un stockage distant hors appareil, équipé de matériel sécurisé offrant une protection équivalente ou plus forte que celle décrite dans le service Google Cloud Key Vault pour empêcher les attaques par force brute sur le facteur de connaissance du verrouillage de l'écran.

Si les implémentations d'appareils incluent une application préinstallée ou souhaitent autoriser des applications tierces à accéder aux statistiques d'utilisation, elles:

  • [SR] Il est FORTEMENT RECOMMANDÉ de fournir un mécanisme accessible par l'utilisateur pour accorder ou révoquer l'accès aux statistiques d'utilisation en réponse à l'intent android.settings.ACTION_USAGE_ACCESS_SETTINGS pour les applications qui déclarent l'autorisation android.permission.PACKAGE_USAGE_STATS.

Si les implémentations d'appareils ont l'intention d'interdire à toute application, y compris aux applications préinstallées, d'accéder aux statistiques d'utilisation, elles:

  • [C-1-1] Une activité doit toujours gérer le modèle d'intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, mais elle doit l'implémenter comme une opération sans effet, c'est-à-dire avoir un comportement équivalent à celui qui se produit lorsque l'accès de l'utilisateur est refusé.

9.2. UID et isolation des processus

Implémentations de l'appareil:

  • [C-0-1] DOIT 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.
  • [C-0-2] DOIT permettre d'exécuter plusieurs applications avec le même ID utilisateur Linux, à condition que les applications soient correctement signées et conçues, comme défini dans la documentation de référence sur la sécurité et les autorisations.

9.3. Autorisations du système de fichiers

Implémentations de l'appareil:

9.4. Environnements d'exécution alternatifs

Les implémentations d'appareils DOIVENT maintenir la cohérence du modèle de sécurité et d'autorisation Android, même si elles incluent des environnements d'exécution qui exécutent des applications à l'aide d'un autre logiciel ou d'une autre technologie que le format exécutable Dalvik ou le code natif. Autrement dit :

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

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

  • [C-0-3] 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.

  • [C-0-4] Les environnements d'exécution alternatifs DOIVENT respecter le modèle de bac à sable Android. Les applications installées à l'aide d'un environnement d'exécution alternatif NE DOIVENT PAS réutiliser le bac à sable d'une autre application installée sur l'appareil, sauf via les mécanismes Android standards d'ID utilisateur partagé et de certificat de signature.

  • [C-0-5] Les environnements d'exécution alternatifs NE DOIVENT PAS se lancer avec, accorder ni être autorisés à accéder aux bacs à sable correspondant à d'autres applications Android.

  • [C-0-6] Les environnements d'exécution alternatifs NE DOIVENT PAS être lancés avec les droits du super-utilisateur (root) ni accorder ces droits à d'autres applications.

  • [C-0-7] Lorsque les fichiers .apk d'autres environnements d'exécution sont inclus dans l'image système des implémentations d'appareils, ils DOIVENT être signés avec une clé distincte de celle utilisée pour signer les autres applications incluses avec les implémentations d'appareils.

  • [C-0-8] Lors de l'installation d'applications, les environnements d'exécution alternatifs DOIVENT obtenir le consentement de l'utilisateur pour les autorisations Android utilisées par l'application.

  • [C-0-9] Lorsqu'une application doit utiliser une ressource d'appareil pour laquelle une autorisation Android correspondante est disponible (appareil photo, GPS, etc.), le runtime alternatif DOIT informer l'utilisateur que l'application pourra accéder à cette ressource.

  • [C-0-10] Lorsque l'environnement d'exécution n'enregistre pas les fonctionnalités de l'application de cette manière, il DOIT lister toutes les autorisations détenues par l'environnement d'exécution lui-même lors de l'installation d'une application utilisant cet environnement d'exécution.

  • Les autres environnements d'exécution DOIVENT installer des applications via PackageManager dans des bacs à sable Android distincts (ID utilisateur Linux, etc.).

  • Les environnements d'exécution alternatifs PEUVENT fournir un seul bac à sable Android partagé par toutes les applications qui utilisent l'environnement d'exécution alternatif.

9.5. Compatibilité multi-utilisateur

Android est compatible avec plusieurs utilisateurs et offre une isolation complète des utilisateurs.

  • Les implémentations d'appareils PEUVENT, mais NE DOIVENT PAS activer la multi-utilisation si elles utilisent des supports amovibles pour le stockage externe principal.

Si les implémentations d'appareils incluent plusieurs utilisateurs:

  • [C-1-1] DOIT répondre aux exigences suivantes concernant la prise en charge multi-utilisateur.
  • [C-1-2] DOIT, pour chaque utilisateur, implémenter un modèle de sécurité conforme au modèle de sécurité de la plate-forme Android, tel que défini dans le document de référence sur la sécurité et les autorisations des API.
  • [C-1-3] DOIT disposer de répertoires de stockage d'application partagés (/sdcard) distincts et isolés pour chaque instance utilisateur.
  • [C-1-4] DOIT s'assurer que les applications appartenant à un utilisateur donné et exécutées en son nom ne peuvent pas lister, lire ni écrire dans les fichiers appartenant à un autre utilisateur, même si les données des deux utilisateurs sont stockées sur le même volume ou le même système de fichiers.
  • [C-1-5] DOIT chiffrer le contenu de la carte SD lorsque la multi-utilisateur est activée à l'aide d'une clé stockée uniquement sur un support non amovible accessible uniquement au système si les implémentations de l'appareil utilisent un support amovible pour les API de stockage externe. Comme les supports multimédias ne seront plus lisibles par un PC hôte, les implémentations d'appareils devront passer à MTP ou à un système similaire pour fournir aux PC hôtes un accès aux données de l'utilisateur actuel.

Si les implémentations d'appareils incluent plusieurs utilisateurs et ne déclarent pas l'indicateur de fonctionnalité android.hardware.telephony, elles:

  • [C-2-1] DOIT prendre en charge les profils limités, une fonctionnalité qui permet aux propriétaires d'appareils de gérer des utilisateurs supplémentaires et leurs fonctionnalités sur l'appareil. Avec les profils restreints, les propriétaires d'appareils peuvent rapidement configurer des environnements distincts pour les utilisateurs supplémentaires, et gérer des restrictions plus précises dans les applications disponibles dans ces environnements.

Si les implémentations d'appareils incluent plusieurs utilisateurs et déclarent l'indicateur de fonctionnalité android.hardware.telephony, elles:

  • [C-3-1] NE DOIT PAS prendre en charge les profils limités, mais DOIT s'aligner sur l'implémentation des commandes AOSP pour autoriser /interdire à d'autres utilisateurs d'accéder aux appels vocaux et aux SMS.

9.6. Avertissement concernant les SMS premium

Android permet d'avertir les utilisateurs de tout message SMS surtaxé sortant. Les SMS premium sont des messages envoyés à un service enregistré auprès d'un opérateur qui peuvent entraîner des frais pour l'utilisateur.

Si les implémentations d'appareils déclarent la compatibilité avec android.hardware.telephony, elles:

  • [C-1-1] L'appareil DOIT avertir les utilisateurs avant d'envoyer un message SMS à des numéros identifiés par des expressions régulières définies dans le fichier /data/misc/sms/codes.xml. Le projet Android Open Source en amont fournit une implémentation qui répond à cette exigence.

9.7. Fonctionnalités de sécurité

Les implémentations d'appareils DOIVENT garantir la conformité avec les fonctionnalités de sécurité du noyau et de la plate-forme, comme décrit ci-dessous.

Le bac à sable Android inclut des fonctionnalités qui utilisent le système de contrôle des accès obligatoire (MAC) de Security-Enhanced Linux (SELinux), l'exécution en bac à sable seccomp et d'autres fonctionnalités de sécurité du noyau Linux. Implémentations de l'appareil:

  • [C-0-1] DOIT assurer la compatibilité avec les applications existantes, même lorsque SELinux ou toute autre fonctionnalité de sécurité est implémentée sous le framework Android.
  • [C-0-2] L'interface utilisateur ne doit PAS être visible lorsqu'une violation de sécurité est détectée et bloquée par la fonctionnalité de sécurité implémentée sous le framework Android. Toutefois, elle peut être visible lorsqu'une violation de sécurité non bloquée se produit et qu'un exploit est réussi.
  • [C-0-3] L'utilisateur ou le développeur d'applications NE DOIT PAS pouvoir configurer SELinux ou toute autre fonctionnalité de sécurité implémentée sous le framework Android.
  • [C-0-4] Une application pouvant affecter une autre application via une API (telle qu'une API d'administration d'appareils) NE DOIT PAS être autorisée à configurer une règle qui compromet la compatibilité.
  • [C-0-5] Le framework multimédia doit être divisé en plusieurs processus afin de pouvoir accorder un accès plus précis à chaque processus, comme décrit sur le site du projet Android Open Source.
  • [C-0-6] DOIT implémenter un mécanisme de bac à sable d'application de kernel qui permet de filtrer les appels système à l'aide d'une stratégie configurable à partir de programmes multithread. Le projet Android Open Source en amont répond à cette exigence en activant seccomp-BPF avec la synchronisation de threadgroup (TSYNC), comme décrit dans la section "Configuration du kernel" de source.android.com.

L'intégrité du noyau et les fonctionnalités d'autoprotection sont des éléments essentiels de la sécurité Android. Implémentations de l'appareil:

  • [C-0-7] Le kernel doit IMPÉRATIVEMENT implémenter des protections contre les débordements de tampon de pile (par exemple, CONFIG_CC_STACKPROTECTOR_STRONG).
  • [C-0-8] Le noyau doit mettre en œuvre des protections strictes de la mémoire, où le code exécutable est en lecture seule, les données en lecture seule ne sont pas exécutables ni en écriture, et les données en écriture ne sont pas exécutables (par exemple, CONFIG_DEBUG_RODATA ou CONFIG_STRICT_KERNEL_RWX).
  • [C-0-9] DOIT implémenter une vérification des limites de taille d'objets statiques et dynamiques pour les copies entre l'espace utilisateur et l'espace noyau (par exemple, CONFIG_HARDENED_USERCOPY) sur les appareils livrés à l'origine avec le niveau d'API 28 ou version ultérieure.
  • [C-0-10] NE DOIT PAS exécuter de mémoire d'espace utilisateur lors de l'exécution en mode kernel (par exemple, PXN matériel ou émulé via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) sur les appareils livrés à l'origine avec un niveau d'API 28 ou supérieur.
  • [C-0-11] NE DOIT PAS lire ni écrire de mémoire d'espace utilisateur dans le noyau en dehors des API d'accès utilisateurcopy normales (par exemple, PAN matériel ou émulé via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) sur les appareils livrés à l'origine avec un niveau d'API 28 ou supérieur.
  • [C-0-12] VOUS DEVEZ implémenter l'isolation de la table des pages du noyau sur tous les appareils initialement livrés avec le niveau d'API 28 ou version ultérieure (par exemple, CONFIG_PAGE_TABLE_ISOLATION ou "CONFIG_UNMAP_KERNEL_AT_EL0").
  • [SR] Il est vivement recommandé de marquer les données du noyau qui ne sont écrites que lors de l'initialisation comme en lecture seule après l'initialisation (par exemple, __ro_after_init).
  • [SR] Il est FORTEMENT RECOMMANDÉ de randomiser la mise en page du code et de la mémoire du noyau, et d'éviter les expositions qui pourraient compromettre la randomisation (par exemple, CONFIG_RANDOMIZE_BASE avec l'entropie du bootloader via /chosen/kaslr-seed Device Tree node ou EFI_RNG_PROTOCOL).

Si les implémentations d'appareils utilisent un noyau Linux, elles:

  • [C-1-1] DOIT implémenter SELinux.
  • [C-1-2] Vous devez définir SELinux sur le mode d'application forcée global.
  • [C-1-3] Vous devez configurer tous les domaines en mode d'application. Aucun domaine en mode permissif n'est autorisé, y compris les domaines spécifiques à un appareil/vendeur.
  • [C-1-4] Vous NE DEVEZ PAS modifier, omettre ni remplacer les règles neverallow présentes dans le dossier system/sepolicy fourni dans le projet Android Open Source (AOSP) en amont. La stratégie DOIT compiler avec toutes les règles neverallow présentes, à la fois pour les domaines SELinux AOSP et les domaines spécifiques à l'appareil/au fournisseur.
  • [C-1-5] DOIT exécuter des applications tierces ciblant le niveau d'API 28 ou version ultérieure dans des bacs à sable SELinux par application avec des restrictions SELinux par application sur le répertoire de données privées de chaque application.
  • DOIT conserver la règle SELinux par défaut fournie dans le dossier system/sepolicy du projet Open Source Android en amont et ne l'ajouter que pour sa propre configuration spécifique à l'appareil.

Si les implémentations d'appareils sont déjà lancées sur une version antérieure d'Android et ne peuvent pas répondre aux exigences [C-1-1] et [C-1-5] via une mise à jour du logiciel système, elles PEUVENT être exemptées de ces exigences.

Si les implémentations d'appareils utilisent un noyau autre que Linux, elles:

  • [C-2-1] Vous devez utiliser un système de contrôle d'accès obligatoire équivalent à SELinux.

Android contient plusieurs fonctionnalités de défense en profondeur qui sont essentielles à la sécurité de l'appareil.

Implémentations de l'appareil:

  • [C-SR] Il est FORTEMENT RECOMMANDÉ de ne pas désactiver l'intégrité du flux de contrôle (CFI) ou la validation de l'overflow d'entier (IntSan) sur les composants qui l'ont activé.
  • [C-SR] Nous vous RECOMMANDONS vivement d'activer à la fois CFI et IntSan pour tous les composants d'espace utilisateur supplémentaires sensibles à la sécurité, comme expliqué dans CFI et IntSan.

9.8. Confidentialité

9.8.1. Historique d'utilisation

Android stocke l'historique des choix de l'utilisateur et le gère à l'aide de UsageStatsManager.

Implémentations de l'appareil:

  • [C-0-1] DOIT conserver cet historique utilisateur pendant une période de conservation raisonnable.
  • [SR] Nous vous RECOMMANDONS vivement de conserver la période de conservation de 14 jours telle que configurée par défaut dans l'implémentation AOSP.

Android stocke les événements système à l'aide des identifiants StatsLog et gère cet historique via l'API système StatsManager et IncidentManager.

Implémentations de l'appareil:

  • [C-0-2] Le rapport d'incident créé par la classe d'API système IncidentManager DOIT inclure uniquement les champs marqués de DEST_AUTOMATIC.
  • [C-0-3] Vous NE DEVEZ PAS utiliser les identifiants d'événement système pour consigner un événement autre que celui décrit dans les documents du SDK StatsLog. Si des événements système supplémentaires sont consignés, ils PEUVENT utiliser un autre identifiant d'atome compris entre 100 000 et 200 000.

9.8.2. Enregistrement…

Implémentations de l'appareil:

  • [C-0-1] NE DOIT PAS précharger ni distribuer de composants logiciels prêts à l'emploi qui envoient les informations privées de l'utilisateur (par exemple, les frappes au clavier, le texte affiché à l'écran) hors de l'appareil sans l'autorisation de l'utilisateur ni sans notifications claires en cours.

Si les implémentations d'appareils incluent une fonctionnalité dans le système qui capture les contenus affichés à l'écran et/ou enregistre le flux audio lu sur l'appareil, elles:

  • [C-1-1] L'utilisateur doit recevoir une notification continue chaque fois que cette fonctionnalité est activée et qu'elle capture/enregistre activement des données.

Si les implémentations d'appareils incluent un composant activé par défaut, capable d'enregistrer l'audio ambiant pour déduire des informations utiles sur le contexte de l'utilisateur, elles:

  • [C-2-1] NE DOIT PAS stocker dans un espace de stockage persistant sur l'appareil ni transmettre hors de l'appareil l'audio brut enregistré ni tout format pouvant être converti en audio d'origine ou en fac-similé proche, sauf avec le consentement explicite de l'utilisateur.

9.8.3. Connectivité

Si les implémentations d'appareils disposent d'un port USB compatible avec le mode périphérique USB, elles:

  • [C-1-1] DOIT présenter une interface utilisateur demandant le consentement de l'utilisateur avant d'autoriser l'accès au contenu du stockage partagé via le port USB.

9.8.4. Trafic réseau

Implémentations de l'appareil:

  • [C-0-1] DOIT préinstaller les mêmes certificats racine pour le magasin de l'autorité de certification (CA) approuvée par le système que ceux fournis dans le projet Open Source Android en amont.
  • [C-0-2] DOIT être fourni avec un magasin d'autorités de certification racine utilisateur vide.
  • [C-0-3] L'utilisateur doit recevoir un avertissement indiquant que le trafic réseau peut être surveillé lorsqu'une autorité de certification racine utilisateur est ajoutée.

Si le trafic de l'appareil est acheminé via un VPN, les implémentations de l'appareil:

  • [C-1-1] DOIT afficher un avertissement à l'utilisateur indiquant :
    • Ce trafic réseau peut être surveillé.
    • Ce trafic réseau est acheminé via l'application VPN spécifique qui fournit le VPN.

Si les implémentations d'appareils disposent d'un mécanisme, activé par défaut, qui achemine le trafic de données réseau via un serveur proxy ou une passerelle VPN (par exemple, précharger un service VPN avec android.permission.CONTROL_VPN accordé), ils:

  • [C-2-1] DOIT demander l'autorisation de l'utilisateur avant d'activer ce mécanisme, sauf si ce VPN est activé par le contrôleur de stratégie d'appareil via DevicePolicyManager.setAlwaysOnVpnPackage() , auquel cas l'utilisateur n'a pas besoin de donner un consentement distinct, mais DOIT simplement être informé.

Si les implémentations d'appareils implémentent une affordance utilisateur permettant d'activer la fonction "VPN permanent" d'une application VPN tierce, elles:

  • [C-3-1] Vous DEVEZ désactiver cette affordance utilisateur pour les applications qui ne sont pas compatibles avec le service VPN permanent dans le fichier AndroidManifest.xml en définissant l'attribut SERVICE_META_DATA_SUPPORTS_ALWAYS_ON sur false.

9.9. Chiffrement du stockage des données

Si les performances de chiffrement AES (Advanced Encryption Standard), mesurées avec la technologie AES la plus performante disponible sur l'appareil (par exemple, les extensions de cryptographie ARM), sont supérieures à 50 Mo/s, les implémentations de l'appareil:

  • [C-1-1] DOIT prendre en charge le chiffrement du stockage des données des données privées de l'application (partition /data), ainsi que la partition de stockage partagé de l'application (partition /sdcard) s'il s'agit d'une partie permanente et non amovible de l'appareil, à l'exception des implémentations d'appareils généralement partagées (par exemple, la télévision).
  • [C-1-2] DOIT activer le chiffrement du stockage des données par défaut au moment où l'utilisateur a terminé l'expérience de configuration prête à l'emploi, à l'exception des implémentations d'appareils généralement partagées (par exemple, la télévision).

Si les performances de chiffrement AES sont inférieures ou égales à 50 Mo/s, les implémentations d'appareils PEUVENT utiliser Adiantum-XChaCha12-AES au lieu de la forme d'AES listée dans l'une des sections suivantes: AES-256-XTS dans la section 9.9.2 [C-1-5]; AES-256 en mode CBS-CTS dans la section 9.9.2 [C-1-6]; AES dans la section 9.9.3 [C-1-1]; AES dans la section 9.9.3 [C-1-3].

Si les implémentations d'appareils sont déjà lancées sur une version antérieure d'Android et ne peuvent pas répondre à la demande via une mise à jour du logiciel système, elles PEUVENT être exemptées des exigences ci-dessus.

Implémentations de l'appareil:

9.9.1. Démarrage direct

Implémentations de l'appareil:

  • [C-0-1] Les API du mode Démarrage direct doivent être implémentées, même si elles ne sont pas compatibles avec le chiffrement de stockage.

  • [C-0-2] Les intents ACTION_LOCKED_BOOT_COMPLETED et ACTION_USER_UNLOCKED DOIVENT toujours être diffusés pour signaler aux applications compatibles avec le Démarrage direct que les emplacements de stockage chiffré de l'appareil (DE) et chiffré par identifiant (CE) sont disponibles pour l'utilisateur.

9.9.2. Chiffrement basé sur les fichiers

Si les implémentations de l'appareil sont compatibles avec FBE:

  • [C-1-1] DOIT démarrer sans demander à l'utilisateur de fournir des identifiants et autoriser les applications compatibles avec le Démarrage direct à accéder au stockage chiffré de l'appareil (DE) après la diffusion du message ACTION_LOCKED_BOOT_COMPLETED.
  • [C-1-2] DOIT n'autoriser l'accès au stockage chiffré par identifiants (CE) qu'après que l'utilisateur a déverrouillé l'appareil en fournissant ses identifiants (code, code PIN, schéma ou empreinte digitale, par exemple) et que le message ACTION_USER_UNLOCKED a été diffusé.
  • [C-1-3] NE DOIT PAS proposer de méthode permettant de déverrouiller le stockage protégé par le chiffrement côté client sans les identifiants fournis par l'utilisateur ni une clé d'entiercement enregistrée.
  • [C-1-4] DOIT prendre en charge le démarrage validé et s'assurer que les clés de chiffrement côté client sont liées de manière cryptographique à la racine matérielle de confiance de l'appareil.
  • [C-1-5] DOIT prendre en charge le chiffrement du contenu des fichiers à l'aide d'AES-256-XTS. AES-256-XTS fait référence à l'algorithme Advanced Encryption Standard avec une longueur de clé de 256 bits, fonctionnant en mode XTS. La longueur totale de la clé XTS est de 512 bits.

  • [C-1-6] DOIT prendre en charge le chiffrement des noms de fichiers à l'aide d'AES-256 en mode CBC-CTS.

  • Les clés protégeant les zones de stockage CE et DE:

  • [C-1-7] DOIT être lié de manière cryptographique à un Keystore intégré au matériel.

  • [C-1-8] Les clés CE DOIVENT être associées aux identifiants de l'écran de verrouillage de l'utilisateur.
  • [C-1-9] Les clés CE DOIVENT être associées à un code secret par défaut lorsque l'utilisateur n'a pas spécifié d'identifiants pour l'écran de verrouillage.

  • [C-1-10] DOIT être unique et distinct. Autrement dit, la clé CE ou DE d'un utilisateur ne doit pas correspondre à celle d'un autre utilisateur.

  • [C-1-11] DOIT utiliser par défaut les algorithmes de chiffrement, les longueurs de clé et les modes pris en charge de manière obligatoire.

  • [C-SR] Il est FORTEMENT RECOMMANDÉ de chiffrer les métadonnées du système de fichiers, telles que les tailles de fichiers, la propriété, les modes et les attributs étendus (xattr), avec une clé liée de manière cryptographique à la racine de confiance matérielle de l'appareil.

  • DOIT rendre les applications essentielles préinstallées (Alarme, Téléphone, Messenger, par exemple) compatibles avec le Démarrage direct.

  • PEUT prendre en charge d'autres algorithmes de chiffrement, longueurs de clé et modes pour le chiffrement du contenu et du nom des fichiers.

Le projet Open Source Android en amont fournit une implémentation privilégiée de cette fonctionnalité basée sur la fonctionnalité de chiffrement ext4 du noyau Linux.

9.9.3. Chiffrement complet du disque

Si les implémentations de l'appareil sont compatibles avec le chiffrement de disque (FDE), elles:

  • [C-1-1] DOIT utiliser AES dans un mode conçu pour le stockage (par exemple, XTS ou CBC-ESSIV), et avec une longueur de clé de chiffrement d'au moins 128 bits.
  • [C-1-2] DOIT utiliser un code secret par défaut pour encapsuler la clé de chiffrement et NE DOIT PAS écrire la clé de chiffrement dans l'espace de stockage à tout moment sans la chiffrer.
  • [C-1-3] La clé de chiffrement doit être chiffrée par défaut avec AES, sauf si l'utilisateur désactive explicitement cette fonctionnalité, sauf lorsqu'elle est utilisée activement, avec les identifiants de l'écran de verrouillage étirés à l'aide d'un algorithme d'étirement lent (par exemple, PBKDF2 ou scrypt).
  • [C-1-4] L'algorithme de forçage de mot de passe par défaut ci-dessus DOIT être lié de manière cryptographique à ce keystore lorsque l'utilisateur n'a pas spécifié d'identifiants pour l'écran de verrouillage ou a désactivé l'utilisation du code pour le chiffrement, et que l'appareil fournit un keystore basé sur du matériel.
  • [C-1-5] NE DOIT PAS envoyer de clé de chiffrement en dehors de l'appareil (même lorsqu'elle est encapsulée avec le code secret de l'utilisateur et/ou la clé liée au matériel).

Le projet Android Open Source en amont fournit une implémentation privilégiée de cette fonctionnalité, basée sur la fonctionnalité dm-crypt du noyau Linux.

9.10. Intégrité de l'appareil

Les exigences suivantes garantissent la transparence de l'état de l'intégrité de l'appareil. Implémentations de l'appareil:

  • [C-0-1] DOIT indiquer correctement via la méthode PersistentDataBlockManager.getFlashLockState() de l'API système si l'état de son bootloader permet le flashage de l'image système. L'état FLASH_LOCK_UNKNOWN est réservé aux implémentations d'appareils mises à niveau à partir d'une version antérieure d'Android où cette nouvelle méthode d'API système n'existait pas.

  • [C-0-2] L'appareil doit prendre en charge le démarrage validé pour l'intégrité de l'appareil.

Si les implémentations d'appareils sont déjà lancées sans prendre en charge le démarrage validé sur une version antérieure d'Android et qu'elles ne peuvent pas prendre en charge cette fonctionnalité avec une mise à jour logicielle du système, elles PEUVENT être exemptées de cette exigence.

Le démarrage validé est une fonctionnalité qui garantit l'intégrité du logiciel de l'appareil. Si les implémentations de l'appareil sont compatibles avec cette fonctionnalité, elles:

  • [C-1-1] Vous DEVEZ déclarer l'option de fonctionnalité de la plate-forme android.software.verified_boot.
  • [C-1-2] Le système DOIT effectuer une validation à chaque séquence de démarrage.
  • [C-1-3] La validation doit commencer à partir d'une clé matérielle immuable qui est la racine de confiance et s'étendre jusqu'à la partition système.
  • [C-1-4] Vous DEVEZ implémenter chaque étape de vérification pour vérifier l'intégrité et l'authenticité de tous les octets de l'étape suivante avant d'exécuter le code de l'étape suivante.
  • [C-1-5] DOIT utiliser des algorithmes de validation aussi sécurisés que les recommandations actuelles du NIST pour les algorithmes de hachage (SHA-256) et les tailles de clé publique (RSA-2048).
  • [C-1-6] Le démarrage NE DOIT PAS être autorisé à se terminer lorsque la validation du système échoue, sauf si l'utilisateur accepte de tenter de démarrer de toute façon, auquel cas les données de tous les blocs de stockage non validés NE DOIVENT PAS être utilisées.
  • [C-1-7] Le bootloader NE DOIT PAS autoriser la modification des partitions validées sur l'appareil, sauf si l'utilisateur a explicitement déverrouillé le bootloader.
  • [C-SR] Si l'appareil contient plusieurs puces distinctes (par exemple, une radio, un processeur d'image spécialisé), il est FORTEMENT RECOMMANDÉ de vérifier chaque étape du processus de démarrage de chacune de ces puces au démarrage.
  • [C-1-8] DOIT utiliser un stockage inviolable: pour stocker l'état de déverrouillage du bootloader. Le stockage inviolable signifie que le bootloader peut détecter si le stockage a été altéré depuis Android.
  • [C-1-9] DOIT inviter l'utilisateur à confirmer physiquement la transition du mode de verrouillage du bootloader au mode de déverrouillage du bootloader lorsqu'il utilise l'appareil.
  • [C-1-10] DOIT implémenter une protection contre le rollback pour les partitions utilisées par Android (par exemple, les partitions de démarrage et système) et utiliser un stockage inviolable pour stocker les métadonnées utilisées pour déterminer la version minimale de l'OS autorisée.
  • [C-SR] Nous vous RECOMMANDONS vivement de vérifier tous les fichiers APK d'application privilégiés avec une chaîne de confiance enracinée dans /system, qui est protégée par le démarrage validé.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de vérifier les artefacts exécutables chargés par une application privilégiée en dehors de son fichier APK (tel que le code chargé dynamiquement ou le code compilé) avant de les exécuter, ou de ne pas les exécuter du tout.
  • DOIT implémenter une protection contre le rollback pour tout composant doté d'un micrologiciel persistant (par exemple, un modem ou une caméra) et DOIT utiliser un stockage inviolable pour stocker les métadonnées utilisées pour déterminer la version minimale autorisée.

Si les implémentations d'appareils sont déjà lancées sans prendre en charge les exigences C-1-8 à C-1-10 sur une version antérieure d'Android et qu'elles ne peuvent pas être mises à jour pour prendre en charge ces exigences avec une mise à jour du logiciel système, elles PEUVENT être exemptées de ces exigences.

Le projet Android Open Source en amont fournit une implémentation privilégiée de cette fonctionnalité dans le dépôt external/avb/, qui peut être intégrée au bootloader utilisé pour charger Android.

Implémentations de l'appareil:

Si les implémentations de l'appareil sont compatibles avec l'API Android Protected Confirmation, elles:

  • [C-3-1] DOIT signaler true pour l'API ConfirmationPrompt.isSupported().
  • [C-3-2] DOIT s'assurer que le matériel sécurisé prend le contrôle total de l'écran de sorte que le système d'exploitation Android ne puisse pas le bloquer sans être détecté par le matériel sécurisé.
  • [C-3-3] DOIT s'assurer que le matériel sécurisé contrôle entièrement l'écran tactile.

9.11. Clés et identifiants

Le système Android Keystore permet aux développeurs d'applications de stocker des clés cryptographiques dans un conteneur et de les utiliser dans des opérations cryptographiques via l'API KeyChain ou l'API Keystore. Implémentations de l'appareil:

  • [C-0-1] DOIT permettre d'importer ou de générer au moins 8 192 clés.
  • [C-0-2] L'authentification de l'écran de verrouillage DOIT limiter le nombre de tentatives et DOIT comporter un algorithme de délai avant réessai exponentiel. Au-delà de 150 tentatives infructueuses, le délai DOIT être d'au moins 24 heures par tentative.
  • NE DOIT PAS limiter le nombre de clés pouvant être générées

Lorsque l'implémentation de l'appareil est compatible avec un écran de verrouillage sécurisé, elle:

  • [C-1-1] Vous DEVEZ sauvegarder l'implémentation du keystore avec un environnement d'exécution isolé.
  • [C-1-2] DOIT implémenter les algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que les fonctions de hachage de la famille MD5, SHA1 et SHA-2 pour prendre en charge correctement les algorithmes compatibles du système Android Keystore dans une zone isolée de manière sécurisée du code exécuté sur le noyau et au-dessus. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lesquels le code du noyau ou de l'espace utilisateur peut accéder à l'état interne de l'environnement isolé, y compris le DMA. Le projet Android Open Source Project (AOSP) en amont répond à cette exigence en utilisant l'implémentation Trusty, mais une autre solution basée sur ARM TrustZone ou une implémentation sécurisée examinée par un tiers d'une isolation basée sur un hyperviseur approprié sont des options alternatives.
  • [C-1-3] DOIT effectuer l'authentification de l'écran de verrouillage dans l'environnement d'exécution isolé et n'autoriser l'utilisation des clés liées à l'authentification que si l'authentification aboutit. Les identifiants de l'écran de verrouillage DOIVENT être stockés de manière à ne permettre qu'à l'environnement d'exécution isolé d'effectuer l'authentification de l'écran de verrouillage. Le projet Android Open Source en amont fournit la couche d'abstraction matérielle (HAL) Gatekeeper et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
  • [C-1-4] DOIT prendre en charge l'attestation de clé lorsque la clé de signature d'attestation est protégée par du matériel sécurisé et que la signature est effectuée sur du matériel sécurisé. Les clés de signature d'attestation DOIVENT être partagées entre un nombre suffisamment important d'appareils pour éviter qu'elles ne soient utilisées comme identifiants d'appareil. Pour répondre à cette exigence, vous pouvez partager la même clé d'attestation, sauf si au moins 100 000 unités d'un SKU donné sont produites. Si plus de 100 000 unités d'un SKU sont produites, une clé différente PEUT être utilisée pour chaque tranche de 100 000 unités.
  • [C-1-5] DOIT permettre à l'utilisateur de choisir le délai de mise en veille pour la transition de l'état déverrouillé à l'état verrouillé, avec un délai minimal autorisé de 15 secondes.

Notez que si une implémentation d'appareil est déjà lancée sur une version antérieure d'Android, cet appareil n'est pas tenu d'avoir un keystore compatible avec un environnement d'exécution isolé et d'accepter l'attestation de clé, sauf s'il déclare la fonctionnalité android.hardware.fingerprint, qui nécessite un keystore compatible avec un environnement d'exécution isolé.

9.11.1. Écran de verrouillage sécurisé

L'implémentation AOSP suit un modèle d'authentification à plusieurs niveaux, où une authentification primaire basée sur une usine de connaissances peut être étayée par une biométrie secondaire forte ou par des modalités tertiaires plus faibles.

Implémentations de l'appareil:

  • [C-SR] Il est FORTEMENT RECOMMANDÉ de ne définir qu'une seule des méthodes d'authentification suivantes comme méthode d'authentification principale :
    • Un code numérique
    • Un mot de passe alphanumérique
    • Un balayage sur une grille de 3 x 3 points

Notez que les méthodes d'authentification ci-dessus sont désignées comme méthodes d'authentification principales recommandées dans ce document.

Si les implémentations d'appareils ajoutent ou modifient les méthodes d'authentification principales recommandées et utilisent une nouvelle méthode d'authentification pour verrouiller l'écran de manière sécurisée, la nouvelle méthode d'authentification:

Si les implémentations de l'appareil ajoutent ou modifient les méthodes d'authentification pour déverrouiller l'écran de verrouillage si elles sont basées sur un secret connu et qu'elles utilisent une nouvelle méthode d'authentification pour être traitées comme un moyen sécurisé de verrouiller l'écran:

  • [C-3-1] L'entropie de la longueur d'entrée la plus courte autorisée DOIT être supérieure à 10 bits.
  • [C-3-2] L'entropie maximale de toutes les entrées possibles DOIT être supérieure à 18 bits.
  • [C-3-3] La nouvelle méthode d'authentification NE DOIT PAS remplacer l'une des méthodes d'authentification principales recommandées (code, schéma, mot de passe) implémentées et fournies dans AOSP.
  • [C-3-4] La nouvelle méthode d'authentification DOIT être désactivée lorsque l'application DPC (Device Policy Controller) a défini la règle de qualité des mots de passe via la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_SOMETHING.

Si les implémentations d'appareils ajoutent ou modifient les méthodes d'authentification principales recommandées pour déverrouiller l'écran de verrouillage et utilisent une nouvelle méthode d'authentification basée sur la biométrie pour être traitée comme un moyen sécurisé de verrouiller l'écran, la nouvelle méthode:

  • [C-4-1] DOIT respecter toutes les exigences décrites dans la section 7.3.10.2.
  • [C-4-2] DOIT disposer d'un mécanisme de remplacement pour utiliser l'une des méthodes d'authentification principale recommandées, qui est basée sur un secret connu.
  • [C-4-3] DOIT être désactivé et n'autoriser que l'authentification primaire recommandée à déverrouiller l'écran lorsque l'application Device Policy Controller (DPC) a défini la stratégie de fonctionnalité de protection par clé en appelant la méthode DevicePolicyManager.setKeyguardDisabledFeatures(), avec l'un des indicateurs biométriques associés (KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE ou KEYGUARD_DISABLE_IRIS).
  • [C-4-4] DOIT demander à l'utilisateur de fournir l'authentification primaire recommandée (code, schéma, mot de passe, par exemple) au moins une fois toutes les 72 heures.
  • [C-4-5] DOIT avoir un taux de fausse acceptation égal ou supérieur à celui requis pour un lecteur d'empreinte digitale, comme décrit dans la section 7.3.10. Sinon, il DOIT être désactivé et ne permettre que l'authentification primaire recommandée pour déverrouiller l'écran lorsque l'application Device Policy Controller (DPC) a défini la stratégie de qualité du mot de passe via la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_BIOMETRIC_WEAK.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de définir des taux d'acceptation des faux et des imposteurs égaux ou supérieurs à ceux requis pour un lecteur d'empreinte digitale, comme décrit dans la section 7.3.10.
  • [C-4-6] DOIT disposer d'un pipeline de traitement sécurisé de sorte qu'une compromission du système d'exploitation ou du noyau ne permette pas d'injecter directement des données pour s'authentifier faussement en tant qu'utilisateur.
  • [C-4-7] DOIT être associé à une action de confirmation explicite (par exemple, un appui sur un bouton) pour autoriser l'accès aux clés du keystore si l'application définit true pour KeyGenParameterSpec.Built.setUserAuthenticationRequired() et que la biométrie est passive (par exemple, visage ou iris, où aucun signal explicite d'intention n'existe).
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de sécuriser l'action de confirmation pour les données biométriques passives afin qu'un système d'exploitation ou un noyau compromis ne puisse pas la falsifier. Par exemple, cela signifie que l'action de confirmation basée sur un bouton physique est acheminée via une broche GPIO (entrée/sortie à usage général) à usage uniquement en entrée d'un composant sécurisé (SE) qui ne peut être piloté que par pression sur un bouton physique.

Si les méthodes d'authentification biométrique ne respectent pas les taux d'acceptation des attaques par falsification et par usurpation d'identité décrits dans la section 7.3.10:

  • [C-5-1] Les méthodes DOIVENT être désactivées si l'application DPC (Device Policy Controller) a défini la stratégie de qualité du mot de passe via la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_BIOMETRIC_WEAK.
  • [C-5-2] L'utilisateur DOIT être invité à fournir l'authentification principale recommandée (par exemple, code, schéma, mot de passe) après un délai d'inactivité de quatre heures. Le délai d'inactivité est réinitialisé après la confirmation des identifiants de l'appareil.
  • [C-5-3] Les méthodes NE DOIVENT PAS être traitées comme un écran de verrouillage sécurisé et DOIVENT respecter les exigences commençant par C-8 dans cette section ci-dessous.

Si les implémentations de l'appareil ajoutent ou modifient les méthodes d'authentification pour déverrouiller l'écran de verrouillage et qu'une nouvelle méthode d'authentification est basée sur un jeton physique ou sur la position:

  • [C-6-1] Ils DOIVENT disposer d'un mécanisme de remplacement permettant d'utiliser l'une des méthodes d'authentification principale recommandées, qui est basée sur un secret connu et qui répond aux exigences pour être traité comme un écran de verrouillage sécurisé.
  • [C-6-2] La nouvelle méthode DOIT être désactivée et ne doit autoriser qu'une seule des méthodes d'authentification primaires recommandées à déverrouiller l'écran lorsque l'application de contrôle des règles relatives aux appareils (DPC) a défini la stratégie avec la méthode DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) ou la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_UNSPECIFIED.
  • [C-6-3] L'utilisateur DOIT être invité à utiliser l'une des méthodes d'authentification primaires recommandées (code, schéma, mot de passe, par exemple) au moins une fois toutes les 72 heures.
  • [C-6-4] La nouvelle méthode NE DOIT PAS être traitée comme un écran de verrouillage sécurisé et DOIT respecter les contraintes listées dans C-8 ci-dessous.

Si les implémentations d'appareils disposent d'un écran de verrouillage sécurisé et incluent un ou plusieurs agents de confiance, qui implémentent l'API système TrustAgentService, elles:

  • [C-7-1] Le menu des paramètres et l'écran de verrouillage doivent indiquer clairement quand le verrouillage de l'appareil est différé ou peut être déverrouillé par un ou plusieurs agents de confiance. Par exemple, AOSP répond à cette exigence en affichant une description textuelle pour les paramètres "Verrouiller automatiquement" et "Le bouton Marche/Arrêt verrouille instantanément" dans le menu des paramètres, ainsi qu'une icône distincte sur l'écran de verrouillage.
  • [C-7-2] DOIT respecter et implémenter entièrement toutes les API de l'agent de confiance dans la classe DevicePolicyManager, comme la constante KEYGUARD_DISABLE_TRUST_AGENTS.
  • [C-7-3] La fonction TrustAgentService.addEscrowToken() NE DOIT PAS être implémentée entièrement sur un appareil utilisé comme appareil personnel principal (par exemple, un appareil portable), mais elle PEUT être implémentée entièrement sur les implémentations d'appareils qui sont généralement partagées (par exemple, un appareil Android TV ou un appareil automobile).
  • [C-7-4] DOIT chiffrer tous les jetons stockés ajoutés par TrustAgentService.addEscrowToken().
  • [C-7-5] La clé de chiffrement NE DOIT PAS être stockée sur le même appareil que celui sur lequel elle est utilisée. Par exemple, une clé stockée sur un téléphone peut être utilisée pour déverrouiller un compte utilisateur sur une télévision.
  • [C-7-6] DOIT informer l'utilisateur des conséquences sur la sécurité avant d'activer le jeton d'entiercement pour déchiffrer le stockage de données.
  • [C-7-7] DOIT disposer d'un mécanisme de remplacement pour utiliser l'une des méthodes d'authentification principales recommandées.
  • [C-7-8] L'utilisateur DOIT être invité à utiliser l'une des méthodes d'authentification primaire recommandées (par exemple, code, schéma, mot de passe) au moins une fois toutes les 72 heures.
  • [C-7-9] L'utilisateur DOIT être invité à utiliser l'une des méthodes d'authentification primaire recommandées (code, schéma, mot de passe, par exemple) après un délai d'inactivité de quatre heures. Le délai d'inactivité est réinitialisé après la confirmation des identifiants de l'appareil.
  • [C-7-10] NE DOIT PAS être traité comme un écran de verrouillage sécurisé et DOIT respecter les contraintes listées dans C-8 ci-dessous.

Si les implémentations d'appareils ajoutent ou modifient les méthodes d'authentification pour déverrouiller un écran de verrouillage qui n'est pas un écran de verrouillage sécurisé comme décrit ci-dessus, et qu'elles utilisent une nouvelle méthode d'authentification pour déverrouiller le clavier:

9.11.2. StrongBox

Le système Android Keystore permet aux développeurs d'applications de stocker des clés cryptographiques dans un processeur sécurisé dédié, ainsi que dans l'environnement d'exécution isolé décrit ci-dessus.

Implémentations de l'appareil:

  • [C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge StrongBox.

Si les implémentations de l'appareil sont compatibles avec StrongBox, elles:

  • [C-1-1] DOIT déclarer FEATURE_STRONGBOX_KEYSTORE.

  • [C-1-2] DOIT fournir du matériel sécurisé dédié qui est utilisé pour prendre en charge le keystore et sécuriser l'authentification des utilisateurs.

  • [C-1-3] DOIT disposer d'un processeur distinct qui ne partage aucun cache, DRAM, coprocesseur ni autre ressource de base avec le processeur d'application (PA).

  • [C-1-4] DOIT s'assurer que les périphériques partagés avec l'AP ne peuvent en aucun cas modifier le traitement de StrongBox ni obtenir des informations de la part de StrongBox. Le point d'accès peut désactiver ou bloquer l'accès à StrongBox.

  • [C-1-5] DOIT disposer d'une horloge interne avec une précision raisonnable (+-10%) qui est à l'abri de toute manipulation par l'AP.

  • [C-1-6] DOIT disposer d'un véritable générateur de nombres aléatoires qui produit une sortie distribuée uniformément et imprévisible.

  • [C-1-7] DOIT être résistant à la falsification, y compris à la pénétration physique et aux glitchs.

  • [C-1-8] DOIT être résistant aux attaques par canal auxiliaire, y compris contre les fuites d'informations via les canaux auxiliaires d'alimentation, de synchronisation, de rayonnement électromagnétique et de rayonnement thermique.

  • [C-1-9] Le stockage doit être sécurisé et assurer la confidentialité, l'intégrité, l'authenticité, la cohérence et la fraîcheur des contenus. Le stockage NE DOIT PAS pouvoir être lu ni modifié, sauf dans les cas autorisés par les API StrongBox.

  • Pour valider la conformité avec les sections [C-1-3] à [C-1-9], les implémentations d'appareils:

    • [C-1-10] DOIT inclure le matériel certifié selon le profil de protection des cartes à puce sécurisées BSI-CC-PP-0084-2014 ou évalué par un laboratoire de test accrédité au niveau national intégrant une évaluation de la vulnérabilité à haut potentiel d'attaque conformément aux critères communs d'application du potentiel d'attaque aux cartes à puce.
    • [C-1-11] DOIT inclure le micrologiciel évalué par un laboratoire de test accrédité au niveau national, qui intègre une évaluation de la vulnérabilité à haut potentiel d'attaque conformément aux critères communs d'application du potentiel d'attaque aux cartes à puce.
    • [C-SR] Il est FORTEMENT RECOMMANDÉ d'inclure le matériel évalué à l'aide d'une cible de sécurité, d'un niveau d'assurance d'évaluation (EAL) 5, complété par AVA_VAN.5. La certification EAL 5 deviendra probablement obligatoire dans une prochaine version.

  • [C-SR] sont FORTEMENT RECOMMANDÉS pour assurer la résistance aux attaques internes (IAR), ce qui signifie qu'un initié ayant accès aux clés de signature du micrologiciel ne peut pas produire de micrologiciel qui provoque une fuite de secrets par la StrongBox, pour contourner les exigences de sécurité fonctionnelles ou pour permettre l'accès à des données utilisateur sensibles. La méthode recommandée pour implémenter l'IAR consiste à n'autoriser les mises à jour du micrologiciel que lorsque le mot de passe utilisateur principal est fourni via le HAL IAuthSecret.

9.12. Suppression des données

Toutes les implémentations d'appareils:

  • [C-0-1] DOIT fournir aux utilisateurs un mécanisme permettant de rétablir la configuration d'usine.
  • [C-0-2] Vous devez supprimer toutes les données générées par l'utilisateur. Autrement dit, toutes les données, à l'exception des suivantes :
    • Image système
    • Tous les fichiers du système d'exploitation requis par l'image système
  • [C-0-3] DOIT supprimer les données de manière à respecter les normes du secteur applicables, telles que la norme NIST SP800-88.
  • [C-0-4] DOIT déclencher le processus "Réinitialisation des données d'usine" ci-dessus lorsque l'API DevicePolicyManager.wipeData() est appelée par l'application de contrôle des règles relatives aux appareils de l'utilisateur principal.
  • PEUT fournir une option de suppression rapide des données qui ne s'effectue qu'au niveau logique.

9.13. Mode démarrage sécurisé

Android propose le mode Démarrage sécurisé, qui permet aux utilisateurs de démarrer en mode où seules les applications système préinstallées sont autorisées à s'exécuter et toutes les applications tierces sont désactivées. Ce mode, appelé "mode Démarrage sécurisé", permet à l'utilisateur de désinstaller les applications tierces potentiellement dangereuses.

Les implémentations d'appareils sont les suivantes:

  • [SR] STRONGLY RECOMMENDED to implement Safe Boot Mode.

Si les implémentations d'appareils implémentent le mode de démarrage sécurisé, elles:

  • [C-1-1] DOIT fournir à l'utilisateur la possibilité de passer en mode Démarrage sécurisé de manière ininterrompue par les applications tierces installées sur l'appareil, sauf lorsque l'application tierce est un contrôleur de stratégie d'appareil et qu'elle a défini l'indicateur UserManager.DISALLOW_SAFE_BOOT sur "true".

  • [C-1-2] L'appareil DOIT permettre à l'utilisateur de désinstaller toutes les applications tierces en mode sans échec.

  • DOIT fournir à l'utilisateur la possibilité d'accéder au mode de démarrage sécurisé à partir du menu de démarrage à l'aide d'un workflow différent de celui d'un démarrage normal.

9.14. Isolation du système de véhicule automobile

Les appareils Android Automotive doivent échanger des données avec les sous-systèmes critiques du véhicule à l'aide du HAL du véhicule pour envoyer et recevoir des messages sur les réseaux du véhicule, tels que le bus CAN.

L'échange de données peut être sécurisé en implémentant des fonctionnalités de sécurité sous les couches du framework Android pour éviter toute interaction malveillante ou involontaire avec ces sous-systèmes.

9.15. Abonnements

Les "forfaits" désignent les détails du forfait de facturation fournis par un opérateur mobile via SubscriptionManager.setSubscriptionPlans().

Toutes les implémentations d'appareils:

  • [C-0-1] DOIT renvoyer les forfaits d'abonnement uniquement à l'application du fournisseur de services mobiles qui les a initialement fournis.
  • [C-0-2] Vous NE DEVEZ PAS sauvegarder ni importer à distance des abonnements.
  • [C-0-3] DOIT n'autoriser que les forçages, tels que SubscriptionManager.setSubscriptionOverrideCongested(), provenant de l'application du fournisseur de services mobiles qui propose actuellement des forfaits d'abonnement valides.

10. Tests de compatibilité des logiciels

Les implémentations d'appareils DOIVENT réussir tous les tests décrits dans cette section. Toutefois, notez qu'aucun package de test logiciel n'est totalement complet. C'est pourquoi il est FORTEMENT RECOMMANDÉ aux implémentateurs d'appareils de procéder au minimum de modifications possibles à l'implémentation de référence et privilégiée d'Android 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 retouches et des mises à jour potentielles de l'appareil.

10.1. Compatibility Test Suite

Implémentations de l'appareil:

  • [C-0-1] DOIT réussir les tests de la suite de tests de compatibilité Android (CTS) disponible sur le projet Android Open Source, à l'aide du logiciel final installé sur l'appareil.

  • [C-0-2] DOIT assurer la compatibilité en cas d'ambiguïté dans le CTS et pour toute réimplémentation de parties du code source de référence.

Le CTS est conçu pour être exécuté sur un appareil réel. Comme tout logiciel, le CTS peut lui-même contenir des bugs. La version du CTS sera indépendante de cette définition de la compatibilité, et plusieurs révisions du CTS peuvent être publiées pour Android 9.

Implémentations de l'appareil:

  • [C-0-3] DOIT réussir les tests de la dernière version du CTS disponible au moment de la finalisation du logiciel de l'appareil.

  • DOIT utiliser autant que possible l'implémentation de référence dans l'arborescence Open Source Android.

10.2. Validateur 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.

Implémentations de l'appareil:

  • [C-0-1] DOIT exécuter correctement tous les cas applicables dans le vérificateur CTS.

Le vérificateur CTS propose des tests pour de nombreux types de matériel, y compris certains matériels facultatifs.

Implémentations de l'appareil:

  • [C-0-2] DOIT réussir tous les tests du matériel dont il dispose. Par exemple, si un appareil possède un accéléromètre, il DOIT exécuter correctement le scénario de test de l'accéléromètre dans le vérificateur CTS.

Les cas de test des fonctionnalités indiquées comme facultatives dans ce document de définition de la compatibilité PEUVENT être ignorés ou omis.

  • [C-0-2] 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 des versions qui ne diffèrent que de manière triviale. Plus précisément, les implémentations d'appareils qui ne diffèrent d'une implémentation ayant réussi le vérificateur CTS que par l'ensemble de paramètres régionaux inclus, de la marque, etc. PEUVENT omettre le test du vérificateur CTS.

11. Logiciels pouvant être mis à jour

  • [C-0-1] Les implémentations d'appareils DOIVENT inclure un mécanisme permettant de remplacer l'intégralité du logiciel système. Le mécanisme n'a pas besoin d'effectuer de mises à niveau en temps réel. Autrement dit, un redémarrage de l'appareil peut être nécessaire. Vous pouvez utiliser n'importe quelle méthode, à 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 OTA (Over The Air) avec mise à jour hors connexion via un redémarrage.
    • Mises à jour "partagée" via USB à partir d'un PC hôte.
    • Mises à jour "hors connexion" via un redémarrage et une mise à jour à partir d'un fichier sur un stockage amovible.

  • [C-0-2] Le mécanisme de mise à jour utilisé DOIT permettre les mises à jour sans effacer les données utilisateur. Autrement dit, 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 les implémentations de l'appareil prennent en charge une connexion de données illimitée, telle que le profil 802.11 ou le profil Bluetooth PAN (Personal Area Network), elles:

  • [C-1-1] DOIT prendre en charge les téléchargements OTA avec mise à jour hors connexion via le redémarrage.

Pour les implémentations d'appareils lancées avec Android 6.0 ou version ultérieure, le mécanisme de mise à jour DOIT permettre de vérifier que l'image système est identique au résultat attendu après une mise à jour OTA. L'implémentation OTA basée sur les blocs dans le projet Android Open Source en amont, ajoutée depuis Android 5.1, répond à cette exigence.

De plus, les implémentations d'appareils DOIVENT prendre en charge les mises à jour système A/B. L'AOSP implémente cette fonctionnalité à l'aide du HAL de contrôle du démarrage.

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, et qu'elle affecte la compatibilité des applications tierces:

  • [C-2-1] 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.

Android inclut des fonctionnalités qui permettent à l'application propriétaire de l'appareil (le cas échéant) de contrôler l'installation des mises à jour du système. Si le sous-système de mise à jour du système pour les appareils signale android.software.device_admin, les appareils:

12. Journal des modifications du document

Pour obtenir un résumé des modifications apportées à la définition de la compatibilité dans cette version:

Pour obtenir un résumé des modifications apportées aux sections sur les personnes:

  1. Introduction
  2. Types d'appareils
  3. Logiciels
  4. Emballage d'application
  5. Multimédia
  6. Outils et options pour les développeurs
  7. Compatibilité matérielle
  8. Performances et puissance
  9. Modèle de sécurité
  10. Tests de compatibilité logicielle
  11. Logiciels pouvant être mis à jour
  12. Journal des modifications du document
  13. Nous contacter

12.1. Conseils pour afficher le journal des modifications

Les modifications sont marquées comme suit:

  • CDD
    Modifications substantielles apportées aux exigences de compatibilité.

  • Documentation
    Modifications esthétiques ou liées à la compilation.

Pour une meilleure visibilité, ajoutez les paramètres d'URL pretty=full et no-merges à vos URL de journal des modifications.

13. Nous contacter

Vous pouvez rejoindre le forum sur la compatibilité Android et demander des précisions ou signaler les problèmes que vous pensez ne pas être couverts par le document.