Journal des modifications du document de définition de compatibilité Android

Android 14

26 juin 2024

2. Types d'appareils

  • 2.2.1. Matériel:

    Voir la révision

    • [7.6.1/H-1-1] DOIT ne prendre en charge qu'une seule ABI (64 bits uniquement ou 32 bits uniquement).

    Voir la révision

    Commencer les nouvelles exigences

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

  • 2.4.1. Matériel:

    Voir la révision

    Commencer les nouvelles exigences

    Si les implémentations d'appareils de la montre sont compatibles avec Vulkan, elles:

  • 2.5.1. Matériel:

    Voir la révision

    Commencer les nouvelles exigences

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

3. Logiciel

  • 3.2.2. Paramètres de compilation:

    Pour le paramètre ODM_SKU:

    Voir la révision

    La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre à l'expression régulière ^([0-9A-Za-z.,_-]+)$.

5. Compatibilité multimédia

  • 5.1.3. Détails du codecs audio

    Ajout d'informations sur le format/codec Vorbis:

    Voir la révision

    Décodage: prise en charge des contenus mono, stéréo, 5.0 et 5.1 avec des taux d'échantillonnage de 8 000, 12 000, 16 000, 24 000 et 48 000 Hz.
    Encodage: prise en charge des contenus mono et stéréo avec des taux d'échantillonnage de 8 000, 12 000, 0 Hz, 0 et 2

7. Compatibilité matérielle

  • 7.1.4.2 Vulkan:

    Voir la révision

  • 7.7.1. Mode périphérique USB:

    Suppression des éléments suivants:

    Voir la révision

    • NE DEVRAIT PAS implémenter l'audio AOAv2 documenté dans la documentation du protocole Android Open Accessory 2.0. L'audio AOAv2 est obsolète à partir de la version Android 8.0 (niveau d'API 26).

9. Compatibilité des modèles de sécurité

  • 9.7. Fonctionnalité de sécurité:

    [C-SR-1] a été renuméroté en [C-SR-7] pour supprimer le contenu en double et [C-SR-8] a été supprimé :

    Voir la révision

    • [C-SR-1] VIVEMENT RECOMMANDÉ pour conserver les données du noyau qui ne sont écrites que lors de l'initialisation marquées en lecture seule après l'initialisation (par exemple, __ro_after_init).

    • [C-SR-2] EST FORTEMENT RECOMMANDÉ pour randomiser la mise en page du code du noyau et de la mémoire, et pour éviter toute exposition qui pourrait compromettre 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-3] Il est FORTEMENT RECOMMANDÉ d'activer l'intégrité du flux de contrôle (CFI) dans le noyau afin de fournir une protection supplémentaire contre les attaques de réutilisation de code (par exemple, CONFIG_CFI_CLANG et CONFIG_SHADOW_CALL_STACK).

    • [C-SR-4] Il est FORTEMENT RECOMMANDÉ de ne pas désactiver Control-Flow Integrity (CFI), Shadow Call Stack (SCS) ou Integer Overflow Sanitization (IntSan) sur les composants pour lesquels ils sont activés.

    • [C-SR-5] 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.

    • [C-SR-6] Il est FORTEMENT RECOMMANDÉ d'activer l'initialisation de la pile dans le noyau afin d'empêcher l'utilisation de variables locales non initialisées (CONFIG_INIT_STACK_ALL ou CONFIG_INIT_STACK_ALL_ZERO). De plus, les implémentations d'appareils NE DOIVENT PAS supposer la valeur utilisée par le compilateur pour initialiser les paramètres locaux.

    • [C-SR-7] Il est FORTEMENT RECOMMANDÉ d'activer l'initialisation du tas de mémoire dans le noyau afin d'empêcher l'utilisation d'allocations de segments de mémoire non initialisés (CONFIG_INIT_ON_ALLOC_DEFAULT_ON). Il NE DOIT PAS supposer la valeur utilisée par le noyau pour initialiser ces allocations.

  • 9.11. Clés et identifiants:

    Voir la révision

    • [C-1-6] DOIT être compatible avec l'un des éléments suivants :
      • IKeymasterDevice 3.0,
      • IKeymasterDevice 4.0,
      • IKeymasterDevice 4.1,
      • IKeyMintDevice version 1 ou
      • IKeyMintDevice version 2.

  • 9.11.1. Écran de verrouillage sécurisé, authentification et appareils virtuels :

    Voir la révision

    • [C-8-3] Ils NE DOIVENT PAS exposer d'API permettant à des applications tierces de modifier l'état de verrouillage.

    Voir la révision

    • [C-12-4] DOIT appeler TrustManagerService.revokeTrust()
      • 24 heures maximum à compter de l'octroi de l'approbation ; ou
      • après une période d'inactivité de 8 heures ;
      • Si les implémentations n'utilisent pas de plages exactes et sécurisées de manière cryptographique, comme défini dans [C-12-5], la connexion sous-jacente à l'appareil physique à proximité est perdue.
    • [C-12-5] Les implémentations qui reposent sur une mesure de plage précise et sécurisée pour répondre aux exigences du [C-12-4] DOIVENT utiliser l'une des solutions suivantes :
      • Implémentations utilisant l'UWB :
        • DOIT répondre aux exigences de conformité, de certification, de précision et d'étalonnage pour la UWB décrites dans la section 7.4.9.
        • DOIT utiliser l'un des modes de sécurité P-STS énumérés dans la section 7.4.9.
      • Implémentations utilisant le réseau Wi-Fi Neighborhood Awareness (NAN) :
        • DOIT répondre aux exigences de précision spécifiées dans la section 2.2.1 [7.4.2.5/H-SR-1], utiliser la bande passante de 160 MHz (ou plus) et suivre les étapes de configuration de la mesure spécifiées dans Étalonnage de présence.
        • DOIT utiliser un LTF sécurisé tel que défini dans la norme IEEE 802.11az.

8 avril 2024

2. Types d'appareils

  • 2.2.1. Matériel:

    Voir la révision

    Commencer les nouvelles exigences

    Si les implémentations d'appareils portables déclarent FEATURE_BLUETOOTH_LE, elles:

    • [7.4.3/H-1-3] DOIT mesurer et compenser le décalage Rx pour s'assurer que le RSSI BLE médian est de -50 dBm +/-15 dB à 1 m de distance d'un appareil de référence émettant à ADVERTISE_TX_POWER_HIGH.
    • [7.4.3/H-1-4] DOIT mesurer et compenser le décalage Tx pour s'assurer que le RSSI BLE médian est de -50 dBm à +/-15 dB lors de la recherche depuis un appareil de référence situé à 1 m de distance et en transmettant à ADVERTISE_TX_POWER_HIGH.

  • 2.2.5. Modèle de sécurité:

    Voir la révision

    Si les implémentations d'appareils portables sont compatibles avec l'API système HotwordDetectionService ou un autre mécanisme de détection de mot clé sans indication d'accès au micro, elles:

    • [9.8/H-1-6] NE DOIT PAS autoriser la transmission de plus de 100 octets de données en dehors du service de détection de mots clés pour chaque résultat de mot clé réussi, à l'exception des données audio transmises via HotwordAudioStream.

    Voir la révision

    Remplacez [9.8/H-1-13] par:

    • [9.8/H-SR-3] Il est FORTEMENT RECOMMANDÉ de redémarrer le processus hébergeant le service de détection de mots clés au moins une fois par heure ou tous les 30 événements déclenchés par le matériel, selon la première échéance atteinte.

    Voir la révision

    Suppression des exigences [9.8.2/H-4-3], [9.8.2/H-4-4], [9.8.2/H-5-3].

  • 2.2.7.2. Appareil photo:

    Voir la révision

    Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.U pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, les conditions suivantes s'appliquent:

    • [7.5/H-1-3] DOIT prendre en charge la propriété android.info.supportedHardwareLevel avec une valeur FULL ou supérieure pour la caméra principale arrière et LIMITED ou supérieure pour la caméra principale avant.

  • 2.3.2. Multimédia:

    Voir la révision

    Si les téléviseurs ne disposent pas d'un écran intégré, mais sont compatibles avec un écran externe connecté via HDMI, ils:

    • [5.8/T-0-1] DOIT définir le mode de sortie HDMI sur la résolution la plus élevée pour le format de pixel choisi, qui fonctionne avec une fréquence d'actualisation de 50 Hz ou 60 Hz pour l'écran externe, en fonction de la fréquence d'actualisation vidéo pour la région dans laquelle l'appareil est vendu. DOIT définir le mode de sortie HDMI pour sélectionner la résolution maximale compatible avec une fréquence d'actualisation de 50 Hz ou de 60 Hz.

3. Logiciel

5. Compatibilité multimédia

  • 5.3.8. Dolby Vision:

    Voir la révision

    Si les implémentations d'appareils déclarent être compatibles avec le décodeur Dolby Vision via HDR_TYPE_DOLBY_VISION, elles:

    • [C-1-3] DOIT définir l'ID de piste des couches de base rétrocompatibles (le cas échéant) de sorte qu'il soit identique à celui de la couche Dolby Vision combinée.

7. Compatibilité matérielle

  • 7.1.1.1. Taille et forme de l'écran:

    Voir la révision

    Si les implémentations d'appareils sont compatibles avec les écrans compatibles avec la configuration de taille UI_MODE_TYPE_NORMAL et utilisent un ou plusieurs écrans physiques aux angles arrondis pour les afficher, elles doivent:

    • [C-1-1] DOIT s'assurer qu'au moins l'une des exigences suivantes est satisfaite pour chacun de ces écrans :
      • Lorsqu'un cadre de 15 dp de 18 dp x 1518 dp est ancré à chaque angle de l'écran logique, au moins un pixel de chaque cadre est visible à l'écran.

  • 7.4.3. Bluetooth:

    Voir la révision

    Les exigences suivantes ont été rétablies:

    Si les implémentations d'appareils déclarent FEATURE_BLUETOOTH_LE, elles:

    • [C-SR-2] Il est FORTEMENT RECOMMANDÉ de mesurer et de compenser le décalage Rx pour s'assurer que le RSSI BLE médian est de -60 dBm +/-10 dB à 1 m de distance d'un appareil de référence transmettant à ADVERTISE_TX_POWER_HIGH, où les appareils sont orientés de sorte qu'ils se trouvent sur des "plans parallèles" avec des écrans orientés dans la même direction.

    • [C-SR-3] Il est FORTEMENT RECOMMANDÉ de mesurer et de compenser le décalage Tx pour s'assurer que le RSSI BLE médian est de -60 dBm à +/-10 dB lors de la recherche depuis un appareil de référence situé à 1 m de distance et en transmettant à ADVERTISE_TX_POWER_HIGH, où les appareils sont orientés de sorte qu'ils se trouvent sur des "plans parallèles" avec des écrans orientés dans la même direction.

    Voir la révision

    Déplacement des exigences [C-10-3] et [C-10-4] vers 2.2.1. Matériel :

    • [C-10-3] DOIT mesurer et compenser le décalage Rx pour s'assurer que le RSSI BLE médian est de -55 dBm à +/-10 dB à 1 mètre d'un appareil de référence transmettant à ADVERTISE_TX_POWER_HIGH.
    • [C-10-4] DOIT mesurer et compenser le décalage Tx pour s'assurer que le RSSI BLE médian est de -55 dBm à +/-10 dB lors du balayage depuis un appareil de référence situé à 1 m de distance et en transmettant à ADVERTISE_TX_POWER_HIGH.

20 novembre 2023

2. Types d'appareils

  • 2.2.1. Matériel:

    Voir la révision

    Si les implémentations d'appareils portables déclarent la prise en charge de toute ABI 64 bits (avec ou sans ABI 32 bits):

  • 2.2.7.2. Appareil photo:

    Voir la révision

    • [7.5/H-1-13] DOIT prendre en charge la fonctionnalité LOGICAL_MULTI_CAMERA pour la caméra arrière principale s'il existe plus d'une caméra RVB à l'arrière.

  • 2.3.2. Multimédia:

    Voir la révision

    • [5.8/T-0-1] DOIT définir le mode de sortie HDMI sur la résolution la plus élevée pour le format SDR ou HDR choisi qui fonctionne avec une fréquence d'actualisation de 50 ou 60 Hz pour l'écran externe.

      DOIT définir le mode de sortie HDMI de manière à sélectionner la résolution maximale compatible avec une fréquence d'actualisation de 50 Hz ou 60 Hz.

  • 2.4.5. Modèle de sécurité:

    Voir la révision

    • [9/W-0-1] DOIT déclarer android.hardware.security.model.compatible feature.

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

  • 6.1. Outils pour les développeurs:

    Voir la révision

    • [C-0-12] DOIT écrire un code Atom LMK_KILL_OCCURRED_FIELD_NUMBER dans le

    Voir la révision

    • [C-0-13] DOIT implémenter la commande shell dumpsys gpu --gpuwork pour afficher

9. Compatibilité des modèles de sécurité

  • 9.7. Fonctionnalités de sécurité:

    Voir la révision

    Si les implémentations d'appareils utilisent un noyau Linux compatible avec SELinux, elles:

    Voir la révision

    Si les implémentations d'appareils utilisent un noyau autre que Linux ou Linux sans SELinux:

4 octobre 2023

