Définition de compatibilité Android 14

1. Introduction

Ce document énumère les conditions à remplir pour que les appareils afin d'être compatible avec Android 14.

Les valeurs "DOIT", "NE DOIT PAS", "OBLIGATOIRE", "DEVRAIT", "NE DEVRAIT PAS", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT" et "FACULTATIF" conformément à la norme IETF défini dans le document RFC 2119.

Tel qu'il est utilisé dans ce document, ou « équipe de mise en œuvre » est une personne ou une organisation qui développe une solution matérielle/logicielle exécutant Android 14. Une « implémentation de l'appareil » ou « implémentation » est le solution matérielle/logicielle ainsi développée.

Pour être considéré comme compatible avec Android 14, les implémentations DOIVENT répondre aux exigences présentées dans le présent document Définition, y compris tout document intégré via une référence.

Lorsque cette définition ou les tests logiciels décrits dans section 10 est silencieuse, ambiguë ou incomplètes, il incombe au responsable de la mise en œuvre de l'appareil de s'assurer la compatibilité avec les implémentations existantes.

C'est pourquoi le projet Android Open Source est à la fois la référence et l'implémentation préférée d'Android. Appareil les responsables de la mise en œuvre sont FORTEMENT RECOMMANDÉS de baser leurs implémentations sur le plus possible en "amont" le code source disponible dans Projet Android Open Source. Certains composants peuvent être par d'autres implémentations, il est FORTEMENT RECOMMANDÉ de ne pas respecter cette pratique, car la réussite aux tests logiciels plus difficile. Il incombe à l'équipe chargée de la mise en œuvre de s'assurer la compatibilité comportementale avec l'implémentation Android standard, y compris et au-delà de la suite de tests de compatibilité. Enfin, notez que certains composants les substitutions et les modifications sont explicitement interdites par ce document.

De nombreuses ressources dont le lien figure dans ce document sont issues directement ou indirectement à partir du SDK Android et sera fonctionnellement identique au dans la documentation de ce SDK. Dans tous les cas où cette compatibilité La définition ou la suite de tests de compatibilité n'est pas d'accord avec le SDK documentation, la documentation du SDK est considérée comme faisant autorité. Tous les problèmes techniques et les détails fournis dans les ressources associées de ce document sont considérés par inclusion comme faisant partie de la présente Définition de compatibilité.

1.1 Structure du document

1.1.1. Exigences par type d'appareil

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

Toutes les autres exigences qui s'appliquent universellement à tous les appareils Android. mises en œuvre, sont présentées dans les sections après la section 2. Ces exigences sont désignées sous le terme "Configuration requise". dans ce document.

1.1.2. Identifiant du prérequis

L'identifiant de la condition est attribué pour les exigences DOIT.

  • L'identifiant est attribué uniquement pour les exigences DOIT.
  • Les exigences FORTEMENT RECOMMANDÉES sont signalées par la mention [SR], mais aucun identifiant n'est attribué.
  • Cet ID se compose des éléments suivants : ID du type d'appareil, ID de la condition, ID de la configuration requise. (par exemple, C-0-1).

Chaque ID est défini comme suit:

  • ID du type d'appareil (pour plus d'informations, voir 2. Types d'appareils).
    • C: Core (exigences qui s'appliquent à toutes les implémentations d'appareils Android)
    • H: Appareil portable Android
    • T: Un appareil Android Television
    • R: L'implémentation d'Android Automotive
    • W: Implémentation d'Android Watch
    • Onglet: Mise en œuvre des tablettes Android
  • ID de la condition
    • Lorsque cette condition est inconditionnelle, cet ID est défini sur 0.
    • Lorsque l'exigence est conditionnelle, le chiffre 1 est attribué pour la première condition et le nombre incrémente de 1 dans la même section et pour le même type d'appareil.
  • Identifiant du prérequis
    • Cet identifiant commence à partir de 1 et incrémente de 1 au sein de la même section et dans le même état.

1.1.3. Identifiant de l'exigence formulée dans la section 2

Les identifiants des exigences de la section 2 se divisent en deux parties. Le premier correspond à un ID de section tel que décrit ci-dessus. La deuxième partie identifie et les exigences spécifiques au facteur de forme.

suivi de l'identifiant du prérequis décrit ci-dessus.

  • Dans la section 2, l'ID comprend les éléments suivants : ID de section / ID du type d'appareil – ID de la condition – ID de la condition requise (par exemple, 7.4.3/A-0-1).

2. Types d'appareils

Le projet Android Open Source fournit une pile logicielle pouvant être utilisée pour divers types d'appareils et facteurs de forme. Pour assurer la sécurité des appareils, la pile logicielle, y compris tout OS de remplacement ou un noyau alternatif doit s'exécuter dans un environnement sécurisé, comme décrit dans la section 9 et ailleurs dans le présent CDD. Il existe plusieurs types d'appareils qui disposent d'un écosystème de distribution d'applications relativement bien établi.

Cette section décrit ces types d'appareils, ainsi que les exigences supplémentaires recommandations applicables à chaque type d'appareil.

Toutes les implémentations d'appareils Android qui ne correspondent à aucun des éléments décrits types d'appareils DOIT respecter toutes les exigences décrites dans les autres sections de ce Définition de compatibilité.

2.1 Configurations des appareils

Pour les principales différences de configuration matérielle par appareil consultez les exigences spécifiques à l'appareil qui suivent dans cette section.

2.2. Configuration requise pour les appareils portables

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

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

  • Disposer d'une source d'alimentation qui permet la mobilité, telle qu'une batterie.
  • ont une taille d'écran diagonale comprise dans la plage 4 pouces 3,3 pouces (ou 2,5 pouces pour les implémentations d'appareils livrées avec le niveau d'API 29 précédemment) à 8 pouces.
  • L'interface de saisie est tactile.

Les exigences supplémentaires figurant dans le reste de cette section sont spécifiques à Android. Implémentations d'appareils portables

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

2.2.1. Matériel

Implémentations pour les appareils portables:

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

  • [7.1.1.3/H-SR-1] SONT FORTEMENT RECOMMANDÉS fournir aux utilisateurs une affordance de modifier la taille d'affichage (densité d'écran).

  • [7.1.1.1/H-0-2] DOIT être compatible avec la composition GPU des éléments suivants : la taille de la mémoire tampon du graphique doit être au moins égale à la résolution la plus élevée l'écran.

Commencer les nouvelles exigences

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

  • [7.1.1.3/H-0-1]* DOIT définir la valeur de DENSITY_DEVICE_STABLE doit être supérieure ou égale à 92% de la densité physique réelle de l'écran correspondant.

Mettre fin aux nouvelles exigences

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 rendre l'écran logique mis à disposition pour des applications tierces doit être d'au moins 2 pouces sur le bord(s) court(s) et 2,7 pouces sur le(s) bord(s) long(s). Les appareils livrés avec le niveau d'API Android 29 ou version antérieure PEUVENT être sont exemptés de cette exigence.

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

  • [7.1.1.1/H-2-1]* DOIT rendre l'écran logique mis à disposition pour des applications tierces doivent être d’au moins 2,7 pouces sur bord(s) court(s). Les appareils livrés avec le niveau d'API Android 29 ou version antérieure PEUVENT être sont exemptés de cette exigence.

Commencer les nouvelles exigences

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

Mettre fin aux nouvelles exigences

Si des implémentations d'appareils portables sont compatibles avec la technologie High Dynamic Range s'affiche via Configuration.isScreenHdr() , ils:

  • [7.1.4.5/H-1-1] DOIT indiquer que le champ EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace et VK_EXT_hdr_metadata extensions.

Implémentations pour les appareils portables:

  • [7.1.4.6/H-0-1] DOIT indiquer si l'appareil prend en charge la capacité de profilage GPU via une propriété système graphics.gpu.profiler.support

Si les implémentations d'appareils portables déclarent la compatibilité via une propriété système graphics.gpu.profiler.support:

Implémentations pour les appareils portables:

  • [7.1.5/H-0-1] DOIT inclure la prise en charge des anciennes versions mode de compatibilité des applications tel qu'il est implémenté par l'application Android Open Source en amont le code source. Autrement dit, les implémentations d'appareils NE DOIVENT PAS modifier les déclencheurs ou seuils auxquels le mode de compatibilité est activé et NE DOIVENT PAS modifier le paramètre du mode de compatibilité.
  • [7.2.1/H-0-1] DOIT inclure la prise en charge des applications tierces Applications de l'éditeur de mode de saisie (IME).
  • [7.2.3/H-0-2] DOIT envoyer à la fois l'appui normal et l'appui prolongé événement de la fonction Retour (KEYCODE_BACK) à l'application de premier plan. Ces événements NE DOIVENT PAS être utilisés par le système et PEUT être déclenché par l'extérieur de l'appareil Android (p.ex., du matériel externe clavier connecté à l'appareil Android).
  • [7.2.3/H-0-3] DOIT fournir la fonction Home sur tous les écrans compatibles Android qui fournissent l'écran d'accueil.
  • [7.2.3/H-0-4] DOIT fournir la fonction "Retour" sur toutes les écrans compatibles avec Android et la fonction Récents sur au moins un les écrans compatibles avec Android.
  • [7.2.4/H-0-1] DOIT être compatible avec la saisie tactile.
  • [7.2.4/H-SR-1] EST FORTEMENT RECOMMANDÉ de lancer le l'application d'assistance sélectionnée par l'utilisateur, c'est-à-dire l'application qui implémente VoiceInteractionService, ou une activité gérant ACTION_ASSIST en appuyant de manière prolongée sur KEYCODE_MEDIA_PLAY_PAUSE ou KEYCODE_HEADSETHOOK si l'activité au premier plan ne gère pas ces événements d'appui prolongé.
  • [7.3.1/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un modèle à 3 axes accéléromètre.

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

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

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

  • [7.3.3/H-2-1] DOIT indiquer les mesures GNSS dès qu'elles même si la position calculée à partir du GPS/GNSS n'est pas encore signalée.
  • [7.3.3/H-2-2] DOIT signaler les pseudo-plages et pseudo-plages GNSS en ciel ouvert, après avoir déterminé l'emplacement, immobile ou se déplaçant à moins de 0,2 mètre par seconde au carré de accélération, sont suffisantes pour calculer la position à 20 mètres près et la vitesse à une distance de 0,2 mètre par seconde, au moins 95% du temps.

Si les appareils portables sont équipés d'un gyroscope à trois axes:

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

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

  • [7,3,8/H] DEVRAIT inclure un capteur de proximité.

Implémentations pour les appareils portables:

  • [7.3.11/H-SR-1] SONT FORTEMENT RECOMMANDÉS pour prendre en charge le capteur de pose avec 6 degrés de liberté.
  • [7.4.3/H] DEVRAIT inclure la prise en charge du Bluetooth et Bluetooth LE.

Si les appareils prennent en charge le protocole Wi-Fi Neighbor Awareness Networking (NAN) déclarant PackageManager.FEATURE_WIFI_AWARE et l'emplacement Wi-Fi (Wi-Fi Round Trip Time (DAR) en déclarant PackageManager.FEATURE_WIFI_RTT, puis:

  • [7.4.2.5/H-1-1] DOIT indiquer la plage avec précision à à +/-1 mètre pour une bande passante de 160 MHz au 68e centile (tel que calculé avec la fonction de distribution cumulative), de +/-2 mètres à une bande passante de 80 MHz à au 68e centile, +/-4 mètres à une bande passante de 40 MHz au 68e centile, et +/-8 mètres à une bande passante de 20 MHz au 68e centile à des distances de 10 1 m, 3 m et 5 m, comme l'observaient API Android WifiRttManager#startRanging

  • [7.4.2.5/H-SR-1] Il est FORTEMENT RECOMMANDÉ de signaler avec précision à +/-1 mètre pour une bande passante de 160 MHz au 90e centile centile (calculé à l'aide de la fonction de distribution cumulative), +/-2 mètres avec une bande passante de 80 MHz au 90e centile, +/-4 mètres à 40 MHz de bande passante au 90e centile, et de +/-8 mètres à 20 MHz au niveau 90e centile à une distance de 10 cm, comme observé via les API Android WifiRttManager#startRanging

Il est FORTEMENT RECOMMANDÉ de suivre les étapes de configuration des mesures spécifiées dans Étalonnage de la présence

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 la réception de messages pour garantir que la valeur médiane du RSSI BLE est de -50 dBm +/-15 dB à 1 m de distance appareil de référence émettant à ADVERTISE_TX_POWER_HIGH.
  • [7.4.3/H-1-4] DOIT mesurer et compenser la valeur Tx pour garantir que la valeur médiane du RSSI BLE est de -50 dBm +/-15 dB lors de la recherche depuis dispositif de référence positionné à une distance de 1 m et émettant à ADVERTISE_TX_POWER_HIGH

Mettre fin aux nouvelles exigences

Si les implémentations d'appareils portables incluent une caméra logique qui liste des fonctionnalités à l'aide CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, ils:

  • [7.5.4/H-1-1] DOIT disposer d'un champ de vision normal par défaut et il DOIT être compris entre 50 et degrés.

Implémentations pour les appareils portables:

  • [7.6.1/H-0-1] DOIT disposer d'au moins 4 Go de stockage non volatile disponible pour les données privées des applications (également appelée partition "/data").
  • [7.6.1/H-0-2] DOIT renvoyer "true" pour ActivityManager.isLowRamDevice() lorsque la mémoire est inférieure à 1 Go disponible pour le noyau et l’espace utilisateur.

Si les implémentations d'appareils portables déclarent ne prendre en charge qu'une ABI 32 bits:

  • [7.6.1/H-1-1] Mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 416 Mo si l'affichage par défaut utilise un framebuffer jusqu'en qHD (FWVGA, par exemple).

  • [7.6.1/H-2-1] Mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 592 Mo si l'affichage par défaut utilise la mémoire tampon du frame jusqu'à HD+ (HD, WSVGA, etc.).

  • [7.6.1/H-3-1] Mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 896 Mo si l'affichage par défaut utilise un framebuffer jusqu'à FHD (WSXGA+, par exemple).

  • [7.6.1/H-4-1] Mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 344 Mo si l'écran par défaut utilise jusqu'en QHD (QWXGA, par exemple).

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

  • [7.6.1/H-5-1] Mémoire disponible pour le noyau et l'espace utilisateur DOIT avoir une taille d'au moins 816 Mo si l'écran par défaut utilise une résolution supérieure de framebuffer en qHD (par exemple, FWVGA).

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

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

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

Notez que la "mémoire disponible pour le noyau et l’espace utilisateur" ci-dessus fait référence de mémoire disponible en plus de la mémoire déjà dédiée au matériel les composants radio, vidéo, etc. qui ne sont pas sous le sur les implémentations d'appareils.

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

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

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

  • [7.6.1/H-10-1] DOIT disposer d'au moins 4 Go de le stockage non volatile disponible données privées de l'application (partition "/data").
  • DEVRAIT déclarer le flag de fonctionnalité android.hardware.ram.normal.

Si les configurations d'appareils portables incluent une capacité supérieure ou égale à 2 Go et moins de 4 Go de mémoire disponible pour le noyau et l’espace utilisateur, ils:

  • [7.6.1/H-SR-1] SONT FORTEMENT RECOMMANDÉS de prendre en charge uniquement un espace utilisateur 32 bits (applications et code système)

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

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

Implémentations pour les appareils portables:

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

Si les implémentations d'appareils portables incluent un port USB prenant en charge les périphériques ils:

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

Si les implémentations d’appareils portables incluent un port USB prenant en charge le mode hôte, ils:

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

Implémentations pour les appareils portables:

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

Si les implémentations d'appareils portables sont capables d'atteindre toutes les performances pour prendre en charge le mode RV et que ce mode soit compatible, ils:

  • [7.9.1/H-1-1] DOIT déclarer Indicateur de fonctionnalité android.hardware.vr.high_performance.
  • [7.9.1/H-1-2] DOIT inclure une application Implémentation de android.service.vr.VrListenerService pouvant être activée par RV applications via android.app.Activity#setVrModeEnabled.

Si les implémentations d'appareils portables incluent un ou plusieurs ports USB-C sur l'hôte et implémenter (classe audio USB), en plus des exigences section 7.7.2, elles:

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

Lorsque des terminaux audio USB de type 0x0302 sont détectés, ils:

  • [7.8.2.2/H-2-1] DOIT diffuser l'intent ACTION_HEADSET_PLUG avec "micro" supplémentaire défini sur 0.

Lorsque des terminaux audio USB de type 0x0402 sont détectés, ils:

  • [7.8.2.2/H-3-1] DOIT diffuser l'intent ACTION_HEADSET_PLUG avec "micro" supplémentaire sur 1.

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

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

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

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

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

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

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

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

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

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

  • [5.6/H-1-1] DOIT disposer d'un aller-retour moyen continu une latence de 300 millisecondes ou moins de cinq mesures, avec une écart absolue moyenne inférieure à 30 ms, plus de les chemins de données suivants : "Haut-parleur vers micro", Adaptateur de bouclage 3,5 mm (si compatible), bouclage USB (si compatible)

  • [5.6/H-1-2] DOIT disposer d'une latence moyenne de type "Appuyer sur tonalité" de 300 millisecondes ou moins sur au moins cinq mesures sur le haut-parleur au chemin d'accès aux données du micro.

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

Un actionneur à résonateur linéaire (LRA) est un système à ressorts à masse unique dont le fréquence de résonance dominante où la masse se traduit le mouvement souhaité.

Si les configurations d'appareils portables incluent au moins un attribut à usage général 7.10 à résonateur linéaire:

Commencer les nouvelles exigences

  • [7,10/H] DEVRAIT positionner l'actionneur à proximité l'endroit où l'appareil est généralement tenu ou touché avec vos mains.

Mettre fin aux nouvelles exigences

  • [7,10/H] DEVRAIT déplacer l'actionneur haptique sur l'axe X (à gauche et à droite) du niveau naturel portrait .

Si les implémentations d'appareils portables ont un usage général l'actionneur haptique, c'est-à-dire un actionneur à résonance linéaire sur l'axe X, ils:

  • [7,10/H] DEVRAIT avoir une fréquence de résonance de la LRA sur l'axe X inférieure à 200 Hz.

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

2.2.2. Multimédia

Les implémentations d'appareils portables DOIVENT prendre en charge les types d'encodage audio suivants : les formats de décodage et les rendre disponibles pour des applications tierces:

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

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

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

Commencer les nouvelles exigences

  • [5.2/H-0-3] AV1

Mettre fin aux nouvelles exigences

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

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

Commencer les nouvelles exigences

  • [5.3/H-0-6] AV1

Mettre fin aux nouvelles exigences

2.2.3. Logiciel

Implémentations pour les appareils portables:

  • [3.2.3.1/H-0-1] DOIT comporter un application qui gère ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, et ACTION_CREATE_DOCUMENT tels que décrits dans les documents du SDK, et fournissent à l'utilisateur les affordances pour accéder aux données du fournisseur de documents via l'API DocumentsProvider.
  • [3.2.3.1/H-0-2]* DOIT en précharger un ou plus d'applications ou de composants de service avec un gestionnaire d'intents, tous les formats de filtres d'intent public définis par l'application suivante : les intents répertoriés sur cette page.
  • [3.2.3.1/H-SR-1] Sont VIVEMENT RECOMMANDÉ de précharger une application de messagerie capable de gérer ACTION_SENDTO. ou ACTION_SEND ou ACTION_SEND_MULTIPLE des intents à l'envoi d'un e-mail.
  • [3.4.1/H-0-1] DOIT fournir une réponse complète l'implémentation de l'API android.webkit.Webview.
  • [3.4.2/H-0-1] DOIT inclure un navigateur autonome. pour naviguer sur le Web.
  • [3.8.1/H-SR-1] SONT FORTEMENT RECOMMANDÉS pour implémenter un lanceur d'applications par défaut qui prend en charge l'épinglage des raccourcis dans l'application, widgets et widgetFeatures.
  • [3.8.1/H-SR-2] SONT FORTEMENT RECOMMANDÉS pour implémenter un lanceur d'applications par défaut qui permet d'accéder rapidement raccourcis fournis par les applications tierces via ShortcutManager API.
  • [3.8.1/H-SR-3] SONT FORTEMENT RECOMMANDÉS pour inclure un lanceur d'applications par défaut qui affiche les badges pour les icônes de l'application.
  • [3.8.2/H-SR-1] SONT FORTEMENT RECOMMANDÉS pour prendre en charge les widgets d'application tiers.
  • [3.8.3/H-0-1] DOIT autoriser les applications tierces applications pour informer les utilisateurs d'événements importants via les Notification et NotificationManager les classes d'API.
  • [3.8.3/H-0-2] DOIT prendre en charge des contenus enrichis les notifications.
  • [3.8.3/H-0-3] DOIT prendre en charge les messages prioritaires les notifications.
  • [3.8.3/H-0-4] DOIT inclure un volet des notifications, ce qui permet à l'utilisateur de contrôler directement répondre, mettre en attente, ignorer, bloquer) les notifications par le biais des affordances de l'utilisateur telles que boutons d'action ou le panneau de configuration comme implémenté dans l'AOSP.
  • [3.8.3/H-0-5] DOIT afficher les options fournies via RemoteInput.Builder setChoices() dans le volet des notifications.
  • [3.8.3/H-SR-1] SONT FORTEMENT RECOMMANDÉS pour afficher le premier choix fourni via RemoteInput.Builder setChoices() dans le volet des notifications sans action supplémentaire de l'utilisateur.
  • [3.8.3/H-SR-2] SONT FORTEMENT RECOMMANDÉS pour afficher tous les choix fournis via RemoteInput.Builder setChoices() dans le volet des notifications lorsque l'utilisateur développe toutes les notifications dans le volet des notifications.
  • [3.8.3.1/H-SR-1] SONT FORTEMENT RECOMMANDÉS pour afficher les actions pour lesquelles Notification.Action.Builder.setContextual est défini sur true dans la ligne des réponses affichées par Notification.Remoteinput.Builder.setChoices
  • [3.8.4/H-SR-1] SONT FORTEMENT RECOMMANDÉS pour implémenter un assistant sur l'appareil afin de gérer l'action d'assistance.

Si les implémentations d'appareils portables sont compatibles avec les notifications MediaStyle ils:

  • [3.8.3.1/H-SR-2] SONT FORTEMENT RECOMMANDÉS pour fournir une affordance utilisateur (par exemple, un sélecteur de sortie) accessible depuis UI du système permettant aux utilisateurs de basculer entre les médias disponibles appropriés des routes (par exemple, les appareils Bluetooth et les itinéraires fournis aux MediaRouter2Manager). Lorsqu'une application publie une notification MediaStyle avec un jeton MediaSession.

Commencer les nouvelles exigences

Si les implémentations d'appareils, y compris la touche de navigation de la fonction recents, comme détaillé dans la section 7.2.3 modifient l'interface, ils:

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

Mettre fin aux nouvelles exigences

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

  • [3.8.4/H-SR-2] SONT FORTEMENT RECOMMANDÉS d'utiliser un appui prolongé sur la touche HOME comme interaction désignée pour lancer la comme décrit dans la section 7.2.3. OBLIGATOIRE LE lancement l'application d'assistance sélectionnée par l'utilisateur, c'est-à-dire l'application qui implémente VoiceInteractionService ou une activité gérant l'intent ACTION_ASSIST.

Si les implémentations d'appareils portables sont compatibles avec conversation notifications et les regrouper dans une section distincte, celle des alertes notifications, ils:

  • [3.8.4/H-1-1]* DOIT afficher notifications de conversation avant les notifications de non-conversation avec à l'exception des notifications de service de premier plan en cours importance:high les notifications.

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

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

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

Si les implémentations d'appareils portables incluent la prise en charge de ControlsProviderService et Control et autorisent les applications tierces à publier des commandes de contrôle des appareils:

  • [3.8.16/H-1-1] DOIT déclarer la fonctionnalité drapeau android.software.controls et définissez-la sur true.
  • [3.8.16/H-1-2] DOIT fournir à un utilisateur avec la possibilité d'ajouter, de modifier, de sélectionner et d'exploiter commandes de contrôle des appareils préférées à partir des commandes enregistrées par le tiers d'applications via le ControlsProviderService et la Control API.
  • [3.8.16/H-1-3] DOIT fournir un accès cette affordance de l'utilisateur dans trois interactions à partir d'un lanceur d'applications par défaut.

  • [3.8.16/H-1-4] DOIT restituer avec précision dans cette affordance d'utilisateur le nom et l'icône de chaque application tierce fournit des commandes via le ControlsProviderService de l'API, ainsi que tous les champs spécifiés par la Control API.

  • [3.8.16/H-1-5] DOIT fournir à un utilisateur affordance de désactiver les commandes d'appareil désignées comme triviales pour l'authentification de l'application les contrôles enregistrés par les applications tierces via les ControlsProviderService et la Control Control.isAuthRequired.

Commencer les nouvelles exigences

  • [3.8.16/H-1-6] Implémentations des appareils DOIT afficher avec précision l' affordance de l'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 ControlsProviderService , y compris le ComponentName d'un activité valide (telle que définie 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 : les champs spécifiés DOIVENT être affichés, conformément aux ControlsProviderService de l'API, ainsi que tous les champs spécifiés par la API de contrôle.
  • [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] en utilisant EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS lors du lancement de l'activité intégrée.

Mettre fin aux nouvelles exigences

À l'inverse, si les implémentations d'appareils portables ne mettent pas en œuvre de tels contrôles, ils:

Si les implémentations d'appareils portables ne s'exécutent pas en mode tâches verrouillées, lorsque le contenu est copié dans le presse-papiers:

  • [3.8.17/H-1-1] DOIT présenter une confirmation à l'utilisateur que les données ont été dans le presse-papiers (par exemple, une vignette ou une alerte indiquant "Contenu copié"). Indiquez également ici si les données du presse-papiers seront synchronisées. sur plusieurs appareils.

Implémentations pour les appareils portables:

  • [3.10/H-0-1] DOIT prendre en charge l'accessibilité par un tiers services.
  • [3.10/H-SR-1] EST FORTEMENT RECOMMANDÉ de précharger services d'accessibilité sur l'appareil comparables ou supérieurs aux fonctionnalités de Switch Access et TalkBack (pour les langues compatibles avec la moteur de synthèse vocale) tels qu'ils sont fournis dans l'API Talkback ouverte projet source.
  • [3.11/H-0-1] DOIT prendre en charge l'installation des moteurs de synthèse vocale tiers.
  • [3.11/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un Moteur de synthèse vocale compatible avec les langues disponibles sur l'appareil.
  • [3.13/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un Composant d'interface utilisateur "Réglages rapides".

Si les implémentations d'appareils portables Android déclarent FEATURE_BLUETOOTH ou FEATURE_WIFI, ils:

  • [3.16/H-1-1] DOIT prendre en charge l'association de l'appareil associé .

Si la fonction de navigation est fournie sous la forme d'une action à l'écran basée sur un geste:

  • [7.2.3/H] Zone de reconnaissance de gestes pour la maison NE DOIT PAS être supérieure à 32 dp de hauteur à partir du bas l'écran.

Si les implémentations d'appareils portables fournissent une fonction de navigation sous forme de geste depuis les bords gauche et droit de l'écran:

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

Si les implémentations d'appareils portables sont compatibles avec un écran de verrouillage sécurisé et ont une supérieure ou égale à 2 Go de mémoire disponible pour le noyau et l'espace utilisateur, elles:

  • [3.9/H-1-2] DOIT déclarer la prise en charge des profils gérés via le Indicateur de fonctionnalité android.software.managed_users.

Si les implémentations d'appareils portables Android déclarent la prise en charge de l'appareil photo via android.hardware.camera.any:

Si l'application des paramètres d'implémentation de l'appareil implémente une fonctionnalité de fractionnement, à l'aide de l'intégration d'activités, ils:

Commencer les nouvelles exigences

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

Mettre fin aux nouvelles exigences

Performances et puissance

  • [8.1/H-0-1] Latence cohérente des frames. Une latence de trame incohérente ou un délai d'affichage des images NE DOIT PAS se produire davantage souvent plus de 5 images par seconde, et DOIT être inférieure à 1 images par seconde.
  • [8.1/H-0-2] Latence de l'interface utilisateur. Les implémentations d'appareils DOIVENT garantir une expérience utilisateur à faible latence en faisant défiler un Liste de 10 000 entrées de liste, telles que définies par la suite de tests de compatibilité Android (CTS) en moins de 36 secondes.
  • [8.1/H-0-3] Changement de tâches Quand ? plusieurs applications ont été lancées, relançant ainsi une application déjà exécutée application après son lancement DOIT prendre moins d'une seconde.

Implémentations pour les appareils portables:

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

Si les implémentations d'appareils portables incluent des fonctionnalités visant à améliorer la puissance de l'appareil de gestion intégrée à l'AOSP ou étendent les fonctionnalités incluses dans AOSP:

  • [8.3/H-1-1] DOIT fournir une affordance à l'utilisateur pour activer et désactiver l'économiseur de batterie.
  • [8.3/H-1-2] DOIT fournir une affordance à l'utilisateur pour afficher toutes les applications exemptées des modes d'économie d'énergie "Mise en veille des applications" et "Sommeil".

Implémentations pour les appareils portables:

  • [8.4/H-0-1] DOIT fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle pour chaque composant matériel, ainsi que la décharge approximative de la batterie causée par composants au fil du temps, comme indiqué sur le site du projet Android Open Source.
  • [8.4/H-0-2] DOIT indiquer toute l'alimentation de consommation exprimées en milliampères-heures (mAh).
  • [8.4/H-0-3] DOIT indiquer la puissance du processeur de consommation par UID de chaque processus. Le projet Android Open Source répond aux via l'implémentation du module de noyau uid_cputime.
  • [8.4/H-0-4] DOIT utiliser cette puissance disponible sur le adb shell dumpsys batterystats au développeur de l'application.
  • [8.4/H] DEVRAIT être attribué à la composant matériel lui-même s'il n'est pas en mesure d'attribuer sa consommation d'énergie à une application.

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

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 déclenchées par l'utilisateur, y compris la durée de chacun de ces services car il a démarré comme décrit dans la documentation sur le 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.avec la possibilité d'arrêter une application qui exécute un service de premier plan et d'afficher toutes les applications avec des services de premier plan actifs, ainsi que la durée de chacune des ces services, car elle a commencé comme décrit dans Document relatif au SDK.
    • Certaines applications PEUVENT être exemptées d'être arrêtées ou répertoriées dans un affinance utilisateur, comme décrit dans le document relatif au SDK.

Commencer les nouvelles exigences

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

Mettre fin aux nouvelles exigences

Modèle de sécurité

Implémentations pour les appareils portables:

  • [9/H-0-1] DOIT déclarer le android.hardware.security.model.compatible .
  • [9.1/H-0-1] DOIT autoriser les applications tierces à accéder des statistiques d'utilisation via l'autorisation android.permission.PACKAGE_USAGE_STATS et fournir un mécanisme accessible à l'utilisateur pour accorder ou révoquer l'accès à ces applications dans réponse au android.settings.ACTION_USAGE_ACCESS_SETTINGS l'intention.

Commencer les nouvelles exigences

Si les implémentations d'appareils déclarent la prise en charge de android.hardware.telephony, ils:

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

Mettre fin aux nouvelles exigences

Implémentations pour les appareils portables:

  • [9.11/H-0-2] DOIT sauvegarder l'implémentation du keystore dans un environnement d'exécution isolé.
  • [9.11/H-0-3] DOIT comporter des implémentations RSA, AES, Algorithmes cryptographiques ECDSA et HMAC, et famille MD5, SHA1 et SHA-2 fonctions de hachage pour prendre en charge correctement des algorithmes dans une zone isolée en toute sécurité du code exécuté sur le noyau et versions ultérieures. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lequel le code du noyau ou de l'espace utilisateur peut accéder à l'état interne environnement isolé, y compris la loi sur les marchés numériques. Android Open Source en amont Le projet (AOSP) répond à cette exigence en utilisant l'implémentation Trusty, mais une autre Solution basée sur ARM TrustZone ou sécurisée par un tiers la mise en œuvre d'une isolation basée sur l'hyperviseur appropriée sont des alternatives options.
  • [9.11/H-0-4] DOIT activer le verrouillage de l'écran l'authentification dans l'environnement d'exécution isolé et uniquement lorsque réussi, autorisez l'utilisation des clés liées à l'authentification. Écran de verrouillage les identifiants DOIVENT être stockés de manière à ne permettre que l'exécution isolée d'authentification pour l'authentification sur l'écran de verrouillage. L'application Android en amont Open Source Project offre Gatekeeper Hardware Abstraction Layer (HAL) et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
  • [9.11/H-0-5] DOIT prendre en charge l'attestation des clés lorsque le d'attestation est protégée par du matériel sécurisé, et la signature est effectuées sur du matériel sécurisé. Les clés de signature des attestations DOIVENT être partagées sur un nombre suffisant d'appareils pour empêcher l'utilisation des clés ; en tant qu'identifiants d'appareil. Pour répondre à cette exigence, vous pouvez la même clé d'attestation,sauf si au moins 100 000 unités d'un SKU donné sont produits. Si plus de 100 000 unités d'un SKU sont produites, une autre PEUT être utilisée pour chaque tranche de 100 000 unités.

Notez que si l'implémentation d'un appareil est déjà lancée sur une version antérieure d'Android, un appareil de ce type n'est pas tenu de disposer d'un keystore reposant sur un environnement d'exécution isolé et prend en charge l'attestation des clés, sauf s'il déclare la fonctionnalité android.hardware.fingerprint, qui nécessite keystore reposant sur un environnement d'exécution isolé.

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

  • [9.11/H-1-1] DOIT permettre à l'utilisateur de choisir la version la plus courte délai de mise en veille, c'est-à-dire la durée de transition entre en 15 secondes ou moins.
  • [9.11/H-1-2] DOIT fournir une affordance à l'utilisateur pour masquer les notifications et désactiver toutes les formes d'authentification, à l'exception l'authentification principale décrite dans 9.11.1 Écran de verrouillage sécurisé. L'AOSP répond aux comme mode de verrouillage.

Commencer les nouvelles exigences

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.

Mettre fin aux nouvelles exigences

Si les implémentations d'appareils portables incluent plusieurs utilisateurs et ne déclarent pas le flag de fonctionnalité android.hardware.telephony:

  • [9.5/H-2-1] DOIT prendre en charge les profils limités. une fonctionnalité qui permet aux propriétaires d'appareils de gérer des utilisateurs supplémentaires et leurs de l'appareil. Avec les profils restreints, les propriétaires d'appareils peuvent configurer rapidement des environnements distincts dans lesquels d'autres utilisateurs peuvent travailler, avec la possibilité de gérer des restrictions plus précises dans les applications sont disponibles dans ces environnements.

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

  • [9.5/H-3-1] NE DOIT PAS prendre en charge profils, mais DOIT s'aligner sur la mise en œuvre des contrôles AOSP pour activer /désactiver l'accès des autres utilisateurs aux appels vocaux et aux SMS.

Commencer les nouvelles exigences

Si les implémentations d'appareils portables définissent UserManager.isHeadlessSystemUserMode à true, ils

  • [9.5/H-4-1] NE DOIT PAS inclure la prise en charge des comptes eUICC. ni pour les eSIM avec fonctionnalité d'appel.
  • [9.5/H-4-2] NE DOIT PAS déclarer la prise en charge des android.hardware.telephony

Mettre fin aux nouvelles exigences

Android, via l'API système, VoiceInteractionService prend en charge un mécanisme détection sécurisée et permanente des mots clés sans indication d'accès au micro et détection permanente des requêtes, sans micro ni caméra ou d'une indication d'accès.

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

  • [9.8/H-1-1] DOIT s'assurer que le service de détection de mots clés ne transmet au système, ContentCaptureService, ou un service de reconnaissance vocale intégré à l'appareil, SpeechRecognizer#createOnDeviceSpeechRecognizer().
  • [9.8/H-1-2] DOIT s'assurer que le service de détection de mots clés ne peut transmettre les données audio du micro ou les données dérivées de celui-ci au serveur système via l'API HotwordDetectionService, ou à ContentCaptureService via ContentCaptureManager.
  • [9.8/H-1-3] NE DOIT PAS fournir d'audio du micro de plus de 30 secondes pendant une une requête individuelle déclenchée par le matériel au service de détection de mots clés.
  • [9.8/H-1-4] NE DOIT PAS fournir de micro mis en mémoire tampon de plus de 8 secondes pour une une requête individuelle au service de détection de mots clés.
  • [9.8/H-1-5] NE DOIT PAS fournir à l'appareil un micro mis en mémoire tampon de plus de 30 secondes un service d'interaction vocale ou une entité similaire.
  • [9.8/H-1-6] NE DOIT PAS autoriser plus de 100 octets de données à transmettre en dehors du service de détection de mots clés à chaque résultat de mot clé, à l'exception des données audio transmises HotwordAudioStream
  • [9.8/H-1-7] NE DOIT PAS permettre la transmission de plus de cinq bits de données. du service de détection de mot clé sur chaque résultat négatif de mot clé.
  • [9.8/H-1-8] NE DOIT autoriser la transmission de données qu'à partir du mot clé service de détection sur une requête de validation de mot clé du serveur système.
  • [9.8/H-1-9] NE DOIT PAS permettre à une application installable par l'utilisateur de fournir de détection de mots clés.
  • [9.8/H-1-10] NE DOIT PAS faire apparaître des données quantitatives sur l'utilisation du micro dans l'interface utilisateur le service de détection de mots clés.
  • [9.8/H-1-11] DOIT consigner le nombre d'octets inclus dans chaque transmission du service de détection de mots clés pour permettre l'inspection à des fins de sécurité chercheurs.
  • [9.8/H-1-12] DOIT prendre en charge un mode de débogage qui enregistre le contenu brut de chaque du service de détection de mots clés pour permettre l'inspection chercheurs en sécurité.
  • [9.8/H-1-14] DOIT afficher l'indicateur du micro, comme décrit dans la section 9.8.2, lorsqu'un résultat de mot clé réussi est transmis à la voix ou d'une entité similaire.

Commencer les nouvelles exigences

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

Mettre fin aux nouvelles exigences

  • [9.8/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'avertir les utilisateurs avant de définir en tant que fournisseur du service de détection de mots clés.
  • [9.8/H-SR-2] SONT FORTEMENT RECOMMANDÉS d'interdire la transmission le service de détection de mots clés.
  • [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 toutes les heures ou toutes les 30 les événements déclencheurs matériels, selon la première échéance atteinte.

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

  • [9.8/H-2-1] DOIT fournir une notification explicite à l'utilisateur pour chaque expression composée de mots clés compatibles.
  • [9.8/H-2-2] NE DOIT PAS préserver les données audio brutes, ni les données qui en découlent. via le service de détection de mots clés.
  • [9.8/H-2-3] NE DOIT PAS transmettre de données audio ni depuis le service de détection de mots clés des données pouvant être utilisées pour reconstruire (entièrement ou partiellement) le contenu audio, ou des contenus audio sans rapport avec le mot clé lui-même, à l'exception ContentCaptureService ou saisie vocale sur l'appareil de reconnaissance vocale.

Commencer les nouvelles exigences

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

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

Mettre fin aux nouvelles exigences

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

  • [9.8.2/H-4-1] DOIT afficher l'indicateur du micro lorsque une application accède aux données audio du micro, mais pas lorsque le le micro n'est accessible que par HotwordDetectionService, SOURCE_HOTWORD,ContentCaptureService ou les applications détenant les rôles appelés consultez la section 9.1 avec l'identifiant CDD [C-4-X].
  • [9.8.2/H-4-2] DOIT afficher la liste des listes "Récentes" et "Actifs" les applications utilisant le micro comme renvoyées par PermissionManager.getIndicatorAppOpUsageData(), ainsi que toute attribution messages qui leur sont associés.

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

  • [9.8.2/H-5-1] DOIT afficher l'indicateur de l'appareil photo lorsqu'un accède aux données en direct de la caméra, mais pas lorsqu'elle est uniquement auxquelles les applications détenant les rôles indiqués dans section 9.1 avec l'identifiant CDD [C-4-X].
  • [9.8.2/H-5-2] DOIT afficher les applications récentes et actives utilisant appareil photo renvoyé par PermissionManager.getIndicatorAppOpUsageData(), ainsi que tous les messages d'attribution qui leur sont associés.

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

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

  • [6.1/H-0-1]* DOIT prendre en charge la commande shell cmd testharness

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

  • Perfetto
    • [6.1/H-0-2]* DOIT exposer un /system/bin/perfetto binaire à l'utilisateur shell auquel la cmdline est conforme la documentation perfetto.
    • [6.1/H-0-3]* Le binaire Perfetto DOIT accepter comme saisissez une configuration protobuf conforme au schéma défini dans la documentation perfetto.
    • [6.1/H-0-4]* Le binaire Perfetto DOIT écrire sous la forme générer une trace protobuf conforme au schéma défini dans la documentation perfetto.
    • [6.1/H-0-5]* DOIT fournir, via le perfetto binaire, au moins les sources de données décrites dans la documentation de Perfetto.
    • [6.1/H-0-6]* Le daemon tracé par Perfetto DOIT être activée par défaut (propriété système persist.traced.enable).

2.2.7. Classe de performance des médias portables

Consultez la section 7.11 pour connaître la définition des la classe de performance multimédia.

Contenus multimédias

Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.T pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

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:

  • [5.1/H-1-1] DOIT indiquer le nombre maximal de décodeurs vidéo matériels qui peuvent être exécutées simultanément dans n'importe quelle combinaison de codecs via CodecCapabilities.getMaxSupportedInstances() et VideoCapabilities.getSupportedPerformancePoints().
  • [5.1/H-1-2] DOIT prendre en charge six instances de décodeur vidéo matériel 8 bits (SDR) (AVC, HEVC, VP9, AV1 ou version ultérieure) dans n'importe quelle combinaison de codecs exécutée simultanément avec 3 sessions en résolution 1080p à 30 FPS et 3 sessions en 4K résolution à 30 ips, sauf AV1. Les codecs AV1 ne sont requis que pour prendre en charge la résolution 1080p, nécessaire pour prendre en charge six instances à 1080p30 FPS.
  • [5.1/H-1-3] DOIT indiquer le nombre maximal d'encodeurs vidéo matériels qui peuvent être exécutées simultanément dans n'importe quelle combinaison de codecs via CodecCapabilities.getMaxSupportedInstances() et VideoCapabilities.getSupportedPerformancePoints().
  • [5.1/H-1-4] DOIT prendre en charge six instances d'encodeur vidéo matériel 8 bits (SDR) (AVC, HEVC, VP9, AV1 ou version ultérieure) dans n'importe quelle combinaison de codecs exécutée simultanément avec 4 sessions en résolution 1080p à 30 FPS et 2 sessions en 4K résolution à 30 ips, sauf AV1. Les codecs AV1 ne sont requis que pour prendre en charge la résolution 1080p, nécessaire pour prendre en charge six instances à 1080p30 FPS.
  • [5.1/H-1-5] DOIT indiquer le nombre maximal d'encodeurs vidéo matériels de décodeur qui peuvent être exécutées simultanément dans n'importe quelle combinaison de codecs via 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 les sessions d'encodeur vidéo matériel (AVC, HEVC, VP9, AV1 ou version ultérieure) combinaison de codecs exécutée simultanément avec trois sessions à 4K à 30 images par seconde (sauf AV1), dont deux au maximum correspondent à des sessions d'encodeur et des sessions en résolution 1080p. Les codecs AV1 ne sont requis que pour prendre en charge la résolution 1080p, nécessaire pour 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 10 bits (HDR) et les sessions d'encodeur vidéo matériel (AVC, HEVC, VP9, AV1 ou version ultérieure) combinaison de codecs exécutée simultanément à une résolution de 4K à 30 images par seconde (sauf AV1) dont 1 au maximum correspond à une session d'encodeur, qui peut être configurée RGBA_1010102 via une surface GL. Génération de métadonnées HDR par l'encodeur n'est pas nécessaire 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 1080p ou moins pour tous les encodeurs vidéo matériels lorsque avec une charge élevée. La valeur "Charger ici" désigne les vidéos simultanées de 1080p à 720p uniquement de transcodage à l'aide de codecs vidéo matériels et de la résolution 1080p l'initialisation de l'enregistrement audio-vidéo. Pour le codec Dolby Vision, le codec la latence d'initialisation 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 débit inférieur pour tous les encodeurs audio lorsque avec une charge élevée. La valeur "Charger ici" désigne les vidéos simultanées de 1080p à 720p uniquement de transcodage à l'aide de codecs vidéo matériels et de la résolution 1080p l'initialisation de l'enregistrement audio-vidéo.
  • [5.1/H-1-9] DOIT prendre en charge deux instances de décodeur vidéo matériel sécurisé (AVC, HEVC, VP9, AV1 ou version ultérieure) dans n'importe quelle combinaison de codecs exécutée simultanément à une résolution 4K à 30 FPS (sauf AV1) pour les réseaux 8 bits (SDR) et Contenu 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 décodeur vidéo matériel non sécurisé avec 1 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 codecs Exécution simultanée de trois sessions en résolution 4K à 30 FPS (sauf AV1) qui comprend une session de décodeur sécurisée et une session nn-secure en 1080p résolution à 30 FPS, avec un maximum de 2 sessions en 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-11] DOIT prendre en charge un décodeur sécurisé pour chaque matériel AVC, HEVC et VP9 ou AV1 sur 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 cas de charge élevée. La valeur "Charger" correspond à une résolution simultanée de 1080p à 720p. de transcodage vidéo uniquement à l'aide de codecs vidéo matériels et du Initialisation de la lecture audio-vidéo 1080p. Pour le codec Dolby Vision, le codec la latence d'initialisation 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 à 128 kbit/s ou débit inférieur pour tous les décodeurs audio lorsque avec une charge élevée. La valeur "Charger ici" désigne les vidéos simultanées de 1080p à 720p uniquement de transcodage à l'aide de codecs vidéo matériels et de la résolution 1080p l'initialisation de la lecture audio/vidéo.
  • [5.1/H-1-14] DOIT prendre en charge le décodeur matériel AV1 Principal 10, Niveau 4.1 et film céréales.
  • [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 trame en 10 secondes (c'est-à-dire moins de perte d'image de 0,167 %) pour une session vidéo 4K à 60 FPS sous charge.
  • [5.3/H-1-2] NE DOIT PAS supprimer plus d'une image en 10 secondes au cours d'une vidéo changement de résolution lors d'une session vidéo de 60 FPS sous charge pour une session 4K.
  • [5.6/H-1-1] DOIT avoir une latence tap-to-ton de 80 millisecondes ou moins en utilisant le test tap-to-ton de CTS Verifier.
  • [5.6/H-1-2] DOIT avoir une latence audio aller-retour de 80 millisecondes sur au moins un chemin de données compatible.
  • [5.6/H-1-3] DOIT prendre en charge un contenu audio ≥ à 24 bits pour une sortie stéréo supérieure à 3,5 mm connecteurs audio (si disponibles) et via USB (si compatible avec l'ensemble des données) pour les configurations de flux et de latence à faible latence. Pour la faible latence l'application doit utiliser AAudio dans les rappels à faible latence. . Pour la configuration du streaming, une piste audio Java doit être utilisée par l'application. Dans les configurations à faible latence et en flux continu, le HAL le récepteur de sortie 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 DJ) commandes permettant de prévisualiser les titres.)
  • [5.6/H-1-5] DOIT prendre en charge les appareils MIDI conformes aux classes et déclarer Indicateur de fonctionnalité MIDI.
  • [5.6/H-1-9] DOIT prendre en charge au moins 12 canaux de mixage. Cela implique que d'ouvrir une piste audio avec un masque de canal 7.1.4 et de lire spatialiser ou réduire le son de tous les canaux en stéréo.
  • [5.6/H-SR] SONT FORTEMENT RECOMMANDÉS de prendre en charge le mixage 24 canaux avec compatible avec les 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 le sous les fonctionnalités de déchiffrement de contenu.
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
Nombre total minimal de clés DRM (toutes 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 format AVIF Profil de référence.
  • [5.1/H-1-18] DOIT prendre en charge l'encodeur AV1 pouvant encoder jusqu'à 480p à 30 FPS et 1 Mbit/s.
  • [5.12/H-1-1] DOIT [5.12/H-SR] Sont vivement recommandés pour Feature_HdrEditing pour tous les encodeurs matériels AV1 et HEVC présents sur l'appareil.
  • [5.12/H-1-2] DOIT prendre en charge le format de couleurs RGBA_1010102 pour tous les composants matériels AV1 et Encodeurs HEVC présents sur l'appareil.
  • [5.12/H-1-3] DOIT indiquer que l'extension EXT_YUV_target est prise en charge à partir de textures YUV en 8 et 10 bits.
  • [7.1.4/H-1-1] DOIT comporter au moins six superpositions matérielles dans le traitement de l'affichage (DPU), dont au moins deux 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 elles incluent d'un encodeur matériel AVC ou HEVC, elles:

Mettre fin aux nouvelles exigences

2.2.7.2. Appareil photo

Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.T pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

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:

  • [7.5/H-1-1] DOIT disposer d'une caméra arrière principale d'une résolution de d'au moins 12 mégapixels compatible avec la capture vidéo à 4K à 30 FPS. L'instance principale la caméra arrière est la caméra arrière dont l'identifiant de caméra est le plus bas.
  • [7.5/H-1-2] DOIT disposer d'une caméra frontale principale d'une résolution de d'au moins 6 mégapixels et prend en charge la capture vidéo à 1080p à 30 images par seconde. L'instance principale la caméra frontale est la caméra frontale 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 comme FULL ou plus pour l'instance principale principale et LIMITED ou mieux pour l'instance principale principale caméra.
  • [7.5/H-1-4] DOIT prendre en charge CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME pour les deux primaires caméras.
  • [7.5/H-1-5] DOIT avoir une latence de capture JPEG de camera2 < 1000 900 ms pour une résolution 1080p mesurée par le test PerformanceTest de la caméra CTS dans Conditions d'éclairage ITS (3 000 K) pour les deux caméras principales.
  • [7.5/H-1-6] DOIT avoir une latence de démarrage de l'appareil photo 2 (ouvrez l'appareil photo pour ouvrir le premier aperçu). cadre) < 500 ms, mesurés par le test PerformanceTest de la caméra CTS dans le cadre du service ITS les conditions d'éclairage (3 000 K) des 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 ips.
  • [7,5/H-1-10] DOIT avoir une valeur minimale de ZOOM_RATIO < 1.0 pour les caméras principales, le cas échéant est un appareil photo RVB ultra grand angle orienté dans la même direction.
  • [7.5/H-1-11] DOIT implémenter une diffusion frontale simultanée sur l'instance principale caméras.
  • [7.5/H-1-12] DOIT prendre en charge CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION pour les deux primaires avant et arrière principale.
  • [7.5/H-1-13] DOIT prendre en charge la capacité LOGICAL_MULTI_CAMERA pour la caméra arrière principale s'il y a plus d'une caméra RVB caméras arrière.
  • [7.5/H-1-14] DOIT prendre en charge la capacité STREAM_USE_CASE pour les instances principales avant et arrière principale.
  • [7.5/H-1-15] DOIT prendre en charge Bokeh et Extensions du mode Nuit via les extensions CameraX et Camera2 pour les caméras.
  • [7.5/H-1-16] DOIT prendre en charge la capacité DYNAMIC_RANGE_TEN_BIT pour l'instance principale caméras.
  • [7.5/H-1-17] DOIT prendre en charge 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.

Mettre fin aux nouvelles exigences

Matériel

Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.T pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

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:

  • [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 prenant en charge au moins 1 000 nits moyenne.
  • [7.6.1/H-2-1] DOIT disposer d'au moins 8 Go de mémoire physique.

Mettre fin aux nouvelles exigences

Performances

Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.T pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

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:

  • [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 doublées d'au moins 50 Mo/s.

Mettre fin aux nouvelles exigences

2.3. Configuration requise pour la télévision

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

Les implémentations d'appareils Android sont classées dans la catégorie "Téléviseur" si elles répondent à toutes les les critères suivants:

  • disposent d'un mécanisme permettant de contrôler à distance l'interface utilisateur affichée sur l'écran peut se trouver à trois mètres de l'utilisateur.
  • disposer d'un écran intégré dont la diagonale est supérieure à 24 pixels ; pouces OU incluent un port de sortie vidéo, tel que VGA, HDMI, DisplayPort ou un port sans fil pour l'affichage.

Les exigences supplémentaires figurant dans le reste de cette section sont spécifiques à Android. Implémentations de téléviseurs

2.3.1. Matériel

Implémentations pour les téléviseurs:

  • [7.2.2/T-0-1] DOIT prendre en charge le pavé directionnel.
  • [7.2.3/T-0-1] DOIT indiquer les champs "Domicile" et "Retour" fonctions.
  • [7.2.3/T-0-2] DOIT envoyer à la fois l'appui normal et l'appui prolongé événement de la fonction Retour (KEYCODE_BACK) à l'application de premier plan.
  • [7.2.6.1/T-0-1] DOIT inclure la prise en charge du jeu contrôleurs et déclarez l'indicateur de fonctionnalité android.hardware.gamepad.
  • [7.2.7/T] DEVRAIT fournir une télécommande à partir de laquelle les utilisateurs peuvent accéder à la navigation non tactile et touches de navigation principales.

Si les téléviseurs sont équipés d'un gyroscope à trois axes:

  • [7.3.4/T-1-1] DOIT pouvoir signaler des événements d'une durée maximale de d'au moins 100 Hz.
  • [7.3.4/T-1-2] DOIT pouvoir mesurer les changements d'orientation jusqu'à 1 000 degrés par seconde.

Implémentations pour les téléviseurs:

  • [7.4.3/T-0-1] DOIT être compatible avec le Bluetooth Bluetooth LE.
  • [7.6.1/T-0-1] DOIT disposer d'au moins 4 Go de stockage non volatile disponible pour les données privées des applications (également appelée partition "/data").

Si les implémentations de téléviseurs comprennent un port USB prenant en charge le mode hôte, ils:

  • [7.5.3/T-1-1] DOIT inclure la prise en charge d'une caméra externe qui se connecte via ce port USB, mais qui n’est pas nécessairement connecté.

Pour les téléviseurs 32 bits:

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

    • 400 ppp ou plus sur les écrans de petite taille
    • xhdpi ou supérieur sur les grands écrans
    • tvdpi ou supérieur sur les très grands écrans

Pour les téléviseurs 64 bits:

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

    • 400 ppp ou plus sur les écrans de petite taille
    • xhdpi ou supérieur sur les grands écrans
    • tvdpi ou supérieur sur les très grands écrans

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

Implémentations pour les téléviseurs:

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

2.3.2. Multimédia

Les intégrations de téléviseurs DOIVENT prendre en charge l'encodage audio suivant et de décodage des formats, et les mettre à la disposition d'applications tierces:

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

Les intégrations de téléviseurs DOIVENT prendre en charge l'encodage vidéo suivant et les mettre à la disposition d'applications tierces:

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

Commencer les nouvelles exigences

  • [5.2/T-0-3] AV1

Mettre fin aux nouvelles exigences

Implémentations pour les téléviseurs:

  • [5.2.2/T-SR-1] SONT FORTEMENT RECOMMANDÉS de fournir une assistance Encodage H.264 de vidéos 720p et 1080p avec une fréquence de 30 images par seconde.

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

Commencer les nouvelles exigences

Mettre fin aux nouvelles exigences

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

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

Les implémentations de téléviseurs DOIVENT prendre en charge le décodage H.264, comme détaillé dans Section 5.3.4, aux fréquences d'images et résolutions vidéo standards jusqu'à y compris:

  • [5.3.4/T-1-1] HD 1080p à 60 images par seconde avec Profil de référence
  • [5.3.4/T-1-2] HD 1080p à 60 images par seconde avec Profil principal
  • [5.3.4/T-1-3] HD 1080p à 60 images par seconde avec Profil élevé niveau 4.2

Les téléviseurs équipés de décodeurs matériels H.265 DOIVENT prendre en charge Décodage H.265, comme détaillé dans la section 5.3.5, aux fréquences d'images vidéo standards et résolutions allant jusqu'à:

  • [5.3.5/T-1-1] HD 1080p à 60 images par seconde avec Profil principal niveau 4.1

Si les implémentations de téléviseurs dotées de décodeurs matériels H.265 sont compatibles Le décodage H.265 et le profil de décodage UHD, ils:

  • [5.3.5/T-2-1] DOIT être compatible avec le profil de décodage UHD à 60 images par seconde avec le profil Main10 de niveau 5 principal ;

Les implémentations de téléviseurs DOIVENT prendre en charge le décodage VP8, comme détaillé dans Section 5.3.6, aux fréquences d'images et résolutions vidéo standards jusqu'à y compris:

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

Les téléviseurs équipés de décodeurs matériels VP9 DOIVENT être compatibles avec ce format le décodage, comme détaillé dans la section 5.3.7, aux fréquences d'images vidéo et de résolution pouvant aller jusqu'à:

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

Si les téléviseurs équipés de décodeurs matériels VP9 sont compatibles avec le codec VP9 et le profil de décodage UHD, ils:

  • [5.3.7/T-2-1] DOIT être compatible avec le profil de décodage UHD à 60 images par seconde avec le profil 0 (profondeur de couleur de 8 bits).
  • [5.3.7/T-SR1] SONT FORTEMENT RECOMMANDÉS de prendre en charge Profil de décodage UHD à 60 images par seconde avec profil 2 (profondeur de couleur de 10 bits).

Implémentations pour les téléviseurs:

  • [5.5/T-0-1] DOIT inclure la prise en charge du maître système Atténuation du volume de la sortie audio numérique sur les sorties compatibles à l'exception de la sortie audio compressée en passthrough (dans laquelle aucun décodage audio n'est effectué sur l'appareil).

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 câble HDMI mode de sortie à la résolution la plus élevée pour le format de pixel compatible avec une fréquence d'actualisation de 50 ou 60 Hz pour l'écran externe, en fonction de la vidéo fréquence d'actualisation correspondant à la région dans laquelle l'appareil est vendu. DOIT définir le mode de sortie HDMI sur sélectionnez la résolution maximale compatible avec une fréquence de 50 Hz ou de 60 Hz la fréquence d'actualisation.
  • [5.8/T-SR-1] Il est FORTEMENT RECOMMANDÉ de fournir à un utilisateur Sélecteur de fréquence d'actualisation HDMI configurable.
  • [5.8] DEVRAIT définir la fréquence d'actualisation du mode de sortie HDMI 50 Hz ou 60 Hz, selon la fréquence d'actualisation vidéo pour la région où appareil est vendu.

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-1-1] DOIT être compatible HDCP 2.2.

Si les téléviseurs ne sont pas compatibles avec le décodage UHD, prennent en charge un écran externe connecté via HDMI, ils:

  • [5.8/T-2-1] DOIT être compatible HDCP 1.4

Logiciel

Implémentations pour les téléviseurs:

  • [3/T-0-1] DOIT déclarer les fonctionnalités android.software.leanback et android.hardware.type.television.
  • [3.2.3.1/T-0-1] DOIT précharger un ou plus d'applications ou de composants de service avec un gestionnaire d'intents, pour toutes les Schémas de filtre d'intent public définis par les intents d'application suivants disponibles ici.
  • [3.4.1/T-0-1] DOIT fournir un formulaire l'implémentation de l'API android.webkit.Webview.

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

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

Implémentations pour les téléviseurs:

  • [3.8.14/T-SR-1] SONT FORTEMENT RECOMMANDÉS pour prendre en charge le mode multifenêtre Picture-in-picture (PIP).
  • [3.10/T-0-1] DOIT prendre en charge l'accessibilité par un tiers services.
  • [3.10/T-SR-1] SONT FORTEMENT RECOMMANDÉS les services d'accessibilité sur l'appareil qui sont comparables ou supérieurs les fonctionnalités de Switch Access et TalkBack (pour les langues compatibles avec le moteur de synthèse vocale préinstallé) tels qu'ils sont fournis dans le projet Open Source TalkBack.

Si les implémentations de téléviseurs signalent cette fonctionnalité android.hardware.audio.output:

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

Implémentations pour les téléviseurs:

  • [3.12/T-0-1] DOIT être compatible avec le framework d'entrée TV.

Performances et puissance

  • [8.1/T-0-1] Latence cohérente des frames. Une latence de trame incohérente ou un délai d'affichage des images NE DOIT PAS se produire davantage souvent plus de 5 images par seconde, et DOIT être inférieure à 1 images par seconde.
  • [8.2/T-0-1] DOIT s'assurer qu'une requête des performances d'écriture d'au moins 5 Mo/s.
  • [8.2/T-0-2] DOIT s'assurer qu'une écriture aléatoire d'au moins 0,5 Mo/s.
  • [8.2/T-0-3] DOIT s'assurer qu'une requête des performances de lecture d'au moins 15 Mo/s.
  • [8.2/T-0-4] DOIT garantir une lecture aléatoire d'au moins 3,5 Mo/s.

Si les implémentations de téléviseurs incluent des fonctionnalités visant à améliorer la puissance de l'appareil de gestion intégrée à l'AOSP ou étendent les fonctionnalités incluses dans AOSP:

  • [8.3/T-1-1] DOIT fournir une affordance à l'utilisateur pour activer et désactiver l'économiseur de batterie.

Si les téléviseurs ne sont pas équipés d'une batterie:

Si les téléviseurs sont équipés d'une batterie:

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

Implémentations pour les téléviseurs:

  • [8.4/T-0-1] DOIT fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle pour chaque composant matériel, ainsi que la décharge approximative de la batterie causée par composants au fil du temps, comme indiqué sur le site du projet Android Open Source.
  • [8.4/T-0-2] DOIT indiquer toute l'alimentation de consommation exprimées en milliampères-heures (mAh).
  • [8.4/T-0-3] DOIT indiquer la puissance du processeur de consommation par UID de chaque processus. Le projet Android Open Source répond aux via l'implémentation du module de noyau uid_cputime.
  • [8.4/T] DEVRAIT être attribué à la composant matériel lui-même s'il n'est pas en mesure d'attribuer sa consommation d'énergie à une application.
  • [8.4/T-0-4] DOIT utiliser cette puissance électrique disponible sur le adb shell dumpsys batterystats au développeur de l'application.

Modèle de sécurité

Implémentations pour les téléviseurs:

  • [9/T-0-1] DOIT déclarer le android.hardware.security.model.compatible .
  • [9.11/T-0-1] DOIT sauvegarder l'implémentation du keystore dans un environnement d'exécution isolé.
  • [9.11/T-0-2] DOIT comporter des implémentations RSA, AES, Algorithmes cryptographiques ECDSA et HMAC, et famille MD5, SHA1 et SHA-2 fonctions de hachage pour prendre en charge correctement des algorithmes dans une zone isolée en toute sécurité du code exécuté sur le noyau et versions ultérieures. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lequel le code du noyau ou de l'espace utilisateur peut accéder à l'état interne environnement isolé, y compris la loi sur les marchés numériques. Android Open Source en amont Le projet (AOSP) répond à cette exigence en utilisant l'implémentation Trusty, mais une autre Solution basée sur ARM TrustZone ou sécurisée par un tiers la mise en œuvre d'une isolation basée sur l'hyperviseur appropriée sont des alternatives options.
  • [9.11/T-0-3] DOIT effectuer le verrouillage de l'écran l'authentification dans l'environnement d'exécution isolé et uniquement lorsque réussi, autorisez l'utilisation des clés liées à l'authentification. Écran de verrouillage les identifiants DOIVENT être stockés de manière à ne permettre que l'exécution isolée d'authentification pour l'authentification sur l'écran de verrouillage. L'application Android en amont Open Source Project offre Gatekeeper Hardware Abstraction Layer (HAL) et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
  • [9.11/T-0-4] DOIT prendre en charge l'attestation des clés lorsque le d'attestation est protégée par du matériel sécurisé, et la signature est effectuées sur du matériel sécurisé. Les clés de signature des attestations DOIVENT être partagées sur un nombre suffisant d'appareils pour empêcher l'utilisation des clés ; en tant qu'identifiants d'appareil. Pour répondre à cette exigence, vous pouvez la même clé d'attestation,sauf si au moins 100 000 unités d'un SKU donné sont produits. Si plus de 100 000 unités d'un SKU sont produites, une autre PEUT être utilisée pour chaque tranche de 100 000 unités.

Notez que si l'implémentation d'un appareil est déjà lancée sur une version antérieure d'Android, un appareil de ce type n'est pas tenu de disposer d'un keystore reposant sur un environnement d'exécution isolé et prend en charge l'attestation des clés, sauf s'il déclare la fonctionnalité android.hardware.fingerprint, qui nécessite keystore reposant sur un environnement d'exécution isolé.

Si les téléviseurs sont compatibles avec un écran de verrouillage sécurisé, ils:

  • [9.11/T-1-1] DOIT permettre à l'utilisateur de choisir le mode Sommeil délai avant expiration de la transition de l'état déverrouillé à l'état verrouillé, avec une délai d'expiration minimal autorisé jusqu'à 15 secondes ou moins.

Si les implémentations de télévision comprennent plusieurs utilisateurs et ne déclarent pas le flag de fonctionnalité android.hardware.telephony:

  • [9.5/T-2-1] DOIT prendre en charge les profils limités. une fonctionnalité qui permet aux propriétaires d'appareils de gérer des utilisateurs supplémentaires et leurs de l'appareil. Avec les profils restreints, les propriétaires d'appareils peuvent configurer rapidement des environnements distincts dans lesquels d'autres utilisateurs peuvent travailler, avec la possibilité de gérer des restrictions plus précises dans les applications sont disponibles dans ces environnements.

Si les implémentations de télévision comprennent plusieurs utilisateurs et déclarer l'indicateur de fonctionnalité android.hardware.telephony:

  • [9.5/T-3-1] NE DOIT PAS prendre en charge profils, mais DOIT s'aligner sur la mise en œuvre des contrôles AOSP pour activer /désactiver l'accès des autres utilisateurs aux appels vocaux et aux SMS.

Si les implémentations de téléviseurs déclarent android.hardware.microphone, elles:

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

Si les implémentations de téléviseurs déclarent android.hardware.camera.any, elles:

  • [9.8.2/T-5-1] DOIT afficher l'indicateur de l'appareil photo lorsqu'un accède aux données en direct de la caméra, mais pas lorsque celle-ci auxquelles accèdent les applications détenant les rôles décrits à la section 9.1. Autorisations avec identifiant CDD [C-3-X].
  • [9.8.2/T-5-2] NE DOIT pas masquer l'indicateur de l'appareil photo pour les applications système qui ont des interfaces utilisateur visibles ou une interaction directe de l’utilisateur.

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

Implémentations pour les téléviseurs:

2.4. Configuration requise pour la montre

Une Watch Android est une implémentation d'appareil Android destinée à sur le corps, voire sur le poignet.

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

  • La longueur de la diagonale physique de l'écran doit être comprise entre 1,1 et 2,5. pouces.
  • Prévoir un mécanisme pouvant être porté sur le corps.

Les exigences supplémentaires figurant dans le reste de cette section sont spécifiques à Android. Implémentations sur les montres

Matériel

Implémentations sur les montres:

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

  • [7.2.3/W-0-1] DOIT disposer de la fonction Home à l'utilisateur et la fonction "Retour", sauf si elle se trouve dans UI_MODE_TYPE_WATCH.

  • [7.2.4/W-0-1] DOIT être compatible avec la saisie tactile.

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

Commencer les nouvelles exigences

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

Mettre fin aux nouvelles exigences

Si les implémentations de montres incluent un récepteur GPS/GNSS et signalent les aux applications via la fonctionnalité android.hardware.location.gps. indicateur, ils:

  • [7.3.3/W-1-1] DOIT indiquer les mesures GNSS dès qu'elles même si la position calculée à partir du GPS/GNSS n'est pas encore signalée.
  • [7.3.3/W-1-2] DOIT signaler les pseudo-plages et pseudo-plages GNSS en ciel ouvert, après avoir déterminé l'emplacement, immobile ou se déplaçant à moins de 0,2 mètre par seconde au carré de accélération, sont suffisantes pour calculer la position à 20 mètres près et la vitesse à une distance de 0,2 mètre par seconde, au moins 95% du temps.

Si les implémentations de montres incluent un gyroscope à 3 axes, elles:

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

Implémentations sur les montres:

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

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

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

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

  • [7.8.2/W] PEUT avoir une sortie audio.

Multimédia

Aucune exigence supplémentaire.

Logiciel

Implémentations sur les montres:

  • [3/W-0-1] DOIT déclarer la fonctionnalité android.hardware.type.watch
  • [3/W-0-2] DOIT prendre en charge uiMode = UI_MODE_TYPE_WATCH :
  • [3.2.3.1/W-0-1] DOIT en précharger un ou plus d'applications ou de composants de service avec un gestionnaire d'intents, tous les formats de filtres d'intent public définis par l'application suivante : les intents répertoriés sur cette page.

Implémentations sur les montres:

  • [3.8.4/W-SR-1] SONT FORTEMENT RECOMMANDÉS pour implémenter un assistant sur l'appareil afin de gérer l'action d'assistance.

Les implémentations d'appareils de montre qui déclarent l'android.hardware.audio.output flag de fonctionnalité:

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

Si les implémentations de la montre indiquent la fonctionnalité android.hardware.audio.output, ils:

  • [3.11/W-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un Moteur de synthèse vocale compatible avec les langues disponibles sur l'appareil.

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

Performances et puissance

Si les implémentations de la montre incluent des fonctionnalités visant à améliorer la puissance de l'appareil de gestion intégrée à l'AOSP ou étendent les fonctionnalités incluses dans AOSP:

  • [8.3/W-SR-1] Il est FORTEMENT RECOMMANDÉ de fournir l'accessibilité de l'utilisateur pour afficher toutes les applications exemptées de mise en veille des applications et Modes d'économie d'énergie Sommeil.
  • [8.3/W-SR-2] Il est FORTEMENT RECOMMANDÉ de fournir d'activer et de désactiver l'économiseur de batterie.

Implémentations sur les montres:

  • [8.4/W-0-1] DOIT fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle pour chaque composant matériel, ainsi que la décharge approximative de la batterie causée par composants au fil du temps, comme indiqué sur le site du projet Android Open Source.
  • [8.4/W-0-2] DOIT indiquer toute l'alimentation de consommation exprimées en milliampères-heures (mAh).
  • [8.4/W-0-3] DOIT indiquer la puissance du processeur de consommation par UID de chaque processus. Le projet Android Open Source répond aux via l'implémentation du module de noyau uid_cputime.
  • [8.4/W-0-4] DOIT utiliser cette puissance électrique disponible sur le adb shell dumpsys batterystats au développeur de l'application.
  • [8.4/W] DEVRAIT être attribué à la composant matériel lui-même s'il n'est pas en mesure d'attribuer sa consommation d'énergie à une application.

Modèle de sécurité

Implémentations sur les montres:

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

Si les implémentations des montres incluent plusieurs utilisateurs et ne déclarent pas le flag de fonctionnalité android.hardware.telephony:

  • [9.5/W-1-1] DOIT prendre en charge les profils limités. une fonctionnalité qui permet aux propriétaires d'appareils de gérer des utilisateurs supplémentaires et leurs de l'appareil. Avec les profils restreints, les propriétaires d'appareils peuvent configurer rapidement des environnements distincts dans lesquels d'autres utilisateurs peuvent travailler, avec la possibilité de gérer des restrictions plus précises dans les applications sont disponibles dans ces environnements.

Si les implémentations des montres incluent plusieurs utilisateurs et déclarer l'indicateur de fonctionnalité android.hardware.telephony:

  • [9.5/W-2-1] NE DOIT PAS être compatible avec profils, mais DOIT s'aligner sur la mise en œuvre des contrôles AOSP pour activer /désactiver l'accès des autres utilisateurs aux appels vocaux et aux SMS.

Commencer les nouvelles exigences

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.

Mettre fin aux nouvelles exigences

2.5. Exigences concernant l'automobile

L'implémentation Android Automotive fait référence à l'unité principale d'un véhicule fonctionnant Android comme système d'exploitation pour une partie ou la totalité du système et/ou la fonctionnalité d'infoloisirs.

Les implémentations d'appareils Android sont classées dans la catégorie "Automobile" si elles déclarent la fonctionnalité android.hardware.type.automotive ou répondre à tous les critères critères.

  • s'intègrent dans un véhicule automobile ou peuvent y être branchés ;
  • utilisent un écran situé sur le siège conducteur comme écran principal ;

Les exigences supplémentaires figurant dans le reste de cette section sont spécifiques à Android. Implémentations d'appareils automobiles

Matériel

Implémentations pour les appareils automobiles:

  • [7.1.1.1/A-0-1] DOIT disposer d'un écran d'au moins 6 de centimètres en diagonale physique.
  • [7.1.1.1/A-0-2] DOIT disposer d'une mise en page de taille d'écran d'au moins 750 dp x 480 dp.
  • [7.2.3/A-0-1] DOIT fournir la fonction Home et PEUVENT fournir les fonctions Retour et Récent.
  • [7.2.3/A-0-2] DOIT envoyer à la fois l'appui normal et l'appui prolongé événement de la fonction Retour (KEYCODE_BACK) à l'application de premier plan.
  • [7.3/A-0-1] DOIT implémenter et signaler GEAR_SELECTION NIGHT_MODE, PERF_VEHICLE_SPEED et PARKING_BRAKE_ON.
  • [7.3/A-0-2] La valeur du paramètre NIGHT_MODE l'indicateur DOIT être cohérent avec le mode Jour/Nuit du tableau de bord et DOIT être basé sur l'entrée du capteur de luminosité ambiante. Le capteur de luminosité ambiante sous-jacent PEUT être le même photomètre.
  • [7.3/A-0-3] DOIT fournir un champ d'informations supplémentaires pour le capteur TYPE_SENSOR_PLACEMENT dans SensorAdditionalInfo pour chaque capteur fourni.
  • [7.3/A-SR1] PEUT-être que le lieu est perdu en fusionnant le GPS/GNSS avec d'autres capteurs. Si Emplacement il est FORTEMENT RECOMMANDÉ de mettre en œuvre et de signaler Capteur correspondant types et/ou ID de propriété de véhicule utilisé.

  • [7.3/A-0-4] L'emplacement demandée via LocationManager#requestLocationUpdates(). NE DOIT PAS être mis en correspondance avec la carte.

  • [7.3.1/A-0-4] DOIT se conformer aux système de coordonnées du capteur de voiture.

  • [7.3/A-SR-1] SONT FORTEMENT_RECOMMANDÉS d'inclure trois axes un accéléromètre et un gyroscope 3 axes.

  • [7.3/A-SR-2] A-T-ILS PUBLIÉMENT d'implémenter et de signaler Capteur TYPE_HEADING.

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

  • [7.1.4.1/A-0-1] DOIT déclarer OpenGL ES 3.1 ou version ultérieure.
  • [7.1.4.1/A-0-2] DOIT prendre en charge Vulkan 1.1.
  • [7.1.4.1/A-0-3] DOIT inclure le chargeur Vulkan et exporter tous les symboles.

Commencer les nouvelles exigences

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

Mettre fin aux nouvelles exigences

Si les implémentations d'appareils automobiles incluent un accéléromètre:

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

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

  • [7.3.1/A-SR-1] SONT FORTEMENT RECOMMANDÉS d'implémenter les capteur composite pour accéléromètre à axes limités.

Si les implémentations d'appareils automobiles incluent un accéléromètre de moins de 3 axes, il:

  • [7.3.1/A-1-3] DOIT implémenter et signaler Capteur TYPE_ACCELEROMETER_LIMITED_AXES.
  • [7.3.1/A-1-4] DOIT implémenter et signaler Capteur TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

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

  • [7.3.4/A-2-1] DOIT pouvoir signaler des événements avec une fréquence d'au moins 100 Hz.
  • [7.3.4/A-2-3] DOIT pouvoir mesurer les changements d'orientation jusqu'à 250 degrés par seconde.
  • [7.3.4/A-SR-1] EST FORTEMENT RECOMMANDÉ de configurer la plage de mesure du gyroscope à +/-250 dps afin d'optimiser la résolution. possible.

Si les implémentations d'appareils Automotive incluent un gyroscope à trois axes:

  • [7.3.4/A-SR-2] EST FORTEMENT RECOMMANDÉ d'implémenter les capteur composite pour le gyroscope à axes limités.

Si les implémentations d'appareils Automotive incluent un gyroscope avec moins de trois axes, elles:

  • [7.3.4/A-4-1] DOIT implémenter et signaler Capteur TYPE_GYROSCOPE_LIMITED_AXES.
  • [7.3.4/A-4-2] DOIT implémenter et signaler Capteur TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

Si les implémentations d'appareils automobiles incluent un récepteur GPS/GNSS, mais ne incluent une connectivité de données basée sur le réseau mobile, elles:

  • [7.3.3/A-3-1] DOIT déterminer la position la toute première fois que le récepteur GPS/GNSS est allumé ou après au moins 4 jours en 60 secondes.
  • [7.3.3/A-3-2] DOIT respecter les critères concernant le délai avant la première correction tels que décrites dans 7.3.3/C-1-2 et 7.3.3/C-1-6 pour toutes les autres demandes de localisation (c'est-à-dire les requêtes qui ne sont pas ou après plus de 4 jours). L'exigence 7.3.3/C-1-2 est généralement utilisés dans les véhicules sans connectivité de données basée sur le réseau cellulaire, en utilisant les prédictions d'orbite GNSS calculées sur le récepteur, ou en utilisant le la dernière position connue d'un véhicule et de pouvoir compter sur au moins 60 secondes, avec une précision de position satisfaisante 7.3.3/C-1-3 ou une combinaison des deux.

Si les implémentations d'appareils automobiles incluent un capteur TYPE_HEADING, celles-ci:

  • [7.3.4/A-4-3] DOIT pouvoir signaler des événements avec une fréquence d'au moins 1 Hz.
  • [7.3.4/A-SR-3] StrongLY_RECOMMENDED pour signaler les événements d'une durée maximale de d'au moins 10 Hz.
  • DEVRAIT faire référence au nord géographique.
  • DEVRAIT être disponible même lorsque le véhicule est immobile.
  • DEVRAIT avoir une résolution d'au moins 1 degré.

Implémentations pour les appareils automobiles:

  • [7.4.3/A-0-1] DOIT prendre en charge le Bluetooth et DEVRAIT est compatible avec la technologie Bluetooth LE.
  • [7.4.3/A-0-2] Implémentations d'Android Automotive DOIT prendre en charge les profils Bluetooth suivants:
    • Appels téléphoniques via un profil mains libres (HFP).
    • Lecture de contenus multimédias via un profil de distribution audio (A2DP).
    • Contrôle de la lecture multimédia via le profil de contrôle à distance (AVRCP).
    • Partage des contacts à l'aide du profil d'accès au répertoire téléphonique (PBAP)

  • [7.4.3/A-SR-1] SONT FORTEMENT RECOMMANDÉS Profil d'accès aux messages (MAP).

  • [7.4.5/A] DEVRAIT inclure la prise en charge des réseaux la connectivité des données basée sur le réseau.

  • [7.4.5/A] PEUT utiliser l'API System Constante NetworkCapabilities#NET_CAPABILITY_OEM_PAID pour qui devraient être disponibles pour les applications système.

Commencer les nouvelles exigences

Si les implémentations d'appareils prennent en charge la radiodiffusion AM/FM et exposent la fonctionnalité à n'importe quelle application, ils:

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

Mettre fin aux nouvelles exigences

Une caméra d'extérieur est une caméra qui capture les scènes à l'extérieur de l'appareil. mise en œuvre, 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 de vue extérieure, par exemple une caméra, ils:

  • [7.5/A-1-1] NE DOIT PAS être accessible via les caméras extérieures via les API Android Camera, à moins qu'elles ne soient avec les conditions de base requises pour l'appareil photo.

  • [7.5/A-SR-1] Il est FORTEMENT RECOMMANDÉ de ne pas alterner dupliquer horizontalement l'aperçu de l'appareil photo.

  • [7.5/A-SR-2] Il est FORTEMENT RECOMMANDÉ de trouver une 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).

  • PEUVENT intégrer un autofocus matériel ou logiciel dans le pilote de la caméra.

Si les implémentations d'appareils automobiles incluent une ou plusieurs caméras de vue extérieure, et charger le service EVS, puis pour ce type de caméra:

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

Implémentations pour les appareils automobiles:

  • PEUT inclure une ou plusieurs caméras mises à la disposition de tiers applications.

Si les implémentations d'appareils automobiles incluent au moins une caméra et la rendent à 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 comme 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 (autofocus, etc.) disponibles pour l'arrière de l'appareil. caméras comme indiqué dans la section 7.5.1.

Commencer les nouvelles exigences

Une caméra arrière est une caméra orientée vers l'extérieur qui peut être installée être placé sur le véhicule et qui doit faire face à l'extérieur de l'habitacle ; c'est-à-dire qu'il des images de scènes de l'autre côté de la carrosserie du véhicule, comme la caméra de recul.

Une caméra frontale est une caméra orientée vers l'utilisateur qui peut être placée à n'importe quel emplacement être placé sur le véhicule et situé de face à l'intérieur de l'habitacle ; c'est tout images de 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 images caméras.
  • PEUT inclure une ou plusieurs caméras orientées vers l'utilisateur.
  • [7.5/A-SR-2] SONT FORTEMENT RECOMMANDÉS de prendre en charge le streaming simultané de plusieurs caméras.

Si les implémentations d'appareils automobiles incluent au moins un appareil photo orientés vers l'extérieur. Pour un tel appareil photo, ils:

  • [7.5/A-1-1] DOIT être orienté de sorte que la dimension longue de la caméra soit alignée avec le plan X-Y des axes des capteurs automobiles Android.
  • [7.5/A-SR-3] Il est FORTEMENT RECOMMANDÉ d'avoir une mise au point fixe ou des fonctionnalités EDOF (profondeur de champ étendue).
  • [7.5/A-1-2] DOIT disposer de l'appareil photo principal orienté vers l'extérieur appareil photo avec l'ID d'appareil photo le plus bas.

Si les implémentations d'appareils automobiles incluent au moins un appareil photo visible par l'utilisateur, alors pour un tel appareil photo:

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

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

  • [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 automobiles incluent un appareil photo inaccessible via l'API android.hardware.Camera ou android.hardware.camera2, puis ils:

  • [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:

  • [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égapixels.

Si les implémentations d'appareils automobiles incluent une ou plusieurs caméras qui sont accessible via Extended View System Service et android.hardware.Camera ou android.hardware.Camera2, puis pour ce type d'appareil photo:

  • [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 android.hardware.camera2 ou Extended View System.

Mettre fin aux nouvelles exigences

Implémentations pour les appareils automobiles:

  • [7.6.1/A-0-1] DOIT disposer d'au moins 4 Go de stockage non volatile disponible pour les données privées des applications (également appelée partition "/data").

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

Si les implémentations d'appareils Automotive fournissent un espace de stockage externe partagé via un de la mémoire de stockage interne non amovible, ils:

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

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

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

    • 280 ppp ou moins sur les écrans de petite taille
    • ldpi ou inférieur sur les très grands écrans
    • mdpi ou inférieur sur les grands écrans

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

    • xhdpi ou supérieur sur les écrans de petite taille/normal
    • hdpi ou supérieur sur les grands écrans
    • mdpi ou supérieur sur les très grands écrans

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

    • 400 ppp ou plus sur les écrans de petite taille
    • xhdpi ou supérieur sur les grands écrans
    • tvdpi ou supérieur sur les très grands écrans

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

    • 560 ppp ou plus sur les écrans de petite taille ou de taille normale
    • 400 ppp ou plus sur les grands écrans
    • xhdpi ou supérieur sur les très grands écrans

Notez que la "mémoire disponible pour le noyau et l’espace utilisateur" ci-dessus fait référence de mémoire disponible en plus de la mémoire déjà dédiée au matériel les composants radio, vidéo, etc. qui ne sont pas sous le sur les implémentations d'appareils.

Implémentations pour les appareils automobiles:

  • [7.7.1/A] DEVRAIT inclure un port USB compatible avec le mode périphérique.

Implémentations pour les appareils automobiles:

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

Implémentations pour les appareils automobiles:

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

2.5.2. Multimédia

Les implémentations d'appareils automobiles DOIVENT prendre en charge l'encodage audio suivant et de décodage des formats, et les mettre à la disposition d'applications tierces:

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

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

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

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

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

Les implémentations d'appareils automobiles sont FORTEMENT RECOMMANDÉES pour prendre en charge le décodage vidéo suivant:

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

Logiciel

Implémentations pour les appareils automobiles:

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

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

  • [3/A-0-3] DOIT être compatible avec toutes les API publiques du android.car.* espace de noms.

Si les implémentations d'appareils automobiles fournissent une API propriétaire utilisant android.car.CarPropertyManager avec android.car.VehiclePropertyIds, ils:

  • [3/A-1-1] NE DOIT PAS associer de privilèges spéciaux au système l'utilisation de ces propriétés par votre application, ni empêcher les applications tierces d'utiliser ces propriétés.
  • [3/A-1-2] NE DOIT PAS reproduire la propriété d'un véhicule qui existe dans le SDK.

Implémentations pour les appareils automobiles:

  • [3.2.1/A-0-1] DOIT prendre en charge et appliquer Constantes d'autorisations, comme indiqué sur la page de référence sur les autorisations automobiles.

  • [3.2.3.1/A-0-1] DOIT précharger un ou plus d'applications ou de composants de service avec un gestionnaire d'intents, pour toutes les Schémas de filtre d'intent public définis par les intents d'application suivants disponibles ici.

  • [3.4.1/A-0-1] DOIT fournir un formulaire l'implémentation de l'API android.webkit.Webview.

Commencer les nouvelles exigences

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

Mettre fin aux nouvelles exigences

  • [3.8.3/A-0-1] DOIT afficher des notifications qui utilisent le Notification.CarExtender API lorsque des applications tierces le demandent.

  • [3.8.4/A-SR-1] Fortement recommandé pour implémenter un assistant sur l'appareil afin de gérer l'action d'assistance.

Si les implémentations d'appareils automobiles incluent un bouton Appuyer pour parler:

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

Implémentations pour les appareils automobiles:

  • [3.8.3.1/A-0-1] DOIT correctement afficher les ressources comme décrit dans le Notifications on Automotive OS Documentation du SDK.
  • [3.8.3.1/A-0-2] DOIT afficher LIRE et IGNORER pour les actions de notification à la place de celles fournies via Notification.Builder.addAction()
  • [3.8.3.1/A] DEVRAIT limiter l'utilisation de tâches de gestion enrichies, telles que des commandes par canal de notification. PEUT utiliser l' affordance d'UI par application pour réduire les contrôles.

Si les implémentations d'appareils automobiles sont compatibles avec les propriétés HAL de l'utilisateur, elles:

Implémentations pour les appareils automobiles:

Si les implémentations d'appareils Automotive incluent un lanceur d'applications par défaut, celles-ci:

Implémentations pour les appareils automobiles:

  • [3.8/A] PEUT restreindre l'application les requêtes de passage en mode plein écran, comme décrit dans immersive documentation.
  • [3.8/A] PEUVENT conserver la barre d'état et la barre de navigation visible en permanence.
  • [3.8/A] PEUT restreindre l'application les demandes de modification des couleurs derrière les éléments de l'interface utilisateur du système, afin de garantir ces éléments sont clairement visibles à tout moment.

Performances et puissance

Implémentations pour les appareils automobiles:

  • [8.2/A-0-1] DOIT indiquer le nombre de d'octets lus et écrits dans un espace de stockage non volatile pour chaque UID de processus. les statistiques sont accessibles aux développeurs via l'API System android.car.storagemonitoring.CarStorageMonitoringManager Android Open Le projet source répond aux exigences du module de noyau uid_sys_stats.
  • [8.3/A-1-3] DOIT être compatible avec le mode Garage.
  • [8.3/A] DEVRAIT être en mode Garage pendant au moins 15 minutes après chaque trajet, sauf dans les cas suivants:
    • La batterie est déchargée.
    • Aucun job inactif n'est planifié.
    • Le conducteur quitte le mode garage.
  • [8.4/A-0-1] DOIT fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle de chaque composant matériel, ainsi que la décharge approximative de la batterie causée par composants au fil du temps, comme indiqué sur le site du projet Android Open Source.
  • [8.4/A-0-2] DOIT indiquer toute l'alimentation de consommation exprimées en milliampères-heures (mAh).
  • [8.4/A-0-3] DOIT indiquer la puissance du processeur de consommation par UID de chaque processus. Le projet Android Open Source répond aux via l'implémentation du module de noyau uid_cputime.
  • [8.4/A] DEVRAIT être attribué à la composant matériel lui-même s'il n'est pas en mesure d'attribuer sa consommation d'énergie à une application.
  • [8.4/A-0-4] DOIT utiliser cette puissance électrique disponible sur le adb shell dumpsys batterystats au développeur de l'application.

2.5.5. Modèle de sécurité

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

Commencer les nouvelles exigences

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

  • [9.8.2/A-1-1] DOIT afficher l'indicateur du micro lorsque une application accède aux données audio du micro, mais pas lorsque le le micro n'est accessible que par HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService ou des applications détenant les rôles décrits dans section 9.1 avec l'identifiant CDD [C-4-X].
  • [9.8.2/A-1-2] NE DOIT pas masquer l'indicateur de micro les applications système qui ont 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 micro dans l'application Paramètres.

Mettre fin aux nouvelles exigences

Si les implémentations d'appareils Android Automotive déclarent android.hardware.camera.any, alors ils:

  • [9.8.2/A-2-1] DOIT afficher l'indicateur de l'appareil photo lorsqu'un accède aux données en direct de la caméra, mais pas lorsqu'elle est uniquement auquel ont accès les applications détenant les rôles, tels que définis indiqués dans Section 9.1 Autorisations avec l'identifiant CDD [C-4-X][C-3-X].
  • [9.8.2/A-2-2] NE DOIT pas masquer l'indicateur de l'appareil photo pour les applications système qui ont des interfaces utilisateur visibles ou une interaction directe de l’utilisateur.

Commencer les nouvelles exigences

  • [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 indiqué dans le message de PermissionManager.getIndicatorAppOpUsageData(), ainsi que messages d'attribution qui leur sont associés.

Mettre fin aux nouvelles exigences

Implémentations pour les appareils automobiles:

  • [9/A-0-1] DOIT déclarer le android.hardware.security.model.compatible .
  • [9.11/A-0-1] DOIT sauvegarder l'implémentation du keystore dans un environnement d'exécution isolé.
  • [9.11/A-0-2] DOIT comporter des implémentations RSA, AES, Algorithmes cryptographiques ECDSA et HMAC, et famille MD5, SHA1 et SHA-2 fonctions de hachage pour prendre en charge correctement des algorithmes dans une zone isolée en toute sécurité du code exécuté sur le noyau et versions ultérieures. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lequel le code du noyau ou de l'espace utilisateur peut accéder à l'état interne environnement isolé, y compris la loi sur les marchés numériques. Android Open Source en amont Le projet (AOSP) répond à cette exigence en utilisant l'implémentation Trusty, mais une autre Solution basée sur ARM TrustZone ou sécurisée par un tiers la mise en œuvre d'une isolation basée sur l'hyperviseur appropriée sont des alternatives options.
  • [9.11/A-0-3] DOIT activer le verrouillage de l'écran l'authentification dans l'environnement d'exécution isolé et uniquement lorsque réussi, autorisez l'utilisation des clés liées à l'authentification. Écran de verrouillage les identifiants DOIVENT être stockés de manière à ne permettre que l'exécution isolée d'authentification pour l'authentification sur l'écran de verrouillage. L'application Android en amont Open Source Project offre Gatekeeper Hardware Abstraction Layer (HAL) et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
  • [9.11/A-0-4] DOIT prendre en charge l'attestation des clés lorsque d'attestation est protégée par du matériel sécurisé, et la signature est effectuées sur du matériel sécurisé. Les clés de signature des attestations DOIVENT être partagées sur un nombre suffisant d'appareils pour empêcher l'utilisation des clés ; en tant qu'identifiants d'appareil. Pour répondre à cette exigence, vous pouvez la même clé d'attestation,sauf si au moins 100 000 unités d'un SKU donné sont produits. Si plus de 100 000 unités d'un SKU sont produites, une autre PEUT être utilisée pour chaque tranche de 100 000 unités.

Notez que si l'implémentation d'un appareil est déjà lancée sur une version antérieure d'Android, un appareil de ce type n'est pas tenu de disposer d'un keystore reposant sur un environnement d'exécution isolé et prend en charge l'attestation des clés, sauf s'il déclare la fonctionnalité android.hardware.fingerprint, qui nécessite keystore reposant sur un environnement d'exécution isolé.

Implémentations pour les appareils automobiles:

  • [9.14/A-0-1] DOIT envoyer des messages de contrôle d'accès provenant de sous-systèmes de véhicule du framework Android (par exemple, ajout de messages autorisés à la liste d'autorisation) et les sources des messages.
  • [9.14/A-0-2] DOIT surveiller et surveiller attaques par déni de service à partir du framework Android ou d'applications tierces. Ce des protections contre les logiciels malveillants inondant le réseau du véhicule de trafic, ce qui peut entraîner des dysfonctionnements des sous-systèmes du véhicule.

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

Implémentations pour les appareils automobiles:

2.6. Configuration requise pour les tablettes

Une tablette Android est une implémentation d'appareil Android qui répond généralement à tous les critères suivants:

  • Utilisé en tenant l'appareil dans les deux mains.
  • Elle ne dispose pas d'un ordinateur à clapet ni d'une configuration convertible.
  • Les implémentations de clavier physique utilisées avec l'appareil se connectent par via une connexion standard (par exemple, USB ou Bluetooth).

  • dispose d'une source d'alimentation qui permet de la mobilité, telle qu'une batterie ;

  • La taille de l'écran est supérieure à 7 pouces et inférieure à 18 pouces en diagonale.

Les implémentations de tablettes ont des exigences similaires à celles des appareils portables mises en œuvre. Les exceptions sont signalées par un * dans cette section. et données à titre indicatif dans cette section.

Matériel

Gyroscope

Si les implémentations de tablettes comprennent un gyroscope à 3 axes, elles:

  • [7.3.4/Tab-1-1] DOIT pouvoir mesurer l'orientation peut atteindre 1 000 degrés par seconde.

Mémoire et stockage minimaux (section 7.6.1)

Densités d'écran indiquées pour les écrans de petite taille ou de taille normale sur l'appareil portable ne s'appliquent pas aux tablettes.

Mode périphérique USB (section 7.7.1)

Si les tablettes comprennent un port USB compatible avec les périphériques ils:

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

Mode de réalité virtuelle (section 7.9.1)

Réalité virtuelle hautes performances (section 7.9.2)

Les exigences concernant la réalité virtuelle ne s'appliquent pas aux tablettes.

2.6.2. Modèle de sécurité

Clés et identifiants (section 9.11)

Consultez la section [9.11].

Si les implémentations des tablettes incluent plusieurs utilisateurs et ne déclarent pas le flag de fonctionnalité android.hardware.telephony:

  • [9.5/T-1-1] DOIT prendre en charge les profils limités. une fonctionnalité qui permet aux propriétaires d'appareils de gérer des utilisateurs supplémentaires et leurs de l'appareil. Avec les profils restreints, les propriétaires d'appareils peuvent configurer rapidement des environnements distincts dans lesquels d'autres utilisateurs peuvent travailler, avec la possibilité de gérer des restrictions plus précises dans les applications sont disponibles dans ces environnements.

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

  • [9.5/T-2-1] NE DOIT PAS prendre en charge profils, mais DOIT s'aligner sur la mise en œuvre des contrôles AOSP pour activer /désactiver l'accès des autres utilisateurs aux appels vocaux et aux SMS.

2.6.2. Logiciel

  • [3.2.3.1/Tab-0-1] DOIT en précharger un ou plus d'applications ou de composants de service avec un gestionnaire d'intents, pour toutes les Schémas de filtre d'intent public définis par les intents d'application suivants disponibles ici.

3. Logiciel

3.1. Compatibilité des API gérées

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

Implémentations pour les appareils:

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

  • [C-0-2] DOIT prendre en charge/préserver l'ensemble des classes, méthodes et éléments associés marquée par l'annotation TestApi (@TestApi).

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

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

  • [C-0-5] NE DOIT PAS autoriser les applications tierces à utiliser des interfaces non SDK, car celles-ci sont définis comme des méthodes et des champs dans les packages de langage Java qui sont dans le classpath de démarrage d'AOSP, et qui ne font pas partie SDK. Cela inclut les API décorées avec l'annotation @hide, mais pas avec un @SystemAPI, comme décrit dans les documents du SDK ; et les membres des classes privées et privées de packages.

  • [C-0-6] DOIT être livré avec chaque interface non SDK soumise à la même restriction fournies via les options provisoires et de blocage dans prebuilts/runtime/appcompat/hiddenapi-flags.csv pour la branche de niveau d'API appropriée dans AOSP.

  • [C-0-7] DOIT prendre en charge la configuration signée mécanisme de mise à jour dynamique permettant de supprimer les interfaces non SDK d'une liste restreinte en intégrant une configuration signée à n'importe quel APK à l'aide des clés publiques existantes. présentes dans AOSP.

    Cependant, ils:

    • PEUT-ÊTRE, si une API masquée est absente ou implémentée différemment sur l'appareil , déplacez l'API cachée dans la liste de blocage ou omettez-la toutes les listes restreintes.
    • PEUT-ÊTRE, si une API cachée n'existe pas déjà dans AOSP, ajoutez l'API cachée à l'une des listes restreintes.

Commencer les nouvelles exigences

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

Mettre fin aux nouvelles exigences

3.1.1. Extensions Android

Android permet d'étendre la surface d'API gérée d'un niveau d'API particulier en en mettant à jour la version de l'extension pour ce niveau d'API. La L'API android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) renvoie version d'extension du apiLevel fourni, s'il existe des extensions pour cette niveau d'API.

Implémentations pour les appareils Android:

  • [C-0-1] DOIT précharger l'implémentation AOSP des deux bibliothèques partagées ExtShared et les services ExtServices dont la version est supérieure ou égale à les versions minimales autorisées par niveau d'API. Par exemple, Android 7.0 implémentations d'appareils, l'exécution du niveau d'API 24 DOIT inclure au moins version 1.

  • [C-0-2] DOIT renvoyer uniquement un numéro de version d'extension valide qui a été défini par l'AOSP.

  • [C-0-3] DOIT prendre en charge toutes les API définies par les versions d'extension renvoyé par android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) de la même manière que les autres API gérées, conformément aux exigences indiquées dans la section 3.1.

3.1.2. Bibliothèque Android

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

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

La mise en œuvre d'AOSP répond à ces exigences.

3.2. Compatibilité avec les API soft

En plus des API gérées de la section 3.1, Android inclut également une API "soft" significative uniquement à l'environnement d'exécution, sous la forme d'une des éléments tels que les intents, les autorisations et d'autres aspects des applications Android qui ne peut pas être appliquée au moment de la compilation de l'application.

3.2.1. Autorisations

  • [C-0-1] Les responsables de la mise en œuvre des appareils DOIVENT prendre en charge et appliquer toutes les autorisations telles qu'indiquées sur la page de référence des autorisations. Notez que la section 9 répertorie d'autres liées au modèle de sécurité Android.

3.2.2. Paramètres de compilation

Les API Android incluent un certain nombre de constantes Classe android.os.Build qui décrivent l'appareil actuel.

  • [C-0-1] Fournir des valeurs cohérentes et significatives sur tous les appareils mises en œuvre, le tableau ci-dessous inclut des restrictions supplémentaires concernant les formats que les implémentations d'appareils DOIVENT respecter.
Paramètre Détails
VERSION.VERSION Version lisible par l'humain du système Android en cours d'exécution . Ce champ DOIT contenir l'une des valeurs de chaîne définies dans Chaînes de version autorisées pour Android 14.
VERSION.SDK Version du système Android en cours d'exécution, dans un format accessibles au code de l'application tierce. Pour Android 14, ce champ DOIT avoir la valeur entière 14_INT.
VERSION.SDK_INT Version du système Android en cours d'exécution, dans un format accessibles au code de l'application tierce. Pour Android 14, ce champ DOIT avoir la valeur entière 14_INT.
VERSION SUPPLÉMENTAIRE Une valeur choisie par le responsable de l'implémentation de l'appareil qui désigne le build spécifique du système Android en cours d'exécution, dans un format lisible par l'humain. Ce la valeur NE DOIT PAS être réutilisée pour différentes versions mises à la disposition des utilisateurs finaux. A ce champ est généralement utilisé pour indiquer le numéro ou l'identifiant de modification du contrôle des sources a été utilisé pour générer la compilation. La valeur de ce champ DOIT être encodable en tant que code ASCII 7 bits imprimable et correspondre à la l'expression régulière "^[^ :\/~]+$".
JEUX DE SOCIÉTÉ Une valeur choisie par le responsable de la mise en œuvre de l'appareil identifiant matériel interne utilisé par l'appareil, dans un format intelligible. Une ce champ permet d'indiquer la révision spécifique de la source d'alimentation de la carte l'appareil. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$".
MARQUE Valeur reflétant la marque associée à l'appareil, connue pour les utilisateurs finaux. DOIT être dans un format lisible et représenter fabricant de l'appareil ou la marque de l'entreprise sous laquelle l'appareil est commercialisés. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre L'expression régulière "^[a-zA-Z0-9_-]+$".
ABI_COMPATIBLES Nom de l'ensemble d'instructions (type de processeur + convention d'ABI) de l'API native du code source. Consultez la section 3.3. API native Compatibilité :
ABI_PRIS EN CHARGE_32_BIT Nom de l'ensemble d'instructions (type de processeur + convention d'ABI) de l'API native du code source. Consultez la section 3.3. API native Compatibilité :
SUPPORTED_64_BIT_ABIS Nom du deuxième ensemble d'instructions (type de processeur + convention ABI) de du code natif. Consultez la section 3.3. Format natif Compatibilité de l'API :
ABI_CPU Nom de l'ensemble d'instructions (type de processeur + convention d'ABI) de l'API native du code source. Consultez la section 3.3. API native Compatibilité :
CPU_ABI2 Nom du deuxième ensemble d'instructions (type de processeur + convention ABI) de du code natif. Consultez la section 3.3. Format natif Compatibilité de l'API :
APPAREIL Valeur choisie par l'outil de mise en œuvre de l'appareil contenant le nom du développement ou un nom de code identifiant la configuration des caractéristiques matérielles de conception industrielle. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$". Le nom de cet appareil NE DOIT PAS changer pendant la durée de vie du produit.
Empreinte Chaîne qui identifie cette compilation de manière unique. Cela DOIT être raisonnablement lisibles par l'humain. Il DOIT suivre ce modèle:

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

Exemple :

acme/monproduit/
mydevice:14/LMYXX/3359:userdebug/clé-test

L'empreinte NE DOIT PAS inclure d'espaces blancs. La valeur ce champ DOIT être encodable au format ASCII 7 bits.
MATÉRIEL Nom du matériel (depuis la ligne de commande du noyau ou /proc). Il DOIT être raisonnablement lisible par l'humain. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondant à l'expression régulière "^[a-zA-Z0-9_-]+$".
HÉBERGEUR Chaîne qui identifie de manière unique l'hôte sur lequel la compilation a été créée, dans dans un format lisible par l'humain. Il n'existe aucune exigence concernant le format spécifique ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide ("").
ID Un identifiant choisi par le responsable de la mise en œuvre de l'appareil pour faire référence à dans un format lisible par l'humain. Ce champ peut être identique à android.os.Build.VERSION.INCREMENTAL, mais DOIT être une valeur suffisante significatif pour les utilisateurs finaux de faire la distinction entre les versions logicielles. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre aux l'expression "^[a-zA-Z0-9._-]+$".
FABRICANT Dénomination commerciale du fabricant d'équipement d'origine (OEM) produit. Il n'y a aucune exigence sur le format spécifique de ce champ, sauf qu'elle NE DOIT PAS être nulle ou chaîne vide (""). Ce champ NE DOIT PAS changer pendant la durée de vie du produit.
FABRICANT_DE_SOC Nom commercial du fabricant du système principal sur (SOC) utilisée dans le produit. Appareils du même fabricant SOC doit utiliser la même valeur constante. Demandez au fabricant de votre SOC la constante correcte à utiliser. La valeur de ce champ DOIT être encodable au format ASCII sur 7 bits, DOIT correspondre à l'expression régulière "^([0-9A-Za-z ]+)", NE DOIT PAS commencer ni se terminer par un espace blanc. et NE DOIT PAS être égal à "inconnu". Ce champ NE DOIT PAS changer au cours de la durée de vie du produit.
MODÈLE SOC Nom de modèle du système principal sur une puce (SOC) utilisé dans le produit. Les appareils ayant le même modèle de SOC doivent utiliser la même constante . Demandez au fabricant de votre SOC la constante à utiliser. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre au l'expression régulière "^([0-9A-Za-z ._/+-]+)$", NE DOIT PAS commencer ni se terminer par un espace et NE DOIT PAS être égal à "inconnu". Ce champ NE DOIT PAS changer pendant la durée de vie du produit.
MODÈLE Valeur choisie par l'outil de mise en œuvre de l'appareil contenant le nom du appareil tel qu'il est connu de l'utilisateur final. Il DOIT être le même nom sous lequel l'appareil est commercialisé et vendu aux utilisateurs finaux. Il n'existe aucune exigence concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni le Chaîne vide (""). Ce champ NE DOIT PAS changer au cours de la durée de vie du produit.
PRODUIT Valeur choisie par l'outil de mise en œuvre de l'appareil contenant le nom du développement ou le nom de code du produit spécifique (SKU) qui DOIT être unique dans le d'une même marque. DOIT être lisible, mais n'est pas nécessairement destiné à la vue par les utilisateurs finaux. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$". Ce produit le nom NE DOIT PAS changer pendant la durée de vie du produit.
SKU_ODM Une valeur facultative choisie par le responsable de la mise en œuvre de l'appareil qui contient SKU (Stock Keeping Unit, unité de gestion des stocks) permettant de suivre des configurations spécifiques des (par exemple, tous les périphériques inclus avec l'appareil lorsqu'il est vendu). La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre au Expression régulière ^([0-9A-Za-z.,_-]+)$.
SÉRIE DOIT renvoyer la valeur "UNKNOWN".
TAGS Une liste de tags séparés par une virgule, choisis par le responsable de l'implémentation de l'appareil, permet de distinguer davantage la compilation. Les tags DOIVENT être encodables au format ASCII 7 bits. et correspondre à l'expression régulière "^[a-zA-Z0-9._-]+" et DOIT avoir l'une des valeurs correspondant aux trois plates-formes Android classiques ; configurations de signature: clés de publication, clés de développement et clés de test.
DURÉE Valeur représentant l'horodatage du moment où la compilation s'est produite.
MACH Valeur choisie par le responsable de la mise en œuvre de l'appareil spécifiant l'environnement d'exécution la configuration de la compilation. Ce champ DOIT contenir l'une des valeurs correspondant aux trois configurations d'exécution standards d'Android: user, userdebug ou eng.
UTILISATEUR Nom ou ID de l'utilisateur (ou de l'utilisateur automatisé) ayant généré la créer. Il n'y a aucune exigence sur le format spécifique de ce champ, sauf qu'elle NE DOIT PAS être nulle ou chaîne vide ("").
SÉCURITÉ_PATCH Valeur indiquant le niveau du correctif de sécurité d'un build. Cela DOIT signifier que la compilation n'est en aucune façon vulnérable aux problèmes décrits via le bulletin de sécurité publique d'Android désigné. Il DOIT se trouver dans au format [AAAA-MM-JJ], correspondant à une chaîne définie documentée dans le Sécurité publique Android Bulletin ou dans le Avis de sécurité Android, par exemple "2015-11-01".
OS DE BASE Valeur représentant le paramètre FINGERPRINT de la compilation qui est autrement identique à ce build, à l'exception des correctifs fournis dans Bulletin de sécurité publique d'Android Il DOIT indiquer la valeur correcte et si une telle compilation n'existe pas, signalez une chaîne vide ("").
CHARGEUR DE CHARGEMENT Une valeur choisie par le responsable de la mise en œuvre de l'appareil identifiant version interne du bootloader utilisé dans l’appareil, dans un format intelligible. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre au l'expression régulière "^[a-zA-Z0-9._-]+$".
getRadioVersion() DOIT (être ou renvoyer) une valeur choisie par l'outil de mise en œuvre de l'appareil identifiant la version radio/modem interne spécifique utilisée dans l’appareil, dans un format lisible par l'humain. Si un appareil ne dispose pas radio/modem, il DOIT renvoyer NULL. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondant à l'expression régulière "^[a-zA-Z0-9._-,]+$".
getSerial() DOIT être (être ou renvoyer) un numéro de série du matériel, qui DOIT être disponible et unique pour tous les appareils avec le même MODEL et le même MANUFACTURER. La valeur ce champ DOIT être encodable au format ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9]+$".

Compatibilité des intents

Intents d'application courants

Les intents Android permettent aux composants d'application de demander des fonctionnalités aux d'autres composants Android. Le projet Android en amont comprend une liste des applications qui implémentent plusieurs modèles d'intent pour effectuer des actions courantes.

Implémentations pour les appareils:

  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ de précharger une ou plusieurs applications ou les composants de service avec un gestionnaire d'intents, pour tous les filtres d'intent publics ; Modèles définis par les intents d'application suivants, qui sont répertoriés ici et assurer le traitement, c'est-à-dire répondre aux attentes des développeurs les intents d'application décrits dans le SDK.

Veuillez consulter la section 2 pour en savoir plus sur les intents d'application obligatoires. pour chaque type d'appareil.

Résolution d'intent

  • [C-0-1] Android étant une plate-forme extensible, les implémentations d'appareils DOIVENT IMPÉRATIVEMENT autoriser chaque modèle d'intent référencé dans la section 3.2.3.1 ; , à l'exception des paramètres, pour être remplacé par des applications tierces. La l'implémentation Open Source d'Android en amont le permet par défaut.

  • [C-0-2] Les responsables de la mise en œuvre de l'appareil NE DOIVENT PAS accorder de privilèges spéciaux au système des applications l'utilisation de ces modèles d'intent ou empêcher les applications tierces de lier et de prendre le contrôle de ces modèles. Cette interdiction Elle inclut, sans s'y limiter, la désactivation de l'utilisateur "Sélecteur". qui permet à l'utilisateur de choisir parmi plusieurs applications gèrent le même modèle d'intent.

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

  • Cependant, les implémentations d'appareils PEUVENT fournir des activités par défaut pour des Formats d'URI (par exemple, http://play.google.com) lorsque l'activité par défaut fournit une un attribut plus spécifique pour l'URI de données. Par exemple, un schéma de filtre d'intent l'URI de données "http://www.android.com" est plus spécifique que le schéma d'intention principal du navigateur, pour "http://".

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

  • [C-0-4] DOIT essayer de valider les filtres d'intent en effectuant l' les étapes de validation définies dans la spécification Digital Asset Links. tel qu'il est implémenté par le gestionnaire de packages dans le package Android Open Source en amont Projet.
  • [C-0-5] DOIT tenter de valider les filtres d'intent pendant l'installation de l'application et définir tous les filtres d'intent d'URI correctement validés en tant que des gestionnaires d'application par défaut pour leurs URI.
  • PEUT définir des filtres d'intent d'URI spécifiques comme gestionnaires d'application par défaut pour leurs URI, s'ils sont validés, mais que les autres filtres d'URI des candidats échouent. la validation. Si une implémentation d'appareil le fait, elle DOIT indiquer la remplacements de format par URI appropriés à l'utilisateur dans le menu des paramètres.
  • DOIT fournir à l'utilisateur des commandes de liens vers une application par application dans les paramètres, ce qui suit:
    • [C-0-6] L'utilisateur DOIT pouvoir ignorer de manière globale l'application par défaut comportement des liens pour qu'une application soit toujours ouverte, toujours demander ou ne jamais ouvrir, qui doit s'appliquer de manière égale à tous les filtres d'intent d'URI candidats.
    • [C-0-7] L'utilisateur DOIT pouvoir voir la liste de l'intent d'URI candidat des filtres.
    • L'implémentation de l'appareil PEUT donner à l'utilisateur la possibilité de remplacer les filtres d'intents d'URI candidats spécifiques qui ont bien été vérifiés, par filtre d'intent.
    • [C-0-8] L'implémentation d'un appareil DOIT donner aux utilisateurs la possibilité de afficher et remplacer des filtres d'intent d'URI candidats spécifiques si l'appareil permet à certains filtres d'intent d'URI candidats de réussir la validation, tandis que d'autres peuvent échouer.
Espaces de noms des intents
  • [C-0-1] Les implémentations d'appareils NE DOIVENT PAS inclure de composants Android qui respecte tout nouvel intent ou modèle d'intent de diffusion à l'aide d'une fonction ACTION, CATEGORY ou Autre chaîne de clé dans l'espace de noms android.* ou com.android.*.
  • [C-0-2] Les responsables de la mise en œuvre des appareils NE DOIVENT PAS inclure de composants Android : honorer tout nouvel intent ou modèle d'intent de diffusion à l'aide d'une fonction ACTION, CATEGORY ou une autre chaîne de clé dans un espace de package appartenant à une autre organisation.
  • [C-0-3] Les responsables de la mise en œuvre de l'appareil NE DOIVENT PAS modifier ni étendre les intents des modèles indiqués dans la section 3.2.3.1.
  • Les implémentations d'appareils PEUVENT inclure clairement des modèles d'intent utilisant des espaces de noms. et bien évidemment associés à leur propre organisation. Cette interdiction analogue à celle spécifiée pour les classes de langage Java dans la section 3.6.
Intents de diffusion

Les applications tierces s'appuient sur la plate-forme pour diffuser certains intents les informer des changements dans l’environnement matériel ou logiciel.

Implémentations pour les appareils:

  • [C-0-1] DOIT diffuser les intents de diffusion publique répertoriés ici en réponse à des événements système appropriés, comme décrit dans la documentation du SDK. Notez que cette exigence n'entre pas en conflit avec la section 3.5, car les pour les applications en arrière-plan sont également décrites dans le SDK dans la documentation Google Cloud. Par ailleurs, certains intents de diffusion dépendent du matériel. prise en charge. Si l'appareil prend en charge le matériel nécessaire, il DOIT diffuser le et fournir le comportement conformément à la documentation du SDK.
Intents d'application conditionnels

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

Le cas échéant, les implémentations d'appareils DOIVENT fournir des paramètres similaires et être compatible avec le schéma de filtre d'intent et les méthodes d'API décrites dans la documentation du SDK, comme ci-dessous.

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

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

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

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

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

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

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

  • [C-6-1] DOIT implémenter une activité qui répond à l'intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS, Pour les implémentations avec UI_MODE_TYPE_NORMAL, il DOIT donc s'agir d'une activité où l'utilisateur peut accorder ou refuser à l'application l'accès aux configurations des règles Ne pas déranger.

Si les implémentations d'appareils permettent aux utilisateurs d'utiliser des modes de saisie tiers appareil, ils:

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

  • [C-8-1] DOIT respecter les android.settings.ACCESSIBILITY_SETTINGS fournir un mécanisme accessible à l'utilisateur permettant d'activer et de désactiver des services d'accessibilité tiers parallèlement aux fonctionnalités d'accessibilité préchargées services.

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

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

Si les implémentations d'appareils ne proposent pas le mode Économiseur de données:

Si les intégrations d'appareils déclarent la prise en charge de la caméra via android.hardware.camera.any:

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

Si les intégrations d'appareils déclarent le android.software.autofill de fonctionnalité, ils:

  • [C-14-1] DOIT implémenter intégralement la AutofillService et AutofillManager API et respecter les conditions d'utilisation de android.settings.REQUEST_SET_AUTOFILL_SERVICE intention d'afficher un menu de paramètres par défaut de l'application pour activer et désactiver la saisie automatique et modifier le service de saisie automatique par défaut pour l'utilisateur.

Si les implémentations d'appareils incluent une application préinstallée ou si vous souhaitez autoriser applications tierces à accéder aux statistiques d'utilisation, elles:

  • [C-SR-2] sont VIVEMENT RECOMMANDÉS de fournir un mécanisme accessible à l'utilisateur pour accorder ou révoquer l'accès aux statistiques d'utilisation en réponse à une android.settings.ACTION_USAGE_ACCESS_SETTINGS intent pour les applications qui déclarent l'android.permission.PACKAGE_USAGE_STATS l'autorisation.

Si les mises en œuvre de l'appareil visent à interdire certaines applications, y compris celles préinstallées applications, d'accéder aux statistiques d'utilisation, elles:

  • [C-15-1] DOIT toujours disposer d'une activité qui gère android.settings.ACTION_USAGE_ACCESS_SETTINGS mais il DOIT l'implémenter en tant que no-op, c'est-à-dire avoir un équivalent comme lorsque l'accès de l'utilisateur est refusé.

Si les implémentations d'appareils affichent des liens vers les activités spécifiées par AutofillService_passwordsActivity dans les paramètres ou via des liens vers les mots de passe des utilisateurs via un mécanisme similaire:

  • [C-16-1] DOIT faire apparaître ces liens pour tous les services de saisie automatique installés.

Si les implémentations d'appareils sont compatibles avec le VoiceInteractionService et que davantage plusieurs applications utilisant cette API à la fois, elles:

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

  • [C-SR-3] Il est FORTEMENT RECOMMANDÉ de respecter android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA et Les intents android.speech.tts.engine.GET_Sample_TEXT ont une activité à fournir pour ces intents, comme décrit dans le SDK ici.

Android est compatible avec les économiseurs d'écran interactifs, auparavant appelés en tant que Dreams. Les économiseurs d'écran permettent aux utilisateurs d'interagir avec les applications lorsqu'un appareil connecté à une source d'alimentation est inactif ou sur la station d'accueil d'un bureau. Implémentations sur les appareils:

  • DEVRAIT inclure la prise en charge des économiseurs d'écran et fournir une option de paramétrage pour aux utilisateurs de configurer les économiseurs d'écran Intent android.settings.DREAM_SETTINGS.

Commencer les nouvelles exigences

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

Mettre fin aux nouvelles exigences

Activités sur des écrans secondaires ou multiples

Si les implémentations d'appareils permettent le lancement d'activités Android normales sur plus de un seul écran, ils:

  • [C-1-1] DOIT définir le paramètre android.software.activities_on_secondary_displays flag de fonctionnalité.
  • [C-1-2] DOIT garantir une compatibilité d'API semblable à celle d'une activité exécutée sur l'écran principal.
  • [C-1-3] DOIT envoyer la nouvelle activité sur le même écran que l'activité lorsque la nouvelle activité est lancée sans spécifier de cible afficher via ActivityOptions.setLaunchDisplayId() API.
  • [C-1-4] DOIT détruire toutes les activités lorsqu'un écran avec Display.FLAG_PRIVATE est supprimé.
  • [C-1-5] DOIT masquer de façon sécurisée le contenu sur tous les écrans lorsque l'appareil est verrouillé avec un écran de verrouillage sécurisé, sauf si l'application accepte de s'afficher en haut de la serrure écran avec Activity#setShowWhenLocked() API.
  • DEVRAIT inclure android.content.res.Configuration correspondant à cet affichage, utilisez correctement et maintenir la compatibilité si une activité est lancée sur l'écran secondaire.

Si les implémentations d'appareils permettent le lancement d'activités Android normales sur des applications secondaires écrans, tandis qu'un écran secondaire dispose de l'autorisation android.view.Display.FLAG_PRIVATE. :

  • [C-3-1] Seul le propriétaire de l'écran, du système et des activités déjà sur cet écran DOIT pouvoir y être lancé. Tout le monde peut lancer vers un écran comportant android.view.Display.FLAG_PUBLIC ; .

3.3. Compatibilité avec les API natives

La compatibilité avec le code natif est complexe. Pour cette raison, les responsables de la mise en œuvre d'appareils:

  • [C-SR-1] FORTEMENT RECOMMANDÉ d'utiliser les implémentations des bibliothèques listées ci-dessous à partir du projet Android Open Source en amont.

3.3.1. Interfaces binaires d'application

Le bytecode Dalvik géré peut appeler le code natif fourni dans l'application .apk en tant que fichier ELF .so compilé pour le matériel approprié de l'appareil de l'architecture. Le code natif dépend fortement du processeur sous-jacent Android, Android définit un certain nombre d'interfaces binaires d'application (ABI) dans Android NDK.

Implémentations pour les appareils:

  • [C-0-1] DOIT être compatible avec une ou plusieurs ABI du NDK Android définies.
  • [C-0-2] DOIT inclure la prise en charge du code exécuté dans l'environnement géré pour appeler du code natif à l'aide de l'interface JNI (Java Native Interface) standard la sémantique.
  • [C-0-3] DOIT être compatible avec la source (compatible avec les en-têtes) compatible binaire (pour l'ABI) avec chaque bibliothèque requise dans la liste ci-dessous.
  • [C-0-5] DOIT indiquer précisément l'interface binaire d'application native (ABI) pris en charge par l'appareil, via android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS Paramètres android.os.Build.SUPPORTED_64_BIT_ABIS séparés par une virgule liste des ABI classées de la plus forte à la moins préférée.

  • [C-0-6] DOIT signaler, à l'aide des paramètres ci-dessus, un sous-ensemble des liste d'ABI et NE DOIT PAS indiquer d'ABI qui ne figure pas sur cette liste.

  • [C-0-7] DOIT créer toutes les bibliothèques suivantes, en fournissant des API natives, disponibles pour les applications qui incluent du code natif:

    • libaaudio.so (compatibilité native avec AAudio)
    • libamidi.so (compatibilité MIDI native, avec la fonctionnalité android.software.midi) est revendiquée comme décrit dans la Section 5.9).
    • libandroid.so (prise en charge des activités Android natives)
    • libc (bibliothèque C)
    • libcamera2ndk.so
    • libdl (lien dynamique)
    • libEGL.so (gestion de la surface OpenGL native)
    • libGLESv1_CM.so (OpenGL ES 1.x)
    • libGLESv2.so (OpenGL ES 2.0)
    • libGLESv3.so (OpenGL ES 3.x)
    • libicui18n.so
    • libicuuc.so
    • libjnigraphics.so
    • liblog (journalisation Android)
    • libmediandk.so (compatibilité avec les API de médias natifs)
    • libm (bibliothèque de mathématiques)
    • libneuralnetworks.so (API Neural Networks)
    • libOpenMAXAL.so (compatible avec OpenMAX AL 1.0.1)
    • libOpenSLES.so (compatibilité audio OpenSL ES 1.0.1)
    • libRS.so
    • libstdc++ (compatibilité minimale avec C++)
    • libvulkan.so (Vulkan)
    • libz (compression Zlib)
    • Interface JNI

  • [C-0-8] NE DOIT PAS ajouter ni supprimer de fonctions publiques pour les bibliothèques natives comme indiqué ci-dessus.

  • [C-0-9] DOIT répertorier des bibliothèques supplémentaires non-AOSP exposées directement à applications tierces dans le pays suivant : /vendor/etc/public.libraries.txt.

  • [C-0-10] NE DOIT PAS exposer d'autres bibliothèques natives, implémentées et fournies dans AOSP en tant que bibliothèques système, à des applications tierces ciblant l'API de niveau 24 ou supérieur, car elles sont réservées.

  • [C-0-11] DOIT exporter tous les éléments OpenGL ES 3.1 et Android Extension Pack symboles de fonction, tels que définis dans le NDK, via la bibliothèque libGLESv3.so. Notez que si tous les symboles DOIVENT être présents, la section 7.1.4.1 décrit les exigences liées à la mise en œuvre complète les fonctions correspondantes sont attendues.

  • [C-0-12] DOIT exporter les symboles de fonction pour la version principale de Vulkan 1.0. Fonction Vulkan 1.1 ainsi que les éléments VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 et VK_KHR_get_physical_device_properties2 via le libvulkan.so. Notez que même si tous les symboles DOIVENT être présents, section 7.1.4.2 décrit plus en détail les exigences liées aux l'implémentation de chaque fonction correspondante est attendue.

  • DEVRAIT être créé à l'aide du code source et des fichiers d'en-tête disponibles dans projet Android Open Source en amont.

Notez que les prochaines versions d'Android pourront inclure d'autres ABI.

3.3.2. Compatibilité avec le code natif ARM 32 bits

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

  • [C-3-1] DOIT également accepter armeabi-v7a et signaler sa compatibilité, car armeabi est uniquement destiné à assurer la rétrocompatibilité avec les anciennes applications.

Si les implémentations d'appareils indiquent la prise en charge de l'ABI armeabi-v7a, pour les applications à l'aide de cette ABI:

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

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

  • [C-2-2] DOIT toujours assurer la disponibilité des opérations suivantes, même dans le dans lequel l'ABI est implémentée sur une architecture ARMv8, compatible avec les processeurs natifs ou via l'émulation logicielle:

    • Instructions SWP et SWPB
    • Opérations de barrières CP15ISB, CP15DSB et CP15DMB

  • [C-2-3] DOIT inclure la prise en charge du module Advanced SIMD (ou NEON).

3.4. Compatibilité Web

3.4.1. Compatibilité avec WebView

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

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

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

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

    • La valeur de la chaîne $(VERSION) DOIT être identique à la valeur de android.os.Build.VERSION.Release.
    • La chaîne $(MODEL) PEUT être vide, mais si elle n'est pas vide, elle DOIT avoir la même valeur que android.os.Build.MODEL.
    • "Build/$(CRÉER)" PEUT être omis, mais si elle est présente, l'élément $(Build) La chaîne DOIT être identique à la valeur d'android.os.Build.ID.
    • La valeur de la chaîne $(CHROMIUM_VER) DOIT être la version de Chromium dans le projet Open Source Android en amont.
    • Il est possible que les implémentations d'appareils omettent "Mobile" dans la chaîne de l'agent utilisateur.

  • Le composant WebView DOIT inclure un maximum de fonctionnalités HTML5 possible et, s'il prend en charge, la fonctionnalité DOIT être conforme au Spécification HTML5

  • [C-1-4] DOIT rendre le contenu fourni ou le contenu de l'URL distante au cours d'un processus distincte de l'application qui instancie la WebView. Plus précisément, le processus du moteur de rendu distinct DOIT disposer d'un privilège inférieur, exécutez en tant qu'ID utilisateur distinct, n'ont pas accès au répertoire de données de l'application, n'ont pas d'accès direct au réseau et n'ont accès qu'aux ressources minimales des services système via Binder. L'implémentation AOSP de WebView répond aux cette exigence.

Notez que si les implémentations d'appareils sont 32 bits ou que vous déclarez le flag de fonctionnalité. android.hardware.ram.low, elles sont exemptées de l'instruction C-1-3.

Compatibilité du navigateur

Si les implémentations d'appareils incluent une application de navigateur autonome sur le Web, ils:

  • [C-1-1] DOIT prendre en charge chacune des API associées HTML5:
  • [C-1-2] DOIT prendre en charge les formats HTML5/W3C webstorage et DOIT prendre en charge les formats HTML5/W3C API IndexedDB : Notez que comme le Web les organismes de normalisation de développement opèrent une transition pour favoriser IndexedDB. Webstorage, IndexedDB devrait devenir un composant obligatoire dans un la prochaine version d'Android.
  • PEUT envoyer une chaîne user-agent personnalisée dans l'application de navigateur autonome.
  • DEVRAIT mettre en œuvre la prise en charge d'autant de HTML5 dans la version autonome Application de navigateur (basée sur le navigateur WebKit en amont) application de remplacement ou la solution de remplacement tierce).

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

  • [C-2-1] DOIT toujours prendre en charge les modèles d'intent public décrits dans section 3.2.3.1.

3.5. Compatibilité comportementale de l'API

Implémentations pour les appareils:

  • [C-0-9] DOIT s'assurer que la compatibilité comportementale de l'API est appliquée à toutes les applications installées, à moins qu'elles ne soient soumises aux restrictions décrites dans la section Section 3.5.1.
  • [C-0-10] NE DOIT PAS implémenter l'approche d'ajout à la liste d'autorisation qui garantit compatibilité comportementale uniquement pour les applis sélectionnées par appareil les responsables de la mise en œuvre.

Le comportement de chacun des types d'API (gérées, logicielles, natives et Web) doit être conforme à l'implémentation préférée de l'infrastructure en amont Projet Android Open Source Certaines zones spécifiques de compatibilité sont les suivants:

  • [C-0-1] Les appareils NE DOIVENT PAS modifier le comportement ni la sémantique d'un l'intent standard.
  • [C-0-2] Les appareils NE DOIVENT PAS modifier la sémantique du cycle de vie Un type particulier de composant système (tel que Service, Activity, ContentProvider, etc.)
  • [C-0-3] Les appareils NE DOIVENT PAS modifier la sémantique d'une autorisation standard.
  • Les appareils NE DOIVENT PAS modifier les limites appliquées aux applications en arrière-plan. En particulier, pour les applications en arrière-plan:
    • [C-0-4], ils DOIVENT cesser d'exécuter des rappels enregistrés par le service l'application pour recevoir les sorties de GnssMeasurement et GnssNavigationMessage.
    • [C-0-5] ils DOIVENT limiter la fréquence des mises à jour fournies à l'application via LocationManager ou la classe d'API WifiManager.startScan() .
    • [C-0-6] Si l'application cible le niveau d'API 25 ou supérieur, elle NE DOIT PAS permettent d'enregistrer des broadcast receivers pour les diffusions implicites des intents Android standards dans le fichier manifeste de l'application, sauf si la diffusion l'intent requiert un "signature" ou un "signatureOrSystem" protectionLevel ou se trouvent sur le liste d'exemptions.
    • [C-0-7] Si l'application cible le niveau d'API 25 ou supérieur, elle DOIT s'arrêter services d'arrière-plan de l'application, comme si l'application avait appelé services stopSelf() , à moins que l'application ne soit placée sur une liste d'autorisation temporaire pour gérer visible par l'utilisateur.
    • [C-0-8] Si l'application cible le niveau d'API 25 ou supérieur, elle DOIT pour libérer les wakelocks que l'application contient.
  • [C-0-11] Les appareils DOIVENT renvoyer les fournisseurs de sécurité suivants en premier sept valeurs de tableau Security.getProviders() , dans l'ordre indiqué et avec les noms donnés (tels que renvoyés par Provider.getName()) et ses classes, sauf si l'application a modifié la liste via insertProviderAt() ou removeProvider(). Appareils PEUT renvoyer des fournisseurs supplémentaires après la liste de fournisseurs spécifiée ci-dessous.
    1. AndroidNSSP – android.security.net.config.NetworkSecurityConfigProvider
    2. AndroidOpenSSL : com.android.org.conscrypt.OpenSSLProvider
    3. CertPathProvider : sun.security.provider.CertPathProvider
    4. AndroidKeyStoreBCSolution : android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
    5. BC – com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
    6. HarmonyJSSE – com.android.org.conscrypt.JSSEProvider
    7. AndroidKeyStore – android.security.keystore.AndroidKeyStoreProvider

La liste ci-dessus n'est pas exhaustive. Tests de la suite de tests de compatibilité (CTS) une partie importante de la plate-forme pour la compatibilité comportementale, mais pas toutes. Il est de la responsabilité de l'outil d'implémentation de s'assurer de la compatibilité du comportement avec le projet Android Open Source. Pour cette raison, les responsables de la mise en œuvre DEVRAIT utiliser le code source disponible via le projet Android Open Source où au lieu de réimplémenter des parties importantes du système.

3.5.1. Restriction d'application

Si les implémentations d'appareils implémentent un mécanisme propriétaire pour restreindre les applications (par exemple, en modifiant ou en limitant les comportements d'une API décrit dans le SDK) et ce mécanisme est plus restrictif que le bucket de mise en veille des applications limitées:

  • [C-1-1] DOIT autoriser l'utilisateur à voir la liste des applications soumises à restriction.
  • [C-1-2] DOIT fournir une affordance à l'utilisateur pour activer / désactiver toutes ces options des restrictions propriétaires sur chaque application.

  • [C-1-3] NE DOIT PAS appliquer automatiquement ces restrictions propriétaires preuve d'un mauvais comportement de l'état du système, mais PEUT appliquer les restrictions sur les applications lors de la détection d'un mauvais comportement de l'état du système, comme les wakelocks figés, les les services et d'autres critères. Les critères PEUVENT être déterminés par l'appareil mais DOIT être lié à l'impact de l'application sur l'état du système. Autre des critères qui ne sont pas uniquement liés à l'état du système, comme le manque de popularité sur le marché, NE DOIVENT PAS être utilisés comme critères.

  • [C-1-4] NE DOIT PAS appliquer automatiquement ces restrictions propriétaires aux applications Lorsqu'un utilisateur a désactivé manuellement les restrictions de l'application et PEUT suggérer à l'utilisateur pour appliquer ces restrictions propriétaires.

  • [C-1-5] DOIT informer les utilisateurs si ces restrictions propriétaires s'appliquent automatiquement une application. Ces informations DOIVENT être fournies dans le délai de 24 heures précédant l'application de ces restrictions propriétaires.

  • [C-1-6] DOIT renvoyer la valeur "true" pour ActivityManager.isBackgroundRestricted(). pour tous les appels d'API à partir d'une application.

  • [C-1-7] NE DOIT PAS limiter l'application au premier plan qui est explicitement utilisée par l'utilisateur.

  • [C-1-8] DOIT suspendre ces restrictions propriétaires d'une application chaque fois qu'un L'utilisateur commence à utiliser explicitement l'application, ce qui en fait le premier plan application.

  • [C-1-10] DOIT fournir un document ou un site Web public et clair décrivant comment les restrictions propriétaires sont appliquées. Ce document ou ce site Web DOIT être accessible via un lien à partir des documents du SDK Android et DOIT inclure ce qui suit:

    • Conditions de déclenchement des restrictions propriétaires
    • les types de restrictions qui peuvent être appliqués à une application et de quelle manière ;
    • Les modalités d'exemption de ces restrictions pour une application
    • Comment une application peut demander une exemption des restrictions propriétaires, si elle prennent en charge ce type d'exception pour les applications que l'utilisateur peut installer.

Si une application est préinstallée sur l'appareil et qu'elle n'a jamais été explicitement utilisée par un utilisateur utilisateur depuis plus de 30 jours, les [C-1-3] [C-1-5] sont exemptés.

Si les implémentations d'appareils étendent les restrictions appliquées aux applications dans AOSP:

  • [C-2-1]DOIT suivre la procédure d'implémentation décrite dans ce document.

3.5.2. Hibernation des applications

Si les implémentations d'appareils incluent l'hibernation des applications qui est incluse dans AOSP ou étend la fonctionnalité qui est incluse dans AOSP, alors ils:

  • [C-1-1] DOIT respecter toutes les exigences de la section 3.5.1, à l'exception des [C-1-6] et [C-1-3].
  • [C-1-2] DOIT appliquer la restriction sur l'application uniquement pour un utilisateur la preuve que l'utilisateur n'a pas utilisé l'application depuis un certain temps. Ce il est FORTEMENT RECOMMANDÉ de durer un mois ou plus. L'utilisation DOIT être défini par une interaction explicite de l'utilisateur via UsageStats#getLastTimeVisible() ou tout autre élément qui pousserait une application à quitter l'état d'arrêt forcé, y compris les liaisons de service, de fournisseur de contenu, de diffusions explicites, etc. qui sera suivi par une nouvelle API UsageStats#getLastTimeAnyComponentUsed().
  • [C-1-3] DOIT appliquer uniquement des restrictions affectant tous les utilisateurs de l'appareil est la preuve que le package n'a été utilisé par AUCUN utilisateur depuis un certain temps en temps réel. Il est FORTEMENT RECOMMANDÉ de choisir une durée d'au moins un mois.
  • [C-1-4] NE DOIT PAS rendre l'application incapable de répondre aux intents d'activité, les liaisons de service, les requêtes de fournisseurs de contenu ou les diffusions explicites.

L'hibernation des applications dans AOSP répond aux exigences ci-dessus.

3.6. Espaces de noms de l'API

Android suit les conventions d'espace de noms des packages et des classes définies par le code Java langage de programmation. Pour assurer la compatibilité avec les applications tierces, les responsables de la mise en œuvre de l'appareil NE DOIVENT PAS apporter de modifications interdites (voir ci-dessous) aux ces espaces de noms de package:

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

En d'autres termes, ils:

  • [C-0-1] NE DOIT PAS modifier les API exposées publiquement sur la plate-forme Android en modifiant une méthode ou une signature de classe, ou en supprimant des classes ou des classes .
  • [C-0-2] NE DOIT PAS ajouter d'éléments exposés publiquement (tels que des classes ou des interfaces, des champs ou des méthodes à des classes ou des interfaces existantes), ou des tests ou les API système aux API dans les espaces de noms ci-dessus. Une application « publiquement exposée " correspond à toute construction qui n'est pas ornée du symbole "@hide" marquer comme utilisés dans le code source Android en amont.

Les responsables de la mise en œuvre des appareils PEUVENT modifier l'implémentation sous-jacente des API, mais de telles modifications:

  • [C-0-3] NE DOIT PAS avoir une incidence sur le comportement indiqué ni sur la signature en langage Java les API exposées publiquement.
  • [C-0-4] NE DOIT PAS être promus ni présentés aux développeurs d'une autre manière.

Cependant, les responsables de la mise en œuvre d'appareils PEUVENT ajouter des API personnalisées en dehors de la version standard d'Android mais les API personnalisées:

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

Les spécialistes de l'implémentation d'appareils PEUVENT ajouter des API personnalisées dans des langues natives, en dehors du NDK. mais les API personnalisées:

  • [C-1-1] NE DOIT PAS faire partie d'une bibliothèque NDK ou d'une bibliothèque appartenant à un autre l'organisation, comme décrit cliquez ici.

Si un responsable de la mise en œuvre d'appareils propose d'améliorer l'un des espaces de noms de package ci-dessus (par exemple, en ajoutant de nouvelles fonctionnalités utiles à une API existante, ou en ajoutant une nouvelle API), l'outil de mise en œuvre DOIT accéder à source.android.com. et entamer le processus pour apporter des modifications aux changements et en fonction des informations fournies sur ce site.

Notez que les restrictions ci-dessus correspondent aux conventions standards de dénomination les API en langage de programmation Java ; Cette section vise simplement à renforcer ces conventions et les lieront par leur inclusion dans ce tableau de compatibilité Définition.

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

Implémentations pour les appareils:

  • [C-0-1] DOIT prendre en charge le format Dalvik Executable (DEX) complet et la spécification et la sémantique du bytecode Dalvik.

  • [C-0-2] DOIT configurer les environnements d'exécution Dalvik pour allouer de la mémoire conformément à la plate-forme Android en amont, et comme spécifié par dans le tableau suivant. Consultez la section 7.1.1 pour les définitions de la taille d'écran et de la densité de l'écran.)

  • DEVRAIT utiliser Android RunTime (ART), la référence en amont du format exécutable Dalvik et la référence de gestion des packages de votre implémentation.

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

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

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

3.8. Compatibilité de l'interface utilisateur

Lanceur d'applications (écran d'accueil)

Android inclut un lanceur d'applications (écran d'accueil) et prend en charge des applications tierces pour remplacer le lanceur d'applications de l'appareil (écran d'accueil).

Si les implémentations d'appareils autorisent des applications tierces à le remplacer l'écran d'accueil, ils:

  • [C-1-1] DOIT déclarer la fonctionnalité de plate-forme android.software.home_screen.
  • [C-1-2] DOIT renvoyer le code AdaptiveIconDrawable lorsque l'application tierce utilise le tag <adaptive-icon> pour fournir leur icône, et le PackageManager de récupération d'icônes.

Si les implémentations de l'appareil incluent un lanceur d'applications par défaut compatible avec les applications épinglage des raccourcis, ils:

À l'inverse, si les implémentations sur les appareils ne sont pas compatibles avec l'épinglage raccourcis, ils:

Si les implémentations d'appareils implémentent un lanceur par défaut qui fournit des l'accès aux raccourcis supplémentaires fournis par des applications tierces via les Gestionnaire de raccourcis API, ils:

  • [C-4-1] DOIT prendre en charge toutes les fonctionnalités de raccourci documentées (par exemple, les raccourcis statiques et les raccourcis dynamiques, épingler les raccourcis) et implémenter intégralement les API de la ShortcutManager classe d'API Google Cloud.

Si les implémentations de l'appareil incluent une application de lancement par défaut qui affiche des badges pour les icônes de l'application:

  • [C-5-1] DOIT respecter les NotificationChannel.setShowBadge() . En d'autres termes, affichez une affordance visuelle associée à l'icône d'application si l' est définie sur true et n'affiche aucun schéma de badge d'icône d'application lorsque toutes des canaux de notification de l'application ont défini la valeur sur false.
  • PEUT remplacer les badges des icônes d'applications par leur système de badges propriétaire lorsque Les applications tierces indiquent la compatibilité avec le système de badges propriétaires. via l'utilisation d'API propriétaires, mais DEVRAIT utiliser les ressources et les valeurs fournies via les API de badges de notification décrites dans le SDK , par exemple Notification.Builder.setNumber() et la Notification.Builder.setBadgeIconType() API.

Si les implémentations d'appareils prennent en charge monochrome des icônes, ces icônes:

  • [C-6-1] DOIT être utilisé uniquement lorsqu'un utilisateur les active explicitement (par exemple, via Paramètres ou menu de sélection du fond d'écran).

Widgets

Android prend en charge les widgets d'application tiers en définissant un type de composant et et le cycle de vie correspondants permettant aux applications d'exposer "AppWidget" à l'utilisateur final.

Si les implémentations d'appareils sont compatibles avec les widgets d'application tiers:

  • [C-1-1] DOIT déclarer la prise en charge de la fonctionnalité de la plate-forme android.software.app_widgets

  • [C-1-2] DOIT inclure la compatibilité intégrée avec les AppWidgets et exposer affordances de l'interface utilisateur permettant d'ajouter, de configurer, d'afficher et de supprimer des AppWidgets.

  • [C-1-3] DOIT être capable d'afficher des widgets 4 x 4 à la taille de grille standard. Consultez les Consignes de conception des widgets d'application. dans la documentation du SDK Android.

  • PEUT prendre en charge les widgets d'application sur l'écran de verrouillage.

Si les implémentations d'appareils sont compatibles avec les widgets d'application tiers et les applications intégrées épinglage des raccourcis, il:

3.8.3. Notifications

Android inclut Notification et NotificationManager API qui permettent aux développeurs d'applications tierces d'informer les utilisateurs d'événements importants et attirer les utilisateurs l'attention à l'aide de composants matériels (son, vibration, etc.) et des fonctionnalités logicielles (volet des notifications, barre système, etc.) appareil.

Présentation des notifications

Si les implémentations sur les appareils permettent aux applications tierces d'avertir les utilisateurs en cas d'événements notables, elles:

  • [C-1-1] DOIT prendre en charge les notifications qui utilisent des fonctionnalités matérielles, comme décrit dans la documentation du SDK et, dans la mesure du possible, via l'implémentation matériel. Par exemple, si l'implémentation d'un appareil inclut un vibreur, elle DOIT implémenter correctement les API de vibreur. Si l'implémentation d'un appareil manque les API correspondantes DOIVENT être implémentées en tant que no-ops. Ce comportement est plus en détail dans la section 7.
  • [C-1-2] DOIT afficher correctement toutes les ressources (icônes, fichiers d'animation, etc.) fournis dans les API ou dans le Guide de style des icônes de la barre d'état/système bien qu'elles PEUVENT fournir une expérience utilisateur alternative pour les notifications que celui fourni par l'implémentation de référence Android Open Source.
  • [C-1-3] DOIT respecter et mettre en œuvre correctement les comportements décrits pour les API pour mettre à jour, supprimer et regrouper les notifications.
  • [C-1-4] DOIT fournir le comportement complet de NotificationChannel documentée dans le SDK.
  • [C-1-5] DOIT fournir une affordance d'utilisateur pour bloquer et modifier une certaine des notifications de l'application tierce pour chaque canal et niveau de package d'application.
  • [C-1-6] DOIT également fournir une affordance d'utilisateur pour afficher les notifications supprimées canaux de distribution.

  • [C-1-7] DOIT afficher correctement toutes les ressources (images, autocollants, icônes, etc.) via Notification.MessagingStyle à côté du texte de la notification sans action supplémentaire de l'utilisateur. Pour exemple, DOIT afficher toutes les ressources, y compris les icônes fournies via android.app.Person dans une conversation de groupe définie par setGroupConversation

  • [C-SR-1] Sont FORTEMENT RECOMMANDÉS de fournir une affordance à l'utilisateur contrôler les notifications exposées aux applications auxquelles le Autorisation "Écouteur des notifications". La précision DOIT être de sorte que l'utilisateur puisse pour contrôler, pour chaque écouteur de notifications, les types de notifications associé à cet écouteur. Les types DOIVENT inclure "conversations", "alertes", "silencieux" et "important en cours" les notifications.

  • [C-SR-2] SONT FORTEMENT RECOMMANDÉS de fournir une affordance que les utilisateurs peuvent spécifier applications à exclure de l'envoi de notifications à un écouteur de notifications spécifique.

  • [C-SR-3] SONT FORTEMENT RECOMMANDÉS de mettre automatiquement en avant une affordance de l'utilisateur pour bloquer les notifications d'une application tierce spécifique pour chaque canal et application au niveau du package après que l'utilisateur a ignoré cette notification plusieurs fois.

  • DEVRAIT prendre en charge les notifications enrichies.

  • DEVRAIT présenter certaines notifications de priorité plus élevée sous forme de notifications prioritaires.

  • DEVRAIT avoir une affordance utilisateur pour mettre en attente les notifications.

  • PEUVENT gérer uniquement la visibilité et les délais de notification des applications tierces les utilisateurs d'événements notables afin d'atténuer les problèmes de sécurité tels que la distraction du conducteur.

Android 11 prend en charge les notifications de conversation, qui sont Les notifications qui utilisent MessagingStyle et fournit un ID de raccourci People (Contacts).

Implémentations pour les appareils:

  • [C-SR-4] SONT FORTEMENT RECOMMANDÉS de regrouper et d'afficher conversation notifications avant les notifications de non-conversation, à l'exception notifications de services de premier plan en cours et importance:high les notifications.

Si les implémentations d'appareils sont compatibles avec conversation notifications et l'application fournit les données requises bubbles:

  • [C-SR-5] Il est FORTEMENT RECOMMANDÉ d'afficher cette conversation sous forme de bulle. L’implémentation d’AOSP répond à ces exigences avec l’UI du système par défaut, Paramètres et Lanceur d'applications.

Si les implémentations d'appareils prennent en charge les notifications enrichies, celles-ci:

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

Les notifications prioritaires sont des notifications présentées à l'utilisateur au fur et à mesure de son arrivée, indépendamment de la surface sur laquelle il se trouve. activé. Si les implémentations d'appareils le permettent notifications, ils:

  • [C-3-1] DOIT utiliser la vue de notification prioritaire et les ressources comme décrit dans la section Notification.Builder classe d'API lors de l'affichage de notifications prioritaires.
  • [C-3-2] DOIT afficher les actions fournies dans Notification.Builder.addAction() avec le contenu de la notification sans action supplémentaire de la part de l'utilisateur comme décrit dans le SDK.
Service d'écoute des notifications

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

Implémentations pour les appareils:

  • [C-0-1] DOIT mettre à jour correctement et rapidement les notifications dans leur intégralité. à tous ces services d'écoute installés et activés par l'utilisateur, y compris toutes les métadonnées associées à l'objet Notification.
  • [C-0-2] DOIT respecter les snoozeNotification() appel d'API, puis ignorer la notification et effectuer un rappel après la mise en attente. définie dans l'appel d'API.

Si les implémentations d'appareils ont une affordance utilisateur pour mettre en attente les notifications, elles:

  • [C-1-1] DOIT refléter correctement l'état des notifications mises en attente. via les API standards, NotificationListenerService.getSnoozedNotifications()
  • [C-1-2] DOIT rendre cette affordance utilisateur disponible pour mettre en attente les notifications de chaque application tierce installée, sauf si elles proviennent les services persistants/de premier plan.
Mode Ne pas déranger/Ne pas déranger

Si les implémentations d'appareils sont compatibles avec la fonctionnalité Ne pas déranger (également appelé "mode Priorité"), les fonctionnalités suivantes:

  • [C-1-1] OBLIGATOIRE lorsque l'implémentation de l'appareil a fourni un moyen à l'utilisateur pour autoriser ou refuser l'accès des applications tierces à la configuration de la règle Ne pas déranger. Afficher les Règles Ne pas déranger automatiques créés par les applications parallèlement aux règles définies par l'utilisateur et prédéfinies.
  • [C-1-3] DOIT respecter les suppressedVisualEffects valeurs transmises via NotificationManager.Policy et si une application a défini l'un des SUPPRESSED_EFFECT_SCREEN_OFF ou SUPPRESSED_EFFECT_SCREEN_ON, cela DOIT indiquer à l'utilisateur que les effets visuels sont supprimés dans le menu des paramètres du mode Ne pas déranger.

3.8.4. API Assist

Android inclut les API Assist pour permettre aux applications de choisir la quantité d'informations dans le contexte actuel partagé avec l'Assistant sur l'appareil.

Si les implémentations d'appareils prennent en charge l'action d'assistance, celles-ci:

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

Alertes et toasts

Les applications peuvent utiliser la classe Toast API permettant de présenter à l'utilisateur final de courtes chaînes non modales qui disparaissent après une une courte période, et utilisez le TYPE_APPLICATION_OVERLAY API de type de fenêtre pour afficher des fenêtres d'alerte en superposition sur d'autres applications

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

  • [C-1-1] DOIT fournir une affordance utilisateur pour empêcher une application d'afficher une alerte. Les fenêtres qui utilisent la classe TYPE_APPLICATION_OVERLAY pour en savoir plus. L'implémentation d'AOSP répond à cette exigence grâce à des commandes dans le volet des notifications.

  • [C-1-2] DOIT respecter l'API Toast et afficher des Toasts à partir des applications auprès des utilisateurs finaux dans des domaines très visible.

3.8.6. Thèmes

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

Android inclut les commandes "Holo" et "Material" famille de thèmes comme un ensemble de styles définis aux développeurs d'applications s'ils souhaitent faire correspondre Apparence du thème Holo comme défini par le SDK Android.

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

  • [C-1-1] NE DOIT PAS modifier les attributs du thème Holo exposés applications.
  • [C-1-2] DOIT prendre en charge la famille de thèmes "Material" et NE DOIT PAS modifier les éléments Attributs de thème Material ou leurs éléments exposés aux applications.

  • [C-1-3] DOIT définir la valeur "sans-serif" famille de polices pour Roboto version 2.x pour les langues compatibles avec Roboto, ou fournissent une affordance à l'utilisateur pour modifier la police utilisée pour "sans-serif" famille de polices vers Roboto version 2.x pour les langues prises en charge par Roboto.

  • [C-1-4] DOIT générer des palettes de tons dynamiques dynamiques, comme spécifié dans l'AOSP documentation de Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (voir android.theme.customization.system_palette et android.theme.customization.theme_style).

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

    "Couleur de la source" utilisé pour générer des palettes de tons dynamiques lorsqu'elles sont envoyées avec android.theme.customization.system_palette (comme indiqué dans Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES).

  • [C-1-6] DOIT avoir une valeur de chrominance CAM16 supérieure ou égale à 5.

    • DEVRAIT être dérivé du fond d'écran via com.android.systemui.monet.ColorScheme#getSeedColors, qui fournit plusieurs couleurs sources valides.

    • DEVRAIT utiliser la valeur 0xFF1B6EF3 si aucune des couleurs fournies ne correspond l'exigence relative à la couleur source ci-dessus.

Android inclut également une famille de thèmes "Par défaut de l'appareil" comme ensemble de styles définis. permettant aux développeurs d'applications de s'adapter à l'interface Thème de l'appareil tel que défini par le responsable de la mise en œuvre de l'appareil.

Android accepte un thème de variante avec des barres système translucides, ce qui permet aux développeurs d'applications de remplir la zone située derrière la barre d'état et de navigation avec le contenu de leur application. Pour offrir une expérience cohérente aux développeurs il est important que le style de l'icône de la barre d'état soit conservé différentes implémentations d'appareils.

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

  • [C-2-1] DOIT utiliser le blanc pour les icônes d'état système (intensité du signal, le niveau de la batterie) et les notifications du système, sauf si l'icône est indiquant un état problématique ou si une application demande l'affichage d'une barre d'état lumineuse en utilisant WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS .
  • [C-2-2] Les implémentations d'appareils Android DOIVENT modifier la couleur du système deviennent noirs (pour en savoir plus, consultez la section R.style) lorsqu'une application demande l'affichage d'une barre d'état de voyant.

3.8.7. Fonds d'écran animés

Android définit un type de composant, ainsi que l'API et le cycle de vie correspondants qui permettent pour exposer une ou plusieurs "Fonds d'écran animés" à l'utilisateur final. Les fonds d'écran animés sont des animations, des motifs ou des images similaires avec des capacités de saisie limitées qui s'affichent comme fond d'écran, derrière d'autres applications.

Le matériel est considéré comme capable d'exécuter des fonds d'écran animés de manière fiable s'il peut s'exécuter Tous les fonds d'écran animés, sans limitation de fonctionnalité, dans un cadre raisonnable sans aucun effet négatif sur les autres applications. Si les limites du champ qui provoque le plantage, le dysfonctionnement ou l'utilisation des fonds d'écran et/ou applications une autonomie excessive du processeur ou de la batterie, ou qui fonctionne à une fréquence d'images trop faible, le le matériel est considéré comme incapable d'exécuter un fond d'écran animé. Par exemple, certaines Les fonds d'écran animés peuvent utiliser un contexte OpenGL 2.0 ou 3.x pour afficher leur contenu. Le fond d'écran animé ne s'exécutera pas de manière fiable sur un matériel non compatible Contextes OpenGL, car l'utilisation du fond d'écran animé d'un contexte OpenGL peut entrer en conflit avec d'autres applications qui utilisent également un contexte OpenGL.

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

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

  • [C-1-1] DOIT signaler l'indicateur de fonctionnalité de plate-forme android.software.live_wallpaper.

3.8.8. Changement d'activité

Le code source Android en amont inclut écran d'aperçu, une interface utilisateur au niveau du système permettant de changer de tâche et d'afficher les données récemment consultées les activités et les tâches à l'aide d'une vignette du graphique au moment où l'utilisateur a quitté l'application pour la dernière fois.

Implémentations sur les appareils y compris la touche de navigation de la fonction "Recents", comme détaillé dans section 7.2.3 PEUT modifier l'interface.

Si les implémentations d'appareils, y compris la touche de navigation de la fonction "Recents", comme détaillé dans la section section 7.2.3 modifient l'interface, ils:

  • [C-1-1] DOIT prendre en charge au moins sept activités affichées.
  • DEVRAIT afficher au moins le titre de quatre activités à la fois.

  • DEVRAIT afficher la couleur de mise en surbrillance, l'icône et le titre de l'écran dans les éléments récents.
  • DEVRAIT afficher une affordance de fermeture ("x"), mais PEUT la retarder jusqu'à ce que l'utilisateur interagit avec les écrans.
  • DEVRAIT implémenter un raccourci pour revenir facilement à l'activité précédente.
  • DEVRAIT déclencher l'action d'activation rapide entre les deux derniers applications, lorsque l'utilisateur appuie deux fois sur la touche de fonction "Récents".
  • DEVRAIT déclencher le mode multifenêtre de l'écran partagé, s'il est compatible, lorsque un appui prolongé sur la touche des fonctions récentes.
  • PEUT afficher les récents affiliés en tant que groupe qui bougent ensemble.
  • [C-SR-1] EST FORTEMENT RECOMMANDÉ d'utiliser l'utilisateur Android en amont (ou une interface similaire basée sur des vignettes) pour l'écran "Overview" (Aperçu).

3.8.9. Gestion des entrées

Android prend en charge Gestion des entrées et la compatibilité avec les éditeurs de mode de saisie tiers.

Si les implémentations d'appareils permettent aux utilisateurs d'utiliser des modes de saisie tiers appareil, ils:

  • [C-1-1] DOIT déclarer la fonctionnalité de plate-forme android.software.input_methods et sont compatibles avec les API IME, comme défini dans la documentation du SDK Android.

3.8.10. Commandes multimédias pour l'écran de verrouillage

L'API Remote Control Client a été abandonnée dans la version 5.0 d'Android au profit de Modèle de notification multimédia qui permet aux applications multimédias de s'intégrer aux commandes de lecture affiché sur l'écran de verrouillage.

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

Consultez la section 3.2.3.5 pour les paramètres. pour encombrer les économiseurs d'écran.

3.8.12. Position

Si les configurations de l'appareil incluent un capteur matériel (par exemple, un GPS) compatible avec de fournir les coordonnées de l'emplacement,

3.8.13. Unicode et police

Android prend en charge les caractères emoji définis dans Unicode 10.0 :

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

  • [C-1-1] DOIT pouvoir afficher ces caractères emoji avec un glyphe de couleur.
  • [C-1-2] DOIT inclure les éléments suivants:
    • Police Roboto 2 avec différentes épaisseurs : sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light pour les langues disponibles sur l'appareil.
    • Compatibilité totale avec Unicode 7.0 des caractères latins, grecs et cyrilliques, y compris les Plages A, B, C et D du latin étendu, et tous les glyphes dans la devise d'Unicode 7.0.
  • [C-1-3] NE DOIT PAS supprimer ni modifier le fichier NotoColorEmoji.tff dans l'image système. Il est possible d'ajouter une police d'emoji pour remplacer les emoji dans NotoColorEmoji.tff).
  • DEVRAIT prendre en charge la carnation et les différents emoji familiaux, comme indiqué dans les Rapport technique Unicode n° 51

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

  • DEVRAIT fournir un mode de saisie à l'utilisateur pour ces caractères emoji.

Android est compatible avec l'affichage des polices birmane. Le Myanmar compte plusieurs des polices non conformes à Unicode, communément appelées "Zawgyi", pour le rendu du Myanmar. langues.

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

  • [C-2-1] DOIT afficher le texte avec une police compatible Unicode par défaut. une police non compatible avec Unicode NE DOIT PAS être définie comme police par défaut, sauf si l'utilisateur la sélectionne dans l'outil de sélection de langue.
  • [C-2-2] DOIT prendre en charge une police Unicode et une police non compatible avec Unicode non compatible avec Unicode est pris en charge par l'appareil. Non Unicode conforme à la norme SSL NE DOIT PAS supprimer ni remplacer la police Unicode.
  • [C-2-3] DOIT afficher le texte avec une police non conforme à Unicode UNIQUEMENT SI un code de langue avec Qaag du code de script est spécifiée (par exemple, my-Qaag). Aucun autre code de langue ou de région ISO (que ce soit attribuée, non attribuée ou réservée) peuvent être utilisées pour faire référence à des compatible avec le Myanmar. Les développeurs d'applications et les auteurs de pages Web peuvent spécifier "my-Qaag" comme code de langue, comme pour toute dans une autre langue.

3.8.14. Multifenêtre

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

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

Si les implémentations d'appareils sont compatibles avec le mode multifenêtre et si l'écran partagé ils:

  • [C-2-2] DOIT recadrer l'activité ancrée d'un écran partagé multifenêtre, mais DEVRAIT afficher un contenu de celui-ci si le lanceur d'applications est la fenêtre sélectionnée.
  • [C-2-3] DOIT respecter la AndroidManifestLayout_minWidth déclarée et AndroidManifestLayout_minHeight de l'application de lancement tierce et ne les remplacent pas. au cours de l'affichage du contenu de l'activité ancrée.

Si les implémentations d'appareils sont compatibles avec le mode multifenêtre et le mode Picture-in-picture mode multifenêtre, elles:

  • [C-3-1] DOIT lancer les activités en mode multifenêtre Picture-in-picture Lorsque l'application est: * Ciblage du niveau d'API 26 ou supérieur et déclare android:supportsPictureInPicture * Cibler le niveau d'API 25 ou inférieur et déclarer les deux android:resizeableActivity et android:supportsPictureInPicture.
  • [C-3-2] DOIT exposer les actions dans leur SystemUI spécifié par l'activité PIP en cours via la setActions() API.
  • [C-3-3] DOIT accepter les formats supérieurs ou égaux à 1:2.39 et inférieures ou égales à 2.39:1, comme spécifié par l'activité PIP via le setAspectRatio() API.
  • [C-3-4] DOIT utiliser KeyEvent.KEYCODE_WINDOW pour contrôler la fenêtre PIP, si le mode PIP n'est pas implémenté, la clé DOIT être disponibles pour l'activité de premier plan.
  • [C-3-5] DOIT fournir une affordance utilisateur pour empêcher une application de s'afficher dans Mode PIP l'implémentation AOSP répond à cette exigence en ayant dans le volet des notifications.

  • [C-3-6] DOIT allouer la largeur et la hauteur minimales suivantes pour la fenêtre PIP période pendant laquelle une application ne déclare aucune valeur pour AndroidManifestLayout_minWidth et AndroidManifestLayout_minHeight:

    • Appareils dont le paramètre Configuration.uiMode est défini sur une valeur autre que UI_MODE_TYPE_TELEVISION DOIT allouer une largeur et une hauteur minimales de 108 dp.
    • Appareils dont le paramètre Configuration.uiMode est défini sur UI_MODE_TYPE_TELEVISION DOIT allouer une largeur minimale de 240 dp et une hauteur minimale de 135 dp.

3.8.15. Découpe de l'écran

Android prend en charge une découpe d'écran comme décrit dans le document du SDK. L'API DisplayCutout définit Une zone située sur le bord de l'écran qui n'est peut-être pas fonctionnelle pour une application en raison d'une encoche ou d'un écran incurvé sur les bords.

Si les implémentations d'appareils incluent une ou plusieurs encoches, celles-ci:

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

3.8.16. Commandes de contrôle des appareils

Android inclut ControlsProviderService et Control API permettant à des applications tierces de publier des commandes de contrôle des appareils l'état et l'action des utilisateurs.

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

3.8.17. Presse-papiers

Implémentations pour les appareils:

  • [C-0-1] NE DOIT PAS envoyer de données du presse-papiers à un composant, une activité, un service sur n'importe quelle connexion réseau, sans action explicite de l'utilisateur (par exemple, appuyer sur un sur le bouton en superposition), sauf pour les services mentionnés dans 9.8.6 Capture de contenu et recherche d'applications.

Si les intégrations sur l'appareil génèrent un aperçu visible par l'utilisateur lorsque le contenu est copié dans le presse-papiers pour tout élément ClipData où ClipData.getDescription().getExtras() contient android.content.extra.IS_SENSITIVE, ils:

  • [C-1-1] DOIT masquer l'aperçu visible par l'utilisateur

L'implémentation de référence AOSP répond aux exigences du presse-papiers.

3.9. Gestion de l'appareil

Android inclut des fonctionnalités qui permettent aux applications fonctions d'administration des appareils au niveau du système, telles que l'application forcée de mots de passe ou en effaçant les données à distance, API Android Device Administration :

Si les implémentations d'appareils implémentent toutes les fonctionnalités d'administration des appareils définies dans la documentation du SDK Android, elles:

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

3.9.1 Préparation des appareils

3.9.1.1 Configuration du propriétaire de l'appareil

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

  • [C-1-1] DOIT prendre en charge l'enregistrement d'un client Device Policy (DPC) en tant que Application Propriétaire de l'appareil comme décrit ci-dessous:
    • Lorsque l'implémentation de l'appareil ni les utilisateurs, ni des données utilisateur configurées, il:
      • [C-1-5] DOIT enregistrer l'application DPC en tant qu'application du propriétaire de l'appareil ou permettre à l'application DPC de choisir de devenir propriétaire de l'appareil ou du profil, si l'appareil déclare la compatibilité avec la technologie NFC (communication en champ proche) via le flag de fonctionnalité android.hardware.nfc et reçoit un message NFC. contenant un enregistrement de type MIME MIME_TYPE_PROVISIONING_NFC
      • [C-1-8] DOIT envoyer ACTION_GET_PROVISIONING_MODE suivant le déclenchement du provisionnement du propriétaire de l'appareil, afin que L'application DPC peut choisir de devenir propriétaire de l'appareil ou profil Propriétaire, en fonction des valeurs de android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES, à moins qu'il ne puisse être déterminé à partir dans le contexte qu'il n'y a qu'une seule option valide.
      • [C-1-9] DOIT envoyer ACTION_ADMIN_POLICY_COMPLIANCE intent vers l'application Propriétaire de l'appareil si un propriétaire de l'appareil est établi quelle que soit la méthode de provisionnement utilisée. La l'utilisateur ne doit pas pouvoir continuer dans l'assistant de configuration tant que L'application Device Owner se termine.
    • Lorsque l'implémentation de l'appareil ou les données utilisateur:
      • [C-1-7] NE DOIT PAS enregistrer d'application DPC en tant qu'application du propriétaire de l'appareil plus tard.

  • [C-1-2] DOIT inclure un avis de divulgation approprié (comme indiqué dans l'AOSP) et obtenir le consentement explicite de l'utilisateur final avant qu'elle ne commence défini comme propriétaire de l'appareil, sauf si celui-ci est configuré de façon programmatique. pour le mode démo en magasin avant l'interaction de l'utilisateur final à l'écran. Si les implémentations de l'appareil déclarent android.software.device_admin, mais aussi incluent un modèle de gestion des appareils et fournit un mécanisme pour promouvoir une application configurée dans sa solution en tant que "Device Owner équivalent" au profil standard "Propriétaire de l'appareil" conformément à la norme Android Gestionnaire de règles d'appareil API, ils:

  • [C-2-1] DOIT mettre en place une procédure permettant de vérifier que l'application concernée l'objet de la promotion relève d'une gestion légitime des appareils d'entreprise et a été configurée dans la solution propriétaire disposer des droits équivalents en tant que "Propriétaire de l'appareil".

  • [C-2-2] DOIT afficher la même mention de consentement du propriétaire de l'appareil AOSP que flux lancé par android.app.action.PROVISION_MANAGED_DEVICE avant d'enregistrer l'application DPC en tant que "Device Owner" (Propriétaire de l'appareil).

  • [C-2-3] NE DOIT PAS coder en dur le consentement l'utilisation d'applications appartenant à d'autres propriétaires de l'appareil.

3.9.1.2 Provisionnement des profils gérés

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

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

  • [C-1-2] Le processus de provisionnement du profil géré (flux lancé par le DPC à l'aide de android.app.action.PROVISION_MANAGED_PROFILE) ou par la plate-forme), l'écran de consentement et l'expérience utilisateur DOIVENT correspondre l'implémentation d'AOSP.

  • [C-1-3] DOIT indiquer les affordances utilisateur suivantes dans les paramètres pour indiquer à l'utilisateur quand une fonction système particulière a été désactivée en l'outil de contrôle des règles relatives aux appareils (DPC):

    • Une icône cohérente ou toute autre affordance de l'utilisateur (par exemple, l'élément en amont l'icône d'information AOSP) pour indiquer quand un paramètre spécifique est limité par un administrateur de périphériques.
    • Brève explication fournie par l'administrateur de l'appareil via le setShortSupportMessage
    • Icône de l'application DPC.

  • [C-1-4] DOIT lancer le gestionnaire pour ACTION_PROVISIONING_SUCCÈS dans le profil professionnel si un propriétaire de profil est établi le provisionnement est lancé par android.app.action.PROVISION_MANAGED_PROFILE. intent et que le DPC a implémenté le gestionnaire.

  • [C-1-5] DOIT envoyer ACTION_PROFILE_PROVISIONING_COMPLETE diffuser au DPC du profil professionnel lorsque le provisionnement est initié par android.app.action.PROVISION_MANAGED_PROFILE l'intention.

  • [C-1-6] DOIT envoyer ACTION_GET_PROVISIONING_MODE après le déclenchement du provisionnement du propriétaire du profil, afin que l'application DPC peuvent choisir de devenir Propriétaire de l'appareil ou Propriétaire de profil, sauf si le provisionnement est déclenché par l'intent android.app.action.PROVISION_MANAGED_PROFILE.

  • [C-1-7] DOIT envoyer la déclaration ACTION_ADMIN_POLICY_COMPLIANCE vers le profil professionnel lorsqu'un propriétaire de profil est défini quelle que soit la méthode utilisée, sauf lorsque le provisionnement est déclenché par l'intent android.app.action.PROVISION_MANAGED_PROFILE. L'utilisateur ne doit pas pouvoir continuer dans l'assistant de configuration tant que le profil L'application du propriétaire est terminée.

  • [C-1-8] DOIT envoyer ACTION_MANAGED_PROFILE_PROVISIONED diffuser au DPC du profil personnel lorsqu'un propriétaire de profil est établi, quelle que soit la méthode de provisionnement utilisée.

3.9.2 Prise en charge des profils gérés

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

  • [C-1-1] DOIT prendre en charge les profils gérés via le android.app.admin.DevicePolicyManager API.
  • [C-1-2] DOIT autoriser la création d'un seul profil géré.
  • [C-1-3] DOIT utiliser un badge d'icône (semblable au badge de travail en amont AOSP) pour représentent les applications et widgets gérés, ainsi que d'autres éléments d'interface utilisateur dotés d'un badge. comme "Récents" et Notifications.
  • [C-1-4] DOIT afficher une icône de notification (similaire aux tâches AOSP en amont) ) pour indiquer quand l'utilisateur se trouve dans une application de profil géré.
  • [C-1-5] DOIT afficher un toast indiquant que l'utilisateur se trouve dans le profil si et quand l'appareil se réactive (ACTION_USER_PRESENT) et que l'application de premier plan se trouve dans le profil géré.
  • [C-1-6] Lorsqu'un profil géré existe, DOIT afficher une affordance visuelle dans le Intent "Sélecteur" pour permettre à l'utilisateur de transférer l'intent à partir du à l'utilisateur principal, et inversement, si la règle Manette de jeu.
  • [C-1-7] Lorsqu'un profil géré existe, DOIT exposer l'utilisateur suivant affordances pour l'utilisateur principal et le profil géré:
    • Données distinctes pour l'utilisation de la batterie, de l'emplacement, des données mobiles et de l'espace de stockage pour l'utilisateur principal et le profil géré.
    • Gestion indépendante des applications VPN installées utilisateur ou un profil géré.
    • Gestion indépendante des applications installées chez l'utilisateur principal ou un profil géré.
    • Gestion indépendante des comptes au sein de l'utilisateur principal ou gérés profil.
  • [C-1-8] DOIT s'assurer que le clavier, les contacts et la messagerie sont préinstallés peuvent rechercher des informations sur l'appelant dans le profil (s'il en existe) en plus de ceux du profil principal, si les L'outil de contrôle des règles relatives aux appareils le permet.
  • [C-1-9] DOIT s'assurer qu'il répond à toutes les exigences de sécurité applicable à un appareil sur lequel plusieurs utilisateurs sont activés (voir section 9.5), même si le profil géré n'est pas comptabilisé comme un autre utilisateur en plus de l'utilisateur principal.

Commencer les nouvelles exigences

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

Mettre fin aux nouvelles exigences

Si les implémentations d'appareils déclarent android.software.managed_users et android.software.secure_lock_screen, ils:

  • [C-2-1] DOIT prendre en charge la possibilité de spécifier une réunion distincte sur l'écran de verrouillage les exigences suivantes pour accorder l'accès aux applications exécutées dans un environnement profil uniquement.
    • Les implémentations d'appareils DOIVENT respecter les DevicePolicyManager.ACTION_SET_NEW_PASSWORD et afficher une interface pour configurer un écran de verrouillage distinct à l'aide d'identifiants associés au profil géré.
    • Les identifiants d'écran de verrouillage du profil géré DOIVENT utiliser les mêmes le stockage et la gestion des identifiants en tant que profil parent, comme indiqué sur le Site du projet Android Open Source
    • Les règles de mot de passe de l'outil DPC DOIT s'appliquer uniquement aux identifiants d'écran de verrouillage du profil géré, sauf appelé sur l'instance DevicePolicyManager renvoyée par getParentProfileInstance.
  • Affichage des contacts du profil géré dans le journal d'appels préinstallé, l'interface utilisateur de l'appel en cours, les appels en cours et les appels manqués des notifications, des contacts et des applications de chat, ils DOIVENT disposer de la mention même badge utilisé pour indiquer les applications de profils gérés.

3.9.3 Assistance aux utilisateurs gérés

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

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

Si les implémentations d'appareils déclarent android.software.device_admin et fournissent une affordance d'utilisateur sur l'appareil pour ajouter des utilisateurs secondaires, ils:

  • [C-SR-1] Sont FORTEMENT RECOMMANDÉS affichent le même consentement "Propriétaire de l'appareil AOSP" qui ont été divulguées lors du processus initié par android.app.action.PROVISION_MANAGED_DEVICE avant d'autoriser l'ajout de comptes dans le nouvel utilisateur secondaire, afin que les utilisateurs comprennent que l'appareil est géré.

3.9.4 Exigences relatives aux rôles de gestion des règles relatives aux appareils

Si l'implémentation des appareils indique android.software.device_admin ou android.software.managed_users:

  • [C-1-1] DOIT prendre en charge le rôle de gestion des règles relatives aux appareils tel que défini dans section 9.1. Application détenant le rôle de gestion des règles relatives aux appareils PEUT être défini en définissant config_devicePolicyManagement sur le nom du package. Le nom du package DOIT être suivi de : et du certificat de signature, sauf si l'application est préchargée.

Si aucun nom de package n'est défini pour config_devicePolicyManagement comme décrites ci-dessus:

Si un nom de package est défini pour config_devicePolicyManagement, comme décrit ici ci-dessus:

  • [C-3-1] L'application DOIT être installée sur toutes les plates-formes profils pour un utilisateur.
  • [C-3-2] Les implémentations d'appareils PEUVENT définir une application qui met à jour le titulaire du rôle de gestion des règles relatives aux appareils avant le provisionnement en définissant config_devicePolicyManagementUpdater

Si un nom de package est défini pour config_devicePolicyManagementUpdater comme décrites ci-dessus:

  • [C-4-1] L'application DOIT être préinstallée sur l'appareil.
  • [C-4-2] L'application DOIT implémenter un filtre d'intent qui résout android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER

Commencer les nouvelles exigences

3.9.5 Système de résolution des règles relatives aux appareils

Si l'implémentation des appareils indique android.software.device_admin ou android.software.managed_users:

Mettre fin aux nouvelles exigences

3.10. Accessibilité

Android fournit une couche d'accessibilité qui aide les utilisateurs handicapés à naviguer sur leurs appareils plus facilement. De plus, Android fournit des API de plate-forme qui permettent aux implémentations de services d'accessibilité de recevoir des rappels pour les utilisateurs et les événements système, et génèrent d'autres mécanismes de rétroaction, tels que la synthèse vocale, le retour haptique et la navigation avec trackball/pavé directionnel.

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

  • [C-1-1] DOIT fournir une implémentation de la fonctionnalité d'accessibilité Android tel que décrit dans le API d'accessibilité Documentation du SDK.
  • [C-1-2] DOIT générer des événements d'accessibilité et fournir les AccessibilityEvent à tous les enregistrements AccessibilityService comme indiqué dans le SDK.
  • [C-1-4] DOIT fournir une affordance à l'utilisateur pour contrôler l'accessibilité services qui déclarent le AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BOUTON pour en savoir plus. Notez que pour les implémentations d'appareil dotées d'une barre de navigation système, elles DEVRAIT permettre à l'utilisateur d'avoir la possibilité d'utiliser un bouton dans le barre de navigation pour contrôler ces services.

Si les implémentations d'appareils incluent des services d'accessibilité préinstallés:

  • [C-2-1] DOIT implémenter ces services d'accessibilité préinstallés Détection du démarrage direct lorsque le stockage des données est chiffré à l'aide du chiffrement basé sur les fichiers.
  • DEVRAIT fournir un mécanisme dans le flux de configuration prêt à l'emploi permettant aux utilisateurs d'activer services d'accessibilité pertinents, ainsi que des options pour ajuster la taille de la police, la taille d'affichage et les gestes d'agrandissement.

3.11. Synthèse vocale

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

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

Si les implémentations d'appareils sont compatibles avec l'installation de moteurs de synthèse vocale tiers, ceux-ci:

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

3.12. Framework d'entrée TV

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

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

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

3.13. Réglages rapides

Android fournit un composant d'interface utilisateur "Réglages rapides" qui permet d'accéder rapidement des actions fréquemment utilisées ou nécessaires en urgence.

Si les implémentations d'appareils incluent un composant d'interface utilisateur "Réglages rapides" et prennent en charge des applications tierces Réglages rapides:

  • [C-1-1] DOIT permettre à l'utilisateur d'ajouter ou de supprimer les vignettes fournies via le quicksettings les API d'une application tierce.
  • [C-1-2] NE DOIT PAS ajouter automatiquement une carte depuis une application tierce directement accédez aux Réglages rapides.
  • [C-1-3] DOIT afficher toutes les vignettes ajoutées par l'utilisateur depuis des applications tierces en plus des blocs de configuration rapide fournis par le système.

3.14. Interface utilisateur multimédia

Si les implémentations d'appareils comprennent des applications non à commande vocale (les Applications) qui interagissent avec des applications tierces via MediaBrowser ou MediaSession, les applications:

  • [C-1-2] DOIT afficher clairement les icônes obtenues via getIconBitmap() ou getIconUri(), ainsi que les titres obtenu via getTitle(), comme décrit dans MediaDescription. Peut raccourcir les titres afin de respecter les réglementations de sécurité (par exemple, les distractions au volant).

  • [C-1-3] DOIT afficher l'icône de l'application tierce lors de l'affichage de contenu fourni par cette application tierce.

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

  • [C-1-5] DOIT prendre en compte le fait d'appuyer deux fois sur KEYCODE_HEADSETHOOK ou KEYCODE_MEDIA_PLAY_PAUSE en tant que KEYCODE_MEDIA_NEXT pour MediaSession.Callback#onMediaButtonEvent.

3.15. Applis instantanées

Si les implémentations d'appareils sont compatibles avec les applis instantanées, celles-ci DOIVENT respecter les conditions suivantes configuration requise:

  • [C-1-1] Les applis instantanées DOIVENT disposer uniquement des autorisations dont le rôle android:protectionLevel définie sur "instant".
  • [C-1-2] Les applis instantanées NE DOIVENT PAS interagir avec les applications installées via des intents implicites sauf si l'une des conditions suivantes est remplie:
    • Le filtre de format d'intent du composant est exposé et comporte CATEGORY_BROWSABLE
    • L'action est l'une des suivantes : ACTION_SEND, ACTION_SENDTO ou ACTION_SEND_MULTIPLE.
    • La cible est explicitement exposée avec android:visibleToInstantApps.
  • [C-1-3] Les applis instantanées NE DOIVENT PAS interagir explicitement avec les applications installées, sauf si est exposé via android:visibleToInstantApps.
  • [C-1-4] Les applis installées NE DOIVENT PAS voir d'informations sur les applis instantanées sur le à moins que l'appli instantanée se connecte application installée.

  • Les implémentations d'appareils DOIVENT fournir les affordances utilisateur suivantes pour interagir avec les applis instantanées. L'AOSP répond aux exigences des par défaut de l'UI du système, des paramètres et du lanceur d'applications. Implémentations pour les appareils:

    • [C-1-5] DOIT fournir une affordance utilisateur pour afficher et supprimer les applis instantanées mis en cache localement pour chaque package d'application individuel.
    • [C-1-6] DOIT fournir une notification persistante à l'utilisateur réduit lorsqu'une appli instantanée est exécutée au premier plan. Cet utilisateur DOIT inclure la notification indiquant que les applis instantanées ne nécessitent pas d'installation et fournissent une affordance de l'utilisateur qui le dirige vers l'application dans les paramètres. Pour les applis instantanées lancées via des intents Web, comme défini à l'aide d'un intent avec l'action définie sur Intent.ACTION_VIEW et avec un schéma "http" ou "https", une affordance pour l'utilisateur DEVRAIT permettre à l'utilisateur de ne pas lancer l'appli instantanée et lancer le lien associé au navigateur Web configuré, si un navigateur est disponible sur l'appareil.
    • [C-1-7] DOIT autoriser l'accès aux applis instantanées en cours d'exécution depuis l'application si la fonction Récents est disponible sur l'appareil.

  • [C-1-8] DOIT précharger un ou plusieurs composants d'applications ou de services Avec un gestionnaire d'intents pour les intents répertoriés dans le SDK, cliquez ici. et rendre les intents visibles pour les applis instantanées.

3.16. Association d'un appareil associé

Android prend en charge l'association d'appareils associés pour une gestion plus efficace association à des appareils associés et fournit le CompanionDeviceManager API permettant aux applis d'accéder à cette fonctionnalité.

Si les implémentations d'appareils sont compatibles avec la fonctionnalité d'association d'appareils associés:

  • [C-1-1] DOIT déclarer le flag de fonctionnalité FEATURE_COMPANION_DEVICE_SETUP pour en savoir plus.
  • [C-1-2] DOIT s'assurer que les API du android.companion package soit entièrement implémenté.
  • [C-1-3] DOIT fournir des affordances à l'utilisateur pour sélectionner/confirmer une annonce associée est présent et opérationnel.

3.17. Applications lourdes

Si les implémentations d'appareils déclarent la fonctionnalité FEATURE_CANT_SAVE_STATE, ils:

  • [C-1-1] DOIT disposer d'une seule application installée spécifiant cantSaveState exécutées dans le système à un moment donné. Si l'utilisateur quitte une application sans la quitter explicitement (par exemple, en appuyant sur tout en laissant une activité active dans le système, au lieu d'appuyer sur et qu'il ne reste aucune activité active dans le système), les implémentations d'appareils DOIVENT donner la priorité à cette application dans la RAM, comme c'est le cas pour les autres éléments qui doivent rester en cours d'exécution, tels que les services de premier plan. Lorsqu'une application de ce type est exécutée en arrière-plan, le système peut quand même mettre l'appareil sous tension des fonctionnalités de gestion, comme la limitation de l'accès au CPU et au réseau.
  • [C-1-2] DOIT fournir une affordance d'UI pour choisir l'application qui ne participer au mécanisme normal d'enregistrement/restauration de l'état une fois que l'utilisateur lance une deuxième application déclarée avec cantSaveState. .
  • [C-1-3] NE DOIT PAS appliquer d'autres modifications du règlement aux applications qui spécifient cantSaveState, comme la modification des performances du processeur ou la modification de la hiérarchisation de la planification.

Si les implémentations d'appareils ne déclarent pas la fonctionnalité FEATURE_CANT_SAVE_STATE, ils:

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

3.18. Contacts

Android inclut Contacts Provider API permettant aux applications de gérer les coordonnées stockées sur l'appareil. Les données des contacts saisies directement sur l'appareil sont généralement synchronisées avec un service Web, mais les données PEUVENT également résider uniquement localement sur l’appareil. Les contacts qui sont uniquement stockés sur l'appareil sont appelés contacts locaux de vos contacts.

RawContacts sont "associés à" ; ou "stocké dans" une Compte lorsque ACCOUNT_NAME, et ACCOUNT_TYPE, les colonnes des contacts bruts correspondent aux Nom.du.compte et Type.compte du compte.

Default local account (Compte local par défaut) : compte pour les contacts bruts qui ne sont stockés que sur l'appareil et qui ne sont associées à aucun Compte dans AccountManager, qui sont créées avec des valeurs null ACCOUNT_NAME, et ACCOUNT_TYPE, colonnes.

Compte local personnalisé: compte pour les contacts bruts qui ne sont stockés que sur le appareil et non associées à un compte dans le gestionnaire de comptes, qui sont créé avec au moins une valeur non nulle pour le paramètre ACCOUNT_NAME, et ACCOUNT_TYPE, colonnes.

Implémentations pour les appareils:

  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ de ne pas créer de comptes locaux personnalisés.

Si les implémentations d'appareils utilisent un compte local personnalisé:

  • [C-1-1] Le ACCOUNT_NAME, du compte local personnalisé DOIT être renvoyé avant le ContactsContract.RawContacts.getLocalAccountName
  • [C-1-2] Le ACCOUNT_TYPE, du compte local personnalisé DOIT être renvoyé avant le ContactsContract.RawContacts.getLocalAccountType
  • [C-1-3] Contacts bruts insérés par des applications tierces avec le compte local par défaut (c'est-à-dire en définissant des valeurs nulles pour ACCOUNT_NAME et ACCOUNT_TYPE) DOIVENT être insérés dans la requête locale personnalisée compte.
  • [C-1-4] Les contacts bruts insérés dans le compte local personnalisé NE DOIVENT pas être supprimés lors de l'ajout ou de la suppression de comptes.
  • [C-1-5] Supprimer les opérations effectuées sur le compte local personnalisé DOIT entraîner la suppression immédiate et définitive des contacts bruts (comme si CALLER_IS_SYNCADAPTER a été défini sur "true"), même si le paramètre CALLER\_IS\_SYNCADAPTER a été défini. sur "false" ou non spécifié.

4. Compatibilité avec les packages d'applications

Implémentations pour les appareils:

  • [C-0-1] DOIT être capable d'installer et d'exécuter le fichier ".apk" d'Android. les fichiers en tant que généré par l'API "aapt" est inclus dans SDK Android officiel.

    • Comme l'exigence ci-dessus peut s'avérer difficile, les implémentations d'appareils sont RECOMMANDÉ d'utiliser la gestion des packages de l'implémentation de référence AOSP du système d'exploitation.

  • [C-0-2] DOIT prendre en charge la validation de ".apk" à l'aide de la commande APK Signature Scheme v3.1, APK Signature Scheme v3 APK Signature Scheme v2 et la signature JAR.

  • [C-0-3] NE DOIT PAS étendre la .apk Fichier manifeste Android, bytecode Dalvik ; ou les formats de bytecode RenderScript d'une manière qui empêche ces fichiers installée et fonctionnant correctement sur d'autres appareils compatibles.

  • [C-0-4] NE DOIT PAS autoriser d'applications autres que la version actuelle "programme d'installation de l'enregistrement" pour que le package désinstalle l'application sans notification de l'utilisateur, comme indiqué dans le SDK pour DELETE_PACKAGE l'autorisation. Les seules exceptions sont la gestion par l'application de l'outil de vérification des packages système PACKAGE_NEEDS_VERIFICATION et le gestionnaire d'espace de stockage ACTION_MANAGE_STORAGE l'intention.

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

  • [C-0-6] NE DOIT PAS installer de packages d'applis inconnus sources, sauf si l'application qui demande l'installation remplit toutes les conditions suivantes:

    • Il DOIT déclarer la REQUEST_INSTALL_PACKAGES autorisation ou définir android:targetSdkVersion sur 24 ou moins.
    • L'utilisateur DOIT avoir été autorisé à installer des applications sources inconnues.

  • DEVRAIT fournir une affordance à un utilisateur pour accorder/révoquer l'autorisation de d'installer par application des applications provenant de sources inconnues, mais PEUVENT choisir de les implémenter comme no-op et renvoie RESULT_CANCELED pour startActivityForResult(), si l'implémentation de l'appareil ne veut pas permettre aux utilisateurs d'avoir ce choix. Cependant, même dans de tels cas, elles DOIVENT indiquer à l'utilisateur pourquoi il n'y a pas ce choix présenté.

  • [C-0-7] DOIT afficher une boîte de dialogue d'avertissement contenant la chaîne fournie via l'API système PackageManager.setHarmfulAppWarning à l'utilisateur avant de lancer une activité dans une application par la même API système PackageManager.setHarmfulAppWarning que potentiellement dangereux.

  • DEVRAIT permettre à l'utilisateur de choisir de désinstaller ou de lancer application dans la boîte de dialogue d'avertissement.

  • [C-0-8] DOIT mettre en œuvre la prise en charge du système de fichiers incrémentiel, tel que documenté cliquez ici.

  • [C-0-9] DOIT prendre en charge la vérification des fichiers .apk à l'aide de APK Signature Scheme v4 et APK Signature Scheme v4.1.

5. Compatibilité multimédia

Implémentations pour les appareils:

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

Implémentations pour les appareils:

  • DEVRAIT avoir une latence minimale du codec. En d'autres termes,
    • NE DEVRAIT PAS consommer ni stocker des tampons d'entrée, et renvoyer uniquement des tampons d'entrée une fois le traitement effectué.
    • NE DEVRAIT PAS conserver sur les tampons décodés plus longtemps que spécifié par le standard (SPS, par exemple).
    • NE DOIT PAS conserver sur les tampons encodés plus longtemps que requis par le GOP structure.

Tous les codecs répertoriés dans la section ci-dessous sont fournis en tant que logiciels dans l'implémentation Android préférée d'Android Open Projet source.

Notez que ni Google ni l'Open Handset Alliance ne que ces codecs sont dépourvus de brevets tiers. Ces si l'on a l'intention d'utiliser ce code source dans des produits matériels ou logiciels, que les implémentations de ce code, y compris dans les logiciels Open Source ou shareware, peut exiger des licences de brevet des détenteurs de brevets concernés.

5.1. Codecs multimédias

5.1.1. Encodage audio

Pour plus d'informations, consultez la section 5.1.3. Détails des codecs audio.

Si les implémentations d'appareils déclarent android.hardware.microphone, ils DOIVENT prendre en charge l'encodage des formats audio suivants et les rendre disponibles à des applications tierces:

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

Tous les encodeurs audio DOIVENT prendre en charge:

5.1.2. Décodage audio

Pour plus d'informations, consultez la section 5.1.3. Détails des codecs audio.

Si les implémentations d'appareils déclarent la prise en charge du android.hardware.audio.output, ils doivent être compatibles avec le décodage formats audio suivants:

  • [C-1-1] Profil MPEG-4 AAC (AAC LC)
  • [C-1-2] Profil MPEG-4 HE AAC (AAC+)
  • [C-1-3] Profil MPEG-4 HE AACv2 (AAC+ amélioré)
  • [C-1-4] AAC ELD (AAC à faible décalage amélioré)
  • [C-1-11] Profil xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile), qui comprend : le profil de référence de l'USAC et la plage dynamique ISO/IEC 23003-4 profil de contrôle)
  • [C-1-5] FLAC
  • [C-1-6] MP3
  • [C-1-7] MIDI
  • [C-1-8] Vorbis
  • [C-1-9] PCM/WAVE avec audio haute résolution jusqu'à 24 bits, un taux d'échantillonnage de 192 kHz et 8 canaux. Notez que cette exigence ne s'applique qu'au décodage, et qu'un appareil est autorisé à sous-échantillonner et à réduire le mixage pendant la phase de lecture.
  • [C-1-10] Opus

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

  • [C-2-1] Le décodage DOIT être effectué sans rétrogradation (par exemple, flux doit être décodé sur cinq canaux PCM, un flux 5.1 AAC doit être décodé à six canaux PCM).
  • [C-2-2] Les métadonnées de la plage dynamique DOIVENT être telles que définies dans "Contrôle de la plage dynamique (RDC) de la norme ISO/IEC 14496-3, et les clés android.media.MediaFormat DRC pour configurer les comportements liés à la plage dynamique du décodeur audio. La Les clés AAC DRC ont été introduites dans l'API 21 et sont: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL et KEY_AAC_ENCODED_TARGET_LEVEL
  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ que les exigences C-2-1 et C-2-2 ci-dessus soient satisfait par tous les décodeurs audio AAC.

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

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

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

  • PEUT prendre en charge le contrôle du volume et de la plage dynamique à l'aide de la norme ISO/IEC 23003-4 Profil Dynamic Range Control.

Si la norme ISO/IEC 23003-4 est acceptée, et si ISO/IEC 23003-4 et Les métadonnées ISO/IEC 14496-3 sont présentes dans un flux de bits décodé, alors:

  • Les métadonnées ISO/IEC 23003-4 ONT la priorité.

Tous les décodeurs audio DOIVENT prendre en charge la sortie:

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

  • [C-7-1] DOIT être configuré par l'application à l'aide du décodage avec la clé KEY_MAX_OUTPUT_CHANNEL_COUNT pour contrôler si le contenu est réduit en stéréo (si vous utilisez la valeur 2) ou est généré en utilisant le nombre natif de canaux (en cas d'utilisation d'une valeur égale ou supérieur à ce nombre). Par exemple, une valeur égale ou supérieure à 6 configure un décodeur pour sortir 6 canaux lorsqu'il est alimenté en 5.1.
  • [C-7-2] Lors du décodage, le décodeur DOIT annoncer le masque de canal utilisé. sur le format de sortie avec KEY_CHANNEL_MASK à l'aide des constantes android.media.AudioFormat (exemple: CHANNEL_OUT_5POINT1).

Si les implémentations de l'appareil sont compatibles avec d'autres décodeurs audio que le format AAC par défaut décodeur et sont capables de produire du contenu audio multicanal (c'est-à-dire plus de 2 canaux) en cas d'insertion de contenu multicanal compressé, puis:

  • [C-SR-2] Il est FORTEMENT RECOMMANDÉ de pouvoir configurer le décodeur pour à l'aide du décodage avec la clé KEY_MAX_OUTPUT_CHANNEL_COUNT pour contrôler si le contenu est réduit en stéréo (si vous utilisez la valeur 2) ou est généré en utilisant le nombre natif de canaux (en cas d'utilisation d'une valeur égale ou supérieur à ce nombre). Par exemple, une valeur égale ou supérieure à 6 configure un décodeur pour sortir 6 canaux lorsqu'il est alimenté en 5.1.
  • [C-SR-3] Lors du décodage, il est FORTEMENT RECOMMANDÉ d'utiliser le décodeur pour annoncer masque de canal utilisé sur le format de sortie avec KEY_CHANNEL_MASK à l'aide des constantes android.media.AudioFormat (exemple: CHANNEL_OUT_5POINT1).

5.1.3. Détails des codecs audio

Format/Codec Détails Types de fichiers/Formats de conteneur compatibles
Profil MPEG-4 AAC
(AAC LC)		 Compatibilité avec le contenu mono/stéréo/5.0/5.1 avec le standard de 8 à 48 kHz.
  • 3GPP (0,3gp)
  • MPEG-4 (.mp4, .m4a)
  • ADTS AAC bruts (.aac, ADIF non compatibles)
  • MPEG-TS (.ts, impossible de rechercher, décodage uniquement)
  • Matroska (.mkv, décodage uniquement)
Profil MPEG-4 HE AAC (AAC+) Compatibilité avec le contenu mono/stéréo/5.0/5.1 avec le standard de 16 à 48 kHz.
  • 3GPP (0,3gp)
  • MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2
Profil (AAC+ amélioré)		 Compatibilité avec le contenu mono/stéréo/5.0/5.1 avec le standard de 16 à 48 kHz.
  • 3GPP (0,3gp)
  • MPEG-4 (.mp4, .m4a)
AAC ELD (AAC à faible délai amélioré) Compatibilité avec les contenus mono/stéréo avec des taux d'échantillonnage standards de 16 à 48 kHz.
  • 3GPP (0,3gp)
  • MPEG-4 (.mp4, .m4a)
USAC Compatibilité avec les contenus mono/stéréo avec des taux d'échantillonnage standards à partir de 7,35 à 48 kHz. MPEG-4 (.mp4, .m4a)
AMR-NB 4,75 à 12,2 kbit/s échantillonnés à 8 kHz 3GPP (0,3gp)
AMR-WB Neuf débits de 6,60 kbit/s à 23,85 kbit/s échantillonnés à 16 kHz, comme défini à AMR-WB, codec vocal à large bande AMR-WB adaptatif multi-débit 3GPP (0,3gp)
FLAC Pour l'encodeur comme le décodeur, au moins les modes Mono et Stéréo DOIVENT être compatibles. Les taux d'échantillonnage jusqu'à 192 kHz DOIVENT être acceptés. 16 bits et 24 bits la résolution DOIT être acceptée. Le traitement des données audio FLAC 24 bits DOIT être disponible avec la configuration audio à virgule flottante.
  • FLAC (.flac)
  • MPEG-4 (.mp4, .m4a, décodage uniquement)
  • Matroska (.mkv, décodage uniquement)
MP3 Constante CBR (Mono/Stéréo) de 8 à 320 kbit/s ou débit variable (VBR)
  • MP3 (.mp3)
  • MPEG-4 (.mp4, .m4a, décodage uniquement)
  • Matroska (.mkv, décodage uniquement)
MIDI Type MIDI 0 et 1. DLS version 1 et 2. XMF et Mobile XMF. Assistance pour formats de sonnerie RTTTL/RTX, OTA et iMelody
  • Type 0 et 1 (.mid, .xmf, .mxmf)
  • RTTTL/RTX (.rtttl, .rtx)
  • iMelody (.imy)
Vorbis Décodage: prise en charge des contenus mono, stéréo, 5.0 et 5.1 avec échantillonnage fréquences 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, 16 000, 24 000 et 48 000 Hz.
  • Ogg (.ogg)
  • MPEG-4 (.mp4, .m4a, décodage uniquement)
  • Matroska (.mkv)
  • WebM (.webm)
PCM/WAVE Le codec PCM DOIT être compatible avec la PCM linéaire 16 bits et le float 16 bits. WAVE l'extracteur doit être compatible avec les mesures PCM linéaires 16, 24 bits et 32 bits, et les nombres à virgule flottante 32 bits. (taux pouvant atteindre la limite du matériel). Les taux d'échantillonnage DOIVENT être acceptés 8 kHz à 192 kHz. WAVE (.wav)
Opus 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, 16 000, 24 000 et 48 000 Hz.
  • Ogg (.ogg)
  • MPEG-4 (.mp4, .m4a, décodage uniquement)
  • Matroska (.mkv)
  • WebM (.webm)

5.1.4. Encodage d'image

Pour plus d'informations, consultez la section 5.1.6. Détails des codecs image.

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

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

Commencer les nouvelles exigences

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

Mettre fin aux nouvelles exigences

Si les implémentations d'appareils acceptent l'encodage HEIC via android.media.MediaCodec pour le type de support MIMETYPE_IMAGE_ANDROID_HEIC, ils:

  • [C-1-1] DOIT fournir un codec encodeur HEVC avec accélération matérielle compatible avec BITRATE_MODE_CQ le mode de contrôle du débit, HEVCProfileMainStill et une taille de cadre de 512 x 512 pixels.

5.1.5. Décodage d'images

Pour plus d'informations, consultez la section 5.1.6. Détails des codecs image.

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

  • [C-0-1] JPEG
  • [C-0-2] GIF
  • [C-0-3] PNG
  • [C-0-4] BMP
  • [C-0-5] WebP
  • [C-0-6] Brut
  • [C-0-7] AVIF (profil de référence)

Si les implémentations d'appareils sont compatibles avec le décodage vidéo HEVC, elles: * [C-1-1] DOIT être compatible avec le décodage d'image HEIF (HEIC).

Décodeurs d'images compatibles avec un format à forte profondeur de bits (plus de 9 bits par canal):

  • [C-2-1] DOIT prendre en charge la sortie d'un format équivalent à 8 bits si le l'application, par exemple, via le ARGB_8888 configuration de android.graphics.Bitmap.

5.1.6. Détails des codecs image

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)

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

  • [C-1-1] DOIT prendre en charge la couleur flexible YUV420 8:8:8 (COLOR_FormatYUV420Flexible) à CodecCapabilities.

  • [C-SR-1] FORTEMENT RECOMMANDÉ de prendre en charge le format de couleurs RGB888 pour la surface d'entrée .

  • [C-1-3] DOIT prendre en charge au moins l'un des types planaires ou semi-planaires Format de couleurs YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (équivalent à COLOR_FormatYUV420Planar) ou COLOR_FormatYUV420PackedSemiPlanar (équivalent à COLOR_FormatYUV420SemiPlanar). Ils sont FORTEMENT RECOMMANDÉS les deux.

5.1.7. Codecs vidéo

  • Qualité acceptable pour le streaming vidéo Web et la visioconférence services, les implémentations d'appareils DOIVENT utiliser un codec matériel VP8 conforme au exigences.

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

  • [C-1-1] Les codecs vidéo DOIVENT prendre en charge les tailles de mémoire tampon d'octets de sortie et d'entrée pour prendre en charge la plus grande trame compressée et non compressée possible, par le standard et la configuration, mais sans surallouer non plus.

  • [C-1-2] Les encodeurs et décodeurs vidéo DOIVENT prendre en charge la couleur flexible YUV420 8:8:8 (COLOR_FormatYUV420Flexible) à CodecCapabilities.

  • [C-1-3] Les encodeurs et décodeurs vidéo DOIVENT prendre en charge au moins l'un des types de plans format de couleurs YUV420 semi-plan 8:8:8: COLOR_FormatYUV420PackedPlanar (équivalent à COLOR_FormatYUV420Planar) ou COLOR_FormatYUV420PackedSemiPlanar (équivalent à COLOR_FormatYUV420SemiPlanar). Il est FORTEMENT RECOMMANDÉ de les accepter dans les deux cas.

  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'utiliser des encodeurs et décodeurs vidéo au moins un format YUV420 planaire ou semi-plan optimisé pour le matériel, couleur 8:8:8 (YV12, NV12, NV21 ou un format équivalent optimisé par les fournisseurs).

  • [C-1-5] Décodeurs vidéo compatibles avec un format à forte profondeur de bits (plus de 9 bits par canal) DOIT prendre en charge la sortie d'un format équivalent à 8 bits si demandée par l'application. Cela DOIT être reflété par l'ajout d'un Format de couleurs YUV420 8:8:8 via android.media.MediaCodecInfo.

Si les implémentations d'appareils font la publicité de la prise en charge des profils HDR via Display.HdrCapabilities, ils:

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

Si les implémentations d'appareils annoncent la prise en charge de l'actualisation des intra-actualisations via FEATURE_IntraRefresh dans le MediaCodecInfo.CodecCapabilities , ils:

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

Sauf indication contraire de l'application, utiliser KEY_COLOR_FORMAT clé de formatage, implémentations de décodeur vidéo:

  • [C-4-1] DOIT utiliser par défaut le format de couleur optimisé pour l'affichage matériel si elle est configurée à l'aide de la sortie de la surface.
  • [C-4-2] DOIT utiliser par défaut un format de couleurs YUV420 8:8:8 optimisé pour le processeur si elle est configurée pour ne pas utiliser la sortie de la surface.

5.1.8. Liste des codecs vidéo

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 Voir la section 5.2 et 5.3 pour en savoir plus
  • 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 Voir la section 5.2 et 5.3 pour en savoir plus
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.9. Sécurité du codec multimédia

Les implémentations d'appareils DOIVENT garantir la conformité avec les fonctionnalités de sécurité du codec multimédia. comme décrit ci-dessous.

Android est compatible avec OMX, une API d'accélération multimédia multiplate-forme, ainsi que Codec 2.0, une API d'accélération multimédia peu coûteuse.

Si les implémentations d'appareils prennent en charge le contenu multimédia, elles:

  • [C-1-1] DOIT prendre en charge les codecs multimédias via OMX ou Codec 2.0 (ou les deux), comme dans le projet Android Open Source, et qui ne peuvent pas désactiver contournent les protections de sécurité. Cela ne signifie pas nécessairement le codec DOIT utiliser l'API OMX ou Codec 2.0, uniquement pour prendre en charge au moins l'une de ces API DOIT être disponible, et la prise en charge de ces API DOIT être disponible inclure les protections de sécurité existantes.
  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure la prise en charge de l'API Codec 2.0.

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

  • [C-2-1] DOIT inclure le codec logiciel OMX correspondant de l'API Android Projet Open Source (s'il est disponible) pour chaque format et type de support (encodeur ou décodeur) compatible avec l'appareil.
  • [C-2-2] Les codecs dont le nom commence par "OMX.google". DOIT être basé sur le code source de son projet Android Open Source.
  • [C-SR-2] Il est FORTEMENT RECOMMANDÉ que les codecs logiciels OMX s'exécutent dans un codec qui n'a pas accès aux pilotes de matériel autres que les mappeurs de mémoire.

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

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

5.1.10. Caractérisation du codec multimédia

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

  • [C-1-1] DOIT renvoyer des valeurs correctes de caractérisation du codec multimédia via la propriété MediaCodecInfo API.

En particulier :

  • [C-1-2] Codecs dont le nom commence par "OMX". OBLIGATOIRE D'utiliser les API OMX et dont les noms sont conformes aux directives OMX IL.
  • [C-1-3] Codecs dont le nom commence par "c2". DOIT utiliser l'API Codec 2.0 et ont des noms conformes aux directives de dénomination du Codec 2.0 pour Android.
  • [C-1-4] Codecs dont le nom commence par "OMX.google" ou "c2.android". OBLIGATOIRE Ne doit PAS être caractérisé par un fournisseur ou une accélération matérielle.
  • [C-1-5] Les codecs qui s'exécutent dans un processus de codec (fournisseur ou système) l'accès aux pilotes de matériel autres que les outils d'allocation de mémoire et les mappeurs NE DOIT PAS être qualifiées uniquement de logiciels.
  • [C-1-6] Codecs absents ou non du projet Android Open Source sur le code source de ce projet DOIT être défini comme fournisseur.
  • [C-1-7] Les codecs qui utilisent l'accélération matérielle DOIVENT être caractérisés avec l'accélération matérielle.
  • [C-1-8] Les noms de codec NE DOIVENT PAS être trompeurs. Par exemple, les codecs nommés "décodeurs" DOIT prendre en charge le décodage, et ceux nommés "encodeurs" DOIT prendre en charge l'encodage. Les codecs dont les noms contiennent des formats multimédias DOIVENT prendre en charge ces .

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 le codec le permet:
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)
  • [C-2-2] Les codecs vidéo caractérisés par une accélération matérielle DOIVENT publier des informations sur les points de performance. Chacune doit OBLIGATOIREMENT être listée points de performance standards (répertoriés dans PerformancePoint) API), sauf si elles sont couvertes par un autre point de performance standard pris en charge.
  • De plus, ils DOIVENT publier des points de performance étendus s'ils d'enregistrer des performances vidéo durables autres que celles standards répertoriées.

5.2. Encodage vidéo

Si les implémentations d'appareils sont compatibles avec n'importe quel encodeur vidéo et le rendent disponible à des applications tierces:

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

Commencer les nouvelles exigences

Si les implémentations d'appareils sont compatibles avec n'importe quel encodeur vidéo et le mettent à la disposition applications tierces et définir le paramètre
De MediaFormat.KEY_BITRATE_MODE à BITRATE_MODE_VBR afin que l'encodeur fonctionne en mode "Débit variable", tant que cela n'a pas d'incidence sur le prix minimal de qualité, débit encodé :

  • [C-5-1] OBLIGATOIRE NE DEVRAIT PAS être supérieur à un fenêtre glissante, supérieure à 15% du débit entre l'intraframe (iFrame) à intervalles réguliers.
  • [C-5-2] OBLIGATOIRE NE DEVRAIT PAS être supérieur à 100% au 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 mettent à la disposition des applications tierces et définir MediaFormat.KEY_BITRATE_MODE jusqu'à BITRATE_MODE_CBR afin que l'encodeur fonctionne en mode "Débit constant", puis le débit encodé:

  • [C-6-1] OBLIGATOIRE [C-SR-2] est VIVEMENT RECOMMANDÉ Ne doit PAS dépasser 15% au-dessus du débit cible sur une fenêtre glissante d'une seconde.

Mettre fin aux nouvelles exigences

Si les implémentations d'appareils incluent un écran intégré avec en diagonale d'au moins 2,5 pouces ou si elles comprennent un port de sortie vidéo ou déclarer la prise en charge d'une caméra via android.hardware.camera.any de fonctionnalité, ils:

  • [C-1-1] DOIT être compatible avec au moins une vidéo VP8 ou H.264 et les rendre disponibles pour des applications tierces.
  • DEVRAIT prendre en charge les encodeurs vidéo VP8 et H.264, et le rendre disponible pour les applications tierces.

Si les implémentations d'appareils sont compatibles avec les vidéos H.264, VP8, VP9 ou HEVC et les mettent à la disposition d'applications tierces, ils:

  • [C-2-1] DOIT être compatible avec les débits configurables dynamiquement.
  • DEVRAIT prendre en charge des fréquences d'images variables, où l'encodeur vidéo DOIT déterminer une durée de frame instantanée en fonction des codes temporels des tampons d'entrée alloue son bucket de bits en fonction de cette durée de trame.

Si les implémentations d'appareils prennent en charge l'encodeur vidéo MPEG-4 SP et l'envoient disponibles pour les applications tierces:

  • DEVRAIT prendre en charge des débits configurables dynamiquement pour l'encodeur pris en charge.

Si les implémentations d'appareils fournissent des encodeurs vidéo ou d'image avec accélération matérielle, et prendre en charge une ou plusieurs caméras branchées ou branchées les API android.camera:

  • [C-4-1] Tous les encodeurs vidéo et d'image avec accélération matérielle DOIVENT prendre en charge à partir des caméras matérielles.
  • DEVRAIT prendre en charge l'encodage des images de la ou des caméras matérielles tout au long de la vidéo ou encodeurs d'images.

Si les implémentations d'appareils proposent un encodage HDR, celles-ci:

  • [C-SR-1] est VIVEMENT RECOMMANDÉ de fournir un plug-in pour API de transcodage transparente pour la conversion du format HDR au format SDR.

5.2.1. H.263

Si les implémentations d'appareils sont compatibles avec les encodeurs H.263 et le rendent disponible à des applications tierces:

  • [C-1-1] DOIT être compatible avec la résolution QCIF (176 x 144) avec le profil de référence de niveau 45. La résolution SQCIF est facultative.
  • DEVRAIT prendre en charge les débits configurables de manière dynamique pour l'encodeur compatible.

5.2.2. H.264

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

  • [C-1-1] DOIT prendre en charge le profil de référence de niveau 3. Toutefois, les options ASO (Arbitrary Slice Ordering) et FMO (Flexible) sont ordre Macroblock) et RS (segments redondants) est FACULTATIF. De plus, pour assurer la compatibilité avec d'autres appareils Android, il est RECOMMANDÉ de ASO, FMO et RS ne sont pas utilisés pour le profil de référence par les encodeurs.
  • [C-1-2] DOIT prendre en charge les profils d'encodage vidéo SD (définition standard) dans le tableau suivant.
  • DEVRAIT prendre en charge le profil principal de niveau 4.
  • DEVRAIT prendre en charge les profils d'encodage vidéo HD (haute définition), car comme indiqué dans le tableau suivant.

Si les configurations d'appareils indiquent que l'encodage H.264 est compatible avec les formats 720p ou 1080p de résolution vidéo via les API multimédias, ils:

  • [C-2-1] DOIT être compatible avec les profils d'encodage indiqués dans le tableau suivant.
SD (basse qualité) SD (haute qualité) HD – 720p HD – 1080p
Résolution vidéo 320 x 240 px 720 x 480 px 1280 x 720 px 1920 x 1080 px
Fréquence d'images vidéo 20 FPS 30 ips 30 ips 30 ips
Débit vidéo 384 kbit/s 2 Mbit/s 4 Mbit/s 10 Mbit/s

5.2.3. VP8

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

  • [C-1-1] DOIT être compatible avec les profils d'encodage vidéo SD.
  • DEVRAIT prendre en charge les profils d'encodage vidéo HD (haute définition) suivants.
  • [C-1-2] DOIT prendre en charge l'écriture de fichiers Matroska WebM.
  • DEVRAIT fournir un codec matériel VP8 conforme à la Exigences concernant le codage matériel RTC du projet WebM, afin de garantir une qualité acceptable pour les services de streaming vidéo Web et de vidéoconférence.

Si les configurations d'appareils indiquent que l'encodage VP8 est compatible avec 720p ou 1080p de résolution vidéo via les API multimédias, ils:

  • [C-2-1] DOIT être compatible avec les profils d'encodage indiqués dans le tableau suivant.
SD (basse qualité) SD (haute qualité) HD – 720p HD – 1080p
Résolution vidéo 320 x 180 px 640 x 360 px 1280 x 720 px 1920 x 1080 px
Fréquence d'images vidéo 30 ips 30 ips 30 ips 30 ips
Débit vidéo 800 Kbit/s 2 Mbit/s 4 Mbit/s 10 Mbit/s

5.2.4. VP9

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

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

Si des mises en œuvre d'appareils prétendent être compatibles avec le Profil 2 ou le Profil 3 via le API multimédias:

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

5.2.5. H265

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'à 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 soutenir le Profil SD 720 x 480 et des profils d'encodage HD comme indiqué dans le tableau suivant en cas de et un encodeur matériel.
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 1,6 Mbit/s 4 Mbit/s 5 Mbit/s 20 Mbit/s

Commencer les nouvelles exigences

5.2.6. AV1

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 de performances, c'est-à-dire créer des rapports sur les données de performances via getSupportedFrameRatesFor() ou getSupportedPerformancePoints() API pour les résolutions compatibles dans le 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 prendre en charge un profil d'encodage HD1080p compris entre 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

Mettre fin aux nouvelles exigences

5.3. Décodage vidéo

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

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

5.3.1. MPEG-2

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

  • [C-1-1] DOIT prendre en charge le niveau supérieur du profil principal.

5.3.2. H.263

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

  • [C-1-1] DOIT prendre en charge le profil de référence de niveau 30 (Résolutions CIF, QCIF et SQCIF à 30 FPS) 384 kbit/s) et niveau 45 (Résolutions QCIF et SQCIF à 30 FPS) 128 kbit/s).

5.3.3. MPEG-4

Si les appareils sont implémentés avec des décodeurs MPEG-4:

  • [C-1-1] DOIT prendre en charge le niveau de profil simple 3.

5.3.4. H.264

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

  • [C-1-1] DOIT être compatible avec le profil principal de niveau 3.1 et le profil de référence. Assistance pour ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) et RS (Segments redondants) est FACULTATIF.
  • [C-1-2] DOIT être capable de décoder les vidéos en définition standard (SD) répertoriés dans le tableau suivant et encodés avec le profil de référence et Profil principal niveau 3.1 (y compris 720p30).
  • DOIT être capable de décoder les vidéos avec des profils HD (haute définition). comme indiqué dans le tableau suivant.

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

  • [C-2-1] DOIT être compatible avec les profils de décodage vidéo HD 720p dans les éléments suivants : tableau.
  • [C-2-2] DOIT être compatible avec les profils de décodage vidéo HD 1080p dans les éléments suivants : tableau.
SD (basse qualité) SD (haute qualité) HD – 720p HD – 1080p
Résolution vidéo 320 x 240 px 720 x 480 px 1280 x 720 px 1920 x 1080 px
Fréquence d'images vidéo 30 ips 30 ips 60 FPS 30 FPS (60 FPS pour la télévision)
Débit vidéo 800 Kbit/s 2 Mbit/s 8 Mbit/s 20 Mbit/s

5.3.5. H.265 (HEVC)

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

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

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

  • [C-2-1] Les implémentations d'appareils DOIVENT être compatibles avec au moins une norme H.265 ou VP9 décodage des profils 720, 1080 et UHD.
SD (basse qualité) SD (haute qualité) HD – 720p HD – 1080p UHD
Résolution vidéo 352 x 288 px 720 x 480 px 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/60 FPS (60 FPS, téléviseur avec décodage matériel H.265) 60 FPS
Débit vidéo 600 Kbits/s 1,6 Mbit/s 4 Mbit/s 5 Mbit/s 20 Mbit/s

Si des appareils affirment être compatibles avec un profil HDR via le support API:

  • [C-3-1] Les implémentations d'appareils DOIVENT accepter les métadonnées HDR requises par les de l'application, et accepteront l'extraction et la sortie de l'image HDR requise. du flux de bits et/ou du conteneur.
  • [C-3-2] Les implémentations d'appareils DOIVENT afficher correctement le contenu HDR l'écran d'un appareil ou sur un port de sortie vidéo standard (par exemple, HDMI).

5.3.6. VP8

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

  • [C-1-1] DOIT être compatible avec les profils de décodage SD indiqués dans le tableau suivant.
  • DEVRAIT utiliser un codec matériel VP8 conforme à la exigences.
  • DEVRAIT prendre en charge les profils de décodage HD indiqués dans le tableau suivant.

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

  • [C-2-1] Les implémentations d'appareils DOIVENT être compatibles avec les profils 720p dans le tableau suivant.
  • [C-2-2] Les implémentations d'appareils DOIVENT être compatibles avec les profils 1080p dans le tableau suivant.
SD (basse qualité) SD (haute qualité) HD – 720p HD – 1080p
Résolution vidéo 320 x 180 px 640 x 360 px 1280 x 720 px 1920 x 1080 px
Fréquence d'images vidéo 30 ips 30 ips 30 FPS (60 FPS pour la télévision) 30 (60 FPS pour la télévision)
Débit vidéo 800 Kbit/s 2 Mbit/s 8 Mbit/s 20 Mbit/s

5.3.7. VP9

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

  • [C-1-1] DOIT être compatible avec les profils de décodage vidéo SD, comme indiqué dans dans le tableau suivant.
  • DEVRAIT être compatible avec les profils de décodage HD, comme indiqué dans le tableau suivant.

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

  • [C-2-1] DOIT être compatible avec les profils de décodage HD, comme indiqué ci-dessous tableau.

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

  • [C-3-1] Les implémentations d'appareils DOIVENT être compatibles avec au moins un code VP9 ou H.265 le décodage des profils 720, 1080 et UHD.
SD (basse qualité) SD (haute qualité) HD – 720p HD – 1080p UHD
Résolution vidéo 320 x 180 px 640 x 360 px 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 FPS (téléviseur avec décodage matériel VP9) 60 FPS
Débit vidéo 600 Kbits/s 1,6 Mbit/s 4 Mbit/s 5 Mbit/s 20 Mbit/s

Si des intégrations d'appareils affirment être compatibles avec VP9Profile2 ou VP9Profile3 via l'élément "CodecProfileLevel" API multimédias:

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

Si des appareils sont compatibles avec un profil HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) via la API multimédias:

  • [C-4-1] Les implémentations d'appareils DOIVENT accepter les métadonnées HDR requises. (KEY_HDR_STATIC_INFO) pour tous les profils HDR, ainsi que "KEY_HDR10_PLUS_INFO" pour les profils HDR10Plus) depuis l'application. Ils DOIVENT également être compatibles avec l'extraction et la sortie des métadonnées HDR requises à partir du flux de bits et/ou du conteneur.
  • [C-4-2] Les implémentations d'appareils DOIVENT afficher correctement le contenu HDR l'écran d'un appareil ou sur un port de sortie vidéo standard (par exemple, HDMI).

5.3.8. Dolby Vision

Si les implémentations d'appareils déclarent prendre en charge le décodeur Dolby Vision via HDR_TYPE_DOLBY_VISION , ils:

  • [C-1-1] DOIT fournir un extracteur compatible Dolby Vision.
  • [C-1-2] DOIT afficher correctement le contenu Dolby Vision sur l'écran de l'appareil ou sur un port de sortie vidéo standard (par exemple, HDMI).
  • [C-1-3] DOIT définir l'ID du canal de couches de base rétrocompatibles (le cas échéant) doivent être identiques à l'ID de piste combiné de la couche Dolby Vision.

5.3.9. AV1

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

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

Commencer les nouvelles exigences

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 de périphériques prennent en charge le codec AV1 avec un le décodeur accéléré:

  • [C-2-1] DOIT être capable de décoder au moins des profils de décodage vidéo HD 720p depuis le tableau ci-dessous lorsque la hauteur indiquée par 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 Display.getSupportedModes() est supérieure ou égale à 1080p.
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 Media, ils:

  • [C-3-1] DOIT être compatible avec l'extraction et la sortie des métadonnées HDR à partir du en flux de bits et/ou en 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).

Mettre fin aux nouvelles exigences

5.4. Enregistrement audio

Bien que certaines des exigences décrites dans cette section soient énumérées comme DEVRAIT. depuis Android 4.3, la définition de compatibilité pour les versions futures pour les remplacer par OBLIGATOIRE. Les appareils Android nouveaux et existants sont fortement RECOMMANDÉ de répondre aux exigences listées comme DEVRAIT, ou ne pourront pas assurer la compatibilité avec Android lors de leur mise à niveau. version.

5.4.1. Capture audio brute et informations sur le micro

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

  • [C-1-1] DOIT autoriser la capture de contenu audio brut pour tout flux d'ENTRÉE AudioRecord ou AAudio ouvert avec succès. Les caractéristiques suivantes DOIVENT être acceptées:

  • DEVRAIT permettre de capturer du contenu audio brut avec les éléments suivants : caractéristiques:

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

  • [C-1-2] DOIT enregistrer à des taux d'échantillonnage supérieurs sans suréchantillonnage.

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

  • DEVRAIT autoriser la capture radio AM et DVD de qualité audio brute, ce qui désigne les caractéristiques suivantes:

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

  • [C-1-4] DOIT respecter l'API MicrophoneInfo et indiquer correctement les informations concernant les micros disponibles sur l'appareil accessibles aux applications tierces AudioManager.getMicrophones() pour un enregistrement audio actif à l'aide de l'API MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION VOICE_COMMUNICATION, UNPROCESSED ou VOICE_PERFORMANCE. Si les configurations d'appareils permettent une capture radio AM et DVD de qualité audio brute contenu, elles:

  • [C-2-1] DOIT enregistrer sans suréchantillonnage à un ratio supérieur à 16000:22050 ou 44100:48000.

  • [C-2-2] DOIT inclure un filtre d'anticrénelage approprié pour tout suréchantillonnage ou le sous-échantillonnage.

5.4.2. Capturer pour la reconnaissance vocale

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

  • [C-1-1] DOIT capturer android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION source audio à l'un des taux d'échantillonnage, 44 100 et 48 000.
  • [C-1-2] DOIT désactiver par défaut tout traitement audio de réduction de bruit enregistrer un flux audio à partir de l'audio AudioSource.VOICE_RECOGNITION source.

  • [C-1-3] DOIT désactiver par défaut tout contrôle de gain automatique lors de l'enregistrement un flux audio provenant de la source audio AudioSource.VOICE_RECOGNITION.

  • DEVRAIT présenter des caractéristiques amplitude-fréquence approximativement plates dans la plage des fréquences moyennes: ±3 dB de 100 Hz à 4 000 Hz pour chacune et chaque micro utilisé pour enregistrer la source audio de reconnaissance vocale.

  • Il est FORTEMENT RECOMMANDÉ d'utiliser [C-SR-1] pour montrer des niveaux d'amplitude dans les basses de ±20 dB de 30 Hz à 100 Hz, plage de fréquence moyenne pour chaque micro utilisé pour enregistrer la voix source audio de reconnaissance.

  • Il est FORTEMENT RECOMMANDÉ d'utiliser les [C-SR-2] pour montrer des niveaux d'amplitude plage de fréquences: spécifiquement de ±30 dB de 4 000 Hz à 22 kHz, La plage de fréquences moyennes pour chaque micro utilisé pour enregistrer la voix source audio de reconnaissance.

  • DEVRAIT régler la sensibilité d'entrée audio de sorte à utiliser une source de tonalités sinusoïdales de 1 000 Hz diffusé à un niveau de pression acoustique (SPL) de 90 dB (mesuré) à une distance de 30 cm de à côté du micro) donne une réponse idéale de 2 500 RMS entre 1 770 et 3 530 pour 16. Échantillons de bits (ou -22,35 db ±3 dB Full Scale pour virgule flottante/double précision) échantillons) pour chaque micro utilisé pour enregistrer la reconnaissance vocale source audio.

  • DEVRAIT enregistrer le flux audio de reconnaissance vocale afin que l'amplitude PCM suivent linéairement les changements de valeurs SPL d'entrée sur une plage d'au moins 30 dB à partir de -18 dB à +12 dB, re 90 dB SPL au niveau du micro.

  • DEVRAIT enregistrer le flux audio de reconnaissance vocale avec une harmonie totale de distorsion (THD) inférieure à 1% pour 1 kHz avec un niveau d'entrée SPL de 90 dB au niveau à l'aide d'un micro.

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

  • [C-2-1] DOIT permettre de contrôler cet effet audio avec la API android.media.audiofx.NoiseSuppressor.
  • [C-2-2] DOIT identifier de manière unique chaque technologie de suppression du bruit via le champ AudioEffect.Descriptor.uuid.

5.4.3. Capturer pour réacheminer la lecture

La classe android.media.MediaRecorder.AudioSource inclut l'élément REMOTE_SUBMIX. source audio.

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

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

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

5.4.4. Annulateur d'écho acoustique

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

  • DEVRAIT implémenter un annulant d'écho acoustique (AEC) calibrée pour la communication vocale et appliquée au chemin de capture lors de la capture avec AudioSource.VOICE_COMMUNICATION.

Si les implémentations de l'appareil fournissent un annulant d'écho acoustique inséré dans le chemin audio de capture lorsque AudioSource.VOICE_COMMUNICATION sont sélectionnées, elles:

5.4.5. Capture simultanée

Si les intégrations d'appareils déclarent android.hardware.microphone,ils DOIVENT implémenter la capture simultanée comme décrit dans ce document. Plus spécifiquement :

  • [C-1-1] DOIT autoriser l'accès simultané au micro par un service d'accessibilité la capture de service avec AudioSource.VOICE_RECOGNITION et au moins un la capture d'application avec n'importe quel AudioSource.
  • [C-1-2] DOIT autoriser l'accès simultané au micro par un appareil application ayant un rôle d'Assistant et au moins une application la capture avec n'importe quel élément AudioSource, sauf AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER.
  • [C-1-3] DOIT couper le son de la capture audio pour toute autre application, sauf un service d'accessibilité, tandis qu'une application capture AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER. Toutefois, lorsque une application capture via AudioSource.VOICE_COMMUNICATION, puis une autre application peut capturer l'appel vocal s'il s'agit d'une application privilégiée (préinstallée) avec autorisation CAPTURE_AUDIO_OUTPUT.
  • [C-1-4] Si plusieurs applications capturent simultanément aucune des deux applications n'a d'interface utilisateur, celle qui a commencé à capturer la dernière fois reçoit le son.

5.5. Lecture audio

Android permet d'autoriser les applications à lire du contenu audio via l'audio périphérique de sortie tel que défini dans la section 7.8.2.

5.5.1. Lecture audio brute

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

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

    • Formats sources: PCM linéaire, 16 bits, 8 bits, float
    • Canaux: configurations mono, stéréo et multicanaux valides avec jusqu'à huit chaînes
    • Taux d'échantillonnage (en Hz):
      • 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 au niveau du canal configurations listées ci-dessus
      • 96 000 en mono et stéréo

5.5.2. Effets audio

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

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

  • [C-1-1] DOIT prendre en charge les EFFECT_TYPE_EQUALIZER et Implémentations EFFECT_TYPE_LOUDNESS_ENHANCER contrôlables via la Les sous-classes AudioEffect Equalizer et LoudnessEnhancer
  • [C-1-2] DOIT prendre en charge l'implémentation de l'API Visualizer, contrôlable via la classe Visualizer.
  • [C-1-3] DOIT prendre en charge l'implémentation de EFFECT_TYPE_DYNAMICS_PROCESSING contrôlables via la sous-classe AudioEffect DynamicsProcessing.

Commencer les nouvelles exigences

  • [C-1-4] DOIT prendre en charge les effets audio avec d'entrée et de sortie à virgule flottante.
  • [C-1-5] DOIT s'assurer que les effets audio sont compatibles avec plusieurs canaux le nombre de canaux de la table de mixage, également appelé FCC_LIMIT.

Mettre fin aux nouvelles exigences

  • DEVRAIT prendre en charge EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, Implémentations EFFECT_TYPE_PRESET_REVERB et EFFECT_TYPE_VIRTUALIZER contrôlable via les sous-classes AudioEffect BassBoost, EnvironmentalReverb, PresetReverb et Virtualizer.
  • [C-SR-1] SONT FORTEMENT RECOMMANDÉS de prendre en charge les effets en virgule flottante et multicanal.

5.5.3. Volume de sortie audio

Implémentations pour les appareils automobiles:

  • DEVRAIT permettre de régler le volume audio séparément pour chaque flux audio, en fonction du type ou de l'utilisation de contenu définis par AudioAttributes et l'utilisation de l'audio dans les voitures, telle que définie publiquement dans android.car.CarAudioManager.

5.5.4. Déchargement audio

Si les appareils sont compatibles avec la lecture de déchargement audio, ils:

  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ de couper le contenu audio lu sans interruption. entre deux extraits de même format si spécifié par API AudioTrack gapless et le conteneur multimédia pour MediaPlayer.

5.6. Latence audio

La latence audio correspond au délai pendant lequel un signal audio traverse un système. De nombreuses classes d'applications reposent sur des latences courtes pour obtenir des des effets sonores.

Pour les besoins de cette section, utilisez les définitions suivantes:

  • latence de sortie. L'intervalle entre le moment où une application écrit un frame des données codées PCM et le moment où le son correspondant est présenté au via un transducteur intégré à l'appareil ou lorsque le signal quitte l'appareil et peuvent être observées en externe.
  • latence de sortie à froid. Délai entre le démarrage d'un flux de sortie et le temps de présentation de la première image en fonction des codes temporels, lorsque la sortie audio le système a été inactif et éteint avant la demande.
  • latence de sortie continue. la latence de sortie des frames suivants après que l'appareil lit du contenu audio.
  • la latence d'entrée. L'intervalle entre le moment où un son est présenté par l'environnement à l'appareil au niveau d'un transducteur intégré ou le signal entre dans l'appareil via un port et lorsqu’une application lit la trame correspondante de données codées PCM.
  • perd input. La partie initiale d'un signal d'entrée inutilisable ou indisponible.
  • latence d'entrée à froid. Délai entre le démarrage de la diffusion et le moment où la première trame valide est reçue, lorsque le système d'entrée audio est inactif et mis hors tension avant la requête.

  • latence d'entrée continue. La latence d'entrée pour les frames suivants pendant la capture audio.

  • la latence aller-retour continue. La somme de la latence d'entrée continue plus une latence de sortie continue plus une période de tampon. La période tampon permet temps nécessaire à l'application pour traiter le signal et temps nécessaire pour atténuer la phase entre les flux d'entrée et de sortie.

  • API de file d'attente de tampon OpenSL ES PCM L'ensemble des mesures liées à la protection contre la perte de données OpenSL ES API dans le NDK Android

  • API audio native AAudio : L'ensemble des API AAudio dans Android NDK.

  • Code temporel : Paire composée d'une position de cadre relative dans une et l'heure estimée à laquelle cette image rejoint ou quitte le flux de traitement audio sur le point de terminaison associé. Voir aussi AudioTimestamp :

  • glitch. Une interruption temporaire ou une valeur d'échantillon incorrecte dans le signal audio généralement causée par sous-exécution de la mémoire tampon pour la sortie, une surcharge de la mémoire tampon pour les entrées ou toute autre source de bruit numérique ou analogique.

  • écart absolu moyen. La moyenne de la valeur absolue de des écarts par rapport à la moyenne d'un ensemble de valeurs.

  • latence "appuyer sur ton". Délai entre le moment où l'utilisateur appuie sur l'écran et celui où une tonalité générée à la suite de cet appui est entendue sur l'enceinte.

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

  • [C-1-1] Le code temporel de sortie renvoyé par AudioTrack.getTimestamp et AAudioStream_getTimestamp a une précision de +/-2 ms.

  • [C-1-2] Latence de sortie à froid de 500 millisecondes ou moins.

  • [C-1-3] L'ouverture d'un flux de sortie à l'aide de AAudioStreamBuilder_openStream() DOIT prend moins de 1 000 millisecondes.

Si les implémentations d'appareils déclarent android.hardware.audio.output, elles sont VIVEMENT RECOMMANDÉ pour répondre aux exigences suivantes, voire les dépasser:

  • [C-SR-1] Latence de sortie à froid de 100 millisecondes ou moins sur les données du locuteur chemin d'accès.
  • [C-SR-2] Latence maximale de 80 millisecondes au maximum.

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

Commencer les nouvelles exigences

  • [C-SR-4] Latences aller-retour calculées en fonction des entrées et des sorties les horodatages renvoyés par AAudioStream_getTimestamp sont VIVEMENT RECOMMANDÉS à 30 ms de la latence aller-retour mesurée pour AAUDIO_PERFORMANCE_MODE_NONE et AAUDIO_PERFORMANCE_MODE_LOW_LATENCY pour les haut-parleurs, les casques filaires et sans fil.

Mettre fin aux nouvelles exigences

Si les implémentations d'appareils répondent aux exigences ci-dessus, calibrage, lors de l'utilisation de l'API audio native AAudio, pour une sortie continue et la latence de sortie à froid sur au moins un fichier audio compatible périphérique de sortie:

Si les implémentations sur les appareils ne répondent pas aux exigences de l'audio à faible latence via l'API audio native AAudio:

  • [C-2-1] NE DOIT PAS indiquer que l'audio à faible latence est pris en charge.

Si les implémentations d'appareils incluent android.hardware.microphone, ils DOIT respecter ces exigences audio d'entrée:

  • [C-3-1] Limite l'erreur dans les horodatages d'entrée renvoyés par AudioRecord.getTimestamp ou AAudioStream_getTimestamp, à +/- 2 ms. "Erreur" correspond ici à l'écart par rapport à la valeur correcte.
  • [C-3-2] Latence d'entrée à froid de 500 millisecondes ou moins.
  • [C-3-3] L'ouverture d'un flux d'entrée avec AAudioStreamBuilder_openStream() DOIT prend moins de 1 000 millisecondes.

Si les implémentations d'appareils incluent android.hardware.microphone, elles sont VIVEMENT RECOMMANDÉ pour répondre à ces exigences audio d'entrée:

  • [C-SR-8] Latence d'entrée froide de 100 millisecondes ou moins au-dessus du micro chemin d'accès aux données.

  • [C-SR-11] Limite l'erreur dans les horodatages d'entrée renvoyés par AudioRecord.getTimestamp ou AAudioStream_getTimestamp, à +/- 1 ms.

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

  • [C-SR-12] Il est FORTEMENT RECOMMANDÉ d'avoir une latence aller-retour moyenne continue de 50 millisecondes ou moins sur cinq mesures, avec une écart absolue moyenne inférieures à 10 ms sur au moins un chemin compatible.

5.7. Protocoles de réseau

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

Pour chaque codec et format de conteneur qu'une implémentation d'appareil est requise pour l'implémentation de l'appareil:

  • [C-1-1] DOIT prendre en charge ce codec ou ce conteneur via HTTP et HTTPS.

  • [C-1-2] DOIT prendre en charge les formats de segments multimédias correspondants, dans le tableau des formats des segments multimédias ci-dessous Brouillon de protocole HTTP Live Streaming, version 7

  • [C-1-3] DOIT prendre en charge les formats de charge utile RTSP correspondants, comme indiqué dans tableau RTSP ci-dessous. Pour les exceptions, consultez les notes de bas de tableau dans section 5.1.

Formats des segments média

Formats de segment Référence(s) Compatibilité avec le codec requise
Flux de transport MPEG-2 ISO 13818 Codecs vidéo:
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
Consultez la section 5.1.8 pour en savoir plus sur H264 AVC, MPEG2-4 SP,
et MPEG-2.

Codecs audio:

  • AAC
Consultez la section 5.1.3 pour en savoir plus sur AAC et ses variantes.
AAC avec encadrement ADTS et balises ID3 ISO 13818-7 Voir la section 5.1.1 . pour en savoir plus sur AAC et ses variantes
WebVTT WebVTT

RTSP (RTP, SDP)

Nom du profil Référence(s) Compatibilité avec le codec requise
H264 AVC RFC 6184 Voir la section 5.1.8 pour en savoir plus sur H264 AVC
MP4A-LATM RFC 6416 Voir la section 5.1.3. pour en savoir plus sur AAC et ses variantes
H263-1998 RFC 3551
RFC 4629
RFC 2190 		Voir la section 5.1.8 pour en savoir plus sur l'algorithme H263
H263-2000 RFC 4629 Voir la section 5.1.8 pour en savoir plus sur l'algorithme H263
AMR RFC 4867 Voir la section 5.1.3. pour en savoir plus sur AMR-NB
AMR-WB RFC 4867 Voir la section 5.1.3. pour en savoir plus sur AMR-WB
MP4V-ES RFC 6416 Voir la section 5.1.8 pour en savoir plus sur MPEG-4 SP
mpeg4 générique RFC 3640 Voir la section 5.1.3. pour en savoir plus sur AAC et ses variantes
MP2T RFC 2250 Pour en savoir plus, consultez la section Flux de transport MPEG-2 sous la diffusion HTTP en direct.

5.8. Secure Media

Si les implémentations d'appareils prennent en charge la sortie vidéo sécurisée et sont capables de des surfaces sécurisées:

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

Si les implémentations d'appareils déclarent la prise en charge de Display.FLAG_SECURE et de l'assistance protocole d'affichage sans fil, ils:

  • [C-2-1] DOIT sécuriser le lien au moyen d'un mécanisme cryptographiquement sécurisé, comme HDCP 2.x ou version ultérieure pour les écrans connectés via des protocoles sans fil comme Miracast.

Si les implémentations d'appareils déclarent la prise en charge de Display.FLAG_SECURE et sont compatibles avec les écrans externes filaires:

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

5.9. Interface numérique pour instruments de musique (MIDI)

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

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

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

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

  • DEVRAIT prendre en charge le mode périphérique MIDI via USB, section 7.7

5.10. Audio professionnel

Si les implémentations d'appareils indiquent la prise en charge de la fonctionnalité android.hardware.audio.pro via le android.content.pm.PackageManager , ils:

  • [C-1-1] DOIT signaler la prise en charge de la fonctionnalité android.hardware.audio.low_latency
  • [C-1-2] DOIT disposer d'une latence audio aller-retour continue, telle que définie dans la section 5.6 Latence audio sur 25 millisecondes ou moins sur au moins un chemin compatible.
  • [C-1-3] DOIT inclure un ou plusieurs ports USB compatibles avec le mode hôte USB et mode périphérique.
  • [C-1-4] DOIT signaler la prise en charge de la fonctionnalité android.software.midi.
  • [C-1-5] DOIT respecter les latences et les exigences audio USB Audio natif AAudio API et AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
  • [C-1-6] DOIT avoir une latence de sortie à froid de 200 millisecondes ou moins.
  • [C-1-7] DOIT avoir une latence d'entrée à froid de 200 millisecondes ou moins.

  • [C-1-8] DOIT avoir une latence moyenne "Tap-to-tone" de 80 millisecondes ou moins sur au moins 5 mesures sur le chemin de données entre le haut-parleur et le micro.

  • [C-SR-1] Sont FORTEMENT RECOMMANDÉS pour respecter les latences telles que définies dans la section 5.6 Latence audio, de 20 millisecondes ou inférieur, plus de 5 mesures avec un écart absolu moyen inférieur à 5 de millisecondes sur le chemin du haut-parleur jusqu'au micro.

  • [C-SR-2] SONT FORTEMENT RECOMMANDÉS de respecter les exigences concernant l'audio Pro pour latence audio aller-retour continue, latence d'entrée à froid et sortie à froid et les exigences audio USB via l'API AAudio native audio sur le chemin d'accès MMAP.

  • [C-SR-3] Il est FORTEMENT RECOMMANDÉ de fournir un niveau de processeur constant les performances lorsque l'audio est actif et que la charge du processeur varie. Cela doit être testé à l'aide de l'application Android SynthMark. SynthMark utilise un synthétiseur logiciel qui s'exécute sur un framework audio simulé qui mesure les performances du système. Consultez le Documentation SynthMark pour en savoir plus sur les benchmarks. SynthMark l'application doit être exécutée à l'aide "Test automatisé" et obtenir les résultats suivants:

    • voicemark.90 >= 32 voix
    • latencemark.Fix.little <= 15 ms
    • latencemark.dynamic.little <= 50 ms

  • DOIT minimiser les inexactitudes et les dérives de l'horloge audio par rapport à l'heure standard.

  • DEVRAIT minimiser la dérive de l'horloge audio par rapport au CPU CLOCK_MONOTONIC lorsque les deux sont actifs.

  • DEVRAIT minimiser la latence audio par rapport aux transducteurs intégrés à l'appareil.

  • DEVRAIT minimiser la latence audio sur l'audio numérique USB.

  • DEVRAIT documenter les mesures de latence audio sur tous les chemins.

  • DEVRAIT réduire la gigue des temps d'entrée du rappel d'achèvement du tampon audio, car cela affecte le pourcentage utilisable de la bande passante totale du processeur par le rappel.

  • DEVRAIT ne fournir aucun problème audio dans des conditions d'utilisation normale et avec une latence signalée.

  • DEVRAIT ne fournir aucune différence de latence entre les canaux.

  • DEVRAIT minimiser la latence moyenne MIDI sur tous les transports.

  • DEVRAIT minimiser la variabilité de la latence MIDI en cas de charge (gigue) sur tous les transports.

  • DEVRAIT fournir des horodatages MIDI précis pour tous les transports.

  • DOIT minimiser le bruit du signal audio sur les transducteurs intégrés à l'appareil, y compris les juste après le démarrage à froid.

  • DEVRAIT ne fournir aucune différence d'horloge audio entre les côtés d'entrée et de sortie de les points de terminaison correspondants, quand les deux sont actifs. Exemples de messages comme le micro et le haut-parleur de l'appareil, ou l'entrée du connecteur audio et la sortie.

  • DEVRAIT gérer les rappels de complétion du tampon audio pour les côtés entrée et sortie des points de terminaison correspondants sur le même thread lorsque les deux sont actifs, et saisissez le rappel de sortie juste après le retour du rappel d'entrée. Ou s'il n'est pas possible de gérer les rappels sur le même thread, saisissez rappel de sortie peu de temps après la saisie du rappel d'entrée pour permettre à une temporisation cohérente des côtés d'entrée et de sortie.

  • DOIT minimiser la différence de phase entre la mise en mémoire tampon de l'audio HAL pour l'entrée et de sortie des points de terminaison correspondants.

  • DEVRAIT minimiser la latence tactile.

  • DEVRAIT minimiser la variabilité de la latence tactile en cas de charge (gigue).

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

Si les appareils sont équipés d'un connecteur audio 3,5 mm à 4 conducteurs, ils:

Si les appareils ne comprennent pas de connecteur audio 3,5 mm à 4 conducteurs et comprennent un ou plusieurs ports USB compatibles avec le mode hôte USB, ils:

  • [C-3-1] DOIT implémenter la classe audio USB.
  • [C-3-2] DOIT avoir une latence audio aller-retour continue moyenne de 25 millisecondes ou moins, sur 5 mesures avec un écart absolu moyen moins de 5 millisecondes sur le port en mode hôte USB en utilisant la classe audio USB. (Cela peut être mesuré à l'aide d'un adaptateur USB-3,5 mm et d'un bouclage audio Dongle ou utilisation d'une interface audio USB avec des câbles de raccordement connectant le entre les entrées et les sorties).
  • [C-SR-6] SONT FORTEMENT RECOMMANDÉS de prendre en charge les E/S simultanées jusqu'à huit canaux. chaque direction, un taux d'échantillonnage de 96 kHz et une profondeur de 24 bits ou 32 bits, selon l'utilisation avec des périphériques audio USB qui prennent également en charge ces exigences.
  • [C-SR-7] Il est FORTEMENT RECOMMANDÉ de répondre à ce groupe d'exigences en utilisant l'API audio AAudio native sur le chemin MMAP.

Si les appareils incluent un port HDMI, ils:

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

5.11. Capturer pour les éléments non traités

Android prend en charge l'enregistrement de contenu audio non traité via le android.media.MediaRecorder.AudioSource.UNPROCESSED source audio. Dans OpenSL ES, il est accessible avec le préréglage d'enregistrement SL_ANDROID_RECORDING_PRESET_UNPROCESSED

Si les implémentations d'appareils ont l'intention de prendre en charge une source audio non traitée pour les applications tierces, celles-ci:

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

  • [C-1-2] DOIT présenter une valeur amplitude-fréquence approximativement plate dans la plage des fréquences moyennes: ±10 dB du 100 Hz à 7 000 Hz pour chaque micro utilisé pour enregistrer le contenu non traité source audio.

  • [C-1-3] DOIT présenter des niveaux d'amplitude en basse fréquence de ±20 dB de 5 z à 100 Hz, dans une plage de fréquences moyennes pour chaque micro utilisé pour enregistrer source audio non traitée.

  • [C-1-4] DOIT présenter des niveaux d'amplitude en fréquence élevée de ±30 dB de 7 000 Hz à 22 kHz, dans une plage de fréquences moyennes pour chaque micro utilisé pour enregistrer source audio non traitée.

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

  • [C-1-6] DOIT avoir un rapport signal sur bruit (SNR) d'au moins 60 dB pour chaque micro utilisé pour enregistrer la source audio non traitée. (alors que la valeur SNR correspond à la différence entre 94 dB SPL et une valeur équivalente SPL du bruit propre, pondéré A).

  • [C-1-7] DOIT avoir une distorsion harmonique totale (THD) inférieure à 1% pour 1 kHZ à un niveau d'entrée SPL de 90 dB pour chacun des micros utilisés pour enregistrer la source audio non traitée.

  • [C-1-8] Ne doit PAS comporter d'autre traitement de signal (par exemple, (contrôle, filtre passe-haut ou annulation de l'écho) dans un chemin autre qu'un pour atteindre la plage souhaitée. Autrement dit :

    • [C-1-9] Si l'architecture comporte un traitement de signal il DOIT être désactivé et introduire efficacement un zéro délai ou une latence supplémentaire au chemin du signal.
    • [C-1-10] Le multiplicateur de niveau, bien qu'il puisse se trouver sur le chemin, NE DOIT PAS être utilisé. d'introduire un retard ou une latence dans le chemin du signal.

Toutes les mesures SPL sont effectuées directement à côté du micro testé. Si vous utilisez plusieurs micros, ces exigences s'appliquent aux appareils suivants : chaque micro.

Si les implémentations de l'appareil déclarent android.hardware.microphone, mais ne le faites pas sont compatibles avec les sources audio non traitées:

  • [C-2-1] DOIT renvoyer null pour AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) méthode API, pour indiquer correctement l'absence de prise en charge.
  • [C-SR-1] est toujours VIVEMENT RECOMMANDÉ de satisfaire à un maximum d'exigences pour le chemin de signal de la source d'enregistrement non traitée.

5.12. Vidéo HDR

Android 13 est compatible avec les technologies HDR décrites dans un prochain document.

Format de pixel

Si un décodeur vidéo annonce la prise en charge du format COLOR_FormatYUVP010, alors:

  • [C-1-1] DOIT prendre en charge le format P010 pour la lecture par processeur (ImageReader, MediaImage, ByteBuffer). Dans Android 13, P010 est assoupli pour permettre un pas arbitraire pour le Y et les plans UV.

  • [C-1-2] Le tampon de sortie P010 DOIT pouvoir être échantillonné par le GPU (lorsque allouée avec l'utilisation de GPU_SAMPLING). Cela permet de créer des GPU et de personnaliser la modélisation des tons par les applications.

Si un décodeur vidéo annonce la prise en charge du format COLOR_Format32bitABGR2101010, il:

  • [C-2-1] DOIT prendre en charge le format RGBA_1010102 pour la surface de sortie et Lisible par le processeur (sortie ByteBuffer).

Si un encodeur vidéo annonce la prise en charge du format COLOR_FormatYUVP010, il:

  • [C-3-1] DOIT être compatible avec le format P010 pour la surface d'entrée et les ressources en écriture pour le processeur (ImageWriter, MediaImage, ByteBuffer).

Si un encodeur vidéo annonce la prise en charge du format COLOR_Format32bitABGR2101010, il:

  • [C-4-1] DOIT prendre en charge le format RGBA_1010102 pour la surface d'entrée et les ressources en écriture sur processeur (ImageWriter, ByteBuffer). Remarque: Effectuer une conversion entre différents pour les encodeurs n'est PAS obligatoire.

Conditions requises pour la capture HDR

Pour tous les encodeurs vidéo compatibles avec les profils HDR, les implémentations d'appareils suivantes:

  • [C-5-1] NE DOIT PAS supposer que les métadonnées HDR sont précises. Par exemple, une trame encodée peut comporter des pixels au-delà du niveau de luminance maximale, ou la l'histogramme peut ne pas être représentatif de l'image.

  • DEVRAIT agréger les métadonnées dynamiques HDR pour générer des images statiques HDR appropriées. les métadonnées des flux encodés, et les afficher à la fin de chaque session d'encodage.

Si les implémentations d'appareils sont compatibles avec la capture HDR à l'aide des API CamcorderProfile ils:

  • [C-6-1] DOIT être également compatible avec la capture HDR via les API Camera2.

  • [C-6-2] DOIT prendre en charge au moins un encodeur vidéo avec accélération matérielle compatible avec chaque technologie HDR.

  • [C-6-3] DOIT prendre en charge (au minimum) la capture HLG.

  • [C-6-4] DOIT prendre en charge l'écriture des métadonnées HDR (le cas échéant d'une image) dans le fichier vidéo capturé. Pour AV1, HEVC et DolbyVision cela signifie inclure les métadonnées dans le flux de bits encodé.

  • [C-6-5] DOIT prendre en charge P010 et COLOR_FormatYUVP010.

  • [C-6-6] DOIT prendre en charge le mappage des tons HDR vers SDR avec les paramètres par défaut avec accélération matérielle pour le profil capturé. Autrement dit, Si un appareil peut capturer des images HDR10+ en HDR10+, le décodeur HEVC par défaut DOIT être capable pour décoder le flux capturé en SDR.

Conditions requises pour la retouche HDR

Si les implémentations d'appareils incluent des encodeurs vidéo compatibles avec le montage HDR, ils:

  • DEVRAIT utiliser une latence minimale pour générer les métadonnées HDR lorsqu'elles ne sont pas présentes. et DOIT gérer correctement les cas où les métadonnées sont présentes pour certains des cadres et pas pour d'autres. Ces métadonnées DOIVENT être précises (par exemple, la luminance maximale réelle et l'histogramme de l'image).

Si l'implémentation de l'appareil inclut des codecs compatibles avec FEATURE_HdrEditing, alors ces codecs:

  • [C-7-1] DOIT prendre en charge au moins un profil HDR.

  • [C-7-2] DOIT accepter FEATURE_HdrEditing pour tous les profils HDR promus par ce codec. En d'autres termes, ils DOIVENT prendre en charge la génération de métadonnées HDR n'est pas disponible pour tous les profils HDR compatibles qui utilisent des métadonnées HDR.

  • [C-7-3] DOIT être compatible avec les formats d'entrée d'encodeur vidéo suivants, préserver le signal décodé HDR:

    • RGBA_1010102 (déjà dans la courbe de transfert cible) pour les deux entrées surface et ByteBuffer et DOIT annoncer la prise en charge de COLOR_Format32bitABGR2101010.

Si l'implémentation de l'appareil inclut des codecs compatibles avec FEATURE_HdrEditing, l'appareil:

  • [C-7-4] DOIT indiquer la compatibilité avec l'extension OpenGL EXT_YUV_target.

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

6.1. Outils pour les développeurs

Implémentations pour les appareils:

  • [C-0-1] DOIT prendre en charge les outils pour les développeurs Android fournis dans SDK.

  • Android Debug Bridge (adb)

    • [C-0-2] DOIT prendre en charge adb, comme indiqué dans le SDK Android et le shell. fournies dans AOSP, qui peuvent être utilisées par les développeurs d'applications, y compris dumpsys cmd stats
    • [C-0-11] DOIT prendre en charge la commande shell cmd testharness. Mise à niveau... des implémentations d'appareils à partir d'une version antérieure d'Android le bloc de données persistant PEUT être exempté de l'instruction C-0-11.
    • [C-0-3] NE DOIT PAS modifier le format ni le contenu du système de l'appareil les événements (batterystats , diskstats, fingerprint, graphicstats, netstats, notification, procstats) consignés via la commande dumpsys.
    • [C-0-10] DOIT enregistrer, sans omission, et faire en sorte que les événements suivants accessible et disponible pour la commande shell cmd stats et Classe d'API système StatsManager.
      • État de premier plan de l'activité modifié
      • Anomalie détectée
      • Fil d'Ariane signalé
      • AppCrashOccured
      • AppStartOccurred (Démarrage de l'application)
      • Niveau de batterie modifié
      • État du mode d'économie de batterie modifié
      • BleScanResultReceived (Résultat reçu)
      • BleScanStateChanged
      • État de facturation modifié
      • DeviceIdleModeStateChanged
      • État du service de premier plan modifié
      • GpsScanStateChanged
      • État du job modifié
      • PluggedStateChanged
      • ScheduledJobStateChanged
      • État de l'écran modifié
      • SyncStateChanged (État de synchronisation modifié)
      • SystèmeElapsedRealtime
      • UidProcessStateChanged
      • État du wakelock modifié
      • Alarme du réveilSure
      • État du verrouillage du Wi-Fi modifié
      • État du verrouillage WifiMulticast modifié
      • État du Wi-Fi modifié
    • [C-0-4] DOIT faire en sorte que le daemon adb côté appareil soit inactif par défaut et il DOIT y avoir un mécanisme accessible à l'utilisateur pour activer le débogage Android Pont.
    • [C-0-5] DOIT être compatible avec adb sécurisé. Android permet de sécuriser adb. Le service adb sécurisé active adb sur des hôtes authentifiés connus.
    • [C-0-6] DOIT fournir un mécanisme permettant à adb d'être connecté à partir d'un la machine hôte. Plus spécifiquement :

    Si les implémentations d'appareils sans port USB sont compatibles avec le mode périphérique, celles-ci:

    • [C-3-1] DOIT implémenter adb via un réseau local (comme Ethernet ou Wi-Fi).
    • [C-3-2] DOIT fournir des pilotes pour Windows 7, 8 et 10, permettant aux développeurs de se connecter à l'appareil à l'aide du protocole adb.

    Si les implémentations d'appareils acceptent les connexions adb à une machine hôte via Wi-Fi ou Ethernet, ils:

    • [C-4-1] DOIT comporter la méthode AdbManager#isAdbWifiSupported() renvoient true.

    Si les implémentations d'appareils acceptent les connexions adb à une machine hôte via Wi-Fi ou Ethernet, et comprend au moins une caméra:

    • [C-5-1] DOIT comporter la méthode AdbManager#isAdbWifiQrSupported() renvoient true.

  • Service Dalvik Debug Monitor (ddms)

    • [C-0-7] DOIT prendre en charge toutes les fonctionnalités ddms décrites dans le SDK Android. Comme ddms utilise adb, la prise en charge de ddms DOIT être inactive par défaut, mais DOIT être pris en charge chaque fois que l'utilisateur a activé Android Debug Bridge, comme indiqué ci-dessus.

  • SysTrace

    • [C-0-9] DOIT prendre en charge l'outil Systrace, comme indiqué dans le SDK Android. Systrace doit être inactif par défaut et il DOIT y avoir une couche accessible par l'utilisateur pour activer Systrace.

  • Perfetto

    • [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'exposer un /system/bin/perfetto binaire à l'utilisateur shell auquel la cmdline est conforme la documentation perfetto.
    • [C-SR-2] Il est FORTEMENT RECOMMANDÉ d'accepter le binaire Perfetto en tant qu'entrée configuration protobuf conforme au schéma défini dans la documentation perfetto.
    • [C-SR-3] Il est FORTEMENT RECOMMANDÉ d'écrire le binaire Perfetto sous forme de sortie trace protobuf conforme au schéma défini dans la documentation perfetto.
    • [C-SR-4] Il est FORTEMENT RECOMMANDÉ de fournir, via le binaire Perfetto, au moins les sources de données décrites dans la documentation de Perfetto.

  • Tueur de mémoire faible

    • [C-0-12] DOIT écrire un code Atom LMK_KILL_OCCURRED_FIELD_NUMBER dans le journal statsd lorsqu'une application est arrêtée par le tueur de mémoire faible.

  • Tester le mode Harness Si les implémentations de l'appareil sont compatibles avec la commande shell cmd testharness et s'exécute cmd testharness enable, il:

  • Informations sur les GPU

    Implémentations pour les appareils:

    • [C-0-13] DOIT implémenter la commande shell dumpsys gpu --gpuwork pour afficher les données de travail GPU agrégées renvoyées par le noyau power/gpu_work_period tracepoint ou n'affiche aucune donnée si le point de trace n'est pas pris en charge. L'AOSP l'implémentation est frameworks/native/services/gpuservice/gpuwork/.

Si les implémentations d'appareils indiquent la prise en charge de Vulkan 1.0 ou version ultérieure via le android.hardware.vulkan.version indicateurs de fonctionnalité:

  • [C-1-1] DOIT fournir une affordance aux développeurs d'applications pour pouvoir activer/désactiver Couches de débogage GPU
  • [C-1-2] DOIT énumérer les couches de débogage GPU dans des bibliothèques fournies par des outils externes (c'est-à-dire qui ne font pas partie de la plate-forme ni package d'application) détecté dans les applications débogables le répertoire de base en acceptent vkEnumerateInstanceLayerProperties(). et vkCreateInstance() méthodes d'API Google Cloud.

6.2. Options pour les développeurs

Android permet aux développeurs de configurer des applications liés au développement.

Les implémentations d'appareils DOIVENT fournir une expérience cohérente pour Options pour les développeurs:

  • [C-0-1] DOIT respecter les android.settings.APPLICATION_DEVELOPMENT_SETTINGS pour afficher les paramètres liés au développement d'applications. L'application Android en amont masque le menu Options du développeur par défaut et permet aux utilisateurs de lancer les Options pour les développeurs après avoir appuyé sept (7) fois dans la section Paramètres > À propos de l'appareil > Élément de menu Build Number (Numéro de version).
  • [C-0-2] DOIT masquer les options pour les développeurs par défaut.
  • [C-0-3] DOIT fournir un mécanisme clair qui n'accorde pas de à une application tierce plutôt qu'à une autre pour permettre aux développeurs Options. DOIT fournir un document ou un site Web visible par le public expliquant comment activer les Options pour les développeurs. Ce document ou ce site Web DOIT pouvoir être référencé sous forme de lien depuis les documents du SDK Android.
  • DEVRAIT avoir une notification visuelle continue à l'utilisateur lorsque le développeur Les options sont activées, et la sécurité de l'utilisateur est préoccupante.
  • PEUVENT limiter temporairement l'accès au menu d'options pour les développeurs, en en masquant ou en désactivant le menu, afin d'éviter toute distraction dans les cas où le la sécurité de l'utilisateur se préoccupe.

7. Compatibilité matérielle

Si un appareil inclut un composant matériel particulier qui a un API pour les développeurs tiers:

  • [C-0-1] La mise en œuvre de l'appareil DOIT mettre en œuvre ce comme décrit dans la documentation du SDK Android.

Si une API du SDK interagit avec un composant matériel qui est désigné comme facultatif et la mise en œuvre sur l'appareil ne possède pas ce composant:

  • [C-0-2] Définitions de classe complètes (telles que documentées par le SDK) pour le composant Les API DOIVENT encore être présentées.
  • [C-0-3] Les comportements de l'API DOIVENT être implémentés en tant que no-ops de manière raisonnable mode.
  • [C-0-4] Les méthodes API DOIVENT renvoyer des valeurs nulles lorsque le SDK le permet dans la documentation Google Cloud.
  • [C-0-5] Les méthodes API DOIVENT renvoyer des implémentations no-op de classes dans lesquelles des valeurs nulles ne sont pas autorisés par la documentation sur les SDK.
  • [C-0-6] Les méthodes API NE DOIVENT PAS générer d'exceptions non documentées par le SDK dans la documentation Google Cloud.
  • [C-0-7] Les implémentations d'appareils DOIVENT indiquer de manière cohérente la fiabilité du matériel les informations de configuration via getSystemAvailableFeatures() et hasSystemFeature(String) sur le android.content.pm.PackageManager pour la même empreinte de build.

Un exemple type de scénario dans lequel ces exigences s'appliquent est le service API: même sur les appareils autres que des téléphones, la mise en œuvre de ces API doit être raisonnable no-ops.

7.1. Écran et graphismes

Android inclut des fonctionnalités qui ajustent automatiquement les éléments et l'UI de l'application. adaptées à l'appareil pour garantir que les applications tierces fonctionnent correctement sur différentes configurations matérielles. une variété d'écrans et de configurations matérielles. Une Les écrans compatibles Android sont des écrans qui implémentent toutes les et les API décrits sur la page Développeurs Android : compatibilité des écrans présentation, ce (7.1) et ses sous-sections, ainsi que tout type d'appareil supplémentaire comportements spécifiques décrits à la section 2 CDD. Sur les écrans compatibles Android sur lesquels tous les appareils peuvent fonctionner, les implémentations d'appareils DOIVENT implémenter ces API correctement et les comportements, comme détaillé dans cette section.

Commencer les nouvelles exigences

Implémentations pour les appareils:

  • [C-0-1] DOIT, par défaut, afficher les applications tierces uniquement sur les écrans compatibles avec Android ;

Mettre fin aux nouvelles exigences

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

  • taille physique en diagonale. La distance en pouces entre deux deux opposés les coins de la partie éclairée de l'écran.
  • densité de points par pouce (ppp). Nombre de pixels entourés par un tracé linéaire. étendue horizontale ou verticale de 1 pouce, exprimée en pixels par pouce (ppp ou dpi). Où dpi ppi et dpi sont répertoriées, les dpi horizontal et vertical doivent se situer dans la liste la plage d'adresses IP.
  • format. Le rapport entre les pixels de la dimension la plus longue et une plus courte dimension de l’écran. Par exemple, un écran de 480 x 854 pixels 854/480 = 1,779, soit environ "16:9".
  • pixel indépendant de la densité (dp). Une unité de pixel virtuel normalisé en écran de 160 ppp d'une densité d'écran de 160. Pour une densité d et un nombre le nombre de pixels indépendants de la densité (dp) est calculé comme suit: pixels = dps * (densité/160) dp = (160 / d) * p .

7.1.1. Configuration de l'écran

Taille et forme de l'écran

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

Implémentations pour les appareils:

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

    • Appareils pour lesquels Configuration.uiMode est défini sur une valeur autre que UI_MODE_TYPE_WATCH et une taille de small pour la Configuration.screenLayout, DOIT mesurer au moins 426 dp x 320 dp.
    • Appareils indiquant une taille de normal pour le Configuration.screenLayout DOIT être d'au moins 480 dp x 320 dp.
    • Appareils indiquant une taille de large pour le Configuration.screenLayout DOIT comporter au moins 640 dp x 480 dp.
    • Appareils indiquant une taille de xlarge pour le Configuration.screenLayout DOIT être d'au moins 960 dp x 720 dp.

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

  • PEUVENT disposer d'un ou plusieurs écrans compatibles avec Android aux angles arrondis.

Si les implémentations d'appareils sont compatibles avec les écrans compatibles UI_MODE_TYPE_NORMAL configuration de la taille et inclure des produits compatibles avec Android utiliser un ou plusieurs écrans physiques avec coins arrondis pour afficher ces écrans, ils:

  • [C-1-1] DOIT s'assurer qu'au moins l'une des exigences suivantes est satisfaite pour chacun de ces affichages:

    • Le rayon des angles arrondis est inférieur ou égal à 38 dp.
    • Quand un 15un 18 dp de 1518 la boîte dp est ancrée à chaque angle de l'écran logique, au moins une pixel de chaque boîte est visible à l'écran.

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

Commencer les nouvelles exigences

Si les implémentations d'appareils ne permettent qu'une configuration de clavier NO_KEYS, et ont l'intention de signaler la prise en charge du mode d'interface utilisateur UI_MODE_TYPE_NORMAL configuration, ils:

  • [C-4-1] DOIT avoir une taille de mise en page (hors encoches) d'au moins 596 dp x 384 dp ou plus

Mettre fin aux nouvelles exigences

Si les implémentations d'appareils incluent un ou plusieurs écrans compatibles Android qui sont d'écran pliable, ou comporte une charnière pliable entre plusieurs écrans les écrans disponibles pour le rendu d'applications tierces:

Si les implémentations d'appareils incluent un ou plusieurs écrans compatibles Android qui sont ou qu'il comporte une charnière pliable entre plusieurs écrans. que la charnière ou le pli traverse une fenêtre d'application en plein écran, ils:

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

Pour savoir comment implémenter correctement les API side-car ou d'extension, consultez à la documentation publique de Window Manager Jetpack.

Commencer les nouvelles exigences

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

  • [C-4-1] DOIT implémenter la version correcte des extensions du gestionnaire de fenêtres Niveau d'API décrit dans la section Extensions WindowManager.

Mettre fin aux nouvelles exigences

Format de l'écran

Bien qu'il n'y ait aucune restriction concernant le format de l'écran physique pour Le ou les écrans compatibles avec Android, ainsi que le format de l'écran logique d'affichage des applications tierces. Cette valeur est déterminée en fonction de la hauteur les valeurs de largeur indiquées via le view.Display API et configuration API, DOIT respecter les exigences suivantes:

  • [C-0-1] Implémentations d'appareils avec Configuration.uiMode défini sur UI_MODE_TYPE_NORMAL DOIT avoir un format inférieur ou égal à à 1.86 (environ 16:9), à moins que l'application ne réponde à l'un des critères suivants conditions:

    • L'appli a déclaré qu'elle était compatible avec un format d'écran plus grand via le android.max_aspect valeur de métadonnées.
    • L'application déclare qu'elle est redimensionnable via android:resizeableActivity .
    • L'application cible le niveau d'API 24 ou supérieur et ne déclare pas de android:maxAspectRatio qui limiterait le format autorisé.

  • [C-0-3] Implémentations d'appareils avec Configuration.uiMode défini sur Le format de UI_MODE_TYPE_WATCH DOIT être défini sur 1.0 (1:1).

Densité d'écran

Le framework d'UI Android définit un ensemble de densités logiques standards pour vous aider les développeurs d'applications ciblent les ressources d'application.

Implémentations des appareils:

  • [C-0-1] Par défaut, les implémentations sur les appareils DOIT signaler uniquement l'un des éléments Densités du framework Android répertoriées DisplayMetrics via l'API DENSITY_DEVICE_STABLE Cette valeur doit être une valeur statique pour chaque écran physique. NE DOIT PAS changer à aucun moment ; Toutefois, Toutefois, il peut s'agir signaler une densité arbitraire différente DisplayMetrics.density en fonction des modifications apportées à la configuration d'affichage par l'utilisateur (par (par exemple, la taille d'affichage) définie après le démarrage initial.

  • Les implémentations d'appareils DOIVENT définir la densité standard du framework Android numériquement la plus proche de la densité physique de l'écran, sauf si pousse la taille d'écran signalée en dessous de la densité minimale prise en charge. Si la densité du framework Android standard la plus proche numériquement la densité physique se traduit par une taille d’écran plus petite que la plus petite taille d'écran compatible (320 dp), implémentations d'appareils DEVRAIT indiquent la deuxième densité de framework Android standard la plus basse.

Commencer les nouvelles exigences

  • DEVRAIT définir la densité du framework Android standard sous forme numérique la plus proche de la densité physique de l'écran, ou d'une valeur correspondant les mêmes mesures de champ de vision angulaires équivalentes à celles d'un appareil portable.

Mettre fin aux nouvelles exigences

Si les intégrations d'appareils permettent il y a une affordance modifier la taille d'affichage de l'appareil, qui:

  • [C-1-1] La taille d'affichage NE DOIT PAS être mise à l'échelle NE DOIT PAS mettre à l'échelle l'écran plus de 1,5 fois la DENSITY_DEVICE_STABLE densité native ou produisent une dimension d'écran minimale efficace inférieure à 320 dp (équivalent au qualificatif de ressource sw320dp), selon la première échéance atteinte.
  • [C-1-2] La taille de l'écran NE DOIT PAS être mise à l'échelle NE DOIT PAS mettre à l'échelle l'écran inférieure à 0,85 fois la densité native de DENSITY_DEVICE_STABLE.
  • Pour garantir la facilité d'utilisation et la cohérence des tailles de police, il est RECOMMANDÉ que que les options d'annonces display natives soient adaptées (tout en respectant les limites comme indiqué ci-dessus)
    • S: x 0,85
    • Par défaut: 1x (échelle d'affichage natif)
    • Grande: x 1,15
    • Plus grande: x1,3
    • Plus grande x 1,45

Métriques sur le Réseau Display

Si les implémentations d'appareils incluent un ou plusieurs écrans compatibles Android ou sur un ou plusieurs écrans compatibles Android:

  • [C-1-1] DOIT indiquer des valeurs correctes pour tous les écrans compatibles avec Android les métriques définies dans API android.util.DisplayMetrics.

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

  • [C-2-1] DOIT indiquer les valeurs correctes de l'écran compatible Android comme défini dans l'API android.util.DisplayMetrics pour le view.Display par défaut émulé.

7.1.3. Orientation de l'écran

Implémentations pour les appareils:

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

Si les implémentations d'appareils sont compatibles avec les deux orientations d'écran:

  • [C-1-1] DOIT prendre en charge l'orientation dynamique des applications sur un écran en mode portrait ou paysage. l'orientation. Autrement dit, l'appareil doit respecter la requête de l'application pour un écran spécifique. l'orientation.
  • [C-1-2] NE DOIT PAS modifier la taille ni la densité d'écran indiquées lors du changement d'orientation.
  • PEUT sélectionner l'orientation portrait ou paysage par défaut.

Accélération graphique 2D et 3D

7.1.4.1 OpenGL ES

Implémentations pour les appareils:

  • [C-0-1] DOIT identifier correctement les versions d'OpenGL ES compatibles (1.1, 2.0, 3.0, 3.1, 3.2) via les API gérées (par exemple, via le GLES10.getString()) et les API natives.
  • [C-0-2] DOIT inclure la prise en charge de toutes les API gérées correspondantes et des API natives pour chaque version d'OpenGL ES qu'elle a jugée compatible.

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

  • [C-1-1] DOIT être compatible avec OpenGL ES 1.1 et 2.0, tels qu'ils sont incarnés et détaillés dans la documentation du SDK Android.
  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge OpenGL ES 3.1.
  • DEVRAIT prendre en charge OpenGL ES 3.2.

Les tests dEQP d'OpenGL ES sont divisés en plusieurs listes de test, chacune avec une date/un numéro de version associé. Ils se trouvent dans l'arborescence source Android, à l'adresse external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt Un appareil qui "Compatible avec OpenGL ES". Selon les auto-déclarations, il est possible de transmettre le dEQP. dans toutes les listes de test à partir de ce niveau.

Si les implémentations d'appareils sont compatibles avec l'une des versions d'OpenGL ES, celles-ci:

  • [C-2-1] DOIT générer des rapports via les API gérées et les API natives d'OpenGL ES autres extensions OpenGL ES qu'ils ont implémentées, et DOIVENT IMPÉRATIVEMENT NE signalent PAS les chaînes d'extension qu'ils ne prennent pas en charge.
  • [C-2-2] DOIT prendre en charge les éléments EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable et EGL_ANDROID_GLES_layers extensions.
  • [C-2-3] DOIT indiquer la version maximale des tests dEQP d'OpenGL ES compatible avec le flag de fonctionnalité android.software.opengles.deqp.level.
  • [C-2-4] DOIT prendre en charge au moins la version 132383489 (à partir du 1er mars 2020), signalé dans le flag de fonctionnalité android.software.opengles.deqp.level.
  • [C-2-5] DOIT réussir tous les tests dEQP d'OpenGL ES dans les listes de tests entre les versions 132383489 et la version spécifiée dans le Indicateur de fonctionnalité android.software.opengles.deqp.level pour chaque option compatible Version d'OpenGL ES.
  • [C-SR-2] Sont FORTEMENT RECOMMANDÉS de prendre en charge les EGL_KHR_partial_update et Extensions OES_EGL_image_external.

  • DEVRAIT générer un rapport précis via la méthode getString(), toute texture format de compression pris en charge, qui est généralement propre au fournisseur.

  • DEVRAIT prendre en charge EGL_IMG_context_priority et Extensions EGL_EXT_protected_content.

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

  • [C-3-1] DOIT exporter les symboles de fonction correspondants à cette version dans en plus des symboles de fonction OpenGL ES 2.0 de la bibliothèque libGLESv2.so.
  • [C-SR-3] SONT FORTEMENT RECOMMANDÉS de soutenir OES_EGL_image_external_essl3 .

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

  • [C-4-1] DOIT prendre en charge le pack d'extensions Android OpenGL ES dans son intégralité.

Si les implémentations d'appareils sont compatibles avec le pack d'extensions Android OpenGL ES dans ses dans son intégralité:

  • [C-5-1] DOIT identifier l'assistance via l'android.hardware.opengles.aep flag de fonctionnalité.

Si les implémentations d'appareils exposent la compatibilité avec EGL_KHR_mutable_render_buffer extension, ils:

  • [C-6-1] DOIT également prendre en charge le protocole EGL_ANDROID_front_buffer_auto_refresh .
7.1.4.2 Vulkan

Android est compatible avec Vulkan. , une API multiplate-forme simple pour des graphismes 3D hautes performances.

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

  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure la prise en charge des Vulkan 1.3.
  • [C-4-1] NE DOIT PAS prendre en charge une version de variante Vulkan (la variante de la version principale de Vulkan DOIT être égale à zéro).

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

  • [C-SR-2] Il est FORTEMENT RECOMMANDÉ d'inclure la prise en charge des Vulkan 1.3.

Les tests dEQP de Vulkan sont partitionnés en plusieurs listes de test, chacune avec une la date et la version associées. Ils se trouvent dans l'arborescence source Android, à l'adresse external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt Un appareil qui Prise en charge de Vulkan à un niveau auto-déclaré indique qu'il peut transmettre le dEQP dans toutes les listes de test à partir de ce niveau.

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

  • [C-1-1] DOIT indiquer la valeur entière correcte avec le paramètre android.hardware.vulkan.level et android.hardware.vulkan.version et les flags de fonctionnalité.
  • [C-1-2] DOIT énumérer au moins un élément VkPhysicalDevice pour Vulkan API native vkEnumeratePhysicalDevices().
  • [C-1-3] DOIT implémenter intégralement Vulkan 1.0 Vulkan 1.1 pour chaque liste énumérée VkPhysicalDevice
  • [C-1-4] DOIT énumérer les calques contenus dans les bibliothèques natives portant le nom libVkLayer*.so dans le répertoire de bibliothèque natif du package d'application via les API natives Vulkan vkEnumerateInstanceLayerProperties() et vkEnumerateDeviceLayerProperties().
  • [C-1-5] NE DOIT PAS énumérer les couches fournies par les bibliothèques situées en dehors de package d'application, ni proposer d'autres moyens de tracer ou d'intercepter API Vulkan, sauf si l'application possède l'attribut android:debuggable défini sur true ou sur la métadonnée com.android.graphics.injectLayers.enable définie sur true .
  • [C-1-6] DOIT indiquer toutes les chaînes d'extension qu'ils prennent en charge via l'attribut Les API natives Vulkan, et, à l'inverse, NE DOIVENT PAS signaler les chaînes d'extension qu'ils ne prennent pas correctement en charge.
  • [C-1-7] DOIT prendre en charge la surface VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain et VK_KHR_incremental_present.
  • [C-1-8] DOIT indiquer la version maximale des tests Vulkan dEQP compatible avec le flag de fonctionnalité android.software.vulkan.deqp.level.
  • [C-1-9] DOIT prendre en charge au moins la version 132317953 (à partir du 1er mars 2019), indiqué dans le flag de fonctionnalité android.software.vulkan.deqp.level.
  • [C-1-10] DOIT réussir tous les tests dEQP Vulkan dans les listes de tests entre version 132317953 et la version spécifiée dans le Indicateur de fonctionnalité android.software.vulkan.deqp.level.
  • [C-1-11] NE DOIT PAS énumérer la compatibilité avec la file d'attente "VK_KHR_video_queue", VK_KHR_video_decode_queue ou VK_KHR_video_encode_queue.
  • [C-SR-3] SONT FORTEMENT RECOMMANDÉS de soutenir VK_KHR_driver_properties et les extensions VK_GOOGLE_display_timing.

  • DEVRAIT prendre en charge VkPhysicalDeviceProtectedMemoryFeatures et VK_EXT_global_priority

  • [C-1-12] NE DOIT PAS énumérer la compatibilité avec l'extension VK_KHR_performance_query.

Commencer les nouvelles exigences

  • [C-SR-5] SONT FORTEMENT RECOMMANDÉS de soutenir VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory et VK_EXT_global_priority.

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

Mettre fin aux nouvelles exigences

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

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

Si les implémentations d'appareils sont compatibles avec Vulkan 1.1 et déclarez l'un des Les indicateurs de fonctionnalité Vulkan décrits ici , ils:

  • [C-3-1] DOIT exposer la prise en charge du sémaphore et du handle externes SYNC_FD et l'extension VK_ANDROID_external_memory_android_hardware_buffer.

Commencer les nouvelles exigences

  • [C-SR-7] Il est FORTEMENT RECOMMANDÉ de rendre les VK_KHR_external_fence_fd est disponible pour les applications tierces et active l'application pour exporter la charge utile de cloisonnement et l'importer à partir du fichier POSIX de description, cliquez ici.

Mettre fin aux nouvelles exigences

7.1.4.3 RenderScript
  • [C-0-1] Les implémentations d'appareils DOIVENT prendre en charge Android RenderScript, comme expliqué dans la documentation du SDK Android.
7.1.4.4 Accélération graphique 2D

Android inclut un mécanisme permettant aux applications de déclarer qu'elles veulent activer l'accélération matérielle pour les graphismes 2D au niveau de l'application, de l'activité, Fenêtre ou au niveau de la vue via l'utilisation d'une balise de fichier manifeste android:hardwareAccelerated ou des appels d'API directs.

Implémentations pour les appareils:

  • [C-0-1] DOIT activer l'accélération matérielle par défaut et DOIT activer désactiver l'accélération matérielle si le développeur le demande en définissant android:hardwareAccelerated="false" ou désactivation de l'accélération matérielle directement via les API Android View.
  • [C-0-2] DOIT présenter un comportement conforme aux Documentation du SDK Android sur l'accélération matérielle

Android inclut un objet TextureView qui permet aux développeurs d'intégrer directement textures OpenGL ES avec accélération matérielle en tant que cibles de rendu dans une hiérarchie d'interface utilisateur.

Implémentations pour les appareils:

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

Si les implémentations d'appareils revendiquent la compatibilité avec les écrans larges via Configuration.isScreenWideColorGamut() , ils:

  • [C-1-1] DOIT disposer d'un écran calibré pour les couleurs.
  • [C-1-2] DOIT disposer d'un écran dont la gamme couvre la gamme de couleurs sRVB entièrement dans l'espace xyY de la CIE de 1931.
  • [C-1-3] DOIT disposer d'un écran dont la surface couvre au moins 90% des DCI-P3 dans un espace xyY CIE de 1931.
  • [C-1-4] DOIT être compatible avec OpenGL ES 3.1 ou 3.2 et les signaler correctement.
  • [C-1-5] DOIT faire la promotion de EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear, et EGL_EXT_gl_colorspace_display_p3_passthrough .
  • [C-SR-1] EST VIVEMENT RECOMMANDÉ d'utiliser GL_EXT_sRGB.

À l'inverse, si les implémentations d'appareils ne sont pas compatibles avec les écrans larges, ils:

  • [C-2-1] DEVRAIT couvrir 100% ou plus du format sRVB dans l'espace xyY de la CIE 1931, bien que la gamme de couleurs de l'écran n'est pas définie.

Mode de compatibilité des anciennes applications

Android spécifie un "mode de compatibilité" dans lequel le framework fonctionne dans un 'normal' mode de taille d'écran équivalente (320 dp) pour profiter des avantages applications non développées pour les anciennes versions d'Android une indépendance par rapport à la taille de l'écran.

Technologie d'écran

La plate-forme Android inclut des API qui permettent aux applications de s'enrichir sur un écran compatible Android. Les appareils DOIVENT être compatibles avec tous ces telles que définies par le SDK Android, sauf autorisation spécifique stipulée dans le présent document.

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

  • [C-0-1] DOIT être capable d'afficher des images en couleurs 16 bits.
  • DEVRAIT prendre en charge les écrans compatibles avec des graphismes en couleurs 24 bits.
  • [C-0-2] DOIT être capable d'afficher des animations.
  • [C-0-3] DOIT avoir un format de pixel (PAR) compris entre 0,9 et 1,15. Autrement dit, le format de pixel DOIT être proche du carré (1,0) avec une tolérance de 10 à 15 %.

Écrans secondaires

Android prend en charge les écrans secondaires compatibles Android pour activer de partage multimédia et des API de développement pour accéder à des écrans externes.

Si les implémentations d'appareils prennent en charge un écran externe via un câble, sans fil ou d'une connexion d'affichage supplémentaire intégrée, ils:

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

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

Implémentations pour les appareils:

7.2.1. Clavier

Si les implémentations d'appareils incluent la compatibilité les applications d'éditeur de mode de saisie (IME) :

Implémentations pour les appareils:

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

7.2.2. Navigation non tactile

Android prend en charge le pavé directionnel, le trackball et la molette comme mécanismes pour la navigation non tactile.

Implémentations pour les appareils:

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

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

7.2.3. Touches de navigation

La page Accueil, Récents, et Retour fonctions généralement fournies par une interaction avec un bouton physique dédié ou une partie distincte de l'écran tactile, sont essentiels pour de navigation et, par conséquent, les implémentations d'appareils:

  • [C-0-1] DOIT fournir une affordance utilisateur pour lancer les applications installées comportant une activité dont le <intent-filter> est défini sur ACTION=MAIN et CATEGORY=LAUNCHER ou CATEGORY=LEANBACK_LAUNCHER pour un téléviseur mises en œuvre. La fonction Accueil DOIT être le mécanisme de cette affordance utilisateur.
  • DEVRAIT fournir des boutons pour les fonctions "Récents" et "Retour".

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

  • [C-1-1] DOIT être accessible en une seule action (appuyer, double-cliquer, geste) lorsque l'un d'entre eux est accessible.
  • [C-1-2] DOIT indiquer clairement quelle action unique déclencherait chaque fonction. Une icône visible est imprimée sur le bouton, indiquant qu’un logiciel dans la barre de navigation de l'écran ou guider l'utilisateur à travers une étape par étape de la procédure de démonstration lors de la configuration prête à l'emploi sont des exemples de ce type d'indications.

Implémentations pour les appareils:

  • [C-SR-1] est FORTEMENT RECOMMANDÉ de ne pas fournir de mécanisme d'entrée pour Fonction de menu car elle a été abandonnée au profit de la barre d'action depuis Android 4.0.

  • [C-SR-2] Il est FORTEMENT RECOMMANDÉ de fournir toutes les fonctions de navigation pouvant être annulées. 'Annulable' se définit comme la capacité de l'utilisateur à empêcher d'exécution (par exemple, retour à l'accueil, retour en arrière, etc.) le balayage n'est pas relâché au-delà d'un certain seuil.

Si les implémentations d'appareils intègrent la fonction Menu, celles-ci:

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

Si les implémentations d'appareils ne fournissent pas la fonction Menu, pour les étapes précédentes la compatibilité, ils:

  • [C-3-1] DOIT mettre la fonction Menu à la disposition des applications targetSdkVersion est inférieur à 10, soit pour un bouton physique, soit pour une clé logicielle ou des gestes. Cette fonction Menu doit être accessible, sauf si elle est masquée avec d'autres fonctions de navigation.

Si la fonction d'assistance est disponible dans les implémentations d'appareils, ils:

  • [C-4-1] DOIT rendre la fonction Assist accessible en une seule action (appuyer, double-cliquer ou faire un geste, par exemple) lorsque d'autres touches de navigation sont accessibles.
  • [C-SR-3] FORTEMENT RECOMMANDÉ d'utiliser un appui prolongé sur la fonction HOME, une interaction désignée.

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

  • [C-5-1] Les touches de navigation DOIVENT utiliser une partie distincte de l'écran, et non disponibles pour les applications, et NE DOIVENT PAS masquer ni perturber la partie de l'écran disponible pour les applications.
  • [C-5-2] DOIT mettre une partie de l'écran à la disposition des applications respecte les exigences définies dans la section 7.1.1 ;
  • [C-5-3] DOIT respecter les indicateurs définis par l'application via le View.setSystemUiVisibility() méthode API afin que cette partie distincte de l'écran (la barre de navigation) est correctement masquée, comme indiqué dans le SDK.

Si la fonction de navigation est fournie sous la forme d'une action à l'écran basée sur un geste:

Si une fonction de navigation est fournie depuis n'importe quel emplacement sur les bords gauche et droit de l'orientation actuelle de l'écran:

  • [C-7-1] La fonction de navigation DOIT être "Retour" et être fournie sous forme de faites glisser votre doigt à partir des bords gauche et droit de l'orientation actuelle l'écran.
  • [C-7-2] Si des panneaux système personnalisés à faire glisser sont fournis sur la gauche ou bord droit, ils DOIVENT être placés dans le tiers supérieur de l'écran une indication visuelle claire et persistante que le fait de glisser entraînerait l'appel aux panneaux susmentionnés, et donc pas Retour. Un panneau système PEUT être configuré par un utilisateur de sorte qu'il s'affiche en dessous du tiers supérieur de l'écran mais le panneau système NE DOIT PAS utiliser plus d'un tiers de ces bords.
  • [C-7-3] Lorsque l'application au premier plan dispose de l'élément View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT ou WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE définis. le balayage depuis les bords DOIT se comporter comme implémenté dans AOSP, ce qui décrites dans le SDK.
  • [C-7-4] Lorsque l'application au premier plan dispose de l'élément View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT ou WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE définis. les panneaux système à faire glisser personnalisés DOIVENT être masqués jusqu'à ce que l'utilisateur y introduise ou annule la luminosité des barres système (barre de navigation et d'état) tel que implémenté dans AOSP.

Si la fonction de navigation vers l'arrière est fournie et que l'utilisateur annule le retour arrière geste, puis:

  • [C-8-1] OnBackInvokedCallback.onBackCancelled() DOIT être appelé.
  • [C-8-2] OnBackInvokedCallback.onBackInvoked() NE DOIT PAS être appelé.
  • [C-8-3] L'événement KEYCODE_BACK NE DOIT PAS être envoyé.

Si la fonction de navigation vers l'arrière est fournie, mais que l'application de premier plan l'est N'avez PAS de OnBackInvokedCallback enregistré, alors:

  • Le système DOIT fournir une animation pour l'application de premier plan qui suggère que l'utilisateur revient en arrière, comme indiqué dans AOSP.

Si les implémentations d'appareils prennent en charge l'API système setNavBarMode pour autoriser toute application système disposant de l'autorisation android.permission.STATUS_BAR à définir barre de navigation, ils:

  • [C-9-1] DOIT prendre en charge les icônes adaptées aux enfants ou les boutons basés sur des boutons comme indiqué dans le code AOSP.

7.2.4. Saisie par écran tactile

Android est compatible avec divers systèmes d'entrée de pointeur, tels que les écrans tactiles, les pavés tactiles et les faux périphériques de saisie tactile. Implémentations des appareils à écran tactile sont associés à un écran de sorte que l'utilisateur ait l'impression en manipulant des éléments à l'écran. Étant donné que l'utilisateur touche directement l'écran, le système ne nécessite aucune affordance supplémentaire pour indiquer les objets manipulé.

Implémentations pour les appareils:

  • DEVRAIT disposer d'un système d'entrée de pointeur (comme une souris ou un écran tactile).
  • DEVRAIT prendre en charge les pointeurs suivis de manière totalement indépendante.

Si les implémentations d'appareils comprennent un écran tactile (simple ou mieux) sur un principal compatible avec Android:

  • [C-1-1] DOIT signaler TOUCHSCREEN_FINGER pour Configuration.touchscreen API.
  • [C-1-2] DOIT signaler l'erreur android.hardware.touchscreen et Indicateurs de fonctionnalité android.hardware.faketouch.

Si les implémentations des appareils comprennent un écran tactile capable de suivre plus de d'un simple geste sur un écran principal compatible avec Android:

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

Si les implémentations de périphériques reposent sur un périphérique d'entrée externe tel qu'une souris ou la trackball (c'est-à-dire si elle ne touche pas directement l'écran) pour l'entrée un écran compatible avec Android et répondre aux exigences de l'écran tactile simulé section 7.2.5, elles:

  • [C-3-1] NE DOIT PAS signaler de drapeau de fonctionnalité commençant par android.hardware.touchscreen
  • [C-3-2] DOIT signaler uniquement android.hardware.faketouch.
  • [C-3-3] DOIT indiquer TOUCHSCREEN_NOTOUCH pour le champ Configuration.touchscreen API.

Saisie tactile simulée

L'interface tactile simulée fournit un système de saisie utilisateur qui se rapproche d'un sous-ensemble de l'écran tactile. Par exemple, une souris ou une télécommande qui entraîne Un curseur à l'écran ressemble à un toucher tactile, mais l'utilisateur doit d'abord pointer ou sélectionner, puis cliquer. De nombreux périphériques d'entrée tels que la souris, le pavé tactile et le gyroscope la souris, le gyroscope, le joystick et le pavé tactile multipoint peuvent prendre en charge des interactions tactiles. Android inclut la constante de fonctionnalité android.hardware.faketouch, qui correspond à une image non tactile haute fidélité (basé sur un pointeur), comme une souris ou un pavé tactile, qui peut émule la saisie tactile (y compris la prise en charge des gestes de base) et indique que l'appareil prend en charge un sous-ensemble émulé de fonctionnalités tactiles.

Si les implémentations d'appareils n'incluent pas d'écran tactile, mais en incluent un autre qu'elle souhaite mettre à disposition, elle:

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

Si les implémentations d'appareils déclarent la prise en charge de android.hardware.faketouch, ils:

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

Si les implémentations d'appareils déclarent prendre en charge android.hardware.faketouch.multitouch.distinct:

  • [C-2-1] DOIT déclarer la prise en charge de android.hardware.faketouch.
  • [C-2-2] DOIT prendre en charge le suivi distinct d'au moins deux pointeurs indépendants d'entrée.

Si les implémentations d'appareils déclarent prendre en charge android.hardware.faketouch.multitouch.jazzhand:

  • [C-3-1] DOIT déclarer la prise en charge de android.hardware.faketouch.
  • [C-3-2] DOIT prendre en charge le suivi distinct de 5 (suivi d'une main des doigts) ou plus d'entrées de pointeur indépendamment.

Compatibilité avec les manettes de jeu

Mappages de boutons

Implémentations pour les appareils:

  • [C-1-1] DOIT être capable de mapper les événements HID aux constantes InputEvent correspondantes, comme indiqué dans les tableaux ci-dessous. L'implémentation Android en amont répond à cette exigence.

Si les implémentations d'appareils intègrent une manette ou sont livrées avec une manette distincte dans la boîte permettant de saisir tous les événements listés dans les tableaux ci-dessous, elles:

  • [C-2-1] DOIT déclarer le flag de fonctionnalité android.hardware.gamepad
Bouton Utilisation HID2 Bouton Android
A1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B1 0 x 09, 0 x 0002 KEYCODE_BUTTON_B (97)
X1 0x09 0x0004 KEYCODE_BUTTON_X (99)
O1 0x09 0x0005 KEYCODE_BOUTON_Y (100)
Pavé directionnel dessus1
Pavé directionnel vers le bas1		 0x01 0x00393 AXIS_HAT_Y4
Pavé directionnel gauche1
Pavé directionnel droit1		 0x01 0x00393 AXIS_HAT_X4
Bouton de l'épaule gauche1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
Bouton de l'épaule droite1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
Clic gauche1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
Effectuer un clic avec le stick droit1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
Retour1 0x0c 0x0224 KEYCODE_BACK (4)

1 Événement clé

2 Les utilisations de HID ci-dessus doivent être déclarées dans un Jeu pad CA (0x01 0x0005).

3 Cette utilisation doit avoir un minimum logique de 0, Maximum logique de 7, minimum physique de 0, maximum physique de 315, unités en degrés, et une taille de rapport de 4. La valeur logique est définie comme étant la une rotation dans le sens des aiguilles d'une montre loin de l'axe vertical ; par exemple, une valeur logique de 0 représente l'absence de rotation et l'appui sur le bouton vers le haut, tandis qu'une valeur logique 1 représente une rotation de 45 degrés, et les touches haut et gauche étant est maintenue enfoncée.

4 MotionEvent

Commandes analogiques1 Utilisation HID Bouton Android
Gâchette gauche 0x02, 0x00C5 AXIS_LTRIGGER
Déclencheur droit 0x02, 0x00C4 AXIS_RTRIGGER
Joystick gauche 0x01 0x0030
0 x 01, 0 x 0031		 AXIS_X
AXIS_Y
Joystick droit 0x01 0x0032
0 x 01, 0 x 0035		 AXIS_Z
AXIS_RZ

1 MotionEvent

7.2.7. Télécommande

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

7.3. Capteurs

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

Implémentations pour les appareils:

  • [C-0-1] DOIT signaler avec précision la présence ou l'absence de capteurs conformément aux android.content.pm.PackageManager .
  • [C-0-2] DOIT renvoyer une liste précise des capteurs compatibles via le SensorManager.getSensorList() et des méthodes similaires.
  • [C-0-3] DOIT se comporter de manière raisonnable pour toutes les autres API de détection (par exemple, Affichage de true ou false, selon le cas, lorsque les applications tentent de s'inscrire les écouteurs de capteur, et non lorsqu'ils ne sont pas présent ; etc.).

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

  • [C-1-1] DOIT signaler toutes les mesures des capteurs en utilisant les valeurs du système international d'unités (métriques) pertinentes pour chaque tel que défini dans la documentation du SDK Android.
  • [C-1-2] DOIT transmettre les données de capteurs avec une latence maximale de 100 millisecondes + 2 * sample_time pour le cas d'un flux de capteurs avec latence maximale demandée de 0 ms lorsque le processeur de l'application est actif. Ce délai n'inclut pas les délais de filtrage.
  • [C-1-3] DOIT signaler le premier échantillon du capteur en 400 millisecondes + 2 * sample_time du capteur en cours d'activation. Il est acceptable que cet échantillon ont une justesse de 0.
  • [C-1-4] Pour toute API indiquée dans la documentation du SDK Android comme étant capteur continu, les implémentations d'appareils DOIVENT fournir en permanence échantillons de données périodiques qui DOIVENT présenter une gigue inférieure à 3%, où la gigue est définie comme l'écart type de la différence les valeurs de code temporel entre des événements consécutifs.
  • [C-1-5] DOIT s'assurer que le flux d'événements du capteur NE DOIT PAS empêcher le processeur de l'appareil de passer en mode suspendu ou de se réactiver de l'état "suspendu".
  • [C-1-6] DOIT indiquer l'heure de l'événement en nanosecondes, comme défini dans la documentation du SDK Android, représentant l'heure à laquelle l'événement s'est produit et synchronisé avec Horloge SystemClock.elapsedRealtimeNano().
  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'avoir des erreurs de synchronisation de l'horodatage inférieures à 100 millisecondes, et DOIT comporter une erreur de synchronisation du code temporel inférieure à 1 de l'ordre de la milliseconde.
  • Lorsque plusieurs capteurs sont activés, la consommation d'énergie NE DOIT PAS dépasser la somme de la consommation d'énergie signalée par chaque capteur.

La liste ci-dessus n'est pas exhaustive. le comportement documenté du SDK Android et les documentations Android Open Source sensors doivent être pris en compte faisant autorité.

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

  • [C-1-6] DOIT définir une résolution non nulle pour tous les capteurs et indiquer la valeur via le Sensor.getResolution() .

Certains types de capteurs sont composites, ce qui signifie qu'ils peuvent être dérivés des données fournies par un ou plusieurs autres capteurs. (par exemple, le capteur d'orientation et le capteur d'accélération linéaire).

Implémentations pour les appareils:

  • DEVRAIT mettre en œuvre ces types de capteurs les capteurs physiques prérequis, comme décrit pour les types de capteurs.

Si les implémentations d'appareils incluent un capteur composite, celles-ci:

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

Si les implémentations d'appareils incluent un type de capteur particulier doté d'un l'API correspondante pour les développeurs tiers, et le capteur n'en signale qu'un puis les implémentations d'appareils:

Si les implémentations d'appareils incluent un type de capteur particulier qui prend en charge SensorAdditionalInfo#TYPE_VEC3_CALIBRATION et que le capteur est exposé aux développeurs tiers, ceux-ci:

  • [C-4-1] NE DOIT PAS inclure d'étalonnage fixe défini en usine dans les données fournies.

Si les implémentations d'appareils comprennent une combinaison d'accéléromètres à 3 axes, un d'un gyroscope à trois axes ou d'un magnétomètre, ce sont:

  • [C-SR-2] VIVEMENT RECOMMANDÉ de vérifier que l'accéléromètre, le gyroscope et magnétomètre ont une position relative fixe, de sorte que si l'appareil est transformables (par exemple, pliables), les axes des capteurs restent alignés et cohérents avec le système de coordonnées du capteur de transformation.

7.3.1. Accéléromètre

Implémentations pour les appareils:

  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un accéléromètre à 3 axes.

Si les implémentations d'appareils comprennent un accéléromètre, elles:

  • [C-1-1] DOIT pouvoir signaler des événements avec une fréquence d'au moins 50 Hz.
  • [C-1-3] DOIT respecter le Système de coordonnées des capteurs Android comme indiqué dans les API Android.
  • [C-1-4] DOIT pouvoir mesurer de la chute libre jusqu'à quatre fois gravité(4g) ou plus sur n'importe quel axe.
  • [C-1-5] DOIT avoir une résolution d'au moins 12 bits.
  • [C-1-6] DOIT avoir un écart type inférieur ou égal à 0,05 m/s^, où l'écart type doit être calculé par axe à partir d'échantillons collectées sur une période d'au moins trois secondes au taux d'échantillonnage le plus rapide.
  • DEVRAIT enregistrer des événements dont la fréquence d'actualisation est d'au moins 200 Hz.
  • DEVRAIT avoir une résolution d'au moins 16 bits.
  • DEVRAIT être calibré pendant l'utilisation si les caractéristiques du cycle de vie et des compensations, et préservent les paramètres de compensation entre les redémarrages de l'appareil.
  • DEVRAIT être compensé en température.

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

  • [C-2-1] DOIT implémenter et signaler le capteur TYPE_ACCELEROMETER.
  • [C-SR-4] Il est FORTEMENT RECOMMANDÉ d'implémenter le TYPE_SIGNIFICANT_MOTION d'un capteur composite.
  • [C-SR-5] Il est FORTEMENT RECOMMANDÉ de mettre en œuvre et de créer des rapports Capteur TYPE_ACCELEROMETER_UNCALIBRATED. Les appareils Android sont FORTEMENT RECOMMANDÉ de répondre à cette exigence afin qu'il puisse passer au la prochaine version de la plate-forme, où cela pourrait devenir OBLIGATOIRE.
  • DEVRAIT implémenter TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR et TYPE_STEP_COUNTER les capteurs composites, comme décrit dans le document du SDK Android.

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

  • [C-3-1] DOIT implémenter et signaler le capteur TYPE_ACCELEROMETER_LIMITED_AXES.
  • [C-SR-6] A-TOUT RECOMMANDÉ de procéder à l'implémentation et à la création de rapports Capteur TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

Si les appareils sont équipés d'un accéléromètre à 3 axes et de l'un des TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR Les capteurs composites TYPE_STEP_COUNTER sont implémentés:

  • [C-4-1] La somme de leurs la consommation électrique DOIT toujours être inférieure à 4 mW.
  • DEVRAIT être inférieure à 2 mW et à 0,5 mW lorsque l'appareil est en mode dynamique ou statique.

Si les implémentations d'appareils comprennent un accéléromètre à 3 axes et un capteur de gyroscope à 3 axes, ils:

  • [C-5-1] DOIT implémenter les éléments TYPE_GRAVITY et TYPE_LINEAR_ACCELERATION capteurs composites.
  • [C-SR-7] Il est FORTEMENT RECOMMANDÉ de mettre en œuvre Capteur composite TYPE_GAME_ROTATION_VECTOR.

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

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

7.3.2. Magnétomètre

Implémentations pour les appareils:

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

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

  • [C-1-1] DOIT implémenter le capteur TYPE_MAGNETIC_FIELD.
  • [C-1-2] DOIT pouvoir signaler des événements avec une fréquence d'au moins 10 Hz et DEVRAIT enregistrer des événements dont la fréquence d'actualisation est d'au moins 50 Hz.
  • [C-1-3] DOIT respecter le système de coordonnées du capteur Android comme indiqué dans le API Android.
  • [C-1-4] DOIT pouvoir mesurer entre -900 μT et +900 μT sur chaque avant de saturer.
  • [C-1-5] DOIT avoir une valeur de décalage du fer dur inférieure à 700 μT et DOIT avoir une valeur inférieure à 200 μT, en plaçant le magnétomètre à distance les champs magnétiques dynamiques (induits par le courant) et statiques (induits par l'aimant).
  • [C-1-6] DOIT avoir une résolution égale ou supérieure à 0,6 μT.
  • [C-1-7] DOIT prendre en charge l'étalonnage et la compensation en ligne du fer dur et préservent les paramètres de compensation entre les redémarrages de l'appareil.
  • [C-1-8] DOIT appliquer la compensation du fer doux. Le calibrage peut être pendant l'utilisation ou la production de l'appareil.
  • [C-1-9] DOIT comporter un écart type, calculé par axe, en fonction échantillons collectés sur une période d'au moins trois secondes lors de l'échantillonnage le plus rapide ne doit pas dépasser 1, 5 μT ; DEVRAIT avoir un écart type inférieur à 0,5 μT.
  • [C-1-10] DOIT mettre en œuvre TYPE_MAGNETIC_FIELD_UNCALIBRATED capteur vidéo.

Si les implémentations d'appareils comprennent un magnétomètre à 3 axes, un accéléromètre et un gyroscope à 3 axes, ils:

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

Si les implémentations d'appareils comprennent un magnétomètre à 3 axes (accéléromètre), elles:

  • PEUT implémenter le capteur TYPE_GEOMAGNETIC_ROTATION_VECTOR.

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

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

7.3.3. GPS

Implémentations pour les appareils:

  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un récepteur GPS/GNSS.

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

  • [C-1-1] DOIT prendre en charge les sorties de localisation à une fréquence d'au moins 1 Hz lorsque demandée par LocationManager#requestLocationUpdate.
  • [C-1-2] DOIT pouvoir déterminer la position en ciel ouvert (signaux forts, multi-chemins négligeables, HDOP < 2) en 10 secondes (rapide délai avant la première correction), lorsque vous êtes connecté à un débit de données d'au moins 0,5 Mbit/s de votre connexion Internet. Cette exigence est généralement satisfaite technique de technique GPS/GNSS assistée ou prévue pour minimiser le temps de verrouillage GPS/GNSS (les données d'assistance comprennent le temps de référence, Emplacement de référence et Éphémères du satellite/Horloge).
    • [C-1-6] Après ce calcul de localisation, les mises en œuvre DOIVENT déterminer son emplacement, en ciel ouvert, dans 5 secondes, lorsque les demandes de localisation sont redémarrées, jusqu'à une heure après le calcul initial de l'emplacement, même lorsque la requête suivante est sans connexion de données et/ou après un redémarrage.

  • En ciel ouvert après avoir déterminé la position, lorsque vous êtes à l'arrêt ou se déplacer avec moins de 1 mètre par seconde carré d'accélération:

    • [C-1-3] DOIT pouvoir déterminer la position dans un rayon de 20 mètres et la vitesse à une distance de 0,5 mètre par seconde, au moins 95% du temps.
    • [C-1-4] DOIT suivre et créer simultanément des rapports via GnssStatus.Callback d'au moins huit satellites d'une constellation.
    • DEVRAIT pouvoir suivre simultanément au moins 24 satellites, à partir plusieurs constellations (par exemple, GPS + au moins l'une des images Glonass, Beidou, Galilée).

  • [C-SR-2] EST FORTEMENT RECOMMANDÉ de continuer à fournir un GPS/GNSS normal les résultats de localisation via l'API GNSS Location Provider lors d'un appel d'urgence ; .

  • [C-SR-3] Il est FORTEMENT RECOMMANDÉ de signaler les mesures GNSS de tous les constellations suivies (tel qu'indiqué dans les messages GnssStatus), à l'exception des des SBA.

  • [C-SR-4] Il est FORTEMENT RECOMMANDÉ de signaler les erreurs AGC et la fréquence du GNSS. les mesures.

  • [C-SR-5] Il est FORTEMENT RECOMMANDÉ de signaler toutes les estimations de précision (y compris la direction, la vitesse et la verticale) pour chaque position GPS/GNSS.

  • [C-SR-6] Il est FORTEMENT RECOMMANDÉ de signaler les mesures GNSS dès que même si la position calculée à partir du GPS/GNSS n'est pas encore signalées.

  • [C-SR-7] Il est FORTEMENT RECOMMANDÉ de signaler les pseudo-plages GNSS et de pseudo-plage, qui, dans des conditions de ciel ouvert après avoir déterminé l'emplacement, lorsque vous êtes immobile ou que vous vous déplacez à moins de 0,2 mètre par seconde au carré accélération, sont suffisantes pour calculer la position à 20 mètres près et la vitesse à une distance de 0,2 mètre par seconde, au moins 95% du temps.

7.3.4. Gyroscope

Implémentations pour les appareils:

  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un capteur gyroscope.

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

  • [C-1-1] DOIT pouvoir signaler des événements avec une fréquence d'au moins 50 Hz.
  • [C-1-4] DOIT avoir une résolution de 12 bits ou plus.
  • [C-1-5] DOIT être compensé en température.
  • [C-1-6] DOIT être calibré et compensé en cours d'utilisation, et préserver entre les redémarrages de l'appareil.
  • [C-1-7] DOIT avoir une variance inférieure ou égale à 1e-7 rad^2 / s^2 par Hz (variance par Hz, ou rad^2 / s). La variance peut varier en fonction du d'échantillonnage, mais DOIT être contraint par cette valeur. En d'autres termes, si vous mesurer la variance du gyroscope à un taux d'échantillonnage de 1 Hz, elle DOIT ne pas être supérieure à que 1e-7 rad^2/s^2.
  • [C-SR-2] Il est FORTEMENT RECOMMANDÉ d'indiquer une erreur d'étalonnage inférieure à 0,01 rad/s lorsque l'appareil est immobile et à température ambiante.
  • [C-SR-3] Il est FORTEMENT RECOMMANDÉ d'avoir une résolution de 16 bits ou plus.
  • DEVRAIT enregistrer des événements dont la fréquence d'actualisation est d'au moins 200 Hz.

Si les implémentations d'appareils comprennent un gyroscope à 3 axes, ils:

  • [C-2-1] DOIT implémenter le capteur TYPE_GYROSCOPE.
  • [C-SR-4] Il est fortement recommandé d'implémenter TYPE_GYROSCOPE_UNCALIBRATED capteur vidéo.

Si les implémentations d'appareils incluent un gyroscope avec moins de trois axes:

  • [C-3-1] DOIT implémenter et signaler le capteur TYPE_GYROSCOPE_LIMITED_AXES.
  • [C-SR-5] A-T-ILS PUBLIÉMENT DE mettre en œuvre et de créer des rapports Capteur TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

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

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

Si les appareils sont équipés d'un accéléromètre à 3 axes et d'un gyroscope à 3 axes capteur, elles:

  • [C-5-1] DOIT implémenter les éléments TYPE_GRAVITY et TYPE_LINEAR_ACCELERATION capteurs composites.
  • [C-SR-6] Il est FORTEMENT RECOMMANDÉ de mettre en œuvre TYPE_GAME_ROTATION_VECTOR d'un capteur composite.

Le baromètre

Implémentations pour les appareils:

  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un baromètre (pression de l'air ambiant) capteur).

Si les implémentations d'appareils comprennent un baromètre, celles-ci:

  • [C-1-1] DOIT implémenter et signaler le capteur TYPE_PRESSURE.
  • [C-1-2] DOIT pouvoir diffuser des événements avec une fréquence de 5 Hz ou plus.
  • [C-1-3] DOIT être compensé en température.
  • [C-SR-2] FORTEMENT RECOMMANDÉ de pouvoir signaler les mesures de pression dans le de 300 hPa à 1 100 hPa.
  • DEVRAIT avoir une précision absolue de 1 hPa.
  • DOIT avoir une précision relative de 0,12 hPa sur une plage de 20 hPa (soit une précision d'environ 1 m pour une variation d'environ 200 m au niveau de la mer).

7.3.6. Thermomètre

Si les appareils sont équipés d'un thermomètre ambiant (capteur de température), ils:

  • [C-1-1] DOIT définir SENSOR_TYPE_AMBIENT_TEMPERATURE du capteur de température ambiante, qui DOIT mesurer la température ambiante la température (de la chambre/cabine du véhicule) à partir de laquelle l'utilisateur interagit avec en degrés Celsius.

Si les appareils sont équipés d'un capteur thermomètre mesurant autre que la température ambiante, comme la température du processeur, ils:

Si les implémentations des appareils incluent un capteur pour surveiller la température cutanée, ils:

7.3.7. Photomètre

  • Les implémentations d'appareils PEUVENT inclure un photomètre (capteur de luminosité ambiante).

7.3.8. Capteur de proximité

  • Les implémentations d'appareils PEUVENT inclure un capteur de proximité.

Si les implémentations d'appareils incluent un capteur de proximité et qu'ils ne signalent qu'une la lecture binaire « proche » ou « large », ils:

  • [C-1-1] DOIT mesurer la proximité d'un objet dans la même direction que la l'écran. Autrement dit, le capteur de proximité DOIT être orienté pour détecter des objets. à proximité de l'écran, car l'objectif principal de ce type de capteur détecter un téléphone en cours d'utilisation par l'utilisateur. Si les implémentations d'appareils incluent un capteur de proximité dans une autre orientation, il NE DOIT PAS être accessible via cette API.
  • [C-1-2] DOIT avoir une précision d'au moins 1 bit.
  • [C-1-3] DOIT utiliser 0 centimètre pour la lecture proche et 5 centimètres pour la lecture de loin.
  • [C-1-4] DOIT indiquer une plage maximale et une résolution de 5.

7.3.9. Capteurs haute fidélité

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

  • [C-1-1] DOIT identifier la capacité à l'aide de la propriété Indicateur de fonctionnalité android.hardware.sensor.hifi_sensors.

Si les implémentations d'appareils déclarent android.hardware.sensor.hifi_sensors, ils:

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

    • DOIT avoir une plage de mesure comprise entre -8 g et +8 g, et est VIVEMENT RECOMMANDÉ d'avoir une plage de mesure comprise entre -16 g ou plus et +16 g.
    • DOIT avoir une résolution de mesure d'au moins 2 048 LSB/g.
    • DOIT avoir une fréquence de mesure minimale de 12,5 Hz ou moins.
    • DOIT avoir une fréquence de mesure maximale de 400 Hz ou plus. DEVRAIT est compatible avec SensorDirectChannel RATE_VERY_FAST.
    • DOIT enregistrer un bruit de mesure inférieur à 400 μg/√Hz.
    • DOIT implémenter une forme non activée de ce capteur avec mise en mémoire tampon d'au moins 3 000 événements de capteurs.
    • DOIT avoir une consommation d'énergie par lot inférieure ou égale à 3 mW.
    • [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'utiliser une bande passante de 3 dB pour les mesures au moins 80% de la fréquence de Nyquist et du spectre du bruit blanc dans cette la bande passante réseau.
    • DEVRAIT avoir une marche aléatoire d'accélération inférieure à 30 μg √Hz testée à température ambiante.
    • DEVRAIT avoir un changement de biais par rapport à une température de ≤ +/- 1 mg/°C.
    • DEVRAIT présenter une non-linéarité de la courbe la plus adaptée de ≤ 0,5 %, et une variation de la sensibilité par rapport à la température de ≤ 0,5 % 0,03%/C°.
    • DEVRAIT avoir une sensibilité interaxe < 2,5 % et une variation de Sensibilité transversale < 0,2% de la plage de températures de fonctionnement de l'appareil.

  • [C-2-2] DOIT avoir un élément TYPE_ACCELEROMETER_UNCALIBRATED ayant le même aux exigences de qualité en tant que TYPE_ACCELEROMETER.

  • [C-2-3] DOIT disposer d'un capteur TYPE_GYROSCOPE qui:

    • DOIT avoir une plage de mesure comprise entre -1 000 et +1 000 dps.
    • DOIT avoir une résolution de mesure d'au moins 16 LSB/dps.
    • DOIT avoir une fréquence de mesure minimale de 12,5 Hz ou moins.
    • DOIT avoir une fréquence de mesure maximale de 400 Hz ou plus. DEVRAIT est compatible avec SensorDirectChannel RATE_VERY_FAST.
    • DOIT enregistrer un bruit de mesure inférieur à 0,014 °/s/√ Hz.
    • [C-SR-2] Il est FORTEMENT RECOMMANDÉ d'utiliser une bande passante de 3 dB pour les mesures au moins 80% de la fréquence de Nyquist et du spectre du bruit blanc dans cette la bande passante réseau.
    • DEVRAIT avoir un taux de marche aléatoire inférieur à 0,001 °/s √Hz testé dans une pièce température.
    • DEVRAIT avoir un changement de biais par rapport à une température de ≤ +/- 0,05 °/ s / °C.
    • DEVRAIT avoir un changement de sensibilité par rapport à une température ≤ 0,02% / °C.
    • DEVRAIT présenter une non-linéarité de droite la plus adaptée de ≤ 0,2%.
    • DEVRAIT avoir une densité de bruit ≤ 0,007 °/s/√Hz.
    • DEVRAIT avoir une erreur de calibrage inférieure à 0,002 rad/s dans de 10 à 40 °C lorsque l'appareil est à l'arrêt.
    • La sensibilité g DOIT être inférieure à 0,1°/s/g.
    • DEVRAIT avoir une sensibilité interaxe < Sensibilité à 4,0 % et sensibilité transversale variation < 0,3% de la plage de températures de fonctionnement de l'appareil.

  • [C-2-4] DOIT disposer d'un TYPE_GYROSCOPE_UNCALIBRATED de même qualité les conditions requises TYPE_GYROSCOPE.

  • [C-2-5] DOIT disposer d'un capteur TYPE_GEOMAGNETIC_FIELD qui:

    • DOIT avoir une plage de mesure comprise entre -900 et +900 μT.
    • DOIT avoir une résolution de mesure d'au moins 5 LSB/uT.
    • DOIT avoir une fréquence de mesure minimale de 5 Hz ou moins.
    • DOIT avoir une fréquence de mesure maximale de 50 Hz ou plus.
    • DOIT présenter un bruit de mesure inférieur à 0,5 uT.

  • [C-2-6] DOIT disposer d'un TYPE_MAGNETIC_FIELD_UNCALIBRATED de même qualité exigences que TYPE_GEOMAGNETIC_FIELD et en plus:

    • DOIT implémenter une forme non activée de ce capteur avec mise en mémoire tampon d'au moins 600 événements de capteurs.
    • [C-SR-3] Il est FORTEMENT RECOMMANDÉ d'avoir un spectre de bruit blanc de 1 Hz à au moins 10 Hz lorsque la fréquence du rapport est de 50 Hz ou plus.

  • [C-2-7] DOIT disposer d'un capteur TYPE_PRESSURE qui:

    • La plage de mesure DOIT être comprise entre 300 et 1 100 hPa au minimum.
    • DOIT avoir une résolution de mesure d'au moins 80 LSB/hPa.
    • DOIT avoir une fréquence de mesure minimale de 1 Hz ou moins.
    • DOIT avoir une fréquence de mesure maximale de 10 Hz ou plus.
    • DOIT enregistrer un bruit de mesure inférieur à 2 Pa/√Hz.
    • DOIT implémenter une forme non activée de ce capteur avec mise en mémoire tampon d'au moins 300 événements de capteurs.
    • DOIT avoir une consommation d'énergie par lot inférieure ou égale à 2 mW.

  • [C-2-8] DOIT disposer d'un capteur TYPE_GAME_ROTATION_VECTOR.

  • [C-2-9] DOIT disposer d'un capteur TYPE_SIGNIFICANT_MOTION qui:

    • La consommation d'énergie ne doit PAS être inférieure à 0,5 mW lorsque l'appareil statique et de 1,5 mW lorsque l'appareil est en mouvement.

  • [C-2-10] DOIT disposer d'un capteur TYPE_STEP_DETECTOR qui:

    • DOIT implémenter une forme non activée de ce capteur avec mise en mémoire tampon d'au moins 100 événements de capteurs.
    • La consommation d'énergie ne doit PAS être inférieure à 0,5 mW lorsque l'appareil statique et de 1,5 mW lorsque l'appareil est en mouvement.
    • DOIT avoir une consommation d'énergie par lot inférieure ou égale à 4 mW.

  • [C-2-11] DOIT disposer d'un capteur TYPE_STEP_COUNTER qui:

    • La consommation d'énergie ne doit PAS être inférieure à 0,5 mW lorsque l'appareil statique et de 1,5 mW lorsque l'appareil est en mouvement.

  • [C-2-12] DOIT disposer d'un capteur TILT_DETECTOR qui:

    • La consommation d'énergie ne doit PAS être inférieure à 0,5 mW lorsque l'appareil statique et de 1,5 mW lorsque l'appareil est en mouvement.

  • [C-2-13] Le code temporel du même événement physique signalé par L'accéléromètre, le gyroscope et le magnétomètre DOIVENT se situer dans un rayon de 2, 5 millisecondes les uns des autres. Le code temporel du même événement physique signalé par l'accéléromètre et le gyroscope DOIVENT se trouver à une distance de 0,25 milliseconde chacun autre.

  • [C-2-14] Les codes temporels des événements du capteur du gyroscope DOIVENT être associés au même moment. de base que le sous-système de l'appareil photo et en 1 milliseconde d'erreur.

  • [C-2-15] DOIT fournir des échantillons aux applications dans un délai de 5 millisecondes Le moment où les données sont disponibles sur l'un des capteurs physiques ci-dessus à l'application.

  • [C-2-16] NE DOIT PAS avoir une consommation d'énergie supérieure à 0,5 mW Lorsque l'appareil est statique et de 2 mW lorsqu'il est en mouvement lorsque n'importe quelle combinaison des capteurs suivants est activée:

    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS

  • [C-2-17] PEUT avoir un capteur TYPE_PROXIMITY, mais s'il est présent, il DOIT avoir une capacité de mémoire tampon minimale de 100 événements de capteur.

Notez que les exigences de consommation d'énergie de cette section n'incluent pas les composants la consommation d'énergie du processeur d'application. Elle inclut le pouvoir par l'ensemble de la chaîne de capteurs : le capteur, les circuits associés, un système dédié au traitement de capteurs, etc.

Si les implémentations d'appareils incluent la prise en charge directe des capteurs, celles-ci:

  • [C-3-1] DOIT déclarer correctement la prise en charge des types de canaux directs des taux de rapports via le isDirectChannelTypeSupported et getHighestDirectReportRateLevel API.
  • [C-3-2] DOIT prendre en charge au moins l'un des deux types de canaux directs des capteurs pour tous les capteurs qui déclarent la prise en charge du canal direct du capteur.
  • DEVRAIT prendre en charge les rapports d'événements via le canal direct de capteur (variante sans réveil) des types suivants:
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Capteurs biométriques

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

Si les implémentations d'appareils comprennent un écran de verrouillage sécurisé:

  • DEVRAIT inclure un capteur biométrique

Les capteurs biométriques peuvent être classés dans la classe 3 (anciennement Strong), Classe 2 (anciennement Faible) ou Classe 1 (anciennement Commodité) en fonction de leurs taux d'acceptation par les imposteurs et par les parasites, ainsi que par la sécurité un pipeline biométrique. Cette classification détermine les capacités le capteur biométrique doit communiquer avec la plate-forme et avec des tiers applications. Les capteurs doivent répondre aux exigences supplémentaires décrites ci-dessous si elles souhaitent être classées dans les catégories Classe 1, Classe 2 ou Classe 3. Les biométries de classe 2 et de classe 3 bénéficient de fonctionnalités supplémentaires : détaillé ci-dessous.

Si des mises en œuvre d'appareils mettent un capteur biométrique à la disposition d'un tiers d'applications via android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt, et android.provider.Settings.ACTION_BIOMETRIC_ENROLL, ils:

  • [C-4-1] DOIT respecter les exigences concernant les données biométriques de classe 3 ou 2 tel que défini dans ce document.
  • [C-4-2] DOIT reconnaître et respecter chaque nom de paramètre défini en tant que constante dans la section Authenticators et toutes les combinaisons de celles-ci. Inversement, NE DOIT PAS respecter ni reconnaître des constantes entières transmises au canAuthenticate(int) et setAllowedAuthenticators(int) autres que celles documentées en tant que constantes publiques Authentificateurs et toutes les combinaisons de celles-ci.
  • [C-4-3] DOIT implémenter l'instruction ACTION_BIOMETRIC_ENROLL sur les appareils utilisant la biométrie de classe 3 ou de classe 2. Cette action DOIT présenter uniquement les points d'entrée d'inscription pour la classe 3 ou la biométrie de classe 2.

Si les implémentations d'appareils prennent en charge la biométrie passive, elles:

  • [C-5-1] DOIT exiger par défaut une étape de confirmation supplémentaire (par exemple, en appuyant sur un bouton).
  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'avoir un paramètre permettant aux utilisateurs de ignorer les préférences de l'application et exiger toujours qu'un accompagnement l'étape de confirmation.
  • [C-SR-2] Il est FORTEMENT RECOMMANDÉ que l'opération de confirmation soit effectuée de sorte qu’un système d’exploitation ou un noyau compromis ne puisse pas en usurper. Par exemple, cela signifie que l'action de confirmation basée sur un bouton physique est acheminée via une broche GPIO (entrée uniquement) un composant sécurisé (SE) qui ne peut être piloté par aucun autre moyen qu'un l'appui physique sur le bouton.
  • [C-5-2] DOIT également implémenter un flux d'authentification implicite (sans étape de confirmation) correspondant à setConfirmationRequired(boolean), les applications pouvant être configurées pour les flux de connexion.

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

Commencer les nouvelles exigences

  • [C-7-1] OBLIGATOIRE lorsqu'une biométrie est verrouillée (c'est-à-dire qu'elle est désactivée) jusqu'à ce que l'utilisateur déverrouille avec l'authentification principale) ou un verrouillage temporalisé (c'est-à-dire que l'authentification biométrique est temporairement désactivée jusqu'à ce que l'utilisateur patiente un certain temps) en raison d'un trop grand nombre de tentatives infructueuses, tous les autres la biométrie d'une classe biométrique inférieure. Dans le cas d’un blocage limité dans le temps, 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 un verrouillage temporel.

  • [C-SR-12] Sont FORTEMENT RECOMMANDÉS lorsque les données biométriques sont verrouillées l'authentification biométrique est désactivée jusqu'à ce que l'utilisateur se déverrouille avec l'authentification principale). verrouillage temporalisé (c'est-à-dire, la biométrie est temporairement désactivée jusqu'à ce que l'utilisateur attend un intervalle de temps) en raison d'un trop grand nombre de tentatives infructueuses. verrouiller toutes les autres données biométriques de la même classe biométrique. Dans le cas d'une verrouillage limité dans le temps, l'intervalle entre les tentatives pour la vérification biométrique est FORTEMENT RECOMMANDÉ comme intervalle maximal entre les tentatives de toutes les données biométriques dans le temps lors d'un verrouillage.

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

Mettre fin aux nouvelles exigences

  • [C-SR-3] Il est FORTEMENT RECOMMANDÉ de n'exiger qu'une seule validation biométrique par authentification (par exemple, si les capteurs d'empreinte digitale et du visage sont disponibles) onAuthenticationSucceeded sur l'appareil doit être envoyé après la confirmation de l'une d'entre elles).

Pour que les implémentations d'appareils autorisent l'accès aux clés de keystore pour applications tierces, ils:

  • [C-6-1] DOIT respecter les exigences de la classe 3, telles que définies ci-dessous.
  • [C-6-2] DOIT présenter uniquement des données biométriques de classe 3 lorsque l'authentification nécessite BIOMETRIC_STRONG, ou l'authentification est appelée avec un CryptoObject.

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

  • [C-1-1] DOIT avoir un taux de faux acceptations inférieur à 0,002%.
  • [C-1-2] DOIT indiquer que ce mode peut être moins sécurisé qu'un code PIN sécurisé. schéma ou mot de passe, et énumérez clairement les risques liés à son activation, les taux d’acceptation de spoofing et d’imposteurs sont supérieurs à 7 %, selon les mesures Protocoles de test biométrique Android
  • [C-1-9] DOIT inviter l'utilisateur à effectuer l'authentification principale recommandée (par exemple, code, schéma ou mot de passe) après un maximum de vingt faux essais et de moins de 90 secondes pour la vérification biométrique, lorsqu'un un faux essai doit offrir une qualité de capture adéquate. (BIOMETRIC_ACQUIRED_GOOD) qui ne correspond à aucune donnée biométrique enregistrée.
  • [C-SR-4] Il est FORTEMENT RECOMMANDÉ de réduire le nombre total de faux essais. pour la vérification biométrique spécifiée dans [C-1-9], si le spoofing et l'imposteur les taux d'acceptation sont supérieurs à 7 %, selon l'indicateur biométrique d'Android Protocoles de test.
  • [C-1-3] DOIT limiter le nombre de tentatives de validation biométrique un faux essai doit offrir une qualité de capture adéquate. (BIOMETRIC_ACQUIRED_GOOD) qui ne correspond pas à une biométrie enregistrée.
  • [C-SR-5] Il est FORTEMENT RECOMMANDÉ de limiter le débit des tentatives pendant au moins 30 secondes après cinq faux essais de vérification biométrique pour le nombre maximal de faux essais par [C-1-9] - où un faux essai correspond à un avec une qualité de capture adéquate (BIOMETRIC_ACQUIRED_GOOD) qui ne correspond pas à une l'enregistrement biométrique.
  • [C-SR-6] Il est FORTEMENT RECOMMANDÉ d'intégrer toute la logique de limitation du débit dans le TEE.

  • [C-1-10] DOIT désactiver la biométrie une fois que l'intervalle d'authentification principal déclenché pour la première fois comme décrit dans l'article [C-0-2] de la section 9.11.

  • [C-1-11] DOIT avoir un taux d'acceptation par usurpation d'identité et par imposteur inférieur ou égal à 30 %. avec (1) une parodie et un taux d'acceptation par l'imposteur pour une présentation de niveau A espèces d'instruments d'attaque (PAI) ne dépassant pas 30%, et (2) une parodie et le taux d'acceptation de l'imposteur des espèces PAI de niveau B n'est pas supérieur à 40%, puisque mesurées par les protocoles de test biométrique Android.

  • [C-1-4] DOIT empêcher l'ajout de nouvelles données biométriques sans avoir préalablement établi de confiance en demandant à l'utilisateur de confirmer l'existence ou d'ajouter un nouvel appareil identifiant (code/schéma/mot de passe) sécurisé par TEE ; l'application Android Open L’implémentation du projet source fournit le mécanisme dans le cadre pour faire donc.

  • [C-1-5] DOIT supprimer complètement toutes les données biométriques permettant d'identifier l'utilisateur Lorsque le compte de l'utilisateur est supprimé (y compris en cas de rétablissement de la configuration d'usine).

  • [C-1-6] DOIT respecter l'indicateur individuel de cette biométrie (par exemple, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE ou DevicePolicymanager.KEYGUARD_DISABLE_IRIS ).

  • [C-1-7] DOIT inviter l'utilisateur à procéder à l'authentification principale recommandée (code, schéma ou mot de passe, par exemple) une fois toutes les 24 heures maximum. Remarque: La mise à niveau des appareils lancés sous Android 9 ou une version antérieure DOIT ÊTRE demander à l'utilisateur de procéder à l'authentification principale recommandée (par exemple, schéma ou mot de passe) toutes les 72 heures au maximum.

  • [C-1-8] DOIT inviter l'utilisateur à la question (par exemple, code, schéma ou mot de passe) ou données biométriques de classe 3 (Strong) après l'un des événements suivants:

    • un délai d'inactivité de quatre heures, OU
    • 3 tentatives d'authentification biométrique ayant échoué.
    • Le délai d'inactivité et le nombre d'échecs d'authentification sont réinitialisés après confirmation des identifiants de l'appareil. Remarque: La mise à niveau des appareils lancés avec Android 9 ou une version antérieure PEUT être est exemptée de l'obligation de contrôle C-1-8.

  • [C-SR-7] EST FORTEMENT RECOMMANDÉ d'utiliser la logique du framework fourni par le projet Android Open Source pour appliquer les contraintes spécifiées dans [C-1-7] et [C-1-8] pour les nouveaux appareils.

  • [C-SR-8] Il est FORTEMENT RECOMMANDÉ d'avoir un taux de faux refus inférieur à 10%, comme mesuré sur l’appareil.

  • [C-SR-9] Il est FORTEMENT RECOMMANDÉ d'avoir une latence mesurée en dessous de 1 seconde entre la détection biométrique et le déverrouillage de l'écran, pour chaque l'enregistrement biométrique.

Commencer les nouvelles exigences

  • [C-1-12] DOIT avoir un taux d'acceptation de spoofing et d'imposteurs ne dépassant pas 40% espèces d'instruments d'attaque par présentation (PAI), mesurées par la métrique Protocoles de test biométrique Android

  • [C-SR-13] Il est FORTEMENT RECOMMANDÉ d'accepter une parodie et un imposteur. un taux maximal de 30% par espèce d'instrument d'attaque de présentation (PAI) selon les mesures effectuées par les protocoles de test biométrique Android.

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

  • [C-SR-17] EST FORTEMENT RECOMMANDÉ d'implémenter les nouvelles interfaces AIDL (par exemple, IFace.aidl et IFingerprint.aidl).

Mettre fin aux nouvelles exigences

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

  • [C-2-1] DOIT respecter toutes les exigences de la classe 1 ci-dessus.

  • [C-2-2] DOIT avoir un taux d'acceptation de spoofing et d'imposteurs ne dépassant pas 20%, (1) une usurpation d'identité et un taux d'acceptation par l'imposteur pour Espèces d'instruments d'attaque de présentation (PAI) de niveau A inférieures à 20%, et (2) un parasite et un taux d'acceptation par l'imposteur d'espèces PAI de niveau B qui ne sont pas supérieure à 30%, selon la métrique Protocoles de test biométrique Android

Commencer les nouvelles exigences

  • [C-SR-15] Il est FORTEMENT RECOMMANDÉ d'accepter une parodie et un imposteur. un taux maximal de 20% par instrument d'attaque de présentation (PAI) espèce, telle que mesurée Protocoles de test biométrique Android

Mettre fin aux nouvelles exigences

  • [C-2-3] DOIT exécuter correspondance biométrique dans un environnement d'exécution isolé en dehors d'Android l'espace utilisateur ou de noyau, comme l'environnement d'exécution sécurisé (TEE), ou sur une puce avec 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 avoir toutes les données identifiables chiffrées et cryptographiques authentifiés de sorte qu'ils ne puissent pas être acquis, lus ou modifiés en dehors l'environnement d'exécution isolé ou une puce dotée d'un canal sécurisé un environnement d'exécution isolé, comme indiqué dans le Guide de mise en œuvre consignes sur le 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, tandis que l'authentification biométrique ou un enregistrement est en cours:
    • DOIT utiliser l'appareil photo dans un mode qui empêche les images en cours de lecture ou de modification en dehors de l'environnement d'exécution isolé ou d'une puce un canal sécurisé vers l'environnement d'exécution isolé ou d'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 cadres PEUVENT être lisibles en dehors de l'environnement d'exécution isolé pour permettre comme l'aperçu pour l'inscription, mais il NE DOIT PAS être modifiable.
  • [C-2-6] NE DOIT PAS permettre aux applications tierces de faire la distinction les enregistrements biométriques individuels.
  • [C-2-7] NE DOIT PAS autoriser un accès non chiffré à des données biométriques toutes les données qui en sont dérivées (telles que les représentations vectorielles continues) vers le processeur d'application en dehors du contexte du TEE ou la machine virtuelle protégée contrôlée par un hyperviseur qui répond aux exigences de la section 9.17. Les appareils mis à niveau lancés sous Android 9 ou une version antérieure ne sont pas exemptés de C-2-7.

  • [C-2-8] DOIT disposer d'un pipeline de traitement sécurisé de sorte qu'un système d'exploitation une compromission du système ou du noyau ne peut pas permettre l’injection directe de données s'authentifier à tort comme l'utilisateur. Remarque: Si les implémentations d'appareils sont déjà lancées sur Android version 9 ou antérieure et ne peut pas répondre à l'exigence C-2-8 par le biais d'un logiciel système mise à jour, ils PEUVENT être exemptés de cette exigence.

  • [C-SR-10] Il est FORTEMENT RECOMMANDÉ d'inclure la détection d'activité pour tous et détection de l'attention pour la biométrie des visages.

  • [C-2-9] DOIT mettre le capteur biométrique à la disposition d'un tiers applications.

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

  • [C-3-1] DOIT respecter toutes les exigences de la classe 2 ci-dessus, à l'exception des [C-1-7] et [C-1-8].
  • [C-3-2] DOIT disposer d'une implémentation de keystore intégré au matériel.
  • [C-3-3] DOIT avoir un taux d'acceptation de spoofing et d'imposteurs ne dépassant pas 7%, (1) une usurpation d'identité et un taux d'acceptation par l'imposteur pour espèces d'instruments d'attaque de présentation (PAI) de niveau A ne dépassant pas 7 % ; et (2) un parodie et un taux d'acceptation par l'imposteur d'espèces PAI de niveau B inférieurs de plus de 20%, comme le mesure Protocoles de test biométrique Android
  • [C-3-4] DOIT inviter l'utilisateur à la question principale recommandée (par code, schéma ou mot de passe, par exemple) toutes les 72 heures ou moins.
  • [C-3-5] DOIT générer à nouveau un ID d'authentificateur pour toutes les données biométriques de classe 3 prises en charge sur l'appareil, si l'une d'entre elles est réinscrit.
  • [C-3-6] Vous devez activer les clés de keystore basées sur la biométrie pour les clés tierces. applications.

Commencer les nouvelles exigences

  • [C-SR-16] Il est FORTEMENT RECOMMANDÉ d'accepter une parodie et un imposteur. un taux maximal de 7% par espèce d'instrument d'attaque de présentation (PAI) selon les mesures effectuées par les protocoles de test biométrique Android.

Mettre fin aux nouvelles exigences

Si les implémentations d'appareils comportent un lecteur d'empreinte digitale sous l'écran (UDFPS), ils:

  • [C-SR-11] Sont FORTEMENT RECOMMANDÉS pour empêcher la zone tactile de l'UDFPS (lecteur d'empreinte digitale sous l'écran) d'interférer avec la navigation à trois boutons( que certains utilisateurs peuvent avoir à des fins d'accessibilité).

7.3.11. Capteur de postures

Implémentations pour les appareils:

  • PEUT prendre en charge les capteurs de position avec 6 degrés de liberté.

Si les implémentations d'appareils prennent en charge les capteurs de position à 6 degrés de liberté, ils:

  • [C-1-1] DOIT implémenter et signaler l'TYPE_POSE_6DOF capteur vidéo.
  • [C-1-2] DOIT être plus précis que le vecteur de rotation seul.

7.3.12. Capteur d'angle de charnière

Si les appareils sont compatibles avec un capteur d'angle de charnière:

7.3.13. IEEE 802.1.15.4 (UWB)

Si les implémentations d'appareils sont compatibles avec la norme 802.1.15.4 et exposent le à une application tierce, ils:

Commencer les nouvelles exigences

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

réussir les tests de conformité et de certification pertinents définis par la norme ; telles que FIRA, CCC et La CSA permet de s'assurer que la norme 802.1.15.4 fonctionne correctement.

Mettre fin aux nouvelles exigences

7.4. Connectivité des données

7.4.1. Téléphonie

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 le terme "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 destinés aux besoins d'Android et sont considérés comme étant indépendants de toute connectivité de données pouvant être implémentée à l'aide du même réseau. En d'autres termes,la fonctionnalité 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.

  • Android PEUT être utilisé sur des appareils n'incluant pas de matériel téléphonique. Cela est qu'Android est compatible avec les appareils qui ne sont pas des téléphones.

Si les implémentations d'appareils incluent la téléphonie GSM ou CDMA, ils:

  • [C-1-1] DOIT déclarer le flag de fonctionnalité android.hardware.telephony. d'autres indicateurs de sous-fonctionnalité, en fonction de la technologie utilisée.
  • [C-1-2] DOIT mettre en œuvre la compatibilité totale de l'API avec cette technologie.
  • DEVRAIT autoriser tous les types de services mobiles disponibles (2G, 3G, 4G, 5G, etc.) pendant les appels d'urgence (quels que soient les types de réseau définis par SetAllowedNetworkTypeBitmap()).

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

  • [C-2-1] DOIT implémenter les API complètes en tant que no-ops.

Si les implémentations d'appareils sont compatibles avec les eUICC ou les eSIM/SIM intégrées et incluent un mécanisme propriétaire permettant de mettre la fonctionnalité eSIM à la disposition des développeurs, ils:

Si les implémentations d'appareils ne définissent pas la propriété système ro.telephony.iwlan\_operation\_mode sur "legacy" :

Si les implémentations d'appareils sont compatibles avec un sous-système multimédia (IMS) unique IP l'enregistrement au service de téléphonie multimédia (MMTEL) et de services de communication enrichis (RCS) et doivent respecter aux exigences de l'opérateur mobile concernant l'utilisation d'un seul L'enregistrement IMS pour tout le trafic IMS signalant le trafic:

Si les implémentations d'appareils signalent la fonctionnalité android.hardware.telephony:

Si les implémentations d'appareils signalent la fonctionnalité android.hardware.telephony et afficher une barre d'état système, puis:

  • [C-7-1] DOIT sélectionner un abonnement actif représentatif pour un UUID du groupe à présenter à l'utilisateur dans toutes les affordances qui fournissent l'état de la carte SIM des informations. Parmi ces affordances, on peut citer la barre d'état cellulaire l'icône de signal ou le bloc Réglages rapides.
  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ que l'abonnement représentatif choisi pour être abonnement data actif sauf si l'appareil utilise une commande vocale au cours duquel il est FORTEMENT RECOMMANDÉ que le représentant L'abonnement est l'abonnement Voice actif.

Si les implémentations d'appareils signalent la fonctionnalité android.hardware.telephony:

  • [C-6-7] DOIT être capable d'ouvrir et d'utiliser simultanément la valeur nombre de canaux logiques (20 au total) pour chaque UICC, conformément à l'ETSI TS 102 221.
  • [C-6-8] NE DOIT PAS appliquer l'un des comportements suivants aux applications d'opérateurs actives (comme indiqué par TelephonyManager#getCarrierServicePackageName) automatiquement ou sans confirmation explicite de l'utilisateur:
    • Révoquer ou limiter l'accès au réseau
    • Révoquer les autorisations
    • Limitez l'exécution d'applications en arrière-plan ou au premier plan au-delà des fonctionnalités de gestion de l'alimentation existantes incluses dans AOSP.
    • Désactiver ou désinstaller l'application

Si les implémentations d'appareils signalent la fonctionnalité android.hardware.telephony et tous actifs, abonnements non opportunistes partageant un UUID de groupe sont désactivés, physiquement retiré de l'appareil ou marqué comme opportuniste, l'appareil:

  • [C-8-1] DOIT désactiver automatiquement tous les autres éléments actifs opportuniste dans le même groupe.

Si les implémentations d'appareils incluent la téléphonie GSM, mais pas la téléphonie CDMA, ils:

  • [C-9-1] NE DOIT PAS déclarer PackageManager#FEATURE_TELEPHONY_CDMA.
  • [C-9-2] DOIT générer une exception IllegalArgumentException lors des tentatives de Types de réseaux 3GPP2 dans les masques de bits des types de réseau préférés ou autorisés.
  • [C-9-3] DOIT renvoyer une chaîne vide TelephonyManager#getMeid

Si les implémentations d'appareils prennent en charge les eUICC avec plusieurs ports et profils, elles:

Compatibilité avec le blocage des numéros

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

  • [C-1-1] DOIT inclure une fonctionnalité de blocage de numéros
  • [C-1-2] DOIT implémenter intégralement BlockedNumberContract et l'API correspondante, comme décrit dans la documentation du SDK.

  • [C-1-3] DOIT bloquer tous les appels et messages provenant d'un numéro de téléphone figurant dans "BloquéNumberProvider" sans aucune interaction avec les applications. La seule exception se produit lorsque le blocage de numéros est temporairement levé, comme décrit dans le SDK. dans la documentation Google Cloud.

  • [C-1-4] DOIT écrire dans le fournisseur de journaux d'appels de la plate-forme pour un appel bloqué et DOIT filtrer les appels avec BLOCKED_TYPE hors du champ l'affichage par défaut du journal d'appels dans l'application de téléphonie préinstallée.

  • [C-1-5] NE DOIT PAS écrire au fournisseur de téléphonie en cas de message bloqué.

  • [C-1-6] DOIT implémenter une interface utilisateur de gestion des numéros bloqués, qui est ouverte avec l'intent renvoyé par TelecomManager.createManageBlockedNumbersIntent() .

  • [C-1-7] NE DOIT PAS autoriser les utilisateurs secondaires à afficher ou modifier les numéros bloqués sur l'appareil, car la plate-forme Android suppose que l'utilisateur principal dispose le contrôle des services de téléphonie, une seule instance, sur l'appareil. Tout l'interface utilisateur associée au blocage DOIT être masquée pour les utilisateurs secondaires, et la liste de blocage DOIT être masquée tout en respectant les règles en vigueur.

  • DEVRAIT migrer les numéros bloqués vers le fournisseur lorsqu'un appareil sera mis à jour vers Android 7.0.

  • DEVRAIT fournir une affordance utilisateur pour afficher les appels bloqués dans le l'application Téléphone.

API Telecom

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

  • [C-1-1] DOIT prendre en charge les API ConnectionService décrites dans le SDK.
  • [C-1-2] DOIT afficher un nouvel appel entrant et fournir une affordance à l'utilisateur accepter ou refuser l'appel entrant lorsqu'un utilisateur est en cours d'appel ; généré par une appli tierce qui n'est pas compatible avec la fonctionnalité de mise en attente spécifié via CAPABILITY_SUPPORT_HOLD
  • [C-1-3] DOIT disposer d'une application qui met en œuvre InCallService :

  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'informer l'utilisateur que le fait de répondre à une l'appel entrant interrompt l'appel en cours.

    L'implémentation d'AOSP répond à ces exigences grâce à une notification prioritaire ce qui indique à l'utilisateur que répondre à un appel entrant entraînera ou un autre appel à abandonner.

  • [C-SR-2] Il est FORTEMENT RECOMMANDÉ de précharger l'application de téléphonie par défaut affiche une entrée du journal d'appels et le nom d'une application tierce dans son journal d'appels. lorsque l'application tierce définit EXTRA_LOG_SELF_MANAGED_CALLS sa clé Extras sur son PhoneAccount pour true.

  • [C-SR-3] Il est FORTEMENT RECOMMANDÉ de manipuler le casque audio Événements KEYCODE_MEDIA_PLAY_PAUSE et KEYCODE_HEADSETHOOK pour android.telecom API comme ci-dessous:

    • Appeler Connection.onDisconnect() Lorsqu'un appui court sur l'événement touche est détecté au cours d'un appel.
    • Appeler Connection.onAnswer() Lorsqu'un appui court sur l'événement touche est détecté pendant un appel entrant.
    • Appeler Connection.onReject() Lorsqu'un appui prolongé sur un événement de touche est détecté pendant un appel entrant.
    • Activer/Désactiver le son de CallAudioState.
Déchargement cellulaire NAT-T Keepalive

Implémentations pour les appareils:

  • DEVRAIT inclure la prise en charge du déchargement du message keepalive cellulaire.

Si les implémentations d'appareils incluent la prise en charge du déchargement du message keepalive cellulaire et expose la fonctionnalité à des applications tierces:

  • [C-1-1] DOIT prendre en charge l'API SocketKeepAlive.
  • [C-1-2] DOIT prendre en charge au moins un emplacement keepalive simultané sur le réseau mobile.
  • [C-1-3] DOIT prendre en charge autant d'emplacements de message keepalive cellulaires simultanés que pris en charge par la HAL de la radio cellulaire.
  • [C-SR-1] EST FORTEMENT RECOMMANDÉ d'accepter au moins trois messages keepalive cellulaire d'emplacements par instance radio.

Si les implémentations d'appareils n'incluent pas la prise en charge du déchargement du message keepalive cellulaire, ils:

  • [C-2-1] DOIT renvoyer ERROR_UNSUPPORTED.

7.4.2. IEEE 802.11 (Wi-Fi)

Implémentations pour les appareils:

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

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

  • [C-1-1] DOIT implémenter l'API Android correspondante.
  • [C-1-2] DOIT signaler le flag de fonctionnalité matérielle android.hardware.wifi.
  • [C-1-3] DOIT implémenter l'API de multidiffusion comme décrit dans la documentation du SDK.
  • [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, y compris lorsque l'écran n'est pas actif, à moins que la suppression ou le filtrage de ces paquets ne soit pour respecter les plages de consommation d'énergie requises par la réglementation aux exigences applicables au marché cible. Pour les implémentations d'appareils Android Television, même en mode veille.
  • [C-1-5] NE DOIT PAS traiter l'élément WifiManager.enableNetwork() appel de méthode API comme indication suffisante pour changer la méthode Network, utilisé par défaut pour le trafic de l'application et renvoyé de ConnectivityManager Méthodes d'API telles que getActiveNetwork et registerDefaultNetworkCallback. En d'autres termes, ils PEUVENT désactiver uniquement l'accès Internet fourni par d'un autre opérateur (par exemple, les données mobiles) s'il valide que le réseau Wi-Fi fournit un accès à Internet.
  • [C-1-6] Sont FORTEMENT RECOMMANDÉS lorsque le ConnectivityManager.reportNetworkConnectivity() la méthode API est appelée, réévaluez l'accès Internet sur le Network, puis une fois que l'évaluation détermine que le Network actuel ne fournit plus Accès Internet, utilisez un autre réseau disponible (par exemple, un réseau mobile qui fournit un accès à Internet.
  • [C-1-7] DOIT appliquer de manière aléatoire l'adresse MAC source et le numéro de séquence de la vérification une fois au début de chaque recherche, tandis que STA est déconnectés.
  • [C-1-8] DOIT utiliser une seule adresse MAC cohérente (NE DEVRAIT PAS afficher les adresses MAC dans un ordre aléatoire) à mi-parcours de la recherche).
  • [C-1-9] DOIT itérer le numéro de séquence de la requête de vérification normalement (de manière séquentielle) entre les requêtes de vérification dans une analyse.
  • [C-1-10] DOIT appliquer de manière aléatoire le numéro de séquence de la requête de vérification entre la dernière vérification requête d'analyse et la première requête de vérification de l'analyse suivante.
  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ de randomiser l'adresse MAC source utilisée pour toutes les communications STA vers un point d'accès, tout en associant et associées.
    • L'appareil DOIT utiliser une adresse MAC aléatoire différente pour chaque SSID. (FQDN pour Passpoint) avec lequel il communique.
    • L'appareil DOIT fournir à l'utilisateur la possibilité de contrôler randomisation par SSID (FQDN pour Passpoint) avec des valeurs non aléatoires et des options aléatoires et DOIT définir le mode par défaut pour le nouveau réseau Wi-Fi de manière aléatoire.
  • [C-SR-2] Il est FORTEMENT RECOMMANDÉ d'utiliser un BSSID aléatoire pour tous les points d'accès créer.
    • L'adresse MAC DOIT être aléatoire et conservée par SSID utilisé par le AP.
    • L'APPAREIL PEUT Donner à l'utilisateur la possibilité de désactiver cette fonctionnalité. Si une telle option est fournie, la randomisation DOIT être activée par défaut.

Si les implémentations d'appareils prennent en charge le mode Économie d'énergie Wi-Fi tel que défini conformément à la norme IEEE 802.11, ils:

  • DEVRAIT désactiver le mode Économie d'énergie Wi-Fi chaque fois qu'une application acquiert Serrure WIFI_MODE_FULL_HIGH_PERF ou WIFI_MODE_FULL_LOW_LATENCY par WifiManager.createWifiLock() et WifiManager.WifiLock.acquire() API et le verrou est actif.
  • [C-3-2] La latence moyenne aller-retour entre les appareils et un point d'accès lorsque l'appareil est verrouillé en mode Wi-Fi à faible latence (WIFI_MODE_FULL_LOW_LATENCY) DOIT être inférieure à la valeur la latence en mode Wi-Fi High Perf Lock (WIFI_MODE_FULL_HIGH_PERF).
  • [C-SR-3] Sont FORTEMENT RECOMMANDÉS pour minimiser la latence aller-retour du Wi-Fi chaque fois qu'un verrou à faible latence (WIFI_MODE_FULL_LOW_LATENCY) est acquis. et prend effet.

Si les implémentations d'appareils sont compatibles avec le Wi-Fi et l'utilisent pour rechercher la position, ils:

Wi-Fi Direct

Implémentations pour les appareils:

  • DEVRAIT inclure la prise en charge du Wi-Fi Direct (Wi-Fi peer-to-peer).

Si les appareils sont compatibles avec le Wi-Fi Direct, ils:

  • [C-1-1] DOIT implémenter l'API Android correspondante comme décrit dans la documentation du SDK.
  • [C-1-2] DOIT signaler la fonctionnalité matérielle android.hardware.wifi.direct.
  • [C-1-3] DOIT être compatible avec le fonctionnement Wi-Fi standard.
  • [C-1-4] DOIT être compatible avec les opérations Wi-Fi et Wi-Fi Direct simultanément.
  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ de randomiser l'adresse MAC source pour tous des connexions Wi-Fi Direct nouvellement créées.

Implémentations pour les appareils:

Si les implémentations d'appareils incluent la prise en charge du TDLS et que celui-ci est activé par le API WiFiManager, ils:

  • [C-1-1] DOIT déclarer la prise en charge du TDLS via WifiManager.isTdlsSupported.
  • DEVRAIT utiliser le TDLS uniquement lorsque cela est possible ET bénéfique.
  • DEVRAIT avoir une heuristique et NE PAS utiliser le TDLS lorsque ses performances pourraient être pire que de passer par le point d'accès Wi-Fi.
Wi-Fi Aware

Implémentations pour les appareils:

Si les implémentations d'appareils incluent la compatibilité Wi-Fi Aware et exposent le à des applications tierces, ils:

  • [C-1-1] DOIT implémenter les API WifiAwareManager, comme décrit dans le Documentation du SDK
  • [C-1-2] DOIT déclarer le flag de fonctionnalité android.hardware.wifi.aware.
  • [C-1-3] DOIT prendre en charge les opérations Wi-Fi et Wi-Fi Aware simultanément.
  • [C-1-4] DOIT attribuer de manière aléatoire à intervalles réguliers l'adresse de l'interface de gestion Wi-Fi Aware ne dépasse pas 30 minutes et chaque fois que Wi-Fi Aware est activé, à moins qu'un l'opération de mesure des distances est en cours ou un chemin de données Aware est actif (la randomisation n'est pas attendu tant que le chemin de données est actif).

Si les implémentations d'appareils sont compatibles avec Wi-Fi Aware et la localisation Wi-Fi, comme décrit dans la section 7.4.2.5 et expose ces fonctionnalités à des applications tierces:

7.4.2.4. Passpoint Wi-Fi

Si les appareils sont compatibles avec la norme 802.11 (Wi-Fi), ils:

  • [C-1-1] DOIT inclure la compatibilité avec Wi-Fi Passpoint.
  • [C-1-2] DOIT implémenter les API WifiManager liées à Passpoint comme décrites dans la documentation du SDK.
  • [C-1-3] DOIT être compatible avec la norme IEEE 802.11u, spécifiquement associée à la découverte et à la sélection du réseau, comme la publicité générique Service (GAS) et le protocole ANQP (Access Network Query Protocol).
  • [C-1-4] DOIT déclarer le flag de fonctionnalité android.hardware.wifi.passpoint.
  • [C-1-5] DOIT suivre l'implémentation AOSP pour découvrir, mettre en correspondance et associer aux réseaux Passpoint.
  • [C-1-6] DOIT prendre en charge au moins le sous-ensemble suivant de provisionnement d'appareils tels que définis dans le contrat Wi-Fi Alliance Passpoint R2: EAP-TTLS l'authentification et les données SOAP-XML.
  • [C-1-7] DOIT traiter le certificat du serveur AAA tel que décrit dans Spécification du point d'accès 2.0 R3.
  • [C-1-8] DOIT prendre en charge le contrôle utilisateur du provisionnement via le sélecteur Wi-Fi.
  • [C-1-9] DOIT garder les configurations Passpoint persistantes lors des redémarrages.
  • [C-SR-1] EST FORTEMENT RECOMMANDÉ de respecter les conditions d'utilisation la fonctionnalité d'acceptation.
  • [C-SR-2] SONT FORTEMENT RECOMMANDÉS de prendre en charge la fonctionnalité d'informations sur le lieu.

Si un bouton de désactivation global des commandes utilisateur pour Passpoint est fourni, les implémentations suivantes:

  • [C-3-1] DOIT activer Passpoint par défaut.
Emplacement du Wi-Fi (délai aller-retour Wi-Fi - DAR)

Implémentations pour les appareils:

Si les implémentations d'appareils incluent la prise en charge de la localisation Wi-Fi et exposent le à des applications tierces, ils:

  • [C-1-1] DOIT implémenter les API WifiRttManager, comme décrit dans le Documentation du SDK
  • [C-1-2] DOIT déclarer le flag de fonctionnalité android.hardware.wifi.rtt.
  • [C-1-3] DOIT appliquer de manière aléatoire l'adresse MAC source pour chaque rafale DAR qui s'exécute alors que l'interface Wi-Fi sur laquelle le texte en temps réel est en cours d'exécution n'est associé à aucun point d'accès.
  • [C-1-4] DOIT être précis à 2 mètres au maximum avec une bande passante de 80 MHz le 68ème centile (calculé à l'aide de la fonction de distribution cumulative).
  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ de le signaler avec précision, dans un rayon de 1,5 mètre. à 80 MHz au 68e centile (calculé avec le de distribution cumulative).
7.4.2.6. Déchargement Wi-Fi Keepalive

Implémentations pour les appareils:

  • DEVRAIT inclure la prise en charge du déchargement Wi-Fi keepalive.

Si les implémentations d'appareils incluent la prise en charge du déchargement Wi-Fi keepalive et les exposent à des applications tierces, ils:

  • [C-1-1] DOIT prendre en charge l'API SocketKeepAlive.
  • [C-1-2] DOIT prendre en charge au moins trois emplacements keepalive simultanés sur le Wi-Fi

Si les implémentations d'appareils n'incluent pas la prise en charge du déchargement Wi-Fi keepalive, ils:

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

Implémentations pour les appareils:

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

7.4.2.8. Validation du certificat du serveur Wi-Fi d'entreprise

Si le certificat du serveur Wi-Fi n'est pas validé ou si le serveur Wi-Fi nom de domaine non défini, implémentations d'appareils:

  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ de ne pas donner à l'utilisateur la possibilité de ajoutez manuellement le réseau Wi-Fi d'entreprise dans l'application Paramètres.
7.4.2.9. Confiance lors de la première utilisation (TOFU)

Si les implémentations d'appareils sont compatibles avec la confiance lors de la première utilisation (TOFU) et permettent à l'utilisateur de définir des configurations WPA/WPA2/WPA3-Enterprise, ils:

  • [C-4-1] DOIT fournir à l'utilisateur l'option de choisir d'utiliser TOFU.

7.4.3. Bluetooth

Si les appareils sont compatibles avec le profil audio Bluetooth, ils:

  • DEVRAIT prendre en charge les codecs audio avancés et les codecs audio Bluetooth (par exemple, LDAC)

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

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

Si les implémentations d'appareils déclarent android.hardware.vr.high_performance fonctionnalité, ils:

  • [C-1-1] DOIT être compatible avec les technologies Bluetooth 4.2 et Bluetooth LE Data Length Extension.

Android est compatible avec le Bluetooth et le Bluetooth à basse consommation.

Si les implémentations de l'appareil incluent la prise en charge du Bluetooth et du Bluetooth Low Energy, ils:

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

Si les implémentations d'appareils sont compatibles avec la technologie BLE (Bluetooth basse consommation), elles:

  • [C-3-1] DOIT déclarer la fonctionnalité matérielle android.hardware.bluetooth_le.
  • [C-3-2] DOIT activer le Bluetooth basé sur le profil d'attribut générique (GATT) telles que décrites dans la documentation du SDK android.bluetooth.
  • [C-3-3] DOIT indiquer la valeur correcte pour BluetoothAdapter.isOffloadedFilteringSupported() pour indiquer si le logique de filtrage pour ScanFilter est implémentée.
  • [C-3-4] DOIT indiquer la valeur correcte pour BluetoothAdapter.isMultipleAdvertisementSupported() pour indiquer si la publicité à faible consommation d'énergie est prise en charge.

  • [C-3-5] DOIT implémenter un délai avant expiration d'une adresse privée pouvant être résolue (RPA, Resolvable Private Address) de plus de 15 minutes et alterner les adresses une fois le délai expiré afin de protéger la confidentialité des utilisateurs. lorsque l'appareil utilise activement la technologie BLE pour l'analyse ou la publicité. Pour éviter les attaques chronophages, les intervalles de temporisation DOIVENT également être aléatoires entre 5 et 15 minutes.

  • DEVRAIT prendre en charge le déchargement de la logique de filtrage sur le chipset Bluetooth lors de la mise en œuvre de l'API ScanFilter.

  • DEVRAIT permettre le déchargement de la recherche par lot sur le chipset Bluetooth.

  • DEVRAIT prendre en charge les annonces multiples comportant au moins 4 emplacements.

Si les implémentations d'appareils sont compatibles avec la technologie Bluetooth LE et utilisez-la pour la localisation, ils:

  • [C-4-1] DOIT fournir une affordance d'utilisateur pour activer/désactiver la lecture de valeur via l'API système BluetoothAdapter.isBleScanAlwaysAvailable().

Si les implémentations d'appareils incluent la compatibilité avec la technologie Bluetooth LE et les appareils auditifs Profil, tel que décrit à la section Compatibilité des appareils auditifs avec Bluetooth LE:

Si les implémentations de l'appareil prennent en charge le Bluetooth ou le Bluetooth basse consommation, ils:

  • [C-6-1] DOIT restreindre l'accès aux métadonnées Bluetooth (comme les résultats) qui pourrait être utilisée pour déterminer la position de l'appareil, sauf si l'application à l'origine de la demande transmet un android.permission.ACCESS_FINE_LOCATION ; vérification des autorisations en fonction de son état actuel de premier plan/arrière-plan.

Si les implémentations de l'appareil sont compatibles avec le Bluetooth ou le Bluetooth à basse consommation et que le fichier manifeste de l'application n'inclut pas de déclaration du développeur indiquant qu'ils ne dérivent pas la localisation à l'aide du Bluetooth, puis:

Si les implémentations d'appareils renvoient true pour BluetoothAdapter.isLeAudioSupported(), ils:

  • [C-7-1] DOIT prendre en charge le client monodiffusion.
  • [C-7-2] DOIT prendre en charge 2M PHY.
  • [C-7-3] DOIT prendre en charge la publicité LE Extended.
  • [C-7-4] DOIT prendre en charge au moins deux connexions CIS dans un pipeline CIG.
  • [C-7-5] DOIT activer le client de monodiffusion BAP, le coordinateur de l'ensemble CSIP, le serveur MCP contrôleur VCP, serveur CCP simultanément.
  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'activer le client monodiffusion HAP.

Si les implémentations d'appareils renvoient true pour BluetoothAdapter.isLeAudioBroadcastSourceSupported(), ils:

  • [C-8-1] DOIT prendre en charge au moins 2 liens BIS dans un BIG.
  • [C-8-2] DOIT activer la source de diffusion BAP et l'assistant de diffusion BAP simultanément.
  • [C-8-3] DOIT prendre en charge la publicité LE Periodic.

Si les implémentations d'appareils renvoient true pour BluetoothAdapter.isLeAudioBroadcastAssistantSupported(), ils:

  • [C-9-1] DOIT être compatible avec PAST (Periodic Advertising Sync Transfer).
  • [C-9-2] DOIT prendre en charge la publicité LE Periodic.

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

  • [C-10-1] Les mesures RSSI DOIVENT être comprises entre +/-9 dB pour 95% de mesures à un mètre de distance d'un dispositif de référence transmettant à ADVERTISE_TX_POWER_HIGH dans l'environnement en ligne.

  • [C-10-2] DOIT inclure des corrections Rx/Tx pour réduire les écarts par canal afin que les mesures sur chacun des trois canaux, sur chacune des antennes (si plusieurs sont utilisés), se trouvent à plus ou moins 3 dB les uns des autres pendant 95% des des mesures.

  • [C-SR-2] Il est FORTEMENT RECOMMANDÉ de mesurer et de compenser le décalage reçu par Assurez-vous que la valeur médiane du RSSI BLE est de -60 dBm +/-10 dB à 1 m de distance dispositif de référence émettant à ADVERTISE_TX_POWER_HIGH, où les appareils sont orientées de sorte qu'elles se trouvent sur des "plans parallèles" ; dont les écrans sont orientés dans la direction souhaitée.

  • [C-SR-3] Il est FORTEMENT RECOMMANDÉ de mesurer et de compenser le décalage Tx Assurez-vous que la valeur médiane du RSSI BLE est de -60 dBm à +/-10 dB lors de la recherche à partir d'une référence appareil positionné à 1 m de distance et émettant ADVERTISE_TX_POWER_HIGH, où les appareils sont orientés de manière à ce qu'ils soient allumés "plans parallèles" avec des écrans orientés dans la même direction.

    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 de Assurez-vous que la valeur médiane du RSSI BLE est de -55 dBm +/-10 dB à 1 m de distance appareil de référence émettant à ADVERTISE_TX_POWER_HIGH.
  • [C-10-4] DOIT mesurer et compenser le décalage Tx pour Assurez-vous que la valeur médiane du RSSI BLE est de -55 dBm à +/-10 dB lors de la recherche à partir d'une référence appareil positionné à 1 m de distance et émettant ADVERTISE_TX_POWER_HIGH

Il est FORTEMENT RECOMMANDÉ de suivre les étapes de configuration des mesures spécifiées dans Exigences concernant l'étalonnage de la présence

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 se trouver dans les rôles de topologie de connexion.
    • Confidentialité de la couche de liaison LE
    • Une "liste de résolution" Taille d'au moins huit entrées

7.4.4. Communication en champ proche

Implémentations pour les appareils:

  • DEVRAIT inclure un émetteur-récepteur et le matériel associé pour la fonctionnalité NFC. (NFC).
  • [C-0-1] DOIT implémenter android.nfc.NdefMessage et android.nfc.NdefRecord même si elles n'incluent pas la compatibilité NFC ou déclarez la caractéristique android.hardware.nfc, car les classes représentent de représentation de données indépendant du protocole.

Si les implémentations d'appareils incluent du matériel NFC et prévoient de le mettre à la disposition des applications tierces, elles:

  • [C-1-1] DOIT signaler la fonctionnalité android.hardware.nfc à partir du Méthode android.content.pm.PackageManager.hasSystemFeature().
  • DOIT être capable de lire et d'écrire des messages NDEF via le protocole NFC suivant : standard comme indiqué ci-dessous:
  • [C-1-2] DOIT être capable d'agir en tant que lecteur/rédacteur sur le forum NFC (tel que défini par la spécification technique du forum NFC NFCForum-TS-DigitalProtocol-1.0) via les normes NFC suivantes:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS X 6319-4)
    • ISO Dep (ISO 14443-4)
    • Types de tags du forum NFC 1, 2, 3, 4, 5 (définis par le forum NFC)

  • [C-SR-1] VIVEMENT RECOMMANDÉ pour être capable de lire et d'écrire des données NDEF de messages et de données brutes via les normes NFC suivantes. Notez que alors que les normes NFC sont citées comme FORTEMENT RECOMMANDÉES, les la définition de compatibilité d'une version future va modifier ces à DOIT. Ces normes sont facultatives dans cette version, mais seront obligatoires dans les prochaines versions. Appareils nouveaux et existants exécutant cette version de Nous encourageons vivement Android à respecter ces exigences dès maintenant. ils pourront passer aux futures versions de la plate-forme.

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

  • DOIT être en mode de détection NFC lorsque l'appareil est activé avec l'écran est actif et l'écran de verrouillage est déverrouillé.

  • DOIT être capable de lire le code-barres et l'URL (s'ils sont encodés) Code-barres NFC Thinfilm produits.

Notez que les liens accessibles au public ne sont pas disponibles pour les normes JIS, ISO et NFC. Spécifications du forum mentionnées ci-dessus.

Android est compatible avec le mode HCE (émulation de carte hôte NFC).

Si les implémentations d'appareils incluent un chipset de contrôleur NFC compatible avec la technologie HCE (pour NfcA et/ou NfcB) et prennent en charge le routage des ID d'application (AID), ils:

  • [C-2-1] DOIT indiquer la constante de caractéristique android.hardware.nfc.hce.
  • [C-2-2] DOIT être compatible avec les API NFC HCE définies dans le SDK Android.

Si les implémentations d'appareils incluent un chipset de contrôleur NFC compatible avec la technologie HCE pour la NFC et implémenter cette fonctionnalité pour les applications tierces, ils:

  • [C-3-1] DOIT indiquer la constante de caractéristique android.hardware.nfc.hcef.
  • [C-3-2] DOIT implémenter les API d'émulation de cartes NfcF comme défini dans le SDK Android.

Si les implémentations d'appareils sont compatibles avec la technologie NFC générale comme décrit dans ce document, et prendre en charge les technologies MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF sur MIFARE Classic) dans le rôle de lecteur/rédacteur:

  • [C-4-1] DOIT implémenter les API Android correspondantes, comme indiqué dans le document le SDK Android.
  • [C-4-2] DOIT signaler la fonctionnalité com.nxp.mifare android.content.pm.PackageManager.hasSystemFeature() . Notez qu'il ne s'agit pas d'une fonctionnalité Android standard et que, par conséquent, apparaissent comme une constante dans la classe android.content.pm.PackageManager.

7.4.5. Protocoles de mise en réseau et API

Capacité réseau minimale

Implémentations pour les appareils:

  • [C-0-1] DOIT inclure la prise en charge d'une ou plusieurs formes de la mise en réseau de données. Plus précisément, les implémentations d'appareils DOIVENT inclure la prise en charge des au moins une norme de données capable de 200 Kbit/s ou plus. Exemples de technologies répondant à cette exigence incluent EDGE, HSPA, EV-DO, 802.11g, réseau Ethernet et Bluetooth PAN.
  • DEVRAIT également prendre en charge au moins un service de données sans fil courant standard, telle que 802.11 (Wi-Fi), lorsqu'une norme de réseau physique (comme Ethernet) est la connexion de données principale.
  • PEUT mettre en œuvre plusieurs formes de connectivité de données.
IPv6

Implémentations pour les appareils:

  • [C-0-2] DOIT inclure une pile réseau IPv6 et être compatible avec le protocole IPv6 à l'aide des API gérées, telles que java.net.Socket et java.net.URLConnection, ainsi que les API natives, telles que AF_INET6 sockets.
  • [C-0-3] DOIT activer IPv6 par défaut.
    • DOIT s'assurer que la communication IPv6 est aussi fiable que l'IPv4, par exemple:
      • [C-0-4] DOIT maintenir la connectivité IPv6 en mode Sommeil.
      • [C-0-5] La limitation du débit NE DOIT PAS entraîner la perte d'adresses IPv6 sur l'appareil sur tout réseau compatible IPv6 qui utilise des durées de vie RA de d'au moins 180 secondes.
  • [C-0-6] DOIT fournir aux applications tierces une connectivité IPv6 directe au réseau lorsqu'ils sont connectés à un réseau IPv6, sans aucune forme d'adresse ou la traduction de port qui s'effectue localement sur l'appareil. Les API gérées, telles que Socket#getLocalAddress ou Socket#getLocalPort) et les API NDK telles que getsockname() ou IPV6_PKTINFO DOIVENT renvoyer l'adresse IP adresse et le port qui sont réellement utilisés pour envoyer et recevoir des paquets sur le réseau et est visible en tant qu'adresse IP et port sources pour les serveurs Internet (Web).

Le niveau requis de compatibilité IPv6 dépend du type de réseau, comme indiqué dans les exigences suivantes.

Si les appareils sont compatibles avec le Wi-Fi, ils:

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

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

  • [C-2-1] DOIT prendre en charge les opérations à double pile et IPv6 uniquement sur Ethernet.

Si les appareils sont compatibles avec les données mobiles, ils:

  • [C-3-1] DOIT prendre en charge les opérations IPv6 (IPv6 uniquement et éventuellement double pile) sur mobile.

Si les implémentations d'appareils sont compatibles avec plusieurs types de réseaux (par exemple, Wi-Fi et les données mobiles), elles:

  • [C-4-1] DOIT respecter simultanément les exigences ci-dessus sur chaque réseau lorsque l'appareil est connecté simultanément à plusieurs types de réseaux.
Portails captifs

Un portail captif est un réseau qui nécessite une connexion afin de obtenir un accès à Internet.

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

  • [C-1-1] DOIT fournir une application de portail captif pour gérer l'intent ACTION_CAPTIVE_PORTAL_SIGN_IN et afficher la page de connexion au portail captif, en envoyant cette intention, sur à l'API System ConnectivityManager#startCaptivePortalApp(Network, Bundle)
  • [C-1-2] DOIT détecter les portails captifs et accepter la connexion via l'application de portail captif lorsque l'appareil est connecté à n'importe quel type de réseau, y compris les réseaux mobiles/cellulaires, Wi-Fi, Ethernet ou Bluetooth.
  • [C-1-3] DOIT prendre en charge la connexion aux portails captifs à l'aide d'un DNS en texte clair Lorsque l'appareil est configuré pour utiliser le mode DNS strict privé.
  • [C-1-4] DOIT utiliser un DNS chiffré conformément à la documentation du SDK android.net.LinkProperties.getPrivateDnsServerName et android.net.LinkProperties.isPrivateDnsActive pour tout le trafic réseau qui ne communique pas explicitement avec un portail captif.
  • [C-1-5] DOIT s'assurer que, lorsque l'utilisateur se connecte à un appareil réseau, le réseau par défaut utilisé par les applications (tel que renvoyé par ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback, et utilisé par défaut par les API de réseau Java telles que java.net.Socket, et les API natives telles que connect()) est tout autre réseau disponible qui fournit un accès à Internet, le cas échéant.

7.4.6. Paramètres de synchronisation

Implémentations pour les appareils:

  • [C-0-1] DOIT activer par défaut le paramètre de synchronisation automatique du maître pour que La méthode getMasterSyncAutomatically() renvoie "true".

7.4.7. Économiseur de données

Si les implémentations d'appareils incluent une connexion limitée, voici les types de connexions:

  • [C-SR-1] FORTEMENT RECOMMANDÉ de fournir le mode Économiseur de données.

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

  • [C-1-1] DOIT prendre en charge toutes les API du ConnectivityManager comme décrit dans la documentation du SDK

Si les implémentations d'appareils ne proposent pas le mode Économiseur de données:

7.4.8. Éléments sécurisés

Si les implémentations d'appareils sont compatibles avec Open Mobile API des éléments sécurisés et les mettent à la disposition d'applications tierces, ils:

7.4.9. UWB

Si les implémentations d'appareils incluent la prise en charge pour 802.1.15.4 et exposer la fonctionnalité à une application tierce, ils:

  • [C-1-1] DOIT implémenter l'API Android correspondante dans android.uwb.
  • [C-1-2] DOIT signaler l'indicateur de fonctionnalité matérielle android.hardware.uwb.
  • [C-1-3] DOIT prendre en charge tous les profils UWB pertinents définis dans Android la mise en œuvre.
  • [C-1-4] DOIT fournir une affordance utilisateur pour permettre à l'utilisateur d'activer/de désactiver l'UWB radio activée/désactivée.
  • [C-1-5] DOIT faire en sorte que les applications qui utilisent la radio UWB détiennent l'autorisation UWB_RANGING. (dans le groupe d'autorisations NEARBY_Devices).
  • [C-SR-1] SONT FORTEMENT RECOMMANDÉS de réussir les tests de conformité les tests de certification définis par les organismes de presse, dont les suivants : FIRA, CCC et CSA.
  • [C-1-6] DOIT s'assurer que les mesures de distance sont comprises entre +/-15 cm pour 95% des mesures dans un environnement à 1 m de distance dans un environnement non réfléchissante.
  • [C-1-7] DOIT veiller à ce que la médiane des mesures de distance soit à 1 m de l'appareil de référence se situe dans la plage de [0,75 m, 1,25 m], où la vérité terrain distance mesurée à partir du bord supérieur de l'appareil testé. tenu face vers le haut et incliné de 45 degrés.
  • [C-SR-2] EST FORTEMENT RECOMMANDÉ de suivre les étapes de configuration des mesures spécifié dans Exigences concernant l'étalonnage de la présence

7.5. Caméras

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

  • [C-1-1] DOIT déclarer le flag de fonctionnalité android.hardware.camera.any.
  • [C-1-2] DOIT être possible pour qu'une application puisse allouer simultanément 3 bitmaps RGBA_8888 correspondant à la taille des images produites par le capteur ayant la résolution la plus élevée de l'appareil, alors que l'appareil photo est ouvert l'objectif de l'aperçu de base et capturez tout de même.
  • [C-1-3] DOIT s'assurer que l'application d'appareil photo par défaut préinstallée Gestion des intents MediaStore.ACTION_IMAGE_CAPTURE MediaStore.ACTION_IMAGE_CAPTURE_SECURE, ou MediaStore.ACTION_VIDEO_CAPTURE, est responsable de la suppression de la position de l'utilisateur dans les métadonnées de l'image avant en l'envoyant à l'application réceptrice lorsque celle-ci ne ont ACCESS_FINE_LOCATION.

Si les implémentations d'appareils sont compatibles avec la capacité de sortie HDR 10 bits, les conditions suivantes s'appliquent:

  • [C-2-1] DOIT prendre en charge au moins le profil HDR HLG pour chaque appareil photo. compatible avec une sortie 10 bits.
  • [C-2-2] DOIT prendre en charge une sortie 10 bits pour la caméra arrière principale ou la caméra frontale principale.
  • [C-SR-1] SONT FORTEMENT RECOMMANDÉS de prendre en charge une sortie 10 bits pour les instances caméras.
  • [C-2-3] DOIT prendre en charge les mêmes profils HDR pour tous Sous-caméras physiques compatibles BACKWARD_COMPATIBLE d'une caméra logique l'appareil photo logique lui-même.

Pour les appareils photo logiques compatibles avec la technologie HDR 10 bits et qui implémentent la android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO, ils:

  • [C-3-1] DOIT prendre en charge le basculement entre tous les dispositifs physiques rétrocompatibles Cameras via la commande CONTROL_ZOOM_RATIO de la caméra logique.

7.5.1. Caméra arrière

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

Commencer les nouvelles exigences

Une caméra arrière est une caméra orientée vers l'extérieur qui capture les scènes de l'autre côté de l'appareil, à l'instar d'un appareil photo traditionnel, sur les appareils portables, situé sur le côté de l'appareil, en face de l'écran.

Mettre fin aux nouvelles exigences

Implémentations pour les appareils:

  • DEVRAIT inclure une caméra arrière.

Si les implémentations d'appareils incluent au moins une caméra arrière:

  • [C-1-1] DOIT signaler le flag de fonctionnalité android.hardware.camera et android.hardware.camera.any
  • [C-1-2] DOIT avoir une résolution d'au moins 2 mégapixels.
  • DEVRAIT mettre en œuvre un autofocus matériel ou logiciel. dans le pilote de l'appareil photo (transparent pour les logiciels de l'application).
  • PEUVENT comporter du matériel à mise au point fixe ou EDOF (profondeur de champ étendue).
  • PEUT inclure un flash.

Si la caméra dispose d'un flash:

  • [C-2-1], la lampe du flash NE DOIT PAS être allumée tant qu'un android.hardware.Camera.PreviewCallback instance a été enregistrée sur une surface d'aperçu de l'appareil photo, à moins que l'application n'ait explicitement activé Flash en activant les attributs FLASH_MODE_AUTO ou FLASH_MODE_ON d'un objet Camera.Parameters. Notez que cette contrainte ne s'applique pas l'application de caméra système intégrée à l'appareil, mais uniquement pour des applications à l'aide de Camera.PreviewCallback.

7.5.2. Caméra frontale

Une caméra frontale est une caméra située du même côté de l'appareil comme écran. c'est-à-dire un appareil photo généralement utilisé pour filmer l'utilisateur, que pour la visioconférence et d'autres applications similaires.

Commencer les nouvelles exigences

Une caméra frontale est une caméra orientée vers l'utilisateur qui est généralement utilisée pour créer des images l'utilisateur, par exemple pour la visioconférence et des applications similaires ; sur portable appareils, c’est-à-dire une caméra située du même côté de l’appareil que l’écran.

Mettre fin aux nouvelles exigences

Implémentations pour les appareils:

  • PEUT inclure une caméra frontale.

Si les implémentations d'appareils incluent au moins une caméra avant:

  • [C-1-1] DOIT signaler le flag de fonctionnalité android.hardware.camera.any et android.hardware.camera.front
  • [C-1-2] DOIT avoir une résolution VGA d'au moins (640 x 480 pixels).
  • [C-1-3] NE DOIT PAS utiliser une caméra frontale par défaut pour le API Camera et NE DOIT PAS configurer l'API pour traiter une caméra frontale comme l'appareil photo arrière par défaut, même s'il s'agit de la seule caméra de l'appareil.
  • [C-1-4] L'aperçu de l'appareil photo DOIT être mis en miroir horizontalement par rapport à spécifiée par l'application lorsque celle-ci a a explicitement demandé à l'appareil photo faire pivoter l'écran via un appel à la fonction android.hardware.Camera.setDisplayOrientation() . À l'inverse, l'aperçu DOIT être dupliqué avec l'aperçu par défaut de l'appareil sur l'axe horizontal lorsque l'application actuelle ne demande pas explicitement faire pivoter l'écran de la caméra via un appel à android.hardware.Camera.setDisplayOrientation() .
  • [C-1-5] NE DOIT PAS dupliquer l'image fixe ou le flux vidéo finaux capturés renvoyées aux rappels de l'application ou validée dans le stockage multimédia.
  • [C-1-6] DOIT mettre en miroir l'image affichée par la vue post-View de la même manière. en tant que flux d'image d'aperçu de la caméra.
  • PEUT inclure des fonctionnalités (autofocus, flash, etc.) à la disposition de caméras arrière, comme décrit dans la section 7.5.1.

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

  • [C-2-1] L'aperçu de l'appareil photo DOIT être mis en miroir horizontalement par rapport à l'orientation actuelle de l'appareil.

7.5.3. Caméra externe

Commencer les nouvelles exigences

Une caméra externe est une caméra qui peut être fixée physiquement ou détachée l'implémentation de l'appareil à tout moment et peut aller dans n'importe quelle direction ; comme des ports USB caméras.

Mettre fin aux nouvelles exigences

Implémentations pour les appareils:

  • PEUT inclure la prise en charge d'une caméra externe qui n'est pas nécessairement connectés en permanence.

Si les implémentations d'appareils prennent en charge une caméra externe, celles-ci:

  • [C-1-1] DOIT déclarer le flag de fonctionnalité de la plate-forme android.hardware.camera.external et android.hardware camera.any.
  • [C-1-2] DOIT être compatible avec la classe vidéo USB (UVC 1.0 ou version ultérieure) si le câble la caméra se connecte via le port hôte USB.
  • [C-1-3] DOIT réussir les tests CTS de la caméra avec une caméra externe physique connectés. Pour en savoir plus sur le test CTS de la caméra, consultez source.android.com.
  • DEVRAIT prendre en charge les compressions vidéo telles que MJPEG pour permettre le transfert flux non codés de haute qualité (images brutes ou compressées indépendamment) flux).
  • PEUT prendre en charge plusieurs appareils photo.
  • PEUT prendre en charge l'encodage vidéo basé sur la caméra.

Si l'encodage vidéo basé sur la caméra est compatible:

  • [C-2-1] Une conversation non codé / flux MJPEG (QVGA ou résolution supérieure) DOIT être accessible aux l'implémentation de l'appareil.

7.5.4. Comportement de l'API Camera

Android inclut deux packages d'API pour accéder à l'appareil photo : le plus récent L'API android.hardware.camera2 expose les commandes de niveau inférieur de l'appareil photo à l'application, y compris des flux efficaces d'utilisation intensive ou par flux sans copie, et des contrôles par image exposition, gain, gains de balance des blancs, conversion des couleurs, suppression du bruit, accentuation et plus encore.

L'ancien package d'API,android.hardware.Camera, est marqué comme obsolète dans Android 5.0, mais qui devrait toujours être disponible pour les applications à utiliser. Appareil Android les mises en œuvre DOIVENT garantir la continuité de la prise en charge de l'API, comme décrit dans dans cette section et dans le SDK Android.

Toutes les fonctionnalités communes à la classe obsolète android.hardware.Camera et le package android.hardware.camera2 plus récent DOIT avoir des performances équivalentes. et la qualité des deux API. Par exemple, avec des paramètres équivalents, la vitesse et la précision de l'autofocus doivent être identiques, et la qualité des images capturées doit être identique doit être identique. Caractéristiques qui dépendent de la sémantique différente des deux API ne sont pas obligatoires, mais DOIVENT être aussi proches que possible. que possible.

Les implémentations d'appareils DOIVENT mettre en œuvre les comportements suivants pour les pour tous les appareils photo disponibles. Implémentations pour les appareils:

  • [C-0-1] DOIT utiliser android.hardware.PixelFormat.YCbCr_420_SP pour l'aperçu Données fournies aux rappels d'application lorsqu'une application n'a jamais appelé android.hardware.Camera.Parameters.setPreviewFormat(int)
  • [C-0-2] DOIT être en outre au format d'encodage NV21 lorsqu'une application enregistre un android.hardware.Camera.PreviewCallback instance, et le système appelle la méthode onPreviewFrame() et l'aperçu est YCbCr_420_SP, les données de l'octet [] sont transmises à onPreviewFrame(). Autrement dit, NV21 DOIT être la valeur par défaut.
  • [C-0-3] DOIT prendre en charge le format YV12 (comme indiqué dans le constante android.graphics.ImageFormat.YV12) pour les aperçus de l'appareil photo pour les deux caméras avant et arrière pour android.hardware.Camera. (Le matériel l'encodeur vidéo et l'appareil photo peuvent utiliser n'importe quel format de pixel natif, mais l'appareil la mise en œuvre DOIT être compatible avec la conversion vers YV12.)
  • [C-0-4] DOIT prendre en charge les android.hardware.ImageFormat.YUV_420_888 et android.hardware.ImageFormat.JPEG en tant que sorties via API android.media.ImageReader pour android.hardware.camera2 appareils qui diffuser des annonces REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE dans android.request.availableCapabilities.
  • [C-0-5] DOIT quand même implémenter la version complète de l'API Camera dans la documentation du SDK Android, que l'appareil inclut un autofocus matériel ou d'autres fonctionnalités. Par exemple, les appareils photo sans autofocus DOIT quand même appeler n'importe quelle android.hardware.Camera.AutoFocusCallback instances (même si aucune instance par rapport à un appareil sans autofocus). Notez que cela s'applique aux images caméras ; Par exemple, même si la plupart des caméras avant ne prennent pas en charge l'autofocus, les rappels de l'API doivent toujours être "falsifiés" comme décrit ici.
  • [C-0-6] DOIT reconnaître et respecter chaque nom de paramètre définie comme une constante android.hardware.Camera.Parameters et android.hardware.camera2.CaptureRequest. Inversement, les implémentations d'appareils NE DOIVENT PAS respecter ni reconnaître des constantes de chaîne transmis à la méthode android.hardware.Camera.setParameters(), à l'exception de documentées en tant que constantes sur android.hardware.Camera.Parameters. En d'autres termes, les implémentations d'appareils DOIVENT prendre en charge tous les paramètres standards de l'appareil photo si le matériel autorise, et NE DOIT PAS être compatible avec les types de paramètres Appareil photo personnalisés. Par exemple, les implémentations d'appareils compatibles avec la capture d'image utilisant des techniques d'imagerie HDR (High Dynamic Range) DOIT être compatible avec les paramètres de l'appareil photo Camera.SCENE_MODE_HDR
  • [C-0-7] DOIT indiquer le niveau d'assistance approprié concernant le android.info.supportedHardwareLevel telle que décrite dans le SDK Android et signaler la options de fonctionnalité du framework.
  • [C-0-8] DOIT également déclarer les capacités de chaque caméra android.hardware.camera2 via le Propriété android.request.availableCapabilities et déclarer les indicateurs de fonctionnalité appropriés ; DOIT définir le flag de fonctionnalité si l'une des caméras associées prend en charge cette fonctionnalité.
  • [C-0-9] DOIT diffuser l'Camera.ACTION_NEW_PICTURE chaque fois qu'une nouvelle photo est prise par l'appareil photo et que l'entrée a été ajoutée à Media Store.
  • [C-0-10] DOIT diffuser l'Camera.ACTION_NEW_VIDEO chaque fois qu'une nouvelle vidéo est enregistrée par la caméra et que l'entrée de a été ajoutée à Media Store.
  • [C-0-11] DOIT disposer de toutes les caméras accessibles via le android.hardware.Camera API également accessible via le android.hardware.camera2 API.
  • [C-0-12] DOIT s'assurer que l'apparence du visage n'est PAS altérée, y compris (sans s'y limiter la modification de la géométrie du visage, de la carnation ou lissage de la peau android.hardware.camera2 ou android.hardware.Camera API.
  • [C-SR-1] Pour les appareils équipés de plusieurs caméras RVB, être proche et de faire face dans la même direction, il est FORTEMENT RECOMMANDÉ de prendre en charge un appareil photo logique qui liste capacité CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA se composant de toutes les caméras RVB orientées dans cette direction comme des sous-périphériques physiques.

Si les implémentations d'appareils fournissent une API d'appareil photo propriétaire à des applications tierces, ils:

7.5.5. Orientation de l'appareil photo

Si les appareils sont équipés d'une caméra avant ou arrière, la ou les caméras suivantes :

  • [C-1-1] DOIT être orienté de sorte que la dimension longue de la caméra soit alignée avec la dimension longue de l'écran. Autrement dit, lorsque l'appareil est tenu en mode paysage les appareils photo DOIVENT enregistrer les images en mode paysage. Ce s'applique quelle que soit l'orientation naturelle de l'appareil ; c'est-à-dire qu'elle s'applique en mode paysage et en mode portrait.

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

  • L'appareil intègre des écrans à géométrie variable, tels que des écrans pliables ou à charnière s'affiche.
  • Lorsque l'état de pliage ou de charnière de l'appareil change, l'appareil passe l'orientation portrait-principal à l'orientation paysage-principal (ou inversement).

Commencer les nouvelles exigences

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

Mettre fin aux nouvelles exigences

7.6. Mémoire et stockage

7.6.1. Mémoire et stockage minimaux

Implémentations pour les appareils:

  • [C-0-1] DOIT inclure un Gestionnaire de téléchargement que des applications PEUVENT utiliser pour télécharger des fichiers de données et qu'elles DOIVENT être capables de télécharger des fichiers individuels d'une taille minimale de 100 Mo par défaut ; "cache" l'emplacement.

7.6.2. Stockage partagé des applications

Implémentations pour les appareils:

  • [C-0-1] DOIT proposer un espace de stockage partagé par les applications, souvent désigné "stockage externe partagé" ou "stockage partagé d'application" ou par le système chemin d'accès "/sdcard" où il est installé.
  • [C-0-2] DOIT être configuré avec un espace de stockage partagé installé par défaut, "prêt à l'emploi", que le stockage soit implémenté ou non un composant de stockage interne ou un support de stockage amovible (par exemple, Secure (emplacement pour carte numérique).
  • [C-0-3] DOIT installer le stockage partagé de l'application directement sur le chemin d'accès Linux sdcard ou inclure un lien symbolique Linux entre sdcard et l'installation réelle point d'accès.
  • [C-0-4] DOIT activer espace de stockage cloisonné par défaut pour tous Applications ciblant le niveau d'API 29 ou supérieur, sauf dans les cas suivants:
    • Lorsque l'application a demandé android:requestLegacyExternalStorage="true" dans leur fichier manifeste.
  • [C-0-5] DOIT masquer les métadonnées de localisation, telles que les balises GPS Exif, stockées dans des fichiers multimédias lorsque vous accédez à ces fichiers via MediaStore, sauf si l'application appelante détient l'autorisation ACCESS_MEDIA_LOCATION.

Les implémentations d'appareils PEUVENT répondre aux exigences ci-dessus en utilisant l'un des suivantes:

  • Stockage amovible accessible par l'utilisateur, tel qu'un emplacement pour carte SD (Secure Digital).
  • Une partie de la mémoire de stockage interne (non amovible) mise en œuvre dans le Projet Android Open Source (AOSP)

Si les implémentations d'appareils utilisent un espace de stockage amovible pour satisfaire aux exigences ci-dessus à ces exigences:

  • [C-1-1] DOIT implémenter une interface utilisateur toast ou pop-up avertissant l'utilisateur lorsqu'aucun support de stockage n'est inséré dans l'emplacement.
  • [C-1-2] DOIT inclure un support de stockage au format FAT (une carte SD, par exemple) ou montrer sur la boîte et sur tout autre matériel disponible au moment de l'achat. support s'achète séparément.

Si les implémentations d'appareils utilisent une partie de l'espace de stockage non amovible pour satisfaire les exigences ci-dessus, ils:

  • DEVRAIT utiliser l'implémentation AOSP de l'application interne partagée stockage.
  • PEUT partager l'espace de stockage avec les données privées de l'application.

Si les implémentations d’appareils disposent d’un port USB compatible avec le mode périphérique USB, ils:

  • [C-3-1] DOIT fournir un mécanisme permettant d'accéder aux données de l'application le stockage partagé à partir d'un ordinateur hôte.
  • DEVRAIT exposer le contenu des deux chemins de stockage de manière transparente Service d'analyse multimédia d'Android et android.provider.MediaStore.
  • PEUT utiliser le stockage de masse USB, mais DEVRAIT utiliser le protocole de transfert multimédia pour satisfaire cette exigence.

Si les appareils disposent d'un port USB avec mode périphérique USB et prise en charge Media Transfer Protocol, ils:

  • DOIT être compatible avec l'hôte MTP Android de référence, Android File Transfer (Transfert de fichiers Android).
  • DEVRAIT signaler une classe de périphérique USB de 0x00.
  • DEVRAIT indiquer le nom d'interface USB « MTP ».

7.6.3. Stockage adoptable

Si l'appareil est censé être mobile par nature, contrairement à la télévision, les implémentations d'appareils sont les suivantes:

  • [C-SR-1] VIVEMENT RECOMMANDÉ d'implémenter le stockage adoptable dans un emplacement stable sur le long terme, car toute déconnexion accidentelle peut causer une perte ou une corruption de données.

Si le port du périphérique de stockage amovible est dans un emplacement stable à long terme, par exemple dans le compartiment à piles ou un autre couvercle de protection, les implémentations d'appareils sont les suivantes:

7.7. USB

Si les appareils disposent d'un port USB, ils:

  • DEVRAIT prendre en charge le mode périphérique USB et le mode hôte USB.
  • DEVRAIT prendre en charge la désactivation du signal de données via USB.

7.7.1. Mode périphérique USB

Si les implémentations d'appareils comprennent un port USB compatible avec le mode périphérique:

  • [C-1-1] Le port DOIT pouvoir être connecté à un hôte USB doté d'un câble d'un port USB Type-A ou Type-C.
  • [C-1-2] DOIT indiquer la valeur correcte de iSerialNumber en standard USB descripteur d'appareil via android.os.Build.SERIAL.
  • [C-1-3] DOIT détecter les chargeurs 1,5 A et 3 A par résistance de type C standard et DOIT détecter les modifications apportées à l'annonce si elles prennent en charge USB Type-C.
  • [C-SR-1] Le port DOIT utiliser un facteur de forme micro-B, micro-AB ou USB Type-C. Les appareils Android, nouveaux et existants, sont VIVEMENT RECOMMANDÉS pour répondre à ces exigences requises pour pouvoir passer aux versions futures de la plate-forme.
  • [C-SR-2] Le port DOIT se trouver en bas de l'appareil (en fonction de l'orientation naturelle) ou activez la rotation logicielle de l'écran pour toutes les applications (y compris l'écran d'accueil), de sorte que l'écran s'affiche correctement l'appareil est orienté avec le port situé en bas. Android (existant et nouveau) il est VIVEMENT RECOMMANDÉ de répondre à ces exigences afin qu'ils puissent vous pourrez effectuer une mise à niveau vers les futures versions de la plate-forme.
  • [C-SR-3] DEVRAIT implémenter la prise en charge de la consommation d'un courant de 1,5 A pendant le bip HS et le trafic, comme indiqué dans la version 1.2 des spécifications relatives à la recharge de la batterie via USB. Les appareils Android, nouveaux et existants, sont VIVEMENT RECOMMANDÉS pour répondre à ces exigences requises pour pouvoir passer aux versions futures de la plate-forme.
  • [C-SR-4] FORTEMENT RECOMMANDÉ de ne pas prendre en charge de recharge qui modifient la tension Vbus au-delà des niveaux par défaut ou altèrent les rôles récepteur/source en tant que tels peuvent entraîner des problèmes d'interopérabilité avec chargeurs ou appareils compatibles avec les modes USB Power Delivery standard. Alors que cette fonctionnalité est qualifiée de « VENTEMENT RECOMMANDÉ ». Dans les futures versions d'Android, nous peut EXIGER tous les appareils de type C pour assurer une interopérabilité totale avec les de type C.
  • [C-SR-5] FORTEMENT RECOMMANDÉ de prendre en charge Power Delivery pour les données et le changement de rôle d’alimentation lorsqu’ils prennent en charge les modes USB Type-C et hôte USB.
  • DEVRAIT prendre en charge Power Delivery pour la charge haute tension et prendre en charge Modes alternatifs tels que l'affichage extérieur.
  • DEVRAIT implémenter l'API et la spécification Android Open Accessory (AOA) en tant que dans la documentation du SDK Android.

Si les implémentations d'appareils comprennent un port USB et mettent en œuvre l'AOA ils:

  • [C-2-1] DOIT déclarer la prise en charge de la fonctionnalité matérielle android.hardware.usb.accessory
  • [C-2-2] La classe de stockage de masse USB DOIT inclure la chaîne "android". au fin de la description de l'interface iInterface chaîne de la mémoire de stockage de masse USB

7.7.2. Mode hôte USB

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

  • [C-1-1] DOIT implémenter l'API hôte USB Android, comme indiqué dans le SDK Android et DOIT déclarer la prise en charge de la fonctionnalité matérielle android.hardware.usb.host
  • [C-1-2] DOIT implémenter la connexion de périphériques USB standards en d'autres termes, ils DOIVENT:
    • Disposer d'un port de type C sur l'appareil ou expédier les produits avec un ou plusieurs câbles adaptés à un appareil port propriétaire vers un port USB type-C standard (appareil USB Type-C).
    • être munis d'un appareil de type A ou livrés avec un ou plusieurs câbles adaptés à l'appareil ; port propriétaire à un port USB type-A standard.
    • disposer d'un port micro-AB intégré, qui DOIT être livré avec un câble adapté vers un port standard de type A.
  • [C-1-3] NE DOIT PAS être expédié avec un adaptateur USB de type A ou micro-AB vers un port de type C (réceptacle).
  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ de mettre en œuvre Classe audio USB comme indiqué dans la documentation du SDK Android.
  • DEVRAIT prendre en charge le chargement du périphérique USB connecté sur l'hôte mode; annonce une source avec un courant d'au moins 1,5 A, comme spécifié dans le la section "Paramètres de résiliation" Version 1.2 des spécifications concernant le câble et le connecteur USB Type-C pour l'USB Type-C ou l'utilisation de la plage de courant de sortie du port de recharge en aval (CDP) comme spécifiées dans Spécifications concernant la recharge de la batterie via USB, révision 1.2 pour les connecteurs micro-AB.
  • DEVRAIT implémenter et prendre en charge les normes USB Type-C.

Si les implémentations d'appareils comprennent un port USB prenant en charge le mode hôte et un câble USB en classe audio, ils:

  • [C-2-1] DOIT être compatible avec la classe USB HID.
  • [C-2-2] DOIT prendre en charge la détection et la mise en correspondance des données HID suivantes spécifiés dans les tableaux d'utilisation USB HID et la demande d'utilisation des commandes vocales vers le KeyEvent constantes comme ci-dessous:
      .
    • ID d'utilisation (0x0CD) de la page d'utilisation (0xC): KEYCODE_MEDIA_PLAY_PAUSE
    • ID d'utilisation (0x0E9) de la page d'utilisation (0xC): KEYCODE_VOLUME_UP
    • ID d'utilisation de la page d'utilisation (0xC) (0x0EA): KEYCODE_VOLUME_DOWN
    • ID d'utilisation (0x0CF) de la page d'utilisation (0xC): KEYCODE_VOICE_ASSIST

Si les implémentations d’appareils comprennent un port USB prenant en charge le mode hôte et Storage Access Framework (SAF), elles:

  • [C-3-1] DOIT reconnaître tout protocole MTP (Media Transfer Protocol) connecté à distance. appareils et rendre leur contenu accessible via ACTION_GET_CONTENT, Intents ACTION_OPEN_DOCUMENT et ACTION_CREATE_DOCUMENT. .

Si les implémentations d'appareils comprennent un port USB compatible avec le mode hôte et un port USB Type-C, ils:

  • [C-4-1] DOIT implémenter la fonctionnalité de port double rôle telle que définie par la clé USB Spécification Type-C (section 4.5.1.3.3). Pour doubles Ports de rôle : sur les appareils équipés d'un connecteur audio 3, 5 mm, le récepteur USB la détection (mode hôte) PEUVENT être désactivées par défaut, mais cela DOIT être possible pour pour l'activer.
  • [C-SR-2] FORTEMENT RECOMMANDÉ pour la compatibilité avec DisplayPort, DEVRAIT prendre en charge USB tarifs de données SuperSpeed et sont VIVEMENT RECOMMANDÉES pour prendre en charge Power Delivery. pour l'échange des rôles des données et du pouvoir.
  • [C-SR-3] FORTEMENT RECOMMANDÉ DE NE PAS prendre en charge le mode accessoire de l'adaptateur audio décrits dans l'annexe A du Version 1.2 des spécifications concernant le câble USB Type-C et le connecteur
  • DEVRAIT implémenter le modèle try.* le plus approprié pour la facteur de forme de l'appareil. Par exemple, un appareil portable DEVRAIT implémenter la le modèle try.SNK.

7.8. Audio

Micro

Si les implémentations d'appareils comprennent un micro, elles:

  • [C-1-1] DOIT indiquer la constante de caractéristique android.hardware.microphone.
  • [C-1-2] DOIT respecter les exigences concernant l'enregistrement audio des section 5.4.
  • [C-1-3] DOIT respecter les exigences de latence audio de section 5.6.
  • [C-SR-1] SONT FORTEMENT RECOMMANDÉS de prendre en charge l'enregistrement par ultrasons, comme décrit ici. comme indiqué dans la section 7.8.3.

Si l'intégration d'un appareil n'inclut pas de micro:

  • [C-2-1] NE DOIT PAS signaler la constante de caractéristique android.hardware.microphone.
  • [C-2-2] DOIT implémenter l'API d'enregistrement audio au moins comme no-ops, conformément section 7.

Sortie audio

Si les implémentations d'appareils incluent un haut-parleur ou une sortie audio/multimédia d'un périphérique de sortie audio, comme un connecteur audio 3,5 mm à 4 conducteurs ou Port en mode hôte USB à l'aide de la classe audio USB:

  • [C-1-1] DOIT indiquer la constante de caractéristique android.hardware.audio.output.
  • [C-1-2] DOIT répondre aux exigences de lecture audio des section 5.5.
  • [C-1-3] DOIT respecter les exigences de latence audio de section 5.6.
  • [C-SR-1] FORTEMENT RECOMMANDÉ de prendre en charge la lecture par ultrasons, comme décrit dans la description comme indiqué dans la section 7.8.3.

Si les appareils ne comprennent pas de haut-parleur ni de port de sortie audio:

  • [C-2-1] NE DOIT PAS signaler la fonctionnalité android.hardware.audio.output.
  • [C-2-2] DOIT implémenter les API liées à la sortie audio au moins comme no-ops.

Dans le cadre de cette section, un "port de sortie" est un interface physique comme un connecteur audio 3, 5 mm, un port HDMI ou un port en mode hôte USB avec classe audio USB. Prise en charge de la sortie audio sur des protocoles basés sur la radio tels que Bluetooth, Les réseaux Wi-Fi et mobiles ne peuvent pas inclure de "port de sortie".

Ports audio analogiques

Pour être compatible avec casques et autres accessoires audio en utilisant la prise audio 3, 5 mm dans l'écosystème Android. incluent un ou plusieurs ports audio analogiques, qui:

  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure au moins l'un des Assurez-vous que le ou les ports audio sont un connecteur audio de 3,5 mm à 4 conducteurs.

Si les appareils sont équipés d'un connecteur audio 3, 5 mm à quatre conducteurs:

  • [C-1-1] DOIT prendre en charge la lecture audio sur des casques stéréo et stéréo avec un micro.
  • [C-1-2] DOIT prendre en charge les prises audio TRRS dans l'ordre de broche CTIA.
  • [C-1-3] DOIT prendre en charge la détection et le mappage avec les codes de clavier pour en suivant trois plages d'impédance équivalente entre le micro et le sol conducteurs sur la prise audio:
    • 70 ohms ou moins: KEYCODE_HEADSETHOOK
    • 210-290 ohm: KEYCODE_VOLUME_UP
    • 360-680 ohm: KEYCODE_VOLUME_DOWN
  • [C-1-4] DOIT déclencher ACTION_HEADSET_PLUG lors de l'insertion d'une fiche, mais que lorsque tous les contacts de la prise ont touché les segments appropriés. sur le connecteur.
  • [C-1-5] DOIT être capable de générer au moins 150 mV ± 10% de la tension de sortie sur une impédance de haut-parleur de 32 ohms.
  • [C-1-6] DOIT avoir une tension de biais du micro comprise entre 1,8 V et 2,9 V.
  • [C-1-7] DOIT détecter et mapper le code de clavier pour plage d'impédance équivalente entre le micro et les conducteurs de terre sur la prise audio:
    • 110-180 ohm:KEYCODE_VOICE_ASSIST
  • [C-SR-2] Il est FORTEMENT RECOMMANDÉ de prendre en charge les prises audio avec le module OMTP. l'ordre de épinglage.
  • [C-SR-3] Sont FORTEMENT RECOMMANDÉS pour les enregistrements audio stéréo. casques avec micro.

Si les appareils sont équipés d'un connecteur audio 3,5 mm à 4 conducteurs et acceptent un micro, et diffusez le android.intent.action.HEADSET_PLUG avec le valeur supplémentaire du micro définie sur 1, il:

  • [C-2-1] DOIT prendre en charge la détection du micro sur l'audio branché accessoire.
Ports audio numériques

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

7.8.3. Presque ultra-sons

Le son proche par ultrasons correspond à la bande 18,5 kHz à 20 kHz.

Implémentations pour les appareils:

Si PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND est "true", les conditions suivantes DOIVENT être satisfaites Sources audio VOICE_RECOGNITION et UNPROCESSED:

  • [C-1-1] La puissance moyenne du micro dans la bande 18,5 kHz-20 kHz Ne doit PAS être inférieure de plus de 15 dB à la réponse à 2 kHz.
  • [C-1-2] Rapport signal/bruit non pondéré du micro sur une plage de 18,5 kHz à 20 kHz pour un ton de 19 kHz à -26 dBFS NE DOIT PAS être inférieur à 50 dB.

Si PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND est "true" :

  • [C-2-1] La réponse moyenne du haut-parleur sur la plage de 18,5 kHz à 20 kHz DOIT être inférieure ou égale à 40 dB en dessous de la réponse à 2 kHz.

7.8.4. Intégrité du signal

Implémentations pour les appareils:

  • DEVRAIT fournir un chemin de signal audio sans faille pour les deux entrées et aux flux de sortie sur les appareils portables, tels que définis lors d'un test d'une minute par chemin. Effectuer un test avec OboeTester "Test de glitch automatisé".

Le test nécessite un dongle de bouclage audio, directement dans un connecteur 3,5 mm et/ou en combinaison avec un adaptateur USB-C vers 3,5 mm. Tous les ports de sortie audio DOIVENT être testés.

OboeTester accepte actuellement les chemins d'accès AAudio. Par conséquent, le Les combinaisons suivantes DOIVENT être testées pour détecter les problèmes avec AAudio:

Mode Performances Partage Taux d'échantillonnage sortant En chan Chans.
FAIBLE_LATENCY EXCLUSIF NON DÉFINI 1 2
FAIBLE_LATENCY EXCLUSIF NON DÉFINI 2 1
FAIBLE_LATENCY PARTAGÉ NON DÉFINI 1 2
FAIBLE_LATENCY PARTAGÉ NON DÉFINI 2 1
AUCUNE PARTAGÉ 48000 1 2
AUCUNE PARTAGÉ 48000 2 1
AUCUNE PARTAGÉ 44100 1 2
AUCUNE PARTAGÉ 44100 2 1
AUCUNE PARTAGÉ 16000 1 2
AUCUNE PARTAGÉ 16000 2 1

Un flux fiable DOIT répondre aux critères suivants en matière de signal sur bruit Ratio (SNR) et distorsion harmonique totale (THD) pour le sinus de 2 000 Hz.

Transducteur THD Numéro SNR
haut-parleur intégré principal, mesuré à l'aide d'un micro de référence externe < 3,0% >= 50 dB
microphone intégré principal, mesuré à l'aide d'un haut-parleur de référence externe < 3,0% >= 50 dB
Connecteurs analogiques 3,5 mm intégrés, testés avec l'adaptateur de rebouclage < 1 % >= 60 dB
Adaptateurs USB fournis avec le téléphone, testés avec l'adaptateur de rebouclage < 1,0% >= 60 dB

7.9. Réalité virtuelle

Android inclut des API et des installations permettant de créer des applications de "réalité virtuelle" (RV) y compris des expériences RV de haute qualité sur mobile. Appareil les implémentations DOIVENT implémenter ces API et ces comportements, comme indiqué dans cette section.

7.9.1. Mode Réalité virtuelle

Android prend en charge Mode RV, une fonctionnalité qui gère le rendu stéréoscopique des notifications et désactive les composants d'UI d'un système monoculaire, tandis qu'une application de RV est axée sur l'utilisateur.

7.9.2. Mode Réalité virtuelle - Hautes performances

Si les implémentations d'appareils sont compatibles avec le mode RV, ils:

  • [C-1-1] DOIT comporter au moins deux cœurs physiques.
  • [C-1-2] DOIT déclarer la fonctionnalité android.hardware.vr.high_performance.
  • [C-1-3] DOIT prendre en charge le mode Performances soutenues.
  • [C-1-4] DOIT être compatible avec OpenGL ES 3.2.
  • [C-1-5] DOIT accepter android.hardware.vulkan.level 0.
  • DEVRAIT prendre en charge android.hardware.vulkan.level 1 ou version ultérieure.
  • [C-1-6] DOIT mettre en œuvre EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync EGL_IMG_context_priority, EGL_EXT_protected_content EGL_EXT_image_gl_colorspace, et exposer les extensions dans la liste des extensions EGL disponibles.
  • [C-1-8] DOIT mettre en œuvre GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures, et exposer les extensions dans la liste des extensions GL disponibles.
  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'implémenter GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture, et exposer les extensions dans la liste des extensions GL disponibles.
  • [C-SR-2] SONT FORTEMENT RECOMMANDÉS de prendre en charge Vulkan 1.1.
  • [C-SR-3] Sont FORTEMENT RECOMMANDÉS d'implémenter VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image, et de l'exposer dans la liste des extensions Vulkan disponibles.
  • [C-SR-4] Il est FORTEMENT RECOMMANDÉ d'exposer au moins une famille de files d'attente Vulkan dans laquelle flags contiennent à la fois VK_QUEUE_GRAPHICS_BIT et VK_QUEUE_COMPUTE_BIT, et queueCount est supérieur ou égal à 2.
  • [C-1-7] Le GPU et l'écran DOIVENT pouvoir synchroniser l'accès à l'instance de sorte qu'un rendu visuel en alternance, à 60 ips, avec deux les contextes de rendu seront affichés sans artefact de déchirure visible.
  • [C-1-9] DOIT implémenter la prise en charge de AHardwareBuffer les indicateurs AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA et AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT comme décrit dans le NDK.
  • [C-1-10] DOIT implémenter la prise en charge des AHardwareBuffer avec tout combinaison des options d'utilisation AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT pour au moins les formats suivants: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT
  • [C-SR-5] Sont FORTEMENT RECOMMANDÉS pour prendre en charge l'allocation de AHardwareBuffer avec plusieurs couches et indicateurs et formats spécifiés dans C-1-10.
  • [C-1-11] DOIT prendre en charge le décodage H.264 d'au moins 3 840 x 2 160 à 30 images par seconde compressé à une vitesse moyenne de 40 Mbit/s (équivalent à 4 instances de 1 920 x 1 080 à 30 FPS - 10 Mbit/s ou 2 instances de 1 920 x 1 080 à 60 FPS - 20 Mbit/s).
  • [C-1-12] DOIT être compatible avec HEVC et VP9, DOIT être capable de décoder au moins 1 920 x 1 080 à 30 FPS compressé à une moyenne de 10 Mbit/s et DEVRAIT être capable de décoder 3 840 x 2 160 pixels à une fréquence de 30 FPS à 20 Mbit/s (équivalent à 4 instances de 1 920 x 1 080 pixels à 30 FPS-5 Mbit/s).
  • [C-1-13] DOIT prendre en charge l'API HardwarePropertiesManager.getDeviceTemperatures et renvoyer des valeurs précises de température cutanée.
  • [C-1-14] DOIT disposer d'un écran intégré et sa résolution DOIT être au moins 1920 x 1080.
  • [C-SR-6] Il est FORTEMENT RECOMMANDÉ d'avoir une résolution d'écran d'au moins 2560 x 1440.
  • [C-1-15] L'écran DOIT mettre à jour une fréquence d'au moins 60 Hz en mode RV.
  • [C-1-17] L'écran DOIT accepter un mode à faible persistance d'une durée de ≤ 5 millisecondes la persistance étant définie comme la durée nécessaire qu'un pixel émet de la lumière.
  • [C-1-18] DOIT prendre en charge le Bluetooth 4.2 et l'extension de longueur de données Bluetooth LE section 7.4.3.
  • [C-1-19] DOIT soutenir et signaler correctement Type de canal direct pour tous les types de capteurs par défaut suivants:
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [C-SR-7] SONT FORTEMENT RECOMMANDÉS de soutenir le TYPE_HARDWARE_BUFFER type de canal direct pour tous les types de canaux directs répertoriés ci-dessus.
  • [C-1-21] DOIT respecter les consignes relatives au gyroscope, à l'accéléromètre et au magnétomètre exigences pour android.hardware.hifi_sensors, comme indiqué dans section 7.3.9.
  • [C-SR-8] SONT FORTEMENT RECOMMANDÉS de soutenir le android.hardware.sensor.hifi_sensors.
  • [C-1-22] DOIT avoir une latence du mouvement de bout en bout du photon qui ne doit pas être supérieure à 28 millisecondes.
  • [C-SR-9] Il est FORTEMENT RECOMMANDÉ d'avoir une latence entre le mouvement et le photon de bout en bout pas plus de 20 millisecondes.
  • [C-1-23] DOIT avoir un ratio de première image, c'est-à-dire le ratio entre les luminosité des pixels sur la première image après une transition du noir au le blanc et la luminosité des pixels blancs, dans un état stable, d'au moins 85%.
  • [C-SR-10] Il est FORTEMENT RECOMMANDÉ d'utiliser un ratio de première image d'au moins 90%.
  • PEUT fournir un cœur exclusif au premier plan application et PEUVENT prendre en charge l'API Process.getExclusiveCores pour renvoyer Nombre de cœurs de processeur réservés au premier plan supérieur application.

Si un cœur exclusif est pris en charge, le noyau:

  • [C-2-1] NE DOIT pas autoriser l'exécution d'autres processus d'espace utilisateur sur celui-ci (à l'exception des pilotes de périphériques utilisés par l'application), mais PEUT autoriser certains noyaux des processus à exécuter si nécessaire.

7.10. Technologie tactile

Commencer les nouvelles exigences

Les dispositifs conçus pour être portés à la main peuvent inclure un capteur haptique à usage général. actionneur utilisé dans les applications, y compris pour attirer l'attention sonneries, alarmes et notifications, ainsi que des commentaires tactiles d'ordre général.

Si les implémentations d'appareils N'incluent PAS ce type d'actionneur haptique à usage général, ils:

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

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

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

Mettre fin aux nouvelles exigences

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

7.11. Classe Media Performance

La classe de performance multimédia de l'implémentation de l'appareil peut être obtenue à partir de l'API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. Conditions requises for Media Performance Class sont définies pour chaque version d'Android commençant par R (version 30). La valeur spéciale 0 indique que l'appareil n'est pas la classe de performance multimédia.

Si les implémentations d'appareils renvoient une valeur non nulle pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

  • [C-1-1] DOIT renvoyer au moins une valeur de android.os.Build.VERSION_CODES.R.

  • [C-1-2] DOIT être une implémentation d'appareil portable.

  • [C-1-3] DOIT respecter toutes les conditions requises pour la "classe de performance multimédia" décrits comme indiqué dans la section 2.2.7.

En d'autres termes, la classe de performance multimédia dans Android T n'est définie que pour appareils portables de version T, S ou R.

Reportez-vous à la section 2.2.7 pour les informations spécifiques à chaque appareil. exigences.

8. Performances et puissance

Certains critères minimaux de performances et de puissance sont essentiels à l'expérience utilisateur. et un impact sur les hypothèses de base que les développeurs auraient l'application.

8.1. Cohérence de l'expérience utilisateur

Une interface utilisateur fluide peut être fournie à l'utilisateur final s'il y a certains afin de garantir la cohérence d'une fréquence d'images et de temps de réponse des applications et des jeux. Les implémentations d'appareils, selon le type d'appareil, PEUVENT avoir des exigences mesurables en termes de latence de l'interface utilisateur et de tâche comme décrit dans la section 2.

8.2. Performances d'accès aux E/S de fichiers

Il fournit une référence commune pour garantir des performances d'accès aux fichiers cohérentes sur le le stockage de données privées des applications (partition /data) permet aux développeurs d'applis pour définir une attente appropriée qui aiderait à concevoir son logiciel. Appareil selon le type d'appareil, elles PEUVENT être soumises à certaines exigences décrites dans la section 2 pour en savoir plus et d'écriture:

  • Performances d'écriture séquentielle. Mesure effectuée par l'écriture d'un fichier de 256 Mo avec Tampon d'écriture de 10 Mo.
  • Performances d'écriture aléatoire. Mesure effectuée à partir de l'écriture d'un fichier de 256 Mo en 4 Ko un tampon d'écriture.
  • Performances de lecture séquentielle. Mesure effectuée à partir de la lecture d'un fichier de 256 Mo avec Tampon d'écriture de 10 Mo.
  • Performances de lecture aléatoire. Mesure effectuée à partir de la lecture d'un fichier de 256 Mo en 4 Ko un tampon d'écriture.

8.3. Modes d'économie d'énergie

Si les implémentations d'appareils incluent des fonctionnalités permettant d'améliorer la gestion de l'alimentation de l'appareil inclus dans AOSP (par exemple, App Standby Bucket ou Sommeil) ou étendent les fonctionnalités pour appliquer des restrictions plus strictes que le bucket de mise en veille des applications LIMITÉ:

  • [C-1-1] NE DOIT PAS vous écarter de l'implémentation AOSP pour le déclenchement. la maintenance, les algorithmes de wakeup et l'utilisation de paramètres système globaux ou DeviceConfig de mise en veille des applications et d'économie d'énergie.
  • [C-1-2] NE DOIT PAS déroger à l'implémentation AOSP pour l'utilisation ou DeviceConfig pour gérer la limitation des tâches, les alarmes pour les applications de chaque bucket en mode Mise en veille des applications.
  • [C-1-3] NE DOIT PAS vous écarter de l'implémentation AOSP pour le nombre Buckets App Standby pour la mise en veille des applications.
  • [C-1-4] DOIT implémenter les buckets de mise en veille des applications et Sommeil comme décrit dans la section Gestion de l'alimentation.
  • [C-1-5] DOIT renvoyer true pour PowerManager.isPowerSaveMode() lorsque l'appareil est en mode Économie d'énergie.
  • [C-1-6] DOIT fournir une affordance utilisateur pour afficher toutes les applications exemptées de mise en veille des applications et d'économie d'énergie, ou d'optimisations de la batterie, et DOIT mettre en œuvre les ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS Intention de demander à l'utilisateur d'autoriser une application à ignorer la batterie et des optimisations.
  • [C-SR-1] SONT FORTEMENT RECOMMANDÉS de fournir une affordance à l'utilisateur pour activer et désactiver l'économiseur de batterie.
  • [C-SR-2] SONT FORTEMENT RECOMMANDÉS de fournir à l'utilisateur l' affordance d'afficher tous les Applications exemptées des modes d'économie d'énergie Sommeil et Mise en veille des applications

Si les implémentations d'appareils étendent les fonctionnalités de gestion de l'alimentation incluses dans AOSP, et cette extension applique des restrictions plus strictes Rare App Standby Bucket, reportez-vous à la section 3.5.1.

En plus des modes d'économie d'énergie, les implémentations d'appareils Android PEUVENT mettre en œuvre tout ou partie des quatre états de veille, tels que définis par la Configuration and Power Interface (ACPI).

Si les implémentations d'appareils implémentent les états d'alimentation S4 tels que définis par le ACPI, ils:

  • [C-1-1] NE DOIT entrer dans cet état qu'après une action explicite de l'utilisateur mettre l'appareil en mode inactif (par exemple, en fermant un couvercle qui est physiquement partie de l'appareil ou éteindre un véhicule ou une télévision) et avant que l'utilisateur réactive l'appareil (par exemple, en ouvrant le capot ou en tournant le véhicule). ou la télévision).

Si les implémentations d'appareils implémentent les états d'alimentation S3 tels que définis par le ACPI, ils:

  • [C-2-1] DOIT respecter l'état C-1-1 ci-dessus, ou DOIT passer à l'état S3 uniquement lorsque l'état les applications n'ont pas besoin des ressources système (écran ou processeur, par exemple).

    À l'inverse, il DOIT quitter l'état S3 lorsque les applications tierces ont besoin des ressources système, comme décrit dans ce SDK.

    Par exemple, alors que les applications tierces demandent à conserver l'écran via FLAG_KEEP_SCREEN_ON ou maintenir le processeur en fonctionnement PARTIAL_WAKE_LOCK, l'appareil NE DOIT PAS passer en mode S3, sauf dans les cas décrits ci-après. dans C-1-1, l'utilisateur a effectué une action explicite pour placer l'appareil l'état inactif. À l'inverse, lorsqu'une tâche qu'une application tierce via JobScheduler ou Firebase Cloud Messaging à des applications tierces, l'appareil DOIT quitter l'état S3, sauf si l'utilisateur a désactivé l'appareil. Ces informations ne sont pas exhaustives et AOSP implémente de nombreux signaux de wakeup qui déclenchent un wakeup. à partir de cet état.

8.4. Comptabilisation de la consommation d'énergie

Une comptabilisation et des rapports plus précis de la consommation d'énergie offrent les avantages et les outils permettant d'optimiser la consommation de l'application.

Implémentations pour les appareils:

  • [C-SR-1] FORTEMENT RECOMMANDÉ de fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle pour chaque composant matériel, ainsi que la décharge approximative de la batterie causée par composants au fil du temps, comme indiqué sur le site du projet Android Open Source.
  • [C-SR-2] VIVEMENT RECOMMANDÉ de consigner toutes les valeurs de consommation d'énergie en milliampères heures (mAh).
  • [C-SR-3] VIVEMENT RECOMMANDÉ de signaler la consommation d'énergie du processeur par UID de chaque processus. Le projet Android Open Source répond aux exigences définies dans le Implémentation du module de noyau uid_cputime.
  • [C-SR-4] FORTEMENT RECOMMANDÉ de rendre cette consommation électrique disponible via le adb shell dumpsys batterystats au développeur de l'application.
  • DOIT être attribué au composant matériel lui-même s'il n'est pas en mesure de attribuer la consommation d'énergie des composants matériels à une application.

8.5. Performances constantes

Les performances peuvent fluctuer considérablement pour les applications de longue durée, soit à cause des autres applications s'exécutant en arrière-plan, soit en raison de la limitation du processeur en raison des limites de température. Android inclut des interfaces de programmation de sorte que, lorsque si l'appareil en est capable, l'application au premier plan peut demander que pour optimiser l'allocation des ressources pour faire face à ces fluctuations.

Implémentations pour les appareils:

Si les implémentations d'appareils sont compatibles avec le mode Performances soutenues, elles:

  • [C-1-1] DOIT fournir à l'application de premier plan supérieure un niveau cohérent pendant au moins 30 minutes, lorsque l'application le demande.
  • [C-1-2] DOIT respecter les Window.setSustainedPerformanceMode() et d'autres API associées.

Si les implémentations d'appareils incluent au moins deux cœurs de processeur:

  • DEVRAIT fournir au moins un cœur exclusif pouvant être réservé application de premier plan.

Si les implémentations d'appareils permettent de réserver un cœur exclusif au principal application de premier plan, ils:

  • [C-2-1] DOIT le faire à l'aide du Process.getExclusiveCores() Méthode API : numéros d'identification des cœurs exclusifs pouvant être réservés par l'application de premier plan.
  • [C-2-2] NE DOIT PAS autoriser de processus d'espace utilisateur, à l'exception des pilotes de périphériques utilisés par l'application pour s'exécuter sur les cœurs exclusifs, mais PEUVENT permettre à certaines les processus du noyau pour s’exécuter selon les besoins.

Si les implémentations d'appareils ne sont pas compatibles avec un cœur exclusif, celles-ci:

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

Implémentations pour les appareils:

  • [C-0-1] DOIT implémenter un modèle de sécurité cohérent avec le modèle de sécurité de la plate-forme Android, tel que défini dans Document de référence sur la sécurité et les autorisations dans les API de la documentation pour les développeurs Android.

  • [C-0-2] DOIT prendre en charge l'installation d'appareils autosignés sans avoir besoin d'autorisations/certificats supplémentaires à des tiers/autorités.

Si les implémentations d'appareils déclarent android.hardware.security.model.compatible fonctionnalité, ils:

  • [C-1-1] DOIT respecter les exigences indiquées dans les sous-sections suivantes.

9.1. Autorisations

Implémentations pour les appareils:

  • [C-0-1] DOIT prendre en charge le modèle d'autorisations Android et le modèle de rôle Android tel que défini dans la documentation pour les développeurs Android. Plus précisément, ils doivent DOIT appliquer chaque autorisation et chaque rôle définis comme décrit dans les la documentation sur les SDK ; aucune autorisation, et aucun rôle ne peut être omis, modifié ou ignorées.

  • PEUT ajouter des autorisations supplémentaires, à condition que les nouvelles chaînes d’identifiant d’autorisation ne se trouvent pas dans l'espace de noms android.\*.

  • [C-0-2] Autorisations avec un protectionLevel de PROTECTION_FLAG_PRIVILEGED NE DOIT être accordée qu'aux applications préinstallées dans le ou les chemins privilégiés l'image système (ainsi que fichiers Apex) et être dans le sous-ensemble des autorisations explicitement ajoutées à la liste d'autorisation pour chaque application. La mise en œuvre d'AOSP répond à cette exigence en lisant et en respectant les les autorisations ajoutées à la liste d'autorisation pour chaque application à partir des fichiers du etc/permissions/ et en utilisant le chemin system/priv-app comme chemin chemin privilégié.

Les autorisations dont le niveau de protection est dangereux sont des autorisations d'exécution. Applications avec targetSdkVersion > 22 lors de l'exécution.

Implémentations pour les appareils:

  • [C-0-3] DOIT afficher une interface dédiée permettant à l'utilisateur de décider accorder ou non les autorisations d'exécution demandées une interface permettant à l'utilisateur de gérer les autorisations d'exécution.

  • [C-0-4] DOIT comporter une seule et même implémentation des deux de commande.

  • [C-0-5] NE DOIT PAS accorder d'autorisations d'exécution aux applications, à moins que:

    • Ils sont installés au moment de l'expédition de l'appareil, ET

    • Le consentement de l'utilisateur peut être obtenu avant l'application utilise l'autorisation,

      OU

    • Les autorisations d'exécution sont accordées par la règle d'octroi d'autorisation par défaut ou pour occuper un rôle de plate-forme.

  • [C-0-6] DOIT accorder l'autorisation android.permission.RECOVER_KEYSTORE uniquement pour les applications système qui enregistrent un agent de récupération correctement sécurisé. A un agent de récupération correctement sécurisé est défini comme un agent logiciel sur l'appareil qui se synchronise avec un stockage à distance hors appareil, qui est équipé du matériel sécurisé avec une protection équivalente ou supérieure à celle décrits dans Service Google Cloud Key Vault pour empêcher les attaques par force brute sur le facteur de connaissance de l'écran de verrouillage.

Implémentations pour les appareils:

  • [C-0-7] DOIT respecter les propriétés de l'autorisation d'accéder à la position Android lorsqu'une application demande les données de localisation ou d'activité physique via l'API Android standard ou un mécanisme propriétaire. Ces données incluent, sans s'y limiter:

    • la position de l'appareil (latitude et longitude, par exemple), comme décrit dans les section 9.8.8.
    • Informations permettant de déterminer ou d'estimer l'état (SSID, BSSID, ID de cellule GSM ou emplacement du réseau auquel l'appareil auquel il est connecté).
    • Activité physique de l'utilisateur ou classification de l'activité physique.

Plus précisément, les implémentations d'appareils:

  • [C-0-8] DOIT obtenir le consentement de l'utilisateur pour permettre à une application d'accéder les données de localisation ou d'activité physique.
  • [C-0-9] DOIT accorder une autorisation d'exécution UNIQUEMENT à l'application qui détient une autorisation suffisante, comme décrit sur le SDK. Par exemple : TelephonyManager#getServiceState nécessite android.permission.ACCESS_FINE_LOCATION).

Les seules exceptions aux propriétés de l'autorisation d'accéder à la position Android ci-dessus concernent les Applications qui n'accèdent pas à la position pour déterminer ou identifier la position de l'utilisateur en particulier:

  • Lorsque les applis détiennent l'autorisation RADIO_SCAN_WITHOUT_LOCATION.
  • Pour les besoins de configuration de l'appareil, lorsque les applications système contiennent Autorisation NETWORK_SETTINGS ou NETWORK_SETUP_WIZARD.

Les autorisations peuvent être marquées comme restreintes, ce qui modifie leur comportement.

  • [C-0-10] Les autorisations comportant l'indicateur hardRestricted NE DOIVENT PAS être accordé à une application, sauf dans les cas suivants:

    • Un fichier APK d'application se trouve dans la partition du système.
    • L'utilisateur attribue un rôle associé à hardRestricted des autorisations à une application.
    • Le programme d'installation accorde le hardRestricted à une application.
    • Une application se voit attribuer le hardRestricted sur une version antérieure d'Android.

  • [C-0-11] Les applications disposant d'une autorisation softRestricted DOIVENT être limitées un accès complet et NE DOIT PAS bénéficier d'un accès complet tant qu'il ne figure pas sur la liste d'autorisation, comme décrit dans les SDK, où un accès complet et limité est défini pour chaque softRestricted (par exemple, READ_EXTERNAL_STORAGE).

  • [C-0-12] NE DOIT PAS fournir de fonctions ni d'API personnalisées permettant de contourner les restrictions d'autorisation définies dans setPermissionPolicy et setPermissionGrantState API.

  • [C-0-13] DOIT utiliser les API AppOpsManager pour enregistrer et suivre chaque tout accès par programmation à des données protégées par des autorisations dangereuses Activités et services Android

  • [C-0-14] NE DOIT attribuer des rôles qu'aux applications dotées de fonctionnalités répondent aux exigences du poste.

  • [C-0-15] NE DOIT pas définir de rôles correspondant à des fonctionnalités en double ou sur-ensemble de rôles définis par la plate-forme.

Si les appareils signalent android.software.managed_users:

  • [C-1-1] NE DOIT PAS disposer des autorisations suivantes, accordées silencieusement par le admin:
    • Emplacement (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
    • Caméra (CAMERA)
    • Micro (RECORD_AUDIO)
    • Capteur corporel (BODY_SENSORS)
    • Activité physique (ACTIVITÉ_RECOGNITION)

Si les implémentations d'appareils permettent à l'utilisateur de choisir les applications pouvant pour se superposer aux autres applications avec une activité qui gère ACTION_MANAGE_OVERLAY_PERMISSION l'intention, ils:

  • [C-2-1] DOIT s'assurer que toutes les activités comportant des filtres d'intent pour ACTION_MANAGE_OVERLAY_PERMISSION ont le même écran d'UI, quelle que soit l'application les informations qu'il fournit.

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

  • [C-3-1] DOIT afficher une clause de non-responsabilité lors de la configuration de l'appareil entièrement géré (configuration du propriétaire de l'appareil) indiquant que l'administrateur informatique sera en mesure de autoriser les applications à contrôler les paramètres du téléphone, y compris le micro, l'appareil photo et emplacement, avec des options permettant à l'utilisateur de poursuivre ou de quitter la configuration SAUF si le l'administrateur a désactivé le contrôle des autorisations sur l'appareil.

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 pour la mise en œuvre d'appareils dans sections "9.8.6 Capture de contenu" "9.8.6 Données au niveau du système d'exploitation et de veille et 9.8.15 Implémentations d'API en bac à sable".

  • [C-4-2] NE DOIT PAS disposer de l'autorisation android.permission.INTERNET. C'est plus strict que les ÉLÉMENTS FORTEMENT RECOMMANDÉS indiqués 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, Multimédia, Téléphonie, SystemUI et composants offrant API Internet. Cette valeur est plus stricte que les recommandations FORTEMENT RECOMMANDÉES figurant dans à la section 9.8.6.

Commencer les nouvelles exigences

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

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

Mettre fin aux nouvelles exigences

9.2. UID et isolation de processus

Implémentations pour les appareils:

  • [C-0-1] DOIT prendre en charge l'application Android modèle de bac à sable, dans lequel chaque application s'exécute sous la forme d'un UID de style Unix unique et dans un processus distinct.
  • [C-0-2] DOIT prendre en charge l'exécution de plusieurs applications sous le même identifiant utilisateur Linux, à condition que les applications soient correctement signées et construit, comme défini dans le Documentation de référence sur la sécurité et les autorisations

9.3. Autorisations du système de fichiers

Implémentations pour les appareils:

9.4. Autres environnements d'exécution

Les implémentations d'appareils DOIVENT assurer la cohérence des mesures de sécurité et modèle d'autorisation, même s'ils incluent des environnements d'exécution qui exécutent des applications utilisant d'autres logiciels ou technologies que l'exécutable Dalvik Format ou code natif. Autrement dit :

  • [C-0-1] Les environnements d'exécution alternatifs DOIVENT être eux-mêmes des applications Android, et respecter le modèle de sécurité Android standard, tel que décrit dans d'autres sections comme indiqué dans la section 9.

  • [C-0-2] Les autres environnements d'exécution NE DOIVENT PAS être autorisés à accéder aux ressources protégée par des autorisations non demandées dans le AndroidManifest.xml de l'environnement d'exécution via l'élément <uses-permission> sur le mécanisme d'attention.

  • [C-0-3] Les environnements d'exécution alternatifs NE DOIVENT PAS permettre aux applications d'utiliser fonctionnalités protégées par des autorisations Android limitées aux applications système.

  • [C-0-4] Les environnements d'exécution alternatifs DOIVENT respecter le modèle de bac à sable Android et les applications installées utilisant un autre environnement d'exécution NE DOIVENT PAS réutiliser le bac à sable de toute autre application installée sur l'appareil, sauf via les mécanismes Android standard du partage d’un ID utilisateur et d’un certificat de signature.

  • [C-0-5] Les environnements d'exécution alternatifs NE DOIVENT PAS se lancer avec, accorder ou être accordés l'accès aux bacs à sable correspondant à d'autres applications Android.

  • [C-0-6] D'autres environnements d'exécution NE DOIVENT PAS être lancés, accordés ni accordés à d'autres applications tout droit de super-utilisateur (racine) ou de toute autre ID utilisateur.

  • [C-0-7] Lorsque les fichiers .apk des environnements d'exécution alternatifs sont inclus dans le fichier image système des implémentations de l'appareil, elle DOIT être signée avec une clé distincte à partir de la clé utilisée pour signer les autres applications incluses dans l'appareil mises en œuvre.

  • [C-0-8] Lors de l'installation d'applications, d'autres environnements d'exécution DOIVENT obtenir le consentement de l'utilisateur pour les autorisations Android utilisées par l'application.

  • [C-0-9] Lorsqu'une application doit utiliser une ressource d'appareil pour qui dispose d'une autorisation Android correspondante (comme Appareil photo, GPS, etc.), l'environnement d'exécution alternatif DOIT informer l'utilisateur que l'application pourra accéder à cette ressource.

  • [C-0-10] Lorsque l'environnement d'exécution n'enregistre pas les applications de cette manière, l'environnement d'exécution DOIT répertorier toutes les autorisations détenues par l'environnement d'exécution lui-même lors de l'installation d'une application utilisant cet environnement.

  • D'autres environnements d'exécution DOIVENT installer des applications via PackageManager dans des bacs à sable Android distincts (ID utilisateur Linux, etc.).

  • D'autres environnements d'exécution PEUVENT fournir un seul bac à sable Android partagé par tous des applications utilisant un autre environnement d'exécution.

9.5. Compatibilité multi-utilisateur

Android est compatible avec plusieurs utilisateurs. Il permet l'isolation complète et permet de cloner des profils utilisateur isolement partiel(c'est-à-dire un seul profil utilisateur supplémentaire de type android.os.usertype.profile.CLONE).

  • Les implémentations d'appareils PEUVENT, mais NE DOIVENT PAS activer le mode multi-utilisateur s'ils utilisent support amovible pour le stockage externe principal.

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

  • [C-1-2] DOIT, pour chaque utilisateur, mettre en œuvre cohérent avec le modèle de sécurité de la plate-forme Android, tel que défini dans Document de référence sur la sécurité et les autorisations dans les API.
  • [C-1-3] DOIT disposer d'un espace de stockage d'application partagé séparé et isolé (également appelés /sdcard) pour chaque instance d'utilisateur.
  • [C-1-4] DOIT s'assurer que les applications détenues et exécutées pour le compte ne peut pas répertorier, lire ou écrire dans les fichiers appartenant à un autre utilisateur, même si les données des deux utilisateurs sont stockées sur le même volume ou système de fichiers.
  • [C-1-5] DOIT chiffrer le contenu de la carte SD lorsque le mode multi-utilisateur est activé à l'aide d'une clé stockée uniquement sur un support non amovible accessible uniquement au système les implémentations d'appareils utilisent des supports amovibles pour les API de stockage externe. Comme cela rend le contenu multimédia illisible par un PC hôte, les implémentations d'appareils devront passer à MTP ou à un système similaire pour fournir aux PC hôtes les aux données de l'utilisateur actuel.

Si les implémentations d'appareils prennent en charge plusieurs utilisateurs, alors pour tous les utilisateurs, à l'exception de ceux créés spécialement pour exécuter des instances doubles d'une même application:

  • [C-2-1] DOIT disposer d'un espace de stockage d'application partagé séparé et isolé (également appelés /sdcard) pour chaque instance d'utilisateur.
  • [C-2-2] DOIT s'assurer que les applications appartenant à et exécutées sur ne peut ni répertorier, ni lire, ni écrire dans les fichiers dont le propriétaire est par un autre utilisateur, même si les données de ces deux utilisateurs sont stockées sur le même le volume ou le système de fichiers.

Les mises en œuvre d'appareils PEUVENT créer un seul profil utilisateur supplémentaire de type android.os.usertype.profile.CLONE par rapport à l'utilisateur principal (et uniquement à l'utilisateur principal) afin d'exécuter deux instances de la même application. Ces instances doubles partagent un stockage partiellement isolé, sont présentées utilisateur final dans le lanceur d’applications en même temps et apparaissent dans la même vue récentes. Par exemple, cela peut permettre à l'utilisateur d'installer deux instances d'une seule application sur un appareil avec double carte SIM.

Si les mises en œuvre de l’appareil créent le profil utilisateur supplémentaire mentionné ci-dessus, ils:

  • [C-3-1] DOIT fournir uniquement un accès à l'espace de stockage ou aux données accessible au profil utilisateur parent ou dont il est le propriétaire direct profil utilisateur supplémentaire.
  • [C-3-2] NE DOIT PAS avoir ceci comme profil professionnel.
  • [C-3-3] DOIT avoir des répertoires de données d'application privés isolés du parent compte utilisateur.
  • [C-3-4] NE DOIT PAS permettre la création d'un profil utilisateur supplémentaire est un propriétaire d'appareil provisionné (voir la section 3.9.1) ou autorise un propriétaire d'appareil sans supprimer le profil utilisateur supplémentaire au préalable.

Commencer les nouvelles exigences

Si les mises en œuvre de l’appareil créent le profil utilisateur supplémentaire mentionné ci-dessus, ils:

  • [C-4-5] DOIT distinguer visuellement les icônes des applications à double instance lorsque les icônes 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 et supprimer les données de l'application privée répertoires 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 Clone.
  • DEVRAIT inviter l'utilisateur à supprimer l'intégralité des données du profil de clonage lors de la dernière application clone supprimée.
  • [C-4-8] DOIT informer l'utilisateur que les données de l'application seront supprimées lors du clone application désinstallée ou permettent aux utilisateurs de conserver leurs données lorsque l'application est désinstallée de l'appareil.
  • [C-4-9] DOIT supprimer les répertoires de données d'applications privées ainsi que leur contenu lorsque l’utilisateur choisit de supprimer les données lors de la désinstallation.

  • [C-4-1] DOIT autoriser les intents ci-dessous provenant de l'API doit être géré par les applications de l'utilisateur principal de l'appareil:

    • 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 de l'élément restrictions applicables aux 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 synchronisation des 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 des autorisations et de l'espace de stockage distinctes pour applications exécutées dans ce profil supplémentaire

  • [C-4-5] DOIT autoriser uniquement les applications du profil supplémentaire qui disposent d'un l'activité du lanceur d'applications pour accéder aux contacts auxquels profil utilisateur parent.

Mettre fin aux nouvelles exigences

9.6. Avertissement relatif aux SMS premium

Android permet d'avertir les utilisateurs en cas de SMS premium. SMS premium messages sont des SMS envoyés à un service enregistré auprès d'un opérateur qui peut entraîner des frais pour l'utilisateur.

Si les implémentations d'appareils déclarent la prise en charge de android.hardware.telephony, ils:

  • [C-1-1] DOIT avertir les utilisateurs avant d'envoyer un SMS à un numéro identifié par des expressions régulières définies dans /data/misc/sms/codes.xml sur l'appareil. Le projet Android Open Source en amont fournit une implémentation qui répond à cette exigence.

9.7. Fonctionnalités de sécurité

Les implémentations d'appareils DOIVENT garantir la conformité avec les fonctionnalités de sécurité du noyau et de la plate-forme comme décrit ci-dessous.

Le bac à sable Android inclut des fonctionnalités qui utilisent le framework (SELinux), système de contrôle des accès obligatoire (MAC), système de bac à sable seccomp, etc. les fonctionnalités de sécurité dans le noyau Linux. Implémentations pour les appareils:

  • [C-0-1] DOIT maintenir la compatibilité avec les applications existantes, même lorsque SELinux ou toute autre fonctionnalité de sécurité sont implémentées en dessous de d'infrastructure.
  • [C-0-2] NE DOIT PAS avoir d'interface utilisateur visible violation a été détectée et bloquée par la fonctionnalité de sécurité implémentées sous le framework Android, mais PEUVENT disposer d'une interface utilisateur visible lorsqu'une violation de sécurité débloquée entraîne un exploit réussi.
  • [C-0-3] NE DOIT PAS rendre SELinux ou toute autre fonctionnalité de sécurité implémentée sous le framework Android, configurable pour l'utilisateur ou le développeur de l'application.
  • [C-0-4] NE DOIT PAS autoriser une application pouvant affecter une autre via une API (telle qu'une API Device Administration) pour configurer une stratégie qui rompt la compatibilité.
  • [C-0-5] DOIT diviser le framework multimédia en plusieurs processus est possible d'accorder l'accès à chaque processus de manière plus précise, décrit sur le site du projet Android Open Source.
  • [C-0-6] DOIT implémenter un mécanisme de bac à sable pour l'application du noyau qui permet de filtrer les appels système à l'aide d'une règle configurable les programmes multithread. Le projet Android Open Source en amont répond à cette en activant seccomp-BPF avec threadgroup (TSYNC) comme décrit ici, dans la section "Configuration du noyau" de source.android.com.

Les fonctionnalités d'intégrité du noyau et d'auto-protection font partie intégrante d'Android la sécurité. Implémentations pour les appareils:

  • [C-0-7] DOIT implémenter des mécanismes de protection contre le débordement de la mémoire tampon de la pile du noyau. Exemples : CC_STACKPROTECTOR_REGULAR et CONFIG_CC_STACKPROTECTOR_STRONG
  • [C-0-8] DOIT implémenter des protections strictes de la mémoire du noyau lorsque les fichiers exécutables le code est en lecture seule, les données en lecture seule ne sont pas exécutables et non accessibles en écriture ; et des données accessibles en écriture ne sont pas exécutables (par exemple, CONFIG_DEBUG_RODATA ou CONFIG_STRICT_KERNEL_RWX).
  • [C-0-9] DOIT implémenter des tailles d'objets statiques et dynamiques vérification des limites des copies entre espace utilisateur et espace noyau (par exemple, CONFIG_HARDENED_USERCOPY) sur les appareils livrés à l'origine avec un niveau d'API 28 ou version ultérieure.
  • [C-0-10] NE DOIT PAS exécuter la mémoire de l'espace utilisateur lors de l'exécution en mode noyau (par exemple, avec un PXN matériel ou émulé via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) sur les appareils était livré avec le niveau d'API 28 ou supérieur.
  • [C-0-11] NE DOIT PAS lire ni écrire de mémoire espace utilisateur dans le noyau en dehors des API d'accès usercopy normales (par exemple, PAN matériel ou émulée via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) sur les appareils livrés avec le niveau d'API 28 ou supérieur.
  • [C-0-12] DOIT implémenter l'isolation des tables de pages du noyau si le matériel est vulnérable à la faille CVE-2017-5754 sur tous les appareils livrés avec le niveau d'API à l'origine 28 ou version ultérieure (par exemple, CONFIG_PAGE_TABLE_ISOLATION ou CONFIG_UNMAP_KERNEL_AT_EL0).

  • [C-0-13] DOIT implémenter le renforcement de la prédiction de branche si le matériel est vulnérable à la faille CVE-2017-5715 sur tous les appareils livrés à l'origine avec ce niveau d'API 28 ou version ultérieure (par exemple, CONFIG_HARDEN_BRANCH_PREDICTOR)

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

  • [C-SR-2] SONT FORTEMENT RECOMMANDÉS de randomiser la disposition du code du noyau et mémoire, et d'éviter les expositions qui pourraient compromettre la randomisation (par exemple, CONFIG_RANDOMIZE_BASE avec entropie du bootloader via le /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 du noyau pour 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 l'intégrité du flux de contrôle (CFI), Shadow Call Stack (SCS) ou Integer Overflow Sanitization (IntSan) activé composants sur lesquels il est activé.

  • [C-SR-5] Il est FORTEMENT RECOMMANDÉ d'activer CFI, SCS et IntSan pour d'autres composants d'espace utilisateur sensibles, comme expliqué dans CFI et IntSan.

  • [C-SR-6] Il est FORTEMENT RECOMMANDÉ d'activer l'initialisation de la pile dans le noyau pour 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 que 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 pour empêcher l'utilisation d'allocations de segments de mémoire non initialisées (CONFIG_INIT_ON_ALLOC_DEFAULT_ON), et ils NE DOIVENT PAS supposer la valeur utilisée par le noyau pour initialiser ces allocations.

Si les implémentations d'appareils utilisent un noyau Linux capable de prendre en charge SELinux:

  • [C-1-1] DOIT implémenter SELinux.
  • [C-1-2] DOIT définir SELinux sur le mode d'application global.
  • [C-1-3] DOIT configurer tous les domaines en mode "Enforcing". Aucun mode permissif les domaines sont autorisés, y compris les domaines propres à un appareil/fournisseur.
  • [C-1-4] NE DOIT PAS modifier, omettre ni remplacer les règles "Neverallow" présentes au sein du dossier system/sepolicy fourni dans le package Android Open Source en amont Project (AOSP) et la stratégie DOIVENT se compiler avec toutes les règles "Neverallow" présentes, pour les domaines AOSP SELinux ainsi que pour les domaines propres à l'appareil ou au fournisseur.
  • [C-1-5] DOIT exécuter des applications tierces ciblant le niveau d'API 28 ou supérieur dans des bacs à sable SELinux par application, avec des restrictions SELinux par application le répertoire de données privé de l'application.
  • DEVRAIT conserver la règle SELinux par défaut fournie dans le fichier system/sepolicy du projet Android Open Source en amont et ne compléter que pour leur propre configuration spécifique à l'appareil.

Si les implémentations de périphériques utilisent un noyau autre que Linux ou Linux sans SELinux, ils:

  • [C-2-1] DOIT utiliser un système obligatoire de contrôle des accès équivalent à SELinux.

Si les implémentations d'appareils utilisent des périphériques d'E/S compatibles avec la loi sur les marchés numériques, ils:

  • [C-SR-9] Il est FORTEMENT RECOMMANDÉ d'isoler chaque périphérique d'E/S compatible avec la loi DMA à l'aide d'un IOMMU (par exemple, l'ARM SMMU).

Android contient plusieurs fonctionnalités de défense en profondeur intégrées à l’appareil la sécurité. De plus, Android s'efforce de réduire les classes clés de bugs courants qui contribuent à la mauvaise qualité et à la sécurité.

Afin de réduire les bugs de mémoire, les implémentations d'appareils:

  • [C-SR-10] EST FORTEMENT RECOMMANDÉ d'être testés avec l'erreur de mémoire de l'espace utilisateur des outils de détection tels que MTE pour les appareils ARMv9, HWASan pour les appareils ARMv8+ ou ASan pour les autres types d'appareils.
  • [C-SR-11] Il est FORTEMENT RECOMMANDÉ d'être testé en utilisant les erreurs de mémoire du noyau. des outils de détection tels que KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS pour Appareils ARMv9, CONFIG_KASAN_SW_TAGS pour les appareils ARMv8 ou CONFIG_KASAN_GENERIC pour les autres types d'appareils).
  • [C-SR-12] Il est FORTEMENT RECOMMANDÉ d'utiliser des outils de détection des erreurs de mémoire de production comme MTE, GWP-ASan et KFENCE.

Si les implémentations d'appareils utilisent un TEE basé sur Arm TrustZone, elles:

  • [C-SR-13] Il est FORTEMENT RECOMMANDÉ d'utiliser un protocole standard pour la mémoire entre Android et le TEE, comme le framework de micrologiciel Arm pour Armv8-A (FF-A).
  • [C-SR-14] Il est FORTEMENT RECOMMANDÉ de limiter les applications approuvées aux seules applications accédant à la mémoire qui a été explicitement partagée avec eux via la méthode ci-dessus standard. Si l'appareil est compatible avec le niveau d'exception S-EL2 ARM, doit être appliquée par le gestionnaire de partitions sécurisées. Sinon, il doit s'agir appliquée par le TEE OS.

Commencer les nouvelles exigences

Une technologie de sécurité de la mémoire est une technologie qui atténue au moins les éléments suivants : classes de bugs avec une probabilité élevée (> 90%) dans les applications qui utilisent le android:memtagMode manifeste:

  • 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 de l'appareil définissent la propriété système ro.arm64.memtag.bootctl_supported sur "true", ils:

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

    • 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 est temporairement activé et est automatiquement désactivé redémarrer
    • 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 aussi mettre à jour la propriété, si l'implémentation de l'appareil permet de modifier l'état sans changer la propriété système.

  • [C-SR-16] Il est FORTEMENT RECOMMANDÉ d'afficher un paramètre "Développeur" qui définit une seule fois et redémarre l'appareil. Avec un bootloader compatible, Le projet Android Open Source répond aux exigences ci-dessus via le Protocole du bootloader MTE.

  • [C-SR-17] Il est FORTEMENT RECOMMANDÉ d'afficher un paramètre de la section Menu "Paramètres" permettant à l'utilisateur d'activer memtag.

Mettre fin aux nouvelles exigences

9.8. Confidentialité

9.8.1. Historique d'utilisation

Android stocke l'historique des choix de l'utilisateur et gère cet historique en UsageStatsManager

Implémentations pour les appareils:

  • [C-0-1] DOIT conserver une durée de conservation raisonnable de cet historique utilisateur.
  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ de conserver la période de conservation de 14 jours configurés par défaut dans l'implémentation AOSP.

Android stocke les événements système à l'aide de la StatsLog les identifiants, et gère cet historique via StatsManager et API système IncidentManager.

Implémentations pour les appareils:

  • [C-0-2] DOIT inclure uniquement les champs marqués d'un DEST_AUTOMATIC dans rapport d'incident créé par la classe IncidentManager de l'API système.
  • [C-0-3] NE DOIT PAS utiliser les identifiants d'événements système pour consigner tout autre événement que ce qui est décrit dans le fichier StatsLog Documents du SDK. Si d'autres événements système sont consignés, ils PEUVENT utiliser une un identifiant atomique différent compris entre 100 000 et 200 000.

9.8.2. Enregistrement…

Implémentations pour les appareils:

  • [C-0-1] NE DOIT PAS précharger ni distribuer de composants logiciels prêts à l'emploi qui d'envoyer des informations privées sur l'utilisateur (par exemple, les frappes au clavier, le texte affiché sur le écran, rapport de bug) de l'appareil sans l'autorisation de l'utilisateur notifications en cours.
  • [C-0-2] DOIT afficher un avertissement utilisateur et obtenir le consentement explicite de l'utilisateur afin de capturer toutes les informations sensibles affichées sur son écran, y compris les informations le même message qu'AOSP à tout moment chaque fois qu'une session l'écran caster ou enregistrer votre écran est activée ; commencé via MediaProjection.createVirtualDisplay(), VirtualDeviceManager.createVirtualDisplay(), ou propriétaires. NE DOIT PAS fournir aux utilisateurs affordance de désactiver l'affichage futur du consentement de l'utilisateur.
  • [C-0-3] DOIT recevoir une notification d'activité en cours à l'utilisateur pendant la diffusion de l'écran ou l'enregistrement d'écran est activé. AOSP répond à cette exigence en présentant une l'icône de notification d'activité en cours dans la barre d'état.

Commencer les nouvelles exigences

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

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

    Mettre fin aux nouvelles exigences

Si les implémentations d'appareils incluent des fonctionnalités dans le système qui : capture le contenu affiché à l'écran et/ou enregistre le flux audio lu sur l'appareil autrement que via l'API système ContentCaptureService ; ou d'autres moyens propriétaires décrits dans Section 9.8.6 Données au niveau du système d'exploitation et données ambiantes:

  • [C-1-1] DOIT recevoir une notification d'activité en cours à l'utilisateur sont activées et capturent/enregistrent activement des données.

Si les implémentations d'appareils incluent un composant activé prêt à l'emploi, capable de enregistrer le son ambiant et/ou enregistrer le son lu sur l'appareil pour déduire des informations utiles sur le contexte de l'utilisateur, il:

  • [C-2-1] NE DOIT PAS stocker de données dans un espace de stockage persistant sur l'appareil ni transmettre le son brut enregistré ou tout format pouvant être reconverti en le contenu audio original ou une copie proche de celle-ci, sauf avec le consentement explicite de l'utilisateur.

Un "indicateur de micro" fait référence à une vue à l'écran, qui est constamment visible à l'utilisateur et ne doit pas être dissimulé, ce que les utilisateurs comprennent en raison de la présence d'un micro utiliser(par le biais d'un texte, d'une couleur, d'une icône ou d'une combinaison unique).

Un "indicateur d'appareil photo" désigne une vue à l'écran, qui est constamment visible par l'utilisateur et ne doit pas être dissimulée (ce que les utilisateurs comprennent lorsqu'une caméra est en cours d'utilisation). (par le biais d'un texte, d'une couleur, d'une icône ou d'une combinaison unique).

Après la première seconde affichée, un indicateur peut changer visuellement, par exemple : diminue et n'est pas nécessaire pour s'afficher tel qu'il était présenté initialement. compris.

L'indicateur du micro peut être fusionné avec une caméra affichée activement indicateur, à condition que le texte, les icônes ou les couleurs indiquent à l'utilisateur que l'utilisation du micro a commencé.

L'indicateur de l'appareil photo peut être fusionné avec un micro affiché en cours. à condition que le texte, les icônes ou les couleurs indiquent à l'utilisateur que de la caméra a commencé.

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

  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'afficher l'indicateur du micro lorsqu'une application accède aux données audio du micro, mais pas lorsqu'il est uniquement accessible par HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService, ou une ou plusieurs applications détenant les rôles décrits dans la section 9.1 Autorisations avec identifiant CDD [C-3-X]. .
  • [C-SR-2] Il est FORTEMENT RECOMMANDÉ d'afficher les listes "Récents" et "Actifs" les applications utilisant le micro comme renvoyées par PermissionManager.getIndicatorAppOpUsageData(), et toute attribution messages qui leur sont associés.
  • [C-SR-3] Il est FORTEMENT RECOMMANDÉ de ne pas masquer l'indicateur de micro les applications système qui ont des interfaces utilisateur visibles ou une interaction directe de l’utilisateur.

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

  • [C-SR-4] Il est FORTEMENT RECOMMANDÉ d'afficher l'indicateur de l'appareil photo lorsqu'une application accéder aux données en direct de la caméra, mais pas lorsqu'elle est uniquement en cours d'accès par une ou plusieurs applications détenant les rôles décrits à la section 9.1 Autorisations avec le CDD identifiant [C-3-X].
  • [C-SR-5] Il est FORTEMENT RECOMMANDÉ d'afficher les applications récentes et actives avec appareil photo renvoyé par PermissionManager.getIndicatorAppOpUsageData(), ainsi que tous les messages d'attribution qui leur sont associés.
  • [C-SR-6] Il est FORTEMENT RECOMMANDÉ de ne pas masquer l'indicateur de l'appareil photo du système les applications dont l'interface utilisateur est visible ou dont l'interaction directe avec l'utilisateur est visible

9.8.3. Connectivité

Si les implémentations d’appareils disposent d’un port USB compatible avec le mode périphérique USB, ils:

  • [C-1-1] DOIT présenter une interface utilisateur demandant le consentement de l'utilisateur avant permettant d'accéder au contenu du stockage partagé sur le port USB.

9.8.4. Trafic réseau

Implémentations pour les appareils:

  • [C-0-1] DOIT préinstaller les mêmes certificats racine pour le certificat Magasin de l'autorité de certification (CA) fourni dans le projet Open Source Android en amont.
  • [C-0-2] DOIT être livré avec un magasin d'autorités de certification racine d'utilisateur vide.
  • [C-0-3] DOIT afficher un avertissement indiquant à l'utilisateur le trafic réseau peuvent être surveillées, lorsqu'une AC racine d'utilisateur est ajoutée.

Si le trafic de l'appareil est acheminé via un VPN, les implémentations d'appareils:

  • [C-1-1] DOIT afficher un avertissement à l'utilisateur indiquant:
    • Ce trafic réseau peut être surveillé.
    • Ce trafic réseau est acheminé via le VPN l'application fournissant le VPN.

Si les implémentations d'appareils disposent d'un mécanisme, activé par défaut, qui achemine le trafic de données réseau via un serveur proxy ou une passerelle VPN (par exemple, préchargement d'un service VPN avec android.permission.CONTROL_VPN accordé), il:

  • [C-2-1] DOIT demander le consentement de l'utilisateur avant d'activer ce mécanisme. sauf si ce VPN est activé par l'outil de contrôle des règles relatives aux appareils via la DevicePolicyManager.setAlwaysOnVpnPackage() . Dans ce cas, l'utilisateur n'a pas besoin de donner un consentement distinct, mais DOIT seulement être notifiés.

Si les implémentations d'appareils implémentent une affordance utilisateur, activez "VPN permanent" d'une application VPN tierce, ils:

  • [C-3-1] DOIT désactiver cette affordance utilisateur pour les applications non compatibles le service VPN permanent dans le fichier AndroidManifest.xml en définissant SERVICE_META_DATA_SUPPORTS_ALWAYS_ON à false.

9.8.5. Identifiants des appareils

Implémentations pour les appareils:

  • [C-0-1] DOIT empêcher l'accès au numéro de série de l'appareil et, si code IMEI/MEID, numéro de série de la carte SIM et International Mobile Identité d'abonné (IMSI) d'une application, sauf si elle répond à l'un des critères suivants configuration requise:
    • est une application d'opérateur signée qui est validée par les fabricants d'appareils.
    • L'autorisation READ_PRIVILEGED_PHONE_STATE a été accordée.
    • dispose de privilèges d'opérateur tels que définis dans les droits d'opérateur de l'UICC.
    • est le propriétaire de l'appareil ou du profil auquel le Autorisation READ_PHONE_STATE.
    • (Pour le numéro de série de la carte SIM/ICCID uniquement) est conforme aux exigences de la réglementation locale que l'application détecte les changements dans l'identité de l'abonné.

9.8.6. Capture de contenu et recherche dans les applicationsDonnées de veille et au niveau de l'OS

Android, par le biais des API système ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query ou d'autres des moyens propriétaires, prend en charge un mécanisme afin de capturer les interactions suivantes avec les données d'application entre les applications l'utilisateur données sensibles:

  • Le texte et les images affichées à l'écran, y compris, mais sans s'y limiter : notifications et données d'assistance via AssistStructure API.
  • Données multimédias, telles que du contenu audio ou vidéo, enregistrées ou lues par l'appareil.
  • Événements d'entrée (par exemple, touche, souris, geste, voix, vidéo et accessibilité)

Commencer les nouvelles exigences

  • Tout écran ou autre donnée envoyée via le AugmentedAutofillService à du système d'exploitation.
  • Tout écran ou autre donnée accessible via Content Capture API.
  • 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.

Mettre fin aux nouvelles exigences

  • Tout autre événement fourni par une application au système via le Content Capture ou une API AppSearchManager, un appareil Android et API propriétaire.

  • Tout texte ou toute autre donnée envoyé via le TextClassifier API au TextClassifier système, c'est-à-dire au service système, pour comprendre la signification du texte et générer des prédictions d'actions suivantes en fonction le texte.
  • Données indexées par l'implémentation de la plate-forme AppSearch, y compris, mais pas se limite au texte, aux graphiques, aux données multimédias ou à d'autres données similaires.

Commencer les nouvelles exigences

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

Mettre fin aux nouvelles exigences

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

  • [C-1-1] DOIT chiffrer toutes ces données lorsqu'elles sont stockées sur l'appareil. Ce le chiffrement PEUT être effectué à l'aide du chiffrement basé sur les fichiers Android, des algorithmes de chiffrement répertoriés dans la version 26 ou ultérieure de l'API, décrits dans le SDK de chiffrement.
  • [C-1-2] NE DOIT PAS sauvegarder de données brutes ou chiffrées via des Méthodes de sauvegarde Android ou tout autre retour .
  • [C-1-3] DOIT uniquement envoyer l'ensemble de ces données et la journalisation des appareil à l'aide d'un mécanisme protégeant la confidentialité, sauf avec le consentement explicite de l'utilisateur chaque fois que les données partagés. 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 consignés ou des résultats dérivés avec des utilisateurs individuels", empêcher l'introspection de données par utilisateur (par exemple, en implémentant des une technologie de confidentialité différentielle comme RAPPOR).
  • [C-1-4] NE DOIT PAS associer ces données à l'identité d'un utilisateur (tel que en tant que Account) sur l'appareil, sauf avec le consentement explicite de l'utilisateur chaque fois que les données sont associées.
  • [C-1-5] NE DOIT PAS partager ces données avec d'autres composants du système d'exploitation qui n'utilisent pas respecter les exigences décrites dans la section actuelle (9.8.6 Capture de contenu Au niveau de l'OS et ambiant ), sauf avec le consentement explicite de l'utilisateur tous les l'heure à laquelle elles sont partagées. À moins que cette fonctionnalité ne soit créé en tant qu'API SDK Android (AmbientContext, HotwordDetectionService).
  • [C-1-6] DOIT fournir une affordance à l'utilisateur pour effacer les données qui la ContentCaptureService implémentation ou des moyens propriétaires collectent if quand le les données sont stockées sous n'importe quelle forme sur l'appareil. Si le l'utilisateur choisit d'effacer les données, il DOIT supprimer l'ensemble des données historiques collectées données.
  • [C-1-7] DOIT fournir une affordance à l'utilisateur pour le refus des données, collectées via AppSearch ou des moyens propriétaires d'être diffusés sur la plate-forme Android Ex. : lanceur d'applications.
  • [C-SR-1] IL EST FORTEMENT RECOMMANDÉ de NE PAS demander l'autorisation INTERNET.
  • [C-SR-2] Il est FORTEMENT RECOMMANDÉ de n'accéder à Internet que via structurées et basées sur des implémentations Open Source publiques.

Commencer les nouvelles exigences

  • [C-SR-4] Il est FORTEMENT RECOMMANDÉ d'être implémenté avec l'API SDK Android ou un dépôt Open Source similaire appartenant à un OEM ; et / ou être effectuées Implémentation en bac à sable (voir 9.8.15 Implémentations de l'API en bac à sable).

Mettre fin aux nouvelles exigences

Si les implémentations d'appareils incluent un service qui implémente l'API System ContentCaptureService, AppSearchManager.index ou tout service propriétaire qui capture les données comme décrit ci-dessus, il:

  • [C-2-1] NE DOIT PAS permettre aux utilisateurs de remplacer les services par un application ou service installable par l'utilisateur et DOIT autoriser uniquement services préinstallés pour capturer de telles données.
  • [C-2-2] NE DOIT PAS autoriser d'applications autres que les services préinstallés pour capturer de telles données.
  • [C-2-3] DOIT fournir une affordance à l'utilisateur pour désactiver les services.
  • [C-2-4] NE DOIT PAS omettre l' affordance de l'utilisateur pour gérer les autorisations Android qui sont détenus par les services et respectent les autorisations Android tel que décrit dans la Section 9.1. Autorisation.

  • [C-SR-3] Il est FORTEMENT RECOMMANDÉ de séparer les services des autres Composants système(par exemple, absence de liaison du service ou partage d'ID de processus) hormis pour les cas suivants:

    • Téléphonie, contacts, UI du système et médias

Android, via SpeechRecognizer#onDeviceSpeechRecognizer(), offre la possibilité pour 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écrits dans cette section.

9.8.7. Accès au presse-papiers

Implémentations pour les appareils:

  • [C-0-1] NE DOIT PAS renvoyer de données tronquées depuis le presse-papiers (par exemple, via le ClipboardManager à moins que l'API tierce app est l'IME par défaut ou est l'application actuellement sélectionnée.

  • [C-0-2] DOIT effacer les données du presse-papiers au plus tard 60 minutes après leur dernière placé dans un presse-papiers ou lu à partir d’un presse-papiers.

9.8.8. Position

La localisation inclut les informations de la classe de localisation Android( comme Latitude, (longitude, altitude), ainsi que les identifiants pouvant être convertis en lieux. La localisation peut être aussi précise que le DGPS (Differential Global Positioning System) grossièrement au niveau du pays (par exemple, l'emplacement avec l'indicatif du pays - CM - Mobile) Code pays).

Vous trouverez ci-dessous la liste des types de lieux qui déterminent directement ou convertir celle d'un utilisateur. Cette liste n'est pas exhaustive mais ils doivent servir d'exemple pour déterminer sont indirectement dérivées de:

  • GPS/GNSS/DGPS/PPP
    • Solution de positionnement global ou système de navigation satellite par satellite, ou Solution de positionnement global différentiel
    • Cela inclut également les mesures GNSS brutes et l'état GNSS
      • La position précise peut être obtenue à partir des mesures GNSS brutes
  • Technologies sans fil avec des identifiants uniques tels que:
    • Points d'accès Wi-Fi (MAC, BSSID, nom ou SSID)
    • Bluetooth/BLE (MAC, BSSID, nom ou SSID)
    • UWB (MAC, BSSID, nom ou SSID)
    • Identifiant de la tour de téléphonie mobile (3G, 4G, 5G, etc., y compris tous les futurs modems mobiles) technologies à identifiants uniques)

Comme point de référence principal, consultez les API Android qui nécessitent ACCESS_FINE_Location ou ACCESS_COARSE_Autorisations d'accès à la position.

Implémentations pour les appareils:

  • [C-0-1] NE DOIT PAS activer/désactiver la localisation de l'appareil ni le Wi-Fi/Bluetooth. les paramètres d'analyse sans consentement explicite ni initiation de l'utilisateur.
  • [C-0-2] DOIT fournir à l'utilisateur les affordances d'accès liées à la localisation comme les demandes de localisation récentes, les autorisations au niveau des applis et leur utilisation de recherche Wi-Fi/Bluetooth pour déterminer la position.
  • [C-0-3] DOIT s'assurer que l'application qui utilise l'API Emergency Location Bypass [LocationRequest.setLocationSettingsIgnored()] est une urgence déclenchée par l'utilisateur. (par exemple, appeler le 112 ou envoyer un SMS au 112). Pour l'automobile, un véhicule PEUT lancer une session d'urgence sans interaction de l'utilisateur actif dans le dossier si un accident ou un accident est détecté (par exemple, pour répondre aux exigences d'eCall).
  • [C-0-4] DOIT préserver la capacité de l'API Emergency Location Bypass ignorer les paramètres de localisation de l'appareil sans les modifier ;
  • [C-0-5] DOIT programmer une notification de rappel à l'utilisateur après qu'une application l'arrière-plan a accédé à sa position à l'aide de Autorisation [ACCESS_BACKGROUND_LOCATION].

9.8.9. Applications installées

Les applications Android ciblant le niveau d'API 30 ou supérieur ne peuvent pas afficher d'informations sur les autres installées par défaut (voir la section Visibilité des packages dans le dans la documentation du SDK).

Implémentations pour les appareils:

  • [C-0-1] NE DOIT PAS exposer aux détails d'une application ciblant le niveau d'API 30 ou supérieur. sur toute autre application installée, sauf si l'application a déjà accès aux détails sur l'autre application installée via les API gérées. Cela inclut, mais est sans s'y limiter les informations fournies par les API personnalisées ajoutées par l'appareil ou accessibles via le système de fichiers.
  • [C-0-2] NE DOIT PAS accorder à une application un accès en lecture ou en écriture aux fichiers d'une répertoire dédié et spécifique à l'application dans un espace de stockage externe. Les seules exceptions sont les suivantes:
    • Autorité du fournisseur de stockage externe (par exemple, des applications telles que DocumentsUI).
    • Fournisseur de téléchargement utilisant l'autorité de fournisseur "téléchargements" pour télécharger des fichiers vers l'espace de stockage de l'application.
    • Les applications MTP (Media Transfer Protocol) signées par la plate-forme qui utilisent l’autorisation privilégiée ACCESS_MTP pour permettre le transfert de fichiers vers un autre appareil.
    • Applications qui installent d'autres applications et qui disposent de l'autorisation INSTALLER_PACKAGES ne peuvent accéder qu'aux répertoires "obb" afin de gérer Fichiers d'extension pour APK

9.8.10. Rapport de bug de connectivité

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

  • [C-1-1] DOIT prendre en charge la génération de rapports de bugs de connectivité via BUGREPORT_MODE_TELEPHONY avec BugreportManager.
  • [C-1-2] DOIT obtenir le consentement de l'utilisateur chaque fois que BUGREPORT_MODE_TELEPHONY utilisée pour générer un rapport et NE DOIT PAS inviter l'utilisateur à donner son consentement les futures requêtes de l'application.
  • [C-1-3] NE DOIT PAS renvoyer le rapport généré à l'application à l'origine de la demande le consentement explicite de l'utilisateur.
  • [C-1-4] Les rapports générés avec BUGREPORT_MODE_TELEPHONY DOIVENT contenir au moins les informations suivantes:
    • Fichier de dump TelephonyDebugService
    • Fichier de dump TelephonyRegistry
    • Fichier de dump WifiService
    • Fichier de dump ConnectivityService
    • Un vidage de l'instance CarrierService du package appelant (si lié)
    • Tampon journal radio
    • Vidage SubscriptionManagerService
  • [C-1-5] NE DOIT PAS inclure les éléments suivants dans les rapports générés:
    • Toute sorte d'information qui n'est pas directement liée à la connectivité le débogage.
    • Tout type de journaux de trafic ou de profils détaillés installés sur les applications installées par l'utilisateur des applications/packages installés par l'utilisateur (les UID sont acceptables, les noms de packages sont non).
  • PEUT inclure des informations supplémentaires qui ne sont associées à aucun utilisateur. l'identité. (par exemple, les journaux des fournisseurs).

Si la mise en œuvre des appareils inclut des informations supplémentaires (par exemple, les journaux des fournisseurs) dans des rapports de bugs et que les informations ont des règles de confidentialité, de sécurité, de batterie, de stockage ou de mémoire. impact, elles:

  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'avoir un paramètre de développeur défini par défaut sur est désactivé. L'implémentation de référence AOSP répond à ce besoin en fournissant le Enable verbose vendor logging. dans les paramètres du développeur pour inclure des journaux supplémentaires de fournisseurs spécifiques à l'appareil dans les rapports de bug.

9.8.11. Partage de blobs de données

Android, via BlobStoreManager permet aux applications de fournir des blobs de données au système à partager avec un ensemble d'applications.

Si les implémentations d'appareils sont compatibles avec les blobs de données partagées, comme décrit dans le Documentation sur les SDK ils:

9.8.12. Reconnaissance musicale

Android, par le biais de MusicRecognitionManager de l'API système, prend en charge un mécanisme pour des implémentations d'appareils pour demander la reconnaissance musicale à partir d'un enregistrement audio ; déléguer la reconnaissance musicale à une application privilégiée l'API MusicRecognitionService.

Si les implémentations d'appareils incluent un service qui implémente l'API System MusicRecognitionManager ou tout service propriétaire qui diffuse des données audio en tant que décrits ci-dessus, ils:

  • [C-1-1] DOIT faire en sorte que l'appelant de MusicRecognitionManager conserve la Autorisation MANAGE_MUSIC_RECOGNITION
  • [C-1-2] OBLIGATOIRE qu'un système de reconnaissance musicale unique préinstallé implémente MusicRecognitionService.
  • [C-1-3] NE DOIT PAS autoriser les utilisateurs à remplacer MusicRecognitionManagerService ou MusicRecognitionService par une application ou un service installables par l'utilisateur.
  • [C-1-4] DOIT s'assurer que lorsque MusicRecognitionManagerService accède au l'enregistrement audio et le transmet à l'application mettant en œuvre MusicRecognitionService, le suivi de l'accès audio est effectué via des appels de AppOpsManager.noteOp / startOp :

Si les implémentations de MusicRecognitionManagerService sur les appareils MusicRecognitionService stocke toutes les données audio capturées, qui:

  • [C-2-1] NE DOIT PAS stocker d'empreintes audio ou audio brutes sur le disque. ou en mémoire pendant plus de 14 jours.
  • [C-2-2] NE DOIT PAS partager ces données au-delà du service MusicRecognitionService, sauf avec le consentement explicite de l'utilisateur à chaque partage.

9.8.13. SensorPrivacyManager

Si les implémentations d'appareils fournissent à l'utilisateur une affordance logicielle pour désactiver l'entrée de la caméra et/ou du micro pour l'implémentation de l'appareil:

  • [C-1-1] DOIT renvoyer avec précision la valeur "true" pour les supportsSensorToggle() .
  • [C-1-2] OBLIGATOIRE lorsqu'une application tente d'accéder à un micro ou à une caméra bloqués présentent à l'utilisateur une affordance qu'il ne peut pas ignorer, indique que le capteur est bloqué et nécessite la possibilité de continuer de blocage ou de déblocage conformément à l'implémentation AOSP, cette exigence.
  • [C-1-3] NE DOIT transmettre que des données d'appareil photo et audio vides (ou factices) aux applications et ne pas signaler de code d'erreur, car l'utilisateur n'allume pas la caméra ni le micro via l' affordance de l'utilisateur présentée comme [C-1-2] ci-dessus.

Commencer les nouvelles exigences

9.8.14. Gestionnaire d'identifiants

Supprimé.

9.8.15. Implémentations d'API en bac à sable

Par le biais d'un ensemble d'API déléguées, Android fournit un mécanisme permettant de traiter des données Données de veille et au niveau de l'OS. Ce traitement peut être délégué à apk avec un accès privilégié et des capacités de communication réduites, ce que l'on appelle une 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] NE DOIT accéder à Internet que via des API structurées reposant sur des implémentations Open Source publiques qui utilisent ou indirectement via les API du SDK Android. La protection de la confidentialité est défini comme "ceux qui autorisent uniquement une analyse sous forme agrégée empêcher la mise en correspondance des événements enregistrés ou des résultats dérivés avec des utilisateurs individuels ; pour éviter l'introspection de données utilisateur spécifiques (par exemple, en implémentant des une technologie de confidentialité différentielle RAPPOR).
  • [C-0-3] DOIT maintenir les services séparés des autres composants du système (par exemple, ne pas lier le service ou partager des ID de processus), sauf pour les suivantes:
    • Téléphonie, contacts, UI du système et médias
  • [C-0-4] NE DOIT PAS permettre aux utilisateurs de remplacer les services par un application ou service installable par l'utilisateur
  • [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 compatibles avec l'Assistant).
  • [C-0-6] NE DOIT PAS autoriser d'applications autres que les services préinstallés pour capturer de telles données. À moins qu'une telle capacité de capture est implémenté avec une API SDK Android.
  • [C-0-7] DOIT fournir une affordance à l'utilisateur pour désactiver les services.
  • [C-0-8] NE DOIT PAS omettre l' affordance de l'utilisateur pour gérer les autorisations Android qui détenus par les services et suivent le modèle d'autorisations Android décrits dans Section 9.1. Autorisation.

9.8.16. Audio en continu et données de la caméra

En plus des exigences décrites dans les sections 9.8.2 Enregistrement, 9.8.6 OS au niveau et et 9.8.15 les implémentations d'API en bac à sable, les implémentations utiliser les données audio obtenues en arrière-plan (en continu) via AudioRecord, SoundTrigger ou d'autres API audio OU données de l'appareil photo obtenues dans en arrière-plan (en continu) via CameraManager ou d'autres API Camera:

  • [C-0-1] DOIT appliquer un indicateur correspondant (appareil photo 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 utilisant ces données, et être désactivé par défaut.
  • [C-SR-2] VIVEMENT RECOMMANDÉ d'appliquer le même traitement (en d'autres termes, suivre les les restrictions décrites dans les sections 9.8.2 Enregistrement, 9.8.6 Données au niveau du système d'exploitation et données ambiantes, 9.8.15 Implémentations d'API en bac à sable et 9.8.16 Audio et caméra en continu données) aux données de l'appareil photo provenant d'un accessoire connecté distant.

Si les données de l'Appareil photo sont fournies par un accessoire connecté distant et accessibles via un formulaire non chiffré en dehors de l'OS Android, ou s'il s'agit d'une implémentation en bac à sable créée par WearableSensingManager, ils:

  • [C-1-1] DOIT indiquer à l'accessoire connecté distant un indicateur supplémentaire s'affiche.

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

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

9.8.17. Telemetry

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 dans la catégorie "Confidentialité" sensibles provenant d'appareils grâce à un mécanisme protégeant la confidentialité. En particulier, L'API StatsManager::query permet d'interroger des métriques limitées les catégories définies dans StatsLog.

Toute implémentation qui interroge et collecte des métriques limitées StatsManager:

  • [C-0-1] DOIT être la seule application/implémentation disponible sur l'appareil l'autorisation READ_RESTRICTED_STATS.
  • [C-0-2] NE DOIT envoyer que des données de télémétrie et le journal de l'appareil à l'aide d'un de protection de la confidentialité. Le mécanisme de protection de la confidentialité comme "ceux qui autorisent uniquement une analyse globale et empêchent la mise en correspondance les événements consignés ou les résultats qui en découlent pour chaque utilisateur", afin d'éviter introspection possible sur les données utilisateur (par exemple, mises en œuvre à l'aide d'une méthode différentielle des technologies de confidentialité comme RAPPOR).
  • [C-0-3] NE DOIT PAS associer ces données à l'identité d'un utilisateur (par exemple, Account). sur l'appareil.
  • [C-0-4] NE DOIT PAS partager ces données avec d'autres composants de l'OS qui ne respectent pas décrites dans la section actuelle (9.8.17 Télémétrie).
  • [C-0-5] DOIT fournir une affordance à l'utilisateur pour activer/désactiver la protection de la confidentialité collecte, utilisation et partage de télémétrie.
  • [C-0-6] DOIT fournir une affordance à l'utilisateur pour effacer les données que le collecte si les données 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 indiquer l'implémentation sous-jacente du protocole protégeant la confidentialité dans un dépôt Open Source.
  • [C-0-8 ]DOIT appliquer les règles de sortie des données décrites dans cette section pour contrôler la collecte de données appartenant à des catégories de métriques limitées définies dans StatsLog.

Mettre fin aux nouvelles exigences

9.9. Chiffrement du stockage des données

Tous les appareils DOIVENT respecter les exigences de la section 9.9.1. Les appareils lancés à un niveau d'API antérieur à celui indiqué dans ce document sont êtes exempté des exigences des sections 9.9.2 et 9.9.3 ; à la place, ils DOIT respecter les exigences de la section 9.9 du règlement de compatibilité Android Document de définition correspondant au niveau d'API sur lequel l'appareil a été lancé.

9.9.1. Démarrage direct

Implémentations pour les appareils:

  • [C-0-1] DOIT implémenter les API en mode Démarrage direct, même si ils ne sont pas compatibles avec le chiffrement du stockage.

  • [C-0-2] Le ACTION_LOCKED_BOOT_COMPLETED et ACTION_USER_UNLOCKED Les intents DOIVENT être diffusés pour signaler les applications compatibles avec le démarrage direct qui Les emplacements de stockage de chiffrement d'appareil (DE) et de chiffrement d'identifiant (CE) sont à la disposition de l'utilisateur.

9.9.2. Exigences de chiffrement

Implémentations pour les appareils:

  • [C-0-1] DOIT chiffrer l'application en mode privé (partition /data), ainsi que la partition de stockage partagé de l'application (partition /sdcard) s'il s'agit d'une partie permanente et non amovible de l'appareil.
  • [C-0-2] DOIT activer le chiffrement du stockage des données par défaut à chaque fois l'utilisateur a terminé la configuration initiale.

  • [C-0-3] DOIT respecter les exigences de chiffrement du stockage de données ci-dessus en implémentant l'une des deux méthodes de chiffrement suivantes:

9.9.3. Méthodes de chiffrement

Si les implémentations d'appareils sont chiffrées, elles:

  • [C-1-1] DOIT démarrer sans demander à l'utilisateur d'obtenir des identifiants Autoriser les applications compatibles avec le démarrage direct à accéder au stockage DE (Device Encrypted) après la diffusion du message ACTION_LOCKED_BOOT_COMPLETED.
  • [C-1-2] DOIT autoriser l'accès au stockage CE (Identifiants chiffrés) uniquement après l'utilisateur a déverrouillé l'appareil en fournissant ses identifiants (code secret, code, schéma ou empreinte digitale, par exemple) et l'ACTION_USER_UNLOCKED le message est diffusé.
  • [C-1-13] NE DOIT PAS proposer de méthode pour déverrouiller l'espace de stockage protégé par CE sans les informations d'identification fournies par l'utilisateur, une clé de séquestre enregistrée ou un à la mise en œuvre du redémarrage répondant aux exigences de section 9.9.4.
  • [C-1-4] DOIT utiliser le démarrage validé.
9.9.3.1. Chiffrement basé sur les fichiers et métadonnées

Si les implémentations d'appareils utilisent le chiffrement basé sur les fichiers avec chiffrement des métadonnées, ils:

  • [C-1-5] DOIT chiffrer le contenu des fichiers et les métadonnées du système de fichiers à l'aide de AES-256-XTS ou Adiantum. L'acronyme AES-256-XTS désigne la norme avec une longueur de clé de chiffrement de 256 bits, exploitée en mode XTS ; toute la durée est de 512 bits. Adiantum fait référence à Adiantum-XChaCha12-AES, comme spécifié dans https://github.com/google/adiantum Les métadonnées du système de fichiers sont des données telles que les tailles, la propriété, les modes et les attributs étendus (xattrs).
  • [C-1-6] DOIT chiffrer les noms de fichiers à l'aide des protocoles AES-256-CBC-CTS, AES-256-HCTR2, ou Adiantum.
  • [C-1-12] Si l'appareil est doté de la norme AES (Advanced Encryption Standard) (telles que les extensions de cryptographie ARMv8 sur les appareils ARM, ou AES-NI sur les appareils basés sur x86), puis les options basées sur AES ci-dessus pour le nom de fichier, le contenu des fichiers et le chiffrement des métadonnées du système de fichiers DOIVENT être utilisés, et non Adiantum.
  • [C-1-13] DOIT utiliser une clé cryptographiquement sécurisée et non réversible de dérivation (par exemple, HKDF-SHA512) pour dériver les sous-clés nécessaires (par exemple, clés par fichier) à partir des clés CE et DE. « Cryptographiquement solide et non réversible" signifie que la fonction de dérivation de clé a un pouvoir de sécurité d'au moins 256 bits et se comporte comme une fonction pseudo-aléatoire famille sur ses entrées.
  • [C-1-14] NE DOIT PAS utiliser les mêmes clés ni sous-clés de chiffrement basé sur les fichiers (FBE) à des fins de chiffrement différentes (par exemple, pour le chiffrement et ou pour deux algorithmes de chiffrement différents).
  • [C-1-15] DOIT s'assurer que tous les blocs de contenus de fichiers chiffrés non supprimés sur le stockage persistant étaient chiffrés à l'aide de combinaisons de clés vecteur d'initialisation (IV) qui dépend à la fois du fichier et du décalage dans le fichier. De plus, toutes ces combinaisons DOIVENT être distinctes, sauf si le chiffrement s'effectue à l'aide de matériel de chiffrement intégré qui n'accepte IV de 32 bits.
  • [C-1-16] DOIT s'assurer que tous les noms de fichiers chiffrés non supprimés sur des disques persistants le stockage dans des répertoires distincts était chiffré à l'aide de combinaisons distinctes la clé de chiffrement et le vecteur d'initialisation (IV).

  • [C-1-17] DOIT s'assurer que tous les blocs de métadonnées chiffrés du système de fichiers le stockage persistant étaient chiffrés à l'aide de combinaisons distinctes de clés et le vecteur d'initialisation (IV).

  • Clés protégeant les zones de stockage CE et DE et les métadonnées du système de fichiers:

    • [C-1-7] DOIT être lié de manière cryptographique à un keystore intégré au matériel. Ce keystore DOIT être lié au démarrage validé et au matériel de l'appareil racine de confiance.
    • [C-1-8] Les clés CE DOIVENT être liées aux identifiants de l'écran de verrouillage d'un utilisateur.
    • [C-1-9] Les clés CE DOIVENT être liées à un code secret par défaut lorsque l'utilisateur a identifiants d'écran de verrouillage non spécifiés.
    • [C-1-10] DOIT être unique et distinct, autrement dit, aucun certificat CE ou DE correspond aux clés CE ou DE de n'importe quel autre utilisateur.
    • [C-1-11] DOIT utiliser les algorithmes de chiffrement, longueurs de clé et différents modes.
    • [C-1-12] DOIT être effacés de manière sécurisée lors du déverrouillage et du verrouillage du bootloader. comme décrit ici.

  • DEVRAIT créer des applications essentielles préinstallées (par exemple, Alarme, Téléphone, Messenger) Prise en compte du démarrage direct.

Le projet Android Open Source en amont offre une implémentation privilégiée Chiffrement basé sur les fichiers basé sur le noyau Linux "fscrypt" de chiffrement, et le chiffrement des métadonnées basé sur le noyau Linux "dm-default-key". .

9.9.3.2. Chiffrement au niveau du bloc par utilisateur

Si les implémentations d'appareils utilisent le chiffrement au niveau du bloc par utilisateur:

  • [C-1-1] DOIT activer la prise en charge multi-utilisateur, comme décrit dans la section 9.5.
  • [C-1-2] DOIT fournir des partitions par utilisateur, soit à l'aide de partitions brutes, soit des volumes logiques.
  • [C-1-3] DOIT utiliser des clés de chiffrement uniques et distinctes par utilisateur pour le chiffrement des périphériques de traitement par blocs sous-jacents.

  • [C-1-4] DOIT utiliser l'algorithme AES-256-XTS pour le chiffrement au niveau du bloc de l'utilisateur des partitions.

  • Les clés qui protègent les appareils chiffrés au niveau du bloc par utilisateur:

    • [C-1-5] DOIT être lié de manière cryptographique à un keystore intégré au matériel. Ce keystore DOIT être lié au démarrage validé et au matériel de l'appareil racine de confiance.
    • [C-1-6] DOIT être lié à l'écran de verrouillage de l'utilisateur correspondant identifiants de connexion.

Le chiffrement au niveau du bloc par utilisateur peut être implémenté à l'aide du kernel Linux. "dm-crypt" sur les partitions par utilisateur.

9.9.4. Reprendre au redémarrage

La reprise au redémarrage permet de déverrouiller l'espace de stockage CE pour toutes les applications, y compris celles-ci qui ne prennent pas encore en charge le démarrage direct, après un redémarrage initié par une OTA. Ce permet aux utilisateurs de recevoir des notifications des applications installées redémarrer.

La mise en œuvre de la fonctionnalité Resume-on-Restart doit se poursuivre pour garantir que lorsqu'un entre les mains d’un pirate informatique, il est extrêmement difficile pour pour récupérer les données de l'utilisateur chiffrées par CE, même si l'appareil est sous tension le stockage CE est déverrouillé, et l'utilisateur a déverrouillé l'appareil après avoir reçu une agence de voyages en ligne. Pour la résistance aux attaques internes, nous supposons également que l’attaquant obtient l’accès pour diffuser des clés de signature cryptographique.

Plus spécifiquement :

  • [C-0-1] Le stockage CE NE DOIT PAS être lisible, même pour l'attaquant qui a physiquement présente alors les fonctionnalités et limites suivantes:

    • Possibilité d'utiliser la clé de signature de n'importe quel fournisseur ou entreprise pour signer arbitrairement messages.
    • Ce paramètre peut entraîner la réception d'une mise à jour OTA par l'appareil.
    • Peut modifier le fonctionnement de tout matériel (point d'accès, flash, etc.), sauf en détaillé ci-dessous, mais une telle modification implique un délai d'au moins heure et un cycle d'arrêt et d'arrêt qui détruit le contenu de la RAM.
    • Ne peut pas modifier le fonctionnement d'un matériel protégé contre les accès non autorisés (Titan M, par exemple).
    • Impossible de lire la RAM de l'appareil actif.
    • ne peut pas obtenir les identifiants de l'utilisateur (code, schéma, mot de passe) ; ou sinon il sera saisi.

À titre d'exemple, une implémentation d'appareil qui implémente et respecte toutes des descriptions disponibles sur cette page est conforme aux normes [C-0-1].

9.10. Intégrité de l'appareil

Les exigences suivantes assurent la transparence de l'état l'intégrité de l'appareil. Implémentations pour les appareils:

  • [C-0-1] DOIT signaler correctement le problème via la méthode de l'API System PersistentDataBlockManager.getFlashLockState(), que son bootloader autorise le flash de l'image système.

  • [C-0-2] DOIT être compatible avec le démarrage validé pour assurer l'intégrité de l'appareil.

Si des implémentations d'appareils sont déjà lancées sans être compatibles avec le démarrage validé sur une version antérieure d'Android et ne peut pas ajouter la prise en charge une mise à jour logicielle système, ils PEUVENT être exemptés du cette exigence.

Le démarrage validé est une fonctionnalité qui garantit l'intégrité de l'appareil logiciels. Si les implémentations d'appareils sont compatibles avec la fonctionnalité, ils:

  • [C-1-1] DOIT déclarer le flag de fonctionnalité de la plate-forme android.software.verified_boot
  • [C-1-2] DOIT effectuer une vérification sur chaque séquence de démarrage.
  • [C-1-3] DOIT démarrer la validation à partir d'une clé matérielle immuable correspondant au racine de confiance et aller jusqu’à la partition du système.
  • [C-1-4] DOIT mettre en œuvre chaque étape de validation pour vérifier l'intégrité et l'authenticité de tous les octets à l'étape suivante, avant d'exécuter le code dans l'étape suivante.
  • [C-1-5] DOIT utiliser des algorithmes de vérification aussi puissants que recommandations du NIST pour les algorithmes de hachage (SHA-256) et les clés publiques (RSA-2048).
  • [C-1-6] NE DOIT PAS autoriser le démarrage en cas d'échec de la vérification du système. sauf si l'utilisateur consent à tenter de le démarrer quand même, auquel cas les données les blocs de stockage non validés NE DOIVENT pas être utilisés.
  • [C-1-7] NE DOIT PAS autoriser la modification des partitions validées sur le périphérique sauf si l'utilisateur a explicitement déverrouillé le bootloader.
  • [C-SR-1] Si l'appareil est équipé de plusieurs puces discrètes (radio, un processeur d'images spécialisé), le processus de démarrage de chacune de ces puces est FORTEMENT RECOMMANDÉ de vérifier chaque étape au démarrage.
  • [C-1-8] DOIT utiliser des dispositifs de stockage avec système d'inviolabilité: pour savoir si le le bootloader est déverrouillé. Un stockage inviolable signifie que le bootloader peut détecter si le stockage a été altéré depuis Android.
  • [C-1-9] DOIT envoyer une invite à l'utilisateur lorsqu'il se sert de l'appareil, et nécessitent une confirmation physique avant d'autoriser une transition depuis le bootloader du mode verrouillé au mode déverrouillé du bootloader.
  • [C-1-10] DOIT implémenter une protection contre le rollback pour les partitions utilisées par Android (démarrage, partitions système, etc.) et utilisez un espace de stockage avec système d'inviolabilité pour le stockage Métadonnées utilisées pour déterminer la version minimale autorisée du système d'exploitation.
  • [C-1-11] DOIT effacer de manière sécurisée toutes les données utilisateur lors du déverrouillage du bootloader et verrouiller, conformément à la version 9.12. Suppression des données (y compris la partition userdata et les espaces NVRAM).
  • [C-SR-2] Il est FORTEMENT RECOMMANDÉ de vérifier tous les fichiers APK d'application privilégiés avec une chaîne de confiance enracinée dans des partitions protégées par le démarrage validé.
  • [C-SR-3] Il est FORTEMENT RECOMMANDÉ de vérifier tout artefact exécutable chargé par une application privilégiée en dehors de son fichier APK (comme du code chargé dynamiquement ou code compilé) avant de les exécuter ou FORTEMENT RECOMMANDÉ de ne pas les exécuter du tout.
  • DEVRAIT mettre en œuvre une protection contre le rollback pour tout composant avec (modem ou caméra, par exemple) et DEVRAIT utiliser un dispositif de stockage inviolable pour stocker les métadonnées utilisées pour déterminer la version minimale autorisée.

Si les implémentations d'appareils sont déjà lancées sans prendre en charge C-1-8 via C-1-11 sur une version antérieure d'Android et ne peut pas ajouter la prise en charge de ces exigences avec une mise à jour logicielle système, ils PEUVENT être exemptés du exigences.

Le projet Android Open Source en amont offre une implémentation privilégiée cette fonctionnalité dans la external/avb/ qui peut être intégré au bootloader utilisé pour le chargement Android

Implémentations sur les appareils

Si les implémentations d'appareils permettent de valider les fichiers page par page, ils :

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

  • [C-0-4 C-2-2] NE DOIT PAS autoriser les requêtes de lecture sur un fichier protégé pour que l’opération aboutisse lorsque le contenu ne valident pas par rapport à une clé fiable. n'est pas validée par [C-2-1] ci-dessus.

Commencer les nouvelles exigences

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

Mettre fin aux nouvelles exigences

Si des implémentations d'appareils sont déjà lancées sans qu'il soit possible de les vérifier le contenu d'un fichier par rapport à une clé de confiance sur une version antérieure d'Android et ne peut pas ajouter de la prise en charge de cette fonctionnalité par une mise à jour logicielle système, ils PEUVENT être exemptés de cette exigence. Le projet Android Open Source en amont fournit l'implémentation préférée de cette fonctionnalité basée sur la fonctionnalité fs-verity du noyau Linux.

Implémentations pour les appareils:

Si les implémentations de l'appareil sont compatibles avec la confirmation de protection Android API:

  • [C-3-1] DOIT signaler true pour ConfirmationPrompt.isSupported() API.

  • [C-3-2] DOIT s'assurer que le code exécuté dans le système d'exploitation Android, y compris ses du noyau, malveillant ou autre, ne peut pas générer de réponse positive sans l'interaction de l'utilisateur.

  • [C-3-3] DOIT s'assurer que l'utilisateur a pu consulter et approuver les même si le système d'exploitation Android, y compris son noyau, est compromis.

9.11. Clés et identifiants

Le système Android Keystore permet aux développeurs d'applications de stocker des clés cryptographiques dans un conteneur et de les utiliser des opérations cryptographiques via l'API KeyChain ou l'API Keystore. Implémentations pour les appareils:

  • [C-0-1] DOIT autoriser l'importation ou la génération d'au moins 8 192 clés.
  • [C-0-2] L'authentification de l'écran de verrouillage DOIT implémenter un intervalle de temps entre les tentatives infructueuses. Avec "n" comme nombre de tentatives infructueuses, l'heure l'intervalle DOIT être d'au moins 30 secondes pour 9 < n < 30. Pour n > 29, le la valeur de l'intervalle de temps DOIT être au moins de 30*2^floor((n-30)/10)) secondes ou au moins 24 heures, selon la plus courte durée.
  • NE DEVRAIT pas limiter le nombre de clés pouvant être générées

Commencer les nouvelles exigences

  • [C-0-3] DOIT limiter le nombre de tentatives d'authentification principale ayant échoué.
  • [C-SR-2] Il est FORTEMENT RECOMMANDÉ d'implémenter une limite supérieure de 20 échecs les principales tentatives d'authentification, et si les utilisateurs donnent leur consentement et activent , effectuez un "rétablissement de la configuration d'usine", après avoir dépassé la limite de les principales tentatives d’authentification principales.

Si les implémentations d'appareils ajoutent ou modifient des méthodes d'authentification pour déverrouiller le l'écran de verrouillage s'il est basé sur un secret connu et que vous utilisez une nouvelle méthode d'authentification traité comme un moyen sécurisé de verrouiller l'écran, alors:

  • [C-SR-3] Il est FORTEMENT RECOMMANDÉ de définir un code d'accès comportant au moins six chiffres, ou équivaut à une entropie de 20 bits.
  • [C-2-1] Un code PIN de moins de six chiffres NE DOIT PAS autoriser la saisie automatique. sans intervention de l'utilisateur pour éviter de révéler la longueur du code.

Mettre fin aux nouvelles exigences

Lorsque l'implémentation de l'appareil est compatible avec l'utilisation d'un écran de verrouillage sécurisé:

  • [C-1-1] DOIT sauvegarder l'implémentation du keystore avec une couche environnement d'exécution.
  • [C-1-2] DOIT comporter des implémentations RSA, AES, ECDSA, ECDH (si IKeyMintDevice est pris en charge), 3DES, et les algorithmes de chiffrement HMAC, ainsi que le hachage de famille MD5, SHA1 et SHA-2. pour assurer la compatibilité avec les fonctionnalités compatibles avec le système Android Keystore des algorithmes dans une zone isolée en toute sécurité du code exécuté sur le noyau et versions ultérieures. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lequel le code du noyau ou de l'espace utilisateur peut accéder à l'état interne environnement isolé, y compris la loi sur les marchés numériques. Android Open Source en amont du projet (AOSP) répond à cette exigence en utilisant le une implémentation fiable, une autre solution ARM TrustZone ou une solution tierce la mise en œuvre d'une isolation basée sur l'hyperviseur appropriée sont des alternatives options.
  • [C-1-3] DOIT réaliser l'authentification de l'écran de verrouillage dans l'environnement isolé environnement d'exécution et, seulement si l'opération réussit, clés à utiliser. Les identifiants de l'écran de verrouillage DOIVENT être stockés dans un qui permet uniquement à l'environnement d'exécution isolé d'effectuer un verrouillage d'écran l'authentification unique. Le projet Android Open Source en amont fournit Gatekeeper Hardware Abstraction Layer (HAL) et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
  • [C-1-4] DOIT prendre en charge l'attestation des clés lorsque la clé de signature d'attestation est protégées par du matériel sécurisé et la signature s'effectue dans du matériel sécurisé. Les clés de signature des attestations DOIVENT être partagées entre un nombre suffisant appareils pour éviter que les clés ne soient utilisées comme identifiants d'appareils. Aller simple de satisfaire à cette exigence consiste à partager la même clé d'attestation au moins 100 000 unités d'un SKU donné sont produites. Si plus de 100 000 unités d'un SKU sont produites, une clé différente PEUT être utilisée pour chaque tranche de 100 000 unités.

Notez que si l'implémentation d'un appareil est déjà lancée sur une version antérieure d'Android, un appareil de ce type n'est pas tenu de disposer d'un keystore reposant sur un environnement d'exécution isolé et prend en charge l'attestation des clés, sauf s'il déclare la fonctionnalité android.hardware.fingerprint, qui nécessite keystore reposant sur un environnement d'exécution isolé.

  • [C-1-5] DOIT permettre à l'utilisateur de choisir le délai de mise en veille pour la transition de déverrouillé à l'état verrouillé, avec un délai d'inactivité minimal autorisé jusqu'à 15 secondes. Appareils automobiles, qui verrouillent l'écran chaque fois que l'unité principale est éteint ou que l'utilisateur change d'appareil, le délai de mise en veille n'est PEUT-ÊTRE PAS associé au délai de mise en veille. configuration.
  • [C-1-6] DOIT prendre en charge l'un des éléments suivants:
    • IKeymasterDevice 3.0,
    • IKeymasterDevice 4.0,
    • IKeymasterDevice 4.1,
    • IKeyMintDevice version 1 ou
    • IKeyMintDevice version 2.
  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge la version 1 d'IKeyMintDevice.

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

L'implémentation d'AOSP suit un modèle d'authentification à plusieurs niveaux dans lequel un l'authentification principale basée sur la fabrique de connaissances peut s'appuyer sur la biométrie secondaire forte, ou par des modalités tertiaires plus faibles.

Implémentations pour les appareils:

  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ de définir une seule des options suivantes comme authentification principale méthode:

    • Un code PIN numérique
    • Un mot de passe alphanumérique

    • Schéma de balayage sur une grille contenant exactement 3 x 3 points

      Notez que les méthodes d'authentification ci-dessus sont appelées les principales méthodes d'authentification de ce document.

Commencer les nouvelles exigences

  • [C-0-1] DOIT limiter le nombre de tentatives d'authentification principale ayant échoué.
  • [C-SR-5] Il est FORTEMENT RECOMMANDÉ d'implémenter une limite supérieure de 20 échecs les principales tentatives d'authentification et si les utilisateurs donnent leur consentement et activent la fonctionnalité, rétablir la configuration d'usine après avoir dépassé le nombre maximal d'instances dupliquées d'authentification unique.

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

  • [C-SR-6] Il est FORTEMENT RECOMMANDÉ de définir un code d'accès comportant au moins six chiffres, ou équivaut à une entropie de 20 bits.
  • [C-SR-7] Il est FORTEMENT RECOMMANDÉ de NE PAS RÉPONDRE à un code PIN comportant moins de six chiffres pour permettre la saisie automatique sans intervention de l'utilisateur, afin d'éviter de révéler le code PIN

Mettre fin aux nouvelles exigences

Si les mises en œuvre des appareils ajoutent ou modifient l'authentification principale recommandée méthodes et d’utiliser une nouvelle méthode d’authentification comme moyen sécurisé de verrouiller l’écran, la nouvelle méthode d'authentification:

Si les implémentations d'appareils ajoutent ou modifient des méthodes d'authentification pour déverrouiller l'écran de verrouillage s'il est basé sur un secret connu et si vous utilisez une nouvelle pour verrouiller l'écran de manière sécurisée:

  • [C-3-1] L'entropie de la longueur d'entrées la plus courte DOIT être supérieure à 10 bits.
  • [C-3-2] L'entropie maximale de toutes les entrées possibles DOIT être supérieure à 18 bits.
  • [C-3-3] La nouvelle méthode d'authentification NE DOIT PAS remplacer les Méthodes d'authentification principales recommandées (code, schéma, mot de passe, etc.) implémentés et fournis dans AOSP.
  • [C-3-4] La nouvelle méthode d'authentification DOIT être désactivée lorsque L'application DPC (Device Policy Controller) a défini le mot de passe sur les exigences de conformité via la DevicePolicyManager.setRequiredPasswordComplexity() avec une constante de complexité plus restrictive PASSWORD_COMPLEXITY_NONE ou via la méthode DevicePolicyManager.setPasswordQuality() avec une constante plus restrictive que PASSWORD_QUALITY_BIOMETRIC_WEAK.
  • [C-3-5] Les nouvelles méthodes d'authentification DOIVENT recourir au méthodes d'authentification principales recommandées (code PIN, schéma, mot de passe) une fois toutes les 72 heures ou moins OU le divulguer clairement au que certaines données ne seront pas sauvegardées la confidentialité de leurs données.

Si les mises en œuvre des appareils ajoutent ou modifient l'authentification principale recommandée pour déverrouiller l'écran de verrouillage et utiliser une nouvelle méthode d'authentification basée sur la biométrie soit traitée comme un moyen sûr de verrouiller l'écran, le nouveau méthode:

  • [C-4-1] DOIT respecter l'ensemble des exigences décrites dans la section 7.3.10 pour la classe 1 (anciennement Pratique).
  • [C-4-2] DOIT disposer d'un mécanisme de secours pour utiliser l'une des méthodes recommandées méthodes d'authentification principales, basées sur un secret connu.
  • [C-4-3] DOIT être désactivé et n'autoriser que l'instance principale recommandée l'authentification pour déverrouiller l'écran lorsque l'outil de contrôle des règles relatives aux appareils (DPC) application a défini la règle de fonctionnalité de protection du clavier en appelant la méthode DevicePolicyManager.setKeyguardDisabledFeatures() , avec tout indicateur biométrique associé (par exemple, KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE ou KEYGUARD_DISABLE_IRIS).

Si les méthodes d'authentification biométrique ne répondent pas aux exigences pour la classe 3 (anciennement Forte), comme décrit dans section 7.3.10:

  • [C-5-1] Les méthodes DOIVENT être désactivées si l'outil de contrôle des règles relatives aux appareils (DPC) application a défini les exigences relatives aux mots de passe - règle de qualité via la méthode DevicePolicyManager.setRequiredPasswordComplexity(), avec un bucket de complexité plus restrictif que PASSWORD_COMPLEXITY_LOW ou à l'aide de DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive PASSWORD_QUALITY_BIOMETRIC_WEAK
  • [C-5-2] L'utilisateur DOIT être invité à répondre à une question d'authentification principale recommandée (par exemple, code, schéma ou mot de passe), comme indiqué dans le document [C-1-7] et [C-1-8] de la section 7.3.10
  • [C-5-3] Les méthodes NE DOIVENT PAS être traitées comme un écran de verrouillage sécurisé, et DOIVENT être répondre aux exigences commençant par C-8 dans la section ci-dessous.

Si les implémentations d'appareils ajoutent ou modifient des méthodes d'authentification pour déverrouiller l'écran de verrouillage et une nouvelle méthode d'authentification est basée sur un jeton physique ou l'emplacement:

  • [C-6-1] Ils DOIVENT disposer d'un mécanisme de secours pour utiliser l'une des méthodes recommandées d'authentification unique basé sur un secret connu les exigences pour être considéré comme un écran de verrouillage sécurisé.
  • [C-6-2] La nouvelle méthode DOIT être désactivée et n'autoriser qu'une méthodes d'authentification principales recommandées pour déverrouiller l'écran lorsque L'application DPC (Device Policy Controller) a défini la règle avec:
  • [C-6-3] L'utilisateur DOIT être invité à répondre à une question d'authentification méthodes d'authentification (code, schéma, mot de passe, etc.) au moins une fois toutes les 4 heures maximum. Lorsqu'un jeton physique répond aux exigences pour les implémentations de TrustAgent dans C-X, restrictions de délai avant expiration définies dans C-9-5 s'appliquent à la place.
  • [C-6-4] La nouvelle méthode NE DOIT PAS être traitée comme un écran de verrouillage sécurisé, et DOIT être respectez les contraintes énumérées dans C-8 ci-dessous.

Si les implémentations d'appareils disposent d'un écran de verrouillage sécurisé et incluent un ou plusieurs qui implémente l'API système TrustAgentService, il:

  • [C-7-1] DOIT avoir une indication claire dans le menu des réglages et sur la serrure l'écran lorsque le verrouillage de l'appareil est différé ou qu'il peut être déverrouillé par un ou plusieurs agents de confiance. Par exemple, AOSP répond à cette exigence en affichant une description textuelle pour le paramètre "Verrouiller automatiquement" et "Verrouillage instantané" dans menu des paramètres et une icône distincte sur l'écran de verrouillage.
  • [C-7-2] DOIT respecter et implémenter intégralement toutes les API d'agent de confiance dans le DevicePolicyManager, comme la classe KEYGUARD_DISABLE_TRUST_AGENTS constante.
  • [C-7-3] NE DOIT PAS implémenter complètement l'TrustAgentService.addEscrowToken() fonctionne sur un appareil utilisé comme appareil personnel principal (portable), mais PEUT mettre en œuvre la fonction complète sur l'appareil. des implémentations qui sont généralement partagées (par exemple, Android Television ou l'appareil automobile).
  • [C-7-4] DOIT chiffrer tous les jetons stockés ajoutés par TrustAgentService.addEscrowToken()
  • [C-7-5] NE DOIT PAS stocker la clé de chiffrement ni le jeton de séquestre sur le même appareil sur lequel la clé est utilisée. Par exemple, il est autorisé une clé stockée sur un téléphone pour déverrouiller un compte utilisateur sur un téléviseur. Pour les appareils automobiles, le stockage du jeton de séquestre n'est pas autorisé. sur n'importe quelle partie du véhicule.
  • [C-7-6] DOIT informer l'utilisateur des conséquences sur la sécurité avant permettant au jeton de séquestre de déchiffrer le stockage de données.
  • [C-7-7] DOIT disposer d'un mécanisme de secours pour utiliser l'une des méthodes recommandées méthodes d'authentification principales.
  • [C-7-8] L'utilisateur DOIT être invité à utiliser l'une des méthodes d'authentification principales recommandées (par exemple, un code, un schéma ou un 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.
  • [C-7-9] L'utilisateur DOIT être invité à répondre à une question d'authentification d'authentification (code, schéma ou mot de passe, par exemple) telles que décrites dans [C-1-7] et [C-1-8] dans la section 7.3.10, sauf si la sécurité de l'utilisateur (par exemple, la distraction du conducteur) est préoccupante.
  • [C-7-10] NE DOIT PAS être traité comme un écran de verrouillage sécurisé et DOIT respecter les les contraintes énumérées dans C-8 ci-dessous.
  • [C-7-11] NE DOIT PAS autoriser les TrustAgents sur les appareils personnels principaux (p. ex., portable) pour déverrouiller l'appareil, et ne peut l'utiliser que pour un appareil déjà déverrouillé à l'état déverrouillé pendant une durée maximale 4 heures maximum. L'implémentation par défaut de TrustManagerService dans AOSP répond à cette exigence.
  • [C-7-12] DOIT utiliser un chiffrement sécurisé (UKEY2, par exemple) canal de communication pour transmettre le jeton de séquestre à partir du stockage à l'appareil cible.

Si les implémentations d'appareils ajoutent ou modifient des méthodes d'authentification pour déverrouiller l'écran de verrouillage s'il ne s'agit pas d'un écran de verrouillage sécurisé tel que décrit ci-dessus et utilisez une nouvelle méthode d'authentification pour déverrouiller la protection du clavier:

  • [C-8-1] La nouvelle méthode DOIT être désactivée lorsque l'outil de contrôle des règles relatives aux appareils (DPC) a défini la règle de qualité du mot de passe via la DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive PASSWORD_QUALITY_NONE ou via la DevicePolicyManager.setRequiredPasswordComplexity() avec une constante de complexité plus restrictive "PASSWORD_COMPLEXITY_NONE" :
  • [C-8-2] Ils NE DOIVENT PAS réinitialiser les délais d'expiration du mot de passe définis par DevicePolicyManager.setPasswordExpirationTimeout()
  • [C-8-3] Ils NE DOIVENT PAS exposer d'API pour que des applications tierces puissent les utiliser modifier l'état de verrouillage.

Si les implémentations d'appareils permettent aux applications de créer des écrans virtuels et ne prennent pas en charge les événements d'entrée associés, tels que VirtualDeviceManager ils:

  • [C-9-1] DOIT verrouiller ces écrans virtuels secondaires lorsque l'écran par défaut est verrouillé, et déverrouillez ces écrans virtuels secondaires lorsque l'écran par défaut de l'appareil est déverrouillé.

Si les implémentations d'appareils permettent aux applications de créer des écrans virtuels secondaires et de prendre en charge les entrées associées via VirtualDeviceManager, par exemple:

  • [C-10-1] DOIT prendre en charge des états de verrouillage distincts par appareil virtuel
  • [C-10-2] DOIT déconnecter tous les appareils virtuels au terme du délai d'inactivité
  • [C-10-3] DOIT disposer d'un délai d'inactivité
  • [C-10-4] DOIT verrouiller tous les écrans lorsque l'utilisateur lance une verrouillage, y compris par le biais de l' affordance utilisateur de verrouillage requise pour les appareils portables (voir Section 2.2.5[9.11/H-1-2])
  • [C-10-5] DOIT disposer d'instances d'appareils virtuels distinctes par utilisateur
  • [C-10-6] DOIT désactiver la création d'événements d'entrée associés via VirtualDeviceManager (si indiqué par DevicePolicyManager.setNearbyAppStreamingPolicy
  • [C-10-7] DOIT utiliser un presse-papiers distinct uniquement pour chaque appareil virtuel (ou désactivez le presse-papiers pour les appareils virtuels)
  • [C-10-11] DOIT désactiver l'interface utilisateur d'authentification sur les appareils virtuels, y compris saisie du facteur de connaissances et requête biométrique
  • [C-10-12] DOIT empêcher l'affichage des intents initiés à partir d'un appareil virtuel uniquement sur le même appareil virtuel
  • [C-10-13] NE DOIT pas utiliser l'état de verrouillage d'un appareil virtuel comme authentification de l'utilisateur avec le système Android Keystore. Voir KeyGenParameterSpec.Builder.setUserAuthentication*

Lorsque les implémentations d'appareils permettent à l'utilisateur de transférer le facteur de connaissances de l'authentification d'un appareil source à un appareil cible, Par exemple, pour la configuration initiale de l'appareil cible, ils:

  • [C-11-1] DOIT chiffrer le facteur de connaissances avec des garanties de protection semblables à celles celles décrites dans le Service Google Cloud Key Vault livre blanc sur la sécurité lors du transfert de l'appareil source à l'appareil cible, de sorte que le facteur de connaissances ne peut pas être déchiffré à distance ni utilisé pour déverrouiller n'importe quel appareil.
  • [C-11-2] DOIT, sur l'appareil source , demander à l'utilisateur de confirmer facteur de connaissances de l'appareil source avant de transférer le facteur de connaissances à l'appareil cible.
  • [C-11-3] OBLIGATOIRE, sur un appareil cible dépourvu d'authentification principale définie facteur de connaissances, demandez à l'utilisateur de confirmer un facteur de connaissances transféré sur l'appareil cible avant de définir ce facteur de connaissances comme l'appareil principal un facteur de connaissances sur l'authentification pour l'appareil cible et avant d'effectuer toutes les données transférées à partir d'un appareil source.

Si les implémentations d'appareils disposent d'un écran de verrouillage sécurisé et incluent un ou plusieurs des agents de confiance, qui appellent l'API System TrustAgentService.grantTrust() avec l'indicateur FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE:

  • [C-12-1] DOIT appeler grantTrust() uniquement avec l'indicateur en cas de connexion à un à proximité d'un appareil physique avec son propre écran de verrouillage et lorsque l'utilisateur a a authentifié son identité auprès de cet écran de verrouillage. Les appareils à proximité peuvent utiliser des mécanismes de détection au poignet ou sur l'appareil lorsqu'un utilisateur unique déverrouille l'appareil pour répondre aux exigences d'authentification de l'utilisateur.
  • [C-12-2] DOIT placer l'implémentation de l'appareil dans TrustState.TRUSTABLE état lorsque l'écran est éteint (par exemple, en appuyant sur un bouton ou en affichant temps écoulé) et que TrustAgent n'a pas révoqué l'approbation. L'AOSP satisfait aux cette exigence.
  • [C-12-3] DOIT seulement déplacer l'appareil de TrustState.TRUSTABLE vers TrustState.TRUSTED si l'agent de confiance accorde toujours l'approbation en fonction de les exigences spécifiées dans C-12-1.
  • [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 méthodes et précise dans les limites du [C-12-5], lorsque la connexion sous-jacente à l'appareil physique à proximité est perdue.
  • [C-12-5] Mises en œuvre reposant sur des mesures de mesure précises et sécurisées pour respecter les exigences du [C-12-4] DOIT utiliser l'une des solutions suivantes:
    • Implémentations utilisant la UWB:
      • DOIT respecter les exigences de conformité, de certification, d'exactitude exigences d'étalonnage pour l'UWB décrit à la section 7.4.9.
      • DOIT utiliser l'un des modes de sécurité P-STS énumérés dans 7.4.9.
    • Implémentations utilisant le réseau Wi-Fi Neighborhood Awareness (NAN):
      • DOIT respecter les critères de précision 2.2.1 [7.4.2.5/H-SR-1], utilisez la bande passante 160 MHz (ou supérieure), et suivez les étapes de configuration de la mesure spécifiées dans Étalonnage de la présence.
      • DOIT utiliser un LTF sécurisé tel que défini dans IEEE 802.11az.

Si les implémentations d'appareils permettent aux applications de créer des écrans virtuels secondaires et de prendre en charge les entrées associées des événements tels que VirtualDeviceManager ; et que les écrans ne sont pas marqués VIRTUAL_DISPLAY_FLAG_SECURE:

  • [C-13-8] DOIT empêcher le démarrage des activités avec l'attribut android:canDisplayOnRemoteDevices ou les métadonnées android.activity.can_display_on_remote_devices définie sur "false" appareil.
  • [C-13-9] DOIT bloquer des activités qui n'activent pas explicitement les flux de données qui indiquent qu'elles affichent du contenu sensible, y compris via SurfaceView#setSecure, FLAG_SECURE ou SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, d'être sur l'appareil virtuel.
  • [C-13-10] DOIT désactiver l'installation d'applications déclenchées à partir d'appareils virtuels.

Si les implémentations d'appareils sont compatibles avec des états d'affichage distincts via DeviceStateManager ET prendre en charge des états de verrouillage de l'écran distincts via KeyguardDisplayManager, ils:

  • [C-SR-2] Il est FORTEMENT RECOMMANDÉ d'organiser une réunion concernant les certificats. aux exigences définies dans la section 9.11.1 ou à une conformité biométrique au moins Les spécifications de classe 1 définies dans la section 7.3.10 permettent le déverrouillage depuis l'écran par défaut de l'appareil.
  • [C-SR-3] SONT FORTEMENT RECOMMANDÉS de limiter le déverrouillage de l'écran séparément via un délai d'affichage défini.
  • [C-SR-4] Sont FORTEMENT RECOMMANDÉS pour permettre à l'utilisateur de verrouiller globalement tous les écrans grâce au verrouillage de l’appareil portable principal.

9.11.2. StrongBox

Le système Android Keystore permet aux développeurs d'applications de stocker les clés cryptographiques dans un processeur sécurisé dédié ainsi que l'environnement d'exécution isolé décrit ci-dessus. Telle un processeur sécurisé dédié s'appelle "StrongBox". Exigences C-1-3 à C-1-11 ci-dessous définissent les exigences auxquelles un appareil doit répondre sont considérés comme des StrongBox.

Implémentations d'appareils disposant d'un processeur sécurisé dédié:

  • [C-SR-1] EST VIVEMENT RECOMMANDÉ pour la compatibilité avec StrongBox. StrongBox va devenir une exigence dans une prochaine version.

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

  • [C-1-1] DOIT déclarer FEATURE_STRONGBOX_KEYSTORE.

  • [C-1-2] DOIT fournir du matériel dédié et sécurisé utilisé pour keystore et sécurisez l'authentification des utilisateurs. L'interface sécurisée le matériel peut également être utilisé à d'autres fins.

  • [C-1-3] DOIT disposer d'un processeur distinct qui ne partage ni cache, ni DRAM, ni coprocesseurs ou d'autres ressources principales avec le processeur d'application.

  • [C-1-4] DOIT s'assurer que les périphériques partagés avec le point d'accès ne peuvent pas StrongBox d'une manière ou d'une autre, ni obtenir des informations à partir de StrongBox. Le point d'accès PEUT désactiver ou bloquer l'accès à StrongBox.

  • [C-1-5] DOIT disposer d'une horloge interne avec une précision raisonnable (+-10%) immunisé contre la manipulation par le point d’accès.

  • [C-1-6] DOIT disposer d'un véritable générateur de nombres aléatoires une sortie imprévisible et distribuée de manière uniforme.

  • [C-1-7] DOIT disposer d'une résistance à la falsification, y compris contre la pénétration physique et les glitchs.

  • [C-1-8] DOIT disposer d'une résistance dans le canal latéral, y compris contre les fuites d'informations via l'alimentation, la temporisation, le rayonnement électromagnétique et la les canaux secondaires de rayonnement.

  • [C-1-9] DOIT disposer d'un stockage sécurisé qui garantit la confidentialité, l'intégrité, l'authenticité, la cohérence et l'actualisation des contenus. Le stockage NE DOIT PAS être lu ni modifié, sauf conformément aux API StrongBox.

  • Pour valider la conformité avec les normes [C-1-3] à [C-1-9], appareil implémentations:

    • [C-1-10] DOIT inclure le matériel certifié conforme aux normes Profil de protection IC sécurisé BSI-CC-PP-0084-2014 ou évalué par un laboratoire d'essais accrédité au niveau national intégrant Évaluation du risque d'attaque élevé Critères communs, application du potentiel d'attaque Cartes à puce.
    • [C-1-11] DOIT inclure le micrologiciel évalué par une laboratoire d'essais accrédité au niveau national incorporant un niveau d'attaque élevé une évaluation des failles potentielles d'après Common Critères Application of Attack Potential to Smartcards.
    • [C-SR-2] Il est FORTEMENT RECOMMANDÉ d'inclure le matériel évalué à l'aide d'une cible de sécurité, le niveau d'assurance de l'évaluation (EAL) 5, augmentée de AVA_VAN.5. la certification EAL 5 deviendra une exigence dans une prochaine version.
    • [C-SR-3] SONT FORTEMENT RECOMMANDÉS pour offrir une résistance aux attaques d'initiés (IAR), ce qui signifie qu'un initié ayant accès à la signature du micrologiciel ne peuvent pas produire de micrologiciel provoquant une fuite de la StrongBox. afin de contourner les exigences de sécurité fonctionnelles l'accès aux données utilisateur sensibles. La méthode recommandée pour implémenter IAR permet d'autoriser les mises à jour du micrologiciel uniquement lorsque le mot de passe de l'utilisateur principal est fournie via le HAL IAuthSecret.

9.11.3. Identifiants d'identité

Ce système est défini et réalisé en implémentant toutes API disponibles dans android.security.identity.* d'un package. Ces API permettent aux développeurs d'applications de stocker et de récupérer l'identité des utilisateurs documents. Implémentations pour les appareils:

  • Il est FORTEMENT RECOMMANDÉ d'implémenter [C-SR-1] pour implémenter l'identifiant d'identité. Système.

Si les implémentations d'appareils implémentent le système d'identification de l'identité, celles-ci:

  • [C-1-1] DOIT renvoyer une valeur non nulle pour la fonction IdentityCredentialStore#getInstance() .

  • [C-1-2] DOIT implémenter le système d'identification de l'identité (par exemple, les API android.security.identity.*) avec du code communiquant avec une l'application dans une zone isolée en toute sécurité du code exécuté sur le noyau et versions ultérieures. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lequel le code du noyau ou de l'espace utilisateur peut accéder à l'état interne environnement isolé, y compris la loi sur les marchés numériques.

  • [C-1-3] Les opérations cryptographiques nécessaires à la mise en œuvre Le système d'identifiants (par exemple, les API android.security.identity.*) DOIT être effectuées entièrement dans l'application approuvée et le matériel de clé privée DOIT Ne quittez jamais l'environnement d'exécution isolé, sauf si cela est spécifiquement requis par des API de niveau supérieur (par exemple, createEphemeralKeyPair() ).

  • [C-1-4] L'application de confiance DOIT être mise en œuvre de telle sorte que son les propriétés de sécurité ne sont pas affectées (par exemple, les données d'identification ne sont pas publiées) sauf si les conditions de contrôle d’accès sont remplies, les MAC ne peuvent pas être produits pour des données arbitraires) même si la sécurité d'Android est compromise ou si celle-ci est compromise.

Le projet Android Open Source en amont fournit une référence La mise en œuvre d'une application de confiance (libeic) qui peut être utilisé pour implémenter le système d'identification d'identité.

9.12. Suppression des données

Toutes les implémentations d'appareils:

  • [C-0-1] DOIT fournir aux utilisateurs un mécanisme permettant de rétablir la configuration d'usine.
  • [C-0-2] DOIT supprimer toutes les données présentes dans le système de fichiers userdata lors de l'exécution d'une "Rétablir la configuration d'usine".
  • [C-0-3] DOIT supprimer les données de manière à respecter les exigences normes du secteur telles que NIST SP800-88 lors de l'exécution d'une étude Réinitialiser".
  • [C-0-4] DOIT déclencher le rétablissement de la configuration d'usine ci-dessus lorsque le DevicePolicyManager.wipeData() L'API est appelée par l'application de contrôle des règles relatives aux appareils de l'utilisateur principal.
  • PEUT fournir une option d'effacement rapide des données qui n'effectue qu'une effacement logique des données.

9.13. Mode de démarrage sécurisé

Android propose le mode Démarrage sécurisé, qui permet aux utilisateurs de démarrer dans un mode où seules les applications système préinstallées sont autorisées à s'exécuter et toutes les applications tierces les applications sont désactivées. Ce mode, appelé "mode de démarrage sécurisé", fournit à l'utilisateur de désinstaller des applications tierces potentiellement dangereuses.

Les implémentations d'appareils sont les suivantes:

  • [C-SR-1] VIVEMENT RECOMMANDÉ d'implémenter le mode Démarrage sécurisé.

Si les implémentations d'appareils implémentent le mode de démarrage sécurisé, elles:

  • [C-1-1] DOIT fournir à l'utilisateur la possibilité de passer en mode Démarrage sécurisé de manière à ce qu'il ne soit pas les applications installées sur l'appareil, sauf si l'application tierce est Device Policy Controller et a défini UserManager.DISALLOW_SAFE_BOOT sur "true".

  • [C-1-2] DOIT fournir à l'utilisateur la possibilité de désinstaller les applications tierces en mode sans échec ;

  • DEVRAIT donner à l'utilisateur la possibilité d'activer le mode Démarrage sécurisé à partir de un menu de démarrage à l’aide d’un flux de travail différent de celui d’un démarrage normal.

9.14. Isolation des systèmes de véhicule automobile

Les appareils Android Automotive doivent échanger des données avec des véhicules critiques à l'aide du composant vehicle HAL pour envoyer et recevoir des messages sur des réseaux de véhicules tels que CAN Bus.

L'échange de données peut être sécurisé en implémentant des fonctionnalités de sécurité situées sous le Les couches du framework Android pour empêcher toute interaction malveillante ou involontaire ces sous-systèmes.

9.15. Abonnements

"Abonnements" reportez-vous aux détails du forfait de facturation fourni par un opérateur mobile via SubscriptionManager.setSubscriptionPlans()

Toutes les implémentations d'appareils:

  • [C-0-1] DOIT renvoyer les abonnements uniquement à l'application de l'opérateur mobile qui les a fournis à l'origine.
  • [C-0-2] NE DOIT PAS sauvegarder ni importer de forfaits d'abonnement à distance.
  • [C-0-3] DOIT uniquement autoriser les forçages SubscriptionManager.setSubscriptionOverrideCongested(), depuis l'application de l'opérateur mobile proposant actuellement des abonnements valides.

9.16. Migration des données d'application

Si les implémentations d'appareils permettent de migrer les données d'un appareil vers un autre appareil et ne limitez pas les données d'application qu'il copie à celles configurés par le développeur de l'application dans le fichier manifeste via android:fullBackupContent , ils:

  • [C-1-1] NE DOIT PAS lancer de transferts de données d'application depuis appareils sur lesquels l'utilisateur n'a pas défini d'authentification principale décrits dans 9.11.1 Écran de verrouillage sécurisé et authentification.
  • [C-1-2] DOIT confirmer de manière sécurisée l'authentification principale sur la source l'appareil et confirmer l'intention de l'utilisateur à copier les données sur la source appareil avant de transférer des données.
  • [C-1-3] DOIT utiliser l'attestation des clés de sécurité pour s'assurer que la source et l'appareil cible lors de la migration d'un appareil à un autre sont appareils Android légitimes et ont un bootloader verrouillé.
  • [C-1-4] DOIT migrer uniquement les données d'application vers la même application sur le appareil cible avec le même nom de package ET le même certificat de signature.
  • [C-1-5] DOIT afficher une indication que l'appareil source a transmis des données migrés par une migration de données d'appareil à appareil dans le menu des paramètres. Un utilisateur NE DEVRAIT PAS être en mesure de supprimer cette indication.

9.17. Framework de virtualisation Android

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 Package android.system.virtualmachine.
  • [C-1-2] NE DOIT PAS modifier le modèle d'autorisation ni le modèle SELinux d'Android pour gestion des machines virtuelles protégées (pVM).

  • [C-1-3] NE DOIT PAS modifier, omettre ni remplacer les règles "Neverallow" présentes au sein du système/de la règle Sepolicy fournis dans le projet Android Open Source en amont (AOSP) et la stratégie DOIT se compiler avec toutes les règles Neverallow.

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

  • [C-1-5] NE DOIT PAS autoriser de machine virtuelle protégée pVM d'exécuter du code qui ne font 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 en téléchargement indépendant) NE DOIT PAS être exécutées dans un environnement protégé Machine virtuelle :

Commencer les nouvelles exigences

  • [C-1-5] DOIT uniquement autoriser une pVM non débogable à exécuter du code depuis la fabrique ou de leur plate-forme, y compris les mises à jour des applications applications.

Mettre fin aux nouvelles exigences

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

  • [C-2-1] DOIT être capable d'exécuter tous les systèmes d'exploitation disponibles de virtualisation APEX dans une machine virtuelle protégée pVM
  • [C-2-2] NE DOIT PAS autoriser de machine virtuelle protégée pVM pour exécuter un système d'exploitation qui n'est pas signé par le responsable de l'implémentation de l'appareil ou du fournisseur de l'OS.
  • [C-2-3] NE DOIT PAS autoriser de machine virtuelle protégée pVM pour 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 fourni dans le package Android Open Source en amont Projet (AOSP).

  • [C-2-5] DOIT mettre en œuvre une machine virtuelle protégée pVM des mécanismes de défense en profondeur (SELinux pour les pVM, par exemple), 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 premières images que la VM exécutera ne peuvent pas être validées. 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 mémoire exclusivement appartenant à une VM (pVM ou VM hôte) ne sont accessibles qu'aux VM ou de l'hyperviseur, et non par d'autres machines virtuelles, protégées ou non. NE DOIT PAS autoriser les pVM à accéder à une page appartenant à un autre (c'est-à-dire une autre pVM ou un hyperviseur), sauf s'il est explicitement partagé par la page propriétaire. 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 de le renvoyer à l'hôte (par exemple, lorsque 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 prend en charge les API du framework de virtualisation Android, puis, dans tous les domaines:

  • [C-4-1] NE DOIT PAS fournir à une pVM une fonctionnalité permettant de contourner 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 les appareils débloqué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. .

10. Tests de compatibilité logicielle

Les implémentations d'appareils DOIVENT réussir tous les tests décrits dans cette section. Notez toutefois qu'aucun package de test logiciel n'est complet. C'est pourquoi les responsables de la mise en œuvre d'appareils sont VIVEMENT RECOMMANDÉS de faire en sorte le nombre minimal de modifications possibles à apporter à la référence mise en œuvre d'Android disponible dans le projet Android Open Source. Vous limiterez ainsi le risque d'introduire des bugs qui créent des incompatibilités. nécessitant des préparations et des mises à jour potentielles de l'appareil.

10.1. Compatibility Test Suite

Implémentations pour les appareils:

  • [C-0-1] DOIT réussir la certification Android Compatibility Test Suite (CTS) disponible dans le projet Open Source Android, avec la livraison finale logiciel sur l'appareil.

  • [C-0-2] DOIT garantir la compatibilité en cas d'ambiguïté dans CTS et pour toute les réimplémentations de certaines parties du code source de référence.

La CTS est conçue pour être exécutée sur un appareil réel. Comme tout logiciel, la CTS peut elle-même contenir des bugs. Les versions de CTS seront gérées indépendamment définition de compatibilité, et plusieurs révisions de la CTS peuvent être publiées pour Android 14.

Implémentations pour les appareils:

  • [C-0-3] DOIT réussir la dernière version CTS disponible au moment où l'appareil le logiciel est terminé.

  • DEVRAIT utiliser l'implémentation de référence dans l'arborescence Open Source d'Android autant que possible.

10.2. Vérificateur CTS

Le vérificateur CTS est inclus dans la suite de tests de compatibilité. est destiné à être exécuté par un opérateur humain pour tester des fonctionnalités qui ne peuvent pas être testés par un système automatisé, comme le bon fonctionnement d'une caméra capteurs.

Implémentations pour les appareils:

  • [C-0-1] DOIT exécuter correctement tous les cas applicables dans l'outil de vérification CTS.

Le vérificateur CTS a des tests pour de nombreux types de matériel, y compris certains qui est facultatif.

Implémentations pour les appareils:

  • [C-0-2] DOIT réussir tous les tests de son matériel. par exemple, si un appareil est équipé d'un accéléromètre, il DOIT exécuter correctement les Cas de test de l'accéléromètre dans l'outil de vérification CTS.

Scénarios de test pour des fonctionnalités indiquées comme facultatives par la présente définition de compatibilité Le document PEUT être ignoré ou omis.

  • [C-0-2] Chaque appareil et chaque build DOIVENT exécuter correctement le vérificateur CTS. comme indiqué ci-dessus. Cependant, comme de nombreux builds sont très similaires, les appareils les développeurs ne sont pas censés exécuter explicitement le vérificateur CTS sur les builds qui ne diffèrent que de manières insignifiantes. Plus précisément, les implémentations d'appareils qui diffèrent d'une implémentation ayant transmis le vérificateur CTS uniquement par des paramètres régionaux inclus, des éléments de branding, etc. PEUVENT omettre le test CTS Verifier.

11. Logiciels à mettre à jour

  • [C-0-1] Les implémentations d'appareils DOIVENT inclure un mécanisme permettant de remplacer l'intégralité du logiciel système. Le mécanisme n'a pas besoin de fonctionner "en direct" mises à niveau, c'est-à-dire qu'un redémarrage de l'appareil PEUT être nécessaire. Vous pouvez utiliser n'importe quelle méthode, à condition qu'elle puisse remplacer l'intégralité d’un logiciel préinstallé sur l’appareil. Par exemple, l'un des éléments suivants répondront à cette exigence:

    • Over The Air (OTA) téléchargements avec mise à jour hors connexion via un redémarrage.
    • "Partage de connexion" les mises à jour par USB à partir d’un PC hôte.
    • "Hors connexion" des mises à jour par un redémarrage et une mise à jour à partir d’un fichier sur un stockage amovible.

  • [C-0-2] Le mécanisme de mise à jour utilisé DOIT prendre en charge les mises à jour sans effacer les données de l'utilisateur données. En d'autres termes, le mécanisme de mise à jour DOIT préserver les données privées de l'application et les données partagées de l'application. Notez que le logiciel Android en amont inclut de mise à jour répondant à cette exigence.

  • [C-0-3] L'intégralité de la mise à jour DOIT être signée et le mécanisme de mise à jour sur l'appareil Vous DEVEZ valider la mise à jour et la signature par rapport à une clé publique stockée sur l'appareil.

  • [C-SR-1] Le mécanisme de signature est FORTEMENT RECOMMANDÉ pour hacher la mise à jour avec SHA-256 et valider le hachage par rapport à la clé publique à l'aide de l'ECDSA NIST P-256.

Si les implémentations de l'appareil sont compatibles avec les données illimitées comme une connexion 802.11 ou un profil Bluetooth PAN (Personal Area Network, ou réseau personnel), puis:

  • [C-1-1] DOIT prendre en charge les téléchargements OTA avec une mise à jour hors connexion via un redémarrage.

Les implémentations d'appareils DOIVENT vérifier que l'image système est identique au binaire au résultat attendu après une OTA. OTA par bloc dans le projet Open Source Android en amont, ajouté depuis Android 5.1 répond à cette exigence.

De plus, les implémentations d'appareils DOIVENT être compatibles avec les mises à jour du système A/B. L'AOSP implémente cette fonctionnalité à l'aide de la commande de démarrage HAL.

Si une erreur est détectée dans une implémentation d'appareil après sa sortie, mais pendant la durée de vie raisonnable du produit, déterminée en concertation avec l'équipe chargée de la compatibilité Android afin d'affecter la compatibilité des applications applications, puis procédez comme suit:

  • [C-2-1] L'équipe chargée de la mise en œuvre de l'appareil DOIT corriger l'erreur au moyen d'un logiciel mise à jour disponible qui peut être appliquée par le mécanisme qui vient d'être décrit.

Android inclut des fonctionnalités qui permettent à l'application Propriétaire de l'appareil (le cas échéant) de contrôler l'installation des mises à jour du système. Si le sous-système de mise à jour du système pour les appareils signalent android.software.device_admin, puis:

12. Journal des modifications du document

Pour obtenir un résumé des modifications apportées à la définition de compatibilité dans cette version:

13. Nous contacter

Vous pouvez rejoindre le forum sur la compatibilité avec Android et de demander des éclaircissements ou de soulever des problèmes que le document ne vous semble pas la couverture.