Définition de la compatibilité avec Android 10

1. Introduction

Ce document énumère les exigences à respecter pour que les appareils soient compatibles avec Android 10.

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 le document RFC2119.

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

Pour être considérées comme compatibles avec Android 10, les implémentations d'appareils DOIVENT répondre aux 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émenteur de l'appareil d'assurer la compatibilité avec les implémentations existantes.

C'est pourquoi le Projet Android Open Source est à la fois la référence et l'implémentation privilégiée d'Android. Il est FORTEMENT RECOMMANDÉ aux développeurs d'appareils de baser leurs implémentations autant que possible sur le code source "en amont" disponible sur le projet Android Open Source. Bien que certains composants puissent théoriquement être remplacés par des implémentations alternatives, il est FORTEMENT DÉCONSEILLÉ de le faire, car il deviendra beaucoup plus difficile de réussir les tests logiciels. Il incombe à l'implémenteur d'assurer 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 le présent document.

La plupart des ressources auxquelles ce document renvoie sont issues directement ou indirectement du SDK Android. Elles sont donc fonctionnellement identiques aux informations de la documentation de ce SDK. Dans tous les cas où cette définition de compatibilité ou la suite de tests de compatibilité ne sont pas d'accord avec la documentation du SDK, cette dernière est considérée comme faisant autorité. Tous les détails techniques fournis dans les ressources associées tout au long de ce document sont considérés comme faisant partie de cette définition de 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 après la section 2. Dans ce document, ces exigences sont appelées "Exigences de base".

1.1.2. ID de l'exigence

Un ID d'exigence est attribué aux exigences MUST.

  • L'ID n'est attribué qu'aux exigences MUST.
  • Les exigences FORTEMENT RECOMMANDÉES sont marquées [SR], mais aucun ID n'est attribué.
  • L'ID se compose de l'ID du type d'appareil, de l'ID de la condition et de l'ID de l'exigence (par exemple, C-0-1).

Chaque ID est défini comme suit :

  • ID du type d'appareil (voir 2. Types d'appareils)
    • C : Core (exigences appliquées à toutes les implémentations d'appareils Android)
    • H : Appareil Android portable
    • T: Appareil Android TV
    • R : Implémentation d'Android Automotive
    • W: Android Watch implementation
    • 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, la valeur 1 est attribuée à la première condition. Le nombre augmente de 1 dans la même section et pour le même type d'appareil.
  • ID de l'exigence
    • 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 d'exigence de la section 2 commence par l'ID de section correspondant, suivi de l'ID d'exigence décrit ci-dessus.

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

2. Types d'appareils

Bien que l'Android Open Source Project 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 toujours répondre à 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 par type d'appareil, consultez les exigences spécifiques aux appareils qui suivent dans cette section.

2.2. Exigences concernant les appareils mobiles

Un appareil mobile Android désigne une implémentation d'appareil Android qui est généralement utilisée en la 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 "Appareil mobile" si elles répondent à tous les critères suivants :

  • être alimenté par une source d'énergie mobile, comme une batterie ;
  • avoir une taille d'écran physique (diagonale) comprise entre 2,5 et 8 pouces ;

Les exigences supplémentaires du reste de cette section sont spécifiques aux implémentations sur les appareils mobiles Android.

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 sur les appareils mobiles :

  • [7.1.1.1/H-0-1] DOIT disposer d'au moins un écran compatible avec Android d'une diagonale physique d'au moins 2,5 pouces, et chaque écran compatible avec Android DOIT répondre à toutes les exigences décrites dans le présent document.
  • [7.1.1.3/H-SR] Il est FORTEMENT RECOMMANDÉ de permettre aux utilisateurs de modifier la taille d'affichage (densité d'écran).

Si les implémentations d'appareils portables affirment prendre en charge les écrans HDR (High Dynamic Range) via Configuration.isScreenHdr() , elles :

  • [7.1.4.5/H-1-1] DOIT annoncer 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 sur 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'il est implémenté par le code source Android Open Source en amont. Autrement dit, les implémentations d'appareils NE DOIVENT PAS modifier les déclencheurs ni les seuils d'activation du mode de compatibilité, et NE DOIVENT PAS modifier le comportement du mode de compatibilité lui-même.
  • [7.2.1/H-0-1] DOIT inclure la prise en charge des applications tierces d'éditeur de méthode de saisie (IME).
  • [7.2.3/H-0-3] DOIT fournir la fonction Accueil sur tous les écrans compatibles avec Android qui fournissent l'écran d'accueil.
  • [7.2.3/H-0-4] DOIT fournir la fonction Retour sur tous les écrans compatibles avec Android et la fonction Récents sur au moins l'un des écrans compatibles avec Android.
  • [7.2.3/H-0-2] DOIT envoyer l'événement d'appui normal et l'événement d'appui prolongé de la fonction Retour (KEYCODE_BACK) à l'application au premier plan. 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, un clavier matériel externe connecté à l'appareil Android).
  • [7.2.4/H-0-1] DOIT prendre en charge la saisie sur é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é gérant ACTION_ASSIST en cas d'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 être capable de signaler des événements jusqu'à une fréquence d'au moins 100 Hz.

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

  • [7.3.3/H-2-1] DOIT indiquer les mesures GNSS dès qu'elles sont trouvées, même si aucune position calculée à partir du GPS/GNSS n'est encore indiquée.
  • [7.3.3/H-2-2] DOIT indiquer les pseudo-distances et les taux de pseudo-distance GNSS qui, dans des conditions de ciel dégagé après avoir déterminé la position, à l'arrêt ou en mouvement avec une accélération inférieure à 0, 2 mètre par seconde au carré, sont suffisants pour calculer la position à 20 mètres près et la vitesse à 0, 2 mètre par seconde près, au moins 95 % du temps.

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

  • [7.3.4/H-3-1] DOIT être capable de signaler des événements jusqu'à une fréquence d'au moins 100 Hz.
  • [7.3.4/H-3-2] DOIT être capable de mesurer les changements d'orientation jusqu'à 1 000 degrés par seconde.

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

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

Implémentations sur les appareils mobiles :

  • [7.3.11/H-SR] Il est RECOMMANDÉ de prendre en charge le capteur de pose avec 6 degrés de liberté.
  • [7.4.3/H] DOIT inclure la prise en charge de Bluetooth et 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.

Si les implémentations d'appareils portables incluent un périphérique de caméras logiques qui liste les fonctionnalités à l'aide de CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, elles :

  • [7.5.4/H-1-1] Le champ de vision (FOV) doit être normal par défaut et compris entre 50 et 90 degrés.