2. Types d'appareils

  • 2.2. Configuration requise pour les appareils portables :

    Voir la révision

    Les implémentations d'appareils Android sont considérées comme des appareils portables si elles répondent à tous les critères suivants:

    • La diagonale de l'écran doit être comprise entre 4 pouces 3,3 pouces (ou 2,5 pouces pour les implémentations d'appareils livrées au niveau d'API 29 ou antérieur) à 8 pouces.

    Commencer les nouvelles exigences

    • être dotées d'une interface de saisie tactile ;

  • 2.2.1. Matériel:

    Voir la révision

    Implémentations pour les appareils portables:

    • [7.1.1.1/H-0-1] DOIT disposer d'au moins un écran compatible Android qui répond à toutes les exigences décrites dans ce document et mesure au moins 2,2 pouces sur le bord court et 3,4 pouces sur le bord long.

    Si les implémentations d'appareils portables prennent en charge la rotation logicielle de l'écran, elles:

    • [7.1.1.1/H-1-1]* DOIT mettre l'écran logique mis à la disposition des applications tierces à au moins 2 pouces sur les bords courts et 2,7 pouces sur les bords longs. Les appareils expédiés avec le niveau d'API Android 29 ou version antérieure PEUVENT être exemptés de cette exigence.

    Si les implémentations d'appareils portables ne sont pas compatibles avec la rotation logicielle de l'écran, elles:

    • [7.1.1.1/H-2-1]* DOIT faire en sorte que l'écran logique mis à disposition pour les applications tierces se trouve à au moins 2,7 pouces sur les bords courts. Les appareils expédiés avec le niveau d'API Android 29 ou version antérieure PEUVENT être exemptés de cette exigence.

    Commencer les nouvelles exigences

    • [7.1.1.1/H-0-3]* DOIT mapper chaque écran UI_MODE_NORMAL mis à la disposition des applications tierces sur une zone d'affichage physique non obstruée, d'au moins 2,2 pouces sur le bord court et 3,4 pouces sur le bord long.

    • [7.1.1.3/H-0-1]* DOIT définir la valeur de DENSITY_DEVICE_STABLE sur 92% ou plus que la densité physique réelle de l'écran correspondant.

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

    • [5.6/H-1-1] DOIT avoir une latence moyenne aller-retour continue de 300 millisecondes ou moins de cinq mesures, avec une écart absolue moyenne inférieure à 30 ms, sur les chemins de données suivants: "haut-parleur vers micro", adaptateur de bouclage 3,5 mm (si compatible), rebouclage USB (si compatible).

    • [5.6/H-1-2] DOIT avoir une latence moyenne de la fonctionnalité "Appuyer sur tonalité" de 300 millisecondes ou moins sur au moins cinq mesures sur le chemin de données entre le haut-parleur et le micro.

    Si les implémentations d'appareils portables incluent au moins un actionneur haptique:

    Si les implémentations d'appareils portables incluent au moins un actionneur à résonateur linéaire à usage général 7.10 , elles:

    • [7.10/H] DEVRAIT positionner l'actionneur à proximité de l'endroit où l'appareil est généralement tenu ou touché par les mains.

    • [7,10/H] DEVRAIT déplacer l'actionneur haptique sur l'axe X (gauche-droite) de l'orientation naturelle en portrait de l'appareil.

    Si les implémentations d'appareils portables disposent d'un actionneur haptique à usage général , à savoir un actionneur à résonance linéaire (LRA), sur l'axe X, ils:

    • [7,10/H] La fréquence de résonance de la LRA sur l'axe X DOIT être inférieure à 200 Hz.

  • 2.2.2. Multimédia:

    Voir la révision

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

    • [5.2/H-0-3] AV1

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

    • [5.3/H-0-6] AV1

  • 2.2.3. Logiciel:

    Voir la révision

    Si les implémentations d'appareils incluant la touche de navigation des fonctions récentes comme détaillé dans la section 7.2.3 modifient l'interface, elles:

    • [3.8.3/H-1-1] DOIT implémenter le comportement d'épinglage d'écran et fournir à l'utilisateur un menu de paramètres pour activer/désactiver la fonctionnalité.

    Si les implémentations d'appareils portables sont compatibles avec les API ControlsProviderService et Control, et autorisent les applications tierces à publier des commandes de contrôle des appareils, elles:

    • [3.8.16/H-1-6] Les implémentations d'appareils DOIVENT afficher précisément l' affordance utilisateur comme suit :
      • Si l'appareil a défini config_supportsMultiWindow=true et que l'application déclare les métadonnées META_DATA_PANEL_ACTIVITY dans la déclaration ControlsProviderService, y compris le ComponentName d'une activité valide (tel que défini par l'API), l'application DOIT intégrer cette activité dans cette affordance utilisateur.
      • Si l'application ne déclare pas de métadonnées META_DATA_PANEL_ACTIVITY, elle DOIT afficher les champs spécifiés tels que fournis par l'API ControlsProviderService, ainsi que tous les champs spécifiés fournis par les API Control.
    • [3.8.16/H-1-7] Si l'application déclare les métadonnées META_DATA_PANEL_ACTIVITY, elle DOIT transmettre la valeur du paramètre défini dans [3.8.16/H-1-5] à l'aide de EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS lors du lancement de l'activité intégrée.

    Si les implémentations d'appareils permettent aux utilisateurs de passer des appels,

  • 2.2.4. Performances et puissance:

    Voir la révision

    Implémentations pour les appareils portables:

    • [8.5/H-0-1] DOIT fournir une affordance utilisateur dans le menu Paramètres pour voir toutes les applications avec des services de premier plan actifs ou des tâches lancées par l'utilisateur, y compris la durée de chacun de ces services, comme décrit dans le document du SDK. et la possibilité d'arrêter une application qui exécute un service de premier plan ou une tâche lancée par l'utilisateur 0.
      • Certaines applications PEUVENT être exemptées d'être arrêtées ou répertoriées dans une telle affordance utilisateur, comme décrit dans le document relatif au SDK.

    • [8.5/H-0-2]DOIT fournir une affordance à l'utilisateur pour arrêter une application qui exécute un service de premier plan ou une tâche lancée par l'utilisateur.

  • 2.2.5. Modèle de sécurité:

    Voir la révision

    Si les implémentations d'appareils déclarent prendre en charge android.hardware.telephony, elles:

    • [9.5/H-1-1] NE DOIT PAS définir UserManager.isHeadlessSystemUserMode sur true.

    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, ils:

    • [9.11.1/H-1-1] DOIT inviter l'utilisateur à utiliser l'une des méthodes d'authentification principales recommandées (par exemple, un code, un schéma ou un mot de passe) plus d'une fois toutes les 72 heures.

    Si les implémentations d'appareils portables définissent UserManager.isHeadlessSystemUserMode sur true, elles

    • [9.5/H-4-1] NE DOIT PAS inclure de compatibilité avec les cartes eUICC, ni avec les cartes eSIM avec capacité d'appel.
    • [9.5/H-4-2] NE DOIT PAS déclarer la prise en charge de android.hardware.telephony.

    Si les implémentations d'appareils portables sont compatibles avec l'API système HotwordDetectionService ou un autre mécanisme de détection de mot clé sans indication d'accès au micro, elles:

    • [9.8/H-1-1] DOIT s'assurer que le service de détection de mots clés ne peut transmettre des données qu'au système, ContentCaptureService ou au service de reconnaissance vocale de l'appareil créé par SpeechRecognizer#createOnDeviceSpeechRecognizer().
    • [9.8/H-1-6] NE DOIT PAS permettre la transmission de plus de 100 octets de données (à l'exclusion des flux audio) en dehors du service de détection de mots clés pour chaque résultat de mot clé réussi.

    • [9.8/H-1-15] DOIT s'assurer que les flux audio fournis pour les résultats de mots clés réussis sont transmis à sens unique du service de détection de mots clés au service d'interaction vocale.

    Si les implémentations d'appareils incluent une application qui utilise l'API système HotwordDetectionService ou un mécanisme similaire de détection de mot clé sans indication d'utilisation du micro, l'application:

    • [9.8/H-2-3] NE DOIT PAS transmettre à partir du service de détection de mots clés, de données audio, de données pouvant être utilisées pour reconstruire (entièrement ou partiellement) l'audio ou des contenus audio sans rapport avec le mot clé lui-même, sauf avec le ContentCaptureService ou le service de reconnaissance vocale de l'appareil.

    Si les implémentations d'appareils portables sont compatibles avec l'API système VisualQueryDetectionService ou un autre mécanisme de détection de requêtes sans indication d'accès au micro et/ou à la caméra, elles:

    • [9.8/H-3-1] DOIT s'assurer que le service de détection de requêtes ne peut transmettre des données qu'au système, à ContentCaptureService ou au service de reconnaissance vocale de l'appareil (créé par SpeechRecognizer#createOnDeviceSpeechRecognizer()).
    • [9.8/H-3-2] NE DOIT PAS permettre la transmission d'informations audio ou vidéo en dehors de VisualQueryDetectionService, sauf vers ContentCaptureService ou le service de reconnaissance vocale de l'appareil.
    • [9.8/H-3-3] DOIT afficher un avis utilisateur dans l'UI du système lorsque l'appareil détecte une intention de l'utilisateur d'interagir avec l'application Assistant numérique (par exemple, en détectant la présence de l'utilisateur via l'appareil photo).
    • [9.8/H-3-4] DOIT afficher un indicateur de micro et la requête utilisateur détectée dans l'interface utilisateur juste après la détection de cette requête.
    • [9.8/H-3-5] NE DOIT PAS permettre à une application installable par l'utilisateur de fournir le service de détection visuelle des requêtes.

  • 2.2.7.1. Multimédia:

    Voir la révision

    Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.T pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, les conditions suivantes s'appliquent:

    Commencer les nouvelles exigences

    Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.U pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, les conditions suivantes s'appliquent:

    • [5.1/H-1-1] DOIT annoncer le nombre maximal de sessions de décodeur vidéo matérielle pouvant être exécutées simultanément dans n'importe quelle combinaison de codecs via les méthodes CodecCapabilities.getMaxSupportedInstances() et VideoCapabilities.getSupportedPerformancePoints().
    • [5.1/H-1-2] DOIT prendre en charge six instances de sessions de décodeur vidéo matériel 8 bits (SDR) (AVC, HEVC, VP9, AV1 ou version ultérieure) dans toute combinaison de codec exécutée simultanément avec trois sessions à 30 FPS et 3 sessions à 4K, sauf AV1. Les codecs AV1 ne sont requis que pour la résolution 1080p, mais ils doivent toujours prendre en charge six instances à 1080p30 FPS.
    • [5.1/H-1-3] DOIT annoncer le nombre maximal de sessions d'encodeur vidéo matériel pouvant être exécutées simultanément dans n'importe quelle combinaison de codecs via les méthodes CodecCapabilities.getMaxSupportedInstances() et VideoCapabilities.getSupportedPerformancePoints().
    • [5.1/H-1-4] DOIT prendre en charge six instances de sessions d'encodeur vidéo matériel 8 bits (SDR) (AVC, HEVC, VP9, AV1 ou version ultérieure) dans toute combinaison de codecs exécutée simultanément avec 4 sessions à 30 FPS et 2 sessions à 4K, sauf AV1. Les codecs AV1 ne sont requis que pour la résolution 1080p, mais ils doivent toujours prendre en charge six instances à 1080p30 FPS.
    • [5.1/H-1-5] DOIT annoncer le nombre maximal de sessions d'encodeur et de décodeur vidéo matériel pouvant être exécutées simultanément dans n'importe quelle combinaison de codecs via les méthodes CodecCapabilities.getMaxSupportedInstances() et VideoCapabilities.getSupportedPerformancePoints().
    • [5.1/H-1-6] DOIT prendre en charge six instances de décodeur vidéo matériel 8 bits (SDR) et de sessions d'encodeur vidéo matériel (AVC, HEVC, VP9, AV1 ou version ultérieure) dans toute combinaison de codec exécutée simultanément avec trois sessions à une résolution de 4K à 30 images par seconde (sauf AV1), dont deux sessions avec encodeur au maximum. Les codecs AV1 ne sont requis que pour la résolution 1080p, mais ils doivent toujours prendre en charge six instances à 1080p30 FPS.
    • [5.1/H-1-19] DOIT prendre en charge trois instances de décodeur vidéo matériel HDR 10 bits et de sessions d'encodeur vidéo matériel (AVC, HEVC, VP9, AV1 ou version ultérieure) dans toute combinaison de codec exécutée simultanément à une résolution de 4K à 30 FPS (sauf AV1), dont au maximum 1 Go est configuré dans une session d'encodeur GLA2. La génération de métadonnées HDR par l'encodeur n'est pas requise en cas d'encodage à partir de la surface GL. Les sessions de codec AV1 ne sont requises que pour la résolution 1080p, même lorsque cette exigence implique la 4K.
    • [5.1/H-1-7] DOIT avoir une latence d'initialisation du codec de 40 ms ou moins pour une session d'encodage vidéo de 1080p ou moins pour tous les encodeurs vidéo matériels en charge. La charge ici est définie comme une session simultanée de transcodage vidéo 1080p à 720p en utilisant des codecs vidéo matériels et l'initialisation de l'enregistrement audio-vidéo 1080p. Pour le codec Dolby Vision, la latence d'initialisation du codec DOIT être inférieure ou égale à 50 ms.
    • [5.1/H-1-8] DOIT avoir une latence d'initialisation du codec de 30 ms ou moins pour une session d'encodage audio de 128 kbit/s ou un débit inférieur pour tous les encodeurs audio en charge. La charge ici est définie comme une session simultanée de transcodage vidéo 1080p à 720p en utilisant des codecs vidéo matériels et l'initialisation de l'enregistrement audio-vidéo 1080p.
    • [5.1/H-1-9] DOIT prendre en charge deux instances de sessions de décodeur vidéo matérielle sécurisées (AVC, HEVC, VP9, AV1 ou version ultérieure) dans toute combinaison de codec exécutée simultanément à 4K à 30 FPS (sauf AV1) pour les contenus 8 bits (SDR) et HDR 10 bits. Les sessions de codec AV1 ne sont requises que pour la résolution 1080p, même lorsque cette exigence implique la 4K.
    • [5.1/H-1-10] DOIT prendre en charge trois instances de sessions de décodeur vidéo matériel non sécurisées avec une instance de session de décodeur vidéo matérielle sécurisée (4 instances au total) (AVC, HEVC, VP9, AV1 ou version ultérieure) dans n'importe quelle combinaison de codec exécutée simultanément avec trois sessions à une résolution de 4K à 30 FPS et une session de décodeur sécurisée à 4K à 30 FPS (sauf une session sécurisée de 30 FPS à 30 FPS et 3 sessions HDR à 0 FPS à une résolution de 4K à 10 FPS). Les sessions de codec AV1 ne sont requises que pour la résolution 1080p, même lorsque cette exigence implique la 4K.
    • [5.1/H-1-11] DOIT être compatible avec un décodeur sécurisé pour chaque décodeur matériel AVC, HEVC, VP9 ou AV1 de l'appareil.
    • [5.1/H-1-12] DOIT avoir une latence d'initialisation du codec de 40 ms ou moins pour une session de décodage vidéo de 1080p ou moins pour tous les décodeurs vidéo matériels en charge. La charge ici est définie comme une session simultanée de transcodage vidéo de 1080p à 720p effectuée à l'aide de codecs vidéo matériels et de l'initialisation de la lecture audio/vidéo 1080p. Pour le codec Dolby Vision, la latence d'initialisation du codec DOIT être inférieure ou égale à 50 ms.
    • [5.1/H-1-13] DOIT avoir une latence d'initialisation du codec de 30 ms ou moins pour une session de décodage audio de 128 kbit/s ou un débit inférieur pour tous les décodeurs audio en charge. Cette charge désigne une session simultanée de transcodage vidéo de 1080p à 720p utilisant des codecs vidéo matériels et l'initialisation de la lecture audio/vidéo 1080p.
    • [5.1/H-1-14] DOIT prendre en charge le décodeur matériel AV1 Main 10, Level 4.1 et le grain.
    • [5.1/H-1-15] DOIT disposer d'au moins un décodeur vidéo matériel compatible avec la résolution 4K60.
    • [5.1/H-1-16] DOIT disposer d'au moins un encodeur vidéo matériel compatible avec la résolution 4K60.
    • [5.3/H-1-1] NE DOIT PAS supprimer plus d'une image en 10 secondes (c'est-à-dire une perte de frames inférieure à 0,167 %) pour une session vidéo 4K à 60 FPS en charge.
    • [5.3/H-1-2] NE DOIT PAS supprimer plus d'une image en 10 secondes lors d'un changement de résolution vidéo au cours d'une session vidéo à 60 FPS et chargée d'une session 4K.
    • [5.6/H-1-1] DOIT avoir une latence tap-to-ton de 80 millisecondes ou moins à l'aide du test tap-to-tone de CTS Verifier.
    • [5.6/H-1-2] DOIT avoir une latence audio aller-retour de 80 millisecondes ou moins sur au moins un chemin de données compatible.
    • [5.6/H-1-3] DOIT prendre en charge l'audio >=24 bits pour une sortie stéréo sur des connecteurs audio 3,5 mm si elle est présente, et via l'audio USB si elle est prise en charge sur l'intégralité du chemin de données pour une faible latence et des configurations de streaming. Pour la configuration à faible latence, AAudio doit être utilisé par l'application en mode de rappel à faible latence. Pour la configuration du streaming, l'application doit utiliser une piste audio Java. Dans les configurations à faible latence et en streaming, le récepteur de sortie HAL doit accepter AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT ou AUDIO_FORMAT_PCM_FLOAT pour son format de sortie cible.
    • [5.6/H-1-4] DOIT prendre en charge les appareils audio USB à 4 canaux ou plus (utilisé par les manettes de DJ pour la prévisualisation des titres).
    • [5.6/H-1-5] DOIT prendre en charge les appareils MIDI conformes à la classe et déclarer l'indicateur de fonctionnalité MIDI.
    • [5.6/H-1-9] DOIT prendre en charge au moins 12 canaux de mixage. Cela implique la possibilité d'ouvrir une piste audio avec un masque de canal 7.1.4 et de répartir correctement tous les canaux en stéréo ou de les décomposer correctement.
    • [5.6/H-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge le mixage de 24 canaux avec au moins la prise en charge des masques de canal 9.1.6 et 22.2.
    • [5.7/H-1-2] DOIT prendre en charge MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL avec les fonctionnalités de déchiffrement de contenu ci-dessous.
    Taille d'échantillon minimale 4 Mio
    Nombre minimal de sous-échantillons – H264 ou HEVC 32
    Nombre minimal de sous-échantillons – VP9 9
    Nombre minimal de sous-échantillons – AV1 288
    Taille minimale de la mémoire tampon du sous-échantillon 1 Mio
    Taille minimale de la mémoire tampon cryptographique générique 500 Kio
    Nombre minimal de sessions simultanées 30
    Nombre minimal de clés par session 20
    Nombre total minimal de clés (toutes les sessions) 80
    Minimum Total Number of DRM Keys (toutes les sessions) 6
    Taille du message 16 Kio
    Frames déchiffrés par seconde 60 FPS
    • [5.1/H-1-17] DOIT disposer d'au moins un décodeur d'image matériel compatible avec le profil de référence AVIF.
    • [5.1/H-1-18] DOIT être compatible avec l'encodeur AV1 capable d'encoder jusqu'à 480p à 30 FPS et 1 Mbit/s.
    • [5.12/H-1-1] DOIT [5.12/H-SR] Sont vivement recommandés pour assurer la compatibilité avec la fonctionnalité Feature_HdrEditing sur tous les encodeurs matériels AV1 et HEVC présents sur l'appareil.
    • [5.12/H-1-2] DOIT être compatible avec le format de couleurs RGBA_1010102 pour tous les encodeurs matériels AV1 et HEVC présents sur l'appareil.
    • [5.12/H-1-3] DOIT annoncer la prise en charge de l'extension EXT_YUV_target pour l'échantillonnage à partir de textures YUV en 8 et 10 bits.
    • [7.1.4/H-1-1] DOIT comporter au moins six superpositions matérielles dans l'unité de traitement des données (HWC, Data Processing Unit) et au moins deux d'entre elles capables d'afficher du contenu vidéo 10 bits.

    Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.U pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS et qu'elles sont compatibles avec un encodeur AVC ou HEVC matériel, les conditions suivantes s'appliquent:

    • [5.2/H-2-1] DOIT respecter l'objectif de qualité minimal défini par les courbes de distorsion du débit de l'encodeur vidéo pour les codecs AVC et HEVC matériels, tel que défini dans la documentation à venir.

  • 2.2.7.2. Appareil photo:

    Voir la révision

    Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.U pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, les conditions suivantes s'appliquent:

    • [7.5/H-1-1] DOIT disposer d'une caméra arrière principale d'une résolution d'au moins 12 mégapixels, permettant la capture vidéo à 4K à 30 images par seconde. La caméra arrière principale est celle qui possède l'ID d'appareil photo le plus bas.
    • [7.5/H-1-2] DOIT disposer d'une caméra frontale principale d'une résolution d'au moins 6 mégapixels et prendre en charge la capture vidéo à 1080p à 30 images par seconde. La caméra frontale principale est celle qui possède l'ID d'appareil photo le plus bas.
    • [7.5/H-1-3] DOIT prendre en charge la propriété android.info.supportedHardwareLevel avec une valeur COMPLÈTE ou supérieure pour les deux caméras principales.
    • [7.5/H-1-4] DOIT prendre en charge CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME pour les deux caméras principales.
    • [7.5/H-1-5] DOIT avoir une latence de capture JPEG "camera2" inférieure à 1 000 900 ms pour une résolution 1080p telle que mesurée par le test PerformanceTest de la caméra CTS dans les conditions d'éclairage ITS (3 000 K) des deux caméras principales.
    • [7.5/H-1-6] DOIT avoir une latence de démarrage de la caméra 2 (ouvrir la caméra à la première image d'aperçu) inférieure à 500 ms, telle que mesurée par le test PerformanceTest de la caméra CTS dans des conditions d'éclairage ITS (3 000 K) pour les deux caméras principales.
    • [7.5/H-1-8] DOIT prendre en charge CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW et android.graphics.ImageFormat.RAW_SENSOR pour la caméra arrière principale.
    • [7.5/H-1-9] DOIT disposer d'une caméra principale arrière compatible avec les résolutions 720p ou 1080p à 240 FPS.
    • [7.5/H-1-10] DOIT avoir une valeur de ZOOM_RATIO inférieure à 1,0 pour les caméras principales si une caméra RVB ultra grand angle orientée dans la même direction.
    • [7.5/H-1-11] DOIT implémenter une diffusion simultanée de flux avant arrière sur les caméras principales.
    • [7.5/H-1-12] DOIT prendre en charge CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION pour la caméra avant principale et la caméra arrière principale.
    • [7.5/H-1-13] DOIT prendre en charge la capacité LOGICAL_MULTI_CAMERA pour les caméras principales si plus d'une caméra RVB orientée dans la même direction.
    • [7.5/H-1-14] DOIT prendre en charge la fonctionnalité STREAM_USE_CASE pour la caméra avant principale et la caméra arrière principale.
    • [7.5/H-1-15] DOIT prendre en charge les extensions Bokeh et en mode Nuit via les extensions CameraX et Camera2 pour les appareils photo principaux.
    • [7.5/H-1-16] DOIT prendre en charge la fonctionnalité DYNAMIC_RANGE_TEN_BIT pour les caméras principales.
    • [7.5/H-1-17] DOIT être compatible avec CONTROL_SCENE_MODE_FACE_PRIORITY et la détection de visages (STATISTICS_FACE_DETECT_MODE_SIMPLE ou STATISTICS_FACE_DETECT_MODE_FULL) pour les caméras principales.

  • 2.2.7.3. Matériel:

    Voir la révision

    Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.U pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, les conditions suivantes s'appliquent:

    • [7.1.1.1/H-2-1] DOIT avoir une résolution d'écran d'au moins 1080p.
    • [7.1.1.3/H-2-1] DOIT avoir une densité d'écran d'au moins 400 ppp.
    • [7.1.1.3/H-3-1] DOIT disposer d'un écran HDR acceptant au moins 1 000 nits en moyenne.
    • [7.6.1/H-2-1] DOIT disposer d'au moins 8 Go de mémoire physique.

  • 2.2.7.4. Performances:

    Voir la révision

    Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.U pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, les conditions suivantes s'appliquent:

    • [8.2/H-1-1] DOIT garantir des performances d'écriture séquentielle d'au moins 150 Mo/s.
    • [8.2/H-1-2] DOIT garantir des performances d'écriture aléatoire d'au moins 10 Mo/s.
    • [8.2/H-1-3] DOIT garantir des performances de lecture séquentielle d'au moins 250 Mo/s.
    • [8.2/H-1-4] DOIT garantir des performances de lecture aléatoire d'au moins 100 Mo/s.
    • [8.2/H-1-5] DOIT garantir des performances de lecture et d'écriture séquentielles en parallèle avec des performances de lecture et d'écriture deux fois plus importantes et d'écriture d'au moins 50 Mo/s.

  • 2.3.2. Multimédia:

    Voir la révision

    Les implémentations de téléviseurs DOIVENT prendre en charge les formats d'encodage vidéo suivants et les mettre à la disposition d'applications tierces:

    • [5.2/T-0-3] AV1

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

  • 2.4.5. Modèle de sécurité:

    Voir la révision

    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, ils:

    • [9.11.1/W-1-1] DOIT inviter l'utilisateur à utiliser l'une des méthodes d'authentification principales recommandées (par exemple, un code, un schéma ou un mot de passe) plus d'une fois toutes les 72 heures.

  • 2.5.1. Matériel:

    Voir la révision

    Si les implémentations d'appareils prennent en charge la diffusion de radio AM/FM et exposent la fonctionnalité à n'importe quelle application, celles-ci:

    • [7.4.10/A-0-1] DOIT déclarer la prise en charge de FEATURE_BROADCAST_RADIO.

    Une caméra de l'extérieur est une caméra qui capture les scènes en dehors de l'implémentation de l'appareil, comme la caméra de recul.

    Implémentations pour les appareils automobiles:

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

    Si les implémentations d'appareils automobiles incluent une caméra offrant une vue extérieure, celles-ci:

    • [7.5/A-1-1] NE DOIT PAS avoir de caméras extérieures accessibles via les API Android Camera, sauf si elles respectent les exigences principales relatives aux caméras.
    • [7.5/A-SR-1] Il est FORTEMENT RECOMMANDÉ de ne pas faire pivoter l'aperçu de l'appareil photo ou de ne pas le reproduire horizontalement.
    • [7.5/A-SR-2] Il est FORTEMENT RECOMMANDÉ d'avoir une résolution d'au moins 1,3 mégapixel.
    • DEVRAIT être équipé d'un matériel à mise au point fixe ou EDOF (profondeur de champ étendue).
    • Un autofocus matériel ou logiciel peut être implémenté dans le pilote de l'appareil photo.

    Si les implémentations d'appareils automobiles incluent une ou plusieurs caméras offrant une vue extérieure et chargent le service EVS (Exterior View System), alors pour ce type de caméra:

    • [7.5/A-2-1] NE DOIT PAS pivoter ni dupliquer horizontalement l'aperçu de l'appareil photo.

    Implémentations pour les appareils automobiles:

    • PEUT inclure une ou plusieurs caméras disponibles pour des applications tierces.

    Si les implémentations d'appareils automobiles incluent au moins une caméra et la mettent à la disposition des applications tierces:

    • [7.5/A-3-1] DOIT signaler le flag de fonctionnalité android.hardware.camera.any.
    • [7.5/A-3-2] NE DOIT PAS déclarer la caméra en tant que caméra système.
    • PEUVENT être compatibles avec les caméras externes décrites dans la section 7.5.3.
    • PEUT inclure des fonctionnalités (telles que l'autofocus, etc.) disponibles pour les caméras arrière, comme décrit dans la section 7.5.1.

    Une caméra arrière est une caméra orientée vers l'extérieur qui peut être installée à n'importe quel endroit du véhicule et qui fait face à l'extérieur de son habitacle. Autrement dit, elle filme des scènes situées de l'autre côté de la carrosserie du véhicule, comme la caméra arrière.

    Une caméra frontale est une caméra tournée vers l'utilisateur qui peut être située à n'importe quel endroit du véhicule et qui fait face à l'intérieur de l'habitacle du véhicule. En d'autres termes, elle affiche l'utilisateur, par exemple pour la visioconférence et des applications similaires.

    Implémentations pour les appareils automobiles:

    • [7.5/A-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure une ou plusieurs caméras orientées vers l'extérieur.
    • PEUT inclure une ou plusieurs caméras orientées vers l'utilisateur.
    • [7.5/A-SR-2] SONT FORTEMENT RECOMMANDÉS pour prendre en charge la diffusion simultanée de flux de plusieurs caméras.

    Si les implémentations d'appareils automobiles incluent au moins une caméra orientée vers l'extérieur:

    • [7.5/A-1-1] DOIT être orienté de sorte que la dimension longue de l'appareil photo s'aligne sur le plan X-Y des axes des capteurs automobiles Android.
    • [7.5/A-SR-3] Il est FORTEMENT RECOMMANDÉ d'utiliser du matériel à mise au point fixe ou EDOF (Extended Depth of Field).
    • [7.5/A-1-2] DOIT disposer de l'appareil photo principal orienté vers l'extérieur en tant qu'appareil photo orienté vers l'extérieur avec l'ID d'appareil photo le plus bas.

    Si les implémentations d'appareils automobiles incluent au moins une caméra orientée vers l'utilisateur, voici comment procéder:

    • [7.5/A-2-1] L'appareil photo principal destiné à l'utilisateur DOIT être celui dont l'ID d'appareil photo est le plus bas.
    • PEUT être orienté de sorte que la dimension longue de l'appareil photo s'aligne sur le plan X-Y des axes des capteurs automobiles Android.

    Si les implémentations d'appareils Android Automotive incluent un appareil photo accessible via l'API android.hardware.Camera ou android.hardware.camera2, elles:

    • [7.5/A-3-1] DOIT respecter les exigences principales de la section 7.5 concernant les appareils photo.

    Si les implémentations d'appareils Android Automotive incluent un appareil photo qui n'est pas accessible via l'API android.hardware.Camera ou android.hardware.camera2, elles:

    • [7.5/A-4-1] DOIT être accessible via le service Extended View System.

    Si les implémentations d'appareils automobiles incluent une ou plusieurs caméras accessibles via Extended View System Service, elles:

    • [7.5/A-5-1] NE DOIT PAS pivoter ni dupliquer horizontalement l'aperçu de l'appareil photo.
    • [7.5/A-SR-4] Il est FORTEMENT RECOMMANDÉ d'avoir une résolution d'au moins 1,3 mégapixel.

    Si les implémentations d'appareils automobiles incluent une ou plusieurs caméras accessibles à la fois via le service Extended View System et l'API android.hardware.Camera ou android.hardware.Camera2, les mesures suivantes s'appliquent:

    • [7.5/A-6-1] DOIT signaler le même ID de caméra.

    Si les implémentations d'appareils automobiles fournissent une API d'appareil photo propriétaire, elles:

    • [7.5/A-7-1] DOIT implémenter une telle API d'appareil photo à l'aide de l'API android.hardware.camera2 ou de l'API Extended View System.

  • 2.5.3. Logiciel:

    Voir la révision

    Implémentations pour les appareils automobiles:

    • [3.8/A-0-1] NE DOIT PAS autoriser les utilisateurs secondaires complets qui ne sont pas l'utilisateur actuel au premier plan à lancer des activités et à accéder à l'interface utilisateur sur n'importe quel écran.

  • 2.5.5. Modèle de sécurité:

    Voir la révision

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

    • [9.8.2/A-1-1] DOIT afficher l'indicateur de micro lorsqu'une application accède aux données audio du micro, mais pas lorsqu'il n'est accessible que par HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService ou par des applications détenant les rôles décrits dans la section 9.1 avec l'identifiant CDD [C-4-X].
    • [9.8.2/A-1-2] NE DOIT pas masquer l'indicateur de micro pour les applications système ayant des interfaces utilisateur visibles ou une interaction directe de l'utilisateur.
    • [9.8.2/A-1-3] DOIT fournir une affordance à l'utilisateur pour activer/désactiver le micro dans l'application Paramètres.

    Si les implémentations d'appareils automobiles déclarent android.hardware.camera.any, elles:

    • [9.8.2/A-2-1] DOIT afficher l'indicateur de l'appareil photo lorsqu'une application accède aux données en direct de l'appareil photo, mais pas lorsqu'elle n'est accessible que par une ou plusieurs applications détenant les rôles, comme indiqué dans la section 9.1 sur les autorisations avec l'identifiant CDD [C-4-X][C-3-X].

    • [9.8.2/A-2-3] DOIT fournir une affordance à l'utilisateur pour activer/désactiver l'appareil photo dans l'application Paramètres.
    • [9.8.2/A-2-4] DOIT afficher les applications récentes et actives utilisant l'appareil photo comme renvoyé par PermissionManager.getIndicatorAppOpUsageData(), avec tous les messages d'attribution qui leur sont associés.

    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, ils:

    • [9.11.1/A-1-1] DOIT interroger l'utilisateur plus d'une fois toutes les 336 heures pour l'une des méthodes d'authentification principales recommandées (par exemple, code, schéma ou mot de passe).

3. Logiciel

  • 3.1. Compatibilité des API gérées:

    Voir la révision

    Implémentations pour les appareils:

    • [C-0-8] NE DOIT PAS prendre en charge l'installation d'applications ciblant un niveau d'API inférieur à 23.

  • 3.2.3.5. Intents d'application conditionnelles:

    Voir la révision

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

  • 3.3.1. Interfaces binaires d'application:

    Voir la révision

    Implémentations pour les appareils:

    • [C-0-12] DOIT exporter les symboles de fonction pour les symboles de fonction de base Vulkan 1.0 Vulkan 1.1, ainsi que les extensions VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 et VK_KHR_get_physical_device_properties2 via la bibliothèque libvulkan.so. Notez que bien que tous les symboles DOIVENT être présents, la section 7.1.4.2 décrit plus en détail les exigences liées à l'implémentation complète de chaque fonction correspondante.

  • 3.8.6. Thèmes:

    Voir la révision

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

    • [C-1-5] DOIT générer des palettes de tons dynamiques à l'aide de styles de thème de couleur énumérés dans la documentation Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (voir android.theme.customization.theme_styles), à savoir TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD et MONOCHROMATIC.

  • 3.8.8. Changement d'activité:

    Voir la révision

    Si les implémentations d'appareils incluant la touche de navigation des fonctions récentes comme indiqué dans la section 7.2.3 modifient l'interface, elles:

  • 3.9.2 Prise en charge des profils gérés:

    Voir la révision

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

    • [C-1-10] DOIT s'assurer que les données de capture d'écran sont enregistrées dans l'espace de stockage du profil professionnel lorsqu'une capture d'écran est effectuée avec une fenêtre topActivity sélectionnée (celle avec laquelle l'utilisateur a interagi en dernier parmi toutes les activités) et appartenant à une application de profil professionnel.
    • [C-1-11] NE DOIT PAS capturer d'autres contenus d'écran (barre système, notifications ou contenu de profil personnel), à l'exception de la fenêtre/fenêtres de l'application du profil professionnel lors de l'enregistrement d'une capture d'écran dans le profil professionnel (pour garantir que les données de profil personnel ne sont pas enregistrées dans celui-ci).

  • 3.9.5 Framework de résolution des règles relatives aux appareils: nouvelle section

    Voir la révision

    Si les implémentations d'appareils signalent android.software.device_admin ou android.software.managed_users, alors:

    • [C-1-1] DOIT résoudre les conflits de règles relatives aux appareils, comme indiqué dans la documentation AOSP.

5. Compatibilité multimédia

  • 5.1.4. Encodage d'image:

    Voir la révision

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

    • [C-0-4] AVIF
      • Les appareils doivent être compatibles avec BITRATE_MODE_CQ et le profil de référence.

  • 5.1.5. Décodage d'image:

    Voir la révision

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

    [C-0-7] AVIF (profil de référence)

  • 5.1.6. Détails des codecs image:

    Voir la révision

    Format/Codec Détails Types de fichiers/formats de conteneur acceptés
    JPEG Base+progressive JPEG (.jpg)
    GIF GIF (.gif)
    PNG PNG (.png)
    BMP BMP (.bmp)
    WebP WebP (.webp)
    Brute ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
    HEIF Image, collection d'images, séquence d'images HEIF (.heif), HEIC (.heic)
    AVIF (Profil de référence) Image, collection d'images, profil de référence de la séquence d'images Conteneur HEIF (.avif)

  • 5.1.8. Liste des codecs vidéo:

    Voir la révision

    Format/Codec Détails Types de fichiers/Formats de conteneur compatibles
    H.263
    • 3GPP (0,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 (0,3gp)
    • MPEG-4 (.mp4)
    • MPEG-2 TS (.ts, impossible de rechercher)
    • Matroska (.mkv, décodage uniquement)
    HEVC H.265 Pour en savoir plus, consultez la section 5.3.
    • MPEG-4 (.mp4)
    • Matroska (.mkv, décodage uniquement)
    MPEG-2 Main Profile
    • MPEG2-TS (.ts, impossible de rechercher)
    • MPEG-4 (.mp4, décodage uniquement)
    • Matroska (.mkv, décodage uniquement)
    MPEG-4 SP
    • 3GPP (0,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.
    AV1 Pour en savoir plus, consultez la section 5.2 et la section 5.3.
    • MPEG-4 (.mp4)
    • Matroska (.mkv, décodage uniquement)

  • 5.1.10. Caractérisation du codec multimédia:

    Voir la révision

    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 de fréquence d'images atteignables pour les tailles suivantes, si elles sont compatibles avec le codec:
    SD (basse qualité) 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, AV1)
    • 1408 x 1152 px (H263)
    • 1 280 x 720 px (autre, AV1)
    		 1 920 x 1 080 px (autres que MPEG4 et AV1) 3840 x 2160 px (HEVC, VP9, AV1)

  • 5.2. Encodage vidéo:

    Voir la révision

    Si les implémentations d'appareils sont compatibles avec n'importe quel encodeur vidéo et le mettent à la disposition d'applications tierces, celles-ci:

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

    Si les implémentations d'appareils sont compatibles avec n'importe quel encodeur vidéo et le rendent disponible pour les applications tierces, et définissez
    MediaFormat.KEY_BITRATE_MODE sur BITRATE_MODE_VBR pour que l'encodeur fonctionne en mode à débit variable, le débit encodé n'affecte pas le prix minimal de qualité :

    • [C-5-1] DOIT NE DEVRAIT PAS être, sur une fenêtre glissante, supérieur à 15% par rapport au débit entre les intervalles intraframes (I-frame).
    • [C-5-2] DOIT NE DEVRAIT PAS dépasser 100% du débit sur une fenêtre glissante d'une seconde.

    Si les implémentations d'appareils sont compatibles avec n'importe quel encodeur vidéo et le rendent disponible pour les applications tierces et définissent MediaFormat.KEY_BITRATE_MODE sur BITRATE_MODE_CBR pour que l'encodeur fonctionne en mode débit constant, le débit encodé:

    • [C-6-1] DOIT [C-SR-2] est VIVEMENT RECOMMANDÉ de NE PAS dépasser 15% du débit cible sur une fenêtre glissante d'une seconde.

  • 5.2.1. H.263:

    Voir la révision

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

    • [C-1-1] DOIT prendre en charge la résolution QCIF (176 x 144) utilisant le niveau de profil de référence 45. La résolution SQCIF est facultative.
    • DEVRAIT accepter des débits configurables dynamiquement pour l'encodeur compatible.

  • 5.2.5. H.265:

    Voir la révision

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

    • [C-1-1] DOIT prendre en charge le profil principal de niveau 3 jusqu'à une résolution de 512 x 512.
    • DEVRAIT prendre en charge les profils d'encodage HD comme indiqué dans le tableau suivant.
    • [C-SR-1] est VIVEMENT RECOMMANDÉ pour prendre en charge le profil SD 720 x 480 et les profils d'encodage HD, comme indiqué dans le tableau suivant s'il existe un encodeur matériel.

  • 5.2.6. AV1: nouvelle section

    Voir la révision

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

    • [C-1-1] DOIT prendre en charge le profil principal, y compris les contenus 8 bits et 10 bits.

    • [C-1-2] DOIT publier les données sur les performances, c'est-à-dire les rapports sur les performances via les API getSupportedFrameRatesFor() ou getSupportedPerformancePoints() pour les résolutions acceptées du tableau ci-dessous.

    • [C-1-3] DOIT accepter les métadonnées HDR et les envoyer dans le flux de bits.

    Si l'encodeur AV1 est accéléré par le matériel:

    • [C-2-1] DOIT accepter un profil d'encodage HD1080p compris dans le tableau ci-dessous:
    SD HD – 720p HD – 1080p UHD
    Résolution vidéo 720 x 480 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 px
    Fréquence d'images vidéo 30 ips 30 ips 30 ips 30 ips
    Débit vidéo 5 Mbit/s 8 Mbit/s 16 Mbit/s 50 Mbit/s

  • 5.3.2. H.263:

    Voir la révision

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

    • [C-1-1] DOIT être compatible avec les profils de référence de niveau 30 (résolutions CIF, QCIF et SQCIF à 30 FPS 384 kbit/s) et les niveaux 45 (résolutions QCIF et SQCIF à 30 FPS et 128 kbit/s).

  • 5.3.9. AV1:

    Voir la révision

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

    • [C-1-1] DOIT prendre en charge le profil 0, y compris le contenu 10 bits.

    Si les implémentations d'appareils sont compatibles avec le codec AV1 et le mettent à la disposition d'applications tierces:

    • [C-1-1] DOIT prendre en charge le profil principal, y compris les contenus 8 bits et 10 bits.

    Si les implémentations d'appareils sont compatibles avec le codec AV1 avec un décodeur avec accélération matérielle, les systèmes suivants:

    • [C-2-1] DOIT être capable de décoder au moins les profils de décodage vidéo HD 720p du tableau ci-dessous lorsque la hauteur indiquée par la méthode Display.getSupportedModes() est supérieure ou égale à 720p.
    • [C-2-2] DOIT être capable de décoder au moins les profils de décodage vidéo HD 1080p du tableau ci-dessous lorsque la hauteur indiquée par la méthode Display.getSupportedModes() est supérieure ou égale à 1 080p.
    SD HD – 720p HD – 1080p UHD
    Résolution vidéo 720 x 480 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 px
    Fréquence d'images vidéo 30 ips 30 ips 30 ips 30 ips
    Débit vidéo 5 Mbit/s 8 Mbit/s 16 Mbit/s 50 Mbit/s

    Si les implémentations d'appareils sont compatibles avec le profil HDR via les API multimédias, ils:

    • [C-3-1] DOIT être compatible avec l'extraction et la sortie des métadonnées HDR à partir du flux de bits et/ou du conteneur.
    • [C-3-2] DOIT afficher correctement le contenu HDR sur l'écran de l'appareil ou sur un port de sortie vidéo standard (HDMI, par exemple).

  • 5.4.2. Capture pour la reconnaissance vocale:

    Voir la révision

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

    • DEVRAIT définir la sensibilité d'entrée audio de sorte qu'une source à tonalités sinusoïdales de 1 000 Hz lue à 90 dB/échantillons de pression acoustique (SPL) à 90 dB/échantillons SPL (mesurés à une distance de 30 cm à côté du micro) produise une réponse idéale de RMS 2 500 à une plage de 1 770 ou 35 dB/d-2 d'échantillons de 1 000 à 1 770 dB/2.

  • 5.5.2. Effets audio:

    Voir la révision

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

    • [C-1-4] DOIT prendre en charge les effets audio avec des entrées et sorties à virgule flottante.
    • [C-1-5] DOIT s'assurer que les effets audio sont compatibles avec plusieurs canaux jusqu'au nombre de canaux du mélangeur, également appelé FCC_LIMIT.

  • 5.6. Latence audio:

    Voir la révision

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

    • [C-SR-4] Le code temporel de sortie renvoyé par AudioTrack.getTimestamp et AAudioStream_getTimestamp est précis à +/- 1 ms.

    • [C-SR-4] Les latences aller-retour calculées en fonction des horodatages d'entrée et de sortie renvoyés par AAudioStream_getTimestamp sont FORTEMENT RECOMMANDÉES de se trouver à 30 ms de la latence aller-retour mesurée pour AAUDIO_PERFORMANCE_MODE_NONE et AAUDIO_PERFORMANCE_MODE_LOW_LATENCY pour les haut-parleurs, ainsi que les casques filaires et sans fil.

7. Compatibilité matérielle

  • 7.1. Écran et graphismes:

    Voir la révision

    Android inclut des fonctionnalités qui ajustent automatiquement les éléments d'application et la mise en page de l'interface utilisateur en fonction de l'appareil afin de s'assurer que les applications tierces s'exécutent correctement sur différentes configurations matérielles. Un écran compatible avec Android est un écran qui implémente tous les comportements et les API décrits dans la section Développeurs Android – Présentation de la compatibilité des écrans, dans cette section (7.1) et dans ses sous-sections, ainsi que sur tout comportement supplémentaire spécifique au type d'appareil décrit dans la section 2 de ce CDD. Sur les écrans compatibles Android sur lesquels toutes les applications tierces compatibles Android peuvent s'exécuter, les implémentations d'appareils DOIVENT implémenter ces API et ces comportements correctement, comme indiqué dans cette section.

    Commencer les nouvelles exigences

    Implémentations pour les appareils:

    • [C-0-1] DOIT, par défaut, n'afficher les applications tierces que sur les écrans compatibles avec Android.

    Les unités référencées par les exigences de cette section sont définies comme suit:

    • taille physique en diagonale. Distance en pouces entre deux coins opposés de la partie éclairée de l'écran.
    • densité de points par pouce (ppp). Nombre de pixels englobés par une étendue linéaire horizontale ou verticale de 1 pouce, exprimé en pixels par pouce (ppp ou dpi). Lorsque des valeurs dpi ppi et dpi sont indiquées, les dpi horizontal et vertical doivent être compris dans la plage listée.
    • format. Rapport entre le nombre de pixels de la dimension la plus longue et la dimension la plus courte de l'écran. Par exemple, un affichage de 480 x 854 pixels serait 854/480 = 1,779, soit approximativement "16:9".
    • pixel indépendant de la densité (dp). L'unité A de pixels virtuels normalisée sur une densité d'écran de 160 ppp de 160. Pour une densité d et un nombre de pixels p, le nombre de pixels indépendants de la densité est calculé comme suit: pixels = dps * (densité/160) dp = (160 / d) * p .

  • 7.1.1.1. Taille et forme de l'écran:

    Voir la révision

    Si les implémentations d'appareils sont compatibles avec les écrans compatibles avec la configuration de taille UI_MODE_TYPE_NORMAL et incluent une compatibilité avec Android, utilisent des écrans physiques aux coins arrondis pour afficher ces écrans:

    • [C-1-1] DOIT s'assurer qu'au moins l'une des exigences suivantes est satisfaite pour chaque écran de ce type:
    • Le rayon des angles arrondis est inférieur ou égal à 38 dp.

    • Lorsqu'une zone de 15 dp par 15 dp est ancrée à chaque coin de l'affichage logique, au moins un pixel de chaque zone est visible à l'écran.

    • DEVRAIT inclure l' affordance de l'utilisateur pour passer au mode d'affichage avec les coins rectangulaires.

    Commencer les nouvelles exigences

    Si les implémentations d'appareils ne peuvent configurer que le clavier NO_KEYS et ont l'intention de signaler la prise en charge de la configuration du mode d'interface utilisateur UI_MODE_TYPE_NORMAL, elles:

    • [C-4-1] DOIT disposer d'une mise en page d'au moins 596 dp x 384 dp, sans encoches, ou plus.

    Si les implémentations d'appareils incluent un ou plusieurs écrans pliables compatibles avec Android, ou qui incluent une charnière pliable entre plusieurs écrans et permettent à ces écrans d'afficher des applications tierces:

    Si les implémentations d'appareils incluent un écran pliable compatible avec Android ou une charnière pliable entre plusieurs écrans, et si la charnière ou le pli traverse une fenêtre d'application en plein écran, ils:

    • [C-3-1] DOIT indiquer à l'application la position, les limites et l'état de la charnière ou du pli via les extensions ou les API side-car.

    Si les implémentations d'appareils incluent une ou plusieurs zones d'affichage pliables compatibles avec Android, ou incluent une charnière pliable entre plusieurs zones d'affichage compatibles avec Android et mettent ces zones d'affichage à la disposition des applications, elles:

    • [C-4-1] DOIT implémenter la version correcte du niveau d'API Window Manager Extensions, comme décrit dans la documentation à venir.

  • 7.1.1.2. Format de l'écran: supprimé

  • 7.1.1.3. Densité d'écran:

    Voir la révision

    Implémentations des appareils:

    • [C-0-1] Par défaut, les implémentations d'appareils DOIVENT indiquer uniquement l'une des densités du framework Android listées sur DisplayMetrics via l'API DENSITY_DEVICE_STABLE, et cette valeur doit être une valeur statique pour chaque écran physique NE DOIT PAS changer à tout moment. touteDisplayMetrics.density

    • 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 pousse la taille d'écran indiquée en dessous de la taille minimale prise en charge. Si la densité du framework Android standard la plus proche numériquement de la densité physique se traduit par une taille d'écran inférieure à la plus petite taille d'écran compatible compatible (largeur de 320 dp), les implémentations d'appareils DOIVENT indiquer la deuxième densité de framework standard Android la plus basse.

    Commencer les nouvelles exigences

    • DEVRAIT définir la densité standard du framework Android qui est numériquement la plus proche de la densité physique de l'écran, ou une valeur correspondant aux mêmes mesures de champ de vision angulaire équivalentes qu'un appareil portable.

    Si les implémentations d'appareils offrent une affordance de modifier la taille d'affichage de l'appareil, elles:

    • [C-1-1] La taille de l'écran NE DOIT PAS être mise à l'échelle NE DOIT PAS augmenter la taille de l'écran au-delà de 1,5 fois la DENSITY_DEVICE_STABLE densité native ou produire une dimension d'écran minimale effective inférieure à 320 dp (équivalent au qualificatif de ressource sw320dp), selon la première éventualité.
    • [C-1-2] La taille de l'écran NE DOIT PAS être mise à l'échelle NE DOIT PAS être mise à l'échelle de moins de 0,85 fois la densité d'origine DENSITY_DEVICE_STABLE.

  • 7.1.4.2 Vulkan:

    Voir la révision

    Si les implémentations d'appareils sont compatibles avec Vulkan 1.0 ou version ultérieure, elles:

    • [C-1-3] DOIT mettre en œuvre complètement les API Vulkan 1.0 Vulkan 1.1 pour chaque VkPhysicalDevice énuméré.

    • [C-1-5] NE DOIT PAS énumérer les couches fournies par les bibliothèques en dehors du package d'application, ni fournir d'autres moyens de traçage ou d'interception de l'API Vulkan, sauf si l'attribut android:debuggable de l'application est défini sur true ou si les métadonnées com.android.graphics.injectLayers.enable sont définies sur true .

    • DEVRAIT prendre en charge VkPhysicalDeviceProtectedMemoryFeatures et VK_EXT_global_priority.

    • [C-SR-5] Il est FORTEMENT RECOMMANDÉ de prendre en charge VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory et VK_EXT_global_priority.

    • [C-SR-6] Il est FORTEMENT RECOMMANDÉ d'utiliser SkiaVk avec HWUI.

    Si les implémentations d'appareils sont compatibles avec Vulkan 1.1 et qu'elles déclarent l'un des flags de fonctionnalité Vulkan décrits ici , elles:

    • [C-SR-7] Il est FORTEMENT RECOMMANDÉ de mettre l'extension VK_KHR_external_fence_fd à la disposition des applications tierces et de permettre à l'application d'exporter la charge utile de clôture vers et d'importer la charge utile de clôture à partir de descripteurs de fichiers POSIX, comme décrit ici.

  • 7.3.10. Capteurs biométriques:

    Voir la révision

    Si les appareils disposent de plusieurs capteurs biométriques, ils:

    • [C-7-1] DOIT, lorsqu'une biométrie est bloquée (c'est-à-dire que l'authentification biométrique est désactivée jusqu'à ce que l'utilisateur se déverrouille avec l'authentification principale) ou qu'elle soit temporairement désactivée jusqu'à ce que l'utilisateur attende un intervalle de temps en raison d'un trop grand nombre de tentatives infructueuses, verrouille également toutes les autres biométries d'une classe biométrique inférieure. Dans le cas d'un verrouillage temporalisé, l'intervalle entre les tentatives pour la validation biométrique DOIT être l'intervalle maximal entre les tentatives de toutes les données biométriques dans le verrouillage temporel.

    • [C-SR-12] Sont FORTEMENT RECOMMANDÉS lorsqu'une biométrie est bloquée (c'est-à-dire qu'elle est désactivée jusqu'à ce que l'utilisateur se déverrouille avec l'authentification principale) ou qu'elle soit limitée dans le temps (la biométrie est temporairement désactivée jusqu'à ce que l'utilisateur attende un intervalle de temps) en raison d'un trop grand nombre de tentatives infructueuses, pour verrouiller également toutes les autres données biométriques de la même classe biométrique. Dans le cas d'un verrouillage à durée limitée, l'intervalle entre les tentatives pour la validation biométrique est VIVEMENT RECOMMANDÉ de correspondre à l'intervalle maximal entre les tentatives pour toutes les données biométriques dans le verrouillage temporel.

    • [C-7-2] DOIT inviter l'utilisateur à effectuer l'authentification principale recommandée (par exemple, code, schéma ou mot de passe) afin de réinitialiser le compteur de verrouillage pour une biométrie verrouillée. La biométrie de classe 3 PEUT être autorisée à réinitialiser le compteur de verrouillage pour une biométrie verrouillée de classe identique ou inférieure. Les biométries de classe 2 ou de classe 1 NE DOIVENT PAS être autorisées à effectuer une opération de verrouillage de réinitialisation pour les données biométriques.

    Si les implémentations d'appareils souhaitent traiter un capteur biométrique en tant que classe 1 (anciennement commodité), procédez comme suit:

    • [C-1-12] DOIT avoir un taux d'acceptation de spoof et d'imposteur ne dépassant pas 40 % par espèce d'instrument d'attaque de présentation (PAI), tel que mesuré par les protocoles de test biométrique Android.

    • [C-SR-13] Il est FORTEMENT RECOMMANDÉ de définir un taux d'acceptation du spoof et de l'imposteur ne dépassant pas 30% par espèce d'instrument d'attaque de présentation (PAI), tel que mesuré par les protocoles de test biométrique Android.

    • [C-SR-14] Il est FORTEMENT RECOMMANDÉ de divulguer la classe biométrique du capteur biométrique et les risques associés à son activation.

    • [C-SR-17] Il est FORTEMENT RECOMMANDÉ d'implémenter les nouvelles interfaces AIDL (telles que IFace.aidl et IFingerprint.aidl).

    Si les implémentations d'appareils souhaitent traiter un capteur biométrique en tant que classe 2 (anciennement Faible), procédez comme suit:

    • [C-SR-15] Il est FORTEMENT RECOMMANDÉ de définir un taux d'acceptation du spoof et de l'imposteur ne dépassant pas 20% par espèce d'instrument d'attaque de présentation (PAI), tel que mesuré par les protocoles de test biométrique Android.

    • [C-2-3] DOIT effectuer la mise en 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 dotée d'un canal sécurisé vers l'environnement d'exécution isolé ou sur une machine virtuelle protégée répondant aux exigences de la section 9.17.
    • [C-2-4] DOIT faire en sorte que toutes les données identifiables soient chiffrées et authentifiées de manière cryptographique de sorte qu'elles ne puissent pas être acquises, lues ou modifiées en dehors de l'environnement d'exécution isolé ou d'une puce dotée d'un canal sécurisé vers l'environnement d'exécution isolé, comme indiqué dans les consignes d'implémentation du site du projet Android Open Source ou une machine virtuelle protégée contrôlée par un hyperviseur qui répond aux exigences de la section 9.17.
    • [C-2-5] Pour la biométrie basée sur l'appareil photo, alors que l'authentification ou l'enregistrement biométriques sont en cours :
      • DOIT utiliser la caméra dans un mode qui empêche la lecture ou la modification des trames de caméra en dehors de l'environnement d'exécution isolé, une puce dotée d'un canal sécurisé vers l'environnement d'exécution isolé ou une machine virtuelle protégée contrôlée par un hyperviseur qui répond aux exigences de la section 9.17.
      • Pour les solutions RVB à caméra unique, les images de la caméra PEUVENT être lisibles en dehors de l'environnement d'exécution isolé pour permettre des opérations telles que l'aperçu pour l'enregistrement, mais elles NE DOIVENT EN AUCUN CAS être modifiables.
    • [C-2-7] NE DOIT PAS permettre un accès non chiffré aux données biométriques identifiables ni aux données qui en sont dérivées (telles que les représentations vectorielles continues) pour le processeur d'application en dehors du contexte du TEE ou de la machine virtuelle protégée contrôlée par un hyperviseur qui répond aux exigences de la section 9.17. La mise à niveau des appareils lancés sous Android 9 ou une version antérieure ne sont pas exemptées de l'autorisation C-2-7.

    Si les implémentations d'appareils souhaitent traiter un capteur biométrique en tant que classe 3 (anciennement Strong), elles:

    • [C-SR-16] Il est FORTEMENT RECOMMANDÉ de définir un taux d'acceptation par spoof et par imposteur d'un maximum de 7% par espèce d'instrument d'attaque de présentation (PAI), tel que mesuré par les protocoles de test biométrique Android.

  • 7.3.13. IEEE 802.1.15.4 (UWB):

    Voir la révision

    Si les implémentations d'appareils prennent en charge la norme 802.1.15.4 et exposent la fonctionnalité à une application tierce, elles:

    • [C-1-2] DOIT signaler le flag de fonctionnalité matérielle android.hardware.uwb.
    • [C-1-3] DOIT être compatible avec tous les ensembles de configuration suivants (combinaisons prédéfinies de paramètres FIRA UCI) définis dans la mise en œuvre d'AOSP.
      • CONFIG_ID_1: mesure de la STATIC STS DS-TWR unicast définie par FiRa, mode différé, intervalle de 240 ms.
      • CONFIG_ID_2: mesure de la plage STATIC STS DS-TWR un à plusieurs définie par FiRa, mode différé, intervalle de 200 ms. Cas d'utilisation typique: un smartphone interagit avec de nombreux appareils connectés.
      • CONFIG_ID_3: identique à CONFIG_ID_1, sauf que les données sur l'angle d'arrivée ne sont pas consignées.
      • CONFIG_ID_4: identique à CONFIG_ID_1, sauf que le mode de sécurité P-STS est activé.
      • CONFIG_ID_5: identique à CONFIG_ID_2, sauf que le mode de sécurité P-STS est activé.
      • CONFIG_ID_6: identique à CONFIG_ID_3, sauf que le mode de sécurité P-STS est activé.
      • CONFIG_ID_7: identique à CONFIG_ID_2, sauf que le mode de clé de contrôle individuel P-STS est activé.
    • [C-1-4] DOIT fournir une affordance utilisateur pour permettre à l'utilisateur d'activer/de désactiver la radio UWB.
    • [C-1-5] DOIT faire en sorte que les applications utilisant la radio UWB détiennent l'autorisation UWB_RANGING (sous le groupe d'autorisations NEARBY_DEVICES).

    Le fait de réussir les tests de conformité et de certification pertinents définis par les organisations standards, y compris FIRA, CCC et CSA, permet de s'assurer que la norme 802.1.15.4 fonctionne correctement.

  • 7.4.1. Téléphonie:

    Voir la révision

    Le terme "Téléphonie" utilisé par les API Android et ce document fait spécifiquement référence au matériel permettant de passer des appels vocaux et d'envoyer des SMS, ou d'établir des données mobiles via un réseau mobile (GSM, CDMA, LTE, NR, par exemple) GSM ou CDMA. Un appareil compatible avec la téléphonie peut choisir de proposer tout ou partie des services d'appel, de messagerie et de données selon le produit.

    via un réseau GSM ou CDMA. Bien que ces appels vocaux puissent être ou non commutés de paquets,ils sont considérés comme indépendants de toute connectivité de données pouvant être implémentée à l'aide du même réseau aux fins d'Android. En d'autres termes,la fonctionnalité de téléphonie et les API Android se réfèrent spécifiquement aux appels vocaux et aux SMS. Par exemple, les implémentations d'appareils qui ne peuvent pas passer d'appels ni envoyer/recevoir des 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.

  • 7.4.2. IEEE 802.11 (Wi-Fi):

    Voir la révision

    Si les implémentations d'appareils sont compatibles avec la norme 802.11 et exposent la fonctionnalité à une application tierce, elles:

    • [C-1-4] DOIT prendre en charge le multicast DNS (mDNS) et NE DOIT PAS filtrer les paquets mDNS (224.0.0.251 ou ff02::fb) à tout moment du fonctionnement, y compris lorsque l'écran n'est pas actif, à moins que la suppression ou le filtrage de ces paquets ne soit nécessaire pour rester dans les plages de consommation d'énergie requises par les exigences réglementaires applicables au marché cible. Pour les implémentations d'appareils Android Television, même en mode veille.

  • 7.4.3. Bluetooth:

    Voir la révision

    Si les implémentations d'appareils déclarent FEATURE_BLUETOOTH_LE, elles:

    • [C-SR-2] Il est FORTEMENT RECOMMANDÉ de mesurer et de compenser le décalage Rx pour s'assurer que le RSSI BLE médian est de -60 dBm +/-10 dB à 1 m de distance d'un appareil de référence transmettant à ADVERTISE_TX_POWER_HIGH, où les appareils sont orientés de sorte qu'ils se trouvent sur des "plans parallèles" avec des écrans orientés dans la même direction.
    • [C-SR-3] Il est FORTEMENT RECOMMANDÉ de mesurer et de compenser le décalage Tx pour s'assurer que le RSSI BLE médian est de -60 dBm à +/-10 dB lors de la recherche depuis un appareil de référence situé à 1 m de distance et en transmettant à ADVERTISE_TX_POWER_HIGH, où les appareils sont orientés de sorte qu'ils se trouvent sur des "plans parallèles" avec des écrans orientés dans la même direction.

    • [C-10-3] DOIT mesurer et compenser le décalage Rx pour s'assurer que le RSSI BLE médian est de -55 dBm à +/-10 dB à 1 mètre d'un appareil de référence transmettant à ADVERTISE_TX_POWER_HIGH.
    • [C-10-4] DOIT mesurer et compenser le décalage Tx pour s'assurer que le RSSI BLE médian est de -55 dBm à +/-10 dB lors du balayage depuis un appareil de référence situé à 1 m de distance et en transmettant à ADVERTISE_TX_POWER_HIGH.

    Si les implémentations d'appareils sont compatibles avec la version Bluetooth 5.0, ils:

    • [C-SR-4] Il est FORTEMENT RECOMMANDÉ de fournir une assistance dans les domaines suivants:
    • LE 2M PHY
    • LE Codec PHY
    • Extension LE Advertising Extension
    • Publicité périodique
    • Au moins 10 ensembles d'annonces
    • Au moins huit connexions LE simultanées. Chaque connexion peut appartenir à l'un ou l'autre des rôles de topologie de connexion.
    • Confidentialité de la couche de liaison LE
    • Une "liste de résolution" d'au moins huit entrées

  • 7.4.9. UWB:

    Voir la révision

    • [C-1-7] DOIT s'assurer que la médiane des mesures de distance à 1 m de l'appareil de référence se situe dans les limites de [0,75 m, 1,25 m], où la distance de vérité terrain est mesurée à partir du bord supérieur de l'appareil testé. Tenir la tête vers le haut et incliner la caméra à 45 degrés

  • 7.5.1. Caméra arrière:

    Voir la révision

    Une caméra arrière est une caméra située sur le côté de l'appareil, en face de l'écran, c'est-à-dire des scènes à l'arrière de l'appareil, comme un appareil photo traditionnel.

    Une caméra arrière est une caméra orientée vers l'extérieur qui capture des scènes de l'autre côté de l'appareil, comme une caméra traditionnelle. Sur les appareils portables, il s'agit d'une caméra située sur le côté de l'appareil, en face de l'écran.

  • 7.5.2. Caméra frontale:

    Voir la révision

    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 créer une image de l'utilisateur, par exemple pour la visioconférence et des applications similaires.

    Une caméra frontale est une caméra orientée vers l'utilisateur qui est généralement utilisée pour créer une image de l'utilisateur, par exemple pour la visioconférence et des applications similaires. Sur les appareils portables, il s'agit d'une caméra située du même côté de l'appareil que l'écran.

  • 7.5.3. Caméra externe:

    Voir la révision

    Une caméra externe est une caméra qui peut être connectée physiquement ou détachée de la mise en œuvre de l'appareil à tout moment et orientée dans n'importe quelle direction, comme une caméra USB.

  • 7.5.4. Comportement de l'API Camera:

    Voir la révision

    Les implémentations d'appareils DOIVENT implémenter les comportements suivants pour les API liées aux caméras, pour toutes les caméras disponibles. Implémentations pour les appareils:

    • [C-SR-1] Pour les appareils dotés de plusieurs caméras RVB à proximité et orientées dans la même direction, il est FORTEMENT RECOMMANDÉ de prendre en charge un appareil photo logique qui répertorie les fonctionnalités CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, qui se composent de toutes les caméras RVB orientées dans cette direction en tant que sous-appareils physiques.

  • 7.5.5. Orientation de l'appareil photo:

    Voir la révision

    Les appareils qui répondent à tous les critères suivants sont exemptés de l'exigence ci-dessus:

    • Les implémentations d'appareils qui ne peuvent pas faire l'objet d'une rotation par l'utilisateur, comme les appareils automobiles.

  • 7.10. Retour haptique:

    Voir la révision

    Les appareils destinés à être portés ou à la main peuvent inclure un actionneur haptique à usage général, disponible pour des applications permettant par exemple d'attirer l'attention par le biais de sonneries, d'alarmes, de notifications et de retour tactile général.

    Si les implémentations d'appareils N'incluent PAS un tel actionneur haptique à usage général, celles-ci:

    • [7.10/C] DOIT renvoyer la valeur "false" pour Vibrator.hasVibrator().

    Si les implémentations d'appareils intègrent au moins un actionneur haptique à usage général, elles:

    Si les implémentations d'appareils suivent le mappage des constantes haptiques, elles:

    Consultez la section 2.2.1 pour connaître les exigences spécifiques à chaque appareil.

9. Compatibilité des modèles de sécurité

  • 9.1. Autorisations:

    Voir la révision

    Implémentations pour les appareils:

    • [C-0-4] DOIT comporter une seule et unique implémentation des deux interfaces utilisateur.

    Si les implémentations d'appareils préinstallent les packages qui possèdent l'un des rôles System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence ou System Visual Intelligence, les packages:

    • [C-4-1] DOIT respecter toutes les exigences décrites dans les sections "9.8.6 Capture de contenu" "9.8.6 Données ambiantes et au niveau du système d'exploitation" et 9.8.15 Implémentations de l'API en bac à sable 9.8.15.

    • [C-4-2] NE DOIT PAS disposer de l'autorisation android.permission.INTERNET. Ceci est plus strict que les recommandations FORTEMENT RECOMMANDÉES figurant dans la section 9.8.6.
    • [C-4-3] NE DOIT PAS être lié à d'autres applications, à l'exception des applications système suivantes : Bluetooth, Contacts, Media, Telephony, SystemUI et les composants fournissant des API Internet. Cette valeur est plus stricte que les recommandations FORTEMENT RECOMMANDÉES répertoriées dans la section 9.8.6.

    Si les implémentations d'appareils incluent une application par défaut compatible avec VoiceInteractionService, elles:

    • [C-5-1] NE DOIT PAS accorder ACCESS_FINE_LOCATION comme valeur par défaut pour cette application.

  • 9.5. Compatibilité multi-utilisateur:

    Voir la révision

    Si les implémentations d'appareils créent le profil utilisateur supplémentaire décrit ci-dessus, ils:

    • [C-4-5] DOIT distinguer visuellement les icônes d'application à double instance lorsqu'elles sont présentées aux utilisateurs.
    • [C-4-6] DOIT fournir une affordance d'utilisateurs pour supprimer l'intégralité des données de profil du clone.
    • [C-4-7] DOIT désinstaller toutes les applications de clonage, supprimer les répertoires de données d'applications privées et leur contenu, et supprimer les données de profil du clonage lorsque l'utilisateur choisit de supprimer l'intégralité des données du profil de clonage.
    • DEVRAIT inviter l'utilisateur à supprimer l'intégralité des données du profil de clonage lorsque la dernière application clone sera supprimée.
    • [C-4-8] DOIT informer l'utilisateur que les données de l'application seront supprimées lorsque l'application clone sera désinstallée, ou leur proposer de conserver ces données lorsque celle-ci sera désinstallée de l'appareil.
    • [C-4-9] DOIT supprimer les répertoires de données d'application privées et leur contenu lorsque l'utilisateur choisit de supprimer les données lors de la désinstallation.

    • [C-4-1] DOIT permettre aux applications de l'utilisateur principal de l'appareil de gérer les intents ci-dessous provenant du profil supplémentaire:

      • Intent.ACTION_VIEW
      • Intent.ACTION_SENDTO
      • Intent.ACTION_SEND
      • Intent.ACTION_EDIT
      • Intent.ACTION_INSERT
      • Intent.ACTION_INSERT_OR_EDIT
      • Intent.ACTION_SEND_MULTIPLE
      • Intent.ACTION_PICK
      • Intent.ACTION_GET_CONTENT
      • MediaStore.ACTION_IMAGE_CAPTURE
      • MediaStore.ACTION_VIDEO_CAPTURE

    • [C-4-2] DOIT hériter de toutes les restrictions utilisateur liées aux règles relatives aux appareils et des restrictions sélectionnées pour les non-utilisateurs(liste ci-dessous) appliquées à l'utilisateur principal de l'appareil à ce profil utilisateur supplémentaire.

    • [C-4-3] DOIT autoriser uniquement l'écriture de contacts à partir de ce profil supplémentaire via les intents suivants:

    • [C-4-4] NE DOIT PAS avoir de synchronisations de contacts en cours d'exécution pour les applications exécutées dans ce profil utilisateur supplémentaire.

    • [C-4-14] DOIT disposer d'une gestion distincte des autorisations et de l'espace de stockage pour les applications exécutées dans ce profil supplémentaire

    • [C-4-5] DOIT autoriser uniquement les applications du profil supplémentaire ayant une activité de lanceur d'applications à accéder aux contacts déjà accessibles au profil utilisateur parent.

  • 9.7. Fonctionnalités de sécurité:

    Voir la révision

    Une technologie de sécurité de la mémoire est une technologie qui atténue au moins les classes de bugs suivantes avec une probabilité élevée (supérieure à 90%) dans les applications qui utilisent l'option de fichier manifeste android:memtagMode:

    • Débordement de la mémoire tampon du tas de mémoire
    • utiliser après libération
    • double sans frais
    • Wild free (sans pointeur non malloc)

    Implémentations pour les appareils:

    • [C-SR-15] Il est FORTEMENT RECOMMANDÉ de définir ro.arm64.memtag.bootctl_supported.

    Si les implémentations d'appareils définissent la propriété système ro.arm64.memtag.bootctl_supported sur "true", elles:

    • [C-3-1] DOIT autoriser la propriété système arm64.memtag.bootctl à accepter une liste des valeurs suivantes séparées par une virgule, avec l'effet souhaité appliqué au prochain redémarrage suivant:

      • memtag: une technologie de sécurité de la mémoire telle que définie ci-dessus est activée.
      • memtag-once: une technologie de sécurité de la mémoire telle que définie ci-dessus est activée temporairement et est automatiquement désactivée au prochain redémarrage.
      • memtag-off: une technologie de sécurité de la mémoire telle que définie ci-dessus est désactivée.

    • [C-3-2] DOIT autoriser l'utilisateur shell à définir arm64.memtag.bootctl.

    • [C-3-3] DOIT autoriser tout processus à lire arm64.memtag.bootctl.

    • [C-3-4] DOIT définir arm64.memtag.bootctl sur l'état actuellement demandé au démarrage. Il DOIT également mettre à jour la propriété si l'implémentation de l'appareil permet de modifier l'état sans modifier la propriété système.

    • [C-SR-16] Il est FORTEMENT RECOMMANDÉ d'afficher un paramètre pour les développeurs qui définit la memtag unique et redémarre l'appareil. Avec un bootloader compatible, le projet Android Open Source répond aux exigences ci-dessus via le protocole de bootloader MTE.

    • [C-SR-17] Il est FORTEMENT RECOMMANDÉ d'afficher un paramètre permettant à l'utilisateur d'activer memtag dans le menu "Security Settings" (Paramètres de sécurité).

  • 9.8.2. Enregistrement:

    Voir la révision

    Implémentations pour les appareils:

    • [C-0-2] DOIT afficher un avertissement utilisateur et obtenir le consentement explicite de l'utilisateur permettant la capture d'informations sensibles affichées sur l'écran de l'utilisateurqui inclut exactement le même message qu'AOSP à chaque fois à chaque session de capture de l'écran casting or (diffusion ou enregistrement d'écran) est activé via les API propriétaires .MediaProjection.createVirtualDisplay()VirtualDeviceManager.createVirtualDisplay() NE DOIT PAS fournir aux utilisateurs une affordance leur permettant de désactiver l'affichage futur du consentement de l'utilisateur.

    • [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'afficher un avertissement utilisateur. Il s'agit exactement du même message que celui implémenté dans AOSP, mais PEUVENT être modifiés tant que le message avertit clairement l'utilisateur que des informations sensibles sur son écran ont été capturées.

    • [C-0-4] NE DOIT PAS fournir aux utilisateurs une affordance de désactiver les futures invites de l'utilisateur pour capturer l'écran, sauf si la session est lancée par une application système que l'utilisateur a autorisée à associate() avec le profil d'appareil android.app.role.COMPANION_DEVICE_APP_STREAMING ou android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING.

  • 9.8.6. Données au niveau de l'OS et données ambiantes : cette section a été renommée Données au niveau de l'OS et données ambiantes au lieu de Capture de contenu et Recherche dans les applications.

    Voir la révision

    Android, via les API système ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query ou par d'autres moyens propriétaires, est compatible avec un mécanisme d'implémentation d'appareil permettant de capturer les interactions suivantes avec les données d'application entre les applications et l'utilisateur données sensibles:

    • Tout écran ou autre donnée envoyée au système via AugmentedAutofillService.
    • Tout écran ou autre donnée accessible via l'API Content Capture.
    • Tout écran ou autre donnée accessible via l'API FieldClassificationService
    • Toutes les données d'application transmises au système via l'API AppSearchManager et accessibles via AppSearchGlobalManager.query.

    • Tous les autres événements qu'une application fournit au système via l'API Content Capture ou l'API AppSearchManager, une API Android et propriétaire aux capacités similaires.

    • Données audio obtenues à la suite de l'utilisation de SpeechRecognizer#onDeviceSpeechRecognizer() par l'implémentation de la reconnaissance vocale.
    • Données audio obtenues (en continu) en arrière-plan via AudioRecord, SoundTrigger ou d'autres API Audio, et qui n'entraînent pas d'indicateur visible par l'utilisateur
    • Données de caméra obtenues en arrière-plan (en continu) via CameraManager ou d'autres API Camera, et qui n'entraînent pas d'indicateur visible par l'utilisateur

    Si les implémentations d'appareils capturent l'une des données ci-dessus, celles-ci:

    • [C-1-3] NE DOIT envoyer toutes ces données et le journal de l'appareil qu'à l'aide d'un mécanisme protégeant la confidentialité, sauf avec le consentement explicite de l'utilisateur chaque fois que les données sont partagées. Le mécanisme de protection de la confidentialité est défini comme "ceux qui autorisent uniquement une analyse globale 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'éviter l'introspection de données utilisateur spécifiques (par exemple, mises en œuvre à l'aide d'une technologie de confidentialité différentielle telle que RAPPOR).

    • [C-1-5] NE DOIT PAS partager ces données avec d'autres composants de l'OS qui ne respectent pas les exigences décrites dans la section actuelle (9.8.6 Capture de contenu, données ambiantes et au niveau de l'OS), sauf avec le consentement explicite de l'utilisateur chaque fois qu'elles sont partagées. À moins que cette fonctionnalité ne soit conçue en tant qu'API SDK Android (AmbientContext, HotwordDetectionService).

    • [C-1-6] DOIT fournir une affordance à l'utilisateur pour effacer les données que l'implémentation de ContentCaptureService ou le moyen propriétaire collecte si quand les données sont stockées sous quelque forme que ce soit sur l'appareil. Si l'utilisateur choisit d'effacer les données, il DOIT supprimer toutes les données historiques collectées.

    • [C-SR-3] Il est FORTEMENT RECOMMANDÉ d'être mis en œuvre avec l'API SDK Android ou un dépôt Open Source similaire appartenant à un OEM, et / ou dans une implémentation en bac à sable (voir 9.8.15 Implémentations d'API en bac à sable).

    Android, via SpeechRecognizer#onDeviceSpeechRecognizer(), permet d'effectuer une reconnaissance vocale sur l'appareil sans impliquer le réseau. Toute implémentation de la reconnaissance vocale sur l'appareil DOIT respecter les règles décrites dans cette section.

  • 9.8.10. Rapport de bug de connectivité:

    Voir la révision

    Si les implémentations d'appareils déclarent le flag de fonctionnalité android.hardware.telephony, elles:

    • [C-1-4] Les rapports générés avec BUGREPORT_MODE_TELEPHONY DOIVENT contenir au moins les informations suivantes :
      • Vidage SubscriptionManagerService

  • 9.8.14. Gestionnaire d'identifiants: supprimé

  • 9.8.15. Implémentations d'API en bac à sable: nouvelle section

    Voir la révision

    Via un ensemble d'API déléguées, Android fournit un mécanisme permettant de traiter les données sécurisées au niveau de l'OS et des données ambiantes. Ce traitement peut être délégué à un APK préinstallé avec accès privilégié et fonctionnalités de communication réduites, appelé "implémentation d'API en bac à sable".

    Toute implémentation d'API en bac à sable:

    • [C-0-1] NE DOIT PAS demander l'autorisation INTERNET.
    • [C-0-2] DOIT accéder à Internet uniquement via des API structurées reposant sur des implémentations Open Source accessibles au public qui utilisent des mécanismes protégeant la confidentialité, ou indirectement via les API du SDK Android. Le mécanisme de protection de la confidentialité est défini comme "ceux qui autorisent uniquement une analyse globale 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'éviter que des données utilisateur spécifiques ne soient introspectives (par exemple, mises en œuvre à l'aide d'une technologie de confidentialité différentielle telle que RAPPOR).
    • [C-0-3] DOIT garder les services séparés des autres composants du système (par exemple, sans lier le service ou partager des ID de processus), sauf dans les cas suivants :
      • Téléphonie, contacts, UI du système et médias
    • [C-0-4] NE DOIT PAS autoriser les utilisateurs à remplacer les services par une application ou un service qu'ils peuvent installer.
    • [C-0-5] DOIT autoriser uniquement les services préinstallés à capturer de telles données. Sauf si la fonctionnalité de remplacement est intégrée à AOSP (par exemple, pour les applications d'assistant numérique).
    • [C-0-6] NE DOIT PAS permettre à des applications autres que le mécanisme de services préinstallés de capturer de telles données. Sauf si cette fonctionnalité de capture est implémentée avec une API du SDK Android,
    • [C-0-7] DOIT fournir une affordance à l'utilisateur pour désactiver les services.
    • [C-0-8] NE DOIT PAS omettre les affordances de l'utilisateur pour gérer les autorisations Android détenues par les services et qui suivent le modèle d'autorisations Android décrit dans la section 9.1. Autorisation.

  • 9.8.16. Audio en continu et données de la caméra: nouvelle section

    Voir la révision

    En plus des exigences décrites dans les sections 9.8.2 "Enregistrement", "9.8.6" concernant les données d'OS et de luminosité ambiante, et les implémentations d'API Sandboxed 9.8.15, les implémentations qui utilisent des données audio obtenues en arrière-plan (en continu) via AudioRecord, SoundTrigger ou d'autres API audio, OU des données de caméra obtenues en arrière-plan (en continu) via CameraManager ou d'autres API Camera:

    • [C-0-1] DOIT appliquer un indicateur correspondant (caméra et/ou micro, conformément à la section 9.8.2 "Enregistrement"), à moins que :
    • [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'exiger le consentement de l'utilisateur pour chaque fonctionnalité utilisant ces données. Il doit être désactivé par défaut.
    • [C-SR-2] FORTEMENT RECOMMANDÉ d'appliquer le même traitement (c'est-à-dire de respecter les restrictions décrites dans les sections 9.8.2 Enregistrement, 9.8.6 Données ambiantes et au niveau du système d'exploitation, 9.8.15 Implémentations de l'API en bac à sable et 9.8.16 Données de l'appareil photo et de l'audio en continu) aux données de la caméra provenant d'un wearable distant.

    Si les données de l'appareil photo sont fournies à partir d'un accessoire connecté distant et que vous y accédez sous une forme non chiffrée en dehors de l'OS Android, une implémentation en bac à sable ou une fonctionnalité de bac à sable créée par WearableSensingManager, les conditions suivantes s'appliquent:

    • [C-1-1] DOIT indiquer à l'accessoire connecté distant qu'il doit y afficher un indicateur supplémentaire.

    Si les appareils permettent d'interagir avec une application d'assistant numérique sans le mot clé attribué (soit en gérant des requêtes utilisateur génériques, soit en analysant la présence des utilisateurs via l'appareil photo):

    • [C-2-1] DOIT s'assurer que cette implémentation est fournie par un package disposant du rôle android.app.role.ASSISTANT.
    • [C-2-2] DOIT s'assurer que cette implémentation utilise les API Android HotwordDetectionService et/ou VisualQueryDetectionService.

  • 9.8.17. Télémétrie: nouvelle section

    Voir la révision

    Android stocke les journaux système et d'application à l'aide des API StatsLog. Ces journaux sont gérés via les API StatsManager, qui peuvent être utilisées par des applications système privilégiées.

    StatsManager permet également de collecter des données classées comme sensibles à partir d'appareils dotés d'un mécanisme protégeant la confidentialité. En particulier, l'API StatsManager::query permet d'interroger des catégories de métriques limitées définies dans StatsLog.

    Toute implémentation interrogeant et collectant des métriques restreintes à partir de StatsManager:

    • [C-0-1] DOIT être la seule application/implémentation sur l'appareil et détenir l'autorisation READ_RESTRICTED_STATS.
    • [C-0-2] DOIT envoyer uniquement des données de télémétrie et le journal de l'appareil à l'aide d'un mécanisme protégeant la confidentialité. Le mécanisme de protection de la confidentialité est défini comme "ceux qui autorisent uniquement une analyse globale 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 donnée utilisateur spécifique (par exemple, mise en œuvre à l'aide d'une technologie de confidentialité différentielle telle que RAPPOR).
    • [C-0-3] NE DOIT PAS associer ces données à une identité d'utilisateur (telle qu'un compte) sur l'appareil.
    • [C-0-4] NE DOIT PAS partager ces données avec d'autres composants de l'OS qui ne respectent pas les exigences décrites dans la section actuelle (9.8.17 Télémétrie protégeant la confidentialité).
    • [C-0-5] DOIT fournir une affordance utilisateur pour activer/désactiver la collecte, l'utilisation et le partage de télémétrie protégeant la confidentialité.
    • [C-0-6] DOIT fournir une affordance à l'utilisateur pour effacer les données collectées par l'implémentation si celles-ci sont stockées sur l'appareil, sous quelque forme que ce soit. Si l'utilisateur a choisi d'effacer les données, il DOIT supprimer toutes les données actuellement stockées sur l'appareil.
    • [C-0-7] DOIT divulguer la mise en œuvre du protocole sous-jacent protégeant la confidentialité dans un dépôt Open Source.
    • [C-0-8 ]DOIT appliquer des règles de sortie des données dans cette section pour contrôler la collecte de données dans les catégories de métriques limitées définies dans StatsLog.

  • 9.10. Intégrité de l'appareil:

    Voir la révision

    Implémentations sur les appareils

    Si les implémentations d'appareils permettent de vérifier le contenu des fichiers page par page, elles :

    • [C-0-3 C-2-1] permet de vérifier de manière cryptographique le contenu d'un fichier par rapport à une clé de confiance sans lire l'intégralité du fichier.

    • [C-0-4 C-2-2] NE DOIT PAS autoriser la réussite des requêtes de lecture sur un fichier protégé lorsque le contenu en lecture ne se vérifie pas à l'aide d'une clé approuvée n'est pas validé comme indiqué ci-dessus.

    • [C-2-4] DOIT renvoyer la somme de contrôle du fichier dans O(1) pour les fichiers activés.

  • 9.11. Clés et identifiants:

    Voir la révision

    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 de chiffrement via l'API KeyChain ou l'API Keystore. Implémentations pour les appareils:

    • [C-0-3] DOIT limiter le nombre de tentatives d'authentification principale ayant échoué.
    • [C-SR-2] Il est FORTEMENT RECOMMANDÉ d'implémenter un plafond de 20 tentatives d'authentification principale ayant échoué. Si les utilisateurs donnent leur consentement et activent la fonctionnalité, il est fortement recommandé de rétablir la configuration d'usine après avoir dépassé le nombre maximal de tentatives d'authentification principale ayant échoué.

    Si les implémentations d'appareils ajoutent ou modifient des méthodes d'authentification pour déverrouiller l'écran de verrouillage s'ils sont basés sur un secret connu et utilisent une nouvelle méthode d'authentification considérée comme un moyen sécurisé de verrouiller l'écran, procédez comme suit:

    • [C-SR-3] Il est FORTEMENT RECOMMANDÉ d'utiliser un code PIN d'au moins six chiffres, ou de manière équivalente une entropie de 20 bits.
    • [C-2-1] Un code PIN de moins de six chiffres NE DOIT PAS permettre la saisie automatique sans l'intervention de l'utilisateur, afin d'éviter d'en révéler la longueur.

  • 9.11.1. Écran de verrouillage sécurisé, authentification et appareils virtuels :

    Voir la révision

    Implémentations pour les appareils:

    • [C-0-1] DOIT limiter le nombre de tentatives d'authentification principale ayant échoué.
    • [C-SR-5] Il est FORTEMENT RECOMMANDÉ d'implémenter un plafond de 20 tentatives d'authentification principale ayant échoué. Si les utilisateurs donnent leur consentement et activent la fonctionnalité, il est fortement recommandé de rétablir la configuration d'usine après avoir dépassé le nombre maximal de tentatives d'authentification principale ayant échoué.

    Si les implémentations d'appareils définissent un code PIN numérique comme méthode d'authentification principale recommandée:

    • [C-SR-6] Il est FORTEMENT RECOMMANDÉ d'utiliser un code PIN d'au moins six chiffres ou de l'équivalent d'une entropie de 20 bits.
    • [C-SR-7] Il est FORTEMENT RECOMMANDÉ de NE PAS autoriser la saisie automatique sans l'intervention de l'utilisateur pour éviter d'en révéler la longueur.

    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, ils:

    [C-7-8] L'utilisateur DOIT être invité à utiliser l'une des méthodes d'authentification principales recommandées (par exemple, par code, schéma ou mot de passe) au moins une fois toutes les 72 heures ou moins, sauf si la sécurité de l'utilisateur (par exemple, en cas de distraction au volant) est préoccupante.

    Si les implémentations d'appareils permettent aux applications de créer des écrans virtuels secondaires et de prendre en charge les événements d'entrée associés, par exemple via VirtualDeviceManager, et que les écrans ne sont pas marqués VIRTUAL_DISPLAY_FLAG_SECURE, ils:

    [C-13-10] DOIT désactiver l'installation d'applications lancées à partir d'appareils virtuels.

  • 9.17. Framework de virtualisation Android:

    Voir la révision

    Si l'appareil est compatible avec les API du framework de virtualisation Android (android.system.virtualmachine.*), l'hôte Android:

    • [C-1-1] DOIT prendre en charge toutes les API définies par le package android.system.virtualmachine.
    • [C-1-2] NE DOIT PAS modifier le modèle d'autorisation ni le modèle SELinux d'Android pour la gestion des machines virtuelles protégées (pVM).

    • [C-1-3] NE DOIT PAS modifier, omettre ni remplacer les règles "Neverallow" présentes dans le système/sepolicy fournis dans le projet Android Open Source (AOSP) en amont. La stratégie DOIT être compilée avec toutes les règles ne pas autoriser présentes.

    • [C-1-4] NE DOIT autoriser que le code signé par la plate-forme et les applications privilégiéesNE DOIVENT PAS autoriser de code non approuvé (applications tierces, par exemple) à créer et à exécuter une machine virtuelle protégéepVM. Remarque: Cela pourrait changer dans les prochaines versions d'Android.

    • [C-1-5] NE DOIT PAS autoriser une machine virtuelle protégée pVM à exécuter du code qui ne fait pas partie de l'image d'usine ou de leurs mises à jour. Tout élément non couvert par le démarrage validé Android (par exemple, les fichiers téléchargés depuis Internet ou téléchargés indépendamment) NE DOIT PAS être exécuté sur une machine virtuelle protégée .

    • [C-1-5] DOIT uniquement autoriser une pVM non débogable à exécuter du code à partir de l'image d'usine ou de leurs mises à jour de plate-forme, y compris les mises à jour des applications privilégiées.

    Si l'appareil est compatible avec les API du framework de virtualisation Android (android.system.virtualmachine.*), toute instance de machine virtuelle protégée pVM :

    • [C-2-1] DOIT pouvoir exécuter tous les systèmes d'exploitation disponibles dans l'APEX de virtualisation dans une machine virtuelle protégée pVM .
    • [C-2-2] NE DOIT PAS autoriser une machine virtuelle protégée pVM à exécuter un système d'exploitation qui n'est pas signé par le responsable de l'implémentation de l'appareil ou le fournisseur de l'OS.
    • [C-2-3] NE DOIT PAS autoriser une machine virtuelle protégée pVM à exécuter des données en tant que code (par exemple, SELinux ne permet jamais d'exécuter la commande "execmem").

    • [C-2-4] NE DOIT PAS modifier, omettre ni remplacer les règles "Neverallow" présentes dans le système/sepolicy/microdroid fournis en amont dans le projet Android Open Source (AOSP).

    • [C-2-5] DOIT mettre en œuvre des mécanismes de défense en profondeur (machine virtuelle protégée pVM , par exemple SELinux pour les VMp), même pour les systèmes d'exploitation autres que Microdroid.
    • [C-2-6] DOIT s'assurer que la VM préemptives échoue le micrologiciel refuse de démarrer si il ne peut pas vérifier les images initiales que la VM va exécuter ne peut pas être vérifiée. La vérification DOIT être effectuée dans la VM.
    • [C-2-7] DOIT s'assurer que la VM préemptives échoue le micrologiciel refuse de démarrer si l'intégrité du fichier instance.img est compromise.

    Si l'appareil est compatible avec les API du framework de virtualisation Android (android.system.virtualmachine.*), l'hyperviseur:

    • [C-3-1] DOIT s'assurer que les pages de mémoire appartenant exclusivement à une VM (pVM ou VM hôte) ne sont accessibles qu'à la machine virtuelle elle-même ou à l'hyperviseur, et non à d'autres machines virtuelles, qu'elles soient protégées ou non. NE DOIT PAS permettre à une pVM d'accéder à une page appartenant à une autre entité (c'est-à-dire une autre pVM ou un hyperviseur), sauf s'il est explicitement partagé par le propriétaire de la page. Cela inclut la VM hôte. Cela s'applique à la fois aux accès au processeur et à la zone de marché désignée.
    • [C-3-2] DOIT effacer une page après son utilisation par une pVM et avant qu'elle ne soit renvoyée à l'hôte (par exemple, si la pVM est détruite).
    • [C-3-3SR-1] EST FORTEMENT RECOMMANDÉ pour s'assurer que DOIT s'assurer que le micrologiciel des VM préemptives est chargé et exécuté avant tout code dans une VM préemptive.
    • [C-3-4] DOIT s'assurer que chaque VM dérive un secret par VM que {Boot Certificate Chain (BCC) and Compound Device Identifier (CDI) provided to a pVM instance ne peut être dérivé que par cette instance de VM particulière, et qui est modifié lors d'une réinitialisation d'usine et de l'OTA.

    Si l'appareil est compatible avec les API du framework de virtualisation Android, procédez comme suit dans tous les domaines:

    • [C-4-1] NE DOIT PAS fournir à une pVM une fonctionnalité permettant de contourner le modèle de sécurité Android.

    Si l'appareil est compatible avec les API du framework de virtualisation Android:

    • [C-5-1] DOIT être capable de prendre en charge la compilation isolée, mais peut désactiver la fonctionnalité de compilation isolée d'une mise à jour de l'environnement d'exécution ART livré avec l'appareil.

    Si l'appareil prend en charge les API du framework de virtualisation Android, procédez comme suit pour la gestion des clés:

    • [C-6-1] DOIT utiliser la chaîne DICE racine à un point que l'utilisateur ne peut pas modifier, même sur des appareils déverrouillés. (pour éviter toute usurpation d'identité).

    • [C-SR-26-2] Il est VIVEMENT RECOMMANDÉ d'utiliser DICE comme mécanisme de dérivation des secrets par VM. DOIT utiliser les dés correctement, c'est-à-dire fournir les valeurs correctes.

Haut de page