Implémentations sur les appareils mobiles :

  • [7.6.1/H-0-1] DOIT disposer d'au moins 4 Go de stockage non volatile disponible pour les données privées de l'application (c'est-à-dire la 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 mobiles 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 mémoire 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 framebuffer 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 mémoire tampon de trame jusqu'à QHD (par exemple, QWXGA).

Si les implémentations d'appareils portables déclarent la prise en charge d'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 mémoire tampon de trame 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'écran par défaut utilise des résolutions de mémoire tampon de trame jusqu'à QHD (par exemple, QWXGA).

Notez que la "mémoire disponible pour le noyau et l'espace utilisateur" ci-dessus fait référence à l'espace mémoire fourni en plus de toute 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 noyau sur les implémentations d'appareils.

Si les implémentations d'appareils mobiles incluent 1 Go de mémoire ou moins 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 des applications (c'est-à-dire la 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] DOIT disposer d'au moins 4 Go de stockage non volatile disponible pour les données privées de l'application (c'est-à-dire la partition "/data").
  • DOIT déclarer le commutateur de fonctionnalité android.hardware.ram.normal.

Implémentations sur les appareils mobiles :

  • [7.6.2/H-0-1] NE DOIT PAS fournir un stockage partagé d'application inférieur à 1 Gio.
  • [7.7.1/H] DOIT inclure un port USB prenant en charge le mode périphérique.

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

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

  • [7.7.2/H-1-1] DOIT implémenter la classe audio USB, comme indiqué dans la documentation du SDK Android.

Implémentations sur 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 la prise en charge du mode VR et incluent cette prise en charge, 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 VR via android.app.Activity#setVrModeEnabled.

Si les implémentations d'appareils portables incluent un ou plusieurs ports USB-C en mode hôte et implémentent la classe audio USB, en plus des exigences de la section 7.7.2, elles :

  • [7.8.2.2/H-1-1] DOIT fournir le mappage logiciel suivant des codes HID :
Fonction Mappages Contexte Comportement
A Page d'utilisation HID : 0x0C
Utilisation HID : 0x0CD
Clé du noyau : KEY_PLAYPAUSE
Clé Android : KEYCODE_MEDIA_PLAY_PAUSE 		Lecture des contenus multimédias Entrée : appui bref sur
Sortie : lecture ou pause
Entrée : appuyer de manière prolongée sur
Sortie : lancer la commande vocale
Envoi : android.speech.action.VOICE_SEARCH_HANDS_FREE si l'appareil est verrouillé ou si son écran est éteint. Envoi de android.speech.RecognizerIntent.ACTION_WEB_SEARCH dans le cas contraire
Appel entrant Entrée : appui bref sur
Sortie : accepter l'appel
Entrée : appuyer de manière prolongée sur
Sortie : refuser l'appel
Appel en cours Entrée : appui bref
Sortie : mettre fin à l'appel
Entrée : appui prolongé sur
Sortie : activer ou couper le micro
B Page d'utilisation HID : 0x0C
Utilisation HID : 0x0E9
Clé du noyau : KEY_VOLUMEUP
Clé Android : VOLUME_UP 		Lecture de contenus multimédias, Appel en cours Entrée : appui bref ou long sur
Sortie : augmente le volume du système ou du casque
C Page d'utilisation HID : 0x0C
Utilisation HID : 0x0EA
Clé du noyau : KEY_VOLUMEDOWN
Clé Android : VOLUME_DOWN 		Lecture de contenus multimédias, Appel en cours Entrée : appuyez brièvement ou longuement sur
Sortie : baisse le volume du système ou du casque
D Page d'utilisation HID : 0x0C
Utilisation HID : 0x0CF
Clé du noyau : KEY_VOICECOMMAND
Clé Android : KEYCODE_VOICE_ASSIST 		Tous. Peut être déclenché dans n'importe quelle instance. Entrée : appui bref ou long
Sortie : lancer une commande vocale
  • [7.8.2.2/H-1-2] DOIT déclencher ACTION_HEADSET_PLUG lors de l'insertion d'une prise, mais uniquement après que les interfaces et points de terminaison audio USB ont été correctement énumérés afin d'identifier le type de terminal connecté.

Lorsque les types de terminaux audio USB 0x0302 sont détectés, ils :

  • [7.8.2.2/H-2-1] DOIT diffuser l'Intent ACTION_HEADSET_PLUG avec l'extra "microphone" défini sur 0.

Lorsque les types de terminaux audio USB 0x0402 sont détectés, ils :

  • [7.8.2.2/H-3-1] DOIT diffuser l'Intent ACTION_HEADSET_PLUG avec l'extra "microphone" défini sur 1.

Lorsque l'API AudioManager.getDevices() est appelée alors que le périphérique USB est connecté :

  • [7.8.2.2/H-4-1] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_HEADSET et le rôle isSink() si le champ de type de terminal audio USB est 0x0302.

  • [7.8.2.2/H-4-2] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_HEADSET et role isSink() si le champ de type de terminal audio USB est 0x0402.

  • [7.8.2.2/H-4-3] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_HEADSET et le rôle isSource() si le champ du type de terminal audio USB est 0x0402.

  • [7.8.2.2/H-4-4] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_DEVICE et le rôle isSink() si le champ du type de terminal audio USB est 0x603.

  • [7.8.2.2/H-4-5] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_DEVICE et de rôle isSource() si le champ de type de terminal audio USB est 0x604.

  • [7.8.2.2/H-4-6] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_DEVICE et role isSink() si le champ de type de terminal audio USB est 0x400.

  • [7.8.2.2/H-4-7] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_DEVICE et le rôle isSource() si le champ du type de terminal audio USB est 0x400.

  • [7.8.2.2/H-SR] Il est FORTEMENT RECOMMANDÉ d'effectuer l'énumération des descripteurs USB, d'identifier les types de terminaux et de diffuser l'Intent ACTION_HEADSET_PLUG en moins de 1 000 millisecondes lors de la connexion d'un périphérique audio USB-C.

2.2.2. Multimédia

Les implémentations sur les appareils portables DOIVENT être compatibles avec les formats d'encodage et de décodage audio suivants, et les mettre à la disposition des applications tierces :

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

Les implémentations sur les appareils portables DOIVENT être compatibles avec les formats d'encodage vidéo suivants et les mettre à la disposition des applications tierces :

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

Les implémentations sur les appareils portables DOIVENT être compatibles avec les formats de décodage vidéo suivants et les mettre à la disposition des applications tierces :

  • [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 sur les appareils mobiles :

  • [3.2.3.1/H-0-1] DOIT disposer d'une application qui gère les intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE et ACTION_CREATE_DOCUMENT comme décrit dans la documentation 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 générale des utilisateurs.
  • [3.8.1/H-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter un lanceur d'applications par défaut qui prend en charge l'épinglage dans l'application des raccourcis, des widgets et des widgetFeatures.
  • [3.8.1/H-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter un lanceur d'applications par défaut qui offre un accès rapide 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 d'applications 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] DOIT autoriser les applications tierces à informer les utilisateurs d'événements notables via les classes d'API Notification et NotificationManager.
  • [3.8.3/H-0-2] DOIT être compatible avec 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 un panneau de notifications, permettant à l'utilisateur de contrôler directement les notifications (par exemple, y répondre, les mettre en veille, les ignorer ou les bloquer) grâce à des fonctionnalités telles que des boutons d'action ou le panneau de configuration, comme implémenté dans l'AOSP.
  • [3.8.3/H-0-5] DOIT afficher les choix fournis par le biais de RemoteInput.Builder setChoices() dans le volet de notification.
  • [3.8.3/H-SR] Il est FORTEMENT RECOMMANDÉ d'afficher le premier choix fourni par le biais de RemoteInput.Builder setChoices() dans la barre de notification sans interaction supplémentaire de l'utilisateur.
  • [3.8.3/H-SR] Il est FORTEMENT RECOMMANDÉ d'afficher tous les choix fournis par RemoteInput.Builder setChoices() dans le volet des notifications lorsque l'utilisateur développe toutes les notifications dans le volet des notifications.
  • [3.8.3.1/H-SR] Il est FORTEMENT RECOMMANDÉ d'afficher les actions pour lesquelles Notification.Action.Builder.setContextual est défini sur true en ligne avec les réponses affichées par Notification.Remoteinput.Builder.setChoices.
  • [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 mobiles sont compatibles avec l'action Assist, elles :

  • [3.8.4/H-SR] Il est FORTEMENT RECOMMANDÉ d'utiliser un 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é gérant l'intent ACTION_ASSIST.

Si les implémentations d'appareils mobiles Android 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 règles 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é de manière à se déclarer comme un appareil à faible RAM ou de manière à allouer un stockage interne (non amovible) comme stockage partagé.

Implémentations sur les appareils mobiles :

  • [3.10/H-0-1] DOIT être compatible avec 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 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.
  • [3.11/H-0-1] DOIT permettre 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 prenant en charge les langues disponibles sur l'appareil.
  • [3.13/H-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un composant d'UI Paramètres rapides.

Si les implémentations d'appareils portables Android déclarent la compatibilité avec FEATURE_BLUETOOTH ou FEATURE_WIFI, elles :

  • [3.16/H-1-1] DOIT être compatible avec la fonctionnalité d'association d'appareils associés.

Si la fonction de navigation est fournie sous la forme d'une action gestuelle à l'écran :

  • [7.2.3/H] La zone de reconnaissance des gestes pour la fonction Accueil NE DOIT PAS dépasser 32 dp de hauteur à partir du bas de l'écran.

Si les implémentations d'appareils portables fournissent une fonction de navigation par geste depuis n'importe quel point des bords gauche et droit de l'écran :

  • [7.2.3/H-0-1] La zone de gestes de la fonction de navigation DOIT avoir une largeur inférieure à 40 dp de chaque côté. La zone de geste DOIT avoir une largeur de 24 dp par défaut.

2.2.4. Performances et puissance

  • [8.1/H-0-1] Latence d'image cohérente. La latence d'images incohérente ou le retard 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] Multitâche. Lorsqu'une application déjà en cours d'exécution est relancée après le lancement de plusieurs applications, cela DOIT prendre moins d'une seconde.

Implémentations sur 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 garantir 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 permettant d'améliorer 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] DOIT permettre à l'utilisateur d'activer et de désactiver la fonctionnalité d'économiseur de batterie.
  • [8.3/H-1-2] DOIT fournir à l'utilisateur un moyen d'afficher toutes les applications exemptées des modes d'économie d'énergie Mise en veille des applications et Sommeil.

Implémentations sur les appareils mobiles :

  • [8.4/H-0-1] DOIT fournir un profil de consommation électrique par composant qui définit la valeur de consommation de courant pour chaque composant matériel et la décharge de batterie approximative causée par les composants au fil du temps, comme indiqué sur le site Android Open Source Project.
  • [8.4/H-0-2] DOIT indiquer toutes les valeurs de consommation d'énergie en milliampères-heures (mAh).
  • [8.4/H-0-3] DOIT signaler la consommation d'énergie du processeur pour chaque UID de 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] DOIT mettre cette consommation d'énergie à la disposition du développeur d'applications via la commande shell adb shell dumpsys batterystats.
  • [8.4/H] DOIT être attribué au composant matériel lui-même s'il est impossible d'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 sur 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 aux utilisateurs pour accorder ou révoquer l'accès à ces applications en réponse à l'intention android.settings.ACTION_USAGE_ACCESS_SETTINGS.

Implémentations pour les appareils portables (* non applicable aux tablettes) :

  • [9.11/H-0-2]* DOIT sauvegarder l'implémentation du keystore avec un environnement d'exécution isolé.
  • [9.11/H-0-3]* DOIT implémenter les algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que les fonctions de hachage MD5, SHA1 et de la famille SHA-2 pour prendre correctement en charge les algorithmes compatibles du système Android Keystore dans une zone sécurisée et isolée du code s'exécutant 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 pourrait 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 d'autres solutions basées sur ARM TrustZone ou une implémentation sécurisée tierce et examinée d'une isolation appropriée basée sur un hyperviseur sont également possibles.
  • [9.11/H-0-4]* 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 qu'en cas de succès. Les identifiants de l'écran de verrouillage DOIVENT être stockés de manière à ce que seul l'environnement d'exécution isolé puisse 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.
  • [9.11/H-0-5]* DOIT prendre en charge l'attestation de clé, où la clé de signature de l'attestation est protégée par un matériel sécurisé et la signature est effectuée dans un matériel sécurisé. Les clés de signature d'attestation DOIVENT être partagées sur un nombre d'appareils suffisamment important pour empêcher 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.

Notez que si une implémentation d'appareil est déjà lancée sur une version antérieure d'Android, cet appareil est exempté de l'obligation d'avoir un keystore soutenu par un environnement d'exécution isolé et de prendre en charge l'attestation de clé, sauf s'il déclare la fonctionnalité android.hardware.fingerprint qui nécessite un keystore soutenu par un environnement d'exécution isolé.

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

  • [9.11/H-1-1] 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 permettre à l'utilisateur de masquer les notifications et de désactiver toutes les formes d'authentification, à l'exception de l'authentification principale décrite dans 9.11.1 Écran de verrouillage sécurisé. L'AOSP répond à l'exigence en tant que mode verrouillé.

Si les implémentations d'appareils mobiles incluent plusieurs utilisateurs et ne déclarent pas l'indicateur de fonctionnalité android.hardware.telephony, elles :

  • [9.5/H-2-1] DOIT être compatible avec les profils limités, une fonctionnalité qui permet aux propriétaires d'appareils de gérer d'autres utilisateurs et leurs capacités sur l'appareil. Grâce aux profils restreints, les propriétaires d'appareils peuvent rapidement configurer des environnements distincts pour que d'autres utilisateurs puissent y travailler. Ils peuvent également gérer des restrictions plus précises dans les applications disponibles dans ces environnements.

Si les implémentations d'appareils portables incluent plusieurs utilisateurs et déclarent l'indicateur de fonctionnalité android.hardware.telephony, elles :

  • [9.5/H-3-1] NE DOIT PAS être compatible avec les profils restreints, mais DOIT s'aligner sur l'implémentation AOSP des commandes permettant d'autoriser /d'interdire l'accès aux appels vocaux et aux SMS pour les autres utilisateurs.

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

Implémentations pour les appareils portables (* non applicable aux tablettes) :

  • [6.1/H-0-1]* DOIT être compatible avec la commande shell cmd testharness.

Implémentations pour les appareils portables (* non applicable aux tablettes) :

  • Perfetto
    • [6.1/H-0-2]* DOIT exposer un binaire /system/bin/perfetto à l'utilisateur du shell dont la ligne de commande est conforme à la documentation de Perfetto.
    • [6.1/H-0-3]* Le binaire perfetto DOIT accepter en entrée une configuration protobuf conforme au schéma défini dans la documentation perfetto.
    • [6.1/H-0-4]* Le binaire perfetto DOIT écrire en sortie une trace protobuf conforme au schéma défini dans la documentation perfetto.
    • [6.1/H-0-5]* DOIT fournir, via le binaire perfetto, au moins les sources de données décrites dans la documentation perfetto.

2.3. Exigences concernant le téléviseur

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

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

  • fourni un mécanisme permettant de contrôler à distance l'interface utilisateur affichée sur l'écran qui peut se trouver à trois mètres de l'utilisateur.
  • Disposer d'un écran intégré dont la diagonale est supérieure à 61 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 de télévision :

  • [7.2.2/T-0-1] DOIT être compatible avec le pavé directionnel.
  • [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 l'événement de pression longue 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 sans contact et aux touches de navigation principales.

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

  • [7.3.4/T-1-1] DOIT être capable de signaler des événements jusqu'à une fréquence d'au moins 100 Hz.
  • [7.3.4/T-1-2] DOIT être capable de mesurer les changements d'orientation jusqu'à 1 000 degrés par seconde.

Implémentations d'appareils de télévision :

  • [7.4.3/T-0-1] DOIT être compatible avec Bluetooth et Bluetooth LE.
  • [7.6.1/T-0-1] DOIT disposer d'au moins 4 Go de stockage non volatile disponible pour les données privées de l'application (c'est-à-dire la 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 inclure la prise en charge d'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 des appareils TV sont en 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 ou moyenne taille
    • xhdpi ou supérieur sur les grands écrans
    • tvdpi ou plus sur les écrans très grands

Si les implémentations d'appareils TV sont en 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 ou moyenne taille
    • xhdpi ou supérieur sur les grands écrans
    • tvdpi ou plus sur les écrans très grands

Notez que la "mémoire disponible pour le noyau et l'espace utilisateur" ci-dessus fait référence à l'espace mémoire fourni en plus de toute 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 noyau sur les implémentations d'appareils.

Implémentations d'appareils de télévision :

  • [7.8.1/T] DOIT inclure un micro.
  • [7.8.2/T-0-1] DOIT disposer d'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 et de décodage audio suivants et les mettre à la disposition des applications tierces :

  • [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 à latence faible amélioré)

Les implémentations de téléviseurs DOIVENT être compatibles avec les formats d'encodage vidéo suivants et les mettre à la disposition des applications tierces :

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

Implémentations d'appareils de télévision :

  • [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 de téléviseurs DOIVENT être compatibles avec les formats de décodage vidéo suivants et les mettre à la disposition des applications tierces :

Les implémentations de téléviseurs DOIVENT prendre en charge le décodage MPEG-2, comme indiqué dans la section 5.3.1, aux fréquences d'images et résolutions vidéo standards, y compris :

  • [5.3.1/T-1-1] HD 1080p à 29,97 images par seconde avec profil principal de niveau élevé.
  • [5.3.1/T-1-2] HD 1080i à 59,94 images par seconde avec le profil principal de niveau élevé. Ils DOIVENT désentrelacer les vidéos MPEG-2 entrelacées et les mettre à la disposition des applications tierces.

Les implémentations de téléviseurs DOIVENT être compatibles avec le décodage H.264, comme indiqué dans la section 5.3.4, aux fréquences d'images vidéo standards et aux résolutions jusqu'à :

  • [5.3.4/T-1-1] HD 1080p à 60 images par seconde avec profil de base
  • [5.3.4/T-1-2] HD 1080p à 60 images par seconde avec profil principal
  • [5.3.4/T-1-3] HD 1080p à 60 images par seconde avec profil High Level 4.2

Les implémentations de téléviseurs avec des décodeurs matériels H.265 DOIVENT être compatibles avec le décodage H.265, comme indiqué dans la section 5.3.5, à des fréquences d'images vidéo et des résolutions standards, y compris :

  • [5.3.5/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/T-2-1] DOIT être compatible avec le profil de décodage UHD à 60 images par seconde avec le profil Main10 de niveau 5 de la catégorie principale.

Les implémentations de téléviseurs 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, y compris :

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

Les implémentations de téléviseurs 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 vidéo et résolutions standards jusqu'à :

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

Si les implémentations de téléviseurs 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/T-2-1] DOIT être compatible avec le profil de décodage UHD à 60 images par seconde avec le profil 0 (profondeur de couleur de 8 bits).
  • [5.3.7/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 de télévision :

  • [5.5/T-0-1] DOIT inclure la prise en charge du volume principal du système et de l'atténuation du volume de sortie audio numérique sur les sorties compatibles, à l'exception de la sortie de transmission directe de l'audio compressé (où aucun décodage audio n'est effectué sur l'appareil).

Si les implémentations d'appareils de télévision ne disposent pas d'un écran intégré, mais prennent en charge un écran externe connecté via HDMI, elles :

  • [5.8/T-0-1] DOIT définir le mode de sortie HDMI pour sélectionner la résolution maximale pouvant être prise en charge avec une fréquence d'actualisation de 50 Hz ou 60 Hz.
  • [5.8/T-SR] Il est FORTEMENT RECOMMANDÉ de fournir un sélecteur de fréquence d'actualisation HDMI configurable par l'utilisateur.
  • [5.8] DOIT définir la fréquence d'actualisation du mode de sortie HDMI sur 50 Hz ou 60 Hz, en fonction de la fréquence d'actualisation vidéo pour la région dans laquelle l'appareil est vendu.

Si les implémentations d'appareils de télévision ne disposent pas d'un écran intégré, mais prennent en charge un écran externe connecté via HDMI, elles :

  • [5.8/T-1-1] DOIT être compatible avec HDCP 2.2.

Si les implémentations d'appareils de télévision ne sont pas compatibles avec le décodage UHD, mais sont compatibles avec un écran externe connecté via HDMI, elles :

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

2.3.3. Logiciel

Implémentations d'appareils de télévision :

  • [3/T-0-1] MUST declare the features android.software.leanback and 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 de télévision :

  • [3.8.14/T-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge le mode Picture-in-picture (PIP) multifenêtre.
  • [3.10/T-0-1] DOIT être compatible avec 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 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 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 prenant en charge les langues disponibles sur l'appareil.
  • [3.11/T-1-1] DOIT permettre l'installation de moteurs TTS tiers.

Implémentations d'appareils de télévision :

  • [3.12/T-0-1] DOIT être compatible avec le framework TV Input.

2.3.4. Performances et puissance

  • [8.1/T-0-1] Latence d'image cohérente. La latence d'images incohérente ou le retard 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 garantir 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 de téléviseurs incluent des fonctionnalités permettant d'améliorer 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 permettre à l'utilisateur d'activer et de désactiver la fonctionnalité d'économiseur de batterie.

Si les implémentations d'appareils télévisuels ne disposent pas de batterie :

Si les implémentations d'appareils de télévision sont équipées d'une batterie, elles doivent :

  • [8.3/T-1-3] DOIT fournir à l'utilisateur un moyen d'afficher toutes les applications exemptées des modes d'économie d'énergie Mise en veille des applications et Sommeil.

Implémentations d'appareils de télévision :

  • [8.4/T-0-1] DOIT fournir un profil de consommation électrique par composant qui définit la valeur de consommation de courant pour chaque composant matériel et la décharge approximative de la batterie causée par les composants au fil du temps, comme indiqué sur le site Android Open Source Project.
  • [8.4/T-0-2] DOIT indiquer toutes les valeurs de consommation d'énergie en milliampères-heures (mAh).
  • [8.4/T-0-3] DOIT indiquer la consommation d'énergie du processeur pour chaque UID de processus. Le projet Android Open Source répond à cette exigence grâce à l'implémentation du module de noyau uid_cputime.
  • [8.4/T] La consommation d'énergie des composants matériels DOIT être attribuée au composant matériel lui-même s'il est impossible de l'attribuer à une application.
  • [8.4/T-0-4] DOIT mettre cette consommation d'énergie à la disposition du développeur d'applications via la commande shell adb shell dumpsys batterystats.

2.3.5. Modèle de sécurité

Implémentations d'appareils de télévision :

  • [9.11/T-0-1] DOIT sauvegarder l'implémentation du keystore avec un environnement d'exécution isolé.
  • [9.11/T-0-2] DOIT implémenter les algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que les fonctions de hachage MD5, SHA1 et de la famille SHA-2 pour prendre correctement en charge les algorithmes compatibles du système Android Keystore dans une zone sécurisée et isolée du code s'exécutant 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 pourrait 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 d'autres solutions basées sur ARM TrustZone ou une implémentation sécurisée tierce et examinée d'une isolation appropriée basée sur un hyperviseur sont également possibles.
  • [9.11/T-0-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 qu'en cas de succès. Les identifiants de l'écran de verrouillage DOIVENT être stockés de manière à ce que seul l'environnement d'exécution isolé puisse 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.
  • [9.11/T-0-4] DOIT prendre en charge l'attestation de clé, où la clé de signature de l'attestation est protégée par un matériel sécurisé et la signature est effectuée dans un matériel sécurisé. Les clés de signature d'attestation DOIVENT être partagées sur un nombre d'appareils suffisamment important pour empêcher 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.

Notez que si une implémentation d'appareil est déjà lancée sur une version antérieure d'Android, cet appareil est exempté de l'obligation d'avoir un keystore soutenu par un environnement d'exécution isolé et de prendre en charge l'attestation de clé, sauf s'il déclare la fonctionnalité android.hardware.fingerprint qui nécessite un keystore soutenu par un environnement d'exécution isolé.

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

  • [9.11/T-1-1] DOIT permettre à l'utilisateur de choisir le délai d'inactivité pour passer de l'état déverrouillé à l'état verrouillé, avec un délai d'inactivité minimal autorisé de 15 secondes ou moins.

Si les implémentations d'appareils TV incluent plusieurs utilisateurs et ne déclarent pas l'indicateur de fonctionnalité android.hardware.telephony, elles :

  • [9.5/T-2-1] DOIT être compatible avec les profils limités, une fonctionnalité qui permet aux propriétaires d'appareils de gérer d'autres utilisateurs et leurs capacités sur l'appareil. Grâce aux profils restreints, les propriétaires d'appareils peuvent rapidement configurer des environnements distincts pour que d'autres utilisateurs puissent y travailler. Ils peuvent également gérer des restrictions plus précises dans les applications disponibles dans ces environnements.

Si les implémentations d'appareils TV incluent plusieurs utilisateurs et déclarent l'indicateur de fonctionnalité android.hardware.telephony, elles :

  • [9.5/T-3-1] NE DOIT PAS être compatible avec les profils restreints, mais DOIT s'aligner sur l'implémentation AOSP des commandes permettant d'autoriser /d'interdire l'accès aux appels vocaux et aux SMS pour les autres utilisateurs.

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

Implémentations d'appareils de télévision :

2.4. Configuration requise pour la montre

Un appareil Android Wear 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 Montre si elles répondent à tous les critères suivants :

  • avoir un écran dont la diagonale physique est comprise entre 1,1 et 2,5 pouces ;
  • Disposer d'un mécanisme permettant de le porter sur le corps.

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

2.4.1. Matériel

Implémentations d'appareils Wear :

  • [7.1.1.1/W-0-1] DOIT disposer d'un écran dont la diagonale physique est comprise entre 1,1 et 2,5 pouces.

  • [7.2.3/W-0-1] DOIT proposer à l'utilisateur les fonctions Accueil et Retour, sauf lorsqu'il se trouve dans UI_MODE_TYPE_WATCH.

  • [7.2.4/W-0-1] DOIT accepter les entrées tactiles.

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

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

  • [7.3.3/W-1-1] DOIT indiquer les mesures GNSS dès qu'elles sont trouvées, même si aucune position calculée à partir du GPS/GNSS n'est encore indiquée.
  • [7.3.3/W-1-2] DOIT indiquer les pseudo-distances et les taux de pseudo-distances GNSS qui, dans des conditions de ciel dégagé après avoir déterminé la position, à l'arrêt ou en mouvement avec une accélération inférieure à 0, 2 mètre par seconde au carré, sont suffisants pour calculer la position à 20 mètres près et la vitesse à 0, 2 mètre par seconde près, au moins 95 % du temps.

Si les implémentations d'appareils Watch incluent un gyroscope à trois axes, elles :

  • [7.3.4/W-2-1] DOIT être capable de mesurer les changements d'orientation jusqu'à 1 000 degrés par seconde.

Implémentations d'appareils Wear :

  • [7.4.3/W-0-1] DOIT être compatible avec le Bluetooth.

  • [7.6.1/W-0-1] DOIT disposer d'au moins 1 Go de stockage non volatile disponible pour les données privées de l'application (c'est-à-dire la partition "/data").

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

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

  • [7.8.2/W] PEUT, mais NE DOIT PAS avoir de sortie audio.

2.4.2. Multimédia

Aucune autre condition requise.

2.4.3. Logiciel

Implémentations d'appareils Wear :

  • [3/W-0-1] MUST declare the feature android.hardware.type.watch.
  • [3/W-0-2] DOIT être compatible avec uiMode = UI_MODE_TYPE_WATCH.

Implémentations d'appareils connectés :

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

Implémentations d'appareils connectés 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 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.

  • [3.11/W-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un moteur de synthèse vocale prenant en charge les langues disponibles sur l'appareil.

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

2.4.4. Performances et puissance

Si les implémentations de l'appareil Watch incluent des fonctionnalités permettant d'améliorer 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/W-SR] Il est FORTEMENT RECOMMANDÉ de fournir aux utilisateurs la possibilité d'afficher toutes les applications exemptées des modes d'économie d'énergie Veille de l'application et Veille.
  • [8.3/W-SR] Il est FORTEMENT RECOMMANDÉ de permettre à l'utilisateur d'activer et de désactiver la fonctionnalité d'économiseur de batterie.

Implémentations d'appareils connectés :

  • [8.4/W-0-1] DOIT fournir un profil de puissance par composant qui définit la valeur de consommation de courant pour chaque composant matériel et la décharge de batterie approximative causée par les composants au fil du temps, comme indiqué sur le site Android Open Source Project.
  • [8.4/W-0-2] DOIT indiquer toutes les valeurs de consommation d'énergie en milliampères-heures (mAh).
  • [8.4/W-0-3] DOIT indiquer la consommation d'énergie du processeur pour chaque UID de 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] DOIT rendre cette consommation d'énergie disponible pour le développeur d'applications via la commande shell adb shell dumpsys batterystats.
  • [8.4/W] DOIT être attribué au composant matériel lui-même s'il est impossible d'attribuer la consommation d'énergie du composant matériel à une application.

2.4.5. Modèle de sécurité

Si les implémentations d'appareils Wear incluent plusieurs utilisateurs et ne déclarent pas l'indicateur de fonctionnalité android.hardware.telephony, elles :

  • [9.5/W-1-1] DOIT être compatible avec les profils limités, une fonctionnalité qui permet aux propriétaires d'appareils de gérer d'autres utilisateurs et leurs capacités sur l'appareil. Grâce aux profils restreints, les propriétaires d'appareils peuvent rapidement configurer des environnements distincts pour que d'autres utilisateurs puissent y travailler. Ils peuvent également gérer des restrictions plus précises dans les applications disponibles dans ces environnements.

Si les implémentations de l'appareil Wear incluent plusieurs utilisateurs et déclarent l'indicateur de fonctionnalité android.hardware.telephony, elles :

  • [9.5/W-2-1] NE DOIT PAS être compatible avec les profils restreints, mais DOIT s'aligner sur l'implémentation AOSP des commandes permettant d'autoriser /d'interdire l'accès aux appels vocaux et aux SMS pour les autres utilisateurs.

2.5. Exigences pour le secteur automobile

L'implémentation Android Automotive fait référence à une unité principale de véhicule exécutant 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.

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

Les exigences supplémentaires décrites dans le 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] DOIT disposer d'un écran d'au moins 6 pouces de diagonale physique.

  • [7.1.1.1/A-0-2] DOIT avoir une disposition de taille d'écran 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'événement d'appui normal et l'événement d'appui long de la fonction Retour (KEYCODE_BACK) à l'application au premier plan.
  • [7.3/A-0-1] DOIT implémenter et signaler GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED et PARKING_BRAKE_ON.
  • [7.3/A-0-2] La valeur du signal NIGHT_MODE 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 luminosité ambiante. Le capteur de luminosité ambiante sous-jacent PEUT être le même que Photometer.
  • [7.3/A-0-3] DOIT fournir le champ d'informations supplémentaires du capteur TYPE_SENSOR_PLACEMENT dans SensorAdditionalInfo pour chaque capteur fourni.
  • [7.3/A-0-1] PEUT calculer à l'estime la position en fusionnant le GPS/GNSS avec des capteurs supplémentaires. Si la position est estimée, il est FORTEMENT RECOMMANDÉ d'implémenter et de signaler les types de capteurs et/ou les ID de propriété du véhicule correspondants utilisés.
  • [7.3/A-0-2] La position demandée via LocationManager#requestLocationUpdates() NE DOIT PAS être associée à une carte.

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

Si les implémentations d'appareils automobiles incluent un gyroscope à trois axes, elles doivent :

  • [7.3.4/A-2-1] DOIT être capable de signaler des événements jusqu'à une fréquence d'au moins 100 Hz.
  • [7.3.4/A-2-2] DOIT également implémenter le capteur TYPE_GYROSCOPE_UNCALIBRATED.
  • [7.3.4/A-2-3] DOIT être capable de mesurer les changements d'orientation jusqu'à 250 degrés par seconde.
  • [7.3.4/A-SR] Il est FORTEMENT RECOMMANDÉ de configurer la plage de mesure du gyroscope sur +/-250 dps afin de maximiser la résolution possible.

Implémentations d'appareils automobiles :

  • [7.4.3/A-0-1] DOIT être compatible avec Bluetooth et DOIT être compatible avec Bluetooth LE.

  • [7.4.3/A-0-2] Les implémentations Android Automotive 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 multimédia via le profil de télécommande (AVRCP).
    • Partage de contacts à l'aide du profil d'accès à l'annuaire téléphonique (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 inclure la prise en charge de la connectivité des données basée sur le réseau mobile.

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

Une caméra de vue extérieure est une caméra qui filme des scènes à l'extérieur de l'implémentation de l'appareil, comme une caméra embarquée.

Implémentations d'appareils automobiles :

  • DOIT inclure une ou plusieurs caméras de vue extérieure.

Si les implémentations d'appareils automobiles incluent une caméra de vue extérieure, pour une telle caméra, elles :

  • [7.5/A-1-1] NE DOIT PAS avoir de caméras avec vue extérieure accessibles via les API Android Camera, sauf si elles respectent les exigences de base concernant les caméras.
  • [7.5/A-SR] Il est FORTEMENT RECOMMANDÉ de ne pas faire pivoter ni mettre en miroir horizontalement l'aperçu de la caméra.
  • [7.5.5/A-SR] Il est FORTEMENT RECOMMANDÉ d'orienter les caméras de sorte que la dimension longue de la caméra soit alignée sur l'horizon.
  • [7.5/A-SR] Il est FORTEMENT RECOMMANDÉ que les caméras de sécurité aient une résolution d'au moins 1,3 mégapixel.
  • DOIT disposer d'un matériel à mise au point fixe ou à profondeur de champ étendue (EDOF).
  • PEUT avoir une mise au point automatique matérielle ou logicielle implémentée dans le pilote de la caméra.

Implémentations d'appareils automobiles :

  • [7.6.1/A-0-1] DOIT disposer d'au moins 4 Go de stockage non volatile disponible pour les données privées de l'application (c'est-à-dire la partition "/data").

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

Si les implémentations d'appareils automobiles fournissent un stockage externe partagé via une partie du stockage interne non amovible, elles :

  • [7.6.1/A-SR] Il est FORTEMENT RECOMMANDÉ de réduire la surcharge d'E/S sur les opérations effectuées sur le stockage externe, par exemple en utilisant SDCardFS.

Si les implémentations d'appareils automobiles sont en 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 ou moyenne taille
    • ldpi ou inférieur sur les écrans très grands
    • mdpi ou inférieure 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 plus sur les écrans de petite ou moyenne taille
    • hdpi ou résolution supérieure sur les grands écrans
    • mdpi ou supérieur 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 ou moyenne taille
    • xhdpi ou supérieur sur les grands écrans
    • tvdpi ou plus 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 ou moyenne taille
    • 400 dpi ou plus sur les grands écrans
    • xhdpi ou supérieur sur les très grands écrans

Si les implémentations d'appareils automobiles sont en 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 ou moyenne taille
    • ldpi ou inférieur sur les écrans très grands
    • mdpi ou inférieure 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 plus sur les écrans de petite ou moyenne taille
    • hdpi ou résolution supérieure sur les grands écrans
    • mdpi ou supérieur 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 ou moyenne taille
    • xhdpi ou supérieur sur les grands écrans
    • tvdpi ou plus 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 ou moyenne taille
    • 400 dpi ou plus sur les grands écrans
    • xhdpi ou supérieur sur les très grands écrans

Notez que la "mémoire disponible pour le noyau et l'espace utilisateur" ci-dessus fait référence à l'espace mémoire fourni en plus de toute 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 noyau sur les implémentations d'appareils.

Implémentations d'appareils automobiles :

  • [7.7.1/A] DOIT inclure un port USB prenant en charge le mode périphérique.

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 être compatibles avec les formats d'encodage et de décodage audio suivants, et les mettre à la disposition des applications tierces :

  • [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é)

Les implémentations d'appareils automobiles DOIVENT prendre en charge les formats d'encodage vidéo suivants et les mettre à la disposition des applications tierces :

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

Les implémentations d'appareils automobiles DOIVENT prendre en charge les formats de décodage vidéo suivants et les mettre à la disposition des applications tierces :

  • [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 FORTEMENT 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] DOIT 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 être compatible avec toutes les API publiques dans l'espace de noms android.car.*.

  • [3.2.1/A-0-1] DOIT être compatible avec toutes les constantes d'autorisation et les appliquer, comme indiqué sur la page de référence sur les autorisations automobiles.

  • [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 lorsqu'elles sont demandées 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.

Si les implémentations d'appareils automobiles incluent un bouton "appuyer pour parler", elles doivent :

  • [3.8.4/A-1-1] DOIT utiliser un appui bref sur le bouton "Appuyer pour parler" comme interaction désignée pour lancer l'application d'assistance sélectionnée par l'utilisateur, c'est-à-dire l'application qui implémente VoiceInteractionService.

Implémentations d'appareils automobiles :

  • [3.8.3.1/A-0-1] DOIT afficher correctement les ressources comme décrit dans la documentation du SDK Notifications on Automotive OS.
  • [3.8.3.1/A-0-2] DOIT afficher "PLAY" (LIRE) et "MUTE" (COUPER LE SON) pour les actions de notification à la place de celles fournies par Notification.Builder.addAction()
  • [3.8.3.1/A] DOIT restreindre l'utilisation de tâches de gestion avancées telles que les commandes par canal de notification. PEUT utiliser une affordance d'UI par application pour réduire les contrôles.

Implémentations d'appareils automobiles :

Si les implémentations d'appareils automobiles incluent une application de lanceur d'applications par défaut, elles doivent :

Implémentations d'appareils automobiles :

2.5.4. Performances et puissance

Implémentations d'appareils automobiles :

  • [8.2/A-0-1] DOIT signaler le nombre d'octets lus et écrits dans le stockage non volatile pour chaque UID de 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 grâce au module de noyau uid_sys_stats.
  • [8.3/A-1-3] Vous DEVEZ passer en mode Garage au moins une fois avant d'éteindre le véhicule.
  • [8.3/A-1-4] DOIT être en mode Garage pendant au moins 15 minutes, sauf si :
    • La batterie est déchargée.
    • Aucun job inactif n'est planifié.
    • Le conducteur quitte le mode Garage.
  • [8.4/A-0-1] DOIT fournir un profil de consommation électrique par composant qui définit la valeur de consommation de courant pour chaque composant matériel et la décharge approximative de la batterie causée par les composants au fil du temps, comme indiqué sur le site Android Open Source Project.
  • [8.4/A-0-2] DOIT indiquer toutes les valeurs de consommation d'énergie en milliampères-heures (mAh).
  • [8.4/A-0-3] DOIT signaler la consommation d'énergie du processeur pour chaque UID de processus. Le projet Android Open Source répond à cette exigence grâce à l'implémentation du module de noyau uid_cputime.
  • [8.4/A] La consommation d'énergie des composants matériels DOIT être attribuée au composant matériel lui-même s'il est impossible de l'attribuer à une application.
  • [8.4/A-0-4] DOIT mettre cette consommation d'énergie à la disposition du développeur d'applications via la commande shell adb shell dumpsys batterystats.

2.5.5. Modèle de sécurité

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

Implémentations d'appareils automobiles :

  • [9.11/A-0-1] DOIT sauvegarder l'implémentation du keystore avec un environnement d'exécution isolé.
  • [9.11/A-0-2] DOIT implémenter les algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que les fonctions de hachage MD5, SHA1 et de la famille SHA-2 pour prendre correctement en charge les algorithmes compatibles du système Android Keystore dans une zone sécurisée et isolée du code s'exécutant 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 pourrait accéder à l'état interne de l'environnement isolé, y compris le DMA. Le projet Android Open Source en amont répond à cette exigence en utilisant l'implémentation Trusty, mais d'autres solutions basées sur ARM TrustZone ou une implémentation sécurisée tierce d'un isolement approprié basé sur un hyperviseur sont également possibles.
  • [9.11/A-0-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 qu'en cas de succès. Les identifiants de l'écran de verrouillage DOIVENT être stockés de manière à ce que seul l'environnement d'exécution isolé puisse 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.
  • [9.11/A-0-4] DOIT prendre en charge l'attestation de clé lorsque la clé de signature de l'attestation est protégée par du matériel sécurisé et que la signature est effectuée dans du matériel sécurisé. Les clés de signature d'attestation DOIVENT être partagées sur un nombre d'appareils suffisamment important pour empêcher 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.

Notez que si une implémentation d'appareil est déjà lancée sur une version antérieure d'Android, cet appareil est exempté de l'obligation d'avoir un keystore soutenu par un environnement d'exécution isolé et de prendre en charge l'attestation de clé, sauf s'il déclare la fonctionnalité android.hardware.fingerprint qui nécessite un keystore soutenu par un environnement d'exécution isolé.

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

  • [9.11/A-1-1] DOIT permettre à l'utilisateur de choisir le délai d'inactivité pour passer de l'état déverrouillé à l'état verrouillé, avec un délai d'inactivité minimal autorisé de 15 secondes ou moins.

Implémentations d'appareils automobiles :

  • [9.14/A-0-1] DOIT contrôler l'accès aux messages provenant des sous-systèmes du véhicule du framework Android, par exemple en autorisant certains types et sources de messages.
  • [9.14/A-0-2] DOIT surveiller les attaques par déni de service provenant du framework Android ou d'applications tierces. Cela permet de se prémunir 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.5.6. Compatibilité des outils et options pour les développeurs

Implémentations d'appareils automobiles :

  • Perfetto
    • [6.1/A-0-1] DOIT exposer un binaire /system/bin/perfetto à l'utilisateur du shell dont la ligne de commande est conforme à la documentation de Perfetto.
    • [6.1/A-0-2] Le binaire perfetto DOIT accepter en entrée une configuration protobuf conforme au schéma défini dans la documentation perfetto.
    • [6.1/A-0-3] Le binaire perfetto DOIT écrire en sortie une trace protobuf conforme au schéma défini dans la documentation perfetto.
    • [6.1/A-0-4] DOIT fournir, via le binaire perfetto, au moins les sources de données décrites dans la documentation perfetto.

2.6. Configuration requise pour les tablettes

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

  • Généralement utilisé en le tenant à deux mains.
  • Ne dispose pas d'une configuration à clapet ou convertible.
  • Toute implémentation de clavier physique utilisée avec l'appareil DOIT se connecter à l'aide d'une connexion standard.
  • Il est alimenté par une source d'énergie qui lui permet de se déplacer, comme une batterie.
  • La taille physique de l'écran en diagonale est comprise entre 7 et 18 pouces.

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

2.6.1. Matériel

Taille de l'écran

  • [7.1.1.1/Tab-0-1] DOIT avoir un écran de 7 à 18 pouces.

Gyroscope

Si les implémentations de tablettes incluent un gyroscope à trois axes, elles :

  • [7.3.4/Tab-1-1] DOIT être capable de mesurer les changements d'orientation jusqu'à 1 000 degrés par seconde.

Mémoire et stockage minimum (section 7.6.1)

Les densités d'écran indiquées pour les petits écrans/écrans normaux dans les exigences relatives aux appareils mobiles ne s'appliquent pas aux tablettes.

Mode périphérique USB (section 7.7.1)

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

  • [7.7.1/Tab] 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 de réalité virtuelle ne s'appliquent pas aux tablettes.

2.6.2. Modèle de sécurité

Clés et identifiants (section 9.11)

Consultez la section [9.11].

Si les implémentations de tablettes incluent plusieurs utilisateurs et ne déclarent pas l'indicateur de fonctionnalité android.hardware.telephony, elles :

  • [9.5/T-1-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 capacités sur l'appareil. Grâce aux profils restreints, les propriétaires d'appareils peuvent rapidement configurer des environnements distincts pour que d'autres utilisateurs puissent y travailler. Ils peuvent également gérer des restrictions plus précises dans les applications disponibles dans ces environnements.

Si les implémentations de tablettes incluent plusieurs utilisateurs et déclarent l'indicateur de fonctionnalité android.hardware.telephony, elles :

  • [9.5/T-2-1] NE DOIT PAS prendre en charge les profils restreints, mais DOIT s'aligner sur l'implémentation AOSP des commandes permettant d'autoriser /d'interdire l'accès aux appels vocaux et aux SMS pour les autres utilisateurs.

3. Logiciel

3.1. Compatibilité des API gérées

L'environnement d'exécution de bytecode Dalvik géré est le principal véhicule pour les applications Android. L'interface de programmation d'application (API) Android est l'ensemble des interfaces de la plate-forme Android exposées aux applications s'exécutant dans l'environnement d'exécution géré.

Implémentations sur les appareils :

  • [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 marqueur "@SystemApi" dans le code source Android en amont.

  • [C-0-2] DOIT prendre en charge/préserver 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 d'opérations sans effet, sauf si la présente Définition de compatibilité l'autorise spécifiquement.

  • [C-0-4] DOIT toujours conserver les API 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] NE DOIT PAS autoriser les applications tierces à utiliser des interfaces non SDK, qui sont définies comme des méthodes et des champs dans les packages de langage Java qui se trouvent dans le chemin de classe de démarrage dans AOSP et qui ne font pas partie du SDK public. Cela inclut les API décorées avec l'annotation @hide, mais pas avec @SystemAPI, comme décrit dans les documents du SDK et les membres de classe privés et package-privés.

  • [C-0-6] DOIT être fourni avec chaque interface non SDK sur les mêmes listes restreintes que celles fournies via la liste provisoire et les indicateurs de liste de refus dans le chemin d'accès prebuilts/runtime/appcompat/hiddenapi-flags.csv pour la branche de niveau d'API appropriée dans AOSP.

    Toutefois, ils :

    • SI une API masquée est absente ou implémentée différemment sur l'implémentation de l'appareil, DÉPLACEZ l'API masquée dans la liste de refus ou OMETTEZ-la de toutes les listes restreintes.
    • MAI, si une API masquée n'existe pas déjà dans l'AOSP, ajoutez-la à l'une des listes restreintes.

  • [C-0-7] DOIT être compatible avec le mécanisme de mise à jour dynamique de la configuration signée pour supprimer les interfaces non SDK d'une liste restreinte en intégrant une configuration signée dans n'importe quel APK, à l'aide des clés publiques existantes dans AOSP.

3.1.1. Extensions Android

Android permet d'étendre les API gérées tout en conservant la même version de 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] DOIT 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éclare dans son fichier manifeste qu'elle 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é logicielle avec les API

En plus des API gérées de la section 3.1, Android inclut également une API "logicielle" d'exécution uniquement, 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émenteurs 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. Créer des paramètres

Les API Android incluent un certain nombre de constantes sur la classe android.os.Build qui sont destinées à décrire l'appareil actuel.

  • [C-0-1] Pour fournir des valeurs cohérentes et pertinentes 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 en cours d'exécution, dans un format lisible. Ce champ DOIT contenir l'une des valeurs de chaîne définies dans 10.
VERSION.SDK Version du système Android en cours d'exécution, dans un format accessible au code d'application tiers. Pour Android 10, ce champ DOIT avoir la valeur entière 10_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 10, ce champ DOIT avoir la valeur entière 10_INT.
VERSION.INCREMENTAL Valeur choisie par l'implémenteur de l'appareil désignant la version spécifique du système Android en cours d'exécution, dans un format lisible. Cette valeur NE DOIT PAS être réutilisée pour différentes versions mises à la disposition des utilisateurs finaux. Ce champ est généralement utilisé pour indiquer le numéro de compilation ou l'identifiant de modification du contrôle de code source qui a été utilisé pour générer la compilation. La valeur de ce champ DOIT pouvoir être encodée en ASCII imprimable sur 7 bits et correspondre à l'expression régulière "^[^ :\/~]+$".
JEUX DE SOCIÉTÉ Valeur choisie par l'implémenteur de l'appareil, qui identifie le matériel interne spécifique utilisé par l'appareil, dans un format lisible. Ce champ peut être utilisé pour indiquer la révision spécifique de la carte qui alimente l'appareil. La valeur de ce champ DOIT pouvoir être encodée en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$".
MARQUE Valeur reflétant le nom de la marque associée à l'appareil, tel qu'il est connu des utilisateurs finaux. DOIT être au format lisible par un 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 pouvoir être encodée 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. Consultez 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. Consultez 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. Consultez 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. Consultez 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. Consultez la section 3.3. Compatibilité avec les API natives.
APPAREIL Valeur choisie par l'intégrateur de l'appareil, contenant le nom de développement ou le nom de code identifiant la configuration des caractéristiques matérielles et du design industriel de l'appareil. La valeur de ce champ DOIT pouvoir être encodée en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$". Le nom de l'appareil NE DOIT PAS changer pendant la durée de vie du produit.
FINGERPRINT Chaîne qui identifie ce build de manière unique. Elle DOIT être raisonnablement lisible par un humain. Il DOIT respecter ce modèle :

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

Exemple :

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

L'empreinte digitale ne DOIT PAS inclure d'espaces. La valeur de ce champ DOIT pouvoir être encodée en ASCII 7 bits.

MATÉRIEL Nom du matériel (à partir de la ligne de commande du noyau ou de /proc). Elle DOIT être raisonnablement lisible par un humain. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$".
HOST Chaîne qui identifie de manière unique l'hôte sur lequel la compilation a été créée, dans un format lisible par l'utilisateur. Il n'y a aucune exigence concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide ("").
ID Identifiant choisi par l'implémenteur de l'appareil pour faire référence à une version spécifique, dans un 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 faire la différence entre les versions logicielles. La valeur de ce champ DOIT pouvoir être encodée en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9._-]+$".
FABRICANT Nom commercial du fabricant d'équipement d'origine (OEM) du produit. Il n'existe aucune exigence concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide (""). Ce champ NE DOIT PAS changer pendant la durée de vie du produit.
MODÈLE Valeur choisie par l'implémenteur de l'appareil, contenant le nom de l'appareil tel qu'il est connu de l'utilisateur final. Il DOIT s'agir du même nom sous lequel l'appareil est commercialisé et vendu aux utilisateurs finaux. Il n'existe aucune exigence concernant le format spécifique de ce champ, si ce n'est qu'il NE DOIT PAS être nul ni la chaîne vide (""). Ce champ NE DOIT PAS changer pendant la durée de vie du produit.
PRODUIT Valeur choisie par l'intégrateur de l'appareil, contenant le nom de développement ou le nom de code du produit spécifique (SKU) qui DOIT être unique au sein de la même marque. DOIT être lisible par un humain, 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_-]+$". Le nom du produit NE DOIT PAS changer pendant sa durée de vie.
SERIAL DOIT renvoyer "UNKNOWN".
TAGS Liste de tags séparés par une virgule, choisis par l'intégrateur de l'appareil, qui permettent de distinguer davantage la compilation. Les tags DOIVENT être encodables en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9._-]+". Ils DOIVENT également avoir l'une des valeurs correspondant aux trois configurations de signature typiques de la plate-forme Android : release-keys, dev-keys et test-keys.
DURÉE Valeur représentant le code temporel du moment où la compilation a eu lieu.
MACH Valeur choisie par l'implémenteur de l'appareil, qui spécifie la configuration d'exécution de la compilation. 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é la compilation. Il n'y a aucune exigence concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide ("").
SECURITY_PATCH Valeur indiquant le niveau du correctif de sécurité d'une version. Il DOIT indiquer que la version n'est en aucun cas vulnérable aux 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 public de sécurité 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 identique à cette version, à l'exception des correctifs fournis dans le bulletin public de sécurité Android. Il DOIT indiquer la valeur correcte et, si une telle version n'existe pas, indiquer une chaîne vide ("").
BOOTLOADER Valeur choisie par l'intégrateur de l'appareil, qui identifie la version spécifique du bootloader interne utilisé dans l'appareil, dans un format lisible par l'utilisateur. La valeur de ce champ DOIT pouvoir être encodée en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9._-]+$".
getRadioVersion() DOIT être ou renvoyer une valeur choisie par l'implémenteur de l'appareil, qui identifie la version spécifique de la radio/du modem interne utilisée dans l'appareil, dans un format lisible. Si un appareil ne dispose d'aucune radio/aucun modem interne, il DOIT renvoyer NULL. La valeur de ce champ DOIT pouvoir être encodée en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9._-,]+$".
getSerial() DOIT (être ou renvoyer) un numéro de série matériel, qui DOIT être disponible et unique pour les appareils ayant le même MODÈLE et le même FABRICANT. La valeur de ce champ DOIT pouvoir être encodée en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9._-,]+$".

3.2.3. Compatibilité des intents

3.2.3.1. Intents d'application principale

Les intents Android permettent aux composants d'application de demander des fonctionnalités à d'autres composants Android. Le projet en amont d'Android inclut une liste d'applications considérées comme des applications Android de base, 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] Android étant une plate-forme extensible, les implémentations d'appareils DOIVENT permettre aux applications tierces de remplacer chaque modèle d'intent référencé dans la section 3.2.3.1, à l'exception des paramètres. L'implémentation Open Source Android en amont l'autorise par défaut.

  • [C-0-2] Les implémenteurs d'appareils NE DOIVENT PAS attribuer de privilèges spéciaux à l'utilisation de ces modèles d'intent par les applications système, ni empêcher les applications tierces de se lier à ces modèles et d'en prendre le contrôle. Cette interdiction inclut, sans s'y limiter, la désactivation de l'interface utilisateur du sélecteur, qui permet à l'utilisateur de choisir entre 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 pour les intents.

  • Toutefois, les implémentations d'appareils PEUVENT fournir des activités par défaut pour des schémas 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 modèle de filtre d'intent spécifiant l'URI de données "http://www.android.com" est plus spécifique que le modèle d'intent principal du navigateur pour "http://".

Android inclut également un mécanisme permettant aux applications tierces de déclarer un comportement de lien d'application par défaut faisant autorité pour certains types d'intentions 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'appareil :

  • [C-0-4] DOIT tenter 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 packages dans le projet Android Open Source 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 comme gestionnaires d'application par défaut pour leurs URI.
  • PEUT définir des filtres d'intent d'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 des remplacements 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 globalement le comportement par défaut des liens d'application pour qu'une application soit : toujours ouverte, toujours demandée ou jamais ouverte, ce qui DOIT s'appliquer à tous les filtres d'intent URI candidats de manière égale.
    • [C-0-7] L'utilisateur DOIT pouvoir voir une liste des filtres d'intent URI candidats.
    • L'implémentation de l'appareil PEUT permettre à l'utilisateur de remplacer des filtres d'intent d'URI candidats spécifiques qui ont été validés, filtre d'intent par 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 utilisant une ACTION, une CATÉGORIE ou une autre chaîne clé dans l'espace de noms android. ou com.android..
  • [C-0-2] Les développeurs 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 CATEGORY ou d'une autre chaîne de clé dans un espace de package appartenant à une autre organisation.
  • [C-0-3] Les développeurs 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 manifestement associés à leur propre organisation. Cette interdiction est analogue à 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 certaines intentions afin de les informer des modifications apportées à l'environnement matériel ou logiciel.

Implémentations sur les appareils :

  • [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'est pas en conflit avec la section 3.5, car les limites pour les applications en arrière-plan sont également décrites dans la documentation du SDK.
3.2.3.5. Paramètres des applications 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écrites dans la documentation du SDK ci-dessous.

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

  • [C-1-1] DOIT respecter l'intention android.settings.HOME_SETTINGS d'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'intention RoleManager.createRequestRoleIntent(String) avec RoleManager.ROLE_SMS pour afficher une boîte de dialogue permettant de modifier l'application de SMS par défaut.

  • [C-2-2] DOIT respecter l'intention android.telecom.action.CHANGE_DEFAULT_DIALER d'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 de 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 doivent utiliser l'application de téléphone préinstallée.

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

  • [C-2-4] DOIT autoriser android.telecom.CallRedirectionService pour une application qui détient le rôle android.app.role.CALL_REDIRECTION.

  • [C-2-5] DOIT permettre à l'utilisateur de choisir une application qui détient le rôle android.app.role.CALL_REDIRECTION.

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

Si les implémentations d'appareils sont compatibles avec VoiceInteractionService et que plusieurs applications utilisant cette API sont installées en même temps, elles :

3.2.4. Activités sur des écrans secondaires/multiples

Si les implémentations d'appareils autorisent le lancement d'activités Android normales sur plusieurs écrans, elles :

  • [C-1-1] DOIT définir le flag de fonctionnalité android.software.activities_on_secondary_displays.
  • [C-1-2] DOIT garantir la compatibilité de l'API de manière similaire à une activité s'exécutant sur l'écran principal.
  • [C-1-3] DOIT lancer 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 le flag Display.FLAG_PRIVATE est supprimé.
  • [C-1-5] DOIT masquer le contenu de manière sécurisée sur tous les écrans lorsque l'appareil est verrouillé avec un écran de verrouillage sécurisé, sauf si l'application choisit de s'afficher au-dessus de l'écran de verrouillage à l'aide de l'API Activity#setShowWhenLocked().
  • DOIT avoir android.content.res.Configuration qui correspond à cet écran pour pouvoir s'afficher, fonctionner correctement et rester compatible si une activité est lancée sur un écran secondaire.

Si les implémentations d'appareil autorisent le lancement d'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 déjà présentes sur cet écran DOIT pouvoir les lancer. 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 à obtenir. C'est pourquoi les développeurs d'appareils sont :

  • [SR] Il est FORTEMENT RECOMMANDÉ d'utiliser les implémentations des bibliothèques listées ci-dessous à partir du projet Android Open Source 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 ELF .so compilé pour l'architecture matérielle de l'appareil approprié. Comme le code natif dépend fortement de la technologie du processeur sous-jacent, Android définit un certain nombre d'interfaces binaires d'application (ABI) dans le NDK Android.

Implémentations sur les appareils :

  • [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 s'exécutant dans l'environnement géré pour appeler le code natif, en utilisant 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 dans la liste ci-dessous.
  • [C-0-5] DOIT indiquer avec précision 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ées par des virgules et classées 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 ne figurant pas dans la liste.

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

    • [C-0-7] DOIT rendre toutes les bibliothèques suivantes, qui fournissent des API natives, disponibles pour les applications qui incluent du code natif :

    • libaaudio.so (compatibilité audio native AAudio)

    • libamidi.so (compatibilité MIDI native, si la fonctionnalité android.software.midi est revendiquée comme décrit dans la section 5.9)
    • libandroid.so (prise en charge des activités Android natives)
    • libc (bibliothèque C)
    • libcamera2ndk.so
    • libdl (éditeur de liens dynamiques)
    • libEGL.so (gestion de surface OpenGL native)
    • 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] NE DOIT 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 supérieur, car elles sont réservées.
  • [C-0-11] DOIT exporter tous les symboles de fonction OpenGL ES 3.1 et Android Extension Pack, tels que définis dans le NDK, via la bibliothèque libGLESv3.so. Notez que tous les symboles DOIVENT être présents, mais la section 7.1.4.1 décrit plus en détail les exigences concernant l'implémentation complète de chaque fonction correspondante.
  • [C-0-12] DOIT exporter les symboles de fonction pour les symboles de fonction Vulkan 1.0 de base, 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 tous les symboles DOIVENT être présents, mais la section 7.1.4.2 décrit plus en détail les exigences concernant l'implémentation complète de chaque fonction correspondante.
  • DOIT être créé à l'aide du code source et des fichiers d'en-tête disponibles dans le projet Android Open Source 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'appareil indiquent la compatibilité avec l'ABI armeabi, elles :

  • [C-3-1] MUST also support armeabi-v7a and report its support, as armeabi is only for backwards compatibility with older apps.

Si les implémentations d'appareils indiquent la compatibilité avec l'ABI armeabi-v7a, les applications utilisant cette ABI :

  • [C-2-1] MUST include the following lines in /proc/cpuinfo, and SHOULD NOT alter the values on the same device, even when they are read by other ABIs.

    • Features:, suivi d'une liste des fonctionnalités de processeur ARMv7 facultatives prises en charge par l'appareil.
    • CPU architecture:, suivi d'un entier décrivant l'architecture ARM la plus élevée compatible avec 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, que ce soit par le biais d'une prise en charge native du processeur ou par le biais d'une émulation logicielle :

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

  • [C-2-3] DOIT inclure la prise en charge de l'extension Advanced SIMD (alias NEON).

3.4. Compatibilité Web

3.4.1. Compatibilité avec WebView

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

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

  • [C-1-3] La chaîne de l'agent utilisateur signalée par 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 à la valeur de 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 s'il est présent, la chaîne $(BUILD) DOIT être identique à la valeur de android.os.Build.ID.
    • La valeur de la chaîne $(CHROMIUM_VER) DOIT correspondre à la version de Chromium dans le projet Android Open Source en amont.
    • Les implémentations d'appareils PEUVENT omettre "Mobile" dans la chaîne user-agent.

  • Le composant WebView DOIT inclure la prise en charge du plus grand nombre possible de fonctionnalités HTML5 et, s'il prend en charge la fonctionnalité, DOIT être conforme à la spécification HTML5.

  • [C-1-4] DOIT afficher le contenu fourni ou le contenu de l'URL distante dans un processus distinct de l'application qui instancie la WebView. Plus précisément, le processus de rendu distinct DOIT disposer de privilèges inférieurs, s'exécuter en tant qu'ID utilisateur distinct, ne pas avoir accès au répertoire de données de l'application, ne pas avoir d'accès direct au réseau et n'avoir accès qu'aux services système minimaux requis via Binder. L'implémentation AOSP de WebView répond à cette exigence.

Notez que les implémentations d'appareils 32 bits ou qui déclarent l'indicateur de fonctionnalité android.hardware.ram.low sont exemptées de la section C-1-3.

3.4.2. Compatibilité du navigateur

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

  • [C-1-1] DOIT être compatible avec chacune des API associées à HTML5 :
  • [C-1-2] DOIT être compatible avec l'API Web Storage HTML5/W3C et DEVRAIT être compatible avec l'API IndexedDB HTML5/W3C. Notez que les organismes de normalisation du développement Web favorisent IndexedDB par rapport au stockage Web. IndexedDB devrait donc devenir un composant obligatoire dans une future version d'Android.
  • MAY ship a custom user agent string in the standalone Browser application.
  • DOIT implémenter la prise en charge d'autant de fonctionnalités 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 doivent :

  • [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é comportementale de l'API

Implémentations sur les appareils :

  • [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 soumises à des restrictions comme décrit dans la Section 3.5.1.
  • [C-0-10] NE DOIT PAS implémenter l'approche de la liste d'autorisation qui garantit la compatibilité comportementale de l'API uniquement pour les applications sélectionnées par les implémenteurs d'appareils.

Le comportement de chaque type d'API (gérée, logicielle, native et Web) DOIT être cohérent avec l'implémentation préférée du projet Android Open Source en amont. Voici quelques exemples précis de compatibilité :

  • [C-0-1] Les appareils NE DOIVENT PAS modifier le comportement ni la sémantique d'une intention standard.
  • [C-0-2] Les appareils NE DOIVENT PAS modifier le cycle de vie ni la sémantique du cycle de vie d'un type particulier de composant système (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 imposé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 d'exécuter les 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 supérieur, elle NE DOIT PAS autoriser l'enregistrement de récepteurs de diffusion pour les diffusions implicites des intents Android standards dans le fichier manifeste de l'application, sauf si l'intent de diffusion nécessite une autorisation protectionLevel "signature" ou "signatureOrSystem" ou figure sur la liste des exceptions.
    • [C-0-7] Si l'application cible le niveau d'API 25 ou supérieur, elle DOIT arrêter les services d'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 supérieur, elle DOIT libérer les verrous de réveil qu'elle détient.
  • [C-0-9] Les appareils DOIVENT renvoyer les fournisseurs de sécurité suivants comme les sept premières valeurs du tableau à partir de la méthode Security.getProviders(), dans l'ordre indiqué et avec les noms (tels que renvoyés par Provider.getName()) et les classes indiqués, sauf si l'application a modifié la liste via insertProviderAt() ou removeProvider(). Les appareils PEUVENT renvoyer des fournisseurs supplémentaires 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) teste des parties importantes de la plate-forme pour vérifier la compatibilité comportementale, mais pas toutes. Il incombe à l'intégrateur de s'assurer de la compatibilité comportementale avec le projet Android Open Source. C'est pourquoi les développeurs 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-1-1] DOIT fournir une affordance utilisateur permettant à l'utilisateur de voir la liste des applications restreintes.
  • [C-1-2] DOIT permettre à l'utilisateur d'activer / de désactiver les restrictions sur chaque application.
  • [C-1-3] NE DOIT PAS appliquer automatiquement des restrictions sans preuve d'un comportement de mauvaise santé du système, mais PEUT appliquer les restrictions aux applications lors de la détection d'un comportement de mauvaise santé 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émenteurs d'appareils, mais DOIVENT être liés à l'impact de l'application sur l'état du système. Les 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 comme critères.
  • [C-1-4] NE DOIT PAS appliquer automatiquement les restrictions d'application lorsque l'utilisateur les a désactivées manuellement, et PEUT suggérer à l'utilisateur d'appliquer des restrictions d'application.
  • [C-1-5] DOIT informer les utilisateurs si des restrictions d'application sont appliquées automatiquement à une application.
  • [C-1-6] DOIT renvoyer true pour ActivityManager.isBackgroundRestricted() lorsque l'application restreinte appelle cette API.
  • [C-1-7] NE DOIT PAS limiter l'application de premier plan supérieure qui est explicitement utilisée par l'utilisateur.
  • [C-1-8] DOIT suspendre les restrictions sur une application qui devient l'application de premier plan supérieure lorsque l'utilisateur commence explicitement à utiliser l'application qui était auparavant soumise à des restrictions.

3.6. Espaces de noms de l'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 fabricants d'appareils NE DOIVENT PAS apporter de modifications interdites (voir ci-dessous) à ces espaces de noms de package :

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

Autrement dit, ils :

  • [C-0-1] NE DOIT PAS modifier les API exposées publiquement sur la plate-forme Android en modifiant les signatures de méthodes ou de classes, ou en supprimant des classes ou des champs de classe.
  • [C-0-2] NE DOIT PAS ajouter d'éléments exposés publiquement (tels que des classes ou des interfaces, ou des champs ou des méthodes à des classes ou interfaces existantes) ni d'API de test ou système aux API dans les espaces de noms ci-dessus. Un "élément exposé publiquement" est toute construction qui n'est pas décorée avec le marqueur "@hide" tel qu'il est utilisé dans le code source Android en amont.

Les développeurs 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 indiqué ni sur la signature en langage Java des API exposées publiquement.
  • [C-0-4] NE DOIT PAS être annoncé ni exposé aux développeurs.

Toutefois, les développeurs 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 à celle-ci. Par exemple, les responsables de l'implémentation 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] DOIT être intégré 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 intégrateur d'appareils 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 se rendre sur source.android.com et commencer le processus de contribution des modifications et du code, conformément aux informations de ce site.

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

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

Implémentations sur les appareils :

  • [C-0-1] DOIT être compatible avec l'intégralité du format Dalvik Executable (DEX) et avec les spécifications et la sémantique du bytecode Dalvik.

  • [C-0-2] DOIT configurer les environnements d'exécution Dalvik pour allouer de la mémoire conformément à la plate-forme Android en amont et comme spécifié dans le tableau suivant. (Consultez la section 7.1.1 pour obtenir 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 packages de l'implémentation de référence.

  • DOIT exécuter des tests de fuzzing dans différents modes d'exécution et architectures cibles pour assurer la stabilité du runtime. 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 dpi (ldpi) 32 Mo
140 PPP (140 PPP)
160 ppp (mdpi)
180 dpi (180 ppp)
200 dpi (200 dpi)
213 ppp (tvdpi)
220 dpi (220 dpi) 36 Mo
240 dpi (hdpi)
280 dpi (280 dpi)
320 ppp (xhdpi) 48 Mo
360 dpi (360 ppp)
400 dpi (400 PPP) 56 Mo
420 ppp (420dpi) 64 Mo
480 dpi (xxhdpi) 88 Mo
560 PPP (560 dpi) 112 Mo
640 dpi (xxxhdpi) 154 Mo
petite/normale 120 dpi (ldpi) 32 Mo
140 PPP (140 PPP)
160 ppp (mdpi)
180 dpi (180 ppp) 48 Mo
200 dpi (200 dpi)
213 ppp (tvdpi)
220 dpi (220 dpi)
240 dpi (hdpi)
280 dpi (280 dpi)
320 ppp (xhdpi) 80 Mo
360 dpi (360 ppp)
400 dpi (400 PPP) 96 Mo
420 ppp (420dpi) 112 Mo
480 dpi (xxhdpi) 128 Mo
560 PPP (560 dpi) 192 Mo
640 dpi (xxxhdpi) 256 Mo
grande 120 dpi (ldpi) 32 Mo
140 PPP (140 PPP) 48 Mo
160 ppp (mdpi)
180 dpi (180 ppp) 80 Mo
200 dpi (200 dpi)
213 ppp (tvdpi)
220 dpi (220 dpi)
240 dpi (hdpi)
280 dpi (280 dpi) 96 Mo
320 ppp (xhdpi) 128 Mo
360 dpi (360 dpi) 160 Mo
400 dpi (400 PPP) 192 Mo
420 ppp (420dpi) 228 Mo
480 dpi (xxhdpi) 256 Mo
560 PPP (560 dpi) 384 Mo
640 dpi (xxxhdpi) 512 Mo
xlarge 120 dpi (ldpi) 48 Mo
140 PPP (140 PPP) 80 Mo
160 ppp (mdpi)
180 dpi (180 ppp) 96 Mo
200 dpi (200 dpi)
213 ppp (tvdpi)
220 dpi (220 dpi)
240 dpi (hdpi)
280 dpi (280 dpi) 144 Mo
320 ppp (xhdpi) 192 Mo
360 dpi (360 dpi) 240 Mo
400 dpi (400 PPP) 288 Mo
420 ppp (420dpi) 336 Mo
480 dpi (xxhdpi) 384 Mo
560 PPP (560 dpi) 576 Mo
640 dpi (xxxhdpi) 768 Mo

3.8. Compatibilité de l'interface utilisateur

3.8.1. Lanceur d'applications (écran d'accueil)

Android inclut une application de lanceur d'applications (écran d'accueil) et permet aux applications tierces de remplacer le lanceur d'applications de l'appareil (écran d'accueil).

Si les implémentations d'appareils autorisent les applications tierces à remplacer l'écran d'accueil de l'appareil, elles :

  • [C-1-1] DOIT 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 permettant de récupérer les icônes sont appelées.

Si les implémentations d'appareils incluent un lanceur d'applications par défaut qui permet d'épingler des raccourcis dans les applications, elles :

À l'inverse, si les implémentations d'appareils 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 être compatible avec toutes les fonctionnalités de raccourci documentées (par exemple, les raccourcis statiques et dynamiques, l'épinglage de raccourcis) 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 système de badge d'icône d'application lorsque tous les canaux de notification de l'application ont défini la valeur sur false.
  • PEUT remplacer les badges d'icône d'application par son propre système de badges lorsque des 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 les API Notification.Builder.setNumber() et Notification.Builder.setBadgeIconType().

3.8.2. Widgets

Android est compatible avec les widgets d'applications tierces en définissant un type de composant, ainsi que l'API et le 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 compatibilité avec 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 pour ajouter, configurer, afficher et supprimer des AppWidgets directement dans le lanceur d'applications.
  • [C-1-3] DOIT être capable d'afficher des widgets de taille 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.
  • MAY peut prendre en charge les widgets d'application sur l'écran de verrouillage.

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

3.8.3. Notifications

Android inclut les API Notification et NotificationManager qui permettent aux développeurs d'applications tierces d'informer les utilisateurs d'événements importants et d'attirer leur attention à l'aide des composants matériels (par exemple, le son, les vibrations et la lumière) 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 d'appareils autorisent les applications tierces à notifier les utilisateurs d'événements importants, 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 du matériel, les API correspondantes DOIVENT être implémentées en tant qu'opérations sans effet. 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, mais PEUT proposer une expérience utilisateur alternative pour les notifications par rapport à 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 option permettant à l'utilisateur de bloquer et de modifier les notifications d'une application tierce spécifique pour chaque canal et chaque niveau de package d'application.
  • [C-1-6] DOIT également fournir une option permettant à l'utilisateur d'afficher les canaux de notification supprimés.
  • [C-1-7] DOIT afficher correctement toutes les ressources (images, autocollants, icônes, etc.) fournies par le biais de Notification.MessagingStyle à côté du texte de la notification, sans interaction supplémentaire de l'utilisateur. Par exemple, TOUTES les ressources, y compris les icônes fournies par le biais de android.app.Person, DOIVENT être affichées dans une conversation de groupe définie par setGroupConversation.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'afficher automatiquement une option permettant à l'utilisateur de bloquer les notifications d'une application tierce spécifique pour chaque canal et chaque niveau de package d'application après que l'utilisateur a ignoré cette notification à plusieurs reprises.
  • DOIT prendre en charge les notifications enrichies.
  • DOIT présenter certaines notifications à priorité élevée sous forme de notifications prioritaires.
  • DOIT permettre à l'utilisateur de répéter les notifications.
  • MAY ne peut gérer que la visibilité et le calendrier des notifications d'événements importants que les applications tierces peuvent envoyer aux utilisateurs, afin d'atténuer les problèmes de sécurité tels que la distraction du conducteur.

Si les implémentations d'appareils sont compatibles avec les notifications enrichies, elles :

  • [C-2-1] DOIT utiliser les ressources exactes fournies par 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, l'icône, le titre et le texte récapitulatif) défini dans la classe d'API Notification.Style et ses sous-classes.

Si les implémentations d'appareils sont compatibles avec les notifications prioritaires, elles :

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

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

Si les implémentations d'appareil signalent l'indicateur de fonctionnalité android.hardware.ram.normal, elles :

  • [C-1-1] DOIT mettre à jour correctement et rapidement les notifications dans leur intégralité pour tous les services d'écoute 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(), et fermer la notification et effectuer un rappel après la durée de report définie dans l'appel d'API.

Si les implémentations d'appareils permettent aux utilisateurs de suspendre les notifications, elles :

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

Si les implémentations d'appareils sont compatibles avec la fonctionnalité Ne pas déranger, elles :

  • [C-1-1] DOIT implémenter une activité qui répond à l'intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS, qui, pour les implémentations avec UI_MODE_TYPE_NORMAL, DOIT être une activité où l'utilisateur peut accorder ou refuser l'accès de l'application aux configurations de la politique Ne pas déranger.
  • [C-1-2] DOIT, lorsque l'implémentation de l'appareil a fourni à l'utilisateur un moyen d'autoriser ou de refuser l'accès des applications tierces à la configuration de la règle Ne pas déranger, afficher les Règles Ne pas déranger automatiques créées par les applications à côté des règles créées par l'utilisateur et prédéfinies.
  • [C-1-3] DOIT respecter les valeurs suppressedVisualEffects transmises avec 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 règle générale, cette fonctionnalité se compose d'une interface utilisateur unique à l'échelle du système qui permet aux utilisateurs de saisir des requêtes, affiche des suggestions à mesure qu'ils saisissent du texte et affiche les résultats. Les API Android permettent aux développeurs de réutiliser cette interface pour proposer une fonctionnalité de 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 fournir des suggestions en temps réel en réponse aux saisies de l'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 utilisant la recherche globale n'est installée :

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

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

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

  • [C-2-1] DOIT indiquer clairement à l'utilisateur final quand le contexte est partagé, soit :
    • Chaque fois que l'application d'assistance accède au contexte, une lumière blanche s'affiche autour des bords de l'écran, avec une durée et une luminosité égales ou supérieures à celles de l'implémentation de l'Android Open Source Project.
    • Pour l'application d'assistance préinstallée, fournir une affordance utilisateur à moins de deux navigations du menu des paramètres par défaut de l'application d'assistance et de saisie vocale, et ne partager le contexte que lorsque l'application d'assistance est explicitement appelée par l'utilisateur via un mot clé ou une 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é gérant l'intent ACTION_ASSIST.

3.8.5. Alertes et toasts

Les applications peuvent utiliser l'API Toast pour afficher de courtes chaînes non modales à l'utilisateur final, qui disparaissent après une brève période, et utiliser 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" comme mécanisme permettant aux applications d'appliquer des styles à une activité ou une application entière.

Android inclut une famille de thèmes "Holo" et "Material" en tant qu'ensemble de styles définis que les développeurs d'applications peuvent utiliser s'ils souhaitent correspondre à 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 :

Android inclut également une famille de thèmes "Device Default" (Par défaut de l'appareil) qui correspond à un ensemble de styles définis que les développeurs d'applications peuvent utiliser s'ils souhaitent que l'apparence de leur application corresponde à celle du thème de l'appareil tel que défini par l'implémenteur de l'appareil.

Android est compatible avec un thème de variante avec des barres système translucides, ce qui permet aux développeurs d'applications de remplir la zone située derrière la barre d'état et la barre de navigation avec le contenu de leur application. Pour permettre une expérience de développement cohérente dans cette configuration, il est important que le style d'icône 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 système, elles :

  • [C-2-1] DOIT utiliser le blanc pour les icônes d'état du système (telles que l'intensité du signal et le niveau de batterie) et les notifications émises par le système, sauf si l'icône indique un état problématique ou si 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 modifier la couleur des icônes d'état du système en noir (pour plus de détails, 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 que l'API et le 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 capacités d'entrée limitées qui s'affichent en tant que fond d'écran, derrière d'autres applications.

Un 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 limitation de fonctionnalité, à une fréquence d'images raisonnable et sans effets indésirables sur les autres applications. Si des limitations matérielles entraînent le plantage ou le dysfonctionnement des fonds d'écran et/ou des applications, une consommation excessive de processeur ou de batterie, ou une fréquence d'images inacceptablement basse, le matériel est considéré comme incapable d'exécuter des fonds d'écran animés. 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 fonctionnera pas de manière fiable sur du matériel qui ne prend pas en charge plusieurs contextes OpenGL, car l'utilisation d'un contexte OpenGL par le fond d'écran animé peut entrer en conflit avec d'autres applications qui utilisent également un contexte OpenGL.

  • Les implémentations d'appareils capables d'exécuter des fonds d'écran 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 la 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 pour le changement de tâche et l'affichage des activités et tâches récemment consultées à l'aide d'une miniature de l'état graphique de l'application au moment où l'utilisateur l'a quittée pour la dernière fois.

Les implémentations d'appareils incluant la touche de navigation de la fonction "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 fonction "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 au moins afficher le titre de quatre activités à la fois.
  • [C-1-2] DOIT implémenter le comportement d'épinglage d'écran et fournir à l'utilisateur un menu de paramètres pour activer/désactiver la fonctionnalité.
  • DOIT afficher la couleur de mise en surbrillance, l'icône et le titre de l'écran dans les éléments récents.
  • DOIT afficher une option de fermeture ("x"), mais PEUT la retarder 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 changement rapide entre les deux applications les plus récemment utilisées lorsque la touche de fonction "Récents" est appuyée deux fois.
  • DOIT déclencher le mode multifenêtre en écran partagé, si celui-ci est pris en charge, lorsque l'utilisateur appuie de manière prolongée sur la touche de fonction "Récents".
  • PEUT afficher les éléments récents affilié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 similaire basée sur des miniatures) pour l'écran "Récents".

3.8.9. Gestion des entrées

Android inclut la prise en charge de la gestion des entrées et des éditeurs de méthode d'entrée tiers.

Si les implémentations d'appareils permettent aux utilisateurs d'utiliser des méthodes de saisie tierces 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 telles que définies dans la documentation du SDK Android.
  • [C-1-2] DOIT fournir un mécanisme accessible aux utilisateurs pour ajouter et configurer des méthodes de saisie tierces en réponse à l'intent android.settings.INPUT_METHOD_SETTINGS.

Si les implémentations d'appareil 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 Remote Control Client est obsolète depuis Android 5.0 au profit du 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 "Rêves")

Android est compatible avec les économiseurs d'écran interactifs, anciennement appelés "Rêves". Les économiseurs d'écran permettent aux utilisateurs d'interagir avec des applications lorsqu'un appareil connecté à une source d'alimentation est inactif ou placé dans une station d'accueil. Les appareils Android Wear PEUVENT implémenter des économiseurs d'écran, mais les autres types d'implémentations d'appareils DOIVENT inclure la prise en charge des économiseurs d'écran et fournir une option de paramètre permettant aux utilisateurs de configurer les économiseurs d'écran en réponse à l'intention 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, elles

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] 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érentes é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 d'Unicode 7.0 pour le latin, le grec et le cyrillique, y compris les plages Latin étendu A, B, C et D, ainsi que tous les glyphes du bloc des symboles monétaires d'Unicode 7.0.
  • DOIT être compatible avec les emoji de couleur de peau et de famille diversifiée spécifiés dans le rapport technique Unicode #51.

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

  • DOIT fournir à l'utilisateur une méthode de saisie pour ces caractères emoji.

Android est compatible avec l'affichage des polices birmanes. Le Myanmar utilise plusieurs polices non conformes à Unicode, communément appelées "Zawgyi", pour afficher les langues du pays.

Si les implémentations d'appareils sont compatibles avec le birman, elles : 

* [C-2-1] MUST render text with Unicode compliant font as default;
  non-Unicode compliant font MUST NOT be set as default font unless the user
  chooses it in the language picker.
* [C-2-2] MUST support a Unicode font and a non-Unicode compliant font if a
  non-Unicode compliant font is supported on the device.  Non-Unicode
  compliant font MUST NOT remove or overwrite the Unicode font.
* [C-2-3] MUST render text with non-Unicode compliant font ONLY IF a
  language code with [script code Qaag](
  http://unicode.org/reports/tr35/#unicode_script_subtag_validity) is
  specified (e.g. my-Qaag). No other ISO language or region codes (whether
  assigned, unassigned, or reserved) can be used to refer to non-Unicode
  compliant font for Myanmar. App developers and web page authors can
  specify my-Qaag as the designated language code as they would for any
  other language.

3.8.14. Mode multifenêtre

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

  • [C-1-1] DOIT implémenter ce ou ces modes multifenêtre conformément aux comportements d'application et aux API décrits dans la documentation sur la prise en charge du mode multifenêtre du SDK Android, et répondre aux exigences suivantes :
  • [C-1-2] DOIT respecter android:resizeableActivity défini par une application dans le fichier AndroidManifest.xml, comme décrit dans ce SDK.
  • [C-1-3] NE DOIT PAS proposer le mode Écran partagé ni le mode Format libre si la hauteur et la largeur de l'écran sont inférieures à 440 dp.
  • [C-1-4] Une activité NE DOIT PAS être redimensionnée à une taille inférieure à 220 dp dans les modes multifenêtre autres que le mode Picture-in-picture.
  • Les implémentations d'appareils avec une taille d'écran xlarge DOIVENT être compatibles avec le mode Format libre.

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

  • [C-2-1] DOIT précharger un lanceur d'applications redimensionnable par défaut.
  • [C-2-2] DOIT recadrer l'activité ancrée d'une fenêtre multifenêtre en écran partagé, mais DOIT afficher une partie de son contenu si l'app 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 d'applications tierce et ne pas les remplacer lors de l'affichage de certains contenus de l'activité ancrée.

Si les implémentations d'appareils 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 d'image 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] DOIT 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é au premier plan.
  • [C-3-5] DOIT fournir une affordance utilisateur pour empêcher une application de s'afficher en mode PIP. L'implémentation AOSP répond à cette exigence en proposant des commandes dans la barre de notifications.
  • [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 minimale de 135 dp pour la fenêtre PIP lorsque Configuration.uiMode est configuré sur UI_MODE_TYPE_TELEVISION.

3.8.15. Encoche

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

Si les implémentations d'appareil incluent une ou plusieurs encoches, elles doivent :

  • [C-1-1] NE DOIT comporter des encoches que sur les bords courts de l'appareil. À l'inverse, si le format de l'appareil est de 1.0(1:1), il NE DOIT PAS comporter d'encoche(s).
  • [C-1-2] NE DOIT PAS comporter plus d'une encoche par bord.
  • [C-1-3] DOIT respecter les indicateurs d'encoche définis par l'application via l'API WindowManager.LayoutParams, comme décrit dans le SDK.
  • [C-1-4] DOIT signaler les valeurs correctes pour toutes les métriques de découpe définies dans l'API DisplayCutout.

3.9. Gestion de l'appareil

Android inclut des fonctionnalités qui permettent aux applications soucieuses de la sécurité d'effectuer des fonctions d'administration des appareils au niveau du système, telles que l'application de règles relatives aux mots 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] DOIT 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'appareil déclarent android.software.device_admin, elles :

  • [C-1-1] DOIT permettre d'enregistrer un client Device Policy (DPC) en tant qu'application propriétaire de l'appareil, comme décrit ci-dessous :
  • [C-1-2] DOIT exiger une action affirmative pendant le processus d'approvisionnement pour autoriser la définition de l'application en tant que propriétaire de l'appareil. Le consentement peut être obtenu par le biais d'une action de l'utilisateur ou par un moyen programmatique lors du provisionnement, mais il ne DOIT PAS être codé en dur ni empêcher l'utilisation d'autres applications de propriétaire 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" au propriétaire de l'appareil standard tel qu'il est reconnu par les API DevicePolicyManager Android standards, elles :

  • [C-2-1] DOIT disposer d'un processus permettant de vérifier que l'application spécifique promue appartient à une solution légitime de gestion des appareils d'entreprise et qu'elle a déjà été configurée dans la solution propriétaire pour disposer de droits équivalents à ceux d'un "propriétaire de l'appareil".
  • [C-2-2] DOIT afficher la même divulgation du consentement du propriétaire de l'appareil AOSP que le flux initié par android.app.action.PROVISION_MANAGED_DEVICE avant d'enregistrer l'application DPC en tant que "propriétaire de l'appareil".
  • Il est POSSIBLE que l'appareil contienne des données utilisateur avant l'enregistrement de 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'appareil déclarent android.software.managed_users, elles :

  • [C-1-1] DOIT implémenter les API permettant à une application Device Policy Controller (DPC) de devenir le propriétaire d'un nouveau profil géré.

  • [C-1-2] Le processus de provisionnement de profil géré (flux initié par android.app.action.PROVISION_MANAGED_PROFILE) que les utilisateurs expérimentent DOIT correspondre à l'implémentation AOSP.

  • [C-1-3] DOIT fournir les affordances utilisateur suivantes dans les paramètres pour indiquer à l'utilisateur lorsqu'une fonction système particulière a été désactivée par le contrôleur de règles relatives aux appareils (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 de l'appareil.
    • Message explicatif court, fourni 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'appareil déclarent android.software.managed_users, elles :

  • [C-1-1] DOIT être compatible avec les profils gérés via les API android.app.admin.DevicePolicyManager.
  • [C-1-2] DOIT autoriser la création d'un seul profil géré.
  • [C-1-3] DOIT utiliser un badge d'icône (semblable au badge de travail en amont AOSP) pour représenter les applications et widgets gérés, ainsi que d'autres éléments d'interface utilisateur avec badge, comme les applications récentes et les notifications.
  • [C-1-4] DOIT afficher une icône de notification (semblable au badge de profil professionnel 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é lorsque l'appareil se réactive (ACTION_USER_PRESENT) et que l'application au premier plan se trouve dans le profil géré.
  • [C-1-6] Lorsqu'un profil géré existe, une indication visuelle DOIT être affichée dans le sélecteur d'intent pour permettre à l'utilisateur de transférer l'intent du profil géré vers l'utilisateur principal ou inversement, si le contrôleur de règles de l'appareil l'a activé.
  • [C-1-7] Lorsqu'un profil géré existe, les affordances utilisateur suivantes DOIVENT être exposées à la fois pour l'utilisateur principal et pour le profil géré :
    • Comptabilité distincte pour l'utilisation de la batterie, de la localisation, des données mobiles et du stockage pour l'utilisateur principal et le profil géré.
    • Gestion indépendante des applications VPN installées dans le profil principal ou géré.
    • Gestion indépendante des applications installées dans le profil principal ou géré.
    • Gestion indépendante des comptes dans le profil utilisateur principal ou géré.
  • [C-1-8] DOIT s'assurer que les applications de téléphone, de contacts et de messagerie préinstallées peuvent rechercher et consulter les informations sur l'appelant à partir du profil géré (le cas échéant) en plus de celles du profil principal, si le contrôleur de règles relatives aux appareils le permet.
  • [C-1-9] DOIT s'assurer de respecter 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 considéré 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 s'exécutant dans un profil géré.
    • Les implémentations d'appareils DOIVENT respecter l'intention DevicePolicyManager.ACTION_SET_NEW_PASSWORD et afficher une interface permettant de configurer un identifiant d'écran de verrouillage distinct 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 Android Open Source.
    • Les règles relatives aux mots 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 des contacts du profil géré sont affichés dans le journal d'appels préinstallé, dans l'interface utilisateur pendant l'appel, dans les notifications d'appels en cours et manqués, dans les applications de contacts et de messagerie, ils DOIVENT être signalés par le même badge que celui utilisé pour indiquer les applications du profil géré.

3.9.3 Assistance pour les utilisateurs gérés

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

  • [C-1-1] DOIT fournir une affordance utilisateur pour se déconnecter de l'utilisateur actuel et 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 en situation de 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 commentaires, tels que la synthèse vocale, le retour haptique et la navigation à l'aide d'une trackball ou d'un pavé directionnel.

Si les implémentations d'appareils sont compatibles avec les 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 des API d'accessibilité.
  • [C-1-2] DOIT générer des événements d'accessibilité et fournir le AccessibilityEvent approprié à toutes les implémentations AccessibilityService enregistrées, comme indiqué dans le SDK.
  • [C-1-3] DOIT respecter l'intention android.settings.ACCESSIBILITY_SETTINGS de fournir un mécanisme accessible aux utilisateurs pour activer et 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 ne s'applique pas 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 d'appareils incluent des services d'accessibilité préinstallés, elles :

  • [C-2-1] DOIT implémenter ces services d'accessibilité préinstallés en tant qu'applications Direct Boot Aware 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'affichage et les gestes d'agrandissement.

3.11. Synthèse vocale

Android inclut des API qui permettent aux applications d'utiliser des services de synthèse vocale et aux fournisseurs de services de fournir des implémentations de services de synthèse vocale.

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

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

  • [C-2-1] DOIT fournir à l'utilisateur la possibilité de sélectionner un moteur TTS à utiliser au niveau du système.

3.12. Framework d'entrée TV

Le framework d'entrée de télévision Android (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 d'appareils sont compatibles avec le format TIF, elles :

  • [C-1-1] DOIT déclarer la fonctionnalité de plate-forme android.software.live_tv.
  • [C-1-2] DOIT être compatible avec 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'interface utilisateur de configuration rapide qui permet d'accéder rapidement aux actions fréquemment utilisées ou urgentes.

Si les implémentations d'appareils incluent un composant d'interface utilisateur Paramètres rapides, elles :

  • [C-1-1] DOIT permettre à l'utilisateur d'ajouter ou de supprimer les tuiles fournies par les API quicksettings à partir d'une application tierce.
  • [C-1-2] NE DOIT PAS ajouter automatiquement un bloc d'une application tierce directement aux réglages rapides.
  • [C-1-3] DOIT afficher tous les blocs ajoutés par l'utilisateur à partir d'applications tierces à côté des blocs de réglages rapides fournis par le système.

3.14. Interface utilisateur Media

Si les implémentations d'appareils incluent des applications non activées par la voix (les Applications) qui interagissent avec des applications tierces via MediaBrowser ou MediaSession, les Applications :

  • [C-1-2] DOIT afficher clairement les icônes obtenues via getIconBitmap() ou getIconUri(), ainsi que les titres obtenus via getTitle(), comme décrit dans MediaDescription. Les titres peuvent être raccourcis pour respecter les règles de sécurité (par exemple, la distraction du conducteur).

  • [C-1-3] DOIT afficher l'icône de l'application tierce chaque fois qu'il affiche du contenu fourni par cette application tierce.

  • [C-1-4] DOIT permettre à l'utilisateur d'interagir avec l'ensemble de la hiérarchie MediaBrowser. PEUT limiter l'accès à une partie de la hiérarchie pour respecter les règles de sécurité (par exemple, la distraction du conducteur), mais NE DOIT PAS accorder de traitement préférentiel en fonction du contenu ou du fournisseur de contenu.

  • [C-1-5] DOIT considérer le double-tap sur KEYCODE_HEADSETHOOK ou KEYCODE_MEDIA_PLAY_PAUSE comme KEYCODE_MEDIA_NEXT pour MediaSession.Callback#onMediaButtonEvent.

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 se voir accorder que les autorisations dont android:protectionLevel est défini sur "instant".
  • [C-0-2] Les applis 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 l'une des suivantes : ACTION_SEND, ACTION_SENDTO ou ACTION_SEND_MULTIPLE.
    • La cible est explicitement exposée avec android:visibleToInstantApps.
  • [C-0-3] Les applis 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 détails concernant les applications instantanées sur l'appareil, sauf si l'application instantanée se connecte explicitement à l'application installée.
  • Les implémentations d'appareils DOIVENT fournir les affordances utilisateur suivantes pour interagir avec les applis instantanées. L'AOSP répond aux exigences avec l'interface utilisateur, les paramètres et le lanceur de l'application système par défaut. Implémentations d'appareils :
    • [C-0-5] DOIT fournir une affordance utilisateur pour afficher et supprimer les applications instantanées mises en cache localement pour chaque package d'application individuel.
    • [C-0-6] DOIT fournir une notification utilisateur persistante qui peut être réduite lorsqu'une appli instantanée est exécutée au premier plan. Cette notification utilisateur DOIT indiquer que les applis instantanées ne nécessitent pas d'installation et fournir une affordance utilisateur qui redirige l'utilisateur vers l'écran d'informations sur l'application dans les paramètres. Pour les applications instantanées lancées via des intents Web, définis en utilisant un intent avec une action définie sur Intent.ACTION_VIEW et avec un schéma "http" ou "https", une affordance utilisateur supplémentaire DOIT permettre à l'utilisateur de ne pas lancer l'application instantanée et de lancer le lien associé avec le navigateur Web configuré, si un navigateur est disponible sur l'appareil.
    • [C-0-7] DOIT permettre d'accéder aux applications instantanées en cours d'exécution à partir de la fonction "Récents" si celle-ci est disponible sur l'appareil.

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 et 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 d'appareils associés, elles :

  • [C-1-1] DOIT déclarer le commutateur 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 utilisateur permettant à l'utilisateur de sélectionner/confirmer qu'un appareil associé est présent et opérationnel.

3.17. Applications gourmandes en ressources

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

  • [C-1-1] Une seule application spécifiant cantSaveState doit être installée et exécutée dans le système à la fois. Si l'utilisateur quitte une telle application sans la fermer explicitement (par exemple, en appuyant sur le bouton d'accueil tout en quittant une activité active du système, au lieu d'appuyer sur le bouton Retour sans qu'il reste d'activité active dans le système), les implémentations d'appareil DOIVENT donner la priorité à cette application dans la RAM, comme elles le font pour d'autres éléments qui doivent rester en cours d'exécution, tels que les services de premier plan. Lorsqu'une telle application est en arrière-plan, le système peut toujours lui appliquer des fonctionnalités de gestion de l'alimentation, comme 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 normal d'enregistrement/restauration de l'état une fois que l'utilisateur aura lancé une deuxième application déclarée avec l'attribut cantSaveState.
  • [C-1-3] NE DOIT PAS appliquer d'autres modifications des règles aux applications qui spécifient cantSaveState, comme la modification des performances du processeur ou de la priorité de planification.

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

  • [C-1-1] MUST ignore the cantSaveState attribute set by apps and MUST NOT change the app behavior based on that attribute.

4. Compatibilité du packaging d'application

Implémentations des appareils :

  • [C-0-1] DOIT être capable d'installer et d'exécuter des 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 être difficile à respecter, il est RECOMMANDÉ aux implémentations d'appareils d'utiliser le système de gestion des packages de l'implémentation de référence AOSP.

Implémentations d'appareils :

  • [C-0-2] DOIT être compatible avec la validation des fichiers ".apk" à l'aide des schémas de signature des APK v3 et v2 , ainsi que 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 correctes de ces fichiers sur d'autres appareils compatibles.

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

  • [C-0-5] DOIT disposer d'une activité qui gère l'intent android.settings.MANAGE_UNKNOWN_APP_SOURCES.

  • [C-0-6] NE DOIT PAS installer de packages d'application provenant 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 pour accorder/révoquer l'autorisation d'installer des applications provenant de sources inconnues par application, mais PEUT choisir d'implémenter cela comme une no-op et de renvoyer RESULT_CANCELED pour startActivityForResult(), si l'implémentation de l'appareil ne souhaite pas permettre aux utilisateurs d'avoir ce choix. Toutefois, même dans ce cas, ils DOIVENT indiquer à l'utilisateur pourquoi ce choix ne lui est pas proposé.

  • [C-0-7] DOIT afficher une boîte de dialogue d'avertissement avec la chaîne d'avertissement fournie par l'API système PackageManager.setHarmfulAppWarning à l'utilisateur 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 option 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 sur les appareils :

  • [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 capable de décoder correctement tous les formats qu'il peut encoder et de les mettre à la disposition des applications tierces. Cela inclut tous les flux de bits générés par ses encodeurs et les profils indiqués dans son CamcorderProfile.

Implémentations sur les appareils :

  • DOIT viser une latence de codec minimale, en d'autres termes, ils
    • NE DOIT PAS consommer ni stocker les tampons d'entrée, et ne doit renvoyer les tampons d'entrée 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 selon 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 garantissent que 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 brevet auprès des titulaires de brevet 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 des formats audio suivants et les mettre à la disposition des applications tierces :

  • [C-1-1] PCM/WAVE
  • [C-1-2] FLAC
  • [C-1-3] Opus

Tous les encodeurs audio DOIVENT être compatibles avec les éléments suivants :

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 prendre en charge la fonctionnalité android.hardware.audio.output, elles DOIVENT être compatibles avec le décodage des formats audio suivants :

  • [C-1-1] Profil AAC MPEG-4 (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 étendu HE-AAC 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, y compris les formats audio haute résolution jusqu'à 24 bits, avec une fréquence d'échantillonnage de 192 kHz et 8 canaux. Notez que cette exigence ne concerne que le décodage. Un appareil est autorisé à sous-échantillonner et à sous-mixer pendant la phase de lecture.
  • [C-1-10] Opus

Si les implémentations d'appareils 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 dans l'API android.media.MediaCodec, les éléments suivants DOIVENT être pris en charge :

  • [C-2-1] Le décodage DOIT être effectué sans mixage réducteur (par exemple, un flux AAC 5.0 DOIT être décodé en cinq canaux PCM, et 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 définies dans la section "Dynamic Range Control (DRC)" de la norme ISO/IEC 14496-3, et les clés DRC android.media.MediaFormat permettent de 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.
  • [SR] Il est FORTEMENT RECOMMANDÉ que les exigences C-2-1 et C-2-2 ci-dessus soient respectées par tous les décodeurs audio AAC.

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

  • [C-3-1] Les métadonnées de volume 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 :

  • MAY est compatible avec le contrôle du volume et de la plage dynamique à l'aide du profil de contrôle de la plage dynamique ISO/IEC 23003-4.

Si la norme ISO/IEC 23003-4 est acceptée et que les métadonnées ISO/IEC 23003-4 et ISO/IEC 14496-3 sont présentes dans un flux binaire décodé :

  • Les métadonnées ISO/IEC 23003-4 prévalent.

Tous les décodeurs audio DOIVENT être compatibles avec les sorties suivantes :

5.1.3. Détails des codecs audio

Format/Codec Détails Types de fichiers/formats de conteneurs à prendre en charge
Profil AAC MPEG-4
(AAC LC) 		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)
  • ADTS AAC brut (.aac, ADIF non accepté)
  • MPEG-TS (.ts, non consultable, décodage uniquement)
  • Matroska (.mkv, décodage uniquement)
Profil MPEG-4 HE AAC (AAC+) Prise en charge des contenus mono/stéréo/5.0/5.1 avec des taux d'échantillonnage standards de 16 à 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
Profil MPEG-4 HE AACv2
(AAC+ amélioré) 		Prise en charge des contenus mono/stéréo/5.0/5.1 avec des taux d'échantillonnage standards de 16 à 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
AAC ELD (AAC à faible délai amélioré) Prise en charge des contenus mono/stéréo avec des taux d'échantillonnage standards de 16 à 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
USAC Contenu mono/stéréo avec des taux d'échantillonnage standards de 7,35 à 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, tels que définis dans AMR-WB, Adaptive Multi-Rate - Wideband Speech Codec 3GPP (.3gp)
FLAC Pour l'encodeur et le décodeur : les modes mono et stéréo DOIVENT au moins être pris en charge. Les taux d'échantillonnage jusqu'à 192 kHz DOIVENT être pris en charge, ainsi que les résolutions 16 bits et 24 bits. La gestion des données audio FLAC 24 bits DOIT être disponible avec la configuration audio à virgule flottante.
  • FLAC (.flac)
  • MPEG-4 (.mp4, .m4a, décodage uniquement)
  • Matroska (.mkv, décodage uniquement)
MP3 Mono/Stéréo, débit constant (CBR) ou variable (VBR) de 8 à 320 kbit/s
  • MP3 (.mp3)
  • MPEG-4 (.mp4, .m4a, décodage uniquement)
  • Matroska (.mkv, décodage uniquement)
MIDI MIDI de type 0 et 1. DLS versions 1 et 2. 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)
  • MPEG-4 (.mp4, .m4a, décodage uniquement)
  • Matroska (.mkv)
  • WebM (.webm)
PCM/WAVE Le codec PCM DOIT être compatible avec le PCM linéaire 16 bits et le format à virgule flottante 16 bits. L'extracteur WAVE DOIT être compatible avec les formats PCM linéaire 16 bits, 24 bits et 32 bits, ainsi qu'avec le format flottant 32 bits (fréquences jusqu'à la limite du matériel). Les taux d'échantillonnage DOIVENT être compatibles de 8 kHz à 192 kHz. WAVE (.wav)
Opus
  • Ogg (.ogg)
  • MPEG-4 (.mp4, .m4a, décodage uniquement)
  • Matroska (.mkv)
  • WebM (.webm)

5.1.4. Encodage d'images

Pour en savoir plus, consultez la section 5.1.6. Détails sur les codecs d'image

Les implémentations d'appareils DOIVENT être compatibles avec l'encodage d'image suivant :

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

Si les implémentations d'appareils sont compatibles avec l'encodage HEIC via android.media.MediaCodec pour le type de contenu multimédia MIMETYPE_IMAGE_ANDROID_HEIC, elles :

  • [C-1-1] DOIT fournir un codec d'encodeur HEVC à accélération matérielle qui prend en charge le mode de contrôle du débit binaire BITRATE_MODE_CQ, le profil HEVCProfileMainStill et la taille de frame de 512 x 512 px.

5.1.5. Décodage d'image

Pour en savoir plus, consultez la section 5.1.6. Détails sur les codecs d'image

Les implémentations d'appareils DOIVENT être compatibles avec 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)

Décodeurs d'image compatibles avec un format à haute profondeur de bits (9 bits ou plus par canal)

  • [C-1-1] DOIT être compatible avec la sortie d'un format équivalent de 8 bits si l'application le demande, par exemple via la configuration ARGB_8888 de android.graphics.Bitmap.

5.1.6. Détails sur les codecs d'image

Format/Codec Détails Types de fichiers/formats de conteneurs acceptés
JPEG Base+progressif 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)

Encodeurs et décodeurs d'images exposés via l'API MediaCodec

  • [C-1-1] DOIT être compatible avec le format de couleur flexible YUV420 8:8:8 (COLOR_FormatYUV420Flexible) via CodecCapabilities.

  • [SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge le format de couleurs RGB888 pour le mode Surface d'entrée.

  • [C-1-3] DOIT être compatible avec au moins un format de couleur YUV420 8:8:8 plan ou semi-plan : COLOR_FormatYUV420PackedPlanar (équivalent à COLOR_FormatYUV420Planar) ou COLOR_FormatYUV420PackedSemiPlanar (équivalent à COLOR_FormatYUV420SemiPlanar). Il est FORTEMENT RECOMMANDÉ qu'il soit compatible avec les deux.

5.1.7. Codecs vidéo

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

Si les implémentations d'appareils incluent un décodeur ou un encodeur vidéo :

  • [C-1-1] Les codecs vidéo DOIVENT être compatibles avec les tailles de bytebuffer d'entrée et de sortie qui permettent d'accueillir la plus grande trame compressée et non compressée possible, comme le prévoient la norme et la configuration, mais sans surallocation.

  • [C-1-2] Les encodeurs et décodeurs vidéo DOIVENT être compatibles avec les formats de couleur flexibles YUV420 8:8:8 (COLOR_FormatYUV420Flexible) via CodecCapabilities.

  • [C-1-3] Les encodeurs et décodeurs vidéo DOIVENT être compatibles avec au moins un format de couleur YUV420 8:8:8 planaire ou semi-planaire : COLOR_FormatYUV420PackedPlanar (équivalent à COLOR_FormatYUV420Planar) ou COLOR_FormatYUV420PackedSemiPlanar (équivalent à COLOR_FormatYUV420SemiPlanar). Il est FORTEMENT RECOMMANDÉ qu'ils soient compatibles avec les deux.

  • [SR] Il est FORTEMENT RECOMMANDÉ que les encodeurs et décodeurs vidéo soient compatibles avec au moins un format de couleur YUV420 8:8:8 plan ou semi-plan optimisé pour le matériel (YV12, NV12, NV21 ou format équivalent optimisé par le fournisseur).

  • [C-1-5] Les décodeurs vidéo compatibles avec un format à haute profondeur de bits (9 bits ou plus par canal) DOIVENT être compatibles avec la sortie d'un format équivalent à 8 bits si l'application le demande. Cela DOIT se refléter dans la prise en charge d'un format de couleur YUV420 8:8:8 via android.media.MediaCodecInfo.

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 par le biais de 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 précision dans les 20 % de la période d'actualisation configurée.

Sauf indication contraire de l'application à l'aide de la clé de format KEY_COLOR_FORMAT, les implémentations de décodeur vidéo :

  • [C-4-1] DOIT utiliser par défaut le format de couleur optimisé pour l'affichage matériel s'il est configuré à l'aide de la sortie Surface.
  • [C-4-2] DOIT utiliser par défaut un format de couleur YUV420 8:8:8 optimisé pour la lecture du processeur s'il est configuré pour ne pas utiliser la sortie Surface.

5.1.8. Liste des codecs vidéo

Format/Codec Détails Types de fichiers/formats de conteneurs à prendre en charge
H.263
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • Matroska (.mkv, décodage uniquement)
H.264 AVC Pour en savoir plus, consultez les sections 5.2 et 5.3.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • MPEG-2 TS (.ts, non consultable)
  • Matroska (.mkv, décodage uniquement)
H.265 HEVC Pour en savoir plus, consultez la section 5.3.
  • MPEG-4 (.mp4)
  • Matroska (.mkv, décodage uniquement)
MPEG-2 Main Profile
  • MPEG2-TS (.ts, non consultable)
  • MPEG-4 (.mp4, décodage uniquement)
  • Matroska (.mkv, décodage uniquement)
MPEG-4 SP
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • Matroska (.mkv, décodage uniquement)
VP8 Pour en savoir plus, consultez les sections 5.2 et 5.3.
VP9 Pour en savoir plus, consultez la section 5.3.

5.1.9. Sécurité des codecs multimédias

Les implémentations d'appareils DOIVENT assurer la conformité avec les fonctionnalités de sécurité des codecs multimédias, comme décrit ci-dessous.

Android est compatible avec OMX, une API d'accélération multimédia multiplate-forme, ainsi qu'avec Codec 2.0, une API d'accélération multimédia à faible surcharge.

Si les implémentations d'appareils sont compatibles avec le multimédia, elles :

  • [C-1-1] DOIT être compatible avec les codecs multimédias via les API OMX ou Codec 2.0 (ou les deux) comme dans le Projet Android Open Source, et ne pas désactiver ni contourner les protections de sécurité. Cela ne signifie pas que chaque codec DOIT utiliser l'API OMX ou Codec 2.0, mais qu'au moins l'une de ces API DOIT être disponible et que la prise en charge des API disponibles DOIT inclure les protections de sécurité présentes.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'inclure la compatibilité avec l'API Codec 2.0.

Si les implémentations d'appareils ne sont pas compatibles avec l'API Codec 2.0, elles :

  • [C-2-1] DOIT inclure le codec logiciel OMX correspondant du projet Android Open Source (s'il est disponible) pour chaque format et type de contenu multimédia (encodeur ou décodeur) pris en charge par l'appareil.
  • [C-2-2] Codecs dont le nom commence par "OMX.google." DOIT être basé sur le code source de l'Android Open Source Project.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ que les codecs logiciels OMX s'exécutent dans un processus de codec qui n'a accès qu'aux mappeurs de mémoire, et non aux pilotes matériels.

Si les implémentations d'appareils sont compatibles avec l'API Codec 2.0, elles :

  • [C-3-1] DOIT inclure le codec logiciel Codec 2.0 correspondant du projet Android Open Source (s'il est disponible) pour chaque format et type de contenu multimédia (encodeur ou décodeur) pris en charge par l'appareil.
  • [C-3-2] DOIT héberger les codecs logiciels Codec 2.0 dans le processus de codec logiciel tel que fourni dans le projet Android Open Source pour permettre d'accorder plus précisément l'accès aux codecs logiciels.
  • [C-3-3] Codecs dont le nom commence par "c2.android." DOIT être basé sur le code source du projet Android Open Source.

5.1.10. Caractérisation des codecs multimédias

Si les implémentations d'appareils sont compatibles avec les codecs multimédias, elles :

  • [C-1-1] DOIT renvoyer les valeurs correctes de la caractérisation du codec média via l'API MediaCodecInfo.

En particulier :

  • [C-1-2] Codecs dont le nom commence par "OMX." DOIT utiliser les API OMX et avoir des noms conformes aux consignes de dénomination OMX IL.
  • [C-1-3] Codecs dont le nom commence par "c2." DOIT utiliser l'API Codec 2.0 et avoir des noms conformes aux consignes de dénomination Codec 2.0 pour Android.
  • [C-1-4] Codecs dont le nom commence par "OMX.google." ou "c2.android." NE DOIT PAS être caractérisé comme un fournisseur ou comme accéléré par le matériel.
  • [C-1-5] Les codecs qui s'exécutent dans un processus de codec (fournisseur ou système) et qui ont accès à des pilotes matériels autres que les allocateurs et les mappeurs de mémoire NE DOIVENT PAS être caractérisés comme étant uniquement logiciels.
  • [C-1-6] Les codecs qui ne sont pas présents dans le projet Android Open Source ou qui ne sont pas basés sur le code source de ce projet DOIVENT être caractérisés comme étant des codecs du fournisseur.
  • [C-1-7] Les codecs qui utilisent l'accélération matérielle DOIVENT être caractérisés comme étant accélérés par le matériel.
  • [C-1-8] Les noms de codecs NE DOIVENT PAS être trompeurs. Par exemple, les codecs nommés "décodeurs" DOIVENT prendre en charge le décodage, et ceux nommés "encodeurs" DOIVENT prendre en charge l'encodage. Les codecs dont le nom contient des formats multimédias DOIVENT prendre en charge ces formats.

Si les implémentations d'appareils sont compatibles avec les codecs vidéo :

  • [C-2-1] Tous les codecs vidéo DOIVENT publier des données sur la fréquence d'images réalisable pour les tailles suivantes, si le codec les prend en charge :
SD (qualité médiocre) SD (haute qualité) HD – 720p HD – 1080p UHD
Résolution vidéo
  • 176 x 144 px (H263, MPEG2, MPEG4)
  • 352 x 288 px (encodeur MPEG4, H263, MPEG2)
  • 320 x 180 px (VP8, VP8)
  • 320 x 240 px (autre)
  • 704 x 576 px (H263)
  • 640 x 360 px (VP8, VP9)
  • 640 x 480 px (encodeur MPEG4)
  • 720 x 480 px (autre)
  • 1 408 x 1 152 px (H263)
  • 1 280 x 720 px (autre)
1 920 x 1 080 px (autre que MPEG4) 3 840 x 2 160 px (HEVC, VP9)
  • [C-2-2] Les codecs vidéo caractérisés comme étant à accélération matérielle DOIVENT publier des informations sur les points de performance. Ils DOIVENT chacun lister tous les points de performances standards acceptés (listés dans l'API PerformancePoint), sauf s'ils sont couverts par un autre point de performances standards accepté.
  • Ils DOIVENT également publier des points de performances étendus s'ils prennent en charge des performances vidéo soutenues autres que celles listées dans les normes.

5.2. Encodage vidéo

Si les implémentations d'appareils sont compatibles avec un encodeur vidéo et le mettent à la disposition des applications tierces, elles :

  • NE DOIT PAS dépasser de plus de 15 % le débit binaire entre les intervalles d'images clés (I-frames) sur deux fenêtres glissantes.
  • NE DOIT PAS dépasser 100 % du débit binaire sur une fenêtre glissante d'une seconde.

Si les implémentations d'appareils incluent un écran intégré d'une longueur diagonale d'au moins 2,5 pouces, 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 inclure la prise en charge d'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 d'appareils sont compatibles avec l'un des encodeurs vidéo H.264, VP8, VP9 ou HEVC et le mettent à la disposition des applications tierces, elles :

  • [C-2-1] DOIT être compatible avec les débits configurables de manière dynamique.
  • DOIT être compatible avec 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 bit bucket en fonction de cette durée d'image.

Si les implémentations d'appareils sont compatibles avec l'encodeur vidéo MPEG-4 SP et le mettent à la disposition des applications tierces, elles :

  • DOIT être compatible avec les débits configurables de manière dynamique pour l'encodeur compatible.

Si les implémentations d'appareils fournissent des encodeurs vidéo ou d'image accélérés par le matériel et prennent en charge une ou plusieurs caméras matérielles connectées ou enfichables exposées via les API android.camera :

  • [C-4-1] Tous les encodeurs vidéo et d'images avec accélération matérielle DOIVENT être compatibles avec l'encodage des frames à partir des caméras matérielles.
  • DOIT être compatible avec l'encodage des frames à partir des caméras matérielles via tous les encodeurs vidéo ou d'image.

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 profil de référence de niveau 45.
  • DOIT être compatible avec les débits configurables de manière dynamique pour l'encodeur compatible.

5.2.2. H.264

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

  • [C-1-1] DOIT être compatible avec le profil de référence de niveau 3. Toutefois, la prise en charge d'ASO (Arbitrary Slice Ordering), de FMO (Flexible Macroblock Ordering) et de RS (Redundant Slices) est FACULTATIVE. De plus, pour maintenir 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 être compatible avec les profils d'encodage vidéo SD (définition standard) du tableau suivant.
  • DOIT être compatible avec 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 indiquent la prise en charge de l'encodage H.264 pour les vidéos en résolution 720p ou 1080p via les API Media, elles :

  • [C-2-1] DOIT prendre en charge les profils d'encodage du tableau suivant.
SD (qualité médiocre) 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 d'appareils sont compatibles avec le codec VP8, elles :

  • [C-1-1] DOIT être compatible avec les profils d'encodage vidéo SD.
  • DOIT être compatible avec les profils d'encodage vidéo HD (haute définition) suivants.
  • [C-1-2] DOIT être compatible avec l'écriture de fichiers Matroska WebM.
  • DOIT fournir un codec VP8 matériel qui répond aux exigences de codage matériel RTC du projet WebM, afin de 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 Media, elles :

  • [C-2-1] DOIT prendre en charge les profils d'encodage du tableau suivant.
SD (qualité médiocre) 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 d'appareils sont compatibles avec le codec VP9, elles :

  • [C-1-2] DOIT être compatible avec le profil 0 niveau 3.
  • [C-1-1] DOIT être compatible avec l'écriture de fichiers Matroska WebM.
  • [C-1-3] DOIT générer des données CodecPrivate.
  • DOIT prendre en charge les profils de décodage HD indiqués dans le tableau suivant.
  • [SR] : il est FORTEMENT RECOMMANDÉ que les SR prennent en charge les profils de décodage HD indiqués dans le tableau suivant s'il existe un encodeur matériel.
SD HD – 720p HD – 1080p UHD
Résolution vidéo 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 ips
Débit vidéo 1,6 Mbit/s 4 Mbit/s 5 Mbit/s 20 Mbit/s

Si les implémentations d'appareils affirment prendre en charge le profil 2 ou le profil 3 via les API Media :

  • La prise en charge du format 12 bits est FACULTATIVE.

5.2.5. H.265

Si les implémentations d'appareils sont compatibles avec le codec H.265, elles :

  • [C-1-1] DOIT être compatible avec le profil principal de niveau 3.
  • DOIT prendre en charge les profils d'encodage HD indiqués dans le tableau suivant.
  • [SR] : il est FORTEMENT RECOMMANDÉ que les SR prennent en charge les profils d'encodage HD indiqués dans le tableau suivant s'il existe un encodeur matériel.
SD HD – 720p HD – 1080p UHD
Résolution vidéo 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 ips
Débit vidéo 1,6 Mbit/s 4 Mbit/s 5 Mbit/s 20 Mbit/s

5.3. Décodage vidéo

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

  • [C-1-1] DOIT prendre en charge le changement dynamique de résolution et de fréquence d'images vidéo via les API Android standards au sein du 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.

5.3.1. MPEG-2

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

  • [C-1-1] DOIT être compatible avec 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 45.

5.3.3. MPEG-4

Si les implémentations d'appareils comportent des décodeurs MPEG-4, elles :

  • [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 être compatible avec le profil principal de niveau 3.1 et le profil de référence. La prise en charge d'ASO (Arbitrary Slice Ordering), de FMO (Flexible Macroblock Ordering) et de RS (Redundant Slices) est FACULTATIVE.
  • [C-1-2] DOIT être capable de décoder les vidéos avec les profils SD (définition standard) listés dans le tableau suivant et encodés avec le profil de base et le profil principal de niveau 3.1 (y compris 720p30).
  • DOIT être capable de décoder les vidéos avec les profils HD (haute définition) indiqués dans le tableau suivant.

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

  • [C-2-1] DOIT être compatible avec les profils de décodage vidéo HD 720p du tableau suivant.
  • [C-2-2] DOIT être compatible avec les profils de décodage vidéo HD 1080p du tableau suivant.
SD (qualité médiocre) 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 fpsTé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 d'appareils sont compatibles avec le codec H.265, elles :

  • [C-1-1] DOIT être compatible avec le profil principal de niveau 3 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 décodeur matériel.

Si la hauteur signalée par la méthode Display.getSupportedModes() est supérieure ou égale à la résolution vidéo :

  • [C-2-1] Les implémentations d'appareils DOIVENT prendre en charge au moins un des profils de décodage H.265 ou VP9 (720, 1080 et UHD).
SD (qualité médiocre) 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 fpsTélévision 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

Si les implémentations d'appareils affirment être compatibles avec un profil HDR (HEVCProfileMain10HDR10, HEVCProfileMain10HDR10Plus) via les API Media :

  • [C-3-1] Les implémentations d'appareils DOIVENT accepter les métadonnées HDR requises (MediaFormat#KEY_HDR_STATIC_INFO pour tous les profils HDR) de l'application à l'aide de l'API MediaCodec, et prendre en charge l'extraction des métadonnées HDR requises (MediaFormat#KEY_HDR_STATIC_INFO pour tous les profils HDR, ainsi que MediaFormat#KEY_HDR10_PLUS_INFO pour les profils HDR10Plus) à partir du flux binaire et/ou du conteneur, comme défini par les spécifications concernées. Ils DOIVENT également être capables de générer les métadonnées HDR requises (MediaFormat#KEY_HDR_STATIC_INFO pour tous les profils HDR) à partir du flux binaire et/ou du conteneur, comme défini par les spécifications correspondantes.

  • [C-SR] Il est FORTEMENT RECOMMANDÉ que les implémentations d'appareils prennent en charge la sortie des métadonnées MediaFormat#KEY_HDR10_PLUS_INFO pour les profils HDR10Plus via MediaCodec#getOutputFormat(int).

  • [C-3-2] Les implémentations d'appareils DOIVENT afficher correctement le contenu HDR pour le profil HEVCProfileMain10HDR10 sur l'écran de l'appareil ou sur un port de sortie vidéo standard (par exemple, HDMI).

  • [C-SR] Il est FORTEMENT RECOMMANDÉ que les implémentations d'appareils affichent correctement le contenu HDR pour le profil HEVCProfileMain10HDR10Plus sur l'écran de l'appareil ou sur un port de sortie vidéo standard (par exemple, HDMI).

5.3.6. VP8

Si les implémentations d'appareils sont compatibles avec le codec VP8, elles :

  • [C-1-1] DOIT être compatible avec 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 signalée par la méthode Display.getSupportedModes() est égale ou supérieure à la résolution vidéo :

  • [C-2-1] Les implémentations d'appareils DOIVENT être compatibles avec les profils 720p du tableau suivant.
  • [C-2-2] Les implémentations d'appareils DOIVENT être compatibles avec les profils 1080p du tableau suivant.
SD (qualité médiocre) 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 fpsTélévision) 30 (60 fpsTé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 d'appareils sont compatibles avec le codec VP9, elles :

  • [C-1-1] DOIT être compatible avec 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 d'appareils 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 signalée par la méthode Display.getSupportedModes() est supérieure ou égale à la résolution vidéo :

  • [C-3-1] Les implémentations d'appareils DOIVENT prendre en charge au moins le décodage VP9 ou H.265 des profils 720, 1080 et UHD.
SD (qualité médiocre) 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 fpsTélévision avec décodage matériel VP9) 60 FPS
Débit vidéo 600 Kbits/s 1,6 Mbit/s 4 Mbit/s 5 Mbit/s 20 Mbit/s

Si les implémentations d'appareils affirment être compatibles avec VP9Profile2 ou VP9Profile3 via les API multimédias CodecProfileLevel :

  • La prise en charge du format 12 bits est FACULTATIVE.

Si les implémentations d'appareils affirment prendre en charge un profil HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) via les API Media :

  • [C-4-1] Les implémentations d'appareils DOIVENT accepter les métadonnées HDR requises (MediaFormat#KEY_HDR_STATIC_INFO pour tous les profils HDR, ainsi que le paramètre MediaCodec#PARAMETER_KEY_HDR10_PLUS_INFO pour les profils HDR10Plus) à partir de l'application à l'aide de l'API MediaCodec, ainsi que prendre en charge l'extraction des métadonnées HDR requises (MediaFormat#KEY_HDR_STATIC_INFO pour tous les profils HDR, ainsi que MediaFormat#KEY_HDR10_PLUS_INFO pour les profils HDR10Plus) à partir du flux binaire et/ou du conteneur, comme défini par les spécifications concernées. Ils DOIVENT également être capables de générer les métadonnées HDR requises (MediaFormat#KEY_HDR_STATIC_INFO pour tous les profils HDR) à partir du flux binaire et/ou du conteneur, comme défini par les spécifications correspondantes.

  • [C-4-2] Les implémentations d'appareils DOIVENT afficher correctement le contenu HDR pour les profils VP9Profile2HDR et VP9Profile3HDR sur l'écran de l'appareil ou sur un port de sortie vidéo standard (par exemple, HDMI).

  • [C-SR] Il est FORTEMENT RECOMMANDÉ que les implémentations d'appareils prennent en charge la sortie des métadonnées MediaFormat#KEY_HDR10_PLUS_INFO pour les profils HDR10Plus via MediaCodec#getOutputFormat(int).

  • [C-SR] Il est FORTEMENT RECOMMANDÉ que les implémentations d'appareils affichent correctement le contenu HDR pour les profils VP9Profile2HDR10Plus et VP9Profile3HDR10Plus sur l'écran de l'appareil ou sur un port de sortie vidéo standard (par exemple, HDMI).

5.3.8. Dolby Vision

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

  • [C-1-1] DOIT fournir un extracteur compatible Dolby Vision.
  • [C-1-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).
  • [C-1-3] DOIT définir l'index de piste de la ou des couches de base rétrocompatibles (le cas échéant) sur la même valeur que l'index de piste de la couche Dolby Vision combinée.

5.3.9. AV1

Si les implémentations d'appareils sont compatibles avec le codec AV1, elles :

  • [C-1-1] DOIT être compatible avec le profil 0, y compris le contenu 10 bits.

5.4. Enregistrement audio

Bien que certaines des exigences décrites dans cette section soient listées comme "SHOULD" depuis Android 4.3, la définition de compatibilité pour les futures versions prévoit de les remplacer par "MUST". Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences listées comme "SHOULD" (DOIVENT), sinon ils ne pourront pas atteindre la compatibilité Android lorsqu'ils seront mis à niveau vers la future version.

5.4.1. Capture audio brute et informations sur le micro

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

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

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

  • DOIT autoriser la capture de contenu audio brut présentant les caractéristiques suivantes :

    • Format : PCM linéaire, 16 bits et 24 bits
    • Taux d'échantillonnage : 8 000, 11 025, 16 000, 22 050, 24 000, 32 000, 44 100, 48 000 Hz
    • Canaux : autant de canaux que de micros sur l'appareil

  • [C-1-2] DOIT capturer aux taux d'échantillonnage ci-dessus sans suréchantillonnage.

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

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

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

  • [C-1-4] DOIT respecter l'API MicrophoneInfo et renseigner correctement les informations concernant les microphones disponibles sur l'appareil et accessibles aux applications tierces via l'API AudioManager.getMicrophones(), ainsi que les microphones actuellement actifs et accessibles aux applications tierces via les API AudioRecord.getActiveMicrophones() et MediaRecorder.getActiveMicrophones(). Si les implémentations d'appareils permettent la capture de contenu audio brut en qualité radio AM et DVD, elles :

  • [C-2-1] DOIT capturer sans suréchantillonner à un rapport supérieur à 16000:22050 ou 44100:48000.

  • [C-2-2] DOIT inclure un filtre anti-aliasing approprié pour tout suréchantillonnage ou sous-échantillonnage.

5.4.2. Capture pour la reconnaissance vocale

Si les implémentations d'appareil 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 suivants : 44 100 et 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 tout contrôle automatique du gain 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 par rapport à la fréquence à peu près plates : plus précisément, ±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 produise une valeur efficace de 2 500 pour les échantillons de 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 changements de SPL d'entrée sur une plage d'au moins 30 dB, de -18 dB à +12 dB par rapport à 90 dB SPL au niveau du micro.
  • DOIT enregistrer le flux audio de reconnaissance vocale avec une distorsion harmonique totale (THD) inférieure à 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 android.hardware.microphone et des technologies de suppression (réduction) du bruit adaptées à 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] DOIT identifier de manière unique chaque implémentation de technologie de suppression du bruit à l'aide du champ AudioEffect.Descriptor.uuid.

5.4.3. Capture pour le reroutage de la lecture

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

Si les implémentations d'appareil déclarent 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 suivants :

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

5.4.4. Annulation de l'écho acoustique

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

  • DOIT implémenter une technologie d'annulation de l'écho acoustique (AEC, Acoustic Echo Canceler) adaptée à la communication vocale et appliquée au chemin de capture lors de la capture à l'aide de AudioSource.VOICE_COMMUNICATION

Si les implémentations d'appareils fournissent un annuleur d'écho acoustique inséré dans le chemin audio de capture lorsque AudioSource.VOICE_COMMUNICATION est sélectionné, elles :

5.4.5. Capture simultanée

Si les implémentations d'appareil déclarent android.hardware.microphone,elles DOIVENT implémenter la capture simultanée comme décrit dans ce document . Plus spécifiquement :

  • [C-1-1] DOIT autoriser l'accès simultané au micro par un service d'accessibilité capturant avec AudioSource.VOICE_RECOGNITION et au moins une application capturant avec n'importe quel AudioSource.
  • [C-1-2] DOIT autoriser l'accès simultané au micro par une application préinstallée qui détient un rôle d'Assistant et au moins une application qui capture avec n'importe quel AudioSource, à l'exception de AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER.
  • [C-1-3] DOIT couper le son capturé par toute autre application, à l'exception d'un service d'accessibilité, lorsqu'une application capture du son avec AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER. Toutefois, lorsqu'une application capture l'audio via AudioSource.VOICE_COMMUNICATION, une autre application peut capturer l'appel vocal s'il s'agit d'une application privilégiée (préinstallée) avec l'autorisation CAPTURE_AUDIO_OUTPUT.
  • [C-1-4] Si deux applications ou plus capturent du contenu simultanément et qu'aucune d'elles n'a d'interface utilisateur au premier plan, celle qui a commencé la capture le plus récemment reçoit l'audio.

5.4.6. Niveaux de gain du micro

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

  • 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 ±3 dB de 100 Hz à 4 000 Hz pour chacun des micros utilisés pour enregistrer la source audio de reconnaissance vocale.
  • DOIT définir la sensibilité de l'entrée audio de sorte qu'une source de tonalité sinusoïdale de 1 000 Hz lue à un niveau de pression acoustique (SPL) de 90 dB produise une réponse avec une valeur efficace de 2 500 pour les échantillons de 16 bits (ou -22,35 dB à pleine échelle pour les échantillons à virgule flottante/double précision) pour chacun des microphones utilisés pour enregistrer la source audio de reconnaissance vocale.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ que les niveaux d'amplitude se situent dans la plage de basses fréquences, plus précisément entre ±20 dB de 5 Hz à 100 Hz par rapport à la plage de moyennes fréquences pour chacun des microphones utilisés pour enregistrer la source audio de reconnaissance vocale.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ que les niveaux d'amplitude dans la plage de hautes fréquences soient de ±30 dB de 4 000 Hz à 22 kHz par rapport à la plage de moyennes fréquences pour chacun des microphones utilisés pour enregistrer la source audio de reconnaissance vocale.

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'appareil déclarent android.hardware.audio.output, elles :

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

    • Formats sources : PCM linéaire, 16 bits, 8 bits, float
    • 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, 48 000 pour les configurations de canaux listées ci-dessus
      • 96 000 en mono et en stéréo

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

    • Taux d'échantillonnage : 24 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 être compatible avec les implémentations EFFECT_TYPE_EQUALIZER et EFFECT_TYPE_LOUDNESS_ENHANCER contrôlables via les sous-classes AudioEffect Equalizer et LoudnessEnhancer.
  • [C-1-2] DOIT être compatible avec l'implémentation de l'API Visualizer, contrôlable via la classe Visualizer.
  • [C-1-3] DOIT être compatible avec l'implémentation EFFECT_TYPE_DYNAMICS_PROCESSING contrôlable via la sous-classe AudioEffect DynamicsProcessing.
  • DOIT être compatible avec les implémentations EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB et EFFECT_TYPE_VIRTUALIZER contrôlables par le biais des sous-classes AudioEffect BassBoost, EnvironmentalReverb, PresetReverb et Virtualizer.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge les effets en virgule flottante et multicanaux.

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 en utilisant le type de contenu ou l'utilisation tels que définis par AudioAttributes et l'utilisation audio de la voiture telle que définie publiquement dans android.car.CarAudioManager.

5.6. Latence audio

La latence audio correspond au délai entre le moment où un signal audio entre dans un système et celui où il en sort. De nombreuses classes d'applications s'appuient sur de faibles latences pour obtenir des effets sonores en temps réel.

Aux fins de la présente section, utilisez les définitions suivantes :

  • Latence de sortie : Intervalle entre le moment où une application écrit une trame de données codées PCM et le moment où le son correspondant est présenté à l'environnement au niveau d'un transducteur intégré ou le moment où le signal quitte l'appareil via un port et peut être observé en externe.
  • Latence de sortie à froid : Latence de sortie pour la première frame, lorsque le système de sortie audio est inactif et éteint avant la requête.
  • Latence de sortie continue Latence de sortie pour les frames suivants, une fois que l'appareil lit l'audio.
  • Latence d'entrée Intervalle entre le moment où un son est présenté par l'environnement à un transducteur sur l'appareil ou où un signal entre dans l'appareil via un port, et le moment où une application lit la trame de données codées PCM correspondante.
  • Entrée perdue Partie 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 est inactif et éteint avant la requête.
  • Latence d'entrée continue : Latence d'entrée pour les frames suivants, lorsque l'appareil enregistre l'audio.
  • Jitter de sortie à froid : Variabilité entre les différentes mesures des valeurs de latence de sortie à froid.
  • Gigue d'entrée à froid. Variabilité entre les différentes mesures 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 mise en mémoire tampon. Le délai tampon permet à l'application de traiter le signal et d'atténuer 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 d'API OpenSL ES liées à PCM dans Android NDK.
  • API audio native AAudio Ensemble d'API AAudio dans le NDK Android.
  • timestamp. 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é. Voir aussi AudioTimestamp.
  • glitch. Il s'agit d'une interruption temporaire ou d'une valeur d'échantillon incorrecte dans le signal audio, généralement causée par un manque de données dans le tampon pour la sortie, un dépassement de tampon pour l'entrée ou toute autre source de bruit numérique ou analogique.

Si les implémentations d'appareils déclarent android.hardware.audio.output, elles DOIVENT respecter ou dépasser les exigences suivantes :

  • [C-1-1] Le code temporel de sortie renvoyé par AudioTrack.getTimestamp et AAudioStream_getTimestamp est précis à +/- 2 ms.
  • [C-1-2] Latence de sortie à froid de 500 millisecondes ou moins.

Si les implémentations d'appareil déclarent android.hardware.audio.output, il est FORTEMENT RECOMMANDÉ qu'elles respectent ou dépassent les exigences suivantes :

  • [C-SR] Latence de sortie à froid de 100 millisecondes ou moins. Il est FORTEMENT RECOMMANDÉ aux appareils existants et nouveaux qui exécutent cette version d'Android de respecter ces exigences dès maintenant. Dans une prochaine version de la plate-forme en 2021, nous exigerons une latence de sortie à froid de 200 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 d'appareils répondent aux exigences ci-dessus, après toute calibration initiale, lorsqu'elles utilisent à la fois les API audio natives OpenSL ES PCM buffer queue et AAudio, pour la latence de sortie continue et la latence de sortie à froid sur au moins un périphérique de sortie audio compatible, elles sont :

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

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

Si les implémentations d'appareils incluent android.hardware.microphone, elles DOIVENT répondre aux exigences suivantes concernant l'entrée audio :

  • [C-3-1] Limitez l'erreur dans les codes temporels d'entrée, tels que renvoyés par AudioRecord.getTimestamp ou AAudioStream_getTimestamp, à +/- 2 ms. Ici, "erreur" désigne l'écart par rapport à la valeur correcte.
  • [C-3-2] Latence d'entrée à froid de 500 millisecondes ou moins.

Si les implémentations d'appareils incluent android.hardware.microphone, il est FORTEMENT RECOMMANDÉ qu'elles répondent aux exigences suivantes concernant l'entrée audio :

  • [C-SR] Latence d'entrée à froid de 100 millisecondes ou moins. Il est FORTEMENT RECOMMANDÉ aux appareils existants et nouveaux qui exécutent cette version d'Android de respecter ces exigences dès maintenant. Dans une prochaine version de la plate-forme en 2021, nous exigerons une latence d'entrée à froid de 200 ms ou moins.
  • [C-SR] Latence d'entrée continue de 30 millisecondes ou moins.
  • [C-SR] Latence aller-retour continue de 50 millisecondes ou moins.
  • [C-SR] Minimiser 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 spécifié dans la documentation du SDK Android.

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

  • [C-1-1] DOIT être compatible avec tous les codecs et formats de conteneur requis dans la section 5.1 sur HTTP(S).

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

  • [C-1-3] DOIT être compatible avec le profil audio/vidéo RTP et les codecs associés 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 des segments multimédias

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

Codecs audio :

  • AAC
 Pour en savoir plus sur AAC et ses variantes, consultez la section 5.1.1.
AAC avec trame ADTS et tags ID3 ISO 13818-7 Pour en savoir plus sur 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 H264 AVC, consultez la section 5.1.3.
MP4A-LATM RFC 6416 Pour en savoir plus sur AAC et ses variantes, consultez la section 5.1.1.
H263-1998 RFC 3551
RFC 4629
RFC 2190 		Pour en savoir plus sur H263, consultez la section 5.1.3.
H263-2000 RFC 4629 Pour en savoir plus sur H263, 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 MPEG-4 SP, consultez la section 5.1.3.
mpeg4-generic RFC 3640 Pour en savoir plus sur AAC et ses variantes, consultez la section 5.1.1.
MP2T RFC 2250 Pour en savoir plus, consultez Flux de transport MPEG-2 sous HTTP Live Streaming.

5.8. Secure Media

Si les implémentations d'appareils sont compatibles avec les sorties vidéo sécurisées 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'appareil déclarent la compatibilité avec Display.FLAG_SECURE et le protocole d'affichage sans fil, elles :

  • [C-2-1] DOIT sécuriser la liaison avec un mécanisme cryptographiquement robuste 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 la compatibilité avec Display.FLAG_SECURE et la compatibilité avec les écrans externes filaires, 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 par l'utilisateur.

5.9. Musical Instrument Digital Interface (MIDI)

Si les implémentations d'appareil signalent la compatibilité avec la fonctionnalité android.software.midi via la classe android.content.pm.PackageManager, elles :

  • [C-1-1] DOIT être compatible avec le protocole MIDI sur tous les transports matériels compatibles avec le protocole MIDI pour lesquels il fournit une connectivité générique non MIDI, lorsque ces transports sont :

  • [C-1-2] DOIT être compatible avec le transport logiciel MIDI entre applications (appareils MIDI virtuels)

  • [C-1-3] DOIT inclure libamidi.so (compatibilité MIDI native)

5.10. Audio professionnel

Si les implémentations d'appareil signalent la compatibilité avec la fonctionnalité android.hardware.audio.pro via la classe android.content.pm.PackageManager, elles :

  • [C-1-1] DOIT signaler la compatibilité avec la fonctionnalité android.hardware.audio.low_latency.
  • [C-1-2] DOIT avoir une latence audio aller-retour continue, telle que définie dans la section 5.6 sur la latence audio, de 20 millisecondes ou moins et DOIT être de 10 millisecondes ou moins sur au moins un chemin d'accès compatible.
  • [C-1-3] DOIT inclure un ou plusieurs ports USB prenant en charge le mode hôte USB et le mode périphérique USB.
  • [C-1-4] DOIT indiquer la compatibilité avec la fonctionnalité android.software.midi.
  • [C-1-5] DOIT respecter les exigences de latence et d'audio USB en utilisant à la fois l'API de file d'attente de tampon PCM OpenSL ES et au moins un chemin d'accès de l'API AAudio native audio.
  • [SR] Il est FORTEMENT RECOMMANDÉ de respecter les exigences de latence et d'audio USB en utilisant l'API AAudio native audio plutôt que le chemin MMAP.
  • [C-1-6] DOIT avoir une latence de sortie à froid de 200 millisecondes ou moins.
  • [C-1-7] La latence d'entrée à froid DOIT être inférieure ou égale à 200 millisecondes.
  • [SR] Il est FORTEMENT RECOMMANDÉ de fournir un niveau constant de performances du processeur lorsque l'audio est actif et que la charge du processeur varie. Ce test DOIT être effectué à l'aide de la version de l'application Android SynthMark avec l'ID de commit 09b13c6f49ea089f8c31e5d035f912cc405b7ab8. SynthMark utilise un synthétiseur logiciel exécuté sur un framework audio simulé qui mesure les performances du système. L'application SynthMark doit être exécutée à l'aide de l'option "Automated Test" (Test automatisé) et obtenir les résultats suivants :
    • voicemark.90 >= 32 voix
    • latencymark.fixed.little <= 15 ms
    • latencymark.dynamic.little <= 50 ms

Pour en savoir plus sur les benchmarks, consultez la documentation de SynthMark.

  • DOIT minimiser l'imprécision et la dérive de l'horloge audio par rapport à l'heure standard.
  • DOIT minimiser la dérive de l'horloge audio par rapport au CLOCK_MONOTONIC du processeur lorsque les deux sont actifs.
  • DOIT minimiser la latence audio sur les transducteurs de l'appareil.
  • DOIT minimiser la latence audio sur l'audio numérique USB.
  • SHOULD document audio latency measurements over all paths.
  • DOIT minimiser 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 CPU complète par le rappel.
  • DOIT fournir zéro problème audio en utilisation normale à la latence signalée.
  • DOIT fournir une différence de latence inter-canaux nulle.
  • DOIT minimiser la latence moyenne du MIDI sur tous les transports.
  • DOIT minimiser la variabilité de la latence MIDI sous charge (gigue) sur tous les transports.
  • DOIT fournir des codes temporels MIDI précis pour tous les transports.
  • DOIT minimiser le bruit du signal audio sur les transducteurs de l'appareil, y compris pendant la période qui suit immédiatement le démarrage à froid.
  • DOIT fournir une différence d'horloge audio nulle entre les côtés d'entrée et de sortie des points de terminaison correspondants, lorsque les deux sont actifs. Par exemple, le micro et le haut-parleur de l'appareil, ou l'entrée et la sortie de la prise audio.
  • DOIT gérer les rappels de fin de remplissage 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 la gestion des rappels sur le même thread n'est pas possible, saisissez le rappel de sortie peu après le rappel d'entrée pour permettre à l'application d'avoir un timing cohérent des 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 minimiser la latence tactile.
  • DOIT minimiser la variabilité de la latence tactile sous charge (instabilité).
  • La latence entre l'entrée tactile et la sortie audio DOIT être inférieure ou égale à 40 ms.

Si les implémentations d'appareils répondent à toutes les exigences ci-dessus, elles :

  • [SR] Il est FORTEMENT RECOMMANDÉ de signaler la compatibilité avec 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 un connecteur 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] DOIT avoir une latence audio aller-retour continue 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.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge les E/S simultanées jusqu'à huit canaux dans chaque sens, une fréquence d'échantillonnage de 96 kHz et une profondeur de 24 ou 32 bits, lorsqu'elles sont utilisées avec des périphériques audio USB qui prennent également en charge ces exigences.

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

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

5.11. Capture pour "Non traité"

Android permet d'enregistrer l'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 ont l'intention de prendre en charge la source audio brute et de la mettre à la disposition des applications tierces, elles :

  • [C-1-1] DOIT signaler 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-fréquence relativement plates dans la plage de fréquences moyennes, plus précisément ±10 dB de 100 Hz à 7 000 Hz pour chacun des micros utilisés pour enregistrer la source audio brute.

  • [C-1-3] DOIT présenter des niveaux d'amplitude dans la plage de basses fréquences, plus précisément de ±20 dB de 5 Hz à 100 Hz par rapport à la plage de moyennes fréquences pour chacun des micros utilisés pour enregistrer la source audio brute.

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

  • [C-1-5] La sensibilité de l'entrée audio DOIT être définie de sorte qu'une source de tonalité sinusoïdale de 1 000 Hz lue à un niveau de pression acoustique (SPL) de 94 dB produise une réponse avec une valeur efficace de 520 pour les échantillons de 16 bits (ou -36 dB à pleine échelle pour les échantillons à virgule flottante/double précision) pour chacun des microphones utilisés pour enregistrer la source audio brute.

  • [C-1-6] DOIT présenter un rapport signal/bruit (SNR) de 60 dB ou plus pour chacun des micros utilisés pour enregistrer la source audio brute. (alors que le SNR 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] DOIT présenter un taux de distorsion harmonique totale (THD) inférieur à 1 % pour 1 kHz à un niveau d'entrée de 90 dB SPL pour chacun des micros utilisés pour enregistrer la source audio brute.

  • NE DOIT PAS avoir d'autre traitement du signal (par exemple, contrôle automatique du gain, filtre passe-haut ou suppression de l'écho) dans le chemin, à l'exception d'un multiplicateur de niveau pour amener 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 n'introduire aucun retard ni 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 introduire de retard ni de latence dans le chemin du signal.

Toutes les mesures SPL sont effectuées directement à côté du microphone testé. Pour les configurations à plusieurs micros, 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] est TOUJOURS FORTEMENT RECOMMANDÉ pour répondre à autant d'exigences que possible concernant le chemin du signal pour la source d'enregistrement brute.

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

6.1. Outils pour les développeurs

Implémentations sur les appareils :

  • [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 être compatible avec 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 cmd stats
    • [C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge la commande shell cmd testharness.
    • [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 à l'aide de 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 démon adb côté appareil DOIT être inactif par défaut et il DOIT exister un mécanisme accessible à l'utilisateur pour activer Android Debug Bridge.
    • [C-0-5] DOIT être compatible avec adb sécurisé. Android est compatible avec adb sécurisé. Secure adb permet d'activer adb sur des hôtes authentifiés connus.

    • [C-0-6] DOIT fournir un mécanisme permettant de connecter adb à 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 telles que documentées dans le SDK Android. Étant donné que ddms utilise adb, la prise en charge de ddms DOIT être inactive par défaut, mais DOIT être disponible 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 il DOIT exister un mécanisme accessible à l'utilisateur pour l'activer.

  • Perfetto

    • [C-SR] Il est FORTEMENT RECOMMANDÉ d'exposer un binaire /system/bin/perfetto à l'utilisateur du shell dont la ligne de commande est conforme à la documentation Perfetto.
    • [C-SR] Il est FORTEMENT RECOMMANDÉ que le binaire perfetto accepte en entrée une configuration protobuf conforme au schéma défini dans la documentation perfetto.
    • [C-SR] Il est FORTEMENT RECOMMANDÉ que le binaire Perfetto écrive en sortie une trace protobuf conforme au schéma défini dans la documentation Perfetto.
    • [C-SR] Il est FORTEMENT RECOMMANDÉ de fournir, via le binaire perfetto, au moins les sources de données décrites dans la documentation perfetto.

  • Mode Atelier de test

    Si les implémentations d'appareils sont compatibles avec la commande shell cmd testharness et exécutent cmd testharness enable, elles :

Si les implémentations d'appareils indiquent la compatibilité avec Vulkan 1.0 ou une version ultérieure via les indicateurs de fonctionnalité android.hardware.vulkan.version, elles :

  • [C-1-1] DOIT fournir une affordance permettant au développeur d'application d'activer/de désactiver les couches de débogage GPU.
  • [C-1-2] DOIT, lorsque les couches de débogage GPU sont activées, énumérer les couches dans les bibliothèques fournies par des outils externes (c'est-à-dire ne faisant 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 les 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 :

  • [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 fois sur l'élément de menu Paramètres > À propos de l'appareil > Numéro de version.
  • [C-0-2] DOIT masquer les options pour les développeurs par défaut.
  • [C-0-3] DOIT fournir un mécanisme clair qui ne favorise pas une application tierce par rapport à une autre pour activer les options pour les développeurs. Vous DEVEZ fournir un document ou un site Web visible publiquement qui décrit comment activer les options pour les développeurs. Ce document ou ce site Web DOIT être accessible depuis les documents du SDK Android.
  • DOIT afficher 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 menacée.
  • PEUT limiter temporairement l'accès au menu "Options pour les développeurs", en le masquant visuellement ou en le désactivant, pour éviter toute distraction dans les scénarios où la sécurité de l'utilisateur est concernée.

7. Compatibilité matérielle

Si un appareil inclut un composant matériel spécifique qui dispose d'une API correspondante 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 possède pas ce composant :

  • [C-0-2] Les définitions de classe complètes (telles que documentées par le SDK) pour les API de composants DOIVENT toujours être présentées.
  • [C-0-3] Les comportements de l'API DOIVENT être implémentés de manière raisonnable en tant qu'opérations sans effet.
  • [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 no-op de classes lorsque 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 par la documentation du SDK.
  • [C-0-7] Les implémentations d'appareils DOIVENT signaler de manière cohérente des informations précises sur la configuration matérielle via les méthodes getSystemAvailableFeatures() et hasSystemFeature(String) de la classe android.content.pm.PackageManager pour la même empreinte numérique de compilation.

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

7.1. Écran et graphismes

Android inclut des fonctionnalités qui ajustent automatiquement les ressources et les mises en page de l'UI des applications de manière appropriée pour l'appareil, afin de garantir que les applications tierces fonctionnent correctement sur une variété de configurations matérielles. Sur les écrans compatibles avec Android sur lesquels toutes les applications tierces compatibles avec Android peuvent s'exécuter, les implémentations d'appareils DOIVENT implémenter correctement ces API et ces comportements, comme indiqué dans cette section.

Les unités auxquelles font référence les exigences de cette section sont définies comme suit :

  • taille diagonale physique. Distance en pouces entre deux angles opposés de la partie éclairée de l'écran.
  • points par pouce (ppp). Nombre de pixels inclus dans une étendue linéaire horizontale ou verticale de 2,54 cm. Lorsque des valeurs de dpi sont indiquées, les valeurs de dpi horizontal et vertical DOIVENT être comprises dans la plage.
  • format. Rapport entre les pixels de la dimension la plus longue et ceux de la dimension la plus courte de l'écran. Par exemple, un écran de 480 x 854 pixels correspond à un format de 854/480 = 1,779, soit environ 16:9.
  • Pixel indépendant de la densité (dp) Unité de pixel virtuel normalisée pour un écran de 160 dpi, 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 d'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 sur les appareils :

  • [C-0-1] MUST report the correct layout size for the Configuration.screenLayout as defined in the Android SDK documentation. Plus précisément, les implémentations d'appareils DOIVENT indiquer les dimensions d'écran logiques en pixels indépendants de la densité (dp) comme suit :

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

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

  • L'appareil PEUT être équipé d'un ou plusieurs écrans compatibles avec Android et dotés de coins arrondis.

Si les implémentations d'appareils sont compatibles avec UI_MODE_TYPE_NORMAL et incluent le ou les écrans compatibles avec Android dotés d'angles arrondis, elles :

  • [C-1-1] DOIT s'assurer que le rayon des angles arrondis est inférieur ou égal à 38 dp.
  • DOIT inclure une option permettant à l'utilisateur de passer au mode d'affichage avec des coins rectangulaires.
7.1.1.2. Format de l'écran

Bien qu'il n'y ait aucune restriction concernant le format de l'écran physique pour les écrans compatibles avec Android, le format de l'écran logique sur lequel les applications tierces sont affichées, qui peut être dérivé des valeurs de hauteur et de largeur signalées par les API view.Display et les API Configuration, DOIT répondre aux exigences suivantes :

  • [C-0-1] Les implémentations d'appareils avec Configuration.uiMode défini sur UI_MODE_TYPE_NORMAL DOIVENT avoir un format d'image inférieur ou égal à 1,86 (environ 16:9), sauf si l'application remplit l'une des conditions suivantes :

    • L'application a déclaré qu'elle était compatible avec un format d'écran plus grand grâce à la valeur de métadonnées android.max_aspect.
    • L'application déclare qu'elle est redimensionnable 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 avec Configuration.uiMode défini sur UI_MODE_TYPE_NORMAL DOIVENT avoir un format égal ou supérieur à 1,3333 (4:3), sauf si l'application peut être étirée en largeur en remplissant l'une des conditions suivantes :

  • [C-0-3] Les implémentations d'appareils avec Configuration.uiMode défini sur UI_MODE_TYPE_WATCH DOIVENT avoir un format défini 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 signaler une seule des densités du framework Android listées sur DisplayMetrics via l'API DENSITY_DEVICE_STABLE, et cette valeur NE DOIT JAMAIS changer. Toutefois, l'appareil PEUT signaler une densité arbitraire différente en fonction des modifications de configuration de l'écran effectuées par l'utilisateur (par exemple, la taille de l'écran) définies après le démarrage initial.

  • Les implémentations d'appareils DOIVENT définir la densité du framework Android standard qui est numériquement la plus proche de la densité physique de l'écran, sauf si cette densité logique réduit la taille de l'écran signalée en dessous de la taille minimale acceptée. Si la densité du framework Android standard qui est numériquement la plus proche de la densité physique entraîne une taille d'écran inférieure à la plus petite taille d'écran compatible acceptée (320 dp de largeur), les implémentations d'appareil DOIVENT indiquer la densité du framework Android standard immédiatement inférieure.

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

  • [C-1-1] La taille d'affichage NE DOIT PAS être mise à l'échelle à plus de 1,5 fois la densité native ni produire une dimension d'écran minimale effective inférieure à 320 dp (équivalente au qualificatif de ressource sw320dp), selon la première de ces conditions qui se produit.
  • [C-1-2] La taille de l'écran NE DOIT PAS être réduite à moins de 0,85 fois la densité native.
  • Pour garantir une bonne facilité d'utilisation et des tailles de police cohérentes, il est RECOMMANDÉ 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
  • Valeur par défaut : 1x (échelle d'affichage native)
  • Grand : x 1,15
  • Plus grand : x 1,3
  • Très grand : x 1,45

7.1.2. Métriques display

Si les implémentations d'appareils incluent le ou les écrans compatibles avec Android ou la sortie vidéo vers le ou les écrans compatibles avec Android, elles :

  • [C-1-1] DOIT signaler les valeurs correctes pour toutes les métriques d'affichage compatibles avec Android définies dans l'API android.util.DisplayMetrics.

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

  • [C-2-1] DOIT signaler les valeurs correctes de l'écran compatible avec Android, telles que définies dans l'API android.util.DisplayMetrics pour le view.Display par défaut émulé.

7.1.3. Orientation de l'écran

Implémentations sur les appareils :

  • [C-0-1] DOIT indiquer les orientations d'écran qu'il prend en charge (android.hardware.screen.portrait et/ou android.hardware.screen.landscape) et DOIT indiquer au moins une orientation prise en charge. Par exemple, un appareil avec un écran paysage à orientation fixe, comme un téléviseur ou un ordinateur portable, NE DOIT signaler que android.hardware.screen.landscape.
  • [C-0-2] DOIT signaler la valeur correcte de l'orientation actuelle de l'appareil, chaque fois qu'elle est demandée via android.content.res.Configuration.orientation, android.view.Display.getOrientation() ou d'autres API.

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

  • [C-1-1] DOIT être compatible avec l'orientation dynamique des applications en mode portrait ou paysage. Autrement dit, l'appareil DOIT respecter la demande d'orientation d'écran spécifique de l'application.
  • [C-1-2] NE DOIT PAS modifier la taille ou la densité de l'écran signalées lors du changement d'orientation.
  • Le fabricant MAY peut sélectionner l'orientation portrait ou paysage comme orientation par défaut.

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

7.1.4.1 OpenGL ES

Implémentations sur les appareils :

  • [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 natives correspondantes pour chaque version d'OpenGL ES qu'il a identifiée comme étant compatible.

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.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge OpenGL ES 3.1.
  • DOIT être compatible avec OpenGL ES 3.2.

Si les implémentations d'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 ne prend pas en charge.
  • [C-2-2] DOIT être compatible avec 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, EGL_ANDROID_recordable et EGL_ANDROID_GLES_layers.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge les extensions EGL_KHR_partial_update et OES_EGL_image_external.
  • DOIT signaler avec précision, via la méthode getString(), tout format de compression de texture qu'il prend en charge, qui est généralement spécifique au fournisseur.

Si les implémentations d'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.
  • [SR] : il est FORTEMENT RECOMMANDÉ de prendre en charge l'extension OES_EGL_image_external_essl3.

Si les implémentations d'appareils sont compatibles avec OpenGL ES 3.2, elles :

  • [C-4-1] DOIT être entièrement compatible avec le pack d'extensions Android OpenGL ES.

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

  • [C-5-1] DOIT identifier la prise en charge via le flag de fonctionnalité android.hardware.opengles.aep.

Si les implémentations d'appareil 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 permettant la création de graphiques 3D hautes performances.

Si les implémentations d'appareils sont compatibles avec OpenGL ES 3.1, elles :

  • [SR] Il est FORTEMENT RECOMMANDÉ d'inclure la compatibilité avec 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 d'appareils incluent la compatibilité avec Vulkan 1.0, elles :

  • [C-1-1] DOIT signaler 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 couches contenues dans les bibliothèques natives nommées libVkLayer*.so dans le répertoire des bibliothèques natives du package d'application, via les API natives Vulkan vkEnumerateInstanceLayerProperties() et vkEnumerateDeviceLayerProperties() .
  • [C-1-5] NE DOIT PAS énumérer les couches fournies par des bibliothèques en dehors du package d'application, ni fournir d'autres moyens de tracer 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.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge les extensions VK_KHR_driver_properties et VK_GOOGLE_display_timing.

Si les implémentations d'appareils ne sont pas compatibles avec Vulkan 1.0, elles :

  • [C-2-1] NE DOIT PAS déclarer de 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 d'appareils incluent la compatibilité avec Vulkan 1.1 et déclarent l'un des indicateurs de fonctionnalité Vulkan, elles :

  • [C-3-1] DOIT exposer la compatibilité avec les types de sémaphores et de handles externes SYNC_FD et 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 de fichier manifeste android:hardwareAccelerated ou d'appels d'API directs.

Implémentations sur les appareils :

  • [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 Android View.
  • [C-0-2] DOIT se comporter de manière cohérente avec 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 le matériel en tant que cibles de rendu dans une hiérarchie d'UI.

Implémentations sur les appareils :

  • [C-0-3] DOIT être compatible avec 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 affirment prendre en charge les écrans à large gamme de couleurs via Configuration.isScreenWideColorGamut() , elles :

  • [C-1-1] DOIT disposer d'un écran calibré en couleur.
  • [C-1-2] DOIT disposer d'un écran dont la gamme couvre entièrement la gamme de couleurs sRVB dans l'espace CIE 1931 xyY.
  • [C-1-3] DOIT disposer d'un écran dont la gamme a une superficie d'au moins 90 % de DCI-P3 dans l'espace CIE 1931 xyY.
  • [C-1-4] DOIT être compatible avec OpenGL ES 3.1 ou 3.2 et le signaler correctement.
  • [C-1-5] DOIT annoncer la compatibilité avec les 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, EGL_EXT_gl_colorspace_display_p3_linear et EGL_EXT_gl_colorspace_display_p3_passthrough.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ 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 100 % ou plus de l'espace sRGB dans l'espace CIE 1931 xyY, bien que la gamme de couleurs de l'écran ne soit pas définie.

7.1.5. Mode de compatibilité avec les anciennes applications

Android spécifie un "mode de compatibilité" dans lequel le framework fonctionne dans un mode de taille d'écran "normale" équivalente (largeur de 320 dp) au profit des anciennes applications non développées pour les anciennes versions d'Android antérieures à l'indépendance de la taille de l'écran.

7.1.6. Technologie d'écran

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

Tous les écrans compatibles avec Android d'une implémentation d'appareil :

  • [C-0-1] DOIT être capable d'afficher des graphiques en couleur 16 bits.
  • DOIT être compatible avec les écrans capables d'afficher des graphiques en couleur 24 bits.
  • [C-0-2] DOIT être capable d'afficher des animations.
  • [C-0-3] DOIT avoir un format de pixels (PAR) compris entre 0,9 et 1,15. Autrement dit, les proportions de pixels DOIVENT être presque carrées (1.0) avec une tolérance de 10 à 15 %.

7.1.7. Écrans secondaires

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

Si les implémentations d'appareils sont compatibles avec un écran externe via une connexion filaire, sans fil ou une connexion d'écran supplémentaire 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 sur les appareils :

7.2.1. Clavier

Si les implémentations d'appareils incluent la prise en charge des applications tierces d'éditeur de méthode de saisie (IME), elles :

Implémentations d'appareils : * [C-0-1] NE DOIVENT 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, la trackball et la molette comme mécanismes de navigation sans écran tactile.

Implémentations sur les appareils :

Si les implémentations d'appareils ne disposent pas de navigations non tactiles, elles :

  • [C-1-1] DOIT fournir un mécanisme d'interface utilisateur alternatif raisonnable pour la sélection et la modification de texte, compatible avec les moteurs de gestion des entrées. L'implémentation Android Open Source en amont inclut un mécanisme de sélection adapté aux appareils dépourvus de commandes de navigation non tactiles.

7.2.3. Touches de navigation

Les fonctions Accueil, Récents et Retour, généralement fournies par le biais d'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 TV. La fonction Accueil DOIT être le mécanisme permettant cette affordance utilisateur.
  • DOIT fournir des boutons pour les fonctions "Récents" et "Retour".

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

  • [C-1-1] DOIT être accessible en une seule action (par exemple, appuyer, double-cliquer ou faire un geste) lorsque l'un d'eux est accessible.
  • [C-1-2] DOIT indiquer clairement quelle action unique déclencherait chaque fonction. Par exemple, vous pouvez afficher une icône visible sur le bouton, une icône logicielle sur la partie barre de navigation de l'écran ou guider l'utilisateur à travers une démo pas à pas lors de la configuration initiale.

Implémentations sur les appareils :

  • [SR] Il est FORTEMENT RECOMMANDÉ de ne pas fournir de mécanisme de saisie pour la fonction de menu, car elle est obsolète au profit de la barre d'action depuis Android 4.0.

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

  • [C-2-1] DOIT afficher le bouton de menu d'actions supplémentaires chaque fois que le menu pop-up d'actions supplémentaires n'est pas vide et que la barre d'action est visible.
  • [C-2-2] NE DOIT PAS modifier la position du pop-up de menu d'actions affiché en sélectionnant le bouton de menu d'actions dans la barre d'actions, mais PEUT afficher le pop-up de menu d'actions à une position modifiée sur 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-SR] SONT FORTEMENT RECOMMANDÉES pour rendre la fonction Menu disponible pour les 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 d'appareils fournissent la fonctionnalité d'assistance, elles :

  • [C-4-1] La fonction d'assistance DOIT être accessible en une seule action (par exemple, un appui, un double-clic ou un geste) lorsque d'autres touches de navigation sont accessibles.
  • [SR] Il est FORTEMENT RECOMMANDÉ d'utiliser un appui prolongé sur la fonction ACCUEIL 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, non disponible pour les applications, et NE DOIVENT PAS masquer ni gêner la partie de l'écran disponible pour les applications.
  • [C-5-2] DOIT mettre à la disposition des applications une partie de l'écran qui répond 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 (c'est-à-dire la barre de navigation) soit correctement masquée, comme indiqué dans le SDK.

Si la fonction de navigation est fournie sous la forme d'une action gestuelle à l'écran :

  • [C-6-1] WindowInsets#getMandatorySystemGestureInsets() DOIT uniquement être utilisé pour signaler la zone de reconnaissance des gestes pour la maison.
  • [C-6-2] Les gestes qui commencent dans un rectangle d'exclusion fourni par l'application de premier plan via View#setSystemGestureExclusionRects(), mais en dehors de WindowInsets#getMandatorySystemGestureInsets(), NE DOIVENT PAS être interceptés pour la fonction de navigation tant que le rectangle d'exclusion est autorisé dans la limite d'exclusion maximale spécifiée dans la documentation pour View#setSystemGestureExclusionRects().
  • [C-6-3] DOIT envoyer un événement MotionEvent.ACTION_CANCEL à l'application de premier plan une fois que les événements tactiles commencent à être interceptés pour un geste système, si un événement MotionEvent.ACTION_DOWN a déjà été envoyé à l'application de premier plan.
  • [C-6-4] DOIT fournir une affordance utilisateur pour passer à une navigation à l'écran basée sur des boutons (par exemple, dans les paramètres).
  • DOIT fournir la fonction Accueil en balayant l'écran vers le haut depuis le bord inférieur de l'orientation actuelle de l'écran.
  • DOIT fournir la fonctionnalité "Récents" en effectuant un balayage vers le haut et en maintenant le doigt appuyé avant de le relâcher, à partir de la même zone que le geste "Accueil".
  • Les gestes qui commencent dans WindowInsets#getMandatorySystemGestureInsets() NE DOIVENT PAS être affectés par les rectangles d'exclusion fournis par l'application de premier plan via View#setSystemGestureExclusionRects().

Si une fonction de navigation est disponible depuis n'importe quel point des bords gauche et droit de l'orientation actuelle de l'écran :

  • [C-7-1] La fonction de navigation DOIT être "Retour" et doit être accessible en balayant l'écran de gauche à droite et de droite à gauche dans l'orientation actuelle de l'écran.
  • [C-7-2] Si des panneaux système personnalisés et balayables sont fournis sur les bords gauche ou droit, ils DOIVENT être placés dans le tiers supérieur de l'écran avec une indication visuelle claire et persistante indiquant que le fait de les faire glisser vers l'intérieur invoquerait les panneaux susmentionnés, et donc pas le bouton "Retour". Un panneau système PEUT être configuré par un utilisateur de sorte qu'il se trouve en dessous du tiers supérieur du ou des bords de l'écran, mais il NE DOIT PAS utiliser plus d'un tiers du ou des bords.
  • [C-7-3] Lorsque l'application au premier plan a défini les indicateurs View.SYSTEM_UI_FLAG_IMMERSIVE ou View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, le balayage depuis les bords DOIT se comporter comme implémenté dans AOSP, tel que décrit dans le SDK.
  • [C-7-4] Lorsque l'application au premier plan a défini les indicateurs View.SYSTEM_UI_FLAG_IMMERSIVE ou View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, les panneaux système personnalisés pouvant être balayés DOIVENT être masqués jusqu'à ce que l'utilisateur affiche les barres système (c'est-à-dire la barre de navigation et la barre d'état) telles qu'implémentées dans AOSP.

7.2.4. Saisie sur écran tactile

Android est compatible avec différents systèmes de saisie au 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 a l'impression de manipuler directement les éléments à l'écran. Étant donné que l'utilisateur touche directement l'écran, le système ne nécessite aucune autre affordance pour indiquer les objets manipulés.

Implémentations sur les appareils :

  • DOIT disposer d'un système de saisie au pointeur (de type 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 (simple ou multipoint), elles :

  • [C-1-1] DOIT signaler 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 pouvant suivre plusieurs contacts, elles :

  • [C-2-1] DOIT signaler 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 reposent uniquement sur un dispositif de pointage) et répondent aux exigences de faux toucher de la section 7.2.5, elles :

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

7.2.5. Fausse saisie tactile

Une interface tactile simulée fournit un système de saisie utilisateur qui se rapproche d'un sous-ensemble des fonctionnalités d'un écran tactile. Par exemple, une souris ou une télécommande qui oriente un curseur à l'écran se rapproche du toucher, mais nécessite que l'utilisateur pointe ou sélectionne d'abord, puis clique. De nombreux périphériques d'entrée tels que la souris, le pavé tactile, la souris aérienne gyroscopique, le pointeur gyroscopique, 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 une entrée tactile (y compris la prise en charge des gestes de base) et indique que l'appareil prend en charge un sous-ensemble émulé de fonctionnalités d'écran tactile.

Si les implémentations d'appareils n'incluent pas d'écran tactile, mais incluent un autre système de saisie au pointeur qu'elles souhaitent rendre disponible, elles doivent :

  • DOIT déclarer la compatibilité avec le flag de fonctionnalité android.hardware.faketouch.

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

  • [C-1-1] DOIT signaler les positions absolues X et Y 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 remonte sur l'écran.
  • [C-1-3] DOIT prendre en charge les événements de 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 événements pointer down, pointer up, pointer down puis pointer up au même endroit sur un objet à l'écran dans un délai donné, ce qui permet aux utilisateurs d'émuler un double-tap 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 glisser tactile.
  • [C-1-6] DOIT permettre aux utilisateurs de déplacer rapidement un objet vers une autre position sur l'écran, puis de le faire glisser sur l'écran.
  • [C-1-7] DOIT signaler TOUCHSCREEN_NOTOUCH pour le champ d'API Configuration.touchscreen.

Si les implémentations d'appareil 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'appareil 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 permettre le suivi distinct d'au moins cinq 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'appareil 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 séparé dans la boîte, qui permettrait 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 à ses constantes view.InputEvent Android associées, comme indiqué dans les tableaux ci-dessous. L'implémentation Android en amont inclut l'implémentation pour les manettes de jeu qui répond à cette exigence.
Bouton Utilisation 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)
Haut du pavé directionnel1
Bas du pavé directionnel1 		0x01 0x00393 AXIS_HAT_Y4
Flèche vers la gauche du pavé directionnel1
Flèche vers la droite du pavé directionnel1 		0x01 0x00393 AXIS_HAT_X4
Bouton supérieur gauche1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
Bouton supérieur droit1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
Clic sur le stick gauche1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
Clic sur le joystick 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 CA de manette de jeu (0x01 0x0005).

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

4 MotionEvent

Commandes analogiques1 Utilisation HID Bouton Android
Bouton de déclenchement gauche 0x02 0x00C5 AXIS_LTRIGGER
Bouton de tranche droit 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

Consultez la section 2.3.1 pour connaître les exigences spécifiques aux appareils.

7.3. Capteurs

Si les implémentations d'appareils incluent un type de capteur particulier qui dispose d'une API correspondante pour les développeurs tiers, l'implémentation de l'appareil DOIT implémenter cette API comme décrit dans la documentation du SDK Android et la documentation Android Open Source sur les capteurs.

Implémentations sur les appareils :

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

Si les implémentations d'appareils incluent un type de capteur particulier qui dispose d'une API correspondante pour les développeurs tiers, elles :

  • [C-1-1] DOIT signaler toutes les mesures des capteurs en utilisant les valeurs du Système international d'unités (métriques) appropriées pour chaque type de capteur, telles que définies 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 flux de capteurs avec une latence maximale demandée de 0 ms 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 de capteur dans les 400 millisecondes + 2 * sample_time de l'activation du capteur. Il est acceptable que cet échantillon ait une précision de 0.

  • [SR] DOIT signaler l'heure de l'événement en nanosecondes, comme défini dans la documentation du SDK Android, qui représente l'heure à laquelle l'événement s'est produit et qui est synchronisée avec l'horloge SystemClock.elapsedRealtimeNano(). Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin de pouvoir passer aux futures versions de la plate-forme, où cela pourrait devenir un composant 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 qui DOIVENT avoir une gigue inférieure à 3 %, où la gigue est définie comme l'écart-type de la différence des valeurs d'horodatage signalées entre les événements consécutifs.

  • [C-1-5] DOIT s'assurer que le flux d'événements du capteur NE DOIT PAS empêcher le processeur de l'appareil de passer en état de veille ou de sortir de l'état de veille.

  • Lorsque plusieurs capteurs sont activés, la consommation d'énergie NE DOIT PAS dépasser la somme des consommations d'énergie individuelles des capteurs.

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 sur les appareils :

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

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

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

7.3.1. Accéléromètre

Implémentations sur les appareils :

  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un accéléromètre 3 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 à une fréquence d'au moins 50 Hz.
  • [C-1-2] DOIT implémenter et signaler le capteur TYPE_ACCELEROMETER.
  • [C-1-3] DOIT être conforme au 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] DOIT avoir une résolution d'au moins 12 bits.
  • [C-1-6] DOIT avoir un écart-type ne dépassant pas 0,05 m/s^2, où l'écart-type DOIT être calculé par axe sur des échantillons collectés sur une période d'au moins 3 secondes à la fréquence d'échantillonnage la plus rapide.
  • [SR] : il est FORTEMENT RECOMMANDÉ d'implémenter le capteur composite TYPE_SIGNIFICANT_MOTION.
  • Nous RECOMMANDONS VIVEMENT aux [SR] d'implémenter le capteur TYPE_ACCELEROMETER_UNCALIBRATED et de générer des rapports à son sujet. Nous RECOMMANDONS FORTEMENT d'utiliser des appareils Android pour répondre à cette exigence, car il est possible qu'elle devienne OBLIGATOIRE dans les futures versions de la plate-forme.
  • DOIT implémenter les capteurs composites TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR et TYPE_STEP_COUNTER, comme décrit dans la documentation 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 compensé, et conserver les paramètres de compensation entre les redémarrages de l'appareil.
  • DOIT être compensé en température.

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 une condition dynamique ou statique.

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

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

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

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

7.3.2. Magnétomètre

Implémentations sur les appareils :

  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un magnétomètre 3 axes (boussole).

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

  • [C-1-1] DOIT implémenter le capteur TYPE_MAGNETIC_FIELD.
  • [C-1-2] DOIT être capable de signaler des événements jusqu'à une fréquence d'au moins 10 Hz et DEVRAIT signaler des événements jusqu'à au moins 50 Hz.
  • [C-1-3] DOIT être conforme au 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 saturation.
  • [C-1-5] DOIT avoir une valeur de décalage ferreux inférieure à 700 µT et DOIT avoir une valeur inférieure à 200 µT en plaçant le magnétomètre loin des champs magnétiques dynamiques (induits par le courant) et statiques (induits par l'aimant).
  • [C-1-6] DOIT avoir une résolution égale ou supérieure à 0,6 µT.
  • [C-1-7] DOIT prendre en charge la calibration et la compensation en ligne du biais de fer doux, 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. La calibration peut être effectuée pendant l'utilisation ou lors de la production de l'appareil.
  • [C-1-9] DOIT avoir un écart-type, calculé par axe sur des échantillons collectés sur une période d'au moins 3 secondes à la fréquence d'échantillonnage la plus rapide, qui ne doit pas dépasser 1,5 µT ; DOIT avoir un écart-type qui ne doit pas dépasser 0,5 µT.
  • DOIT implémenter le capteur TYPE_MAGNETIC_FIELD_UNCALIBRATED.
  • [SR] Il est FORTEMENT RECOMMANDÉ aux appareils Android existants et nouveaux d'implémenter le capteur TYPE_MAGNETIC_FIELD_UNCALIBRATED.

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

  • [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 sur les appareils :

  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'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 l'indicateur de fonctionnalité android.hardware.location.gps, elles :

  • [C-1-1] DOIT prendre en charge les sorties de localisation à un taux 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 dans des conditions de ciel dégagé (signaux forts, multitrajet négligeable, HDOP < 2) en 10 secondes (temps rapide pour la première correction), lorsqu'il est connecté à une connexion Internet d'une vitesse de 0,5 Mbit/s ou supérieure. Pour ce faire, il est généralement nécessaire d'utiliser une technique de localisation GPS/GNSS assistée ou par prédiction afin de réduire le temps de verrouillage du GPS/GNSS (les données d'assistance incluent l'heure de référence, la position de référence et l'éphéméride/horloge du satellite) ;
    • [C-1-6] Après avoir effectué un tel calcul de localisation, les implémentations d'appareils DOIVENT déterminer leur position en ciel dégagé dans un délai de cinq secondes, lorsque les requêtes de localisation sont redémarrées, jusqu'à une heure après le calcul initial de la position, même lorsque la requête suivante est effectuée sans connexion de données et/ou après arrêt et redémarrage.

  • En conditions de ciel dégagé après avoir déterminé la position, à l'arrêt ou en mouvement avec une accélération inférieure à 1 mètre par seconde au carré :

    • [C-1-3] DOIT être en mesure de déterminer la position à 20 mètres près et la vitesse à 0,5 mètre par seconde près, et ce, au moins 95 % du temps.
    • [C-1-4] DOIT suivre et signaler simultanément via GnssStatus.Callback au moins huit satellites d'une même constellation.
    • DOIT être capable de suivre simultanément au moins 24 satellites de plusieurs constellations (par exemple, GPS + au moins l'une des constellations Glonass, Beidou ou Galileo).
    • [C-SR] Il est FORTEMENT RECOMMANDÉ aux SR de continuer à fournir des données de localisation GPS/GNSS normales via les API GNSS Location Provider lors d'un appel téléphonique d'urgence.
    • [C-SR] Il est FORTEMENT RECOMMANDÉ de signaler les mesures GNSS de toutes les constellations suivies (comme indiqué dans les messages GnssStatus), à l'exception de SBAS.
    • [C-SR] Il est FORTEMENT RECOMMANDÉ d'indiquer l'AGC et la fréquence de mesure GNSS.
    • [C-SR] Il est FORTEMENT RECOMMANDÉ de signaler toutes les estimations de précision (y compris le cap, la vitesse et la précision verticale) pour chaque position GPS/GNSS.
    • [C-SR] Il est FORTEMENT RECOMMANDÉ de signaler les mesures GNSS dès qu'elles sont trouvées, même si aucune position calculée à partir du GPS/GNSS n'est encore signalée.
    • [C-SR] Il est FORTEMENT RECOMMANDÉ que les STR signalent les pseudo-distances et les taux de pseudo-distance GNSS qui, dans des conditions de ciel dégagé après avoir déterminé la position, lorsqu'ils sont à l'arrêt ou se déplacent avec une accélération inférieure à 0, 2 mètre par seconde au carré, sont suffisants pour calculer la position à 20 mètres près et la vitesse à 0, 2 mètre par seconde près, au moins 95 % du temps.

7.3.4. Gyroscope

Implémentations sur les appareils :

  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un capteur gyroscopique, sauf si un accéléromètre à trois axes est également inclus.

Si les implémentations d'appareils incluent un gyroscope à trois axes, elles doivent :

  • [C-1-1] DOIT pouvoir signaler des événements à une fréquence d'au moins 50 Hz.
  • [C-1-2] DOIT implémenter le capteur TYPE_GYROSCOPE et est FORTEMENT RECOMMANDÉ d'implémenter également le capteur TYPE_GYROSCOPE_UNCALIBRATED.
  • [C-1-4] DOIT avoir une résolution d'au moins 12 bits et DOIT AVOIR une résolution d'au moins 16 bits.
  • [C-1-5] DOIT être compensé en température.
  • [C-1-6] DOIT être calibré et compensé pendant l'utilisation, et conserver les paramètres de compensation entre les redémarrages de l'appareil.
  • [C-1-7] La variance ne DOIT PAS être supérieure à 1e-7 rad^2 / s^2 par Hz (variance par Hz, ou rad^2 / s). La variance peut varier en fonction du taux d'échantillonnage, mais DOIT être limitée par cette valeur. En d'autres termes, si vous mesurez la variance du gyroscope à une fréquence d'échantillonnage de 1 Hz, elle NE DOIT PAS être supérieure à 1e-7 rad^2/s^2.
  • [SR] Il est FORTEMENT RECOMMANDÉ que l'erreur de calibration soit inférieure à 0,01 rad/s lorsque l'appareil est immobile à température ambiante.
  • DOIT signaler les événements jusqu'à au moins 200 Hz.

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

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

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

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

7.3.5. Le baromètre

Implémentations sur les appareils :

  • Il est FORTEMENT RECOMMANDÉ d'inclure un baromètre (capteur de pression atmosphérique) dans les [C-SR].

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

  • [C-1-1] DOIT implémenter et signaler le capteur TYPE_PRESSURE.
  • [C-1-2] DOIT être capable de fournir des événements à 5 Hz ou plus.
  • [C-1-3] DOIT être compensé en température.
  • [SR] FORTEMENT RECOMMANDÉ pour pouvoir signaler les mesures de pression dans la plage de 300 hPa à 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 (ce qui équivaut à 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 sur les appareils :

  • PEUT inclure un thermomètre ambiant (capteur de température).
  • PEUT inclure un capteur de température du processeur, mais NE DOIT PAS le faire.

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

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

Notez que le type de capteur SENSOR_TYPE_TEMPERATURE est obsolète 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'appareil 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é de manière à 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 un bit.

7.3.9. Capteurs haute fidélité

Si les implémentations d'appareils incluent un ensemble de capteurs de qualité supérieure, tels que définis dans cette section, et les mettent à la disposition des applications tierces, elles :

  • [C-1-1] DOIT identifier la fonctionnalité à l'aide du flag de fonctionnalité android.hardware.sensor.hifi_sensors.

Si les implémentations d'appareil déclarent android.hardware.sensor.hifi_sensors, elles :

  • [C-2-1] DOIT disposer d'un capteur TYPE_ACCELEROMETER qui :

    • DOIT avoir une plage de mesure d'au moins -8 g et +8 g, DOIT avoir une plage de mesure d'au moins -16 g et +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 être compatible avec SensorDirectChannel RATE_VERY_FAST.
    • DOIT présenter un bruit de mesure ne dépassant pas 400 μg/√Hz.
    • DOIT implémenter une forme non wake-up de ce capteur avec une capacité de mise en mémoire tampon d'au moins 3 000 événements de capteur.
    • DOIT avoir une consommation d'énergie par lot ne dépassant pas 3 mW.
    • [C-SR] Il est FORTEMENT RECOMMANDÉ que la bande passante de mesure à 3 dB soit d'au moins 80 % de la fréquence de Nyquist, et que le spectre du bruit blanc se trouve dans cette bande passante.
    • DOIT avoir une marche aléatoire d'accélération inférieure à 30 μg √Hz testée à température ambiante.
    • DOIT présenter une variation du biais en fonction de la température ≤ +/- 1 mg/°C.
    • DOIT avoir une non-linéarité de la ligne de régression ≤ 0,5 % et une variation de la sensibilité en fonction de la température ≤ 0,03 %/°C.
    • DOIT avoir une sensibilité à l'axe transversal inférieure à 2,5 % et une variation de la sensibilité à l'axe transversal inférieure à 0,2 % dans la plage de températures 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 disposer d'un capteur TYPE_GYROSCOPE qui :

    • DOIT avoir une plage de mesure comprise entre -1 000 et +1 000 dps au minimum.
    • 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 être compatible avec SensorDirectChannel RATE_VERY_FAST.
    • DOIT avoir un bruit de mesure ne dépassant pas 0,014°/s/√Hz.
    • [C-SR] Il est FORTEMENT RECOMMANDÉ que la bande passante de mesure à 3 dB soit d'au moins 80 % de la fréquence de Nyquist, et que le spectre du bruit blanc se trouve dans cette bande passante.
    • DOIT avoir une marche aléatoire de taux inférieure à 0,001 °/s √Hz testée à température ambiante.
    • La variation du biais par rapport à la température DOIT être inférieure ou égale à +/- 0,05 °/ s / °C.
    • DOIT présenter une variation de sensibilité en fonction de la température ≤ 0,02 % / °C.
    • DOIT avoir une non-linéarité de la droite d'ajustement optimal ≤ 0,2 %.
    • DOIT avoir une densité de bruit ≤ 0,007 °/s/√Hz.
    • DOIT présenter une erreur de calibration inférieure à 0,002 rad/s dans la plage de température de 10 à 40 °C lorsque l'appareil est immobile.
    • DOIT avoir une sensibilité g inférieure à 0,1°/s/g.
    • DOIT avoir une sensibilité à l'axe transversal inférieure à 4,0 % et une variation de sensibilité à l'axe transversal 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 disposer d'un capteur TYPE_GEOMAGNETIC_FIELD qui :

    • DOIT avoir une plage de mesure comprise entre 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.
    • DOIT avoir un bruit de mesure ne dépassant pas 0,5 uT.

  • [C-2-6] DOIT comporter un TYPE_MAGNETIC_FIELD_UNCALIBRATED avec les mêmes exigences de qualité que TYPE_GEOMAGNETIC_FIELD et, en plus :

    • DOIT implémenter une forme non-wake-up 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É que le spectre du bruit blanc soit 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 disposer d'un capteur TYPE_PRESSURE qui :

    • DOIT avoir une plage de mesure comprise entre 300 et 1 100 hPa au minimum.
    • 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.
    • DOIT avoir un bruit de mesure ne dépassant pas 2 Pa/√Hz.
    • DOIT implémenter une forme non-wake-up de ce capteur avec une capacité de mise en mémoire tampon d'au moins 300 événements de capteur.
    • La consommation d'énergie par lot ne doit pas dépasser 2 mW.
  • [C-2-8] DOIT disposer d'un capteur TYPE_GAME_ROTATION_VECTOR.
  • [C-2-9] DOIT disposer d'un capteur TYPE_SIGNIFICANT_MOTION qui :
    • DOIT avoir une consommation d'énergie inférieure ou égale à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsqu'il est en mouvement.
  • [C-2-10] DOIT disposer d'un capteur TYPE_STEP_DETECTOR qui :
    • DOIT implémenter une forme non wake-up 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 ou égale à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsqu'il est en mouvement.
    • DOIT avoir une consommation d'énergie par lot ne dépassant pas 4 mW.
  • [C-2-11] DOIT disposer d'un capteur TYPE_STEP_COUNTER qui :
    • DOIT avoir une consommation d'énergie inférieure ou égale à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsqu'il est en mouvement.
  • [C-2-12] DOIT disposer d'un capteur TILT_DETECTOR qui :
    • DOIT avoir une consommation d'énergie inférieure ou égale à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsqu'il est en mouvement.
  • [C-2-13] L'horodatage du même événement physique signalé par l'accéléromètre, le gyroscope et le magnétomètre DOIT être à moins de 2, 5 millisecondes les uns des autres. L'horodatage de l'événement physique identique signalé par l'accéléromètre et le gyroscope DOIT être à moins de 0,25 milliseconde l'un de l'autre.
  • [C-2-14] Les codes temporels des événements du capteur gyroscopique DOIVENT être sur la même base temporelle que le sous-système de caméras et présenter une marge d'erreur de 1 milliseconde.
  • [C-2-15] DOIT fournir des échantillons aux applications dans un délai de cinq millisecondes à compter du moment où les données sont disponibles sur l'un des capteurs physiques ci-dessus.
  • [C-2-16] NE DOIT PAS avoir une consommation d'énergie supérieure à 0,5 mW lorsque l'appareil est statique et à 2,0 mW lorsqu'il est en mouvement lorsque l'une des combinaisons de capteurs suivantes est activée :
    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS
  • [C-2-17] PEUT disposer d'un capteur TYPE_PROXIMITY, mais s'il est présent, 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. Elle inclut la puissance absorbée par l'ensemble de la chaîne de capteurs (capteur, circuits auxiliaires, système de traitement des capteurs 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 compatibilité avec les types de canaux directs et le niveau de taux de signalement direct via les API isDirectChannelTypeSupported et getHighestDirectReportRateLevel.
  • [C-3-2] DOIT être compatible avec au moins l'un des deux types de canaux directs de capteur pour tous les capteurs qui déclarent être compatibles avec le canal direct de capteur.
  • DOIT être compatible avec le signalement d'événements via le canal direct du capteur pour le capteur principal (variante non-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

Pour en savoir plus sur la mesure de la sécurité du déverrouillage biométrique, consultez la documentation sur la mesure de la sécurité biométrique.

Si les implémentations d'appareils incluent un écran de verrouillage sécurisé, elles :

  • DOIT inclure un capteur biométrique

Les capteurs biométriques peuvent être classés comme forts, faibles ou pratiques en fonction de leurs taux d'acceptation des usurpations et des imposteurs, ainsi que de la sécurité du pipeline biométrique. Cette classification détermine les capacités du capteur biométrique à interagir avec la plate-forme et les applications tierces. Par défaut, les capteurs sont classés comme pratiques. Ils doivent répondre à des exigences supplémentaires, détaillées ci-dessous, s'ils souhaitent être classés comme faibles ou forts. Les authentifications biométriques faibles et fortes bénéficient de fonctionnalités supplémentaires, comme indiqué ci-dessous.

Pour rendre un capteur biométrique disponible pour les applications tierces, les implémentations d'appareils doivent :

  • [C-0-1] DOIT répondre aux exigences biométriques fortes ou faibles définies dans ce document.

Pour autoriser l'accès aux clés du Keystore aux applications tierces et aux implémentations d'appareils :

  • [C-0-2] DOIT répondre aux exigences de la catégorie Élevé, telles que définies dans le présent document.

De plus :

  • [C-0-3] DOIT être associée à une action de confirmation explicite (par exemple, un appui sur un bouton) si cette biométrie forte est passive (par exemple, le visage ou l'iris, où il n'existe aucun signal explicite de l'intention de l'utilisateur).
    • [C-SR] Il est FORTEMENT RECOMMANDÉ de sécuriser l'action de confirmation pour la biométrie passive de sorte qu'une compromission du système d'exploitation ou du noyau 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 d'entrée/sortie à usage général (GPIO) en entrée uniquement d'un élément sécurisé (SE) qui ne peut être déclenchée que par l'appui sur un bouton physique.

Si les implémentations d'appareils souhaitent traiter un capteur biométrique comme Convenience, elles doivent :

  • [C-1-1] DOIT avoir un taux de fausse acceptation inférieur à 0,002 %.
  • [C-1-2] Si les taux d'acceptation de l'usurpation d'identité et de l'imposture sont supérieurs à 7 %, le fabricant 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 liés à son activation.
  • [C-1-3] DOIT limiter le nombre de tentatives pendant au moins 30 secondes après cinq tentatives infructueuses de vérification biométrique (une tentative infructueuse étant une tentative avec une qualité de capture adéquate (BIOMETRIC_ACQUIRED_GOOD) qui ne correspond pas à une empreinte biométrique enregistrée).
  • [C-1-4] DOIT empêcher l'ajout de nouvelles données biométriques sans avoir d'abord établi une chaîne de confiance en demandant à l'utilisateur de confirmer les identifiants d'appareil existants ou d'en ajouter de nouveaux (code/schéma/mot de passe) sécurisés par TEE. L'implémentation Android Open Source Project fournit le mécanisme nécessaire dans le framework.
  • [C-1-5] DOIT supprimer complètement toutes les données biométriques identifiables d'un utilisateur lorsque son compte est supprimé (y compris par le biais d'une réinitialisation des paramètres d'usine).
  • [C-1-6] MUST honor the individual flag for that biometric (i.e. DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE , or DevicePolicymanager.KEYGUARD_DISABLE_IRIS ).
  • [C-1-7] DOIT demander à l'utilisateur de s'authentifier avec la méthode principale recommandée (par exemple, code, schéma ou mot de passe) au moins une fois toutes les 24 heures pour les nouveaux appareils lancés avec Android 10, et au moins une fois toutes les 72 heures pour les appareils mis à niveau à partir d'une version antérieure d'Android.

  • [C-1-8] DOIT demander à l'utilisateur de s'authentifier à l'aide de la méthode d'authentification principale recommandée (par exemple, code, schéma ou mot de passe) dans l'un des cas suivants :

    • Un délai d'inactivité de quatre heures, OU
    • Trois tentatives d'authentification biométrique ont échoué.
    • La période de délai d'inactivité et le nombre d'échecs d'authentification sont réinitialisés après toute confirmation réussie des identifiants de l'appareil.

    La mise à niveau des appareils à partir d'une version antérieure d'Android peut être exemptée de la section C-1-8.

  • [C-SR] Il est FORTEMENT RECOMMANDÉ que les STR aient un taux de faux rejets inférieur à 10 %, tel que mesuré sur l'appareil.

  • [C-SR] Il est FORTEMENT RECOMMANDÉ que la latence soit inférieure à une seconde, mesurée à partir du moment où l'élément biométrique est détecté jusqu'au déverrouillage de l'écran, pour chaque élément biométrique enregistré.

Si les implémentations d'appareils souhaitent traiter un capteur biométrique comme faible, elles doivent :

  • [C-2-1] DOIT répondre à toutes les exigences de la catégorie Praticité ci-dessus, à l'exception de [C-1-2].
  • [C-2-2] DOIT avoir un taux d'acceptation des usurpations d'identité et des impostures ne dépassant pas 20 %.
  • [C-2-3] DOIT disposer d'une implémentation de Keystore soutenue par du matériel et effectuer la correspondance biométrique dans un environnement d'exécution isolé en dehors de l'espace utilisateur ou du noyau Android, tel que l'environnement d'exécution sécurisé (TEE) ou sur une puce avec un canal sécurisé vers l'environnement d'exécution isolé.
  • [C-2-4] DOIT avoir toutes les données identifiables chiffrées et authentifiées de manière cryptographique afin qu'elles ne puissent pas être acquises, lues ou modifiées en dehors de l'environnement d'exécution isolé ou d'une puce avec un canal sécurisé vers l'environnement d'exécution isolé, comme indiqué dans les consignes d'implémentation sur le site Android Open Source Project.
  • [C-2-5] Lors de l'authentification ou de l'enregistrement biométriques basés sur une caméra :
    • DOIT faire fonctionner la caméra dans un mode qui empêche la lecture ou la modification des images de la caméra en dehors de l'environnement d'exécution isolé ou d'une puce avec un canal sécurisé vers l'environnement d'exécution isolé.
    • Pour les solutions RVB à une seule caméra, les frames de la caméra PEUVENT être lisibles en dehors de l'environnement d'exécution isolé pour prendre en charge des opérations telles que l'aperçu pour l'enregistrement, mais NE DOIVENT TOUJOURS PAS être modifiables.
  • [C-2-6] NE DOIT PAS permettre aux applications tierces de faire la distinction entre les inscriptions biométriques individuelles.
  • [C-2-7] NE DOIT PAS autoriser l'accès non chiffré aux données biométriques identifiables ni aux données qui en sont dérivées (telles que les embeddings) au processeur d'applications en dehors du contexte de l'environnement d'exécution sécurisé.

  • [C-2-8] DOIT disposer d'un pipeline de traitement sécurisé de sorte qu'une compromission du système d'exploitation ou du noyau ne puisse pas permettre d'injecter directement des données pour s'authentifier de manière frauduleuse en tant qu'utilisateur.

    Si les implémentations d'appareils sont déjà lancées sur une version antérieure d'Android et ne peuvent pas répondre à l'exigence C-2-8 par le biais d'une mise à jour du logiciel système, elles PEUVENT être exemptées de l'exigence.

Si les implémentations d'appareils souhaitent traiter un capteur biométrique comme Strong, elles doivent :

  • [C-3-1] DOIT répondre à toutes les exigences de la section Faible ci-dessus. La mise à niveau d'appareils à partir d'une version antérieure d'Android n'est pas exemptée de la section C-2-7.
  • [C-3-2] Le taux d'acceptation des usurpations d'identité et des imposteurs NE DOIT PAS dépasser 7 %.
  • [C-3-3] DOIT demander à l'utilisateur de s'authentifier avec la méthode d'authentification principale recommandée (code, schéma, mot de passe, par exemple) au moins une fois toutes les 72 heures.

7.3.12. Capteur de posture

Implémentations sur les appareils :

  • MAY prend en charge le capteur de pose avec 6 degrés de liberté.

Si les implémentations d'appareils sont compatibles avec le capteur de pose à 6 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" tel qu'il est utilisé par les API Android et dans ce document fait spécifiquement référence au matériel permettant de passer des appels vocaux et d'envoyer des messages SMS via un réseau GSM ou CDMA. Bien que ces appels vocaux puissent ou non être commutés par paquets, ils sont considérés par Android comme indépendants de toute connectivité de données pouvant être implémentée à l'aide du même réseau. En d'autres termes, la fonctionnalité et les API de "téléphonie" d'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, qu'elles utilisent ou non un réseau mobile pour la connectivité des données.

  • Android PEUT être utilisé sur des appareils qui n'incluent pas de matériel de téléphonie. Autrement dit, Android est compatible avec les appareils autres que les 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 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 pour cette technologie.

Si les implémentations d'appareils n'incluent pas de matériel de téléphonie, elles :

  • [C-2-1] DOIT implémenter les API complètes en tant qu'opérations sans effet.

Si les implémentations d'appareils sont compatibles avec les eUICCs ou les eSIM/SIM intégrées et incluent un mécanisme propriétaire pour rendre la fonctionnalité eSIM disponible pour les développeurs tiers, elles :

7.4.1.1. Compatibilité du blocage de numéros

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

  • [C-1-1] DOIT inclure la fonctionnalité de blocage de 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 des numéros est temporairement levé, comme décrit dans la documentation du SDK.
  • [C-1-4] NE DOIT PAS écrire dans le 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'intention renvoyée par la méthode TelecomManager.createManageBlockedNumbersIntent().
  • [C-1-7] NE DOIT PAS autoriser les utilisateurs secondaires à 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. Toute l'UI liée au blocage DOIT être masquée pour les utilisateurs secondaires, et la liste des utilisateurs bloqués DOIT toujours être respectée.
  • DOIT migrer les numéros bloqués vers le fournisseur lorsqu'un appareil est mis à jour vers Android 7.0.
7.4.1.2. API Telecom

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

  • [C-1-1] DOIT être compatible avec les API ConnectionService décrites dans le SDK.
  • [C-1-2] DOIT afficher un nouvel appel entrant et permettre à l'utilisateur d'accepter ou de refuser l'appel entrant lorsqu'il est en cours d'appel avec une application tierce qui ne prend pas en charge la fonctionnalité de mise en attente spécifiée via CAPABILITY_SUPPORT_HOLD.
  • [C-1-3] DOIT disposer d'une application qui implémente InCallService.

  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'informer l'utilisateur que répondre à un appel entrant mettra fin à l'appel en cours.

    L'implémentation AOSP répond à ces exigences par le biais d'une notification heads-up qui indique à l'utilisateur que répondre à un appel entrant entraînera la fin de l'autre appel.

  • [C-SR] Il est FORTEMENT RECOMMANDÉ aux fabricants d'OEM de précharger l'application de téléphone par défaut qui affiche une entrée du journal d'appels et le nom d'une application tierce dans son journal d'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É aux STR 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'une brève pression sur l'événement clé est détectée pendant un appel en cours.
    • Appelez Connection.onAnswer() lorsqu'une pression courte sur l'événement clé est détectée lors d'un appel entrant.
    • Appelez Connection.onReject() lorsqu'une pression longue sur l'événement clé est détectée lors d'un appel entrant.
    • Activez ou désactivez le son de CallAudioState.

7.4.2. IEEE 802.11 (Wi-Fi)

Implémentations sur les appareils :

  • DOIT inclure la prise en charge d'une ou plusieurs formes de la norme 802.11.

Si les implémentations d'appareils incluent la compatibilité 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 le commutateur de fonctionnalité matérielle android.hardware.wifi.
  • [C-1-3] DOIT implémenter l'API multicast comme décrit dans la documentation du SDK.
  • [C-1-4] DOIT être compatible avec le multicast DNS (mDNS) et NE DOIT PAS filtrer les paquets mDNS (224.0.0.251) à aucun moment de son fonctionnement, 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 considérer 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 d'application et qui 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 valident que le réseau Wi-Fi fournit un accès à Internet.
  • [C-1-6] Il est FORTEMENT RECOMMANDÉ de réévaluer l'accès à Internet sur le Network lorsque la méthode d'API ConnectivityManager.reportNetworkConnectivity() est appelée, et de passer à tout autre réseau disponible (par exemple, les données mobiles) qui fournit un accès à Internet une fois que l'évaluation détermine que le Network actuel ne fournit plus d'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 la STA est déconnectée.
    • Chaque groupe de trames de requête de sonde constituant une analyse DOIT utiliser une adresse MAC cohérente (il NE DOIT PAS randomiser l'adresse MAC à mi-parcours d'une analyse).
    • Le numéro de séquence de la requête de vérification DOIT être incrémenté normalement (de manière séquentielle) entre les requêtes de vérification d'une analyse.
    • Le numéro de séquence de la demande de vérification DOIT être aléatoire entre la dernière demande de vérification d'une analyse et la première demande de vérification de l'analyse suivante.
  • [C-SR] sont FORTEMENT RECOMMANDÉS, tandis que STA est déconnecté, pour 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 incluent la prise en charge du mode économie d'énergie Wi-Fi tel que défini dans la norme IEEE 802.11, elles :

  • [C-3-1] DOIT désactiver le mode d'économie d'énergie du Wi-Fi chaque fois qu'une application acquiert un verrou WIFI_MODE_FULL_HIGH_PERF ou un verrou WIFI_MODE_FULL_LOW_LATENCY via les API WifiManager.createWifiLock() et WifiManager.WifiLock.acquire(), et que le verrou est actif.
  • [C-3-2] La latence moyenne aller-retour entre l'appareil et un point d'accès lorsque l'appareil est en mode Wi-Fi Low Latency Lock (WIFI_MODE_FULL_LOW_LATENCY) DOIT être inférieure à la latence en mode Wi-Fi High Perf Lock (WIFI_MODE_FULL_HIGH_PERF).
  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'utiliser des STRONGLY RECOMMENDED pour minimiser la latence aller-retour du Wi-Fi chaque fois qu'un verrou de faible latence (WIFI_MODE_FULL_LOW_LATENCY) est acquis et prend effet.

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 sur les appareils :

  • DOIT inclure la prise en charge de Wi-Fi Direct (Wi-Fi peer-to-peer).

Si les implémentations d'appareils incluent la compatibilité 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 sur les appareils :

Si les implémentations d'appareils incluent la prise en charge de TDLS et que TDLS est activé par l'API WiFiManager, elles :

  • [C-1-1] DOIT déclarer la compatibilité avec TDLS via WifiManager.isTdlsSupported.
  • N'UTILISEZ TDLS que lorsque cela est possible ET bénéfique.
  • DOIT disposer d'une heuristique et NE DOIT PAS utiliser TDLS lorsque ses performances peuvent être inférieures à celles d'un point d'accès Wi-Fi.
7.4.2.3. Wi-Fi Aware

Implémentations sur les appareils :

Si les implémentations d'appareils incluent la compatibilité avec Wi-Fi Aware et exposent la fonctionnalité aux applications tierces, elles doivent :

  • [C-1-1] DOIT implémenter les API WifiAwareManager comme décrit dans la documentation du SDK.
  • [C-1-2] DOIT déclarer l'option 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 aléatoire à des intervalles ne dépassant pas 30 minutes et chaque fois que Wi-Fi Aware est activé.

Si les implémentations d'appareils incluent la compatibilité avec Wi-Fi Aware et la localisation Wi-Fi, comme décrit dans la section 7.4.2.5, et exposent ces fonctionnalités aux applications tierces, elles doivent :

7.4.2.4. Passpoint Wi-Fi

Implémentations sur les appareils :

Si les implémentations d'appareils incluent la prise en charge de 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 du réseau, comme le service d'annonce générique (GAS, Generic Advertisement Service) et le protocole de requête du réseau d'accès (ANQP, Access Network Query Protocol).

Inversement, 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)

Implémentations sur les appareils :

Si les implémentations d'appareils incluent la prise en charge de la localisation Wi-Fi et exposent la fonctionnalité aux applications tierces, elles doivent :

  • [C-1-1] DOIT implémenter les API WifiRttManager comme décrit dans la documentation du SDK.
  • [C-1-2] DOIT déclarer l'option android.hardware.wifi.rtt.
  • [C-1-3] DOIT sélectionner une adresse MAC source aléatoire 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.2.6. Déchargement du keepalive Wi-Fi

Implémentations sur les appareils :

  • DOIT inclure la prise en charge du déchargement de la fonctionnalité Wi-Fi Keep-Alive.

Si les implémentations d'appareils incluent la prise en charge du déchargement de keepalive Wi-Fi et exposent la fonctionnalité aux applications tierces, elles :

  • [C-1-1] DOIT être compatible avec l'API SocketKeepAlive.

  • [C-1-2] DOIT prendre en charge au moins trois emplacements de signal de présence simultanés sur le Wi-Fi et au moins un emplacement de signal de présence sur le réseau mobile.

Si les implémentations d'appareils n'incluent pas la prise en charge du déchargement de keep-alive Wi-Fi, elles :

7.4.2.7. Wi-Fi Easy Connect (protocole de configuration des appareils)

Implémentations sur les appareils :

Si les implémentations d'appareils incluent la prise en charge de Wi-Fi Easy Connect et exposent la fonctionnalité aux applications tierces, elles :

7.4.3. Bluetooth

Si les implémentations d'appareils sont compatibles avec le profil audio Bluetooth, elles :

  • DOIT être compatible avec les codecs audio avancés et les codecs audio Bluetooth (par exemple, LDAC).

Si les implémentations d'appareils sont compatibles avec HFP, A2DP et AVRCP, elles :

  • DOIT prendre en charge au moins cinq appareils connectés au total.

Si les implémentations d'appareil 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 Bluetooth et Bluetooth à basse consommation.

Si les implémentations d'appareils incluent la prise en charge du Bluetooth et du Bluetooth à basse consommation, elles :

  • [C-2-1] DOIT déclarer les fonctionnalités de plate-forme pertinentes (android.hardware.bluetooth et android.hardware.bluetooth_le, respectivement) et implémenter les API de plate-forme.
  • DOIT implémenter les profils Bluetooth pertinents tels que A2DP, AVRCP, OBEX, HFP, etc., selon l'appareil.

Si les implémentations d'appareils incluent la prise en charge du 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 GATT (Generic Attribute Profile), comme décrit dans la documentation du SDK et android.bluetooth.
  • [C-3-3] DOIT signaler 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 préciser si la publicité à faible consommation d'énergie est prise en charge.
  • DOIT prendre en charge le déchargement de la logique de filtrage sur le chipset Bluetooth lors de l'implémentation de l'API ScanFilter.
  • DOIT prendre en charge le déchargement de l'analyse par lots sur le chipset Bluetooth.

  • DOIT être compatible avec plusieurs annonces (au moins quatre emplacements).

  • [SR] Il est FORTEMENT RECOMMANDÉ d'implémenter un délai d'inactivité pour les adresses privées résolvables (RPA) qui ne dépasse pas 15 minutes 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 l'utilisent pour la recherche 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().

Si les implémentations d'appareils incluent la prise en charge du profil Bluetooth LE et d'appareils auditifs, comme décrit dans Prise en charge audio des appareils auditifs avec Bluetooth LE, elles :

7.4.4. Communication en champ proche

Implémentations sur les appareils :

  • DOIT inclure un émetteur-récepteur et le matériel associé pour la communication en champ proche (NFC).
  • [C-0-1] DOIT implémenter les API android.nfc.NdefMessage et android.nfc.NdefRecord, même si elles ne sont pas compatibles avec la technologie NFC ou ne déclarent pas 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 des applications tierces, elles doivent :

  • [C-1-1] DOIT signaler 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 un 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)
    • NFC-F (JIS X 6319-4)
    • IsoDep (ISO 14443-4)
    • Types de tags NFC Forum 1, 2, 3, 4 et 5 (définis par le NFC Forum)

  • [SR] Il est FORTEMENT RECOMMANDÉ d'être capable de lire et d'écrire des messages NDEF ainsi que des données brutes via les normes NFC suivantes. Notez que, bien que les normes NFC soient fortement recommandées, la définition de compatibilité pour une future version prévoit de les remplacer par "DOIT". Ces normes sont facultatives dans cette version, mais seront obligatoires dans les versions ultérieures. Il est FORTEMENT RECOMMANDÉ aux appareils existants et nouveaux qui exécutent cette version d'Android de répondre à ces exigences dès maintenant afin de pouvoir passer aux futures versions de la plate-forme.

  • [C-1-13] DOIT interroger toutes les technologies compatibles en mode de détection NFC.

  • DOIT être en mode découverte NFC lorsque l'appareil est réveillé, que l'écran est actif et que l'écran de verrouillage est déverrouillé.
  • DOIT être capable de lire le code-barres et l'URL (si elle est encodée) des produits Thinfilm NFC Barcode.

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

Android est compatible avec le mode HCE (Host Card Emulation) NFC.

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 signaler 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 signaler 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 prennent en charge les technologies MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF sur MIFARE Classic) dans le rôle de lecteur/enregistreur, elles :

  • [C-4-1] DOIT implémenter les API Android correspondantes, comme indiqué dans le 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 sur les appareils :

  • [C-0-1] DOIT inclure la prise en charge d'une ou plusieurs formes de mise en réseau de données. Plus précisément, les implémentations d'appareils DOIVENT inclure la prise en charge d'au moins une norme de données capable d'atteindre 200 Kbit/s ou plus. Voici quelques exemples de technologies qui répondent à cette exigence : EDGE, HSPA, EV-DO, 802.11g, Ethernet et Bluetooth PAN.
  • Il DOIT également être compatible avec 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é des données.
  • [C-0-2] DOIT inclure une pile réseau IPv6 et accepter 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] DOIT activer IPv6 par défaut.
  • DOIT s'assurer que la communication IPv6 est aussi fiable que la communication IPv4, par exemple :
    • [C-0-4] DOIT maintenir la connectivité IPv6 en mode Veille.
    • [C-0-5] La limitation du débit ne DOIT PAS entraîner la perte de connectivité IPv6 de l'appareil sur un réseau compatible 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 au niveau local sur l'appareil. Les API gérées telles que Socket#getLocalAddress ou Socket#getLocalPort) et 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 d'appareils sont compatibles avec le Wi-Fi, elles :

  • [C-1-1] DOIT être compatible avec le fonctionnement à double pile et uniquement IPv6 sur le Wi-Fi.

Si les implémentations d'appareils sont compatibles avec Ethernet, elles :

  • [C-2-1] DOIT être compatible avec le fonctionnement à double pile sur Ethernet.

Si les implémentations d'appareils sont compatibles avec les données mobiles, elles :

  • DOIT être compatible avec 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éseau (par exemple, Wi-Fi et données mobiles) :

  • [C-3-1] DOIT répondre simultanément aux exigences ci-dessus sur chaque réseau lorsque l'appareil est connecté simultanément à plusieurs types de réseaux.

7.4.6. Paramètres de synchronisation

Implémentations sur les appareils :

  • [C-0-1] La synchronisation automatique principale DOIT être activée par défaut afin 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] STRONGLY RECOMMENDED to provide the data saver mode.

Si les implémentations d'appareils fournissent le mode Économiseur de données, elles :

Si les implémentations d'appareils 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] DOIT disposer d'une activité qui gère l'intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, mais 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'appareil incluent au moins une caméra, elles :

  • [C-1-1] DOIT déclarer le commutateur de fonctionnalité android.hardware.camera.any.
  • [C-1-2] Il DOIT être possible pour une application d'allouer simultanément trois bitmaps RGBA_8888 de la taille des images produites par le capteur de caméra de la plus haute résolution sur l'appareil, tandis que la caméra est ouverte à des fins d'aperçu de base et de capture d'image fixe.
  • [C-1-3] DOIT s'assurer que l'application d'appareil photo par défaut préinstallée qui gère les intents MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE ou MediaStore.ACTION_VIDEO_CAPTURE est responsable de la suppression de la position de l'utilisateur dans les métadonnées de l'image avant de l'envoyer à l'application destinataire lorsque celle-ci ne dispose pas de ACCESS_FINE_LOCATION.

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 opposé à l'écran. Elle permet de prendre des photos de scènes situées à l'arrière de l'appareil, comme une caméra traditionnelle.

Implémentations sur les appareils :

  • DOIT inclure une caméra arrière.

Si les implémentations d'appareils incluent au moins une caméra orientée vers l'arrière, elles :

  • [C-1-1] DOIT signaler les commutateurs de fonctionnalité android.hardware.camera et android.hardware.camera.any.
  • [C-1-2] DOIT avoir une résolution d'au moins 2 mégapixels.
  • DOIT avoir une mise au point automatique matérielle ou logicielle implémentée dans le pilote de l'appareil photo (transparente pour le logiciel d'application).
  • PEUT disposer d'un matériel à mise au point fixe ou EDOF (profondeur de champ étendue).
  • PEUT inclure un flash.

Si la caméra inclut un flash :

  • [C-2-1] La lampe flash NE DOIT PAS être allumée lorsqu'une instance android.hardware.Camera.PreviewCallback a été enregistrée sur une surface d'aperçu de la caméra, sauf si l'application a explicitement activé le flash en activant les attributs FLASH_MODE_AUTO ou FLASH_MODE_ON d'un objet Camera.Parameters. Notez que cette contrainte ne s'applique pas à l'application de caméras système intégrée à l'appareil, mais uniquement aux applications tierces utilisant Camera.PreviewCallback.

7.5.2. Caméra frontale

Une caméra frontale 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 filmer l'utilisateur, par exemple pour les visioconférences et les applications similaires.

Implémentations sur les appareils :

  • PEUT inclure une caméra frontale.

Si les implémentations d'appareils incluent au moins une caméra frontale, elles :

  • [C-1-1] DOIT signaler les commutateurs 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 de caméra frontale comme caméra par défaut pour l'API Camera et NE DOIT PAS configurer l'API pour traiter une caméra frontale comme caméra arrière par défaut, même s'il s'agit de 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é la rotation de l'affichage de l'appareil photo 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 actuelle ne demande pas explicitement la rotation de l'affichage de la caméra via un appel à la méthode android.hardware.Camera.setDisplayOrientation().
  • [C-1-5] NE DOIT PAS mettre en miroir l'image fixe ou les flux vidéo finaux 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 la post-vue de la même manière que le flux d'images de prévisualisation de la caméra.
  • PEUT inclure des fonctionnalités (comme l'autofocus, le flash, etc.) disponibles pour les caméras orientées vers l'arrière, comme décrit dans la section 7.5.1.

Si les implémentations d'appareils peuvent être pivotées par l'utilisateur (automatiquement via un accéléromètre ou manuellement via une saisie utilisateur, par exemple) :

  • [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 sur les appareils :

  • PEUT inclure la compatibilité avec une caméra externe qui n'est pas nécessairement toujours connectée.

Si les implémentations d'appareils incluent la prise en charge d'une caméra externe, elles :

  • [C-1-1] DOIT 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] DOIT réussir les tests CTS de la caméra avec un appareil photo externe physique connecté. Pour en savoir plus sur les tests CTS de l'appareil photo, consultez source.android.com.
  • DOIT être compatible avec 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).
  • MAY est compatible avec plusieurs caméras.
  • MAY prend en charge l'encodage vidéo basé sur la caméra.

Si l'encodage vidéo basé sur la caméra est pris en charge :

  • [C-2-1] Une diffusion simultanée non encodée / MJPEG (résolution QVGA 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 un contrôle de l'appareil photo de niveau inférieur à l'application, y compris des flux de rafale/streaming efficaces sans copie et des contrôles par frame de l'exposition, du gain, des gains de balance des blancs, de la conversion des couleurs, de la réduction du bruit, de l'amélioration de la netteté et plus encore.

L'ancien package d'API, android.hardware.Camera, est marqué comme obsolète dans Android 5.0, mais il DOIT 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 de l'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 une vitesse ou une qualité identiques, mais DOIVENT être aussi proches que possible.

Les implémentations d'appareils DOIVENT implémenter les comportements suivants pour les API liées à l'appareil photo, pour tous les appareils photo disponibles. Implémentations sur les appareils :

  • [C-0-1] DOIT 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] DOIT é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[] sont transmises à onPreviewFrame(). En d'autres termes, NV21 DOIT être la valeur par défaut.
  • [C-0-3] DOIT être compatible avec le format YV12 (tel qu'indiqué par la constante android.graphics.ImageFormat.YV12) pour les aperçus de 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 au format YV12.)
  • [C-0-4] DOIT prendre en charge les formats android.hardware.ImageFormat.YUV_420_888 et android.hardware.ImageFormat.JPEG en tant que sorties 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] DOIT toujours implémenter l'intégralité de l'API Camera incluse dans la documentation du SDK Android, que l'appareil inclue ou non la mise au point automatique matérielle ou d'autres fonctionnalités. Par exemple, les caméras sans autofocus DOIVENT toujours appeler les instances android.hardware.Camera.AutoFocusCallback enregistrées (même si cela n'a aucune pertinence pour une caméra sans autofocus). Notez que cela s'applique aux caméras frontales. Par exemple, même si la plupart des caméras frontales ne sont pas compatibles avec la mise au point automatique, les rappels d'API DOIVENT toujours être "simulés" comme décrit.
  • [C-0-6] DOIT reconnaître et respecter chaque nom de paramètre défini comme constante dans les classes android.hardware.Camera.Parameters et android.hardware.camera2.CaptureRequest. À l'inverse, les implémentations d'appareil NE DOIVENT PAS honorer ni reconnaître les constantes de chaîne transmises à la méthode android.hardware.Camera.setParameters() autres que celles documentées comme constantes sur android.hardware.Camera.Parameters. En d'autres termes, les implémentations d'appareils DOIVENT prendre en charge tous les paramètres de caméra standards si le matériel le permet, et NE DOIVENT PAS prendre en charge les types de paramètres de caméra personnalisés. Par exemple, les implémentations d'appareils qui prennent en charge la capture d'images à l'aide de techniques d'imagerie à plage dynamique élevée (HDR) DOIVENT prendre en charge le paramètre de caméra Camera.SCENE_MODE_HDR.
  • [C-0-7] DOIT signaler le niveau de compatibilité approprié avec la propriété android.info.supportedHardwareLevel, comme décrit dans le SDK Android, et signaler les indicateurs de fonctionnalité du framework appropriés.
  • [C-0-8] DOIT également déclarer les capacités de caméra individuelles de android.hardware.camera2 via la propriété android.request.availableCapabilities et déclarer les indicateurs de fonctionnalité appropriés ; DOIT définir l'indicateur de fonctionnalité si l'un de ses appareils photo associés est compatible avec la fonctionnalité.
  • [C-0-9] DOIT diffuser l'intention 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 à la galerie multimédia.
  • [C-0-10] DOIT diffuser l'intention Camera.ACTION_NEW_VIDEO chaque fois qu'une nouvelle vidéo est enregistrée par la caméra et que l'entrée de l'image a été ajoutée au Media Store.
  • [C-0-11] DOIT permettre d'accéder à toutes les caméras via l'API android.hardware.camera2, en plus de l'API android.hardware.Camera obsolète.
  • [C-SR] Pour les appareils dotés de plusieurs caméras RVB orientées dans la même direction, il est FORTEMENT RECOMMANDÉ de prendre en charge un périphérique de caméra logique qui liste la fonctionnalité CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, composée de toutes les caméras RVB orientées dans cette direction en tant que sous-périphériques physiques.

Si les implémentations d'appareils fournissent une API de caméra propriétaire aux applications tierces, elles :

7.5.5. Orientation de la caméra

Si les implémentations d'appareils sont dotées d'une caméra avant ou arrière, celle-ci ou celles-ci :

  • [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 en mode Paysage, les caméras DOIVENT capturer des images en mode Paysage. Cela s'applique quelle que soit l'orientation naturelle de l'appareil, c'est-à-dire aux appareils dont l'orientation principale est le mode paysage, ainsi qu'à ceux dont l'orientation principale est le mode portrait.

7.6. Mémoire et stockage

7.6.1. Mémoire et espace de stockage minimum

Implémentations sur les appareils :

  • [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. Il DOIT être capable de télécharger des fichiers individuels d'au moins 100 Mo vers l'emplacement de "cache" par défaut.

7.6.2. Stockage partagé des applications

Implémentations sur les appareils :

  • [C-0-1] DOIT proposer un espace de stockage partagé par les applications, souvent appelé "espace de stockage externe partagé", "espace de stockage partagé par les applications" ou par le chemin Linux "/sdcard" sur lequel il est monté.
  • [C-0-2] DOIT être configuré avec un stockage partagé monté par défaut, en d'autres termes "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 emplacement pour carte Secure Digital).
  • [C-0-3] DOIT monter le stockage partagé de l'application directement sur le chemin Linux sdcard ou inclure un lien symbolique Linux de sdcard vers le point de montage réel.
  • [C-0-4] DOIT appliquer l'autorisation android.permission.WRITE_EXTERNAL_STORAGE sur cet espace de stockage partagé, comme indiqué dans le SDK.
  • [C-0-5] DOIT activer le stockage étendu par défaut pour toutes les applications ciblant le niveau d'API 29 ou supérieur, sauf dans les cas suivants :
    • lorsque l'application a été installée avant la mise à niveau de l'appareil vers le niveau d'API 29, quel que soit l'API cible de l'application.
    • lorsque l'application a demandé android:requestLegacyExternalStorage="true" dans son fichier manifeste.
    • lorsque l'autorisation android.permission.WRITE_MEDIA_STORAGE est accordée à l'application.
  • [C-0-6] DOIT s'assurer que les applications avec stockage étendu activé n'ont pas d'accès direct au système de fichiers pour les fichiers en dehors de leurs répertoires spécifiques à l'application, tels que renvoyés par les méthodes d'API Context telles que les méthodes Context.getExternalFilesDirs(), Context.getExternalCacheDirs(), Context.getExternalMediaDirs() et Context.getObbDirs().
  • [C-0-7] DOIT masquer les métadonnées de localisation, telles que les balises GPS Exif, stockées dans les fichiers multimédias lorsque ces fichiers sont consultés via MediaStore, sauf lorsque l'application appelante détient l'autorisation ACCESS_MEDIA_LOCATION.

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 par l'utilisateur, tel qu'un lecteur de carte Secure Digital (SD).
  • Partie du stockage interne (non amovible) telle qu'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] DOIT implémenter une interface utilisateur de type toast ou pop-up pour avertir l'utilisateur lorsqu'aucun support de stockage n'est inséré dans le logement.
  • [C-1-2] DOIT inclure un support de stockage au format FAT (par exemple, une carte SD) ou indiquer sur l'emballage et les autres supports disponibles 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é interne des applications.
  • 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é (par exemple, un emplacement pour carte SD et un stockage interne partagé), elles :

  • [C-2-1] DOIT autoriser uniquement les applications Android préinstallées et privilégiées disposant de l'autorisation WRITE_MEDIA_STORAGE à écrire sur le stockage externe secondaire, sauf lors de l'écriture dans leurs répertoires spécifiques au package ou dans le URI renvoyé par le déclenchement de l'intent ACTION_OPEN_DOCUMENT_TREE.
  • [C-2-2] DOIT exiger que l'accès direct associé à l'autorisation android.permission.WRITE_MEDIA_STORAGE ne soit accordé aux applications visibles par l'utilisateur que lorsque l'autorisation android.permission.WRITE_EXTERNAL_STORAGE est également accordée.
  • [SR] Il est FORTEMENT RECOMMANDÉ que les applications Android préinstallées et privilégiées utilisent des API publiques telles que MediaStore pour interagir avec les périphériques de stockage, au lieu de s'appuyer sur l'accès direct accordé par android.permission.WRITE_MEDIA_STORAGE.

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 depuis un ordinateur hôte.
  • DOIT exposer le contenu des deux chemins de stockage de manière transparente via le service de scanner multimédia d'Android et android.provider.MediaStore.
  • PEUT utiliser le stockage de masse USB, mais DOIT utiliser le protocole MTP (Media Transfer Protocol) 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 MTP (Media Transfer Protocol), elles :

  • DOIT être compatible avec l'hôte MTP Android de référence, Android File Transfer.
  • DOIT signaler une classe de périphérique USB de 0x00.
  • DOIT indiquer le nom d'interface USB "MTP".

7.6.3. Stockage adoptable

Si l'appareil est censé être mobile (contrairement à un téléviseur), les implémentations d'appareils sont les suivantes :

  • [SR] Il est FORTEMENT RECOMMANDÉ d'implémenter le stockage adaptable dans un emplacement stable à long terme, car une déconnexion accidentelle peut entraîner une perte ou une corruption des données.

Si le port du périphérique de stockage amovible se trouve dans un emplacement stable à long terme, par exemple dans le compartiment de la batterie ou sous un autre couvercle de 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 d'appareils incluent un port USB compatible avec le mode périphérique :

  • [C-1-1] Le port DOIT pouvoir être connecté à un hôte USB doté d'un port USB standard de type A ou de type C.
  • [C-1-2] DOIT signaler la valeur correcte de iSerialNumber dans le descripteur de périphérique standard USB via android.os.Build.SERIAL.
  • [C-1-3] DOIT détecter les chargeurs de 1,5 A et 3,0 A conformément à la norme de résistance Type-C et DOIT détecter les changements dans l'annonce s'ils sont compatibles avec l'USB Type-C.
  • [SR] Le port DOIT utiliser un facteur de forme micro-B, micro-AB ou USB Type-C. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin de pouvoir passer aux futures versions de la plate-forme.
  • [SR] Le port DOIT être situé 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 soit correct 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 de pouvoir passer aux futures versions de la plate-forme.
  • [SR] DOIT implémenter la prise en charge du tirage d'un courant de 1,5 A pendant le chirp et le trafic HS, comme spécifié dans la spécification USB Battery Charging, révision 1.2. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin de pouvoir passer aux futures versions de la plate-forme.
  • [SR] Il est FORTEMENT 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 cela soit indiqué comme "FORTEMENT RECOMMANDÉ", il est possible que nous EXIGIONS à l'avenir que tous les appareils Type-C soient entièrement interopérables avec les chargeurs Type-C standards dans les futures versions d'Android.
  • [SR] STRONGLY RECOMMENDED to support Power Delivery for data and power role swapping when they support Type-C USB and USB host mode.
  • DOIT être compatible avec la technologie Power Delivery pour la recharge haute tension et avec les modes alternatifs tels que la sortie vidéo.
  • 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 de description de l'interface iInterface du 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 telle qu'elle est documentée dans le SDK Android et DOIT déclarer la prise en charge de la fonctionnalité matérielle android.hardware.usb.host.
  • [C-1-2] DOIT implémenter la prise en charge de la connexion de périphériques USB standards, c'est-à-dire qu'il DOIT :
    • Disposer d'un port Type-C sur l'appareil ou être livré avec un ou plusieurs câbles adaptant un port propriétaire sur l'appareil à un port USB Type-C standard (appareil USB Type-C).
    • Disposer d'un port de type A intégré ou être fourni avec un ou plusieurs câbles adaptant un port propriétaire intégré à un port USB de type A standard.
    • Disposer d'un port micro-AB sur l'appareil, qui DOIT être fourni avec un câble adaptateur pour un port Type-A standard.
  • [C-1-3] NE DOIT PAS être livré avec un adaptateur convertissant les ports USB de type A ou micro-AB en port de type C (prise).
  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter la classe audio USB, comme indiqué dans la documentation du SDK Android.
  • DOIT prendre en charge la recharge du périphérique USB connecté en mode hôte, en annonçant un courant source d'au moins 1,5 A, comme spécifié dans la section "Termination Parameters" de la spécification USB Type-C Cable and Connector Revision 1.2 pour les connecteurs USB Type-C, ou en utilisant la plage de courant de sortie Charging Downstream Port(CDP) comme spécifié dans les spécifications USB Battery Charging, révision 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 demande d'utilisation de commandes vocales aux constantes KeyEvent comme suit :
    • 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 tout appareil MTP (Media Transfer Protocol) connecté à distance et rendre son contenu accessible 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 l'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 FORTEMENT RECOMMANDÉ de prendre en charge DisplayPort, il est RECOMMANDÉ de prendre en charge les débits de données USB SuperSpeed et il est FORTEMENT RECOMMANDÉ de prendre en charge Power Delivery pour l'échange de rôle des données et de l'alimentation.
  • [SR] Il est FORTEMENT RECOMMANDÉ de NE PAS prendre en charge le mode accessoire de l'adaptateur audio décrit dans l'annexe A de la spécification du câble et du connecteur USB Type-C, révision 1.2.
  • DOIT implémenter le modèle Try.* le plus approprié 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 doivent :

  • [C-1-1] DOIT signaler la constante de fonctionnalité android.hardware.microphone.
  • [C-1-2] DOIT respecter les exigences relatives à l'enregistrement audio de la section 5.4.
  • [C-1-3] DOIT répondre aux exigences de latence audio de la section 5.6.
  • [SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'enregistrement de sons proches des ultrasons, comme décrit dans la section 7.8.3.

Si les implémentations d'appareils omettent un micro, elles doivent :

  • [C-2-1] NE DOIT PAS signaler la constante de fonctionnalité android.hardware.microphone.
  • [C-2-2] DOIT implémenter l'API d'enregistrement audio 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 signaler la constante de fonctionnalité android.hardware.audio.output.
  • [C-1-2] DOIT répondre aux exigences de lecture audio de la section 5.5.
  • [C-1-3] DOIT répondre aux exigences de latence audio de la section 5.6.
  • [SR] STRONGLY RECOMMENDED to support near-ultrasound playback as described in 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] DOIT implémenter au moins les API liées à la sortie audio en tant qu'opérations sans effet.

Dans cette section, un "port de sortie" désigne une interface physique telle qu'une prise audio de 3, 5 mm, un port HDMI ou un port USB en mode hôte 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 constitue pas 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 de 3,5 mm dans l'écosystème Android, si les implémentations d'appareils incluent un ou plusieurs ports audio analogiques, elles :

  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'inclure au moins un port audio de type connecteur audio 3,5 mm à quatre conducteurs.

Si les implémentations d'appareils disposent d'une prise audio 3,5 mm à quatre conducteurs, elles :

  • [C-1-1] DOIT être compatible avec la lecture audio sur des écouteurs stéréo et des casques stéréo avec micro.
  • [C-1-2] DOIT être compatible avec les connecteurs audio TRRS avec l'ordre de broches CTIA.
  • [C-1-3] DOIT prendre en charge la détection et le mappage des codes de touches pour les trois plages d'impédance équivalente suivantes entre les conducteurs du microphone et de la masse 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] MUST déclencher ACTION_HEADSET_PLUG lors de l'insertion d'une fiche, mais uniquement une fois que tous les contacts de la fiche touchent les segments correspondants de 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 de haut-parleur de 32 ohms.
  • [C-1-6] DOIT avoir une tension de polarisation du micro comprise entre 1,8 V et 2,9 V.
  • [C-1-7] DOIT détecter et mapper le code clé pour la plage suivante d'impédance équivalente entre les conducteurs du micro et de la masse sur la prise audio :
    • 110 à 180 ohms : KEYCODE_VOICE_ASSIST
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge les connecteurs audio avec l'ordre des broches OMTP.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'enregistrement audio à partir de casques stéréo avec micro.

Si les implémentations d'appareils sont dotées 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] DOIT prendre en charge la détection du micro sur l'accessoire audio branché.
7.8.2.2. Ports audio numériques

Pour être compatible avec les casques et autres accessoires audio utilisant des connecteurs USB-C et implémentant (classe audio USB) dans l'écosystème Android, comme défini dans la spécification des casques USB Android.

Consultez la section 2.2.1 pour connaître les exigences spécifiques aux appareils.

7.8.3. Proche des ultrasons

La bande audio proche des ultrasons se situe entre 18,5 kHz et 20 kHz.

Implémentations sur les appareils :

  • DOIT signaler correctement la compatibilité avec la fonctionnalité audio proche des 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 en puissance moyenne du microphone dans la bande de fréquences de 18,5 kHz à 20 kHz DOIT être inférieure de 15 dB maximum à la réponse à 2 kHz.
  • [C-1-2] Le rapport signal/bruit non pondéré du micro sur la plage de fréquences de 18,5 kHz à 20 kHz pour une tonalité de 19 kHz à -26 dBFS DOIT être d'au moins 50 dB.

Si PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND est défini sur "true" :

  • [C-2-1] La réponse moyenne de l'enceinte entre 18,5 kHz et 20 kHz DOIT être inférieure d'au moins 40 dB à la réponse à 2 kHz.

7.8.4. Intégrité du signal

Implémentations sur les appareils :

  • DOIT fournir un chemin de signal audio sans problème pour les flux d'entrée et de sortie sur les appareils portables, tel que défini par zéro problème mesuré lors d'un test d'une minute par chemin. Testez à l'aide de [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester) "Automated Glitch Test".

Le test nécessite un dongle de boucle audio, utilisé directement dans une prise 3,5 mm et/ou en combinaison avec un adaptateur USB-C vers 3,5 mm. TOUS les ports de sortie audio DOIVENT être testés.

OboeTester est actuellement compatible avec les chemins AAudio. Les combinaisons suivantes DOIVENT donc être testées pour détecter les problèmes à l'aide d'AAudio :

Mode Performances Partage Taux d'échantillonnage de sortie Dans les chans Out Chans
LOW_LATENCY EXCLUSIFS NON DÉFINI 1 2
LOW_LATENCY EXCLUSIFS NON DÉFINI 2 1
LOW_LATENCY PARTAGÉ NON DÉFINI 1 2
LOW_LATENCY PARTAGÉ NON DÉFINI 2 1
AUCUNE PARTAGÉ 48000 1 2
AUCUNE PARTAGÉ 48000 2 1
AUCUNE PARTAGÉ 44100 1 2
AUCUNE PARTAGÉ 44100 2 1
AUCUNE PARTAGÉ 16000 1 2
AUCUNE PARTAGÉ 16000 2 1

Un flux fiable DOIT répondre aux critères suivants concernant le rapport signal/bruit (SNR) et la distorsion harmonique totale (THD) pour une sinusoïde de 2 000 Hz.

Transducteur THD SNR
Haut-parleur principal intégré, mesuré à l'aide d'un micro de référence externe < 3,0 % >= 50 dB
Microphone intégré principal, mesuré à l'aide d'un haut-parleur de référence externe < 3,0 % >= 50 dB
Connecteurs analogiques 3,5 mm intégrés, testés à l'aide d'un adaptateur de boucle < 1 % >= 60 dB
Adaptateurs USB fournis avec le téléphone, testés à l'aide d'un adaptateur de boucle < 1,0 % >= 60 dB

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 RV, 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 sélectionnée par l'utilisateur.

7.9.2. Mode Réalité virtuelle : hautes performances

Si les implémentations d'appareils sont compatibles avec le mode RV, elles :

  • [C-1-1] DOIT comporter au moins deux cœurs physiques.
  • [C-1-2] DOIT déclarer la fonctionnalité android.hardware.vr.high_performance.
  • [C-1-3] MUST support sustained performance mode.
  • [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 android.hardware.vulkan.level 1 ou version 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, 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, 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É aux développeurs d'implémenter VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing et VK_KHR_shared_presentable_image, et de l'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 être capables de synchroniser l'accès au tampon avant partagé de sorte que le rendu alterné pour chaque œil du contenu VR à 60 fps avec deux contextes de rendu s'affiche sans artefacts de déchirement visibles.
  • [C-1-9] DOIT implémenter la prise en charge des indicateurs AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA et AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT, comme décrit dans le NDK.
  • [C-1-10] DOIT implémenter la compatibilité avec les 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] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'attribution des AHardwareBuffer comportant plusieurs calques, ainsi que les indicateurs et les 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 prendre en charge 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 être compatible avec l'API HardwarePropertiesManager.getDeviceTemperatures et renvoyer des valeurs précises pour la température cutanée.
  • [C-1-14] DOIT comporter un écran intégré dont la résolution DOIT être d'au moins 1 920 x 1 080.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ que la résolution d'affichage soit d'au moins 2 560 x 1 440.
  • [C-1-15] L'affichage DOIT se mettre à jour à au moins 60 Hz en mode VR.
  • [C-1-17] L'écran DOIT être compatible avec un mode à faible persistance (≤ 5 millisecondes). La persistance est 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] Il est FORTEMENT RECOMMANDÉ 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 répondre aux 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 bout en bout entre le mouvement et le photon ne DOIT PAS dépasser 28 millisecondes.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ que la latence de bout en bout entre le mouvement et le photon ne dépasse pas 20 millisecondes.
  • [C-1-23] DOIT avoir un ratio de première image d'au moins 85 %, qui correspond au rapport entre la luminosité des pixels de la première image après une transition du noir au blanc et la luminosité des pixels blancs en régime permanent.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ que les STR aient un ratio de première image d'au moins 90 %.
  • PEUT fournir un cœur exclusif à l'application au premier plan et PEUT prendre en charge l'API Process.getExclusiveCores pour renvoyer le nombre de cœurs de processeur exclusifs à l'application au premier plan.

Si le cœur exclusif est pris en charge, le cœur :

  • [C-2-1] NE DOIT PAS autoriser l'exécution d'autres processus d'espace utilisateur (à l'exception des pilotes de périphériques utilisés par l'application), mais PEUT autoriser l'exécution de certains processus du noyau si nécessaire.

8. Performances et puissance

Certains critères minimaux de performances et de puissance sont essentiels à l'expérience utilisateur et ont un impact sur les hypothèses de base que les développeurs auraient lors du développement d'une application.

8.1. Cohérence de l'expérience utilisateur

Une interface utilisateur fluide peut être fournie à l'utilisateur final si certaines exigences 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 d'appareils 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

En fournissant une base de référence commune pour des performances d'accès aux fichiers cohérentes sur la partition de stockage des données privées de l'application (/data), les développeurs d'applications peuvent définir une attente appropriée qui les aidera à concevoir leur logiciel. Les implémentations d'appareils, selon le type d'appareil, PEUVENT avoir 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 : Mesuré 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 permettant d'améliorer la gestion de l'alimentation de l'appareil qui sont incluses dans AOSP ou qui étendent les fonctionnalités incluses dans AOSP, 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, ni pour l'utilisation des paramètres système globaux des modes d'économie d'énergie Veille de l'application et Veille.
  • [C-1-2] NE DOIT PAS s'écarter de l'implémentation AOSP pour l'utilisation des paramètres généraux permettant de gérer la limitation des tâches, des alarmes et du réseau pour les applications de chaque bucket dans le mode Veille de l'application.
  • [C-1-3] NE DOIT PAS s'écarter de l'implémentation AOSP pour le nombre de buckets App Standby utilisés pour App Standby.
  • [C-1-4] DOIT implémenter les buckets App Standby et le mode Veille comme décrit dans 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 aux utilisateurs la possibilité d'activer et de désactiver la fonctionnalité d'économiseur de batterie.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de fournir aux utilisateurs la possibilité d'afficher toutes les applications exemptées des modes d'économie d'énergie Veille de l'application et Veille prolongée.

En plus des modes d'économie d'énergie, les implémentations d'appareils Android PEUVENT implémenter tout ou partie des quatre états de 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 DOIT passer dans cet état uniquement après que l'utilisateur a effectué une action explicite pour le mettre dans un état inactif (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 répondre à 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, il DOIT quitter l'état S3 lorsque des applications tierces ont besoin des ressources système, comme décrit dans ce SDK.

    Par exemple, alors que les applications tierces demandent de maintenir l'écran allumé via FLAG_KEEP_SCREEN_ON ou de maintenir le processeur en fonctionnement via PARTIAL_WAKE_LOCK, l'appareil NE DOIT PAS passer à l'état S3, sauf si, comme décrit dans C-1-1, l'utilisateur a pris des mesures explicites pour mettre l'appareil en état inactif. Inversement, lorsqu'une tâche que des applications tierces implémentent via JobScheduler est déclenchée ou que Firebase Cloud Messaging est distribué à 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. L'AOSP implémente de nombreux signaux de réveil qui déclenchent une sortie de cet état.

8.4. Comptabilisation de la consommation électrique

Une comptabilisation et un reporting plus précis de la consommation d'énergie fournissent au développeur d'applications à la fois les incitations et les outils nécessaires pour optimiser le modèle d'utilisation de l'énergie de l'application.

Implémentations sur les appareils :

  • [SR] Il est FORTEMENT RECOMMANDÉ de fournir un profil de puissance par composant qui définit la valeur de consommation de courant pour chaque composant matériel et la décharge de batterie approximative causée par les composants au fil du temps, comme indiqué sur le site Android Open Source Project.
  • [SR] Il est FORTEMENT RECOMMANDÉ de signaler toutes les valeurs de consommation d'énergie en milliampères-heure (mAh).
  • [SR] STRONGLY RECOMMENDED to report CPU power consumption per each process's UID. Le projet Android Open Source répond à cette exigence grâce à l'implémentation du module de noyau uid_cputime.
  • [SR] Il est FORTEMENT RECOMMANDÉ de mettre cette consommation d'énergie à la disposition du développeur d'applications via la commande shell adb shell dumpsys batterystats.
  • DOIT être attribuée au composant matériel lui-même s'il est impossible d'attribuer la consommation d'énergie du composant matériel à une application.

8.5. Constance des performances

Les performances peuvent fluctuer considérablement 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 de la limitation de la fréquence du processeur due aux limites de température. Android inclut des interfaces programmatiques qui permettent à l'application de premier plan de demander au système d'optimiser l'allocation des ressources pour faire face à ces fluctuations lorsque l'appareil en est capable.

Implémentations sur les appareils :

Si les implémentations d'appareils indiquent la prise en charge du mode Performances soutenues, elles :

  • [C-1-1] DOIT fournir à l'application de premier plan supérieure un niveau de performances constant 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 sont compatibles avec la réservation d'un cœur exclusif pour l'application de premier plan, elles :

  • [C-2-1] DOIT signaler via la méthode d'API Process.getExclusiveCores() les numéros d'ID des cœurs exclusifs qui peuvent être réservés par l'application de premier plan supérieure.
  • [C-2-2] NE DOIT PAS autoriser les processus de l'espace utilisateur, à l'exception des pilotes de périphériques utilisés par l'application pour s'exécuter sur les cœurs exclusifs, mais PEUT autoriser l'exécution de certains processus du noyau si nécessaire.

Si les implémentations d'appareils ne sont pas compatibles avec un cœur exclusif, elles :

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

Implémentations sur les appareils :

  • [C-0-1] DOIT implémenter un modèle de sécurité cohérent avec le modèle de sécurité de la plate-forme Android, tel que défini dans le document de référence sur la sécurité et les autorisations dans la documentation pour les développeurs Android.

  • [C-0-2] DOIT permettre l'installation d'applications autosignées sans nécessiter d'autorisations ni de certificats supplémentaires de la part de tiers ou d'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 sur les appareils :

  • [C-0-1] DOIT prendre en charge le modèle d'autorisations Android tel que défini dans la documentation pour les 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 ni 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 uniquement être accordées 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 autorisées 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 "dangerous" (dangereux) sont des autorisations d'exécution. Les applications avec targetSdkVersion > 22 les demandent au moment de l'exécution.

Implémentations sur les appareils :

  • [C-0-3] DOIT afficher une interface dédiée permettant à l'utilisateur de décider d'accorder ou non 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] DOIT avoir une et une seule implémentation des deux interfaces utilisateur.
  • [C-0-5] NE DOIT 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] DOIT 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é d'un matériel sécurisé avec une protection équivalente ou supérieure à celle décrite dans le service Google Cloud Key Vault pour empêcher les attaques par force brute sur le facteur de connaissance de l'écran de verrouillage.

Implémentations sur les appareils :

  • [C-0-7] DOIT respecter les propriétés de l'autorisation de localisation Android lorsqu'une application demande les données de localisation ou d'activité physique via une API Android standard ou un mécanisme propriétaire. Ces données incluent, entre autres, les éléments suivants :

    • Position de l'appareil (latitude et longitude, par exemple).
    • Informations permettant de déterminer ou d'estimer la position de l'appareil (par exemple, SSID, BSSID, ID de cellule, recherches Bluetooth ou position du réseau auquel l'appareil est connecté).
    • Activité physique de l'utilisateur ou classification de l'activité physique.

Plus précisément, les implémentations d'appareils :

  • [C-0-8] DOIT obtenir le consentement de l'utilisateur pour autoriser une application à accéder aux données de localisation ou d'activité physique.
  • [C-0-9] DOIT accorder une autorisation d'exécution UNIQUEMENT à l'application qui dispose d'une autorisation suffisante, comme décrit dans le SDK. Par exemple, TelephonyManager#getServiceState nécessite android.permission.ACCESS_FINE_LOCATION).

Les autorisations peuvent être marquées comme restreintes, ce qui modifie leur comportement.

  • [C-0-10] Les autorisations marquées par l'indicateur hardRestricted NE DOIVENT PAS être accordées à une application, sauf si :

    • Le fichier APK d'une application se trouve dans la partition système.
    • L'utilisateur attribue à une application un rôle associé aux autorisations hardRestricted.
    • Le programme d'installation accorde hardRestricted à une application.
    • Une application se voit accorder l'autorisation hardRestricted sur une version antérieure d'Android.

  • [C-0-11] Les applications disposant d'une autorisation softRestricted DOIVENT obtenir un accès limité et NE DOIVENT PAS obtenir un accès complet tant qu'elles n'ont pas été ajoutées à une liste d'autorisation, comme décrit dans le SDK. L'accès complet et l'accès limité sont définis pour chaque autorisation softRestricted (par exemple, WRITE_EXTERNAL_STORAGE et READ_EXTERNAL_STORAGE).

Si les implémentations d'appareils incluent une application préinstallée ou souhaitent autoriser les applications tierces à accéder aux statistiques d'utilisation, elles doivent :

  • [SR] Il est FORTEMENT RECOMMANDÉ de fournir un mécanisme accessible aux utilisateurs pour accorder ou révoquer l'accès aux statistiques d'utilisation en réponse à l'intention 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 l'accès aux statistiques d'utilisation à certaines applications, y compris les applications préinstallées, elles doivent :

  • [C-1-1] DOIT toujours avoir une activité qui gère le modèle d'intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, mais DOIT l'implémenter en tant qu'opération sans effet, c'est-à-dire avoir un comportement équivalent à celui qui se produit lorsque l'accès est refusé à l'utilisateur.

9.2. UID et isolement des processus

Implémentations sur les appareils :

  • [C-0-1] DOIT être compatible avec le modèle de bac à sable des applications Android, dans lequel chaque application s'exécute en tant qu'UID de style Unix unique et dans un processus distinct.
  • [C-0-2] DOIT permettre l'exécution de plusieurs applications avec le même ID utilisateur Linux, à condition que les applications soient correctement signées et construites, comme défini dans la documentation de référence sur la sécurité et les autorisations.

9.3. Autorisations du système de fichiers

Implémentations sur les appareils :

9.4. Autres environnements d'exécution

Les implémentations d'appareils DOIVENT maintenir la cohérence du modèle de sécurité et d'autorisations 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 eux-mêmes être des applications Android et respecter le modèle de sécurité Android standard, comme décrit ailleurs dans la section 9.

  • [C-0-2] Les environnements d'exécution alternatifs NE DOIVENT PAS avoir accès 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 réservées aux applications système.

  • [C-0-4] Les environnements d'exécution alternatifs DOIVENT respecter le modèle de bac à sable Android, et les applications installées à l'aide d'un environnement d'exécution alternatif NE DOIVENT PAS réutiliser le bac à sable d'une autre application installée sur l'appareil, sauf par le biais des 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 ou se voir accorder l'accès aux bacs à sable correspondant à d'autres applications Android.

  • [C-0-6] Les environnements d'exécution alternatifs NE DOIVENT PAS être lancés avec des privilèges de superutilisateur (root) ou d'un autre ID utilisateur, ni accorder de tels privilèges à d'autres applications.

  • [C-0-7] Lorsque les fichiers .apk des environnements d'exécution alternatifs 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 de l'appareil pour laquelle il existe une autorisation Android correspondante (comme l'appareil photo, le GPS, etc.), l'environnement d'exécution 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 capacité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 runtimes alternatifs DOIVENT installer les 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 utilisant l'environnement d'exécution alternatif.

9.5. Compatibilité multi-utilisateur

Android prend en charge plusieurs utilisateurs et offre une isolation complète des utilisateurs.

  • Les implémentations d'appareils PEUVENT, mais NE DOIVENT PAS activer le mode multi-utilisateur si elles utilisent un support amovible pour le stockage externe principal.

Si les implémentations d'appareils incluent plusieurs utilisateurs, elles :

  • [C-1-1] DOIT répondre aux exigences suivantes concernant la prise en charge du mode multi-utilisateur.
  • [C-1-2] DOIT, pour chaque utilisateur, implémenter un modèle de sécurité cohérent avec le modèle de sécurité de la plate-forme Android tel que défini dans 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'applications partagées distincts et isolés (également appelés /sdcard) pour chaque instance utilisateur.
  • [C-1-4] DOIT s'assurer que les applications appartenant à un utilisateur donné et s'exécutant 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 système de fichiers.
  • [C-1-5] DOIT chiffrer le contenu de la carte SD lorsque le mode multi-utilisateur est activé à l'aide d'une clé stockée uniquement sur un support non amovible accessible uniquement au système si les implémentations d'appareils utilisent un support amovible pour les API de stockage externe. Comme cela rendra le contenu multimédia illisible par un PC hôte, les implémentations d'appareils devront passer à MTP ou à un système similaire pour permettre aux PC hôtes d'accéder aux données de l'utilisateur actuel.

9.6. Avertissement concernant les SMS premium

Android permet d'avertir les utilisateurs de tout SMS surtaxé sortant. Les SMS premium sont des messages envoyés à un service enregistré auprès d'un opérateur et qui peuvent être facturés à l'utilisateur.

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

  • [C-1-1] 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 de l'appareil. 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 assurer 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) Security-Enhanced Linux (SELinux), le bac à sable seccomp et d'autres fonctionnalités de sécurité du noyau Linux. Implémentations sur les appareils :

  • [C-0-1] DOIT maintenir la compatibilité avec les applications existantes, même lorsque SELinux ou d'autres fonctionnalités de sécurité sont implémentées sous le framework Android.
  • [C-0-2] NE DOIT PAS comporter d'interface utilisateur visible lorsqu'une atteinte à la sécurité est détectée et bloquée par la fonctionnalité de sécurité implémentée sous le framework Android, mais PEUT comporter une interface utilisateur visible lorsqu'une atteinte à la sécurité non bloquée se produit et entraîne une exploitation réussie.
  • [C-0-3] NE DOIT PAS permettre à l'utilisateur ni au développeur d'application de configurer SELinux ni aucune autre fonctionnalité de sécurité implémentée en dessous du framework Android.
  • [C-0-4] NE DOIT PAS autoriser une application qui peut affecter une autre application via une API (telle qu'une API d'administration des appareils) à configurer une règle qui rompt la compatibilité.
  • [C-0-5] DOIT diviser le framework multimédia en plusieurs processus afin de pouvoir accorder un accès plus limité à 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 pour les applications du noyau qui permet de filtrer les appels système à l'aide d'une règle configurable à partir de programmes multithread. Le projet Android Open Source en amont répond à cette exigence en activant seccomp-BPF avec la synchronisation de groupe de threads (TSYNC), comme décrit dans la section "Configuration du noyau" de source.android.com.

L'intégrité et l'autoprotection du noyau font partie intégrante de la sécurité Android. Implémentations sur les appareils :

  • [C-0-7] DOIT implémenter des mécanismes de protection contre le dépassement de tampon de pile du noyau. (par exemple, CC_STACKPROTECTOR_REGULAR et CONFIG_CC_STACKPROTECTOR_STRONG).
  • [C-0-8] DOIT implémenter des protections strictes de la mémoire du noyau, où le code exécutable est en lecture seule, les données en lecture seule ne sont ni exécutables ni accessibles en écriture, et les données accessibles en écriture ne sont pas exécutables (par exemple, CONFIG_DEBUG_RODATA ou CONFIG_STRICT_KERNEL_RWX).
  • [C-0-9] DOIT implémenter la vérification des limites de taille des objets statiques et dynamiques des copies entre l'espace utilisateur et l'espace noyau (par exemple, CONFIG_HARDENED_USERCOPY) sur les appareils fournis à l'origine avec le niveau d'API 28 ou supérieur.
  • [C-0-10] NE DOIT PAS exécuter de mémoire de l'espace utilisateur lors de l'exécution en mode noyau (par exemple, PXN matériel ou émulation via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) sur les appareils fournis à l'origine avec le niveau d'API 28 ou supérieur.
  • [C-0-11] NE DOIT PAS lire ni écrire dans la mémoire de l'espace utilisateur du noyau en dehors des API d'accès usercopy normales (par exemple, PAN matériel ou émulation via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) sur les appareils fournis à l'origine avec le niveau d'API 28 ou supérieur.
  • [C-0-12] DOIT implémenter l'isolation des tables de pages du noyau si le matériel est vulnérable à CVE-2017-5754 sur tous les appareils fournis à l'origine avec le niveau d'API 28 ou supérieur (par exemple, CONFIG_PAGE_TABLE_ISOLATION ou CONFIG_UNMAP_KERNEL_AT_EL0).
  • [C-0-13] DOIT implémenter le renforcement de la prédiction de branchement si le matériel est vulnérable à CVE-2017-5715 sur tous les appareils fournis à l'origine avec le niveau d'API 28 ou supérieur (par exemple, CONFIG_HARDEN_BRANCH_PREDICTOR).
  • [SR] Il est FORTEMENT RECOMMANDÉ de conserver les données du noyau qui ne sont écrites que lors de l'initialisation en lecture seule après l'initialisation (par exemple, __ro_after_init).

  • [C-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 compromettraient la randomisation (par exemple, CONFIG_RANDOMIZE_BASE avec l'entropie du bootloader via /chosen/kaslr-seed Device Tree node ou EFI_RNG_PROTOCOL).

  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'activer l'intégrité du flux de contrôle (CFI) dans le noyau pour fournir une protection supplémentaire contre les attaques par réutilisation de code (par exemple, CONFIG_CFI_CLANG et CONFIG_SHADOW_CALL_STACK).

  • [C-SR] Il est FORTEMENT RECOMMANDÉ de ne pas désactiver l'intégrité du flux de contrôle (CFI), la pile d'appels fantôme (SCS) ni la désinfection des dépassements d'entiers (IntSan) sur les composants pour lesquels ces fonctionnalités sont activées.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'activer CFI, SCS et IntSan pour tous les composants d'espace utilisateur supplémentaires sensibles à la sécurité, comme expliqué dans CFI et IntSan.

Si les implémentations d'appareils utilisent un noyau Linux, elles :

  • [C-1-1] DOIT implémenter SELinux.
  • [C-1-2] DOIT définir SELinux sur le mode d'application forcée global.
  • [C-1-3] DOIT configurer tous les domaines en mode "Appliquer". Aucun domaine en mode permissif n'est autorisé, y compris les domaines spécifiques à un appareil ou à un fournisseur.
  • [C-1-4] Il NE DOIT 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 règle DOIT être compilée avec toutes les règles "neverallow" présentes, à la fois pour les domaines SELinux AOSP et pour les domaines spécifiques à l'appareil/au fournisseur.
  • [C-1-5] DOIT exécuter les applications tierces ciblant le niveau d'API 28 ou supérieur 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 Android Open Source en amont et ne l'étendre 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] par le biais d'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] DOIT utiliser un système de contrôle d'accès obligatoire équivalent à SELinux.

Android contient plusieurs fonctionnalités de défense en profondeur qui font partie intégrante de la sécurité des appareils.

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 sur les appareils :

  • [C-0-1] DOIT conserver un historique des utilisateurs pendant une période raisonnable.
  • [SR] Il est FORTEMENT RECOMMANDÉ de conserver la période de conservation de 14 jours telle qu'elle est 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 les API système StatsManager et IncidentManager.

Implémentations sur les appareils :

  • [C-0-2] MUST only include the fields marked with DEST_AUTOMATIC in the incident report created by the System API class IncidentManager.
  • [C-0-3] NE DOIT PAS utiliser les identifiants d'événements système pour consigner d'autres événements que ceux décrits dans la documentation du SDK StatsLog. Si des événements système supplémentaires sont enregistrés, ils PEUVENT utiliser un identifiant d'atome différent dans la plage comprise entre 100 000 et 200 000.

9.8.2. Enregistrement…

Implémentations sur les appareils :

  • [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, le rapport de bug) hors de l'appareil sans le consentement de l'utilisateur ni des notifications claires et continues.

  • [C-0-2] DOIT afficher et obtenir le consentement explicite de l'utilisateur, y compris un message sensiblement identique à celui d'AOSP, chaque fois que la diffusion ou l'enregistrement d'écran sont activés via MediaProjection ou des API propriétaires. NE DOIT PAS fournir aux utilisateurs un moyen de désactiver l'affichage futur du consentement de l'utilisateur.

  • [C-0-3] Une notification continue DOIT être affichée à l'utilisateur lorsque la diffusion ou l'enregistrement d'écran sont activés. AOSP répond à cette exigence en affichant une icône de notification continue dans la barre d'état.

Si les implémentations d'appareils incluent des fonctionnalités dans le système qui capturent le contenu affiché à l'écran et/ou enregistrent le flux audio lu sur l'appareil autrement que via l'API système ContentCaptureService ou d'autres moyens propriétaires décrits dans la section 9.8.6, Capture de contenu, elles :

  • [C-1-1] Une notification continue doit être affichée à l'utilisateur 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é prêt à l'emploi, capable d'enregistrer l'audio ambiant et/ou l'audio lu sur l'appareil 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é ou tout format pouvant être reconverti en audio d'origine ou en une copie presque identique, 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 sur les appareils :

  • [C-0-1] DOIT préinstaller les mêmes certificats racine pour le magasin d'autorité de certification (CA) approuvé par le système que ceux fournis dans le projet Android Open Source en amont.
  • [C-0-2] DOIT être livré avec un magasin d'autorité de certification racine utilisateur vide.
  • [C-0-3] DOIT afficher un avertissement à l'utilisateur 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, en préchargeant un service VPN avec l'autorisation android.permission.CONTROL_VPN), elles :

  • [C-2-1] DOIT demander le consentement de l'utilisateur avant d'activer ce mécanisme, sauf si le VPN est activé par le contrôleur de règles de l'appareil via DevicePolicyManager.setAlwaysOnVpnPackage(). Dans ce cas , l'utilisateur n'a pas besoin de fournir un consentement distinct, mais DOIT uniquement être averti.

Si les implémentations d'appareils implémentent une affordance utilisateur pour activer la fonction "VPN permanent" d'une application VPN tierce, elles :

  • [C-3-1] DOIT désactiver cette fonctionnalité 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.8.5. Identifiants des appareils

Implémentations sur les appareils :

  • [C-0-1] DOIT empêcher l'accès au numéro de série de l'appareil et, le cas échéant, à l'IMEI/MEID, au numéro de série de la carte SIM et à l'identité internationale d'abonné mobile (IMSI) depuis une application, sauf si elle répond à l'une des exigences suivantes :
    • est une application opérateur signée et validée par les fabricants d'appareils.
    • a reçu l'autorisation READ_PRIVILEGED_PHONE_STATE.
    • dispose de privilèges d'opérateur tels que définis dans UICC Carrier Privileges.
    • est le propriétaire de l'appareil ou du profil et dispose de l'autorisation READ_PHONE_STATE.
    • (Pour le numéro de série de la carte SIM/ICCID uniquement) est soumis aux réglementations locales qui exigent que l'application détecte les changements d'identité de l'abonné.

9.8.6. Capture de contenu

Android, via l'API système ContentCaptureService ou par d'autres moyens propriétaires, prend en charge un mécanisme permettant aux implémentations d'appareil de capturer les interactions suivantes entre les applications et l'utilisateur.

  • Texte et éléments graphiques affichés à l'écran, y compris, mais sans s'y limiter, les notifications et les données d'assistance via l'API AssistStructure.
  • Données multimédias, telles que les données audio ou vidéo enregistrées ou lues par l'appareil.
  • Événements d'entrée (par exemple, clavier, souris, geste, voix, vidéo et accessibilité).
  • Tout autre événement qu'une application fournit au système via l'API Content Capture ou une API propriétaire aux fonctionnalités similaires.

Si les implémentations d'appareil capturent les données ci-dessus, elles :

  • [C-1-1] DOIT chiffrer toutes ces données lorsqu'elles sont stockées dans l'appareil. Ce chiffrement PEUT être effectué à l'aide du chiffrement Android basé sur les fichiers ou de l'un des algorithmes de chiffrement listés pour la version 26 de l'API ou ultérieure, comme décrit dans Cipher SDK.
  • [C-1-2] NE DOIT PAS sauvegarder les données brutes ou chiffrées à l'aide des méthodes de sauvegarde Android ni d'aucune autre méthode de sauvegarde.
  • [C-1-3] DOIT uniquement envoyer toutes ces données et le journal de l'appareil à l'aide d'un mécanisme respectueux de la confidentialité. Le mécanisme de préservation de la confidentialité est défini comme "ceux qui n'autorisent que l'analyse agrégée et empêchent la mise en correspondance des événements enregistrés ou des résultats dérivés avec des utilisateurs individuels", afin d'empêcher toute introspection des données par utilisateur (par exemple, implémentée à l'aide d'une technologie de confidentialité différentielle telle que RAPPOR).
  • [C-1-4] NE DOIT PAS associer ces données à une identité utilisateur (telle que Account) sur l'appareil, sauf avec le consentement explicite de l'utilisateur chaque fois que les données sont associées.
  • [C-1-5] NE DOIT PAS partager ces données avec d'autres applications, sauf avec le consentement explicite de l'utilisateur à chaque fois qu'elles sont partagées.
  • [C-1-6] DOIT fournir à l'utilisateur la possibilité d'effacer les données collectées par ContentCaptureService ou par des moyens propriétaires si les données sont stockées sous quelque forme que ce soit sur l'appareil.

Si les implémentations d'appareils incluent un service qui implémente l'API System ContentCaptureService ou tout service propriétaire qui capture les données comme décrit ci-dessus, elles :

  • [C-2-1] NE DOIT PAS permettre aux utilisateurs de remplacer le service de capture de contenu par une application ou un service installable par l'utilisateur et NE DOIT autoriser que le service préinstallé à capturer ces données.
  • [C-2-2] NE DOIT PAS autoriser d'autres applications que le mécanisme de service de capture de contenu préinstallé à capturer ces données.
  • [C-2-3] DOIT fournir à l'utilisateur un moyen de désactiver le service de capture de contenu.
  • [C-2-4] NE DOIT PAS omettre la possibilité pour l'utilisateur de gérer les autorisations Android détenues par le service de capture de contenu et doit suivre le modèle d'autorisations Android décrit dans la section 9.1. Autorisation.

  • [C-SR] Il est FORTEMENT RECOMMANDÉ de conserver les composants du service de capture de contenu séparés, par exemple en ne liant pas le service ni en partageant les ID de processus, des autres composants du système, à l'exception des suivants :

    • Téléphonie, Contacts, UI système et Multimédia

9.8.7. Accès au presse-papiers

Implémentations sur les appareils :

  • [C-0-1] NE DOIT PAS renvoyer de données tronquées dans le presse-papiers (par exemple, via l'API ClipboardManager), sauf si l'application est l'IME par défaut ou l'application actuellement sélectionnée.

9.8.8. Position

Implémentations sur les appareils :

  • [C-0-1] NE DOIT PAS activer/désactiver les paramètres de localisation de l'appareil ni les paramètres de recherche Wi-Fi/Bluetooth sans le consentement explicite de l'utilisateur ou sans que l'utilisateur en soit à l'origine.
  • [C-0-2] DOIT fournir à l'utilisateur un moyen d'accéder aux informations liées à la localisation, y compris les demandes de localisation récentes, les autorisations au niveau de l'application et l'utilisation du scan Wi-Fi/Bluetooth pour déterminer la position.
  • [C-0-3] DOIT s'assurer que l'application utilisant l'API Emergency Location Bypass [LocationRequest.setLocationSettingsIgnored()] est une session d'urgence initiée par l'utilisateur (par exemple, appel ou message au 112).
  • [C-0-4] DOIT préserver la capacité de l'API Emergency Location Bypass à contourner les paramètres de localisation de l'appareil sans les modifier.
  • [C-0-5] DOIT planifier une notification qui rappelle à l'utilisateur qu'une application en arrière-plan a accédé à sa position à l'aide de l'autorisation [ACCESS_BACKGROUND_LOCATION].

9.9. Chiffrement du stockage des données

Tous les appareils DOIVENT répondre aux exigences de la section 9.9.1. Les appareils lancés avec un niveau d'API antérieur à celui de ce document sont exemptés des exigences des sections 9.9.2 et 9.9.3. Ils DOIVENT en revanche répondre aux exigences de la section 9.9 du document de définition de compatibilité Android correspondant au niveau d'API avec lequel l'appareil a été lancé.

9.9.1. Démarrage direct

Implémentations sur les appareils :

  • [C-0-1] DOIT implémenter les API du mode Démarrage direct, même si elles ne sont pas compatibles avec le chiffrement du 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és par l'appareil (DE) et chiffrés par les identifiants (CE) sont disponibles pour l'utilisateur.

9.9.2. Exigences de chiffrement

Implémentations sur les appareils :

  • [C-0-1] DOIT chiffrer les données privées de l'application (partition /data), ainsi que la partition de stockage partagé de l'application (partition /sdcard) si elle constitue une partie permanente et non amovible de l'appareil.
  • [C-0-2] DOIT activer le chiffrement du stockage des données par défaut une fois que l'utilisateur a terminé la configuration initiale.
  • [C-0-3] DOIT répondre aux exigences de chiffrement du stockage de données ci-dessus en implémentant le chiffrement basé sur les fichiers (FBE, File Based Encryption).

9.9.3. Chiffrement basé sur les fichiers

Appareils chiffrés :

  • [C-1-1] DOIT démarrer sans demander d'identifiants à l'utilisateur 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 autoriser l'accès au stockage chiffré par identifiants (CE, Credential Encrypted) uniquement après que l'utilisateur a déverrouillé l'appareil en fournissant ses identifiants (par exemple, un code secret, un code PIN, un schéma ou une empreinte digitale) et que le message ACTION_USER_UNLOCKED a été diffusé.
  • [C-1-3] NE DOIT PAS proposer de méthode pour déverrouiller l'espace de stockage protégé par CE sans les identifiants fournis par l'utilisateur ni une clé de dépôt enregistrée.
  • [C-1-4] DOIT utiliser le démarrage validé et s'assurer que les clés de chiffrement du disque sont liées cryptographiquement à la racine de confiance matérielle de l'appareil.
  • [C-1-5] DOIT chiffrer le contenu des fichiers à l'aide d'AES-256-XTS ou d'Adiantum. AES-256-XTS fait référence à la norme Advanced Encryption Standard avec une longueur de clé de chiffrement de 256 bits, fonctionnant en mode XTS. La longueur totale de la clé est de 512 bits. Adiantum fait référence à Adiantum-XChaCha12-AES, comme indiqué sur https://github.com/google/adiantum.
  • [C-1-6] DOIT chiffrer les noms de fichiers à l'aide d'AES-256-CBC-CTS ou d'Adiantum.

  • [C-1-12] DOIT utiliser AES-256-XTS pour le contenu des fichiers et AES-256-CBC-CTS pour les noms de fichiers (au lieu d'Adiantum) si l'appareil dispose d'instructions AES (Advanced Encryption Standard). Les instructions AES sont des extensions de chiffrement ARMv8 sur les appareils basés sur ARM ou AES-NI sur les appareils basés sur x86. Si l'appareil ne dispose pas d'instructions AES, il PEUT utiliser Adiantum.

  • Clés protégeant les zones de stockage CE et DE :

  • [C-1-7] DOIT être lié de manière cryptographique à un Keystore avec support matériel.

  • [C-1-8] Les clés CE DOIVENT être associées aux identifiants de l'écran de verrouillage d'un utilisateur.
  • [C-1-9] Les clés CE DOIVENT être lié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. En d'autres termes, la clé CE ou DE d'un utilisateur ne doit correspondre à la clé CE ou DE d'aucun autre utilisateur.
  • [C-1-11] DOIT utiliser les modes, les longueurs de clé et les algorithmes de chiffrement obligatoirement pris en charge.

  • [C-SR] Il est FORTEMENT RECOMMANDÉ de chiffrer les métadonnées du système de fichiers, telles que la taille, la propriété, les modes et les attributs étendus (xattrs) des fichiers, 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 (par exemple, Alarme, Téléphone, Messenger) compatibles avec le démarrage direct.

Le projet Android Open Source en amont fournit une implémentation privilégiée de cette fonctionnalité basée sur la fonctionnalité de chiffrement "fscrypt" 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 sur les appareils :

  • [C-0-1] DOIT indiquer correctement via la méthode PersistentDataBlockManager.getFlashLockState() de l'API System 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 qui effectuent une mise à niveau à partir d'une version antérieure d'Android où cette nouvelle méthode d'API système n'existait pas.

  • [C-0-2] DOIT prendre en charge le démarrage sécurisé pour l'intégrité de l'appareil.

Si des implémentations d'appareils sont déjà lancées sans prise en charge du démarrage validé sur une version antérieure d'Android et qu'il est impossible d'ajouter la prise en charge de cette fonctionnalité avec une mise à jour du logiciel 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 d'appareil sont compatibles avec la fonctionnalité, elles :

  • [C-1-1] DOIT déclarer le commutateur de fonctionnalité de la plate-forme android.software.verified_boot.
  • [C-1-2] DOIT effectuer une vérification à chaque séquence de démarrage.
  • [C-1-3] DOIT commencer la validation à partir d'une clé matérielle immuable qui est la racine de confiance et aller jusqu'à la partition système.
  • [C-1-4] DOIT implémenter chaque étape de validation 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 puissants que les recommandations actuelles du NIST pour les algorithmes de hachage (SHA-256) et les tailles de clés publiques (RSA-2048).
  • [C-1-6] NE DOIT PAS autoriser le démarrage à se terminer en cas d'échec de la validation du système, sauf si l'utilisateur accepte de tenter le démarrage quand même, auquel cas les données des blocs de stockage non validés NE DOIVENT PAS être utilisées.
  • [C-1-7] 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 comporte plusieurs puces distinctes (par exemple, une puce radio ou 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.
  • [C-1-8] DOIT utiliser un stockage inviolable : pour stocker si le bootloader est déverrouillé. Le stockage inviolable signifie que le bootloader peut détecter si le stockage a été falsifié depuis Android.
  • [C-1-9] DOIT inviter l'utilisateur à confirmer physiquement la transition du mode bootloader verrouillé au mode bootloader déverrouillé pendant l'utilisation de 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 autorisée de l'OS.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de valider tous les fichiers APK des applications privilégiées avec une chaîne de confiance ancrée dans les partitions protégées par le démarrage validé.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de valider tout artefact exécutable chargé par une application privilégiée en dehors de son fichier APK (comme du code chargé dynamiquement ou du code compilé) avant de l'exécuter, ou FORTEMENT RECOMMANDÉ de ne pas l'exécuter du tout.
  • DOIT implémenter une protection contre la restauration pour tout composant avec un micrologiciel persistant (par exemple, le modem ou la 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 des 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'il est impossible d'ajouter la prise en charge de 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 sur les appareils :

Si les implémentations d'appareils 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 code s'exécutant dans l'OS Android, y compris son noyau, malveillant ou non, ne peut pas générer de réponse positive sans interaction de l'utilisateur.

  • [C-3-3] DOIT s'assurer que l'utilisateur a pu examiner et approuver le message affiché, même si l'OS Android, y compris son noyau, est compromis.

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 sur les appareils :

  • [C-0-1] DOIT permettre d'importer ou de générer au moins 8 192 clés.
  • [C-0-2] L'authentification sur l'écran de verrouillage DOIT limiter le nombre de tentatives et DOIT utiliser un algorithme d'intervalle exponentiel entre les tentatives. 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] DOIT sauvegarder l'implémentation du keystore avec un environnement d'exécution isolé.
  • [C-1-2] DOIT implémenter les algorithmes de chiffrement RSA, AES, ECDSA et HMAC, ainsi que les fonctions de hachage de la famille MD5, SHA1 et SHA-2 pour prendre correctement en charge les algorithmes compatibles du système Android Keystore dans une zone sécurisée et isolée du code s'exécutant 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 pourrait 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 d'autres solutions basées sur ARM TrustZone ou une implémentation sécurisée tierce et examinée d'une isolation appropriée basée sur un hyperviseur sont également possibles.
  • [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 qu'en cas de succès. Les identifiants de l'écran de verrouillage DOIVENT être stockés de manière à ce que seul l'environnement d'exécution isolé puisse 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 de l'attestation est protégée par du matériel sécurisé et que la signature est effectuée dans du matériel sécurisé. Les clés de signature d'attestation DOIVENT être partagées sur un nombre d'appareils suffisamment important pour empêcher 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.

Notez que si une implémentation d'appareil est déjà lancée sur une version antérieure d'Android, cet appareil est exempté de l'obligation d'avoir un keystore soutenu par un environnement d'exécution isolé et de prendre en charge l'attestation de clé, sauf s'il déclare la fonctionnalité android.hardware.fingerprint qui nécessite un keystore soutenu par un environnement d'exécution isolé.

  • [C-1-5] DOIT permettre à l'utilisateur de choisir le délai d'inactivité pour passer de l'état déverrouillé à l'état verrouillé, avec un délai d'inactivité minimal autorisé de 15 secondes.

9.11.1. Écran de verrouillage sécurisé et authentification

L'implémentation AOSP suit un modèle d'authentification à plusieurs niveaux, dans lequel une authentification principale basée sur un facteur de connaissance peut être soutenue par une authentification biométrique secondaire forte ou par des modalités tertiaires plus faibles.

Implémentations sur les appareils :

  • [C-SR] Il est FORTEMENT RECOMMANDÉ de définir une seule des méthodes d'authentification suivantes comme méthode principale :
    • Un code numérique
    • Un mot de passe alphanumérique
    • Un schéma de balayage sur une grille de 3 x 3 points

Notez que les méthodes d'authentification ci-dessus sont appelées 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 comme moyen sécurisé de verrouiller l'écran, la nouvelle méthode d'authentification :

Si les implémentations d'appareils 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 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 les méthodes d'authentification principales recommandées (c'est-à-dire le code, le schéma ou le 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 Device Policy Controller (DPC) a défini la règle de qualité du mot de passe via la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_SOMETHING.
  • [C-3-5] Les nouvelles méthodes d'authentification DOIVENT revenir aux méthodes d'authentification principales recommandées (c'est-à-dire le code, le schéma ou le mot de passe) au moins une fois toutes les 72 heures OU indiquer clairement à l'utilisateur que certaines données ne seront pas sauvegardées afin de préserver la confidentialité de ses données.

Si les implémentations d'appareils ajoutent ou modifient les méthodes d'authentification principale 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ées comme un moyen sécurisé de verrouiller l'écran, la nouvelle méthode :

  • [C-4-1] DOIT répondre à toutes les exigences décrites dans la section 7.3.10 pour la catégorie Convenience.
  • [C-4-2] DOIT disposer d'un mécanisme de secours pour utiliser l'une des méthodes d'authentification principale recommandées, qui repose sur un secret connu.
  • [C-4-3] DOIT être désactivé et n'autoriser que l'authentification principale recommandée pour déverrouiller l'écran lorsque l'application Device Policy Controller (DPC) a défini la règle de fonctionnalité keyguard en appelant la méthode DevicePolicyManager.setKeyguardDisabledFeatures(), avec l'un des indicateurs biométriques associés (c'est-à-dire KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE ou KEYGUARD_DISABLE_IRIS).

Si les méthodes d'authentification biométrique ne répondent pas aux exigences de la catégorie Forte décrites dans la section 7.3.10 :

  • [C-5-1] Les méthodes DOIVENT être désactivées si l'application Device Policy Controller (DPC) a défini la règle 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é à utiliser la méthode d'authentification principale recommandée (par exemple, code, schéma ou mot de passe) après toute période d'inactivité de quatre heures. Le délai d'inactivité est réinitialisé après toute confirmation réussie 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 répondre aux exigences commençant par C-8 dans la section ci-dessous.

Si les implémentations d'appareils 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 secours pour utiliser l'une des méthodes d'authentification principale recommandées, qui est basée sur un secret connu et répond aux exigences pour être traitée comme un écran de verrouillage sécurisé.
  • [C-6-2] La nouvelle méthode DOIT être désactivée et n'autoriser qu'une seule des méthodes d'authentification principale recommandées pour déverrouiller l'écran lorsque l'application Device Policy Controller (DPC) a défini la règle 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 principale recommandées (par exemple, code, schéma, mot de passe) au moins une fois toutes les quatre heures ou moins.
  • [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] Une indication claire doit figurer dans le menu des paramètres et sur l'écran de verrouillage lorsque le verrouillage de l'appareil est différé ou peut être maintenu déverrouillé par des agents de confiance. Par exemple, l'AOSP répond à cette exigence en affichant une description textuelle pour les paramètres "Verrouillage automatique" et "Verrouillage instantané avec le bouton Marche/Arrêt" dans le menu des paramètres, ainsi qu'une icône distinctive sur l'écran de verrouillage.
  • [C-7-2] DOIT respecter et implémenter entièrement toutes les API d'agent de confiance de la classe DevicePolicyManager, telles que la constante KEYGUARD_DISABLE_TRUST_AGENTS.
  • [C-7-3] NE DOIT PAS implémenter entièrement la fonction TrustAgentService.addEscrowToken() sur un appareil utilisé comme appareil personnel principal (par exemple, un appareil mobile), mais PEUT implémenter entièrement la fonction sur les implémentations d'appareils qui sont généralement partagées (par exemple, un appareil Android TV ou automobile).
  • [C-7-4] DOIT chiffrer tous les jetons stockés ajoutés par TrustAgentService.addEscrowToken().
  • [C-7-5] NE DOIT PAS stocker la clé de chiffrement ni le jeton de séquestre sur le même appareil que celui sur lequel la clé est utilisée. Par exemple, une clé stockée sur un téléphone peut être autorisée à déverrouiller un compte utilisateur sur un téléviseur.
  • [C-7-6] DOIT informer l'utilisateur des implications en termes de sécurité avant d'activer le jeton de séquestre pour déchiffrer le stockage de données.
  • [C-7-7] DOIT disposer d'un mécanisme de secours 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 principale recommandées (par exemple, code, schéma, mot de passe) au moins une fois toutes les 72 heures ou moins, sauf si la sécurité de l'utilisateur (par exemple, distraction du conducteur) est préoccupante.
  • [C-7-9] L'utilisateur DOIT être invité à utiliser l'une des méthodes d'authentification principale recommandées (par exemple, code, schéma ou mot de passe) après toute période d'inactivité de quatre heures, sauf si la sécurité de l'utilisateur est en jeu (par exemple, distraction du conducteur). Le délai d'inactivité est réinitialisé après toute confirmation réussie 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.
  • [C-7-11] NE DOIT PAS autoriser les TrustAgents sur les appareils personnels principaux (par exemple, les appareils portables) à déverrouiller l'appareil.Ils ne peuvent être utilisés que pour maintenir un appareil déjà déverrouillé dans cet état pendant une durée maximale de quatre heures. L'implémentation par défaut de TrustManagerService dans AOSP répond à cette exigence.
  • [C-7-12] DOIT utiliser un canal de communication cryptographiquement sécurisé (par exemple, UKEY2) pour transmettre le jeton de dépôt de garantie du périphérique de stockage à l'appareil cible.

Si les implémentations d'appareils ajoutent ou modifient les méthodes d'authentification pour déverrouiller l'écran de verrouillage qui n'est pas un écran de verrouillage sécurisé comme décrit ci-dessus, et utilisent une nouvelle méthode d'authentification pour déverrouiller le keyguard :

  • [C-8-1] La nouvelle méthode DOIT être désactivée lorsque l'application Device Policy Controller (DPC) a défini la règle de qualité du mot de passe via la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_UNSPECIFIED.
  • [C-8-2] Ils NE DOIVENT PAS réinitialiser les minuteurs d'expiration des mots de passe définis par DevicePolicyManager.setPasswordExpirationTimeout().
  • [C-8-3] Elles NE DOIVENT PAS exposer d'API permettant aux applications tierces de modifier l'état de la serrure.

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. Ce processeur sécurisé dédié est appelé "StrongBox". Les exigences C-1-3 à C-1-11 ci-dessous définissent les exigences auxquelles un appareil DOIT répondre pour être considéré comme une StrongBox.

Implémentations d'appareils dotés d'un processeur sécurisé dédié :

  • [C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge StrongBox. StrongBox deviendra probablement une exigence dans une prochaine version.

Si les implémentations d'appareils sont compatibles avec StrongBox, elles :

  • [C-1-1] Vous DEVEZ déclarer FEATURE_STRONGBOX_KEYSTORE.

  • [C-1-2] DOIT fournir un matériel sécurisé dédié utilisé pour le keystore et l'authentification sécurisée des utilisateurs. Le matériel sécurisé dédié peut également être utilisé à d'autres fins.

  • [C-1-3] DOIT disposer d'un processeur distinct qui ne partage pas de cache, de DRAM, de coprocesseurs ni d'autres ressources de base avec le processeur d'application (AP).

  • [C-1-4] DOIT s'assurer que les périphériques partagés avec l'AP ne peuvent en aucun cas modifier le traitement StrongBox ni obtenir d'informations de StrongBox. L'AP PEUT désactiver ou bloquer l'accès à StrongBox.

  • [C-1-5] DOIT disposer d'une horloge interne d'une précision raisonnable (± 10 %) et à l'abri de toute manipulation par le PA.

  • [C-1-6] DOIT disposer d'un véritable générateur de nombres aléatoires qui produit des résultats imprévisibles et uniformément répartis.

  • [C-1-7] DOIT être résistant à la falsification, y compris à la pénétration physique et aux problèmes techniques.

  • [C-1-8] DOIT être résistant aux canaux auxiliaires, y compris aux fuites d'informations via les canaux auxiliaires de puissance, de timing, de rayonnement électromagnétique et de rayonnement thermique.

  • [C-1-9] MUST have secure storage which ensures confidentiality, integrity, authenticity, consistency, and freshness of the contents. Le stockage NE DOIT PAS pouvoir être lu ni modifié, sauf dans les limites autorisées par les API StrongBox.

  • Pour valider la conformité avec les sections [C-1-3] à [C-1-9], les implémentations d'appareils doivent :

    • [C-1-10] DOIT inclure le matériel certifié conforme au profil de protection Secure IC BSI-CC-PP-0084-2014 ou évalué par un laboratoire d'essai accrédité au niveau national intégrant une évaluation de la vulnérabilité à fort potentiel d'attaque conformément à l'application des critères communs du potentiel d'attaque aux cartes à puce.
    • [C-1-11] DOIT inclure le micrologiciel évalué par un laboratoire d'essai accrédité au niveau national intégrant une évaluation de la vulnérabilité à fort potentiel d'attaque conformément à l'application des critères communs 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] Il est FORTEMENT RECOMMANDÉ de fournir une protection contre les attaques internes (IAR, Insider Attack Resistance). Cela signifie qu'un employé ayant accès aux clés de signature du micrologiciel ne peut pas produire un micrologiciel qui provoque la fuite de secrets par StrongBox, contourne les exigences de sécurité fonctionnelles ou permet d'accéder à des données utilisateur sensibles. La méthode recommandée pour implémenter IAR consiste à autoriser les mises à jour du micrologiciel uniquement lorsque le mot de passe de l'utilisateur principal est fourni via IAuthSecret HAL.

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] DOIT supprimer toutes les données du système de fichiers userdata.
  • [C-0-3] DOIT supprimer les données de manière à respecter les normes sectorielles pertinentes, telles que NIST SP800-88.
  • [C-0-4] DOIT déclencher la procédure de réinitialisation des données d'usine ci-dessus lorsque l'API DevicePolicyManager.wipeData() est appelée par l'application Device Policy Controller de l'utilisateur principal.
  • PEUT proposer une option d'effacement rapide des données qui n'effectue qu'un effacement logique des données.

9.13. Mode démarrage sécurisé

Android propose un mode de démarrage sécurisé qui permet aux utilisateurs de démarrer l'appareil dans un mode où seules les applications système préinstallées sont autorisées à s'exécuter et où toutes les applications tierces sont désactivées. Ce mode, appelé "mode sans échec", permet à l'utilisateur de désinstaller les applications tierces potentiellement dangereuses.

Les implémentations d'appareils sont les suivantes :

  • [SR] Il est FORTEMENT RECOMMANDÉ d'implémenter le mode Démarrage sécurisé.

Si les implémentations d'appareils implémentent le mode Safe Boot, elles :

  • [C-1-1] DOIT fournir à l'utilisateur une option permettant d'accéder au 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 règles relatives aux appareils et que l'indicateur UserManager.DISALLOW_SAFE_BOOT est défini sur "true".

  • [C-1-2] DOIT permettre à l'utilisateur de désinstaller les applications tierces en mode sans échec.

  • DOIT fournir à l'utilisateur une option permettant d'accéder au mode sans échec à 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 sont censés échanger des données avec les sous-systèmes critiques du véhicule à l'aide de la 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 empêcher toute interaction malveillante ou involontaire avec ces sous-systèmes.

9.15. Abonnements

Les "forfaits d'abonnement" font référence aux 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 de l'opérateur mobile qui les a fournis à l'origine.
  • [C-0-2] NE DOIT PAS sauvegarder ni importer à distance des forfaits d'abonnement.
  • [C-0-3] DOIT uniquement autoriser les remplacements, tels que SubscriptionManager.setSubscriptionOverrideCongested(), à partir de l'application de l'opérateur mobile qui fournit actuellement des forfaits 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 entièrement exhaustif. C'est pourquoi il est FORTEMENT RECOMMANDÉ aux développeurs d'appareils de modifier le moins possible l'implémentation de référence et préférée d'Android disponible dans le projet Android Open Source. Cela permet de minimiser 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 sur les appareils :

  • [C-0-1] DOIT réussir la suite de tests de compatibilité (CTS) Android disponible sur le projet Android Open Source, en utilisant le logiciel final fourni 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 CTS sera versionnée indépendamment de cette définition de compatibilité, et plusieurs révisions de la CTS pourront être publiées pour Android 10.

Implémentations sur les appareils :

  • [C-0-3] DOIT réussir la dernière version CTS disponible au moment où le logiciel de l'appareil est terminé.

  • DOIT utiliser l'implémentation de référence dans l'arborescence Android Open Source autant que possible.

10.2. Vérificateur CTS

CTS Verifier est inclus dans la suite de tests de compatibilité. Il est conçu pour être exécuté par un opérateur humain afin de 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 sur les appareils :

  • [C-0-1] DOIT exécuter correctement tous les cas applicables dans le CTS Verifier.

Le CTS Verifier comporte des tests pour de nombreux types de matériel, y compris certains matériels optionnels.

Implémentations sur les appareils :

  • [C-0-2] DOIT réussir tous les tests pour le 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 CTS Verifier.

Les cas de test pour les fonctionnalités indiquées comme facultatives par le présent document de définition de compatibilité PEUVENT être ignorés ou omis.

  • [C-0-2] Chaque appareil et chaque compilation DOIVENT exécuter correctement le CTS Verifier, comme indiqué ci-dessus. Toutefois, comme de nombreuses compilations sont très similaires, les responsables de l'implémentation des appareils ne sont pas censés exécuter explicitement le CTS Verifier sur les compilations qui ne diffèrent que de manière triviale. Plus précisément, les implémentations d'appareils qui diffèrent d'une implémentation ayant réussi le test CTS Verifier uniquement par l'ensemble des paramètres régionaux inclus, la marque, etc. PEUVENT omettre le test CTS Verifier.

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 des mises à niveau "en direct", c'est-à-dire qu'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é des logiciels préinstallés sur l'appareil. Par exemple, l'une des approches suivantes répondra à cette exigence :

    • Téléchargements "Over-the-air (OTA)" avec mise à jour hors connexion via le redémarrage.
    • Mises à jour "ancrées" via USB depuis un PC hôte.
    • Mises à jour "hors connexion" via un redémarrage et une mise à jour à partir d'un fichier sur un espace de stockage amovible.

  • [C-0-2] Le mécanisme de mise à jour utilisé DOIT permettre les mises à jour sans effacer les données utilisateur. En d'autres termes, 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.

  • [C-0-3] L'intégralité de la mise à jour DOIT être signée, et le mécanisme de mise à jour sur l'appareil DOIT vérifier la mise à jour et la signature par rapport à une clé publique stockée sur l'appareil.

  • [C-SR] Il est FORTEMENT RECOMMANDÉ que le mécanisme de signature hache la mise à jour avec SHA-256 et valide le hachage par rapport à la clé publique à l'aide d'ECDSA NIST P-256.

Si les implémentations d'appareils incluent la prise en charge d'une connexion de données illimitée telle que le profil 802.11 ou 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 et versions ultérieures, 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 des 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 être compatibles avec 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 sortie, mais pendant sa durée de vie raisonnable déterminée en concertation avec l'équipe de compatibilité Android, et qu'elle affecte la compatibilité des applications tierces :

  • [C-2-1] L'intégrateur de l'appareil DOIT corriger l'erreur via une mise à jour logicielle disponible qui peut être appliquée selon le mécanisme décrit ci-dessus.

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, cela signifie que :

12. Journal des modifications des documents

Pour obtenir un résumé des modifications apportées à la définition de compatibilité dans cette version :

Pour obtenir un résumé des modifications apportées aux sections concernant les particuliers :

  1. Introduction
  2. Types d'appareils
  3. Logiciels
  4. Packaging 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 consulter le journal des modifications

Les modifications sont indiquées comme suit :

  • CDD
    Modifications importantes apportées aux exigences de compatibilité.

  • Docs
    Modifications esthétiques ou liées à la compilation.

Pour une expérience optimale, ajoutez les paramètres d'URL pretty=full et no-merges à vos URL de journaux des modifications.

13. Nous contacter

Vous pouvez rejoindre le forum sur la compatibilité Android pour demander des éclaircissements ou signaler tout problème qui, selon vous, n'est pas abordé dans le document.