1. Introduction
Ce document énumère les exigences à respecter pour que les appareils soient compatibles avec Android 15.
L'utilisation des termes "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" et "OPTIONAL" est conforme à la norme IETF définie dans la RFC2119.
Dans ce document, un "implémentateur d'appareils" ou "implémentateur" désigne une personne ou une organisation qui développe une solution matérielle/logicielle exécutant Android 15. Une "implémentation d'appareil" ou "implémentation" est la solution matérielle/logicielle ainsi développée.
Pour être considérées comme compatibles avec Android 15, les implémentations d'appareils DOIVENT respecter les exigences présentées dans cette définition de la compatibilité, y compris les documents incorporés par référence.
Lorsque cette définition ou les tests logiciels décrits dans la section 10 sont silencieux, ambigus ou incomplets, il incombe à l'implémentateur de l'appareil de s'assurer de la compatibilité avec les implémentations existantes.
C'est pourquoi le projet Open Source Android est à la fois l'implémentation de référence et l'implémentation privilégiée d'Android. Il est vivement recommandé aux implémentateurs d'appareils de baser leurs implémentations dans la mesure du possible sur le code source "en amont" disponible dans le projet Android Open Source. Bien que certains composants puissent être remplacés par d'autres implémentations, il est FORTEMENT RECOMMANDÉ de ne pas suivre cette pratique, car réussir les tests logiciels deviendra beaucoup plus difficile. Il est de la responsabilité de l'implémentateur de garantir une compatibilité comportementale totale avec l'implémentation Android standard, y compris au-delà de la suite de tests de compatibilité. Enfin, notez que certaines substitutions et modifications de composants sont explicitement interdites par ce document.
De nombreuses ressources auxquelles ce document fait référence sont dérivées directement ou indirectement du SDK Android et sont fonctionnellement identiques aux informations de la documentation de ce SDK. Dans tous les cas où cette définition de compatibilité ou la suite de tests de compatibilité ne sont pas conformes à la documentation du SDK, la documentation du SDK est considérée comme faisant autorité. Toutes les informations techniques fournies dans les ressources associées dans ce document sont considérées comme faisant partie de cette définition de compatibilité.
1.1 Structure du document
1.1.1. Exigences par type d'appareil
La section 2 contient toutes les exigences qui s'appliquent à un type d'appareil spécifique. Chaque sous-section de la section 2 est dédiée à un type d'appareil spécifique.
Toutes les autres exigences, qui s'appliquent universellement à toutes les implémentations d'appareils Android, sont listées dans les sections qui suivent la section 2. Ces exigences sont référencées sous le nom "Exigences de base" dans ce document.
1.1.2. ID de la condition
Un ID de contrainte est attribué aux contraintes obligatoires.
- L'ID est attribué uniquement pour les exigences obligatoires.
- Les exigences FORTEMENT RECOMMANDÉES sont marquées comme [SR], mais aucun ID n'est attribué.
- L'ID se compose de trois parties : l'ID de type d'appareil, l'ID de condition et l'ID de l'exigence (par exemple, C-0-1).
Chaque ID est défini comme suit:
- ID de type d'appareil (voir 2. Types d'appareils)
- C: Core (Conditions requises appliquées à toutes les implémentations d'appareils Android)
- H: Appareil portable Android
- T: Appareil Android Television
- A: Implémentation d'Android Automotive
- W: Implémentation de la montre Android
- Onglet: Implémentation sur tablette Android
- ID de la condition
- Lorsque l'exigence est inconditionnelle, cet ID est défini sur 0.
- Lorsque l'exigence est conditionnelle, le nombre 1 est attribué à la première condition, et le nombre augmente de 1 dans la même section et pour le même type d'appareil.
- ID de la condition requise
- Cet ID commence à 1 et augmente de 1 dans la même section et la même condition.
1.1.3. ID de l'exigence dans la section 2
Les ID de condition de la section 2 se composent de deux parties. Le premier correspond à un ID de section, comme décrit ci-dessus. La deuxième partie identifie le facteur de forme et l'exigence spécifique au facteur de forme.
section, suivi de l'ID de l'exigence décrit ci-dessus.
- L'ID de la section 2 se compose de : ID de section / ID de type d'appareil - ID de condition - ID d'exigence (par exemple, 7.4.3/A-0-1).
2. Types d'appareils
Le projet Android Open Source fournit une pile logicielle pouvant être utilisée pour différents types d'appareils et facteurs de forme. Pour assurer la sécurité sur les appareils, la pile logicielle, y compris tout OS de remplacement ou toute implémentation de kernel alternatif, doit s'exécuter dans un environnement sécurisé, comme décrit dans la section 9 et ailleurs dans ce CDD. Il existe quelques types d'appareils dont l'écosystème de distribution d'applications est relativement mieux établi.
Cette section décrit ces types d'appareils, ainsi que les exigences et recommandations supplémentaires applicables à chacun d'eux.
Toutes les implémentations d'appareils Android qui ne correspondent à aucun des types d'appareils décrits DOIVENT respecter toutes les exigences des autres sections de cette définition de compatibilité.
2.1 Configurations de l'appareil
Pour connaître les principales différences de configuration matérielle par type d'appareil, consultez les exigences spécifiques à l'appareil qui suivent dans cette section.
2.2. Exigences concernant les appareils portables
Un appareil Android portable désigne une implémentation d'appareil Android qui est généralement utilisée en le tenant dans la main, comme un lecteur MP3, un téléphone ou une tablette.
Les implémentations d'appareils Android sont classées comme appareils portables si elles répondent à l'ensemble des critères suivants:
- disposer d'une source d'alimentation mobile, comme une batterie ;
- Avoir une diagonale d'écran physique comprise entre 4 et 8 pouces.
- disposer d'une interface de saisie à écran tactile ;
Les exigences supplémentaires du reste de cette section sont spécifiques aux implémentations d'appareils Android portables.
2.2.1. Matériel
Implémentations pour appareils mobiles:
- [7.1.1.1/H-0-1] DOIT comporter au moins un écran compatible avec Android 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] Il est FORTEMENT RECOMMANDÉ de fournir aux utilisateurs une affordance leur permettant de modifier la taille de l'écran (densité d'écran).
[7.1.1.1/H-0-2] DOIT prendre en charge la composition GPU des tampons graphiques d'une taille au moins égale à la résolution la plus élevée de n'importe quel écran intégré.
[7.1.1.1/H-0-3]* Chaque écran
UI_MODE_NORMAL
mis à la disposition des applications tierces DOIT être mappé sur une zone d'affichage physique non obstruée d'au moins 5,6 cm sur le bord court et 8,6 cm sur le bord long.[7.1.1.3/H-0-1]* La valeur de
DENSITY_DEVICE_STABLE
doit être supérieure ou égale à 92% de la densité physique réelle de l'écran correspondant.
Si les implémentations d'appareils portables incluent la prise en charge de Vulkan, elles:
- [7.1.4.2/H-1-1] DOIT respecter les exigences spécifiées par le profil de référence Android 2021.
Si les implémentations d'appareils portables déclarent être compatibles avec les écrans HDR via Configuration.isScreenHdr()
, elles:
- [7.1.4.5/H-1-1] DOIT annoncer la prise en charge des extensions
EGL_EXT_gl_colorspace_bt2020_pq
,EGL_EXT_surface_SMPTE2086_metadata
,EGL_EXT_surface_CTA861_3_metadata
,VK_EXT_swapchain_colorspace
etVK_EXT_hdr_metadata
.
Implémentations pour appareils mobiles:
- [7.1.4.6/H-0-1] DOIT indiquer si l'appareil est compatible avec la fonctionnalité de profilage du 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
, elles:
- [7.1.4.6/H-1-1] DOIT générer en sortie une trace protobuf conforme au schéma des compteurs GPU et des étapes de rendu GPU définies dans la documentation de Perfetto.
- [7.1.4.6/H-1-2] DOIT indiquer des valeurs conformes pour les compteurs GPU de l'appareil conformément au protocole de paquet de trace de compteur GPU.
- [7.1.4.6/H-1-3] DOIT indiquer des valeurs conformes pour les étapes de rendu GPU de l'appareil conformément au protocole de paquet de trace d'étape de rendu.
- [7.1.4.6/H-1-4] DOIT signaler un point de trace de la fréquence du GPU, comme spécifié par le format: power/gpu_frequency.
Implémentations pour appareils mobiles:
- [7.1.5/H-0-1] DOIT inclure la prise en charge du mode de compatibilité des anciennes applications tel qu'implémenté par le code source ouvert Android en amont. Autrement dit, les implémentations d'appareils NE DOIVENT PAS modifier les déclencheurs ou les seuils à partir desquels le mode de compatibilité est activé, et NE DOIVENT PAS modifier le comportement du mode de compatibilité lui-même.
- [7.2.1/H-0-1] L'application doit inclure la prise en charge des applications tierces d'éditeur de mode de saisie (IME).
- [7.2.3/H-0-2] DOIT envoyer à l'application de premier plan l'événement de pression normale et de pression prolongée de la fonction Retour (
KEYCODE_BACK
). Ces événements NE DOIVENT PAS être consommés par le système et PEUVENT être déclenchés en dehors de l'appareil Android (par exemple, un clavier matériel externe connecté à l'appareil Android). - [7.2.3/H-0-3] DOIT fournir la fonction Accueil sur tous les écrans compatibles avec Android qui fournissent l'écran d'accueil.
- [7.2.3/H-0-4] DOIT fournir la fonction Retour sur tous les écrans compatibles avec Android et la fonction Recents sur au moins un des écrans compatibles avec Android.
- [7.2.4/H-0-1] L'appareil DOIT prendre en charge la saisie par écran tactile.
- [7.2.4/H-SR-1] Il est FORTEMENT RECOMMANDÉ de lancer l'application d'assistance sélectionnée par l'utilisateur, c'est-à-dire l'application qui implémente VoiceInteractionService, ou une activité qui gère
ACTION_ASSIST
lors d'un appui prolongé surKEYCODE_MEDIA_PLAY_PAUSE
ouKEYCODE_HEADSETHOOK
si l'activité de 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 accéléromètre à trois axes.
Si les implémentations d'appareils portables incluent un accéléromètre à trois axes, elles:
- [7.3.1/H-1-1] DOIT pouvoir signaler des événements jusqu'à une fréquence d'au moins 100 Hz.
Si les implémentations d'appareils portables incluent un récepteur GPS/GNSS et signalent la fonctionnalité aux applications via l'indicateur de fonctionnalité android.hardware.location.gps
, elles:
- [7.3.3/H-2-1] DOIT signaler les mesures GNSS dès qu'elles sont détectées, même si une position calculée à partir du GPS/GNSS n'est pas encore signalée.
- [7.3.3/H-2-2] DOIT indiquer les pseudo-distances et les taux de pseudo-distance GNSS, qui, dans des conditions d'ensoleillement après avoir déterminé l'emplacement, à l'arrêt ou en mouvement avec une accélération inférieure à 0,2 mètre par seconde au carré, sont suffisants pour calculer la position à 20 mètres près et la vitesse à 0,2 mètre par seconde près, au moins 95% du temps.
Si les implémentations d'appareils portables incluent un gyroscope à trois axes, elles:
- [7.3.4/H-3-1] DOIT pouvoir signaler des événements jusqu'à une fréquence d'au moins 100 Hz.
- [7.3.4/H-3-2] DOIT être capable de mesurer les changements d'orientation jusqu'à 1 000 degrés par seconde.
Implémentations d'appareils portables pouvant passer un appel vocal et indiquer toute valeur autre que PHONE_TYPE_NONE
dans getPhoneType
:
- [7.3.8/H] DOIT inclure un capteur de proximité.
Implémentations pour appareils mobiles:
- [7.3.11/H-SR-1] FORTEMENT RECOMMANDÉ pour prendre en charge le capteur de position à six degrés de liberté.
Début des nouvelles exigences pour Android 15
- [7.4.3/H] DOIT inclure la prise en charge du Bluetooth et du Bluetooth LE.
Implémentations d'appareils portables compatibles avec le Bluetooth LE:
[7.4.3/H-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'extension de la longueur des paquets de données Bluetooth LE.
Fin des nouvelles exigences
Si les appareils sont compatibles avec le protocole NAN (Wi-Fi Neighbor Awareness Networking) en déclarant PackageManager.FEATURE_WIFI_AWARE
et la position Wi-Fi (Wi-Fi Round Trip Time, RTT) en déclarant PackageManager.FEATURE_WIFI_RTT
, ils:
[7.4.2.5/H-1-1] DOIT indiquer la portée avec une précision de +/- 1 mètre pour une bande passante de 160 MHz au 68e percentile (calculé avec la fonction de distribution cumulative), +/- 2 mètres pour une bande passante de 80 MHz au 68e percentile, +/- 4 mètres pour une bande passante de 40 MHz au 68e percentile et +/- 8 mètres pour une bande passante de 20 MHz au 68e percentile à des distances de 10 cm, 1 m, 3 m et 5 m, comme observé via l'API Android WifiRttManager#startRanging.
[7.4.2.5/H-SR-1] Il est FORTEMENT RECOMMANDÉ de signaler la portée avec une précision de +/- 1 mètre à une bande passante de 160 MHz au 90e percentile (calculé avec la fonction de distribution cumulative), de +/- 2 mètres à une bande passante de 80 MHz au 90e percentile, de +/- 4 mètres à une bande passante de 40 MHz au 90e percentile et de +/- 8 mètres à une bande passante de 20 MHz au 90e percentile à des distances de 10 cm, comme observé via l'API Android WifiRttManager#startRanging.
Nous vous RECOMMANDONS vivement de suivre la procédure de configuration des mesures spécifiée dans la section Calibrage de la présence.
Si les implémentations d'appareils portables déclarent FEATURE_BLUETOOTH_LE
, elles:
- [7.4.3/H-1-3] DOIT mesurer et compenser le décalage de réception pour s'assurer que le RSSI BLE médian est de -50 dBm +/-15 dB à 1 m d'un appareil de référence transmettant à
ADVERTISE_TX_POWER_HIGH
. - [7.4.3/H-1-4] DOIT mesurer et compenser le décalage de transmission pour s'assurer que le RSSI BLE médian est de -50 dBm +/-15 dB lors de la numérisation à partir d'un appareil de référence situé à 1 m et transmettant à
ADVERTISE_TX_POWER_HIGH
.
Si les implémentations d'appareils portables incluent un appareil photo logique qui liste les fonctionnalités à l'aide de CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
, elles:
- [7.5.4/H-1-1] Le champ de vision (FOV) doit être normal par défaut et doit être compris entre 50 et 60 degrés.
Implémentations pour appareils mobiles:
- [7.6.1/H-0-1] 4 Go de stockage non volatile minimum doivent être disponibles pour les données privées de l'application (également appelées partition "/data").
- [7.6.1/H-0-2] DOIT renvoyer "true" pour
ActivityManager.isLowRamDevice()
lorsqu'il y a moins de 1 Go de mémoire disponible pour le noyau et l'espace utilisateur.
Si les implémentations d'appareils portables ne déclarent la prise en charge que d'une ABI 32 bits:
[7.6.1/H-1-1] La mémoire disponible pour le kernel et l'espace utilisateur DOIT être d'au moins 416 Mo si l'écran par défaut utilise des résolutions de framebuffer jusqu'à qHD (par exemple, FWVGA).
[7.6.1/H-2-1] La mémoire disponible pour le kernel et l'espace utilisateur DOIT être d'au moins 592 Mo si l'écran par défaut utilise des résolutions de framebuffer jusqu'à HD+ (par exemple, HD, WSVGA).
[7.6.1/H-3-1] La mémoire disponible pour le kernel et l'espace utilisateur DOIT être d'au moins 896 Mo si l'écran par défaut utilise des résolutions de framebuffer jusqu'à FHD (par exemple, WSXGA+).
[7.6.1/H-4-1] La mémoire disponible pour le kernel et l'espace utilisateur DOIT être d'au moins 1 344 Mo si l'écran par défaut utilise des résolutions de frame buffer jusqu'à QHD (par exemple, QWXGA).
Si les implémentations d'appareils portables déclarent la prise en charge d'une ABI 64 bits (avec ou sans ABI 32 bits):
[7.6.1/H-5-1] La mémoire disponible pour le kernel et l'espace utilisateur DOIT être d'au moins 816 Mo si l'écran par défaut utilise des résolutions de tampon d'affichage jusqu'à qHD (par exemple, FWVGA).
[7.6.1/H-6-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 944 Mo si l'écran par défaut utilise des résolutions de framebuffer jusqu'à HD+ (par exemple, HD, WSVGA).
[7.6.1/H-7-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 280 Mo si l'écran par défaut utilise des résolutions de framebuffer jusqu'à FHD (par exemple, WSXGA+).
[7.6.1/H-8-1] La mémoire disponible pour le kernel et l'espace utilisateur DOIT être d'au moins 1 824 Mo si l'écran par défaut utilise des résolutions de tampon de trame jusqu'à QHD (par exemple, QWXGA).
Notez que la "mémoire disponible pour le kernel et l'espace utilisateur" ci-dessus fait référence à l'espace mémoire fourni en plus de toute mémoire déjà dédiée aux composants matériels tels que la radio, la vidéo, etc. qui ne sont pas sous le contrôle du kernel sur les implémentations d'appareils.
Si les implémentations d'appareils portables incluent moins de 1 Go de mémoire disponible pour le noyau et l'espace utilisateur, elles:
- [7.6.1/H-9-1] DOIT déclarer le flag de fonctionnalité
android.hardware.ram.low
. - [7.6.1/H-9-2] DOIT disposer d'au moins 1,1 Go de stockage non volatile pour les données privées de l'application (également appelée partition "/data").
Si les implémentations d'appareils portables incluent plus de 1 Go de mémoire disponible pour le noyau et l'espace utilisateur, elles:
- [7.6.1/H-10-1] DOIT disposer d'au moins 4 Go d'espace de stockage non volatile pour les données privées de l'application (également appelée partition "/data").
- DOIT déclarer le commutateur de fonctionnalité
android.hardware.ram.normal
.
Si les implémentations d'appareils portables incluent au moins 2 Go et moins de 4 Go de mémoire disponible pour le noyau et l'espace utilisateur, elles:
- [7.6.1/H-SR-1] Il est vivement recommandé de n'accepter que l'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, elles:
- [7.6.1/H-1-1] DOIT n'être compatible qu'avec une seule ABI (64 bits uniquement ou 32 bits uniquement).
Implémentations pour appareils mobiles:
- [7.6.2/H-0-1] NE DOIT PAS fournir un espace de stockage partagé d'application inférieur à 1 Go.
- [7.7.1/H] Un port USB compatible avec le mode périphérique DOIT être inclus.
Début des nouvelles exigences pour Android 15
Si les implémentations d'appareils portables incluent un port USB compatible avec un contrôleur fonctionnant en mode périphérique, elles :
- [7.7.1/H-1-1] DOIT implémenter l'API Android Open Accessory (AOA).
Fin des nouvelles exigences
Si les implémentations d'appareils portables incluent un port USB compatible avec le mode hôte, elles:
- [7.7.2/H-1-1] DOIT implémenter la classe audio USB comme indiqué dans la documentation du SDK Android.
Implémentations pour appareils mobiles:
- [7.8.1/H-0-1] DOIT inclure un micro.
- [7.8.2/H-0-1] DOIT disposer d'une sortie audio et déclarer
android.hardware.audio.output
.
Si les implémentations d'appareils portables sont capables de répondre à toutes les exigences de performances pour prendre en charge le mode VR et qu'elles le font, elles:
- [7.9.1/H-1-1] DOIT déclarer le flag de fonctionnalité
android.hardware.vr.high_performance
. - [7.9.1/H-1-2] DOIT inclure une application implémentant
android.service.vr.VrListenerService
qui peut être activée par les applications VR viaandroid.app.Activity#setVrModeEnabled
.
Si les implémentations d'appareils portables incluent un ou plusieurs ports USB-C en mode hôte et implémentent (classe audio USB), en plus des exigences de la section 7.7.2, elles:
- [7.8.2.2/H-1-1] DOIT fournir le mappage logiciel suivant des codes HID:
Fonction | Mappages | Contexte | Comportement |
---|---|---|---|
A | Page d'utilisation du HID: 0x0C Utilisation du HID: 0x0CD Clé du noyau: KEY_PLAYPAUSE Clé Android: KEYCODE_MEDIA_PLAY_PAUSE |
Lecture des contenus multimédias | Entrée: appui bref Sortie: lecture ou pause |
Entrée: appui prolongé Sortie: lancement de la commande vocale Envoi : android.speech.action.VOICE_SEARCH_HANDS_FREE si l'appareil est verrouillé ou si son écran est éteint. Envoyerandroid.speech.RecognizerIntent.ACTION_WEB_SEARCH dans le cas contraire |
|||
Appel entrant | Entrée: appui bref Sortie: accepter l'appel |
||
Entrée: Appuyer de manière prolongée sur Sortie: Refuser l'appel |
|||
Appel en cours | Entrée: appui bref Sortie: raccrocher |
||
Entrée: Appuyez de manière prolongée sur Sortie: Couper ou réactiver le son du micro |
|||
B | Page d'utilisation du HID: 0x0C Utilisation du HID: 0x0E9 Clé du noyau: 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 du casque |
C | Page d'utilisation du HID: 0x0C Utilisation du HID: 0x0EA Clé du noyau: KEY_VOLUMEDOWN Clé Android: VOLUME_DOWN |
Lecture de contenus multimédias, Appel en cours | Entrée: appui court ou long Sortie: baisse le volume du système ou du casque |
D | Page d'utilisation des périphériques HID: 0x0C Utilisation des périphériques HID: 0x0CF Clé du noyau: KEY_VOICECOMMAND Clé Android: KEYCODE_VOICE_ASSIST |
Tous. Peut être déclenché dans n'importe quelle instance. | Entrée: appui court ou long Sortie: lancer la commande vocale |
- [7.8.2.2/H-1-2] DOIT déclencher ACTION_HEADSET_PLUG lors de l'insertion d'une prise, mais uniquement après que les interfaces audio USB et les points de terminaison ont été correctement énumérés afin d'identifier le type de terminal connecté.
Lorsque les types de terminaux audio USB 0x0302 sont détectés, ils:
- [7.8.2.2/H-2-1] DOIT diffuser l'intent ACTION_HEADSET_PLUG avec l'élément supplémentaire "microphone" défini sur 0.
Lorsque les types de terminaux audio USB 0x0402 sont détectés, ils:
- [7.8.2.2/H-3-1] DOIT diffuser l'intent ACTION_HEADSET_PLUG avec le paramètre supplémentaire "micro" défini sur 1.
Lorsque l'API AudioManager.getDevices() est appelée lorsque le périphérique USB est connecté, les éléments suivants sont effectués:
[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 de type de terminal audio USB est 0x0302.[7.8.2.2/H-4-2] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_HEADSET et le rôle
isSink()
si le champ de type de terminal audio USB est 0x0402.[7.8.2.2/H-4-3] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_HEADSET et le rôle
isSource()
si le champ de type de terminal audio USB est 0x0402.[7.8.2.2/H-4-4] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_DEVICE et de rôle
isSink()
si le champ de type de terminal audio USB est 0x603.[7.8.2.2/H-4-5] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_DEVICE et le rôle
isSource()
si le champ de type de terminal audio USB est 0x604.[7.8.2.2/H-4-6] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_DEVICE et le rôle
isSink()
si le champ de 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 le rôle
isSource()
si le champ de type de terminal audio USB est 0x400.[7.8.2.2/H-SR-1] FORTEMENT RECOMMANDÉ lors de la connexion d'un périphérique audio USB-C, pour effectuer l'énumération des descripteurs USB, identifier les types de terminaux et diffuser l'intent ACTION_HEADSET_PLUG en moins de 1 000 millisecondes.
Début des nouvelles exigences pour Android 15
Si
pour
les implémentations d'appareils portables
qui déclarent android.hardware.audio.output
et android.hardware.microphone
,
ils:
consultez les exigences concernant l'écriture RTL et le TTL dans la section 5.6.
[5.6/H-1-1] La latence moyenne de la boucle de rétroaction doit être de 300 ms ou moins sur cinq mesures, avec une déviation absolue moyenne inférieure à 30 ms, sur les chemins de données suivants: "haut-parleur vers micro", adaptateur de boucle de rétroaction 3,5 mm (si compatible), boucle de rétroaction USB (si compatible).
[5.6/H-1-2] La latence moyenne de la pression pour un son doit être de 300 millisecondes ou moins sur au moins cinq mesures sur le chemin de données de l'enceinte au micro.
Fin des nouvelles exigences
Un actionneur linéaire à résonance (LRA) est un système de ressort à masse unique qui présente une fréquence de résonance dominante où la masse se traduit dans la direction du mouvement souhaité.
Si les implémentations d'appareils portables incluent au moins un actionneur linéaire résonant 7.10 à usage général, elles:
[7.10/H] L'emplacement de l'actionneur DOIT être situé à proximité de l'endroit où l'appareil est généralement tenu ou touché par les mains.
[7.10/H] L'actionneur haptique DOIT être déplacé sur l'axe X (gauche-droite) de l'orientation naturelle de l'appareil.
Si les implémentations d'appareils portables disposent d'un actionneur haptique à usage général qui est un actionneur linéaire à résonance (LRA) sur l'axe X, ils:
- [7.10/H] La fréquence de résonance du LRA de l'axe X DOIT être inférieure à 200 Hz.
Si les implémentations d'appareils portables suivent la mise en correspondance des constantes haptiques, elles:
- [7.10/H]* VÉRIFIEZ L'ÉTAT DE L'Implémentation EN ÉCÉRANT LES API android.os.Vibrator.areAllEffectsSupported() ET android.os.Vibrator.arePrimitivesSupported().
[7.10/H]* : DOIT effectuer une évaluation de la qualité pour les constantes haptiques.
[7.10/H]* DOIT vérifier et mettre à jour si nécessaire la configuration de remplacement pour les primitives non prises en charge, comme décrit dans les conseils d'implémentation pour les constantes.
2.2.2. Multimédia
Les implémentations d'appareils portables DOIVENT prendre en charge les formats d'encodage et de décodage audio suivants, et les mettre à la disposition des applications tierces:
- [5.1/H-0-1] AMR-NB
- [5.1/H-0-2] AMR-WB
- [5.1/H-0-3] Profil 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 latence amélioré)
Les implémentations d'appareils portables DOIVENT prendre en charge les formats d'encodage vidéo suivants et les mettre à la disposition des applications tierces:
Les implémentations d'appareils portables DOIVENT prendre en charge les formats de décodage vidéo suivants et les mettre à la disposition des applications tierces:
- [5.3/H-0-1] H.264 AVC
- [5.3/H-0-2] H.265 HEVC
- [5.3/H-0-3] MPEG-4 SP
- [5.3/H-0-4] VP8
- [5.3/H-0-5] VP9
- [5.3/H-0-6] AV1
2.2.3. Logiciel
Implémentations pour appareils mobiles:
- [3.2.3.1/H-0-1] Une application doit gérer les intents
ACTION_GET_CONTENT
,ACTION_OPEN_DOCUMENT
,ACTION_OPEN_DOCUMENT_TREE
etACTION_CREATE_DOCUMENT
comme décrit dans les documents du SDK, et fournir à l'utilisateur la possibilité d'accéder aux données du fournisseur de documents à l'aide de l'APIDocumentsProvider
. - [3.2.3.1/H-0-2]* DOIT précharger une ou plusieurs applications ou composants de service avec un gestionnaire d'intent, pour tous les modèles de filtre d'intent publics définis par les intents d'application suivants listés ici.
- [3.2.3.1/H-SR-1] Nous vous RECOMMANDONS vivement de précharger une application de messagerie capable de gérer les intents ACTION_SENDTO, ACTION_SEND ou ACTION_SEND_MULTIPLE pour envoyer un e-mail.
- [3.4.1/H-0-1] DOIT fournir une implémentation complète de l'API
android.webkit.Webview
. - [3.4.2/H-0-1] DOIT inclure une application de navigateur autonome pour la navigation Web des utilisateurs.
- [3.8.1/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'implémenter un lanceur par défaut compatible avec l'épinglage de raccourcis, de widgets et de widgetFeatures dans l'application.
- [3.8.1/H-SR-2] Il est FORTEMENT RECOMMANDÉ d'implémenter un lanceur par défaut qui permet d'accéder rapidement aux raccourcis supplémentaires fournis par les applications tierces via l'API ShortcutManager.
- [3.8.1/H-SR-3] Il est FORTEMENT RECOMMANDÉ d'inclure une application de lanceur par défaut qui affiche des badges pour les icônes d'application.
- [3.8.2/H-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge les widgets d'applications tierces.
- [3.8.3/H-0-1] DOIT autoriser les applications tierces à avertir les utilisateurs d'événements notables via les classes d'API
Notification
etNotificationManager
. - [3.8.3/H-0-2] DOIT prendre en charge les notifications enrichies.
- [3.8.3/H-0-3] DOIT prendre en charge les notifications heads-up.
- [3.8.3/H-0-4] DOIT inclure une barre de notification, qui permet à l'utilisateur de contrôler directement (par exemple, répondre, répéter, ignorer, bloquer) les notifications via des affordances utilisateur telles que des boutons d'action ou le panneau de configuration tel qu'implémenté dans l'AOSP.
- [3.8.3/H-0-5] DOIT afficher les choix fournis via
RemoteInput.Builder setChoices()
dans le volet des notifications. - [3.8.3/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'afficher le premier choix fourni via
RemoteInput.Builder setChoices()
dans la barre de notification sans interaction utilisateur supplémentaire. - [3.8.3/H-SR-2] Il est FORTEMENT RECOMMANDÉ d'afficher tous les choix fournis via
RemoteInput.Builder setChoices()
dans le volet des notifications lorsque l'utilisateur développe toutes les notifications dans le volet des notifications. - [3.8.3.1/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'afficher les actions pour lesquelles
Notification.Action.Builder.setContextual
est défini surtrue
en ligne avec les réponses affichées parNotification.Remoteinput.Builder.setChoices
. - [3.8.4/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'implémenter un assistant sur l'appareil pour gérer l'action d'assistance.
Si les implémentations d'appareils portables sont compatibles avec les notifications MediaStyle:
- [3.8.3.1/H-SR-2] Il est FORTEMENT RECOMMANDÉ de fournir une affordance utilisateur (par exemple, un sélecteur de sortie) accessible depuis l'interface utilisateur du système, qui permet aux utilisateurs de basculer entre les routes multimédias disponibles appropriées (par exemple, les appareils et les routes Bluetooth fournis à
MediaRouter2Manager
) lorsqu'une application publie une notificationMediaStyle
avec un jetonMediaSession
.
Si les implémentations d'appareils incluant la touche de navigation de la fonction "Récents", comme indiqué dans la section 7.2.3, modifient l'interface, elles:
- [3.8.3/H-1-1] DOIT implémenter le comportement d'épinglage d'écran et fournir à l'utilisateur un menu de paramètres pour activer/désactiver la fonctionnalité.
Si les implémentations d'appareils portables sont compatibles avec l'action d'assistance, elles:
- [3.8.4/H-SR-2] Il est FORTEMENT RECOMMANDÉ d'utiliser l'appui prolongé sur la touche
HOME
comme interaction désignée pour lancer l'application d'assistance, comme décrit dans la section 7.2.3. DOIT lancer l'application d'assistance sélectionnée par l'utilisateur, c'est-à-dire l'application qui implémenteVoiceInteractionService
, ou une activité qui gère l'intentACTION_ASSIST
.
Si les implémentations d'appareils portables sont compatibles avec conversation notifications
et les regroupent dans une section distincte des alertes et des notifications silencieuses non conversationnelles, elles:
- [3.8.4/H-1-1]* : DOIT afficher les notifications de conversation avant les notifications autres que des conversations, à l'exception des notifications de service de premier plan en cours et des notifications importance:high.
Si les implémentations d'appareils Android portables sont compatibles avec un écran de verrouillage, elles:
- [3.8.10/H-1-1] DOIT afficher les notifications de l'écran de verrouillage, y compris le modèle de notification multimédia.
Si les implémentations d'appareils portables sont compatibles avec un écran de verrouillage sécurisé, elles:
- [3.9/H-1-1] DOIT implémenter l'ensemble des stratégies d'administration des appareils définies dans la documentation du SDK Android.
Si les implémentations d'appareils portables sont compatibles avec les API ControlsProviderService
et Control
, et permettent aux applications tierces de publier des commandes d'appareil, elles:
- [3.8.16/H-1-1] DOIT déclarer l'indicateur de fonctionnalité
android.software.controls
et le définir surtrue
. - [3.8.16/H-1-2] DOIT fournir à l'utilisateur une affordance lui permettant d'ajouter, de modifier, de sélectionner et d'utiliser les commandes d'appareil préférées de l'utilisateur à partir des commandes enregistrées par les applications tierces via les API
ControlsProviderService
etControl
. - [3.8.16/H-1-3] DOIT fournir un accès à cette affordance utilisateur dans les trois interactions à partir d'un lanceur par défaut.
[3.8.16/H-1-4] DOIT afficher avec précision dans cette affordance utilisateur le nom et l'icône de chaque application tierce qui fournit des commandes via l'API
ControlsProviderService
, ainsi que tous les champs spécifiés fournis par les APIControl
.[3.8.16/H-1-5] DOIT fournir une affordance utilisateur pour désactiver les commandes d'appareils désignées par l'application à partir des commandes enregistrées par les applications tierces via l'API
ControlsProviderService
et l'APIControl
Control.isAuthRequired
.[3.8.16/H-1-6] Les implémentations d'appareil DOIVENT afficher avec précision l'affordance utilisateur comme suit:
- Si l'appareil a défini
config_supportsMultiWindow=true
et que l'application déclare les métadonnéesMETA_DATA_PANEL_ACTIVITY
dans la déclarationControlsProviderService
, y compris le nom de composant d'une activité valide (tel que défini par l'API), l'application DOIT intégrer cette activité dans cette affordance utilisateur. - Si l'application ne déclare pas les métadonnées
META_DATA_PANEL_ACTIVITY
, elle DOIT afficher les champs spécifiés tels que fournis par l'APIControlsProviderService
, ainsi que tous les champs spécifiés fournis par les API Control.
- Si l'appareil a défini
[3.8.16/H-1-7] Si l'application déclare les métadonnées
META_DATA_PANEL_ACTIVITY
, elle DOIT transmettre la valeur du paramètre défini dans [3.8.16/H-1-5] à l'aide deEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS
lors du lancement de l'activité intégrée.
À l'inverse, si les implémentations d'appareils portables n'implémentent pas de tels contrôles, elles:
- [3.8.16/H-2-1] DOIT signaler
null
pour les APIControlsProviderService
etControl
. - [3.8.16/H-2-2] DOIT déclarer l'indicateur de fonctionnalité
android.software.controls
et le définir surfalse
.
Si les implémentations d'appareils portables ne s'exécutent pas en mode tâche verrouillée, les contenus sont copiés dans le presse-papiers comme suit:
- [3.8.17/H-1-1] L'application DOIT confirmer à l'utilisateur que des données ont été copiées dans le presse-papiers (par exemple, une vignette ou une alerte "Contenu copié"). Indiquez également si les données du presse-papiers seront synchronisées entre les appareils.
Implémentations pour appareils mobiles:
- [3.10/H-0-1] DOIT prendre en charge les services d'accessibilité tiers.
- [3.10/H-SR-1] Il est FORTEMENT RECOMMANDÉ de précharger sur l'appareil des services d'accessibilité comparables ou supérieurs aux fonctionnalités des services d'accessibilité Switch Access et TalkBack (pour les langues prises en charge par le moteur de synthèse vocale préinstallé), comme indiqué dans le projet Open Source talkback.
- [3.11/H-0-1] DOIT prendre en charge l'installation de moteurs TTS tiers.
- [3.11/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un moteur TTS compatible avec les langues disponibles sur l'appareil.
- [3.13/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un composant d'UI des paramètres rapides.
Si les implémentations d'appareils portables Android déclarent la prise en charge de FEATURE_BLUETOOTH
ou de FEATURE_WIFI
, elles:
- [3.16/H-1-1] DOIT prendre en charge la fonctionnalité d'association de l'appareil associé.
Si la fonction de navigation est fournie sous la forme d'une action gestuelle à l'écran:
- [7.2.3/H] La zone de reconnaissance des gestes pour la fonction Accueil NE DOIT PAS dépasser 32 dp de hauteur à partir du bas de l'écran.
Si les implémentations d'appareils portables fournissent une fonction de navigation sous forme de geste à partir de n'importe quel point des bords gauche et droit de l'écran:
- [7.2.3/H-0-1] La zone de gestes de la fonction de navigation DOIT avoir une largeur inférieure à 40 dp de chaque côté. La zone de geste doit mesurer 24 dp de large par défaut.
Si les implémentations d'appareils portables sont compatibles avec un écran de verrouillage sécurisé et disposent de 2 Go de mémoire ou plus disponibles 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 l'indicateur de fonctionnalité
android.software.managed_users
.
Si les implémentations d'appareils Android portables déclarent la prise en charge de la caméra via android.hardware.camera.any
, elles:
- [7.5.4/H-1-1] DOIT respecter l'intent
android.media.action.STILL_IMAGE_CAMERA
etandroid.media.action.STILL_IMAGE_CAMERA_SECURE
, et lancer l'appareil photo en mode photo, comme décrit dans le SDK. - [7.5.4/H-1-2] DOIT respecter l'intent
android.media.action.VIDEO_CAMERA
pour lancer l'appareil photo en mode vidéo, comme décrit dans le SDK.
Si l'application des paramètres de l'implémentation de l'appareil implémente une fonctionnalité de fractionnement à l'aide de l'intégration d'activités, les éléments suivants s'appliquent:
- [3.2.3.1/ H-1-1] Une activité doit gérer l'intent Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY lorsque la fonctionnalité de fractionnement est activée. L'activité DOIT être protégée par
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
et DOIT démarrer l'activité de l'intent analysé à partir de Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.
Si les implémentations d'appareils permettent aux utilisateurs de passer des appels de quelque nature que ce soit,
- [7.4.1.2/H-0-1] Vous devez déclarer le flag de fonctionnalité
android.software.telecom
. - [7.4.1.2/H-0-2] DOIT implémenter le framework télécom.
2.2.4. Performances et puissance
- [8.1/H-0-1] Latence des images cohérente. La latence des images incohérente ou le délai de rendu des images NE DOIT PAS se produire plus de cinq fois par seconde et DOIT être inférieur à une fois par seconde.
- [8.1/H-0-2] Latence de l'interface utilisateur. Les implémentations d'appareils DOIVENT garantir une expérience utilisateur à faible latence en faisant défiler une liste de 10 000 entrées, comme défini par la suite de tests de compatibilité Android (CTS), en moins de 36 secondes.
- [8.1/H-0-3] Changement de tâche. Lorsque plusieurs applications ont été lancées, le redémarrage d'une application déjà en cours d'exécution doit prendre moins d'une seconde.
Implémentations pour appareils mobiles:
- [8.2/H-0-1] DOIT garantir des performances d'écriture séquentielle d'au moins 5 Mo/s.
- [8.2/H-0-2] DOIT assurer des performances d'écriture aléatoire d'au moins 0,5 Mo/s.
- [8.2/H-0-3] DOIT assurer des performances de lecture séquentielle d'au moins 15 Mo/s.
- [8.2/H-0-4] DOIT assurer des performances de lecture aléatoire d'au moins 3,5 Mo/s.
Si les implémentations d'appareils portables incluent des fonctionnalités pour améliorer la gestion de l'alimentation de l'appareil qui sont incluses dans AOSP ou qui étendent les fonctionnalités incluses dans AOSP, elles:
- [8.3/H-1-1] DOIT fournir une affordance utilisateur pour activer et désactiver la fonctionnalité Économiseur de batterie.
- [8.3/H-1-2] L'application DOIT fournir une affordance permettant à l'utilisateur d'afficher toutes les applications exemptées des modes d'économie d'énergie App Standby et Doze.
Implémentations pour appareils mobiles:
- [8.4/H-0-1] DOIT fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle pour chaque composant matériel et l'épuisement approximatif de la batterie causé par les composants au fil du temps, comme indiqué sur le site du projet Android Open Source.
- [8.4/H-0-2] DOIT indiquer toutes les valeurs de consommation d'énergie en milliampères-heure (mAh).
- [8.4/H-0-3] DOIT indiquer la consommation d'énergie du processeur par UID de chaque processus. Le projet Android Open Source répond à cette exigence via l'implémentation du module de noyau
uid_cputime
. - [8.4/H-0-4] Le développeur de l'application DOIT pouvoir accéder à cette consommation d'énergie via la commande shell
adb shell dumpsys batterystats
. - [8.4/H] DOIT être attribué au composant matériel lui-même si vous ne parvenez pas à attribuer la consommation d'énergie du composant matériel à une application.
Si les implémentations d'appareils portables incluent un écran ou une sortie vidéo, elles:
- [8.4/H-1-1] DOIT respecter l'intent
android.intent.action.POWER_USAGE_SUMMARY
et afficher un menu de paramètres qui indique cette consommation d'énergie.
Implémentations pour appareils mobiles:
[8.5/H-0-1] DOIT fournir une affordance utilisateur pour afficher toutes les applications avec des services de premier plan actifs ou des tâches déclenchées par l'utilisateur, y compris la durée de chacun de ces services depuis son démarrage, comme décrit dans le document du SDK.
[8.5/H-0-2]L'application doit fournir une affordance utilisateur pour arrêter une application qui exécute un service de premier plan ou une tâche initiée par l'utilisateur.
2.2.5. Modèle de sécurité
Implémentations pour appareils mobiles:
- [9/H-0-1] VOUS DEVEZ déclarer la fonctionnalité
android.hardware.security.model.compatible
. - [9.1/H-0-1] DOIT autoriser les applications tierces à accéder aux statistiques d'utilisation via l'autorisation
android.permission.PACKAGE_USAGE_STATS
et fournir un mécanisme accessible par l'utilisateur pour accorder ou révoquer l'accès à ces applications en réponse à l'intentandroid.settings.ACTION_USAGE_ACCESS_SETTINGS
.
Début des nouvelles exigences pour Android 15
Les implémentations d'appareils DOIVENT déclarer la compatibilité avec android.software.credentials
et:
[9/H-0-2] DOIT respecter l'intent
android.settings.CREDENTIAL_PROVIDER
pour permettre de sélectionner un fournisseur privilégié pour le Gestionnaire d'identifiants. Ce fournisseur sera activé pour la saisie automatique et sera également l'emplacement par défaut pour enregistrer les nouveaux identifiants saisis via le Gestionnaire d'identifiants.[9/H-0-3] DOIT prendre en charge au moins deux fournisseurs d'identifiants simultanés et fournir une affordance utilisateur dans l'application Paramètres pour activer ou désactiver les fournisseurs.
Fin des nouvelles exigences
Si les implémentations d'appareils déclarent la compatibilité avec android.hardware.telephony
, elles:
- [9.5/H-1-1]
UserManager.isHeadlessSystemUserMode
ne doit PAS être défini surtrue
.
Implémentations pour appareils mobiles:
- [9.11/H-0-2] L'implémentation du keystore doit être sauvegardée avec un environnement d'exécution isolé.
- [9.11/H-0-3] DOIT implémenter les algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que les fonctions de hachage de la famille MD5, SHA-1 et SHA-2 pour prendre en charge correctement les algorithmes compatibles du système Android Keystore dans une zone isolée de manière sécurisée du code exécuté sur le noyau et au-dessus. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lesquels le code du noyau ou de l'espace utilisateur peut accéder à l'état interne de l'environnement isolé, y compris le DMA. Le projet Android Open Source Project (AOSP) en amont répond à cette exigence en utilisant l'implémentation Trusty, mais une autre solution basée sur ARM TrustZone ou une implémentation sécurisée examinée par un tiers d'une isolation basée sur un hyperviseur approprié sont des options alternatives.
- [9.11/H-0-4] DOIT effectuer l'authentification de l'écran de verrouillage dans l'environnement d'exécution isolé et, uniquement en cas de réussite, autoriser l'utilisation des clés liées à l'authentification. Les identifiants de l'écran de verrouillage DOIVENT être stockés de manière à ne permettre qu'à l'environnement d'exécution isolé d'effectuer l'authentification de l'écran de verrouillage. Le projet Android Open Source en amont fournit la couche d'abstraction matérielle (HAL) Gatekeeper et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
Début des nouvelles exigences pour Android 15
[9.11/H-0-5] DOIT prendre en charge l'attestation de clé lorsque la clé de signature d'attestation est protégée par du matériel sécurisé et que la signature est effectuée sur du matériel sécurisé. Les clés de signature d'attestation DOIVENT être
partagées entre un nombre suffisamment important d'appareils pour empêcher leurutilisation comme identifiants d'appareil permanents.Une façon de répondre à cette exigence consiste à partager la même clé d'attestation,sauf si au moins 100 000 unités d'un SKU donné sont produites. Si plus de 100 000 unités d'un SKU sont produites, une clé différente PEUT être utilisée pour chaque tranche de 100 000 unités.
Fin des nouvelles exigences
Notez que si une implémentation d'appareil est déjà lancée sur une version antérieure d'Android, cet appareil est exempté de l'obligation d'avoir un keystore compatible avec un environnement d'exécution isolé et d'accepter l'attestation de clé, sauf s'il déclare la fonctionnalité android.hardware.fingerprint
, qui nécessite un keystore compatible avec un environnement d'exécution isolé.
Lorsque les implémentations d'appareils portables sont compatibles avec un écran de verrouillage sécurisé, elles:
- [9.11/H-1-1] L'appareil DOIT permettre à l'utilisateur de choisir le délai de mise en veille le plus court, c'est-à-dire la durée de transition entre l'état déverrouillé et l'état verrouillé, qui doit être de 15 secondes ou moins.
- [9.11/H-1-2] DOIT fournir à l'utilisateur la possibilité de masquer les notifications et de désactiver toutes les formes d'authentification, à l'exception de l'authentification principale décrite dans la section 9.11.1 Écran de verrouillage sécurisé. L'AOSP répond à cette exigence en tant que mode blocage.
Si les implémentations d'appareils disposent d'un écran de verrouillage sécurisé et incluent un ou plusieurs agents de confiance, qui implémentent l'API système TrustAgentService
, elles:
- [9.11.1/H-1-1] L'utilisateur doit être invité à fournir l'une des méthodes d'authentification primaires recommandées (par exemple, un code, un schéma ou un mot de passe) plus fréquemment qu'une fois toutes les 72 heures.
Si les implémentations d'appareils portables incluent plusieurs utilisateurs et ne déclarent pas l'indicateur de fonctionnalité android.hardware.telephony
, elles:
- [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 fonctionnalités sur l'appareil. Avec les profils restreints, les propriétaires d'appareils peuvent rapidement configurer des environnements distincts pour que d'autres utilisateurs puissent y travailler, et gérer des restrictions plus précises dans les applications disponibles dans ces environnements.
Si les implémentations d'appareils portables incluent plusieurs utilisateurs et déclarent l'indicateur de fonctionnalité android.hardware.telephony
, elles:
- [9.5/H-3-1] NE DOIT PAS prendre en charge les profils restreints, mais DOIT respecter l'implémentation des commandes AOSP pour autoriser /désactiver l'accès des autres utilisateurs aux appels vocaux et aux SMS.
Si les implémentations d'appareils portables définissent UserManager.isHeadlessSystemUserMode
sur true
, elles
- [9.5/H-4-1] NE DOIT PAS inclure la prise en charge des eUICC ni des eSIM avec fonctionnalité d'appel.
- [9.5/H-4-2] NE DOIT PAS déclarer la prise en charge de
android.hardware.telephony
.
Android, via l'API système VoiceInteractionService, prend en charge un mécanisme de détection sécurisée des mots clés toujours activés sans indication d'accès au micro et de détection des requêtes toujours activées, sans indication d'accès au micro ni à la caméra.
Début des nouvelles exigences pour Android 15
Paramètres restreints
Les paramètres restreints fournissent des avertissements visibles à l'utilisateur et sollicitent sa confirmation pour accorder des autorisations à chaque application qui:
- Être installé après avoir été téléchargé via une application (par exemple, une application de chat ou un navigateur) autre qu'une application de "plate-forme de téléchargement d'applications" identifiée par
PackageManager
commePACKAGE_DOWNLOADED_FILE
. - Installer à partir d'un fichier local (par exemple, l'application a été installée en mode hors connexion) identifié par
PackageManager
commePACKAGE_SOURCE_LOCAL_FILE
.
Pour toutes les autorisations appliquées et les identifiants associés listés dans [9.8/H-0-5] ci-dessous.
Ces applications sont désignées par le libellé "Applications couvertes" pour les exigences listées dans cette section.
Implémentations de l'appareil:
[9.8/H-0-1] DOIT implémenter les paramètres restreints comme indiqué ci-dessus pour les éléments suivants:
- Autorisations spéciales
- Accessibilité (
AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
) - Écouteur de notifications (
AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
) - Applications d'administration de l'appareil (
Manifest.permission.BIND_DEVICE_ADMIN
) - Superposer aux autres applications (
AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
) - Accès à l'utilisation (
AppOpsManager.OPSTR_GET_USAGE_STATS
)
- Accessibilité (
- Rôles (applications par défaut)
- Téléphone (
RoleManager.ROLE_DIALER
) - SMS (
RoleManager.ROLE_SMS
)
- Téléphone (
- Autorisations d'exécution
- Durée d'exécution du SMS (
Manifest.permission_group.SMS
)
- Durée d'exécution du SMS (
- Autorisations spéciales
[9.8/H-0-2] Les paramètres restreints DOIVENT être activés par défaut. Il est fortement recommandé de ne pas proposer d'affordance permettant à l'utilisateur de désactiver les paramètres restreints pour toutes les applications.
[9.8/H-0-3] Vous devez OBLIGATOIREMENT vous assurer que l'utilisateur confirme chaque application couverte avant de pouvoir accorder l'une des autorisations appliquées.
[9.8/H-0-4] DOIT n'autoriser que la confirmation de l'utilisateur pour permettre d'obtenir des paramètres restreints à partir de la page AppInfo de l'application couverte, à l'aide de l'API EnhancedConfirmationManager.
[9.8/H-0-5] Il est FORTEMENT RECOMMANDÉ d'intégrer et d'appeler EnhancedConfirmationManager pour toutes les autorisations spéciales afin de déterminer dynamiquement s'il s'agit d'un paramètre limité.
- Alarmes et rappels:
AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
- Accès à tous les fichiers:
AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
- Afficher par-dessus les autres applications:
AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
- Installer des applications inconnues:
AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
- Gérer les contenus multimédias:
AppOpsManager.OPSTR_MANAGE_MEDIA
- Modifier les paramètres système:
AppOpsManager.OPSTR_WRITE_SETTINGS
- Picture-in-picture:
AppOpsManager.OPSTR_PICTURE_IN_PICTURE
- Activer l'écran:
AppOpsManager.OPSTR_TURN_SCREEN_ON
- Notifications en plein écran:
AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
- Contrôle Wi-Fi:
AppOpsManager.OPSTR_CHANGE_WIFI_STATE
- Accessibilité:
AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
- Écouteur de notifications:
AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
- Accès à l'utilisation:
AppOpsManager.OPSTR_GET_USAGE_STATS
- Administrateur de l'appareil:
Manifest.permission.BIND_DEVICE_ADMIN
- Ne pas déranger:
Manifest.permission.MANAGE_NOTIFICATIONS
- Alarmes et rappels:
Fin des nouvelles exigences
Si les implémentations d'appareils portables sont compatibles avec l'API système HotwordDetectionService
ou un autre mécanisme de détection de mots clés sans indication d'accès au micro, elles:
- [9.8/H-1-1] DOIT s'assurer que le service de détection de mot clé ne peut transmettre des données qu'au système, à
ContentCaptureService
ou au service de reconnaissance vocale sur l'appareil créé parSpeechRecognizer#createOnDeviceSpeechRecognizer()
. - [9.8/H-1-2] Le service de détection de mot clé DOIT s'assurer que le service de détection de mot clé ne peut transmettre que des données audio du micro ou des données dérivées de celui-ci au serveur système via l'API
HotwordDetectionService
, ou àContentCaptureService
via l'APIContentCaptureManager
. - [9.8/H-1-3] NE DOIT PAS fournir d'audio du micro de plus de 30 secondes pour une requête individuelle déclenchée par du matériel au service de détection de mot clé.
- [9.8/H-1-4] NE DOIT PAS fournir d'audio de micro tamponné datant de plus de huit secondes pour une requête individuelle au service de détection de mots clés.
- [9.8/H-1-5] NE DOIT PAS fournir d'audio du micro tamponné datant de plus de 30 secondes au service d'interaction vocale ou à une entité similaire.
- [9.8/H-1-6] NE DOIT PAS autoriser la transmission de plus de 100 octets de données (à l'exception des flux audio) en dehors du service de détection de mot clé à chaque résultat de mot clé réussi.
- [9.8/H-1-7] NE DOIT PAS autoriser la transmission de plus de cinq bits de données en dehors du service de détection de mot clé pour chaque résultat de mot clé négatif.
- [9.8/H-1-8] Le service de détection des mots clés DOIT uniquement autoriser la transmission de données en dehors du service de détection des mots clés sur une requête de validation de mot clé provenant du serveur système.
- [9.8/H-1-9] Une application installable par l'utilisateur NE DOIT PAS fournir le service de détection de mots clés.
- [9.8/H-1-10] Les données quantitatives sur l'utilisation du micro par le service de détection de mot clé NE DOIVENT PAS s'afficher dans l'UI.
- [9.8/H-1-11] DOIT consigner le nombre d'octets inclus dans chaque transmission du service de détection des mots clés pour permettre aux chercheurs en sécurité de l'inspecter.
- [9.8/H-1-12] DOIT prendre en charge un mode débogage qui consigne le contenu brut de chaque transmission du service de détection des mots clés pour permettre aux chercheurs en sécurité de l'inspecter.
[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é est transmis au service d'interaction vocale ou à une entité similaire.
[9.8/H-1-15] DOIT s'assurer que les flux audio fournis en cas de résultats de mot clé réussis sont transmis à sens unique du service de détection de mot clé au service d'interaction vocale.
[9.8/H-SR-1] Il est vivement recommandé d'informer les utilisateurs avant de définir une application comme fournisseur du service de détection de mots clés.
[9.8/H-SR-2] Il est FORTEMENT RECOMMANDÉ d'interdire la transmission de données non structurées en dehors du 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 mot clé au moins une fois par heure ou tous les 30 événements déclenchés par du matériel, selon la première éventualité.
Si les implémentations de l'appareil incluent une application qui utilise l'API système HotwordDetectionService
ou un mécanisme similaire pour la détection des mots clés sans indication d'utilisation du micro, l'application:
- [9.8/H-2-1] L'utilisateur doit être informé explicitement de chaque phrase de mot clé compatible.
- [9.8/H-2-2] NE DOIT PAS conserver les données audio brutes ni les données dérivées via le service de détection de mot clé.
- [9.8/H-2-3] Le service de détection de mot clé NE DOIT PAS transmettre à partir du service de détection de mot clé des données audio, des données pouvant être utilisées pour reconstruire (entièrement ou partiellement) l'audio, ou des contenus audio sans rapport avec le mot clé lui-même, sauf au service
ContentCaptureService
ou de reconnaissance vocale sur l'appareil.
Si les implémentations d'appareils portables sont compatibles avec l'API système VisualQueryDetectionService
ou un autre mécanisme de détection des requêtes sans indication d'accès au micro et/ou à la caméra, elles:
- [9.8/H-3-1] DOIT s'assurer que le service de détection des requêtes ne peut transmettre des données qu'au système, à
ContentCaptureService
ou au service de reconnaissance vocale sur l'appareil (créé parSpeechRecognizer#createOnDeviceSpeechRecognizer()
). - [9.8/H-3-2] NE DOIT PAS autoriser la transmission d'informations audio ou vidéo en dehors de la
VisualQueryDetectionService
, sauf versContentCaptureService
ou le service de reconnaissance vocale intégré à l'appareil. - [9.8/H-3-3] DOIT afficher une notification à l'utilisateur dans l'UI du système lorsque l'appareil détecte l'intention de l'utilisateur d'interagir avec l'application d'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 afficher la requête utilisateur détectée dans l'UI juste après sa détection.
- [9.8/H-3-5] Une application installable par l'utilisateur NE DOIT PAS fournir le service de détection des requêtes visuelles.
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 lorsqu'une application accède aux données audio du micro, mais pas lorsque le micro n'est accessible que par
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
ou les applications disposant des rôles mentionnés dans la section 9.1 avec l'identifiant CDD [C-4-X]. - [9.8.2/H-4-2] DOIT afficher la liste des applications récentes et actives qui utilisent le micro, comme indiqué dans
PermissionManager.getIndicatorAppOpUsageData()
, ainsi que les messages d'attribution qui leur sont associés. - [9.8.2/H-4-3] L'indicateur du micro ne doit PAS être masqué pour les applications système qui disposent d'une interface utilisateur visible ou d'une interaction directe avec l'utilisateur.
- [9.8.2/H-4-4] DOIT afficher la liste des applications récentes et actives qui utilisent le micro, comme indiqué par
PermissionManager.getIndicatorAppOpUsageData()
, ainsi que les messages d'attribution 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] L'indicateur de la caméra DOIT s'afficher lorsqu'une application accède aux données de la caméra en direct, mais pas lorsque la caméra n'est accessible que par une ou plusieurs applications disposant des rôles indiqués dans la section 9.1 avec l'identifiant CDD [C-4-X].
- [9.8.2/H-5-2] DOIT afficher les applications récentes et actives à l'aide de la caméra, comme indiqué par
PermissionManager.getIndicatorAppOpUsageData()
, ainsi que les messages d'attribution qui leur sont associés. - [9.8.2/H-5-3] L'indicateur de l'appareil photo ne doit PAS être masqué pour les applications système qui disposent d'une interface utilisateur visible ou d'une interaction directe avec l'utilisateur.
Début des nouvelles exigences pour Android 15
Le démarrage validé est une fonctionnalité qui garantit l'intégrité du logiciel de l'appareil. Si les implémentations de l'appareil sont compatibles avec cette fonctionnalité, elles:
- [9.10/H-1-1] DOIT vérifier toutes les partitions en lecture seule montées pendant la séquence de démarrage d'Android, et le récapitulatif VBMeta doit inclure toutes ces partitions validées dans son calcul.
Fin des nouvelles exigences
2.2.6. Compatibilité des outils et options pour les développeurs
Implémentations pour les appareils portables (* Non applicable aux tablettes):
- [6.1/H-0-1]* : la commande shell
cmd testharness
doit être prise en charge.
Début des nouvelles exigences pour Android 15
Implémentations pour les appareils mobiles (* Non applicable aux tablettes):
- Perfetto
- [6.1/H-0-2]
*doit exposer un binaire/system/bin/perfetto
à l'utilisateur du shell, dont la ligne de commande est conforme à la documentation de perfetto. - [6.1/H-0-3]
*Le binaire perfetto DOIT accepter en entrée une configuration protobuf conforme au schéma défini dans la documentation de perfetto. - [6.1/H-0-4]
*Le binaire perfetto DOIT écrire en sortie une trace protobuf conforme au schéma défini dans la documentation de perfetto. - [6.1/H-0-5]
*doit fournir, via le binaire perfetto, au moins les sources de données décrites dans la documentation de perfetto. - [6.1/H-0-6]
*Le daemon de traçage perfetto DOIT être activé par défaut (propriété systèmepersist.traced.enable
).
- [6.1/H-0-2]
Fin des nouvelles exigences
2.2.7. Classe de performance multimédia pour les appareils portables
Consultez la section 7.11 pour connaître la définition de la classe de performances multimédias.
2.2.7.1. Contenus multimédias
Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.U
pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, elles:
- DOIT respecter les exigences multimédias indiquées dans la section 2.2.7.1 du CDD Android 14.
Début des nouvelles exigences pour Android 15
Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.V
pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, elles:
Fin des nouvelles exigences
- [5.1/H-1-1] DOIT annoncer le nombre maximal de sessions de décodeur vidéo matériel pouvant s'exécuter simultanément dans n'importe quelle combinaison de codecs via les méthodes
CodecCapabilities.getMaxSupportedInstances()
etVideoCapabilities.getSupportedPerformancePoints()
.
Début des nouvelles exigences pour Android 15
- [5.1/H-1-2] DOIT prendre en charge six instances de sessions de décodeur vidéo matériel 8 bits (SDR) (AVC, HEVC, VP9, AV1 ou version ultérieure) dans n'importe quelle combinaison de codecs exécutée simultanément avec trois sessions en résolution 1080p à 30 FPS et trois sessions en résolution 4K à 30 FPS. Pour toutes les sessions, il ne doit pas y avoir plus d'une image perdue par seconde. Les codecs AV1 ne sont tenus de prendre en charge que la résolution 1080p, mais doivent tout de même prendre en charge six instances à 1080p30fps.
Fin des nouvelles exigences
- [5.1/H-1-3] DOIT annoncer le nombre maximal de sessions d'encodeur vidéo matériel pouvant s'exécuter simultanément dans n'importe quelle combinaison de codecs via les méthodes
CodecCapabilities.getMaxSupportedInstances()
etVideoCapabilities.getSupportedPerformancePoints()
.
Début des nouvelles exigences pour Android 15
- [5.1/H-1-4] DOIT prendre en charge six instances de sessions d'encodeur vidéo matériel 8 bits (SDR) (AVC, HEVC, VP9, AV1 ou version ultérieure) dans n'importe quelle combinaison de codecs exécutée simultanément avec quatre sessions en résolution 1080p à 30 FPS et deux sessions en résolution 4K à 30 FPS. Pour toutes les sessions, il ne doit pas y avoir plus d'une image perdue par seconde. Les codecs AV1 ne sont requis que pour la résolution 1080p, mais doivent également prendre en charge six instances à 1080p30fps.
Fin des nouvelles exigences
- [5.1/H-1-5] DOIT annoncer le nombre maximal de sessions d'encodeur et de décodeur vidéo matériel pouvant être exécutées simultanément dans n'importe quelle combinaison de codecs via les méthodes
CodecCapabilities.getMaxSupportedInstances()
etVideoCapabilities.getSupportedPerformancePoints()
.
Début des nouvelles exigences pour Android 15
- [5.1/H-1-6] DOIT prendre en charge six instances de sessions de décodeur vidéo matériel 8 bits (SDR) et d'encodeur vidéo matériel (AVC, HEVC, VP9, AV1 ou version ultérieure) dans n'importe quelle combinaison de codecs exécutée simultanément avec trois sessions en résolution 4K à 30 fps, dont au maximum deux sont des sessions d'encodeur et trois des sessions en résolution 1080p. Pour toutes les sessions, il ne doit pas y avoir plus d'une image perdue par seconde. Les codecs AV1 ne sont requis que pour la résolution 1080p, mais doivent également prendre en charge six instances à 1080p30fps.
Fin des nouvelles exigences
Début des nouvelles exigences pour Android 15
- [5.1/H-1-19] DOIT prendre en charge trois instances de sessions de décodeur vidéo matériel 10 bits (HDR) et d'encodeur vidéo matériel (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, dont au maximum une session d'encodeur, qui peut être configurée au format d'entrée RGBA_1010102 via une surface GL. Pour toutes les sessions, il ne doit pas y avoir plus d'une image perdue par seconde. La génération de métadonnées HDR par l'encodeur n'est pas requise si l'encodage est effectué à partir de la surface GL. Les sessions de codec AV1 ne sont requises que pour la résolution 1080p, même si cette exigence appelle la 4K.
Fin des nouvelles exigences
- [5.1/H-1-7] La latence d'initialisation du codec doit être de 40 ms maximum pour une session d'encodage vidéo 1080p ou inférieure pour tous les encodeurs vidéo matériels en charge. La charge est ici définie comme une session de transcodage vidéo uniquement 1080p vers 720p simultanée à l'aide de codecs vidéo matériels, ainsi que l'initialisation de l'enregistrement audio-vidéo 1080p. Pour le codec Dolby Vision, la latence d'initialisation du codec DOIT être inférieure ou égale à 50 ms.
- [5.1/H-1-8] La latence d'initialisation du codec doit être de 30 ms ou moins pour une session d'encodage audio de 128 kbit/s ou moins pour tous les encodeurs audio en charge. La charge est ici définie comme une session de transcodage vidéo uniquement 1080p vers 720p simultanée à l'aide de codecs vidéo matériels, ainsi que l'initialisation de l'enregistrement audio-vidéo 1080p.
Début des nouvelles exigences pour Android 15
- [5.1/H-1-9] DOIT prendre en charge deux instances de sessions 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 de 1080p à 30 FPS pour les contenus 8 bits (SDR) et 10 bits HDR. Pour toutes les sessions, il ne doit pas y avoir plus d'une image perdue par seconde.
Fin des nouvelles exigences
Début des nouvelles exigences pour Android 15
- [5.1/H-1-10] DOIT prendre en charge trois instances de sessions de décodeur vidéo matériel non sécurisées et une instance de session de décodeur vidéo matériel sécurisé (quatre instances au total) (AVC, HEVC, VP9, AV1 ou version ultérieure) dans n'importe quelle combinaison de codecs exécutée simultanément avec trois sessions en résolution 4K à 30 FPS, y compris une session de décodeur sécurisée et une session non sécurisée en résolution 1080p à 30 FPS, où deux sessions au maximum peuvent être en HDR 10 bits. Pour toutes les sessions, il ne doit pas y avoir plus d'une image perdue par seconde. Les sessions de codec AV1 ne sont requises que pour la résolution 1080p, même si cette exigence appelle la résolution 4K.
Fin des nouvelles exigences
- [5.1/H-1-11] DOIT prendre en charge un décodeur sécurisé pour chaque décodeur matériel AVC, HEVC, VP9 ou AV1 de l'appareil.
- [5.1/H-1-12] La latence d'initialisation du codec doit être de 40 ms ou moins pour une session de décodage vidéo 1080p ou inférieure pour tous les décodeurs vidéo matériels en charge. La charge est ici définie comme une session de transcodage vidéo uniquement 1080p vers 720p simultanée à l'aide de codecs vidéo matériels, ainsi que l'initialisation de la lecture audio-vidéo 1080p. Pour le codec Dolby Vision, la latence d'initialisation du codec DOIT être inférieure ou égale à 50 ms.
- [5.1/H-1-13] La latence d'initialisation du codec doit être de 30 ms maximum pour une session de décodage audio de 128 kbit/s ou moins pour tous les décodeurs audio en charge. La charge est ici définie comme une session de transcodage vidéo uniquement 1080p vers 720p simultanée à l'aide de codecs vidéo matériels, ainsi que l'initialisation de la lecture audio-vidéo 1080p.
Début des nouvelles exigences pour Android 15
- [5.1/H-1-14] DOIT prendre en charge le décodeur matériel AV1 Main 10, niveau 4.1 ainsi que
l'effet film grainet l'effet film grain sur la composition GPU.
Fin des nouvelles exigences
- [5.1/H-1-15] DOIT disposer d'au moins un décodeur vidéo matériel compatible avec la 4K60.
- [5.1/H-1-16] DOIT disposer d'au moins un encodeur vidéo matériel compatible avec la 4K60.
Début des nouvelles exigences pour Android 15
- [5.1/H-1-21] DOIT prendre en charge
FEATURE_DynamicColorAspect
pour tous les décodeurs vidéo matériels (AVC, HEVC, VP9, AV1 ou version ultérieure). Remarque: Cela signifie que les applications peuvent mettre à jour les aspects de couleur du contenu vidéo pendant la session de décodage. Les décodeurs compatibles avec les contenus 10 bits et 8 bits DOIVENT prendre en charge le basculement dynamique entre les contenus 8 bits et 10 bits en mode Surface. Les décodeurs compatibles avec la fonction de transfert HDR DOIVENT prendre en charge le basculement dynamique entre le contenu SDR et HDR.
Fin des nouvelles exigences
Début des nouvelles exigences pour Android 15
- [5.1/H-1-22] DOIT prendre en charge l'encodage, le décodage, le montage avec GPU et l'affichage de contenu vidéo au format portrait, quelle que soit la résolution de la caméra la plus élevée ou la 4K, la plus faible étant retenue. Remarque: cela inclut les profils HDR si le codec est compatible avec le HDR. Les codecs AV1 ne sont requis que pour prendre en charge la résolution 1080p. Cette exigence ne s'applique qu'aux codecs matériels, au GPU et au DPU.
Fin des nouvelles exigences
- [5.3/H-1-1] NE DOIT PAS perdre plus d'une image toutes les 10 secondes (c'est-à-dire moins de 0,167 % de perte d'image) pour une session vidéo 4K 60 FPS sous charge.
- [5.3/H-1-2] NE DOIT PAS perdre plus d'un frame en 10 secondes lors d'un changement de résolution vidéo dans une session vidéo 60 FPS sous charge pour une session 4K.
- [5.6/H-1-1] La latence de la fonctionnalité de contact pour un son doit être de 80 millisecondes ou moins à l'aide du test de contact pour un son du vérificateur CTS.
- [5.6/H-1-2] La latence audio aller-retour doit être de 80 millisecondes ou moins sur au moins un chemin de données compatible.
- [5.6/H-1-3] DOIT prendre en charge l'audio 24 bits pour la sortie stéréo via les prises audio 3,5 mm, le cas échéant, et via l'audio USB, le cas échéant, sur l'ensemble du chemin de données pour les configurations à faible latence et de streaming. Pour la configuration à faible latence, l'application doit utiliser AAudio en mode rappel à faible latence. Pour la configuration de streaming, l'application doit utiliser un AudioTrack Java. Dans les configurations à faible latence et en streaming, le collecteur de sortie HAL doit accepter
AUDIO_FORMAT_PCM_24_BIT
,AUDIO_FORMAT_PCM_24_BIT_PACKED
,AUDIO_FORMAT_PCM_32_BIT
ouAUDIO_FORMAT_PCM_FLOAT
comme format de sortie cible.
Début des nouvelles exigences pour Android 15
- [5.6/H-1-4] L'appareil doit être compatible avec les appareils audio USB à 4 canaux ou plus.
(Cette fonctionnalité est utilisée par les contrôleurs DJ pour prévisualiser des titres.)
Fin des nouvelles exigences
- [5.6/H-1-5] DOIT prendre en charge les appareils MIDI conformes à la classe et déclarer l'indicateur de fonctionnalité MIDI.
- [5.6/H-1-9] DOIT prendre en charge au moins 12 canaux de mixage. Cela implique la possibilité d'ouvrir un AudioTrack avec un masque de canaux 7.1.4 et de spatialiser ou de mixer correctement tous les canaux en stéréo.
- [5.6/H-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge le mixage à 24 canaux, avec au moins la prise en charge des masques de canaux 9.1.6 et 22.2.
- [5.7/H-1-2] DOIT prendre en charge
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
avec les fonctionnalités de déchiffrement de contenu ci-dessous.
Taille minimale de l'échantillon | 4 Mo |
Nombre minimal de sous-échantillons – H.264 ou HEVC | 32 |
Nombre minimal de sous-échantillons – VP9 | 9 |
Nombre minimal de sous-échantillons – AV1 | 288 |
Taille minimale du tampon de sous-échantillonnage | 1 Mo |
Taille minimale du tampon de cryptographie générique | 500 Ko |
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 les sessions) | 6 |
Taille du message | 16 Ko |
Images déchiffrées par seconde | 60 images par seconde |
- [5.1/H-1-17] DOIT comporter au moins un décodeur d'image matériel compatible avec le profil de référence AVIF.
- [5.1/H-1-18] DOIT prendre en charge l'encodeur AV1, qui peut encoder jusqu'à une résolution de 480p à 30 FPS et 1 Mbit/s.
Début des nouvelles exigences pour Android 15
- [5.1/H-1-20] L'appareil DOIT prendre en charge la fonctionnalité
Feature_HdrEditing
pour tous les encodeurs AV1 et HEVC matériels présents sur l'appareil en résolution 4K ou en résolution maximale prise en charge par la caméra, la valeur la plus faible étant retenue.
Fin des nouvelles exigences
- [5.12/H-SR] Il est fortement recommandé de prendre en charge la fonctionnalité
Feature_HdrEditing
pour tous les encodeurs AV1 et HEVC matériels présents sur l'appareil. - [5.12/H-1-2] DOIT être compatible avec le format de couleur RGBA_1010102 pour tous les encodeurs AV1 et HEVC matériels présents sur l'appareil.
- [5.12/H-1-3] DOIT annoncer la prise en charge de l'extension EXT_YUV_target pour échantillonner à partir de textures YUV en 8 et 10 bits.
- [7.1.4/H-1-1] L'unité de traitement d'affichage (DPU) doit comporter au moins six superpositions matérielles, dont au moins deux doivent être capables d'afficher du contenu vidéo 10 bits.
Début des nouvelles exigences pour Android 15
Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.V
pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
et qu'elles incluent la prise en charge d'un encodeur AVC ou HEVC matériel, elles:
Fin des nouvelles exigences
- [5.2/H-2-1] DOIT respecter la cible de qualité minimale définie par les courbes de débit-distorsion de l'encodeur vidéo pour les codecs AVC et HEVC matériels, comme défini dans les tests de la classe de performances 14 (PC14) : qualité de l'encodage vidéo (VEQ).
2.2.7.2. Appareil photo
Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.U
pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, elles:
- DOIT respecter les exigences multimédias listées dans la section 2.2.7.2 du CDD Android 14.
Début des nouvelles exigences pour Android 15
Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.V
pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, elles:
Fin des nouvelles exigences
Début des nouvelles exigences pour Android 15
- [7.5/H-1-1] L'appareil doit comporter une caméra arrière principale d'une résolution d'au moins 12 mégapixels compatible avec la capture vidéo en 4K à 30 FPS, en 1080p à 60 FPS et en 720p à 60 FPS. La caméra arrière principale est la caméra arrière dont l'ID est le plus bas.
Fin des nouvelles exigences
- [7.5/H-1-2] DOIT comporter une caméra avant principale avec une résolution d'au moins 6 mégapixels et prendre en charge la capture vidéo en 1080p à 30 FPS. La caméra avant principale est la caméra avant dont l'ID est le plus bas.
- [7.5/H-1-3] DOIT prendre en charge la propriété
android.info.supportedHardwareLevel
en tant queFULL
ou version ultérieure pour la caméra principale arrière etLIMITED
ou version ultérieure pour la caméra principale avant. - [7.5/H-1-4] DOIT prendre en charge
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
pour les deux caméras principales. - [7.5/H-1-5] La latence de capture JPEG camera2 doit être inférieure à 1 000 ms pour la résolution 1080p, comme mesuré par le test de performances de la caméra CTS dans les conditions d'éclairage ITS (3 000 K) pour les deux caméras principales.
- [7.5/H-1-6] La latence de démarrage de camera2 (ouverture de la caméra au premier frame d'aperçu) DOIT être inférieure à 500 ms, comme mesuré par le test de performances de la caméra CTS dans les conditions d'éclairage ITS (3 000 K) pour les deux caméras principales.
- [7.5/H-1-8] DOIT être compatible avec
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW
etandroid.graphics.ImageFormat.RAW_SENSOR
pour la caméra arrière principale. - [7.5/H-1-9] L'appareil doit comporter une caméra principale arrière compatible avec la résolution 720p ou 1080p à 240 FPS.
- [7.5/H-1-10] ZOOM_RATIO doit être inférieur à 1,0 pour les caméras principales si une caméra RGB ultra grand angle est orientée dans la même direction.
- [7.5/H-1-11] DOIT implémenter le streaming avant/arrière simultané sur les caméras principales.
- [7.5/H-1-12] DOIT prendre en charge
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
pour la caméra avant principale et la caméra arrière principale. - [7.5/H-1-13] DOIT prendre en charge la fonctionnalité
LOGICAL_MULTI_CAMERA
pour la caméra arrière principale s'il existe plusieurs caméras arrière RVB. - [7.5/H-1-14] DOIT prendre en charge la fonctionnalité
STREAM_USE_CASE
pour la caméra avant principale et la caméra arrière principale. - [7.5/H-1-15] DOIT prendre en charge les extensions du mode Nuit via les extensions CameraX et Camera2 pour les caméras principales.
- [7.5/H-1-16] DOIT prendre en charge la fonctionnalité DYNAMIC_RANGE_TEN_BIT pour les caméras principales.
- [7.5/H-1-17] DOIT prendre en charge CONTROL_SCENE_MODE_FACE_PRIORITY et la détection de visage (STATISTICS_FACE_DETECT_MODE_SIMPLE ou STATISTICS_FACE_DETECT_MODE_FULL) pour les caméras principales.
Début des nouvelles exigences pour Android 15
- [7.5/H-1-18] DOIT prendre en charge
JPEG_R
pour les caméras arrière et avant principales. - [7.5/H-1-19] DOIT prendre en charge
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
pour l'aperçu HLG10 1080p avec JPEG au format 16:9 de taille maximale et pour l'aperçu HLG10 720p avec des combinaisons de flux JPEG au format 16:9 de taille maximale pour la caméra arrière principale. - [7.5/H-1-20] L'appareil photo principal arrière et l'appareil photo principal avant doivent afficher
JPEG_R
par défaut dans l'application d'appareil photo native.
Fin des nouvelles exigences
2.2.7.3. Matériel
Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.U
pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, elles:
- DOIT respecter les exigences multimédias indiquées dans la section 2.2.7.3 du CDD Android 14.
Début des nouvelles exigences pour Android 15
Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.V
pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, elles:
Fin des nouvelles exigences
- [7.1.1.1/H-2-1] La résolution d'écran doit être d'au moins 1 080p.
Début des nouvelles exigences pour Android 15
- [7.1.1.3/H-2-1] L'appareil doit avoir une densité d'écran d'au moins 400 dpi si la largeur de l'écran de l'appareil est inférieure à 600 dp.
Fin des nouvelles exigences
- [7.1.1.3/H-3-1] L'appareil doit disposer d'un écran HDR compatible avec une luminosité moyenne d'au moins 1 000 nits.
Début des nouvelles exigences pour Android 15
- [7.6.1/H-2-1] Le système doit disposer d'au moins 8 Go de mémoire physique, avec au moins 6,64 Go disponibles pour le noyau, comme indiqué par
android.app.ActivityManager.MemoryInfo.totalMem
.
Fin des nouvelles exigences
2.2.7.4. Performances
Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.U
pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, elles:
- DOIT respecter les exigences de performances listées dans la section 2.2.7.4 du CDD Android 14.
Début des nouvelles exigences pour Android 15
Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.V
pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, elles:
Fin des nouvelles exigences
- [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éatoires 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 parallèles avec des performances de lecture doublées et d'écriture d'au moins 50 Mo/s.
Début des nouvelles exigences pour Android 15
2.2.7.5. Graphiques
Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.V
pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, elles:
- [7.1.4.1/H-1-2] DOIT prendre en charge les extensions
EGL_IMG_context_priority
etEGL_EXT_protected_content
. - [7.1.4.1/H-1-3] DOIT prendre en charge
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
etVK_KHR_global_priority
.
Fin des nouvelles exigences
2.3. Exigences concernant les téléviseurs
Un appareil Android TV désigne une implémentation d'appareil Android qui est une interface de divertissement permettant de consommer des contenus multimédias numériques, des films, des jeux, des applications et/ou de la télévision en direct pour les utilisateurs assis à environ trois mètres (une interface utilisateur "relax" ou "10 pieds").
Les implémentations d'appareils Android sont classées comme téléviseurs si elles répondent à tous les critères suivants:
- Vous avez fourni un mécanisme permettant de contrôler à distance l'interface utilisateur affichée sur un écran situé à 3 mètres de l'utilisateur.
- Avoir un écran intégré dont la diagonale est supérieure à 60 cm OU inclure un port de sortie vidéo, tel que VGA, HDMI, DisplayPort ou un port sans fil pour l'affichage.
Les exigences supplémentaires du reste de cette section sont spécifiques aux implémentations d'appareils Android TV.
2.3.1. Matériel
Implémentations d'appareils TV:
- [7.2.2/T-0-1] La croix directionnelle doit être prise en charge.
- [7.2.3/T-0-1] DOIT fournir les fonctions "Accueil" et "Retour".
- [7.2.3/T-0-2] DOIT envoyer à l'application de premier plan l'événement de pression normale et de pression prolongée de la fonction Retour (
KEYCODE_BACK
). - [7.2.6.1/T-0-1] DOIT inclure la prise en charge des manettes de jeu et déclarer le flag de fonctionnalité
android.hardware.gamepad
. - [7.2.7/T] DOIT fournir une télécommande à partir de laquelle les utilisateurs peuvent accéder à la navigation non tactile et aux entrées des principales touches de navigation.
Si les implémentations d'appareils de télévision incluent un gyroscope à trois axes, elles:
- [7.3.4/T-1-1] DOIT pouvoir signaler des événements jusqu'à une fréquence d'au moins 100 Hz.
- [7.3.4/T-1-2] DOIT être capable de mesurer les changements d'orientation jusqu'à 1 000 degrés par seconde.
Implémentations d'appareils TV:
- [7.4.3/T-0-1] DOIT prendre en charge Bluetooth et Bluetooth LE.
- [7.6.1/T-0-1] DOIT disposer d'au moins 4 Go d'espace de stockage non volatile pour les données privées de l'application (également appelée partition "/data").
Si les implémentations d'appareils de télévision incluent un port USB compatible avec le mode hôte, elles:
- [7.5.3/T-1-1] DOIT inclure la compatibilité avec une caméra externe qui se connecte via ce port USB, mais qui n'est pas nécessairement toujours connectée.
Si les implémentations de l'appareil TV sont 32 bits:
[7.6.1/T-1-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 896 Mo si l'une des densités suivantes est utilisée:
- 400 dpi ou plus sur les écrans de petite/moyenne taille
- xhdpi ou version ultérieure sur les grands écrans
- tvdpi ou version ultérieure sur les écrans très grands
Si les implémentations de l'appareil TV sont 64 bits:
[7.6.1/T-2-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 280 Mo si l'une des densités suivantes est utilisée:
- 400 dpi ou plus sur les écrans de petite/moyenne taille
- xhdpi ou version ultérieure sur les grands écrans
- tvdpi ou version ultérieure sur les écrans très grands
Notez que la "mémoire disponible pour le kernel et l'espace utilisateur" ci-dessus fait référence à l'espace mémoire fourni en plus de toute mémoire déjà dédiée aux composants matériels tels que la radio, la vidéo, etc. qui ne sont pas sous le contrôle du kernel sur les implémentations d'appareils.
Implémentations d'appareils TV:
- [7.8.1/T] DOIT inclure un micro.
- [7.8.2/T-0-1] DOIT comporter une sortie audio et déclarer
android.hardware.audio.output
.
2.3.2. Multimédia
Les implémentations d'appareils de télévision DOIVENT prendre en charge les formats d'encodage et de décodage audio suivants, et les mettre à la disposition des applications tierces:
- [5.1/T-0-1] Profil MPEG-4 AAC (AAC LC)
- [5.1/T-0-2] Profil MPEG-4 HE AAC (AAC+)
- [5.1/T-0-3] AAC ELD (AAC à faible latence améliorée)
Les implémentations d'appareils de télévision DOIVENT prendre en charge les formats d'encodage vidéo suivants et les mettre à la disposition des applications tierces:
Implémentations d'appareils TV:
- [5.2.2/T-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'encodage H.264 des vidéos en résolution 720p et 1080p à 30 images par seconde.
Les implémentations d'appareils de télévision DOIVENT prendre en charge les formats de décodage vidéo suivants et les mettre à la disposition des applications tierces:
- [5.3.3/T-0-1] MPEG-4 SP
- [5.3.4/T-0-2] H.264 AVC
- [5.3.5/T-0-3] H.265 HEVC
- [5.3.6/T-0-4] VP8
- [5.3.7/T-0-5] VP9
- [5.3.1/T-0-6] MPEG-2
- [5.3.2/T-0-7] AV1
Les implémentations d'appareils de télévision DOIVENT prendre en charge le décodage MPEG-2, comme indiqué dans la section 5.3.1, à des fréquences d'images et résolutions vidéo standards jusqu'à:
- [5.3.1/T-1-1] HD 1080p à 29,97 images par seconde avec le profil principal de niveau élevé.
- [5.3.1/T-1-2] HD 1080i à 59,94 images par seconde avec le profil principal de niveau élevé. Ils DOIVENT démêler la vidéo MPEG-2 entrelacée et la mettre à la disposition des applications tierces.
Les implémentations d'appareils de télévision DOIVENT prendre en charge le décodage H.264, comme indiqué dans la section 5.3.4, à des fréquences d'images et résolutions vidéo standards jusqu'à:
- [5.3.4/T-1-1] HD 1080p à 60 images par seconde avec le profil de référence
- [5.3.4/T-1-2] HD 1080p à 60 images par seconde avec le profil principal
- [5.3.4/T-1-3] HD 1080p à 60 images par seconde avec High Profile Level 4.2
Les implémentations d'appareils de télévision avec des décodeurs matériels H.265 DOIVENT prendre en charge le décodage H.265, comme indiqué dans la section 5.3.5, aux fréquences d'images et résolutions vidéo standards jusqu'à:
- [5.3.5/T-1-1] HD 1080p à 60 images par seconde avec le profil principal de niveau 4.1
Si les implémentations d'appareils de télévision avec des décodeurs matériels H.265 prennent en charge le décodage H.265 et le profil de décodage UHD, elles:
- [5.3.5/T-2-1] DOIT prendre en charge le profil de décodage UHD à 60 images par seconde avec le profil Main10 de niveau 5
Les implémentations d'appareils de télévision DOIVENT prendre en charge le décodage VP8, comme indiqué dans la section 5.3.6, à des fréquences d'images et résolutions vidéo standards jusqu'à:
- [5.3.6/T-1-1] Profil de décodage HD 1080p à 60 images par seconde
Les implémentations d'appareils de télévision avec des décodeurs matériels VP9 DOIVENT prendre en charge le décodage VP9, comme indiqué dans la section 5.3.7, aux fréquences d'images et résolutions vidéo standards jusqu'à:
- [5.3.7/T-1-1] HD 1080p à 60 images par seconde avec le profil 0 (profondeur de couleur de 8 bits)
Si les implémentations d'appareils de télévision avec des décodeurs matériels VP9 prennent en charge le décodage VP9 et le profil de décodage UHD, elles:
- [5.3.7/T-2-1] DOIT prendre en charge le profil de décodage UHD à 60 images par seconde avec le profil 0 (profondeur de couleur de 8 bits).
- [5.3.7/T-SR1] Il est FORTEMENT RECOMMANDÉ de prendre en charge le profil de décodage UHD à 60 images par seconde avec le profil 2 (profondeur de couleur de 10 bits).
Implémentations d'appareils TV:
- [5.5/T-0-1] DOIT inclure la prise en charge du volume principal du système et de l'atténuation du volume de sortie audio numérique sur les sorties compatibles, à l'exception de la sortie de passthrough audio compressé (où aucun décodage audio n'est effectué sur l'appareil).
Si les implémentations d'appareils de télévision ne disposent pas d'écran intégré, mais prennent en charge un écran externe connecté via HDMI, elles:
- [5.8/T-0-1] Le mode de sortie HDMI doit être défini sur la résolution la plus élevée pour le format de pixel choisi, qui fonctionne avec une fréquence d'actualisation de 50 Hz ou 60 Hz pour l'écran externe, en fonction de la fréquence d'actualisation vidéo de la région dans laquelle l'appareil est vendu.
- [5.8/T-SR-1] Il est FORTEMENT RECOMMANDÉ de fournir un sélecteur de fréquence d'actualisation HDMI configurable par l'utilisateur.
- [5.8] LE MODÈLE DOIT définir la fréquence d'actualisation du mode de sortie HDMI sur 50 Hz ou 60 Hz, en fonction de la fréquence d'actualisation vidéo de la région dans laquelle l'appareil est vendu.
Si les implémentations d'appareils de télévision ne disposent pas d'écran intégré, mais prennent en charge un écran externe connecté via HDMI, elles:
- [5.8/T-1-1] La prise en charge de la norme HDCP 2.2 est OBLIGATOIRE.
Si les implémentations d'appareils de télévision ne sont pas compatibles avec le décodage UHD, mais qu'elles prennent en charge un écran externe connecté via HDMI, elles:
- [5.8/T-2-1] DOIT prendre en charge HDCP 1.4
2.3.3. Logiciel
Implémentations d'appareils TV:
- [3/T-0-1] DOIT déclarer les fonctionnalités
android.software.leanback
etandroid.hardware.type.television
. - [3.2.3.1/T-0-1] DOIT précharger une ou plusieurs applications ou composants de service avec un gestionnaire d'intent, pour tous les modèles de filtre d'intent publics définis par les intents d'application suivants listés ici.
- [3.4.1/T-0-1] DOIT fournir une implémentation complète de l'API
android.webkit.Webview
.
Si les implémentations d'appareils Android TV sont compatibles avec un écran de verrouillage,elles:
- [3.8.10/T-1-1] DOIT afficher les notifications de l'écran de verrouillage, y compris le modèle de notification multimédia.
Implémentations d'appareils TV:
- [3.8.14/T-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge le mode multifenêtre Picture-in-picture (PIP).
- [3.10/T-0-1] DOIT prendre en charge les services d'accessibilité tiers.
- [3.10/T-SR-1] Il est FORTEMENT RECOMMANDÉ de précharger sur l'appareil des services d'accessibilité comparables ou supérieurs aux fonctionnalités des services d'accessibilité Switch Access et TalkBack (pour les langues prises en charge par le moteur de synthèse vocale préinstallé) tels que fournis dans le projet Open Source talkback.
Si les implémentations d'appareils de télévision signalent la fonctionnalité android.hardware.audio.output
, elles:
- [3.11/T-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un moteur TTS compatible avec les langues disponibles sur l'appareil.
- [3.11/T-1-1] DOIT prendre en charge l'installation de moteurs TTS tiers.
Début des nouvelles exigences pour Android 15
Implémentations d'appareils TV:
- [3.12/T-0-1] DOIT prendre en charge le TV Input Framework.
Fin des nouvelles exigences
Début des nouvelles exigences pour Android 15
Le framework d'entrée Android TV (TIF) simplifie la diffusion de contenus en direct sur les appareils Android TV. TIF fournit une API standard pour créer des modules d'entrée qui contrôlent les appareils Android TV.
Implémentations d'appareils TV:
- [3/T-0-2] DOIT déclarer la fonctionnalité de plate-forme
android.software.live_tv
. - [3/T-0-3] DOIT prendre en charge toutes les API TIF afin qu'une application qui utilise ces API et le service d'entrées tierces basées sur TIF puisse être installée et utilisée sur l'appareil.
Le framework Android Television Tuner (TF) unifie la gestion du contenu en direct du tuner avec le contenu en streaming à partir d'une adresse IP sur les appareils Android Television. Le Tuner Framework fournit une API standard pour créer des services d'entrée qui utilisent le tuner Android TV.
Si les implémentations d'appareils sont compatibles avec le tuner, elles:
- [3/T-1-1] DOIT être compatible avec toutes les API du framework Tuner afin qu'une application qui utilise ces API puisse être installée et utilisée sur l'appareil.
Fin des nouvelles exigences
2.3.4. Performances et puissance
- [8.1/T-0-1] Latence des images cohérente. La latence des images incohérente ou le délai de rendu des images NE DOIT PAS se produire plus de cinq fois par seconde et DOIT être inférieur à une fois par seconde.
- [8.2/T-0-1] DOIT assurer des performances d'écriture séquentielle d'au moins 5 Mo/s.
- [8.2/T-0-2] DOIT garantir des performances d'écriture aléatoire d'au moins 0,5 Mo/s.
- [8.2/T-0-3] DOIT assurer des performances de lecture séquentielle d'au moins 15 Mo/s.
- [8.2/T-0-4] DOIT assurer des performances de lecture aléatoire d'au moins 3,5 Mo/s.
Si les implémentations d'appareils de télévision incluent des fonctionnalités permettant d'améliorer la gestion de l'alimentation de l'appareil qui sont incluses dans AOSP ou qui étendent les fonctionnalités incluses dans AOSP, elles:
- [8.3/T-1-1] DOIT fournir une affordance utilisateur pour activer et désactiver la fonctionnalité Économiseur de batterie.
Si les implémentations d'appareils de télévision ne disposent pas de batterie:
- [8.3/T-1-2] DOIT enregistrer l'appareil en tant qu'appareil sans batterie, comme décrit dans la section Prendre en charge les appareils sans batterie.
Si les implémentations d'appareils de télévision sont équipées d'une batterie:
- [8.3/T-1-3] DOIT fournir une affordance utilisateur pour afficher toutes les applications exemptées des modes d'économie d'énergie Mise en veille des applications et Sommeil.
Implémentations d'appareils TV:
- [8.4/T-0-1] DOIT fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle pour chaque composant matériel et l'épuisement approximatif de la batterie causé par les composants au fil du temps, comme indiqué sur le site du projet Open Source Android.
- [8.4/T-0-2] DOIT indiquer toutes les valeurs de consommation d'énergie en milliampères-heure (mAh).
- [8.4/T-0-3] DOIT indiquer la consommation d'énergie du processeur par UID de chaque processus. Le projet Android Open Source répond à cette exigence via l'implémentation du module de noyau
uid_cputime
. - [8.4/T] DOIT être attribué au composant matériel lui-même si vous ne parvenez pas à attribuer la consommation d'énergie du composant matériel à une application.
- [8.4/T-0-4] Le développeur de l'application DOIT pouvoir accéder à cette consommation d'énergie via la commande shell
adb shell dumpsys batterystats
.
2.3.5. Modèle de sécurité
Implémentations d'appareils TV:
- [9/T-0-1] Vous devez déclarer la fonctionnalité
android.hardware.security.model.compatible
. - [9.11/T-0-1] L'implémentation du keystore DOIT être sauvegardée avec un environnement d'exécution isolé.
- [9.11/T-0-2] DOIT implémenter les algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que les fonctions de hachage de la famille MD5, SHA-1 et SHA-2 pour prendre en charge correctement les algorithmes compatibles du système Android Keystore dans une zone isolée de manière sécurisée du code exécuté sur le noyau et au-dessus. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lesquels le code du noyau ou de l'espace utilisateur peut accéder à l'état interne de l'environnement isolé, y compris le DMA. Le projet Android Open Source Project (AOSP) en amont répond à cette exigence en utilisant l'implémentation Trusty, mais une autre solution basée sur ARM TrustZone ou une implémentation sécurisée examinée par un tiers d'une isolation basée sur un hyperviseur approprié sont des options alternatives.
- [9.11/T-0-3] DOIT effectuer l'authentification de l'écran de verrouillage dans l'environnement d'exécution isolé et, uniquement en cas de réussite, autoriser l'utilisation des clés liées à l'authentification. Les identifiants de l'écran de verrouillage DOIVENT être stockés de manière à ne permettre qu'à l'environnement d'exécution isolé d'effectuer l'authentification de l'écran de verrouillage. Le projet Android Open Source en amont fournit la couche d'abstraction matérielle (HAL) Gatekeeper et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
Début des nouvelles exigences pour Android 15
[9.11/T-0-4] DOIT prendre en charge l'attestation de clé lorsque la clé de signature d'attestation est protégée par du matériel sécurisé et que la signature est effectuée sur du matériel sécurisé. Les clés de signature d'attestation DOIVENT être
partagées entre un nombre suffisamment important d'appareils pour empêcher leurutilisation comme identifiants d'appareil permanents.Une façon de répondre à cette exigence consiste à partager la même clé d'attestation,sauf si au moins 100 000 unités d'un SKU donné sont produites. Si plus de 100 000 unités d'un SKU sont produites, une clé différente PEUT être utilisée pour chaque tranche de 100 000 unités.
Fin des nouvelles exigences
Notez que si une implémentation d'appareil est déjà lancée sur une version antérieure d'Android, cet appareil est exempté de l'obligation d'avoir un keystore compatible avec un environnement d'exécution isolé et d'accepter l'attestation de clé, sauf s'il déclare la fonctionnalité android.hardware.fingerprint
, qui nécessite un keystore compatible avec un environnement d'exécution isolé.
Si les implémentations d'appareils de télévision sont compatibles avec un écran de verrouillage sécurisé, elles:
- [9.11/T-1-1] L'appareil DOIT permettre à l'utilisateur de choisir le délai de mise en veille pour la transition de l'état déverrouillé à l'état verrouillé, avec un délai minimal autorisé de 15 secondes ou moins.
Si les implémentations d'appareils de télévision incluent plusieurs utilisateurs et ne déclarent pas l'indicateur de fonctionnalité android.hardware.telephony
, elles:
- [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 fonctionnalités sur l'appareil. Avec les profils restreints, les propriétaires d'appareils peuvent rapidement configurer des environnements distincts pour que d'autres utilisateurs puissent y travailler, et gérer des restrictions plus précises dans les applications disponibles dans ces environnements.
Si les implémentations d'appareils de télévision incluent plusieurs utilisateurs et déclarent l'indicateur de fonctionnalité android.hardware.telephony
, elles:
- [9.5/T-3-1] NE DOIT PAS prendre en charge les profils restreints, mais DOIT s'aligner sur l'implémentation des commandes AOSP pour autoriser /désactiver l'accès des autres utilisateurs aux appels vocaux et aux SMS.
Si les implémentations d'appareils de télévision déclarent android.hardware.microphone
, elles:
- [9.8.2/T-4-1] DOIT afficher l'indicateur du micro lorsqu'une application accède aux données audio du micro, mais pas lorsque le micro n'est accessible que par HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService ou les applications disposant des rôles mentionnés dans la section 9.1 sur les autorisations avec l'identifiant CDD C-3-X.
- [9.8.2/T-4-2] L'indicateur du micro ne doit PAS être masqué pour les applications système qui disposent d'interfaces utilisateur visibles ou d'interactions directes avec l'utilisateur.
Si les implémentations d'appareils de télévision déclarent android.hardware.camera.any
, elles:
- [9.8.2/T-5-1] DOIT afficher l'indicateur de caméra lorsqu'une application accède aux données de la caméra en direct, mais pas lorsque la caméra n'est accessible que par une ou plusieurs applications disposant des rôles indiqués dans la section 9.1 Autorisations avec l'identifiant CDD [C-3-X].
- [9.8.2/T-5-2] L'indicateur de la caméra ne doit PAS être masqué pour les applications système qui disposent d'interfaces utilisateur visibles ou d'interactions directes avec l'utilisateur.
2.3.6. Compatibilité des outils et options pour les développeurs
Début des nouvelles exigences pour Android 15
Implémentations d'appareils TV:
- Perfetto
- [6.1/T-0-1] DOIT exposer un binaire
/system/bin/perfetto
à l'utilisateur du shell dont la ligne de commande est conforme à la documentation de perfetto. - [6.1/T-0-2] Le binaire perfetto DOIT accepter en entrée une configuration protobuf conforme au schéma défini dans la documentation de perfetto.
- [6.1/T-0-3] Le binaire perfetto DOIT écrire en sortie une trace protobuf conforme au schéma défini dans la documentation de perfetto.
- [6.1/T-0-4] DOIT fournir, via le binaire perfetto, au moins les sources de données décrites dans la documentation de perfetto.
- [6.1/T-0-5] Le daemon de traçage perfetto DOIT être activé par défaut (propriété système
persist.traced.enable
).
- [6.1/T-0-1] DOIT exposer un binaire
Fin des nouvelles exigences
2.4. Configuration requise pour la montre
Un appareil Android Watch désigne une implémentation d'appareil Android destinée à être portée sur le corps, peut-être au poignet.
Les implémentations d'appareils Android sont classées comme montres si elles remplissent tous les critères suivants:
- Avoir un écran dont la diagonale physique est comprise entre 1,1 et 2,5 pouces.
- être doté d'un mécanisme permettant de le porter sur le corps ;
Les exigences supplémentaires du reste de cette section sont spécifiques aux implémentations d'appareils Android Watch.
2.4.1. Matériel
Implémentations des appareils de visionnage:
[7.1.1.1/W-0-1] L'écran doit avoir une diagonale physique comprise entre 1,1 et 2,5 pouces.
[7.2.3/W-0-1] La fonction "Accueil" doit être disponible pour l'utilisateur, ainsi que la fonction "Retour", sauf lorsqu'il se trouve dans
UI_MODE_TYPE_WATCH
.[7.2.4/W-0-1] DOIT prendre en charge la saisie par écran tactile.
[7.3.1/W-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un accéléromètre à trois axes.
Si les implémentations d'appareils de montre incluent un récepteur GPS/GNSS et signalent la fonctionnalité aux applications via l'indicateur de fonctionnalité android.hardware.location.gps
, elles:
- [7.3.3/W-1-1] DOIT signaler les mesures GNSS dès qu'elles sont détectées, même si une position calculée à partir du GPS/GNSS n'est pas encore signalée.
- [7.3.3/W-1-2] DOIT indiquer les pseudo-distances et les taux de pseudo-distance GNSS, qui, dans des conditions d'ensoleillement après avoir déterminé la position, à l'arrêt ou en mouvement avec une accélération inférieure à 0,2 mètre par seconde au carré, sont suffisants pour calculer la position à 20 mètres près et la vitesse à 0,2 mètre par seconde près, au moins 95% du temps.
Si les implémentations d'appareils Watch incluent un gyroscope à trois axes, elles:
- [7.3.4/W-2-1] DOIT être capable de mesurer les changements d'orientation jusqu'à 1 000 degrés par seconde.
Implémentations des appareils de visionnage:
[7.4.3/W-0-1] DOIT prendre en charge la technologie Bluetooth.
[7.6.1/W-0-1] Au moins 1 Go de stockage non volatile doit être disponible pour les données privées de l'application (également appelée partition "/data").
[7.6.1/W-0-2] Le noyau et l'espace utilisateur doivent disposer d'au moins 416 Mo de mémoire.
[7.8.1/W-0-1] DOIT inclure un micro.
[7.8.2/W] Peut avoir une sortie audio.
2.4.2. Multimédia
Aucune autre condition requise.
2.4.3. Logiciel
Implémentations des appareils de visionnage:
- [3/W-0-1] VOUS DEVEZ déclarer la fonctionnalité
android.hardware.type.watch
. - [3/W-0-2] DOIT prendre en charge uiMode = UI_MODE_TYPE_WATCH.
- [3.2.3.1/W-0-1] DOIT précharger une ou plusieurs applications ou composants de service avec un gestionnaire d'intent, pour tous les modèles de filtre d'intent publics définis par les intents d'application suivants listés ici.
Implémentations des appareils de visionnage:
- [3.8.4/W-SR-1] Il est FORTEMENT RECOMMANDÉ d'implémenter un assistant sur l'appareil pour gérer l'action d'assistance.
Observez les implémentations d'appareils qui déclarent l'option de fonctionnalité android.hardware.audio.output
:
- [3.10/W-1-1] DOIT prendre en charge les services d'accessibilité tiers.
- [3.10/W-SR-1] Il est FORTEMENT RECOMMANDÉ de précharger sur l'appareil des services d'accessibilité comparables ou supérieurs aux fonctionnalités des services d'accessibilité Switch Access et TalkBack (pour les langues prises en charge par le moteur de synthèse vocale préinstallé), comme indiqué dans le projet Open Source talkback.
Si les implémentations d'appareils de montre signalent la fonctionnalité android.hardware.audio.output:
[3.11/W-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un moteur TTS compatible avec les langues disponibles sur l'appareil.
[3.11/W-0-1] DOIT prendre en charge l'installation de moteurs TTS tiers.
2.4.4. Performances et puissance
Si les implémentations d'appareils de montre incluent des fonctionnalités pour améliorer la gestion de l'alimentation de l'appareil qui sont incluses dans AOSP ou qui étendent les fonctionnalités incluses dans AOSP, elles:
- [8.3/W-SR-1] Il est FORTEMENT RECOMMANDÉ de fournir une affordance utilisateur pour afficher toutes les applications qui sont exemptées des modes d'économie d'énergie App Standby et Doze.
- [8.3/W-SR-2] Il est FORTEMENT RECOMMANDÉ de fournir une affordance utilisateur pour activer et désactiver la fonctionnalité Économiseur de batterie.
Implémentations des appareils de visionnage:
- [8.4/W-0-1] DOIT fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle pour chaque composant matériel et l'épuisement approximatif de la batterie causé par les composants au fil du temps, comme indiqué sur le site du projet Android Open Source.
- [8.4/W-0-2] DOIT indiquer toutes les valeurs de consommation d'énergie en milliampères-heure (mAh).
- [8.4/W-0-3] DOIT indiquer la consommation d'énergie du processeur par UID de chaque processus. Le projet Android Open Source répond à cette exigence via l'implémentation du module de noyau
uid_cputime
. - [8.4/W-0-4] Le développeur de l'application DOIT pouvoir accéder à cette consommation d'énergie via la commande shell
adb shell dumpsys batterystats
. - [8,4 W] DOIT être attribué au composant matériel lui-même si vous ne parvenez pas à attribuer la consommation d'énergie du composant matériel à une application.
2.4.5. Modèle de sécurité
Implémentations des appareils de visionnage:
- [9/W-0-1] Vous devez déclarer la fonctionnalité
android.hardware.security.model.compatible
.
Si les implémentations d'appareils Watch incluent plusieurs utilisateurs et ne déclarent pas l'indicateur de fonctionnalité android.hardware.telephony
, elles:
- [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 fonctionnalités sur l'appareil. Avec les profils restreints, les propriétaires d'appareils peuvent rapidement configurer des environnements distincts pour que d'autres utilisateurs puissent y travailler, et gérer des restrictions plus précises dans les applications disponibles dans ces environnements.
Si les implémentations d'appareils Watch incluent plusieurs utilisateurs et déclarent l'indicateur de fonctionnalité android.hardware.telephony
, elles:
- [9.5/W-2-1] NE DOIT PAS prendre en charge les profils restreints, mais DOIT s'aligner sur l'implémentation des commandes AOSP pour autoriser /désactiver l'accès des autres utilisateurs aux appels vocaux et aux SMS.
Si les implémentations d'appareils disposent d'un écran de verrouillage sécurisé et incluent un ou plusieurs agents de confiance, qui implémentent l'API système TrustAgentService
, elles:
- [9.11.1/W-1-1] L'appareil DOIT demander à l'utilisateur de fournir l'une des méthodes d'authentification primaires recommandées (par exemple, un code, un schéma ou un mot de passe) plus fréquemment qu'une fois toutes les 72 heures.
2.5. Exigences pour le secteur automobile
L'implémentation d'Android Automotive désigne une unité principale de véhicule exécutant Android comme système d'exploitation pour une partie ou la totalité du système et/ou des fonctionnalités d'infodivertissement.
Les implémentations d'appareils Android sont classées comme Automotive si elles déclarent la fonctionnalité android.hardware.type.automotive
ou si elles répondent à tous les critères suivants.
- Ils sont intégrés à un véhicule automobile ou peuvent y être branchés.
- Utilise un écran sur la rangée du siège conducteur comme écran principal.
Les exigences supplémentaires du reste de cette section sont spécifiques aux implémentations d'appareils Android Automotive.
2.5.1. Matériel
Implémentations d'appareils automobiles:
- [7.1.1.1/A-0-1] L'écran doit mesurer au moins 6 pouces de diagonale physique.
- [7.1.1.1/A-0-2] La mise en page de la taille de l'écran doit être d'au moins 750 dp x 480 dp.
Début des nouvelles exigences pour Android 15
Si les implémentations d'appareils Automotive sont compatibles avec le mode multi-utilisateur simultané (dans lequel plusieurs utilisateurs Android peuvent interagir avec l'appareil simultanément, chacun utilisant son propre écran lorsque config_multiuserVisibleBackgroundUsers
est activé), elles:
- [7.1.1.1/A-1-1] L'écran principal DOIT comporter un écran distinct d'au moins 6 pouces de diagonale physique pour chaque zone d'occupant. Cette valeur doit être taguée comme
CarOccupantZoneManager.DISPLAY_TYPE_MAIN
pour chaque zone d'occupant. - [7.1.1.1/A-1-2] La mise en page de la taille de l'écran doit être d'au moins 750 dp x 480 dp pour chaque écran principal.
Fin des nouvelles exigences
Si les implémentations d'appareils Automotive 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.
Implémentations d'appareils automobiles:
Début des nouvelles exigences pour Android 15
- [7.1.7/A-0-1] Les écrans secondaires situés dans le champ de vision du conducteur doivent être configurés en tant que
FLAG_PRIVATE
.
Fin des nouvelles exigences
[7.2.3/A-0-1] DOIT fournir la fonction "Accueil" et PEUT fournir les fonctions "Retour" et "Récents".
[7.2.3/A-0-2] DOIT envoyer à l'application de premier plan l'événement de pression normale et de pression prolongée de la fonction Retour (
KEYCODE_BACK
).[7.3/A-0-1] DOIT implémenter et signaler
GEAR_SELECTION
,NIGHT_MODE
,PERF_VEHICLE_SPEED
etPARKING_BRAKE_ON
.[7.3/A-0-2] La valeur de l'indicateur
NIGHT_MODE
DOIT être cohérente avec le mode jour/nuit du tableau de bord et DOIT être basée sur l'entrée du capteur de lumière ambiante. Le capteur de luminosité ambiante sous-jacent PEUT être le même que le photomètre.[7.3/A-0-3] DOIT fournir le champ d'informations supplémentaires sur le capteur
TYPE_SENSOR_PLACEMENT
dans SensorAdditionalInfo pour chaque capteur fourni.[7.3/A-SR1] PEUT calculer la position par triangulation en fusionnant le GPS/GNSS avec des capteurs supplémentaires. Si la position est déterminée par calcul, il est FORTEMENT RECOMMANDÉ d'implémenter et de signaler les types de capteurs et/ou les ID de propriété du véhicule correspondants.
[7.3/A-0-4] La position demandée via LocationManager#requestLocationUpdates() NE DOIT PAS être mise en correspondance avec la carte.
[7.3.1/A-0-4] DOIT respecter le système de coordonnées des capteurs de voiture Android.
[7.3/A-SR-1] Il est FORTEMENT_RECOMMANDÉ d'inclure un accéléromètre à trois axes et un gyroscope à trois axes.
[7.3/A-SR-2] Il est FORTEMENT_RECOMMANDÉ d'implémenter et de signaler le capteur
TYPE_HEADING
.
Début des nouvelles exigences pour Android 15
Si les implémentations d'appareils Automotive sont compatibles avec le mode multi-utilisateur simultané (dans lequel plusieurs utilisateurs Android peuvent interagir avec l'appareil simultanément, chacun utilisant son propre écran lorsque config_multiuserVisibleBackgroundUsers
est activé), elles:
- [7.3/A-1-1] La valeur de l'indicateur
NIGHT_MODE
DOIT être cohérente avec le mode jour/nuit du tableau de bord sur tous les écrans, y compris ceux des sièges arrière.
Fin des nouvelles exigences
Si les implémentations d'appareils Automotive incluent un accéléromètre, elles:
- [7.3.1/A-1-1] DOIT pouvoir signaler des événements jusqu'à une fréquence d'au moins 100 Hz.
Si les implémentations d'appareils incluent un accéléromètre à trois axes, elles:
- [7.3.1/A-SR-1] Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur composite pour l'accéléromètre à axes limités.
Si les implémentations d'appareils Automotive incluent un accéléromètre à moins de trois axes, elles:
- [7.3.1/A-1-3] DOIT implémenter et signaler le capteur
TYPE_ACCELEROMETER_LIMITED_AXES
. - [7.3.1/A-1-4] DOIT implémenter et signaler le capteur
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
.
Si les implémentations d'appareils Automotive incluent un gyroscope, elles:
- [7.3.4/A-2-1] DOIT pouvoir signaler des événements jusqu'à une fréquence d'au moins 100 Hz.
- [7.3.4/A-2-3] DOIT être capable de mesurer les changements d'orientation jusqu'à 250 degrés par seconde.
- [7.3.4/A-SR-1] Il est FORTEMENT RECOMMANDÉ de configurer la plage de mesure du gyroscope sur +/- 250 dps afin de maximiser la résolution possible.
Si les implémentations d'appareils Automotive incluent un gyroscope à trois axes, elles:
- [7.3.4/A-SR-2] Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur composite pour le gyroscope à axes limités.
Si les implémentations d'appareils Automotive incluent un gyroscope à moins de trois axes, elles:
- [7.3.4/A-4-1] DOIT implémenter et signaler le capteur
TYPE_GYROSCOPE_LIMITED_AXES
. - [7.3.4/A-4-2] DOIT implémenter et signaler le capteur
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
.
Si les implémentations d'appareils Automotive incluent un récepteur GPS/GNSS, mais pas de connectivité de données basée sur un réseau mobile, elles:
- [7.3.3/A-3-1] Le récepteur GPS/GNSS doit déterminer la position la toute première fois qu'il est allumé ou après quatre jours ou plus, dans un délai de 60 secondes.
- [7.3.3/A-3-2] DOIT respecter les critères de temps de première correction décrits dans 7.3.3/C-1-2 et 7.3.3/C-1-6 pour toutes les autres requêtes de localisation (c'est-à-dire les requêtes qui ne sont pas la première fois ou après plus de quatre jours). L'exigence 7.3.3/C-1-2 est généralement remplie dans les véhicules sans connectivité de données basée sur un réseau mobile, en utilisant les prédictions d'orbite GNSS calculées sur le récepteur, ou en utilisant la dernière position connue du véhicule avec la possibilité de calculer une position estimée pendant au moins 60 secondes avec une précision de position satisfaisant aux exigences de la section 7.3.3/C-1-3, ou une combinaison des deux.
Si les implémentations d'appareils automobiles incluent un capteur TYPE_HEADING
, elles:
- [7.3.4/A-4-3] DOIT pouvoir générer des rapports sur les événements à une fréquence d'au moins 1 Hz.
- [7.3.4/A-SR-3] Il est FORTEMENT_RECOMMANDÉ de signaler les événements jusqu'à une fréquence d'au moins 10 Hz.
- DOIT être en référence au nord géographique.
- DOIT être disponible même lorsque le véhicule est à l'arrêt.
- Doit avoir une résolution d'au moins 1 degré.
Implémentations d'appareils automobiles:
- [7.4.3/A-0-1] DOIT prendre en charge le Bluetooth et DOIT prendre en charge le Bluetooth LE.
- [7.4.3/A-0-2] Les implémentations Android Auto doivent prendre en charge les profils Bluetooth suivants :
- Appels téléphoniques via le profil mains libres (HFP)
- Lecture de contenus multimédias via le profil de distribution audio (A2DP)
- Contrôle de la lecture de contenus multimédias via le profil de télécommande (AVRCP).
- Partage de contacts à l'aide du profil d'accès au carnet d'adresses (PBAP)
Début des nouvelles exigences pour Android 15
- [7.4.3/A-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge le profil d'accès aux messages (MAP) si l'appareil dispose de la zone d'occupant conducteur.
Fin des nouvelles exigences
Début des nouvelles exigences pour Android 15
Si les implémentations d'appareils Automotive sont compatibles avec le mode multi-utilisateur simultané (dans lequel plusieurs utilisateurs Android peuvent interagir avec l'appareil simultanément, chacun utilisant son propre écran lorsque config_multiuserVisibleBackgroundUsers
est activé), elles:
- [7.4.3/A-1-1] DOIT être indépendant et NE PAS interférer avec l'expérience BT des autres utilisateurs.
Fin des nouvelles exigences
Implémentations d'appareils automobiles:
- [7.4.5/A] DOIT inclure la prise en charge de la connectivité de données basée sur le réseau mobile.
- [7.4.5/A] PEUT utiliser la constante
NetworkCapabilities#NET_CAPABILITY_OEM_PAID
de l'API système pour les réseaux qui doivent être disponibles pour les applications système.
Si les implémentations d'appareils incluent la prise en charge de la radio AM/FM et exposent la fonctionnalité à n'importe quelle application, elles:
- [7.4/A-1-1] doit déclarer la prise en charge de
FEATURE_BROADCAST_RADIO
.
Une caméra arrière désigne une caméra orientée vers l'extérieur du véhicule, qui peut être située n'importe où sur le véhicule et qui est orientée vers l'extérieur de la cabine du véhicule. Autrement dit, elle capture des scènes à l'arrière du corps du véhicule, comme la caméra de recul.
Une caméra avant désigne une caméra orientée vers l'utilisateur, qui peut être située n'importe où sur le véhicule et qui est orientée vers l'intérieur de la cabine du véhicule. Autrement dit, elle filme l'utilisateur, par exemple pour les visioconférences et les applications similaires.
Implémentations d'appareils automobiles:
- [7.5/A-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure une ou plusieurs caméras orientées vers l'extérieur.
- POURRA inclure une ou plusieurs caméras orientées vers l'utilisateur.
- [7.5/A-SR-2] FORTEMENT RECOMMANDÉ pour la diffusion simultanée de plusieurs caméras.
Si les implémentations d'appareils Automotive incluent au moins une caméra orientée vers l'extérieur, les éléments suivants s'appliquent à cette caméra:
- [7.5/A-1-1] DOIT être orienté de sorte à faire correspondre la dimension longue de l'appareil photo au plan X-Y des axes des capteurs Android Automotive.
- [7.5/A-SR-3] Il est FORTEMENT RECOMMANDÉ de disposer d'un matériel à mise au point fixe ou à champ d'image étendu (EDOF).
- [7.5/A-1-2] La caméra principale orientée vers l'extérieur doit être la caméra orientée vers l'extérieur avec l'ID de caméra le plus bas.
Si les implémentations d'appareils Automotive incluent au moins une caméra orientée vers l'utilisateur, pour une telle caméra:
- [7.5/A-2-1] La caméra avant principale DOIT être la caméra avant ayant l'ID de caméra le plus bas.
- PEUT être orienté de sorte à faire correspondre la dimension longue de l'appareil photo au plan X-Y des axes des capteurs automobiles Android.
Si les implémentations d'appareils Automotive incluent une caméra accessible via l'API android.hardware.Camera
ou android.hardware.camera2
, elles:
- [7.5/A-3-1] L'appareil photo DOIT respecter les exigences de base de la section 7.5.
Si les implémentations d'appareils Automotive incluent une caméra qui n'est pas accessible via l'API android.hardware.Camera
ou android.hardware.camera2
, elles:
- [7.5/A-4-1] DOIT être accessible via le service Extended View System.
Si les implémentations d'appareils Automotive incluent une ou plusieurs caméras accessibles via le service système de vue étendue, pour une telle caméra, elles:
- [7.5/A-5-1] L'aperçu de l'appareil photo NE DOIT PAS être pivoté ni mis en miroir horizontalement.
- [7.5/A-SR-4] Il est vivement recommandé que la résolution soit d'au moins 1,3 mégapixel.
Si les implémentations d'appareils automobiles incluent une ou plusieurs caméras accessibles à la fois via le service Extended View System Service et l'API android.hardware.Camera
ou android.hardware.Camera2
, alors, pour une telle caméra:
- [7.5/A-6-1] DOIT indiquer le même ID de caméra.
Si les implémentations d'appareils Automotive fournissent une API d'appareil photo propriétaire, elles:
- [7.5/A-7-1] Une telle API de caméra DOIT être implémentée à l'aide de l'API
android.hardware.camera2
ou de l'API Extended View System.
Implémentations d'appareils automobiles:
[7.6.1/A-0-1] DOIT disposer d'au moins 4 Go de stockage non volatile disponible pour les données privées de l'application (partition
/data
).[7.6.1/A] LE FORMATAGE DE LA PARTITION DE DONNÉES DOIT être effectué pour améliorer les performances et la longévité du stockage flash (par exemple, à l'aide du système de fichiers
f2fs
).
Si les implémentations d'appareils Automotive fournissent un stockage externe partagé via une partie de l'espace de stockage interne non amovible, elles:
- [7.6.1/A-SR-1] FORTEMENT RECOMMANDÉ pour réduire les coûts d'E/S sur les opérations effectuées sur le stockage externe, par exemple en utilisant
SDCardFS
.
Début des nouvelles exigences pour Android 15
Si les implémentations d'appareils Automotive sont compatibles avec le mode multi-utilisateur simultané (dans lequel plusieurs utilisateurs Android peuvent interagir avec l'appareil simultanément, chacun utilisant son propre écran lorsque config_multiuserVisibleBackgroundUsers
est activé), elles:
- [7.6.1/A-1-1] Chaque instance AAOS doit disposer d'au moins 4 Go de stockage non volatile disponible pour les données privées de l'application (partition
/data
) pour chaque utilisateur Android simultané.
Fin des nouvelles exigences
Si les implémentations d'appareils Automotive sont 64 bits:
Début des nouvelles exigences pour Android 15
[7.6.1/A-2-1] La mémoire disponible pour le kernel et l'espace utilisateur DOIT être d'au moins 816 Mo par écran principal si l'une des densités suivantes est utilisée:
- 280 dpi ou moins sur les écrans de petite/moyenne taille
- ldpi ou moins sur les écrans très grands formats
- mdpi ou moins sur les grands écrans
[7.6.1/A-2-2] La mémoire disponible pour le kernel et l'espace utilisateur DOIT être d'au moins 944 Mo par écran principal si l'une des densités suivantes est utilisée:
- xhdpi ou version ultérieure sur les écrans de petite/moyenne taille
- hdpi ou version ultérieure sur les grands écrans
- mdpi ou plus sur les écrans très grands
[7.6.1/A-2-3] La mémoire disponible pour le kernel et l'espace utilisateur DOIT être d'au moins 1 280 Mo par écran principal si l'une des densités suivantes est utilisée:
- 400 dpi ou plus sur les écrans de petite/moyenne taille
- xhdpi ou version ultérieure sur les grands écrans
- tvdpi ou version ultérieure sur les écrans très grands
[7.6.1/A-2-4] La mémoire disponible pour le kernel et l'espace utilisateur DOIT être d'au moins 1 824 Mo par écran principal si l'une des densités suivantes est utilisée:
- 560 dpi ou plus sur les écrans de petite/moyenne taille
- 400 dpi ou plus sur les grands écrans
- xhdpi ou version ultérieure sur les écrans très grands
Notez que la "mémoire disponible pour le kernel et l'espace utilisateur" ci-dessus fait référence à l'espace mémoire fourni en plus de toute mémoire déjà dédiée aux composants matériels tels que la radio, la vidéo, etc. qui ne sont pas sous le contrôle du kernel sur les implémentations d'appareils.
Fin des nouvelles exigences
Implémentations d'appareils automobiles:
- [7.7.1/A] Un port USB compatible avec le mode périphérique DOIT être inclus.
Implémentations d'appareils automobiles:
- [7.8.1/A-0-1] DOIT inclure un micro.
Implémentations d'appareils automobiles:
- [7.8.2/A-0-1] DOIT disposer d'une sortie audio et déclarer
android.hardware.audio.output
.
Début des nouvelles exigences pour Android 15
Si les implémentations d'appareils Automotive sont compatibles avec le mode multi-utilisateur simultané (dans lequel plusieurs utilisateurs Android peuvent interagir avec l'appareil simultanément, chacun utilisant son propre écran lorsque config_multiuserVisibleBackgroundUsers
est activé), elles:
- [7.8.2/A-1-1] Un dispositif de sortie audio doit être présent pour chaque écran principal pour les systèmes multi-utilisateurs simultanés.
- [7.8.2/A-1-2] La zone audio du conducteur doit couvrir le haut-parleur global de la cabine. La zone du passager avant peut partager la zone audio du conducteur ou avoir sa propre sortie audio.
Fin des nouvelles exigences
2.5.2. Multimédia
Les implémentations d'appareils automobiles DOIVENT prendre en charge les formats d'encodage et de décodage audio suivants, et les mettre à la disposition des applications tierces:
- [5.1/A-0-1] Profil MPEG-4 AAC (AAC LC)
- [5.1/A-0-2] Profil MPEG-4 HE AAC (AAC+)
- [5.1/A-0-3] AAC ELD (AAC à faible latence améliorée)
Les implémentations d'appareils automobiles DOIVENT prendre en charge les formats d'encodage vidéo suivants et les mettre à la disposition des applications tierces:
Les implémentations d'appareils automobiles DOIVENT prendre en charge les formats de décodage vidéo suivants et les mettre à la disposition des applications tierces:
Il est vivement recommandé que les implémentations d'appareils automobiles soient compatibles avec le décodage vidéo suivant:
- [5.3/A-SR-1] H.265 HEVC
Début des nouvelles exigences pour Android 15
Si les implémentations d'appareils Automotive sont compatibles avec le mode multi-utilisateur simultané (dans lequel plusieurs utilisateurs Android peuvent interagir avec l'appareil simultanément, chacun utilisant son propre écran lorsque config_multiuserVisibleBackgroundUsers
est activé), elles:
- [5.5.3/A-1-1] DOIT définir des courbes de volume identiques pour tous les flux de sortie audio mappant sur le même groupe de volume que celui défini dans le fichier de configuration audio de la voiture.
Fin des nouvelles exigences
2.5.3. Logiciel
Implémentations d'appareils automobiles:
[3/A-0-1] La fonctionnalité
android.hardware.type.automotive
DOIT être déclarée.[3/A-0-2] DOIT prendre en charge uiMode =
UI_MODE_TYPE_CAR
.[3/A-0-3] DOIT prendre en charge toutes les API publiques de l'espace de noms
android.car.*
.
Si les implémentations d'appareils Automotive fournissent une API propriétaire à l'aide de android.car.CarPropertyManager
avec android.car.VehiclePropertyIds
, elles:
- [3/A-1-1] NE DOIT PAS associer des droits spéciaux à l'utilisation de ces propriétés par l'application système, ni empêcher les applications tierces d'utiliser ces propriétés.
- [3/A-1-2] NE DOIT PAS dupliquer une propriété de véhicule qui existe déjà dans le SDK.
Implémentations d'appareils automobiles:
[3.2.1/A-0-1] DOIT prendre en charge et appliquer toutes les constantes d'autorisation, comme indiqué sur la page de référence sur les autorisations automobiles.
[3.2.3.1/A-0-1] DOIT précharger une ou plusieurs applications ou composants de service avec un gestionnaire d'intent, pour tous les modèles de filtre d'intent publics définis par les intents d'application suivants listés ici.
[3.4.1/A-0-1] DOIT fournir une implémentation complète de l'API
android.webkit.Webview
.
Début des nouvelles exigences pour Android 15
- [3.8/A-0-1] Les utilisateurs secondaires complets qui ne sont pas l'utilisateur de premier plan actuel NE DOIVENT PAS être autorisés à lancer des activités et à accéder à l'UI sur n'importe quel écran.
Si les implémentations d'appareils Automotive sont compatibles avec le mode multi-utilisateur simultané (dans lequel plusieurs utilisateurs Android peuvent interagir avec l'appareil simultanément, chacun utilisant son propre écran lorsque config_multiuserVisibleBackgroundUsers
est activé), elles:
[3.8/A-1-1] DOIT implémenter la liste prédéfinie suivante de
UserRestrictions
pour les utilisateurs secondaires complets qui ne sont pas l'utilisateur de premier plan actuel, mais qui ont un accès à l'UI de l'écran qui leur est attribué. La liste desUserRestrictions
est la suivante :DISALLOW_CONFIG_LOCALE
,DISALLOW_CONFIG_BLUETOOTH
,DISALLOW_BLUETOOTH
,DISALLOW_CAMERA_TOGGLE
etDISALLOW_MICROPHONE_TOGGLE
.[3.8/A-1-2] Les utilisateurs secondaires complets qui ne sont pas l'utilisateur de premier plan actuel, mais qui ont accès à l'UI de l'écran qui leur est attribué, NE DOIVENT PAS être autorisés à modifier le mode jour/nuit, les paramètres régionaux, la date, l'heure, le fuseau horaire ou les fonctionnalités de couleur de l'écran (y compris la luminosité, la lumière de nuit, le mode gris du Bien-être numérique et la réduction des couleurs vives) pour tout autre utilisateur via les paramètres ou à partir d'une API.
Fin des nouvelles exigences
Implémentations d'appareils automobiles:
[3.8.3/A-0-1] DOIT afficher les notifications qui utilisent l'API
Notification.CarExtender
lorsqu'elles sont demandées par des applications tierces.[3.8.4/A-SR-1] Il est fortement recommandé d'implémenter un assistant sur l'appareil pour gérer l'action d'assistance.
Si les implémentations d'appareils Automotive incluent un bouton PTT:
- [3.8.4/A-1-1] DOIT utiliser un appui bref sur le bouton PTT comme interaction désignée pour lancer l'application d'assistance sélectionnée par l'utilisateur, c'est-à-dire l'application qui implémente
VoiceInteractionService
.
Implémentations d'appareils automobiles:
- [3.8.3.1/A-0-1] DOIT afficher correctement les ressources, comme décrit dans la documentation du SDK
Notifications on Automotive OS
. - [3.8.3.1/A-0-2] DOIT afficher "PLAY" (LECTURE) et "MUTE" (COUPE-SON) pour les actions de notification à la place de celles fournies via
Notification.Builder.addAction()
. - [3.8.3.1/A] DOIT limiter l'utilisation de tâches de gestion avancées telles que les commandes par canal de notification. PEUT utiliser l'affordance de l'interface utilisateur par application pour réduire les commandes.
Si les implémentations d'appareils Automotive sont compatibles avec les propriétés HAL utilisateur, elles:
- [3.9.3/A-1-1] DOIT implémenter toutes les propriétés de cycle de vie de l'utilisateur
INITIAL_USER_INFO
,SWITCH_USER
,CREATE_USER
,REMOVE_USER
.
Implémentations d'appareils automobiles:
- [3.14/A-0-1] DOIT inclure un framework d'UI pour prendre en charge les applications tierces qui utilisent les API multimédias, comme décrit dans la section 3.14.
- [3.14/A-0-2] L'application DOIT permettre à l'utilisateur d'interagir de manière sécurisée avec les applications multimédias lorsqu'il conduit.
- [3.14/A-0-3] DOIT prendre en charge l'action d'intent implicite
CAR_INTENT_ACTION_MEDIA_TEMPLATE
avec l'extraCAR_EXTRA_MEDIA_PACKAGE
. - [3.14/A-0-4] DOIT fournir une affordance permettant d'accéder à l'activité de préférences d'une application multimédia, mais DOIT uniquement l'activer lorsque les restrictions liées à l'expérience utilisateur du véhicule ne sont pas en vigueur.
- [3.14/A-0-5] DOIT afficher les messages d'erreur définis par les applications multimédias et DOIT prendre en charge les éléments facultatifs
ERROR_RESOLUTION_ACTION_LABEL
etERROR_RESOLUTION_ACTION_INTENT
. - [3.14/A-0-6] DOIT prendre en charge une affordance de recherche dans l'application pour les applications compatibles avec la recherche.
- [3.14/A-0-7] DOIT respecter les définitions de
CONTENT_STYLE_BROWSABLE_HINT
et deCONTENT_STYLE_PLAYABLE_HINT
lors de l'affichage de la hiérarchie MediaBrowser.
Si les implémentations d'appareils Automotive incluent une application de lanceur par défaut, elles:
- [3.14/A-1-1] DOIT inclure des services multimédias et les ouvrir avec l'intent
CAR_INTENT_ACTION_MEDIA_TEMPLATE
.
Implémentations d'appareils automobiles:
- [3.8/A] PEUT limiter les requêtes d'application pour passer en mode plein écran, comme décrit dans
immersive documentation
. - [3.8/A] La barre d'état et la barre de navigation peuvent rester visibles en permanence.
- [3.8/A] PEUT limiter les requêtes de l'application pour modifier les couleurs derrière les éléments d'interface utilisateur du système, afin de s'assurer que ces éléments sont clairement visibles à tout moment.
2.5.4. Performances et puissance
Implémentations d'appareils automobiles:
- [8.2/A-0-1] DOIT indiquer le nombre d'octets lus et écrits dans l'espace de stockage non volatile par UID de chaque processus afin que les statistiques soient disponibles pour les développeurs via l'API système
android.car.storagemonitoring.CarStorageMonitoringManager
. Le projet Open Source Android répond à cette exigence via le module de noyauuid_sys_stats
. - [8.3/A-1-3] DOIT être compatible avec le mode Garage.
- [8.3/A] Le véhicule DOIT être en mode Garage pendant au moins 15 minutes après chaque trajet, sauf si :
- La batterie est déchargée.
- Aucune tâche inactive n'est planifiée.
- 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 pour chaque composant matériel et l'épuisement approximatif de la batterie causé par les composants au fil du temps, comme indiqué sur le site du projet Open Source Android.
- [8.4/A-0-2] DOIT indiquer toutes les valeurs de consommation d'énergie en milliampères-heure (mAh).
- [8.4/A-0-3] DOIT indiquer la consommation d'énergie du processeur par UID de chaque processus. Le projet Android Open Source répond à cette exigence via l'implémentation du module de noyau
uid_cputime
. - [8.4/A] DOIT être attribué au composant matériel lui-même si vous ne parvenez pas à attribuer la consommation d'énergie du composant matériel à une application.
- [8.4/A-0-4] Le développeur de l'application DOIT pouvoir accéder à cette consommation d'énergie via la commande shell
adb shell dumpsys batterystats
.
2.5.5. Modèle de sécurité
Si les implémentations d'appareils Automotive sont compatibles avec plusieurs utilisateurs, elles:
- [9.5/A-1-1] Le système NE DOIT PAS permettre aux utilisateurs d'interagir avec l'utilisateur du système sans tête ni de passer à cet utilisateur, sauf pour le provisionnement de l'appareil.
- [9.5/A-1-2] L'utilisateur DOIT passer à un utilisateur secondaire avant
BOOT_COMPLETED
. - [9.5/A-1-3] L'application DOIT permettre de créer un utilisateur invité, même lorsque le nombre maximal d'utilisateurs sur un appareil a été atteint.
Si les implémentations d'appareils Automotive déclarent android.hardware.microphone
:
- [9.8.2/A-1-1] DOIT afficher l'indicateur du micro lorsqu'une application accède aux données audio du micro, mais pas lorsque le micro n'est accessible que par
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
ou les applications disposant des rôles mentionnés dans la section 9.1 avec l'identifiant CDD [C-4-X]. - [9.8.2/A-1-2] L'indicateur du micro ne doit PAS être masqué pour les applications système qui disposent d'une interface utilisateur visible ou d'une interaction directe avec l'utilisateur.
- [9.8.2/A-1-3] L'application doit fournir une affordance permettant à l'utilisateur d'activer ou de désactiver le micro dans l'application Paramètres.
Si les implémentations d'appareils Automotive déclarent android.hardware.camera.any
, elles:
- [9.8.2/A-2-1] DOIT afficher l'indicateur de l'appareil photo lorsqu'une application accède aux données de l'appareil photo en direct, mais pas lorsque l'appareil photo n'est accessible que par une ou plusieurs applications disposant des rôles définis dans la section 9.1 Autorisations avec l'identifiant CDD [C-4-X].
- [9.8.2/A-2-2] L'indicateur de l'appareil photo ne doit PAS être masqué pour les applications système qui disposent d'une interface utilisateur visible ou d'une interaction directe avec l'utilisateur.
- [9.8.2/A-2-3] L'application doit fournir une affordance permettant à l'utilisateur d'activer/de désactiver l'appareil photo dans l'application Paramètres.
- [9.8.2/A-2-4] DOIT afficher les applications récentes et actives à l'aide de la caméra, telles que renvoyées par
PermissionManager.getIndicatorAppOpUsageData()
, ainsi que les messages d'attribution qui leur sont associés.
Implémentations d'appareils automobiles:
- [9/A-0-1] Vous devez déclarer la fonctionnalité
android.hardware.security.model.compatible
. - [9.11/A-0-1] L'implémentation du keystore DOIT être sauvegardée avec un environnement d'exécution isolé.
- [9.11/A-0-2] DOIT implémenter les algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que les fonctions de hachage de la famille MD5, SHA-1 et SHA-2 pour prendre en charge correctement les algorithmes compatibles du système Android Keystore dans une zone isolée de manière sécurisée du code exécuté sur le noyau et au-dessus. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lesquels le code du noyau ou de l'espace utilisateur peut accéder à l'état interne de l'environnement isolé, y compris le DMA. Le projet Android Open Source Project (AOSP) en amont répond à cette exigence en utilisant l'implémentation Trusty, mais une autre solution basée sur ARM TrustZone ou une implémentation sécurisée examinée par un tiers d'une isolation basée sur un hyperviseur approprié sont des options alternatives.
- [9.11/A-0-3] DOIT effectuer l'authentification de l'écran de verrouillage dans l'environnement d'exécution isolé et n'autoriser l'utilisation des clés liées à l'authentification que si l'authentification aboutit. Les identifiants de l'écran de verrouillage DOIVENT être stockés de manière à ne permettre qu'à l'environnement d'exécution isolé d'effectuer l'authentification de l'écran de verrouillage. Le projet Android Open Source en amont fournit la couche d'abstraction matérielle (HAL) Gatekeeper et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
Début des nouvelles exigences pour Android 15
[9.11/A-0-4] DOIT prendre en charge l'attestation de clé lorsque la clé de signature d'attestation est protégée par du matériel sécurisé et que la signature est effectuée sur du matériel sécurisé. Les clés de signature d'attestation DOIVENT être
partagées entre un nombre suffisamment important d'appareils pour empêcher leurutilisation comme identifiants d'appareil permanents.Une façon de répondre à cette exigence consiste à partager la même clé d'attestation,sauf si au moins 100 000 unités d'un SKU donné sont produites. Si plus de 100 000 unités d'un SKU sont produites, une clé différente PEUT être utilisée pour chaque tranche de 100 000 unités.
Fin des nouvelles exigences
Notez que si une implémentation d'appareil est déjà lancée sur une version antérieure d'Android, cet appareil est exempté de l'obligation d'avoir un keystore compatible avec un environnement d'exécution isolé et d'accepter l'attestation de clé, sauf s'il déclare la fonctionnalité android.hardware.fingerprint
, qui nécessite un keystore compatible avec un environnement d'exécution isolé.
Implémentations d'appareils automobiles:
- [9.14/A-0-1] DOIT contrôler les messages provenant des sous-systèmes du véhicule du framework Android, par exemple en ajoutant à la liste d'autorisation les types et sources de messages autorisés.
- [9.14/A-0-2] Le moniteur doit empêcher les attaques de déni de service provenant du framework Android ou d'applications tierces. Cela permet de se protéger contre les logiciels malveillants qui inondent le réseau du véhicule de trafic, ce qui peut entraîner un dysfonctionnement des sous-systèmes du véhicule.
2.5.6. Compatibilité des outils et options pour les développeurs
Début des nouvelles exigences pour Android 15
Implémentations d'appareils automobiles:
- Perfetto
- [6.1/A-0-1] DOIT exposer un binaire
/system/bin/perfetto
à l'utilisateur du shell dont la ligne de commande est conforme à la documentation de perfetto. - [6.1/A-0-2] Le binaire perfetto DOIT accepter en entrée une configuration protobuf conforme au schéma défini dans la documentation de perfetto.
- [6.1/A-0-3] Le binaire perfetto DOIT écrire en sortie une trace protobuf conforme au schéma défini dans la documentation de Perfetto.
- [6.1/A-0-4] DOIT fournir, via le binaire perfetto, au moins les sources de données décrites dans la documentation de perfetto.
- [6.1/A-0-5] Le daemon de traçage perfetto DOIT être activé par défaut (propriété système
persist.traced.enable
).
- [6.1/A-0-1] DOIT exposer un binaire
Fin des nouvelles exigences
2.6. Configuration requise pour la tablette
Un appareil Android Tablet désigne une implémentation d'appareil Android qui répond généralement à tous les critères suivants:
- À utiliser en le tenant dans les deux mains.
- Ne propose pas de configuration en mode clamshell ou convertible.
- Les implémentations de clavier physique utilisées avec l'appareil se connectent via une connexion standard (par exemple, USB, Bluetooth).
dispose d'une source d'alimentation qui permet de le déplacer, comme une batterie ;
La taille de l'écran est comprise entre 7 et 18 pouces, mesurée en diagonale.
Les implémentations d'appareils de tablette ont des exigences similaires à celles des implémentations d'appareils portables. Les exceptions sont indiquées par un * dans cette section et sont indiquées à titre de référence dans cette section.
2.6.1. Matériel
Gyroscope
Si les implémentations d'appareils de tablette incluent un gyroscope à trois axes, elles:
- [7.3.4/Tab-1-1] DOIT être capable de mesurer les changements d'orientation jusqu'à 1 000 degrés par seconde.
Mémoire et stockage minimums (section 7.6.1)
Les densités d'écran indiquées pour les écrans petits/normaux dans les exigences concernant les appareils portables ne s'appliquent pas aux tablettes.
Début des nouvelles exigences pour Android 15
Mode périphérique USB (section 7.7.1)
Si les implémentations d'appareils de tablette incluent un port USB compatible avec le mode périphérique, elles:
- [7.7.1/Tab] PEUT implémenter l'API Android Open Accessory (AOA).
Fin des nouvelles exigences
Mode réalité virtuelle (section 7.9.1)
Réalité virtuelle hautes performances (section 7.9.2)
Les exigences liées à la réalité virtuelle ne s'appliquent pas aux tablettes.
2.6.2. Modèle de sécurité
Clés et identifiants (section 9.11)
Consultez la section [9.11].
Si les implémentations d'appareils de tablette incluent plusieurs utilisateurs et ne déclarent pas l'indicateur de fonctionnalité android.hardware.telephony
, elles:
- [9.5/T-1-1] DOIT prendre en charge les profils limités, une fonctionnalité qui permet aux propriétaires d'appareils de gérer des utilisateurs supplémentaires et leurs fonctionnalités sur l'appareil. Avec les profils restreints, les propriétaires d'appareils peuvent rapidement configurer des environnements distincts pour que d'autres utilisateurs puissent y travailler, et gérer des restrictions plus précises dans les applications disponibles dans ces environnements.
Si les implémentations d'appareils de tablette incluent plusieurs utilisateurs et déclarent l'indicateur de fonctionnalité android.hardware.telephony
, elles:
- [9.5/T-2-1] NE DOIT PAS prendre en charge les profils restreints, mais DOIT respecter l'implémentation des commandes AOSP pour autoriser /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 précharger une ou plusieurs applications ou composants de service avec un gestionnaire d'intent, pour tous les modèles de filtre d'intent publics définis par les intents d'application suivants listés ici.
3. Logiciel
3.1. Compatibilité avec les API gérées
L'environnement d'exécution de bytecode Dalvik géré est le principal moyen de transport des applications Android. L'API Android est l'ensemble d'interfaces de la plate-forme Android exposées aux applications exécutées dans l'environnement d'exécution géré.
Implémentations de l'appareil:
[C-0-1] DOIT fournir des implémentations complètes, y compris tous les comportements documentés, de toute API documentée exposée par le SDK Android ou de toute API décorée avec le repère "@SystemApi" dans le code source Android en amont.
[C-0-2] DOIT prendre en charge/conserver toutes les classes, méthodes et éléments associés marqués par l'annotation TestApi (@TestApi).
[C-0-3] NE DOIT PAS omettre d'API gérées, modifier les interfaces ou les signatures d'API, s'écarter du comportement documenté ni inclure de no-ops, sauf dans les cas spécifiquement autorisés par cette définition de compatibilité.
[C-0-4] DOIT toujours conserver les API et se comporter de manière raisonnable, même lorsque certaines fonctionnalités matérielles pour lesquelles Android inclut des API sont omises. Consultez la section 7 pour connaître les exigences spécifiques à ce scénario.
[C-0-5] NE DOIT PAS autoriser les applications tierces à utiliser des interfaces non SDK, qui sont définies comme des méthodes et des champs dans les packages de langage Java qui se trouvent dans le chemin d'accès au chemin d'exécution de démarrage dans AOSP et qui ne font pas partie du SDK public. Cela inclut les API décorées avec l'annotation
@hide
, mais pas avec un@SystemAPI
, comme décrit dans les documents du SDK, ainsi que les membres de classe privés et privés par package.[C-0-6] DOIT être fourni avec chaque interface non SDK dans les mêmes listes limitées que celles fournies via les indicateurs provisoires et de liste de refus dans le chemin
prebuilts/runtime/appcompat/hiddenapi-flags.csv
pour la branche de niveau d'API appropriée dans l'AOSP.[C-0-7] DOIT prendre en charge le mécanisme de mise à jour dynamique de la configuration signée pour supprimer les interfaces autres que SDK d'une liste restreinte en insérant la configuration signée dans n'importe quel APK, à l'aide des clés publiques existantes présentes dans AOSP.
Toutefois, ils:
- PEUT, si une API masquée est absente ou implémentée différemment dans l'implémentation de l'appareil, placer l'API masquée dans la liste de blocage ou l'omettre de toutes les listes de restriction.
- PEUT, si une API masquée n'existe pas déjà dans l'AOSP, ajouter l'API masquée à l'une des listes de restriction.
Début des nouvelles exigences pour Android 15
- [C-0-8] NE DOIT PAS permettre l'installation d'applications ciblant un niveau d'API inférieur à
2324.
Fin des nouvelles exigences
3.1.1. Extensions Android
Android permet d'étendre la surface de l'API gérée d'un niveau d'API particulier en mettant à jour la version de l'extension pour ce niveau d'API. L'API android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
renvoie la version de l'extension de l'apiLevel
fournie, s'il existe des extensions pour ce niveau d'API.
Implémentations d'appareils Android:
[C-0-1] DOIT précharger l'implémentation AOSP de la bibliothèque partagée
ExtShared
et des servicesExtServices
avec des versions supérieures ou égales aux versions minimales autorisées pour chaque niveau d'API. Par exemple, les implémentations d'appareils Android 7.0 exécutant le niveau d'API 24 DOIVENT inclure au moins la version 1.[C-0-2] DOIT uniquement renvoyer un numéro de version d'extension valide défini par l'AOSP.
[C-0-3] DOIT prendre en charge toutes les API définies par les versions d'extension renvoyées 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 de la section 3.1.
3.1.2. Bibliothèque Android
En raison de l'abandon du client HTTP Apache, les implémentations d'appareils:
- [C-0-1] NE DOIT PAS placer la bibliothèque
org.apache.http.legacy
dans le bootclasspath. - [C-0-2] Vous devez ajouter la bibliothèque
org.apache.http.legacy
au chemin d'accès des classes de l'application uniquement lorsque l'application remplit l'une des conditions suivantes :- Cible le niveau d'API 28 ou inférieur.
- Déclarer dans son fichier manifeste qu'il a besoin de la bibliothèque en définissant l'attribut
android:name
de<uses-library>
surorg.apache.http.legacy
.
L'implémentation AOSP répond à ces exigences.
3.2. Compatibilité avec les API souples
En plus des API gérées de la section 3.1, Android inclut également une API "soft" importante, uniquement au moment de l'exécution, sous la forme d'intents, d'autorisations et d'aspects similaires des applications Android qui ne peuvent pas être appliqués au moment de la compilation de l'application.
3.2.1. Autorisations
- [C-0-1] Les implémentateurs d'appareils DOIVENT prendre en charge et appliquer toutes les constantes d'autorisation, comme indiqué sur la page de référence sur les autorisations. Notez que la section 9 liste des exigences supplémentaires liées au modèle de sécurité Android.
3.2.2. Paramètres de compilation
Les API Android incluent un certain nombre de constantes dans la classe android.os.Build destinées à décrire l'appareil actuel.
- [C-0-1] Pour fournir des valeurs cohérentes et significatives dans les implémentations d'appareils, le tableau ci-dessous inclut des restrictions supplémentaires sur les formats de ces valeurs auxquelles les implémentations d'appareils DOIVENT se conformer.
Paramètre | Détails |
---|---|
VERSION.RELEASE | Version du système Android actuellement en cours d'exécution, au format lisible. Ce champ DOIT contenir l'une des valeurs de chaîne définies dans la section Chaînes de version autorisées pour Android 15. |
VERSION.SDK | Version du système Android actuellement en cours d'exécution, dans un format accessible au code d'application tiers. Pour Android 15, ce champ DOIT avoir la valeur entière 15_INT. |
VERSION.SDK_INT | Version du système Android actuellement en cours d'exécution, dans un format accessible au code d'application tiers. Pour Android 15, ce champ DOIT avoir la valeur entière 15_INT. |
VERSION.INCREMENTAL | Valeur choisie par l'implémentateur de l'appareil pour désigner la version spécifique du système Android actuellement en cours d'exécution, au format lisible par l'homme. Cette valeur NE DOIT PAS être réutilisée pour les différents builds mis à la disposition des utilisateurs finaux. L'utilisation typique de ce champ consiste à indiquer le numéro de build ou l'identifiant de modification de contrôle source utilisé pour générer le build. La valeur de ce champ DOIT être encodable en ASCII 7 bits imprimable et correspondre à l'expression régulière ^[^ :\/~]+$ . |
JEUX DE SOCIÉTÉ | Valeur choisie par l'implémentateur de l'appareil pour identifier le matériel interne spécifique utilisé par l'appareil, au format lisible par l'homme. Ce champ peut être utilisé pour indiquer la révision spécifique de la carte alimentant l'appareil. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière ^[a-zA-Z0-9_-]+$ . |
MARQUE | Valeur reflétant le nom de la marque associé à l'appareil tel qu'il est connu des utilisateurs finaux. DOIT être au format lisible par l'homme et DOIT représenter le fabricant de l'appareil ou la marque de l'entreprise sous laquelle l'appareil est commercialisé. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière ^[a-zA-Z0-9_-]+$ . |
ABIS COMPATIBLES | Nom de l'ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives |
ABI 32 bits compatibles | Nom de l'ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives |
ABI 64 bits compatibles | Nom du deuxième ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives. |
CPU_ABI | Nom de l'ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives |
CPU_ABI2 | Nom du deuxième ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives. |
APPAREIL | Valeur choisie par l'implémentateur de l'appareil contenant le nom de développement ou le nom de code identifiant la configuration des fonctionnalités matérielles et la conception industrielle de l'appareil. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière ^[a-zA-Z0-9_-]+$ . Ce nom d'appareil NE DOIT PAS changer pendant toute la durée de vie du produit. |
FINGERPRINT | Chaîne qui identifie de manière unique ce build. Il DOIT être raisonnablement lisible par l'humain. Il doit respecter ce modèle:
$(BRAND)/$(PRODUCT)/ Exemple : acme/myproduct/ L'empreinte ne doit PAS inclure d'espaces blancs. La valeur de ce champ DOIT être encodable en ASCII 7 bits. |
MATÉRIEL | Nom du matériel (à partir de la ligne de commande du noyau ou de /proc). Il DOIT être raisonnablement lisible par l'humain. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière ^[a-zA-Z0-9_-]+$ . |
HOST | Chaîne qui identifie de manière unique l'hôte sur lequel le build a été créé, au format lisible par l'utilisateur. Aucune exigence n'est requise concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide (""). |
ID | Identifiant choisi par l'implémentateur de l'appareil pour faire référence à une version spécifique, au format lisible par l'utilisateur. Ce champ peut être identique à android.os.Build.VERSION.INCREMENTAL, mais DOIT être une valeur suffisamment significative pour que les utilisateurs finaux puissent distinguer les builds logiciels. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière ^[a-zA-Z0-9._-]+$ . |
FABRICANT | Nom commercial du fabricant d'équipement d'origine (OEM) du produit. Aucune exigence n'est imposée concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide (""). Ce champ NE DOIT PAS changer pendant la durée de vie du produit. |
SOC_FABRICANT | Nom commercial du fabricant du système sur une puce (SOC) principal utilisé dans le produit. Les appareils du même fabricant de SOC doivent utiliser la même valeur constante. Veuillez demander au fabricant du SOC la constante à utiliser. La valeur de ce champ DOIT être encodable en ASCII 7 bits, DOIT correspondre à l'expression régulière ^([0-9A-Za-z ]+) , NE DOIT PAS commencer ni se terminer par un espace et NE DOIT PAS être égale à "unknown". Ce champ NE DOIT PAS changer pendant la durée de vie du produit. |
SOC_MODÈLE | Nom du modèle du système sur une puce (SoC) principal utilisé dans le produit. Les appareils avec le même modèle de SOC doivent utiliser la même valeur constante. Veuillez demander au fabricant du SOC la constante à utiliser.
La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière ^([0-9A-Za-z ._/+-]+)$ . Elle NE DOIT PAS commencer ni se terminer par un espace et NE DOIT PAS être égale à "unknown". Ce champ NE DOIT PAS changer pendant la durée de vie du produit. |
MODÈLE | Valeur choisie par l'implémentateur de l'appareil contenant le nom de l'appareil tel que connu par l'utilisateur final. Il doit s'agir du même nom que celui sous lequel l'appareil est commercialisé et vendu aux utilisateurs finaux. Aucune exigence n'est imposée concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide (""). Ce champ NE DOIT PAS changer pendant la durée de vie du produit. |
PRODUIT | Valeur choisie par l'implémentateur de l'appareil contenant le nom de développement ou le nom de code du produit spécifique (code SKU) qui DOIT être unique au sein de la même marque. DOIT être lisible par l'humain, mais n'est pas nécessairement destiné à être vu par les utilisateurs finaux. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière ^[a-zA-Z0-9_-]+$ . Ce nom de produit NE DOIT PAS changer pendant la durée de vie du produit. |
SKU de l'OEM | Valeur facultative choisie par l'implémentateur de l'appareil, qui contient l'unité de gestion des stocks (SKU) utilisée pour suivre les configurations spécifiques de l'appareil, par exemple les périphériques inclus avec l'appareil lors de la vente.
La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière ^([0-9A-Za-z.,_-]+)$ . |
SERIAL | DOIT renvoyer "UNKNOWN". |
TAGS | Liste de balises choisies par l'implémentateur de l'appareil, séparées par une virgule, qui permet de distinguer davantage le build. Les balises DOIVENT être encodables en ASCII 7 bits et correspondre à l'expression régulière ^[a-zA-Z0-9._-]+ . Elles DOIVENT également avoir l'une des valeurs correspondant aux trois configurations de signature de plate-forme Android typiques: release-keys, dev-keys et test-keys. |
DURÉE | Valeur représentant le code temporel de la compilation. |
MACH | Valeur choisie par l'implémentateur de l'appareil spécifiant la configuration d'exécution du build. Ce champ DOIT avoir l'une des valeurs correspondant aux trois configurations d'exécution Android typiques: user, userdebug ou eng. |
UTILISATEUR | Nom ou ID utilisateur de l'utilisateur (ou de l'utilisateur automatisé) ayant généré le build. Aucune exigence n'est requise concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni contenir la chaîne vide (""). |
PATCH DE SÉCURITÉ | Valeur indiquant le niveau du correctif de sécurité d'un build. Il DOIT indiquer que le build n'est en aucun cas vulnérable à l'un des problèmes décrits dans le bulletin de sécurité public Android désigné. Elle DOIT être au format [AAAA-MM-JJ] et correspondre à une chaîne définie documentée dans le Bulletin de sécurité publique Android ou dans l' Avis de sécurité Android, par exemple "2015-11-01". |
BASE_OS | Valeur représentant le paramètre FINGERPRINT de la version qui est par ailleurs identique à cette version, à l'exception des correctifs fournis dans le bulletin de sécurité publique Android. Il DOIT indiquer la valeur correcte et, si un tel build n'existe pas, indiquer une chaîne vide (""). |
BOOTLOADER | Valeur choisie par l'implémentateur de l'appareil pour identifier la version spécifique du bootloader interne utilisée sur l'appareil, au format lisible par l'utilisateur.
La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière ^[a-zA-Z0-9._-]+$ . |
getRadioVersion() | DOIT (être ou renvoyer) une valeur choisie par l'implémentateur de l'appareil identifiant la version radio/modem interne spécifique utilisée dans l'appareil, au format lisible par l'homme. Si un appareil ne dispose pas de radio/modem interne, il DOIT renvoyer NULL. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière ^[a-zA-Z0-9._-,]+$ . |
getSerial() |
DOIT (être ou renvoyer) un numéro de série matériel, qui DOIT être disponible et unique pour tous les appareils du même MODÈLE et du même FABRICANT. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière ^[a-zA-Z0-9]+$ . |
3.2.3. Compatibilité des intents
3.2.3.1. Intents d'application courants
Les intents Android permettent aux composants d'application de demander des fonctionnalités à d'autres composants Android. Le projet Android en amont inclut une liste d'applications qui implémentent plusieurs modèles d'intent pour effectuer des actions courantes.
Implémentations de l'appareil:
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ de précharger une ou plusieurs applications ou composants de service avec un gestionnaire d'intent, pour tous les modèles de filtre d'intent publics définis par les intents d'application suivants listés ici et de fournir un traitement, c'est-à-dire de répondre aux attentes du développeur pour ces intents d'application courants, comme décrit dans le SDK.
Pour connaître les intents d'application obligatoires pour chaque type d'appareil, consultez la section 2.
3.2.3.2. Résolution d'intent
[C-0-1] Étant donné qu'Android est une plate-forme extensible, les implémentations d'appareils DOIVENT permettre à chaque modèle d'intent référencé dans la section 3.2.3.1, à l'exception de "Paramètres", d'être remplacé par des applications tierces. L'implémentation Open Source d'Android en amont permet cela par défaut.
[C-0-2] Les implémentateurs d'appareils NE DOIVENT PAS associer des droits spéciaux à l'utilisation de ces modèles d'intent par les applications système, ni empêcher les applications tierces de se lier à ces modèles et de les contrôler. Cette interdiction inclut spécifiquement, mais sans s'y limiter, la désactivation de l'interface utilisateur "Chooser" qui permet à l'utilisateur de choisir parmi plusieurs applications qui gèrent toutes le même modèle d'intent.
[C-0-3] Les implémentations d'appareils DOIVENT fournir une interface utilisateur permettant aux utilisateurs de modifier l'activité par défaut pour les intents.
Toutefois, les implémentations d'appareils PEUVENT fournir des activités par défaut pour des modèles d'URI spécifiques (par exemple, http://play.google.com) lorsque l'activité par défaut fournit un attribut plus spécifique pour l'URI de données. Par exemple, un modèle de filtre d'intent spécifiant l'URI de données "http://www.android.com" est plus spécifique que le modèle d'intent principal du navigateur pour "http://".
Android inclut également un mécanisme permettant aux applications tierces de déclarer un comportement d'association d'application par défaut autoritaire pour certains types d'intents d'URI Web. Lorsque de telles déclarations faisant autorité sont définies dans les modèles de filtre d'intent d'une application, les implémentations d'appareils:
- [C-0-4] DOIT essayer de valider tous les filtres d'intent en effectuant les étapes de validation définies dans la spécification Digital Asset Links, telles qu'implémentées par le gestionnaire de paquets dans le projet Open Source Android en amont.
- [C-0-5] DOIT tenter de valider les filtres d'intent lors de l'installation de l'application et définir tous les filtres d'intent URI validés avec succès comme gestionnaires d'application par défaut pour leurs URI.
- PEUT définir des filtres d'intent URI spécifiques comme gestionnaires d'application par défaut pour leurs URI, s'ils sont correctement validés, mais que d'autres filtres d'URI candidats ne le sont pas. Si une implémentation d'appareil le fait, elle DOIT fournir à l'utilisateur les forçages de modèle par URI appropriés dans le menu des paramètres.
- DOIT fournir à l'utilisateur des commandes de liens d'application par application dans les paramètres comme suit :
- [C-0-6] L'utilisateur DOIT pouvoir remplacer de manière globale le comportement par défaut des liens d'application pour qu'une application soit toujours ouverte, toujours demander ou ne jamais s'ouvrir, ce qui doit s'appliquer de manière égale à tous les filtres d'intent URI candidats.
- [C-0-7] L'utilisateur DOIT pouvoir consulter une liste des filtres d'intent URI candidats.
- L'implémentation de l'appareil PEUT permettre à l'utilisateur de remplacer des filtres d'intent URI candidats spécifiques qui ont été validés, sur la base d'un filtre d'intent.
- [C-0-8] L'implémentation de l'appareil DOIT permettre aux utilisateurs d'afficher et de remplacer des filtres d'intent d'URI candidats spécifiques si l'implémentation de l'appareil permet à certains filtres d'intent d'URI candidats de réussir la validation, tandis que d'autres peuvent échouer.
3.2.3.3. Espaces de noms d'intent
- [C-0-1] Les implémentations d'appareils NE DOIVENT PAS inclure de composant Android qui respecte les nouveaux modèles d'intent ou d'intent de diffusion à l'aide d'une ACTION, d'une CATEGORIE ou d'une autre chaîne de clé dans l'espace de noms android.* ou com.android.*.
- [C-0-2] Les implémentateurs d'appareils NE DOIVENT PAS inclure de composants Android qui respectent de nouveaux modèles d'intent ou d'intent de diffusion à l'aide d'une ACTION, d'une CATEGORIE ou d'une autre chaîne de clé dans un espace de package appartenant à une autre organisation.
- [C-0-3] Les implémentateurs d'appareils NE DOIVENT PAS modifier ni étendre l'un des modèles d'intent listés dans la section 3.2.3.1.
- Les implémentations d'appareils PEUVENT inclure des modèles d'intent utilisant des espaces de noms clairement et évidemment associés à leur propre organisation. Cette interdiction est semblable à celle spécifiée pour les classes de langage Java dans la section 3.6.
3.2.3.4. Intents de diffusion
Les applications tierces s'appuient sur la plate-forme pour diffuser certains intents afin de les informer des modifications apportées à l'environnement matériel ou logiciel.
Implémentations de l'appareil:
- [C-0-1] DOIT diffuser les intents de diffusion publique listés ici en réponse aux événements système appropriés, comme décrit dans la documentation du SDK. Notez que cette exigence n'est pas en conflit avec la section 3.5, car la limite pour les applications en arrière-plan est également décrite dans la documentation du SDK. De plus, certains intents de diffusion sont conditionnés à la prise en charge matérielle. Si l'appareil est compatible avec le matériel nécessaire, il DOIT diffuser les intents et fournir le comportement conformément à la documentation du SDK.
3.2.3.5. Intents d'application conditionnels
Android inclut des paramètres qui permettent aux utilisateurs de sélectionner facilement leurs applications par défaut, par exemple pour l'écran d'accueil ou les SMS.
Lorsque cela est pertinent, les implémentations d'appareils DOIVENT fournir un menu de paramètres similaire et être compatibles avec le modèle de filtre d'intent et les méthodes d'API décrites dans la documentation du SDK, comme indiqué ci-dessous.
Si les implémentations d'appareils signalent android.software.home_screen
, elles:
- [C-1-1] DOIT respecter l'intent
android.settings.HOME_SETTINGS
pour afficher un menu de paramètres d'application par défaut pour l'écran d'accueil.
Si les implémentations d'appareils signalent android.hardware.telephony.calling
, elles:
[C-2-1] DOIT fournir un menu de paramètres qui appelle l'intent
android.provider.Telephony.ACTION_CHANGE_DEFAULT
pour afficher une boîte de dialogue permettant de modifier l'application de SMS par défaut.[C-2-2] DOIT respecter l'intent
android.telecom.action.CHANGE_DEFAULT_DIALER
pour afficher une boîte de dialogue permettant à l'utilisateur de modifier l'application Téléphone par défaut.- DOIT utiliser l'UI de l'application Téléphone par défaut sélectionnée par l'utilisateur pour les appels entrants et sortants, à l'exception des appels d'urgence, qui utiliseraient l'application Téléphone préinstallée.
[C-2-3] DOIT respecter l'intent android.telecom.action.CHANGE_PHONE_ACCOUNTS pour fournir à l'utilisateur la possibilité de configurer le
ConnectionServices
associé auPhoneAccounts
, ainsi qu'un PhoneAccount par défaut que le fournisseur de services de télécommunications utilisera pour passer des appels sortants. L'implémentation AOSP répond à cette exigence en incluant un menu "Option de compte d'appel" dans le menu des paramètres "Appels".[C-2-4] DOIT autoriser
android.telecom.CallRedirectionService
pour une application disposant du rôleandroid.app.role.CALL_REDIRECTION
.[C-2-5] DOIT fournir à l'utilisateur la possibilité de choisir une application qui détient le rôle
android.app.role.CALL_REDIRECTION
.[C-2-6] DOIT respecter les intents android.intent.action.SENDTO et android.intent.action.VIEW, et fournir une activité pour envoyer/afficher des SMS.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de respecter les intents android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW et android.intent.action.DIAL avec une application de numérotation préchargée pouvant gérer ces intents et fournir l'exécution comme décrit dans le SDK.
Si les implémentations d'appareils signalent android.hardware.nfc.hce
, elles:
- [C-3-1] DOIT respecter l'intent android.settings.NFC_PAYMENT_SETTINGS pour afficher un menu de paramètres d'application par défaut pour les paiements sans contact.
- [C-3-2] DOIT respecter l'intent android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT pour afficher une activité qui ouvre une boîte de dialogue demandant à l'utilisateur de modifier le service d'émulation de carte par défaut pour une certaine catégorie, comme décrit dans le SDK.
Si les implémentations d'appareils signalent android.hardware.nfc
, elles:
- [C-4-1] DOIT respecter ces intents android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED et android.nfc.action.TECH_DISCOVERED pour afficher une activité qui répond aux attentes des développeurs pour ces intents, comme décrit dans le SDK.
Si les implémentations d'appareils signalent android.hardware.bluetooth
, elles:
- [C-5-1] DOIT respecter l'intent android.bluetooth.adapter.action.REQUEST_ENABLE et afficher une activité système pour permettre à l'utilisateur d'activer le Bluetooth.
- [C-5-2] DOIT respecter l'intent android.bluetooth.adapter.action.REQUEST_DISCOVERABLE et afficher une activité système qui demande le mode visible.
Si les implémentations de l'appareil sont compatibles avec la fonctionnalité de mode Ne pas déranger, elles:
- [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 s'agir d'une activité dans laquelle l'utilisateur peut accorder ou refuser à l'application l'accès aux configurations de règles de non-déranger.
Si les implémentations de l'appareil permettent aux utilisateurs d'utiliser des modes de saisie tiers sur l'appareil, elles:
- [C-7-1] DOIT fournir un mécanisme accessible à l'utilisateur pour ajouter et configurer des modes de saisie tiers en réponse à l'intent
android.settings.INPUT_METHOD_SETTINGS
.
Si les implémentations d'appareils sont compatibles avec des services d'accessibilité tiers, elles:
- [C-8-1] DOIT respecter l'intention
android.settings.ACCESSIBILITY_SETTINGS
de fournir un mécanisme accessible à l'utilisateur pour activer et désactiver les services d'accessibilité tiers en plus des services d'accessibilité préchargés.
Si les implémentations d'appareils sont compatibles avec Wi-Fi Easy Connect et exposent la fonctionnalité aux applications tierces, elles:
- [C-9-1] DOIT implémenter les API d'intent Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI comme décrit dans la documentation du SDK.
Si les implémentations de l'appareil fournissent le mode Économiseur de données, elles:
- [C-10-1] DOIT fournir une interface utilisateur dans les paramètres, qui gère l'intent
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
, permettant aux utilisateurs d'ajouter des applications à la liste d'autorisation ou de les en supprimer.
Si les implémentations de l'appareil ne fournissent pas le mode Économiseur de données, elles:
- [C-11-1] Une activité doit gérer l'intent
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
, mais elle peut l'implémenter en tant que "no-op".
Si les implémentations d'appareils déclarent la compatibilité avec la caméra via android.hardware.camera.any
, elles:
- [C-12-3] DOIT gérer et DOIT n'autoriser que les applications Android préinstallées à gérer les intents suivants :
MediaStore.ACTION_IMAGE_CAPTURE
,MediaStore.ACTION_IMAGE_CAPTURE_SECURE
etMediaStore.ACTION_VIDEO_CAPTURE
, comme décrit dans le document du SDK.
Si les implémentations d'appareils signalent android.software.device_admin
, elles:
[C-13-1] DOIT respecter l'intent
android.app.action.ADD_DEVICE_ADMIN
pour appeler une UI afin de guider l'utilisateur lors de l'ajout de l'administrateur de l'appareil au système (ou lui permettre de le refuser).[C-13-2] DOIT respecter les intents android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD et android.app.action.START_ENCRYPTION, et doit disposer d'une activité pour répondre à ces intents, comme décrit dans le SDK ici.
Si les implémentations de l'appareil déclarent l'indicateur de fonctionnalité android.software.autofill
, elles:
- [C-14-1] DOIT implémenter entièrement les API
AutofillService
etAutofillManager
, et respecter l'intent android.settings.REQUEST_SET_AUTOFILL_SERVICE pour afficher un menu de paramètres d'application par défaut permettant d'activer et de désactiver la saisie automatique, et de 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 souhaitent autoriser des applications tierces à accéder aux statistiques d'utilisation, elles:
- [C-SR-2] Il est FORTEMENT RECOMMANDÉ de fournir un mécanisme accessible par l'utilisateur pour accorder ou révoquer l'accès aux statistiques d'utilisation en réponse à l'intent android.settings.ACTION_USAGE_ACCESS_SETTINGS pour les applications qui déclarent l'autorisation
android.permission.PACKAGE_USAGE_STATS
.
Si les implémentations d'appareils ont l'intention d'interdire à toute application, y compris les applications préinstallées, d'accéder aux statistiques d'utilisation, elles:
- [C-15-1] Une activité doit toujours gérer le modèle d'intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, mais elle doit l'implémenter comme une opération sans effet, c'est-à-dire avoir un comportement équivalent à celui qui se produit lorsque l'accès de l'utilisateur est refusé.
Si les implémentations de l'appareil affichent des liens vers les activités spécifiées par AutofillService_passwordsActivity dans les paramètres ou des liens vers les mots de passe utilisateur via un mécanisme similaire, elles:
- [C-16-1] DOIT afficher ces liens pour tous les services de saisie automatique installés.
Si les implémentations de l'appareil sont compatibles avec VoiceInteractionService
et qu'elles ont installé plusieurs applications utilisant cette API en même temps, elles:
- [C-18-1] DOIT respecter l'intent
android.settings.ACTION_VOICE_INPUT_SETTINGS
pour afficher un menu de paramètres d'application par défaut pour la saisie vocale et l'assistance.
Si les implémentations d'appareils signalent la fonctionnalité android.hardware.audio.output
, elles:
- [C-SR-3] Il est FORTEMENT RECOMMANDÉ de respecter les intents android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA et android.speech.tts.engine.GET_SAMPLE_TEXT. Une activité doit être fournie pour exécuter ces intents, comme décrit dans le SDK ici.
Android est compatible avec les écrans de veille interactifs, auparavant appelés "Dreams". Les écrans de veille permettent aux utilisateurs d'interagir avec les applications lorsqu'un appareil connecté à une source d'alimentation est inactif ou posé sur une station d'accueil. Implémentations de l'appareil:
- DOIT inclure la prise en charge des écrans de veille et fournir une option de paramètres permettant aux utilisateurs de configurer des écrans de veille en réponse à l'intent
android.settings.DREAM_SETTINGS
.
Si les implémentations d'appareils signalent android.hardware.nfc.uicc
ou android.hardware.nfc.ese
:
- [C-19-1] DOIT implémenter l'API d'intent NfcAdapter.ACTION_TRANSACTION_DETECTED (en tant que "EVT_TRANSACTION" défini par la spécification technique de la GSM Association TS.26 – Exigences concernant les téléphones à technologie NFC).
3.2.4. Activités sur des écrans secondaires/multiples
Si les implémentations d'appareils permettent de lancer des activités Android normales sur plusieurs écrans, elles:
- [C-1-1] Vous DEVEZ définir le flag de fonctionnalité
android.software.activities_on_secondary_displays
. - [C-1-2] DOIT garantir la compatibilité des API semblable à celle d'une activité exécutée sur l'écran principal.
- [C-1-3] DOIT placer la nouvelle activité sur le même écran que l'activité qui l'a lancée, lorsque la nouvelle activité est lancée sans spécifier d'écran cible via l'API
ActivityOptions.setLaunchDisplayId()
. - [C-1-4] DOIT détruire toutes les activités lorsqu'un affichage avec l'indicateur
Display.FLAG_PRIVATE
est supprimé. - [C-1-5] L'application DOIT masquer de manière 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 choisit de s'afficher au-dessus de l'écran de verrouillage à l'aide de l'API
Activity#setShowWhenLocked()
. - DOIT avoir
android.content.res.Configuration
, qui correspond à cet écran, pour s'afficher, fonctionner correctement et assurer la compatibilité si une activité est lancée sur un écran secondaire.
Si les implémentations de l'appareil permettent de lancer des activités Android normales sur des écrans secondaires et qu'un écran secondaire comporte l'indicateur android.view.Display.FLAG_PRIVATE:
- [C-3-1] Seul le propriétaire de l'écran, du système et des activités déjà affichés doit pouvoir y lancer des activités. Tout le monde peut lancer une application sur un écran doté du flag android.view.Display.FLAG_PUBLIC.
3.3. Compatibilité avec les API natives
La compatibilité du code natif est difficile. Par conséquent, les implémentateurs d'appareils sont:
- [C-SR-1] Nous vous recommandons vivement d'utiliser les implémentations des bibliothèques listées ci-dessous à partir du projet Open Source Android en amont.
3.3.1. Interfaces binaires d'application
Le bytecode Dalvik géré peut appeler le code natif fourni dans le fichier .apk
de l'application en tant que fichier .so
ELF compilé pour l'architecture matérielle de l'appareil appropriée. Étant donné que le code natif est fortement dépendant de la technologie de processeur sous-jacente, Android définit un certain nombre d'interfaces binaires d'application (ABI) dans le NDK Android.
Implémentations de l'appareil:
- [C-0-1] DOIT être compatible avec un ou plusieurs ABI Android NDK définis.
- [C-0-2] DOIT inclure la prise en charge du code exécuté dans l'environnement géré pour appeler du code natif, à l'aide de la sémantique standard de Java Native Interface (JNI).
- [C-0-3] DOIT être compatible avec la source (c'est-à-dire compatible avec l'en-tête) et compatible avec le binaire (pour l'ABI) avec chaque bibliothèque requise de la liste ci-dessous.
- [C-0-5] DOIT indiquer avec précision l'interface binaire d'application (ABI) native prise en charge par l'appareil, via les paramètres
android.os.Build.SUPPORTED_ABIS
,android.os.Build.SUPPORTED_32_BIT_ABIS
etandroid.os.Build.SUPPORTED_64_BIT_ABIS
, chacun étant une liste d'ABI séparée par une virgule, de la plus à la moins préférée.
Début des nouvelles exigences pour Android 15
- [C-0-6] DOIT signaler, via les paramètres ci-dessus, un sous-ensemble de la liste suivante d'ABI et NE DOIT PAS signaler d'ABI qui ne figure pas dans la liste.
armeabi
(plus compatible en tant que cible par le NDK)armeabi-v7a
arm64-v8a
x86
x86-64
riscv64
Fin des nouvelles exigences
[C-0-7] DOIT mettre toutes les bibliothèques suivantes, fournissant des API natives, à la disposition des applications qui incluent du code natif:
- libaaudio.so (prise en charge audio native d'AAudio)
- libamidi.so (compatibilité MIDI native, si la fonctionnalité
android.software.midi
est revendiquée comme décrit dans la section 5.9) - libandroid.so (prise en charge des activités Android natives)
- libc (bibliothèque C)
- libcamera2ndk.so
- libdl (lieneur dynamique)
- libEGL.so (gestion des surfaces OpenGL natives)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- liblog (journalisation Android)
- libmediandk.so (compatibilité avec les API multimédias natives)
- libm (bibliothèque mathématique)
- libneuralnetworks.so (API Neural Networks)
- libOpenMAXAL.so (compatibilité avec OpenMAX AL 1.0.1)
- libOpenSLES.so (compatibilité audio OpenSL ES 1.0.1)
- libRS.so
- libstdc++ (compatibilité minimale avec C++)
- libvulkan.so (Vulkan)
- libz (compression zlib)
- Interface JNI
[C-0-8] Vous NE DEVEZ PAS ajouter ni supprimer les fonctions publiques des bibliothèques natives listées ci-dessus.
[C-0-9] DOIT lister les bibliothèques non AOSP supplémentaires exposées directement aux applications tierces dans
/vendor/etc/public.libraries.txt
.[C-0-10] NE DOIT PAS exposer d'autres bibliothèques natives, implémentées et fournies dans AOSP en tant que bibliothèques système, aux applications tierces ciblant le niveau d'API 24 ou version ultérieure, car elles sont réservées.
[C-0-11] DOIT exporter tous les symboles de fonction OpenGL ES 3.1 et du pack d'extensions Android, tels que définis dans le NDK, via la bibliothèque
libGLESv3.so
. Notez que, bien que tous les symboles DOIVENT être présents, la section 7.1.4.1 décrit plus en détail les exigences concernant le moment où l'implémentation complète de chaque fonction correspondante est attendue.[C-0-12] DOIT exporter des symboles de fonction pour les symboles de fonction Vulkan 1.1 de base, ainsi que les extensions
VK_KHR_surface
,VK_KHR_android_surface
,VK_KHR_swapchain
,VK_KHR_maintenance1
etVK_KHR_get_physical_device_properties2
via la bibliothèquelibvulkan.so
. Notez que, bien que tous les symboles DOIVENT être présents, la section 7.1.4.2 décrit plus en détail les exigences concernant le moment où l'implémentation complète de chaque fonction correspondante est attendue.DOIT être compilé à l'aide du code source et des fichiers d'en-tête disponibles dans le projet Open Source Android en amont.
Notez que les futures versions d'Android pourront prendre en charge d'autres ABI.
3.3.2. Compatibilité du code natif ARM 32 bits
Si les implémentations d'appareils signalent la prise en charge de l'ABI armeabi
, elles:
- [C-3-1] DOIT également prendre en charge
armeabi-v7a
et signaler sa prise en charge, cararmeabi
n'est destiné qu'à la rétrocompatibilité avec les anciennes applications.
Si les implémentations de l'appareil signalent la prise en charge de l'ABI armeabi-v7a
, les applications qui utilisent cette ABI:
[C-2-1] DOIT inclure les lignes suivantes dans
/proc/cpuinfo
et NE DOIT PAS modifier les valeurs sur le même appareil, même lorsqu'elles sont lues par d'autres ABI.Features:
, suivi d'une liste des fonctionnalités de processeur ARMv7 facultatives compatibles avec l'appareil.CPU architecture:
, suivi d'un entier décrivant l'architecture ARM la plus élevée prise en charge par l'appareil (par exemple, "8" pour les appareils ARMv8).
[C-2-2] DOIT toujours maintenir les opérations suivantes disponibles, même dans le cas où l'ABI est implémentée sur une architecture ARMv8, soit via la prise en charge native du processeur, soit via l'émulation logicielle:
- Instructions SWP et SWPB.
- Opérations de barrière CP15ISB, CP15DSB et CP15DMB.
[C-2-3] DOIT inclure la compatibilité avec l'extension Advanced SIMD (également appelée NEON).
3.4. Compatibilité Web
3.4.1. Compatibilité avec WebView
Si les implémentations d'appareils fournissent une implémentation complète de l'API android.webkit.Webview
, elles:
- [C-1-1] DOIT signaler
android.software.webview
. - [C-1-2] Vous devez utiliser la version du projet Chromium à partir du projet Open Source Android en amont sur la branche Android 15 pour l'implémentation de l'API
android.webkit.WebView
. [C-1-3] La chaîne user-agent signalée par la WebView DOIT être au format suivant:
Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- La valeur de la chaîne $(VERSION) DOIT être identique à celle d'android.os.Build.VERSION.RELEASE.
- La chaîne $(MODEL) PEUT être vide, mais si elle ne l'est pas, elle DOIT avoir la même valeur que android.os.Build.MODEL.
- "Build/$(BUILD)" peut être omis, mais si cette valeur est présente, la chaîne $(BUILD) DOIT être identique à la valeur d'android.os.Build.ID.
- La valeur de la chaîne $(CHROMIUM_VER) DOIT correspondre à la version de Chromium dans le projet Open Source Android en amont.
- Les implémentations d'appareils PEUVENT omettre "Mobile" dans la chaîne user-agent.
Le composant WebView DOIT prendre en charge autant de fonctionnalités HTML5 que possible et, s'il est compatible avec la fonctionnalité, DOIT se conformer à la spécification HTML5.
[C-1-4] DOIT afficher le contenu fourni ou le contenu de l'URL distante dans un processus distinct de l'application qui instancie la WebView. Plus précisément, le processus de rendu distinct DOIT disposer de privilèges inférieurs, s'exécuter en tant qu'ID utilisateur distinct, ne pas avoir accès au répertoire de données de l'application, ne pas avoir d'accès direct au réseau et n'avoir accès qu'aux services système requis au minimum via Binder. L'implémentation AOSP de WebView répond à cette exigence.
Notez que si les implémentations d'appareils sont 32 bits ou déclarent l'indicateur de fonctionnalité android.hardware.ram.low
, elles sont exemptées de C-1-3.
3.4.2. Compatibilité avec les navigateurs
Si les implémentations d'appareils incluent une application de navigateur autonome pour la navigation Web générale, elles:
- [C-1-1] DOIT prendre en charge chacune de ces API associées à HTML5 :
- [C-1-2] DOIT être compatible avec l'API WebStorage HTML5/W3C et DEVRAIT être compatible avec l'API IndexedDB HTML5/W3C. Notez que, à mesure que les organismes de normalisation du développement Web passent à IndexedDB plutôt qu'à Webstorage, IndexedDB devrait devenir un composant obligatoire dans une future version d'Android.
- PEUT fournir une chaîne user-agent personnalisée dans l'application de navigateur autonome.
- DOIT implémenter la compatibilité avec autant de HTML5 que possible dans l'application de navigateur autonome (qu'elle soit basée sur l'application de navigateur WebKit en amont ou sur un remplacement tiers).
Toutefois, si les implémentations d'appareils n'incluent pas d'application de navigateur autonome, elles:
- [C-2-1] DOIT toujours prendre en charge les modèles d'intent publics, comme décrit dans la section 3.2.3.1.
3.5. Compatibilité du comportement des API
Implémentations de l'appareil:
- [C-0-9] DOIT s'assurer que la compatibilité comportementale des API est appliquée à toutes les applications installées, sauf si elles sont limitées comme décrit dans la section 3.5.1.
- [C-0-10] NE DOIT PAS implémenter l'approche de liste d'autorisation qui garantit la compatibilité du comportement des API uniquement pour les applications sélectionnées par les implémentateurs d'appareils.
Les comportements de chacun des types d'API (gérés, soft, natifs et Web) doivent être cohérents avec l'implémentation privilégiée du projet Open Source Android en amont. Voici quelques domaines de compatibilité spécifiques:
- [C-0-1] Les appareils NE DOIVENT PAS modifier le comportement ni la sémantique d'un intent standard.
- [C-0-2] Les appareils NE DOIVENT PAS modifier le cycle de vie ou la sémantique du cycle de vie d'un type particulier de composant système (tel que Service, Activity, ContentProvider, etc.).
- [C-0-3] Les appareils NE DOIVENT PAS modifier la sémantique d'une autorisation standard.
- Les appareils NE DOIVENT PAS modifier les limites appliquées aux applications en arrière-plan.
Plus précisément, pour les applications en arrière-plan :
- [C-0-4] Ils DOIVENT arrêter d'exécuter les rappels enregistrés par l'application pour recevoir les sorties de
GnssMeasurement
etGnssNavigationMessage
. - [C-0-5] Ils DOIVENT limiter la fréquence des mises à jour fournies à l'application via la classe d'API
LocationManager
ou la méthodeWifiManager.startScan()
. - [C-0-6] Si l'application cible le niveau d'API 25 ou version ultérieure, elle NE DOIT PAS autoriser l'enregistrement de broadcast receivers pour les diffusions implicites des intents Android standards dans le fichier manifeste de l'application, sauf si l'intent de diffusion nécessite une autorisation
"signature"
ou"signatureOrSystem"
protectionLevel
ou si elle figure sur la liste d'exemptions. - [C-0-7] Si l'application cible le niveau d'API 25 ou une version ultérieure, elle DOIT arrêter les services en arrière-plan de l'application, comme si l'application avait appelé la méthode
stopSelf()
des services, sauf si l'application est placée sur une liste d'autorisation temporaire pour gérer une tâche visible par l'utilisateur. - [C-0-8] Si l'application cible le niveau d'API 25 ou une version ultérieure, elle DOIT libérer les wakelocks qu'elle détient.
- [C-0-4] Ils DOIVENT arrêter d'exécuter les rappels enregistrés par l'application pour recevoir les sorties de
- [C-0-11] Les appareils DOIVENT renvoyer les fournisseurs de solutions de sécurité suivants comme sept premières valeurs de tableau de la méthode
Security.getProviders()
, dans l'ordre indiqué et avec les noms (comme renvoyés parProvider.getName()
) et les classes donnés, sauf si l'application a modifié la liste viainsertProviderAt()
ouremoveProvider()
. Les appareils peuvent renvoyer d'autres fournisseurs après la liste de fournisseurs spécifiée ci-dessous.- AndroidNSSP :
android.security.net.config.NetworkSecurityConfigProvider
- AndroidOpenSSL :
com.android.org.conscrypt.OpenSSLProvider
- CertPathProvider :
sun.security.provider.CertPathProvider
- AndroidKeyStoreBCWorkaround :
android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
- BC :
com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
- HarmonyJSSE :
com.android.org.conscrypt.JSSEProvider
- AndroidKeyStore :
android.security.keystore.AndroidKeyStoreProvider
- AndroidNSSP :
La liste ci-dessus n'est pas exhaustive. La suite de tests de compatibilité (CTS) teste des parties importantes de la plate-forme pour vérifier sa compatibilité comportementale, mais pas toutes. Il incombe à l'implémentateur de s'assurer de la compatibilité comportementale avec le projet Open Source Android. C'est pourquoi les implémentateurs d'appareils DOIVENT utiliser le code source disponible via le projet Android Open Source dans la mesure du possible, plutôt que de réimplémenter des parties importantes du système.
3.5.1. Restriction 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 des API décrits dans le SDK) et que ce mécanisme est plus restrictif que le bucket de mise en veille des applications limitées, ils:
- [C-1-1] L'application DOIT permettre à l'utilisateur de voir la liste des applications soumises à des restrictions.
- [C-1-2] DOIT fournir à l'utilisateur la possibilité d'activer / de désactiver toutes ces restrictions propriétaires dans chaque application.
[C-1-3] NE DOIT PAS appliquer automatiquement ces restrictions propriétaires sans preuve d'un mauvais état du système, mais PEUT appliquer les restrictions aux applications en cas de détection d'un mauvais état du système, comme des wakelocks bloqués, des services de longue durée et d'autres critères. Les critères PEUVENT être déterminés par les implémentateurs de l'appareil, mais DOIVENT être liés à l'impact de l'application sur l'état du système. D'autres critères qui ne sont pas purement liés à l'état du système, tels que le manque de popularité de l'application sur le marché, NE DOIVENT PAS être utilisés comme critères.
[C-1-4] Les restrictions propriétaires ne DOIVENT PAS être appliquées automatiquement aux applications lorsqu'un utilisateur a désactivé manuellement les restrictions d'application. L'utilisateur peut être invité à appliquer ces restrictions propriétaires.
[C-1-5] DOIT informer les utilisateurs si ces restrictions propriétaires sont appliquées automatiquement à une application. Ces informations DOIVENT être fournies dans les 24 heures précédant l'application de ces restrictions propriétaires.
[C-1-6] La méthode ActivityManager.isBackgroundRestricted() DOIT renvoyer la valeur "true" pour tous les appels d'API d'une application.
[C-1-7] NE DOIT PAS limiter l'application de premier plan supérieure utilisée explicitement par l'utilisateur.
[C-1-8] DOIT suspendre ces restrictions propriétaires sur une application chaque fois qu'un utilisateur commence à l'utiliser explicitement, ce qui en fait l'application de premier plan.
[C-1-10] DOIT fournir un document ou un site Web public et clair qui décrit comment les restrictions propriétaires sont appliquées. Ce document ou ce site Web DOIT être accessible en lien depuis les documents du SDK Android et DOIT inclure les éléments suivants:
- Conditions de déclenchement des restrictions propriétaires
- Ce qui peut être limité et comment
- Comment une application peut être exemptée de ces restrictions
- Comment une application peut demander une exemption des restrictions propriétaires, si elles acceptent une telle exemption 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é utilisée explicitement par un utilisateur pendant plus de 30 jours, [C-1-3] [C-1-5] sont exclus.
Si les implémentations d'appareils étendent les restrictions d'application implémentées dans AOSP, elles:
- [C-2-1]L'implémentation doit impérativement suivre les instructions décrites dans ce document.
3.5.2. Hibernation des applications
Si les implémentations de l'appareil incluent l'hibernation d'application incluse dans AOSP ou étendent la fonctionnalité incluse dans AOSP, elles:
- [C-1-1] DOIT respecter toutes les exigences de la section 3.5.1, à l'exception de [C-1-6] et [C-1-3].
- [C-1-2] Vous devez appliquer la restriction à l'application pour un utilisateur uniquement lorsqu'il est prouvé que l'utilisateur n'a pas utilisé l'application pendant une certaine période. Nous vous recommandons vivement de choisir une durée d'un mois ou plus. L'utilisation DOIT être définie par une interaction utilisateur explicite via l'API UsageStats#getLastTimeVisible() ou par tout élément qui ferait quitter à une application l'état d'arrêt forcé, y compris les liaisons de service, les liaisons de fournisseurs de contenu, les diffusions explicites, etc., qui seront suivis par une nouvelle API UsageStats#getLastTimeAnyComponentUsed().
- [C-1-3] Les restrictions qui affectent tous les utilisateurs de l'appareil DOIVENT être appliquées uniquement lorsqu'il est prouvé que le package n'a été utilisé par AUCUN utilisateur pendant une certaine période. Nous vous recommandons vivement de choisir une durée d'un mois ou plus.
- [C-1-4] L'application NE DOIT PAS être empêchée de répondre aux intents d'activité, aux liaisons de service, aux requêtes du fournisseur de contenu ou aux diffusions explicites.
L'hibernation d'application dans AOSP répond aux exigences ci-dessus.
3.6. Espaces de noms d'API
Android suit les conventions d'espace de noms de package et de classe définies par le langage de programmation Java. Pour assurer la compatibilité avec les applications tierces, les implémentateurs d'appareils NE DOIVENT PAS apporter de modifications interdites (voir ci-dessous) à ces espaces de noms de packages:
java.*
javax.*
sun.*
android.*
androidx.*
com.android.*
En d'autres termes:
- [C-0-1] Vous NE DEVEZ PAS modifier les API exposées publiquement sur la plate-forme Android en modifiant les signatures de méthode ou de classe, ni en supprimant des classes ou des champs de classe.
- [C-0-2] Vous NE DEVEZ PAS ajouter d'éléments exposés publiquement (tels que des classes ou des interfaces, ou des champs ou des méthodes pour des classes ou des interfaces existantes) ni d'API de test ou système aux API des espaces de noms ci-dessus. Un "élément exposé publiquement" est toute construction qui n'est pas décorée avec le repère "@hide" tel qu'il est utilisé dans le code source Android en amont.
Les implémentateurs d'appareils PEUVENT modifier l'implémentation sous-jacente des API, mais ces modifications:
- [C-0-3] NE DOIT PAS avoir d'incidence sur le comportement indiqué et la signature en langage Java de toute API exposée publiquement.
- [C-0-4] NE DOIVENT PAS être annoncés ni exposés aux développeurs.
Toutefois, les implémentateurs d'appareils peuvent ajouter des API personnalisées en dehors de l'espace de noms Android standard, mais les API personnalisées:
- [C-0-5] NE DOIT PAS se trouver dans un espace de noms appartenant à une autre organisation ou faisant référence à une autre organisation. Par exemple, les implémentateurs d'appareils NE DOIVENT PAS ajouter d'API à l'espace de noms
com.google.*
ou à un espace de noms similaire: seul Google peut le faire. De même, Google NE DOIT PAS ajouter d'API aux espaces de noms d'autres entreprises. - [C-0-6] DOIVENT être empaquetées dans une bibliothèque partagée Android afin que seules les applications qui les utilisent explicitement (via le mécanisme <uses-library>) soient affectées par l'augmentation de l'utilisation de la mémoire de ces API.
Les implémentateurs d'appareils peuvent ajouter des API personnalisées dans des langages natifs, en dehors des API du NDK, mais les API personnalisées:
- [C-1-1] NE DOIT PAS se trouver dans une bibliothèque NDK ni dans une bibliothèque appartenant à une autre organisation, comme décrit ici.
Si un implémentateur d'appareil propose d'améliorer l'un des espaces de noms de package ci-dessus (par exemple, en ajoutant une nouvelle fonctionnalité utile à une API existante ou en ajoutant une nouvelle API), il DOIT consulter source.android.com et commencer le processus d'envoi de modifications et de code, conformément aux informations disponibles sur ce site.
Notez que les restrictions ci-dessus correspondent aux conventions standards de dénomination des API dans le langage de programmation Java. Cette section vise simplement à renforcer ces conventions et à les rendre contraignantes en les incluant dans cette définition de compatibilité.
3.7. Compatibilité avec l'environnement d'exécution
Implémentations de l'appareil:
[C-0-1] DOIT être compatible avec le format Dalvik Executable (DEX) complet et la spécification et la sémantique du bytecode Dalvik.
[C-0-2] DOIT configurer les environnements d'exécution Dalvik pour allouer de la mémoire conformément à la plate-forme Android en amont, comme indiqué dans le tableau suivant. (Consultez la section 7.1.1 pour connaître les définitions de la taille et de la densité de l'écran.)
DOIT utiliser Android Runtime (ART), l'implémentation en amont de référence du format exécutable Dalvik et le système de gestion des paquets de l'implémentation de référence.
DOIT exécuter des tests de fuzz dans différents modes d'exécution et architectures cibles pour assurer la stabilité de l'environnement d'exécution. Reportez-vous à JFuzz et DexFuzz sur le site Web du projet Android Open Source.
Notez que les valeurs de mémoire spécifiées ci-dessous sont considérées comme des valeurs minimales, et que les implémentations d'appareils PEUVENT allouer plus de mémoire par application.
Mise en page de l'écran | Densité d'écran | Mémoire minimale de l'application |
---|---|---|
Montre Android | 120 ppp (ldpi) | 32 Mo |
140 ppp (140 dpi) | ||
160 ppp (mdpi) | ||
180 ppp (180dpi) | ||
200 dpi (200 dpi) | ||
213 ppp (tvdpi) | ||
220 dpi (220 dpi) | 36 Mo | |
240 ppp (hdpi) | ||
280 ppp (280 dpi) | ||
320 ppp (xhdpi) | 48 Mo | |
360 dpi (360 dpi) | ||
400 ppp (400 dpi) | 56 Mo | |
420 ppp (420 dpi) | 64 Mo | |
480 dpi (xxhdpi) | 88 Mo | |
560 ppp (560 dpi) | 112 Mo | |
640 ppp (xxxhdpi) | 154 Mo | |
petite/normale | 120 ppp (ldpi) | 32 Mo |
140 ppp (140 dpi) | ||
160 ppp (mdpi) | ||
180 ppp (180dpi) | 48 Mo | |
200 dpi (200 dpi) | ||
213 ppp (tvdpi) | ||
220 dpi (220 dpi) | ||
240 ppp (hdpi) | ||
280 ppp (280 dpi) | ||
320 ppp (xhdpi) | 80 Mo | |
360 dpi (360 dpi) | ||
400 ppp (400 dpi) | 96 Mo | |
420 ppp (420 dpi) | 112 Mo | |
480 dpi (xxhdpi) | 128 Mo | |
560 ppp (560 dpi) | 192 Mo | |
640 ppp (xxxhdpi) | 256 Mo | |
grand | 120 ppp (ldpi) | 32 Mo |
140 ppp (140 dpi) | 48 Mo | |
160 ppp (mdpi) | ||
180 ppp (180dpi) | 80 Mo | |
200 dpi (200 dpi) | ||
213 ppp (tvdpi) | ||
220 dpi (220 dpi) | ||
240 ppp (hdpi) | ||
280 ppp (280 dpi) | 96 Mo | |
320 ppp (xhdpi) | 128 Mo | |
360 dpi (360 dpi) | 160 Mo | |
400 ppp (400 dpi) | 192 Mo | |
420 ppp (420 dpi) | 228 Mo | |
480 dpi (xxhdpi) | 256 Mo | |
560 ppp (560 dpi) | 384 Mo | |
640 ppp (xxxhdpi) | 512 Mo | |
xlarge | 120 ppp (ldpi) | 48 Mo |
140 ppp (140 dpi) | 80 Mo | |
160 ppp (mdpi) | ||
180 ppp (180dpi) | 96 Mo | |
200 dpi (200 dpi) | ||
213 ppp (tvdpi) | ||
220 dpi (220 dpi) | ||
240 ppp (hdpi) | ||
280 ppp (280 dpi) | 144 Mo | |
320 ppp (xhdpi) | 192 Mo | |
360 dpi (360 dpi) | 240 Mo | |
400 ppp (400 dpi) | 288 Mo | |
420 ppp (420 dpi) | 336 Mo | |
480 dpi (xxhdpi) | 384 Mo | |
560 ppp (560 dpi) | 576 Mo | |
640 ppp (xxxhdpi) | 768 Mo |
3.8. Compatibilité de l'interface utilisateur
3.8.1. Lanceur (écran d'accueil)
Android inclut une application de lanceur (écran d'accueil) et prend en charge les applications tierces pour remplacer le lanceur de l'appareil (écran d'accueil).
Si les implémentations de l'appareil permettent aux applications tierces de remplacer l'écran d'accueil de l'appareil, elles:
- [C-1-1] Vous DEVEZ déclarer la fonctionnalité de plate-forme
android.software.home_screen
. - [C-1-2] DOIT renvoyer l'objet
AdaptiveIconDrawable
lorsque l'application tierce utilise la balise<adaptive-icon>
pour fournir son icône, et que les méthodesPackageManager
sont appelées pour récupérer les icônes.
Si les implémentations d'appareils incluent un lanceur d'applications par défaut compatible avec l'épinglage de raccourcis dans l'application, elles:
- [C-2-1] DOIT signaler
true
pourShortcutManager.isRequestPinShortcutSupported()
. - [C-2-2] L'affordance utilisateur doit demander à l'utilisateur avant d'ajouter un raccourci demandé par les applications via la méthode de l'API
ShortcutManager.requestPinShortcut()
. - [C-2-3] DOIT prendre en charge les raccourcis épinglés, ainsi que les raccourcis dynamiques et statiques, comme indiqué sur la page des raccourcis d'application.
À l'inverse, si les implémentations de l'appareil ne sont pas compatibles avec l'épinglage de raccourcis dans l'application, elles:
- [C-3-1] DOIT signaler
false
pourShortcutManager.isRequestPinShortcutSupported()
.
Si les implémentations d'appareils implémentent un lanceur par défaut qui permet d'accéder rapidement aux raccourcis supplémentaires fournis par les applications tierces via l'API ShortcutManager, elles:
- [C-4-1] DOIT prendre en charge toutes les fonctionnalités de raccourcis documentées (par exemple, les raccourcis statiques et dynamiques, les raccourcis d'épinglage) et implémenter entièrement les API de la classe d'API
ShortcutManager
.
Si les implémentations d'appareils incluent une application de lanceur par défaut qui affiche des badges pour les icônes d'application, elles:
- [C-5-1] DOIT respecter la méthode d'API
NotificationChannel.setShowBadge()
. En d'autres termes, affichez une affordance visuelle associée à l'icône de l'application si la valeur est définie surtrue
, et n'affichez aucun schéma de badging d'icône d'application lorsque tous les canaux de notification de l'application ont défini la valeur surfalse
. - PEUT remplacer les badges d'icône d'application par leur schéma de badges propriétaire lorsque les applications tierces indiquent la prise en charge du schéma de badges propriétaire via l'utilisation d'API propriétaires, mais DOIT utiliser les ressources et les valeurs fournies via les API de badges de notification décrites dans le SDK, telles que l'API
Notification.Builder.setNumber()
et l'APINotification.Builder.setBadgeIconType()
.
Si les implémentations d'appareils sont compatibles avec les icônes monochromes, les icônes suivantes:
- [C-6-1] DOIT être utilisé uniquement lorsqu'un utilisateur les active explicitement (par exemple, via le menu "Paramètres" ou le sélecteur de fond d'écran).
3.8.2. Widgets
Android est compatible avec les widgets d'application tiers en définissant un type de composant, une API et un cycle de vie correspondants qui permettent aux applications d'exposer un "AppWidget" à l'utilisateur final.
Si les implémentations d'appareils sont compatibles avec les widgets d'applications tierces, elles:
- [C-1-1] DOIT déclarer la prise en charge de la fonctionnalité de plate-forme
android.software.app_widgets
. - [C-1-2] DOIT inclure la prise en charge intégrée des AppWidgets et exposer les affordances de l'interface utilisateur pour ajouter, configurer, afficher et supprimer des AppWidgets
- [C-1-3] DOIT être capable d'afficher des widgets de 4 x 4 dans la taille de grille standard. Pour en savoir plus, consultez les consignes de conception des widgets d'application dans la documentation du SDK Android.
- PEUT prendre en charge les widgets d'application sur l'écran de verrouillage.
Si les implémentations de l'appareil sont compatibles avec les widgets d'applications tierces et l'épinglage de raccourcis dans l'application, elles:
- [C-2-1] DOIT signaler
true
pourAppWidgetManager.html.isRequestPinAppWidgetSupported()
. - [C-2-2] L'affordance utilisateur doit demander à l'utilisateur avant d'ajouter un raccourci demandé par les applications via la méthode de l'API
AppWidgetManager.requestPinAppWidget()
.
3.8.3. Notifications
Android inclut les API Notification
et NotificationManager
qui permettent aux développeurs d'applications tierces d'avertir les utilisateurs d'événements notables et d'attirer leur attention à l'aide des composants matériels (son, vibration et lumière, par exemple) et des fonctionnalités logicielles (par exemple, la barre de notification et la barre système) de l'appareil.
3.8.3.1. Présentation des notifications
Si les implémentations d'appareils autorisent les applications tierces à avertir les utilisateurs d'événements notables, elles:
- [C-1-1] DOIT prendre en charge les notifications qui utilisent des fonctionnalités matérielles, comme décrit dans la documentation du SDK et dans la mesure du possible avec le matériel d'implémentation de l'appareil. Par exemple, si une implémentation d'appareil inclut un vibreur, elle DOIT implémenter correctement les API de vibration. Si une implémentation d'appareil ne dispose pas de matériel, les API correspondantes DOIVENT être implémentées en tant que no-ops. Ce comportement est décrit plus en détail dans la section 7.
- [C-1-2] DOIT afficher correctement toutes les ressources (icônes, fichiers d'animation, etc.) fournies dans les API ou dans le guide de style des icônes de la barre d'état/système, bien qu'elles PUISSENT proposer une expérience utilisateur différente pour les notifications que celle fournie par l'implémentation Open Source Android de référence.
- [C-1-3] DOIT respecter et implémenter correctement les comportements décrits pour les API afin de mettre à jour, supprimer et regrouper les notifications.
- [C-1-4] DOIT fournir le comportement complet de l'API NotificationChannel documentée dans le SDK.
- [C-1-5] DOIT fournir une affordance utilisateur permettant de bloquer et de modifier la notification d'une application tierce spécifique par niveau de canal et de package d'application.
- [C-1-6] DOIT également fournir une affordance utilisateur pour afficher les canaux de notification supprimés.
[C-1-7] DOIT afficher correctement toutes les ressources (images, autocollants, icônes, etc.) fournies via Notification.MessagingStyle avec le texte de la notification, sans interaction supplémentaire de l'utilisateur. Par exemple, vous devez afficher toutes les ressources, y compris les icônes fournies via android.app.Person dans une conversation de groupe définie via setGroupConversation.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de fournir une affordance permettant à l'utilisateur de contrôler les notifications exposées aux applications auxquelles l'autorisation d'écouteur de notifications a été accordée. La granularité DOIT être telle que l'utilisateur puisse contrôler pour chaque écouteur de notification les types de notifications qui sont mis en correspondance avec cet écouteur. Les types DOIVENT inclure les notifications "conversations", "alertes", "silencieuses" et "importantes en cours".
[C-SR-2] Il est FORTEMENT RECOMMANDÉ de fournir aux utilisateurs une affordance leur permettant de spécifier les applications à exclure de la notification d'un écouteur de notification spécifique.
[C-SR-3] Il est FORTEMENT RECOMMANDÉ de présenter automatiquement une affordance utilisateur pour bloquer la notification d'une application tierce par niveau de canal et de package d'application après que l'utilisateur a ignoré cette notification plusieurs fois.
DOIT prendre en charge les notifications enrichies.
DOIT présenter certaines notifications de priorité plus élevée sous forme de notifications prioritaires.
DOIT proposer une affordance permettant à l'utilisateur de répéter les notifications.
NE DOIT GÉRER QUE la visibilité et le moment où les applications tierces peuvent avertir les utilisateurs d'événements notables afin de réduire les problèmes de sécurité tels que la distraction du conducteur.
Android 11 prend en charge les notifications de conversation, qui sont des notifications qui utilisent MessagingStyle et fournissent un ID de raccourci Personnes publié.
Implémentations de l'appareil:
- [C-SR-4] Il est FORTEMENT RECOMMANDÉ de regrouper et d'afficher
conversation notifications
avant les notifications autres que les notifications de conversation, à l'exception des notifications de service de premier plan en cours et des notificationsimportance:high
.
Si les implémentations d'appareils sont compatibles avec conversation notifications
et que l'application fournit les données requises pour bubbles
, elles:
- [C-SR-5] Il est FORTEMENT RECOMMANDÉ d'afficher cette conversation sous forme de bulle. L'implémentation AOSP répond à ces exigences avec l'UI système, les paramètres et le lanceur par défaut.
Si les implémentations de l'appareil sont compatibles avec les notifications enrichies, elles:
- [C-2-1] DOIT utiliser les ressources exactes telles que fournies via la classe d'API
Notification.Style
et ses sous-classes pour les éléments de ressources présentés. - DOIT présenter chaque élément de ressource (par exemple, icône, titre et texte récapitulatif) défini dans la classe d'API
Notification.Style
et ses sous-classes.
Les notifications prioritaires sont des notifications qui sont présentées à l'utilisateur lorsqu'elles arrivent, indépendamment de la surface sur laquelle il se trouve. Si les implémentations de l'appareil sont compatibles avec les notifications heads-up, elles:
- [C-3-1] Vous DEVEZ utiliser la vue et les ressources de notification prioritaire comme décrit dans la classe d'API
Notification.Builder
lorsque des notifications prioritaires sont présentées. - [C-3-2] DOIT afficher les actions fournies via
Notification.Builder.addAction()
avec le contenu de la notification sans interaction utilisateur supplémentaire, comme décrit dans le SDK.
3.8.3.2. Service de notification de l'auditeur
Android inclut les API NotificationListenerService
qui permettent aux applications (une fois activées explicitement par l'utilisateur) de recevoir une copie de toutes les notifications lorsqu'elles sont publiées ou mises à jour.
Implémentations de l'appareil:
- [C-0-1] DOIT mettre à jour correctement et rapidement l'intégralité des notifications pour tous ces services d'écouteur 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 l'appel d'API
snoozeNotification()
, ignorer la notification et effectuer un rappel après la durée de répétition définie dans l'appel d'API.
Si les implémentations d'appareils disposent d'une affordance permettant à l'utilisateur de suspendre les notifications:
- [C-1-1] DOIT refléter correctement l'état de la notification différée via les API standards telles que
NotificationListenerService.getSnoozedNotifications()
. - [C-1-2] L'affordance utilisateur doit être disponible pour suspendre les notifications de chaque application tierce installée, sauf si elles proviennent de services persistants/de premier plan.
3.8.3.3. Mode Ne pas déranger/Mode Prioritaire
Si les implémentations de l'appareil sont compatibles avec la fonctionnalité Ne pas déranger (également appelée mode Priorité), elles:
- [C-1-1] L'utilisateur doit pouvoir afficher les règles de DND automatiques créées par les applications, ainsi que les règles prédéfinies et créées par l'utilisateur, lorsque l'implémentation de l'appareil a fourni un moyen pour l'utilisateur d'autoriser ou d'interdire aux applications tierces d'accéder à la configuration de la règle de DND.
- [C-1-3] DOIT respecter les valeurs
suppressedVisualEffects
transmises viaNotificationManager.Policy
et si une application a défini l'un des indicateurs SUPPRESSED_EFFECT_SCREEN_OFF ou SUPPRESSED_EFFECT_SCREEN_ON, elle DOIT indiquer à l'utilisateur que les effets visuels sont supprimés dans le menu des paramètres du mode Ne pas déranger.
Début des nouvelles exigences pour Android 15
3.8.3.4. Protection des notifications sensibles
Les informations sensibles des notifications incluent des contenus tels que des mots de passe à usage unique, des codes de confirmation à usage unique et des codes d'authentification ou de réinitialisation similaires qui peuvent apparaître dans les notifications envoyées aux utilisateurs.
Si les implémentations d'appareils autorisent les applications tierces à avertir les utilisateurs d'événements notables, elles:
[C-1-1] Les informations de notification sensibles NE DOIVENT PAS être transmises aux écouteurs de notification, sauf si le service d'écouteur est l'un des suivants:
- Applications système signées avec un
uid
< 10 000 - UI du système
- Coquille Rose
- Application associée d'appareil désignée (définie par
CompanionDeviceManager
) - Rôle
SYSTEM_AUTOMOTIVE_PROJECTION
- Rôle
SYSTEM_NOTIFICATION_INTELLIGENCE
- Rôle MAISON
- Applications système signées avec un
L'implémentation AOSP de NotificationAssistantServices
illustre et répond à ces exigences. Pour voir un exemple, consultez android.ext.services.notification
.
Fin des nouvelles exigences
3.8.4. API Assist
Android inclut les API Assist pour permettre aux applications de choisir la quantité d'informations du contexte actuel à partager avec l'assistant sur l'appareil.
Si les implémentations de l'appareil sont compatibles avec l'action d'assistance, elles:
- [C-2-1] L'utilisateur final doit être informé clairement du moment où le contexte est partagé, par :
- Chaque fois que l'application d'assistance accède au contexte, une lumière blanche s'affiche autour des bords de l'écran, qui correspond ou dépasse la durée et la luminosité de l'implémentation du projet Android Open Source.
- Pour l'application d'assistance préinstallée, fournir une affordance utilisateur à moins de deux navigations du menu de paramètres de saisie vocale et d'application d'assistance par défaut, et ne partager le contexte que lorsque l'application d'assistance est explicitement appelée par l'utilisateur via un mot clé ou une saisie de touche de navigation d'assistance.
- [C-2-2] L'interaction désignée pour lancer l'application d'assistance, comme décrit dans la section 7.2.3, DOIT lancer l'application d'assistance sélectionnée par l'utilisateur, c'est-à-dire l'application qui implémente
VoiceInteractionService
ou une activité qui gère l'intentACTION_ASSIST
.
3.8.5. Alertes et notifications toast
Les applications peuvent utiliser l'API Toast
pour afficher des chaînes courtes non modales à l'utilisateur final qui disparaissent après un court laps de temps, et utiliser l'API de type de fenêtre TYPE_APPLICATION_OVERLAY
pour afficher des fenêtres d'alerte en superposition sur d'autres applications.
Si les implémentations d'appareils incluent un écran ou une sortie vidéo, elles:
[C-1-1] DOIT fournir une affordance utilisateur pour empêcher une application d'afficher des fenêtres d'alerte qui utilisent
TYPE_APPLICATION_OVERLAY
. L'implémentation AOSP répond à cette exigence en proposant des commandes dans la barre de notification.[C-1-2] DOIT respecter l'API Toast et afficher les toasts des applications aux utilisateurs finaux de manière très visible.
3.8.6. Thèmes
Android fournit des "thèmes" comme mécanisme permettant aux applications d'appliquer des styles à l'ensemble d'une activité ou d'une application.
Android inclut une famille de thèmes "Holo" et "Material" en tant qu'ensemble de styles définis que les développeurs d'applications peuvent utiliser s'ils souhaitent reproduire l'apparence du thème Holo tel que défini par le SDK Android.
Si les implémentations d'appareils incluent un écran ou une sortie vidéo, elles:
- [C-1-1] Vous NE DEVEZ PAS modifier l'un des attributs de thème Holo exposés aux applications.
- [C-1-2] DOIT prendre en charge la famille de thèmes "Material" et NE DOIT PAS modifier les attributs de thème Material ni les éléments exposés aux applications.
[C-1-3] La famille de polices "sans-serif" doit être définie sur Roboto version 2.x pour les langues compatibles avec Roboto, ou une affordance utilisateur doit être fournie pour modifier la police utilisée pour la famille de polices "sans-serif" en Roboto version 2.x pour les langues compatibles avec Roboto.
[C-1-4] DOIT générer des palettes tonales de couleurs dynamiques, comme spécifié dans la documentation AOSP de
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
(voirandroid.theme.customization.system_palette
etandroid.theme.customization.theme_style
).[C-1-5] DOIT générer des palettes de tons de couleurs dynamiques à l'aide de styles de thèmes de couleurs énumérés dans la documentation
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
(voirandroid.theme.customization.theme_styles
), à savoirTONAL_SPOT
,VIBRANT
,EXPRESSIVE
,SPRITZ
,RAINBOW
,FRUIT_SALAD
etMONOCHROMATIC
."Couleur source" utilisée pour générer des palettes tonales de couleurs dynamiques lorsqu'elle est envoyée avec
android.theme.customization.system_palette
(comme indiqué dansSettings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
).[C-1-6] La valeur de chrominance
CAM16
doit être égale ou supérieure à 5.DOIT être dérivé du fond d'écran via
com.android.systemui.monet.ColorScheme#getSeedColors
, qui fournit plusieurs couleurs sources valides parmi lesquelles choisir.DOIT utiliser la valeur
0xFF1B6EF3
si aucune des couleurs fournies ne répond aux exigences de couleur source ci-dessus.
Android inclut également une famille de thèmes "Par défaut de l'appareil" en tant qu'ensemble de styles définis que les développeurs d'applications peuvent utiliser s'ils souhaitent reproduire l'apparence du thème de l'appareil tel que défini par l'implémentateur de l'appareil.
- Les implémentations d'appareil PEUVENT modifier les attributs du thème par défaut de l'appareil exposés aux applications.
Android est compatible avec un thème de variante avec des barres système transparentes, ce qui permet aux développeurs d'applications de remplir la zone derrière la barre d'état et de navigation avec le contenu de leur application. Pour offrir une expérience de développement cohérente dans cette configuration, il est important que le style des icônes de la barre d'état soit conservé dans les différentes implémentations d'appareils.
Si les implémentations d'appareils incluent une barre d'état du système, elles:
- [C-2-1] Vous devez utiliser le blanc pour les icônes d'état du système (telles que l'intensité du signal et le niveau de la batterie) et les notifications émises par le système, sauf si l'icône indique un état problématique ou qu'une application demande une barre d'état claire à l'aide de l'indicateur WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS.
- [C-2-2] Les implémentations d'appareils Android DOIVENT changer la couleur des icônes d'état du système en noir (pour en savoir plus, consultez R.style) lorsqu'une application demande une barre d'état claire.
3.8.7. Fonds d'écran animés
Android définit un type de composant, ainsi qu'une API et un cycle de vie correspondants, qui permettent aux applications d'exposer un ou plusieurs fonds d'écran animés à l'utilisateur final. Les fonds d'écran animés sont des animations, des motifs ou des images similaires avec des fonctionnalités d'entrée limitées qui s'affichent en tant que fond d'écran, derrière d'autres applications.
Le matériel est considéré comme capable d'exécuter de manière fiable des fonds d'écran animés s'il peut exécuter tous les fonds d'écran animés, sans aucune limitation de fonctionnalité, à une fréquence d'images raisonnable et sans effet négatif sur les autres applications. Si des limites matérielles provoquent le plantage et/ou le dysfonctionnement des fonds d'écran et/ou des applications, ou qu'elles consomment une puissance de processeur ou de batterie excessive, ou qu'elles s'exécutent à des fréquences d'images inacceptablement faibles, le matériel est considéré comme incapable d'exécuter un fond d'écran animé. Par exemple, certains fonds d'écran animés peuvent utiliser un contexte OpenGL 2.0 ou 3.x pour afficher leur contenu. Le fond d'écran animé ne s'exécute pas de manière fiable sur du matériel qui n'est pas compatible avec plusieurs contextes OpenGL, car l'utilisation d'un contexte OpenGL par le fond d'écran animé peut entrer en conflit avec d'autres applications qui utilisent également un contexte OpenGL.
- Les implémentations d'appareils capables d'exécuter des fonds d'écran animés de manière fiable, comme décrit ci-dessus, DOIVENT implémenter des fonds d'écran animés.
Si les implémentations d'appareils implémentent des fonds d'écran animés, elles:
- [C-1-1] DOIT signaler le flag de fonctionnalité de plate-forme android.software.live_wallpaper.
3.8.8. Changement d'activité
Le code source Android en amont inclut l'écran d'aperçu, une interface utilisateur au niveau du système permettant de changer de tâche et d'afficher les activités et tâches récemment consultées à l'aide d'une image miniature de l'état graphique de l'application au moment où l'utilisateur a quitté l'application pour la dernière fois.
Les implémentations d'appareils, y compris la touche de navigation de la fonction "Récents", comme indiqué dans la section 7.2.3, PEUVENT modifier l'interface.
Si les implémentations d'appareils incluant la touche de navigation de la fonction "Récents", comme indiqué dans la section 7.2.3, modifient l'interface, elles:
- [C-1-1] DOIT prendre en charge au moins sept activités affichées.
- DOIT afficher au moins le titre de quatre activités à la fois.
- DOIT afficher la couleur de surbrillance, l'icône et le titre de l'écran dans les éléments récents.
- DOIT afficher une affordance de fermeture ("x"), mais PEUT retarder cette action jusqu'à ce que l'utilisateur interagisse avec les écrans.
- DOIT implémenter un raccourci pour passer facilement à l'activité précédente.
- DOIT déclencher l'action de commutation rapide entre les deux applications les plus récemment utilisées lorsque la touche de fonction "Récents" est enfoncée deux fois.
- DOIT déclencher le mode multifenêtre en écran partagé, le cas échéant, lorsque la touche de fonction "Récents" est enfoncée de manière prolongée.
- PEUT afficher les contenus récents affiliés sous forme de groupe qui se déplace ensemble.
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'utiliser l'interface utilisateur Android en amont (ou une interface basée sur des miniatures similaire) pour l'écran d'aperçu.
3.8.9. Gestion des entrées
Android est compatible avec la gestion des entrées et les éditeurs de modes de saisie tiers.
Si les implémentations de l'appareil permettent aux utilisateurs d'utiliser des modes de saisie tiers sur l'appareil, elles:
- [C-1-1] DOIT déclarer la fonctionnalité de plate-forme android.software.input_methods et prendre en charge les API IME telles que définies dans la documentation du SDK Android.
3.8.10. Contrôle des contenus multimédias sur l'écran de verrouillage
L'API Client de télécommande est obsolète à partir d'Android 5.0 au profit du modèle de notification multimédia, qui permet aux applications multimédias de s'intégrer aux commandes de lecture affichées sur l'écran de verrouillage.
3.8.11. Économiseurs d'écran (anciennement "Dreams")
Consultez la section 3.2.3.5 pour connaître l'intent de paramètres permettant de configurer les écrans de veille.
3.8.12. Position
Si les implémentations d'appareils incluent un capteur matériel (par exemple, un GPS) capable de fournir les coordonnées de localisation,
- [C-1-2] DOIT afficher l'état actuel de la localisation dans le menu "Localisation" des paramètres.
- [C-1-3] NE DOIT PAS afficher les modes de localisation dans le menu "Position" des paramètres.
3.8.13. Unicode et police
Android est compatible avec les caractères emoji définis dans Unicode 10.0.
Si les implémentations d'appareils incluent un écran ou une sortie vidéo, elles:
- [C-1-1] La plate-forme DOIT être capable d'afficher ces caractères emoji sous forme de glyphes en couleur.
- [C-1-2] DOIT inclure la prise en charge des éléments suivants :
- Police Roboto 2 avec différentes épaisseurs : sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed et sans-serif-condensed-light pour les langues disponibles sur l'appareil.
- Couverture complète de l'Unicode 7.0 pour l'alphabet latin, le grec et le cyrillique, y compris les plages A, B, C et D de l'alphabet latin étendu, ainsi que tous les glyphes du bloc des symboles de devise de l'Unicode 7.0.
- [C-1-3] NE DOIT PAS supprimer ni modifier NotoColorEmoji.tff dans l'image système. (Il est acceptable d'ajouter une nouvelle police d'emoji pour remplacer les emoji dans NotoColorEmoji.tff)
- DOIT être compatible avec les emoji de couleur de peau et de famille variés, comme indiqué dans le rapport technique Unicode 51.
Si les implémentations d'appareils incluent un IME, elles:
- DOIT fournir à l'utilisateur une méthode d'entrée pour ces caractères emoji.
Android est compatible avec l'affichage des polices birmanes. Le Myanmar dispose de plusieurs polices non conformes à Unicode, communément appelées "Zawgyi", pour afficher les langues birmanes.
Si les implémentations de l'appareil sont compatibles avec le birman, elles:
- [C-2-1] Le texte doit être affiché avec une police conforme à Unicode par défaut. Une police non conforme à Unicode ne doit pas être définie comme police par défaut, sauf si l'utilisateur la choisit dans le sélecteur de langue.
- [C-2-2] DOIT prendre en charge une police Unicode et une police non conforme à Unicode si une police non conforme à Unicode est prise en charge sur l'appareil. La police non conforme à Unicode NE DOIT PAS supprimer ni écraser la police Unicode.
- [C-2-3] DOIT afficher le texte avec une police non conforme à Unicode UNIQUEMENT SI un code de langue avec le code de script Qaag est spécifié (par exemple, my-Qaag). Aucun autre code de langue ou de région ISO (qu'il soit attribué, non attribué ou réservé) ne peut être utilisé pour faire référence à une police non conforme à l'Unicode pour le Myanmar. Les développeurs d'applications et les auteurs de pages Web peuvent spécifier my-Qaag comme code de langue désigné, comme ils le feraient pour n'importe quelle autre langue.
3.8.14. Multifenêtres
Si les implémentations d'appareils peuvent afficher plusieurs activités en même temps, elles:
- [C-1-1] DOIT implémenter ces modes multifenêtre conformément aux comportements d'application et aux API décrits dans la documentation de prise en charge du mode multifenêtre du SDK Android, et doit respecter les exigences suivantes:
- [C-1-2] DOIT respecter
android:resizeableActivity
défini par une application dans le fichierAndroidManifest.xml
, comme décrit dans ce SDK. - [C-1-3] NE DOIT PAS proposer de mode É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.
- [C-1-4] Une activité NE DOIT PAS être redimensionnée à une taille inférieure à 220 dp dans les modes multifenêtre autres que Picture-in-picture.
- Les implémentations d'appareils avec une taille d'écran
xlarge
DOIVENT être compatibles avec le mode de dessin libre.
Si les implémentations de l'appareil sont compatibles avec le ou les modes multifenêtre et le mode Écran partagé, elles:
- [C-2-2] DOIT recadrer l'activité ancrée d'un mode multifenêtre en écran partagé, mais DOIT afficher une partie de son contenu, si l'application Launcher est la fenêtre sélectionnée.
- [C-2-3] DOIT respecter les valeurs
AndroidManifestLayout_minWidth
etAndroidManifestLayout_minHeight
déclarées de l'application de lanceur tiers et ne pas remplacer ces valeurs lors de l'affichage d'un contenu de l'activité ancrée.
Si les implémentations de l'appareil sont compatibles avec le ou les modes multifenêtre et le mode multifenêtre Picture-in-picture, elles:
- [C-3-1] DOIT lancer des activités en mode multifenêtre Picture-in-picture lorsque l'application :
* Cible le niveau d'API 26 ou supérieur et déclare
android:supportsPictureInPicture
* Cible le niveau d'API 25 ou inférieur et déclare à la foisandroid:resizeableActivity
etandroid:supportsPictureInPicture
. - [C-3-2] DOIT exposer les actions dans leur SystemUI comme spécifié par l'activité PIP actuelle via l'API
setActions()
. - [C-3-3] DOIT prendre en charge les formats supérieurs ou égaux à 1:2,39 et inférieurs ou égaux à 2,39:1, comme spécifié par l'activité PIP via l'API
setAspectRatio()
. - [C-3-4] Vous devez utiliser
KeyEvent.KEYCODE_WINDOW
pour contrôler la fenêtre PIP. Si le mode PIP n'est pas implémenté, la clé doit être disponible pour l'activité de premier plan. - [C-3-5] DOIT fournir une affordance utilisateur pour empêcher l'affichage d'une application en mode PIP. L'implémentation AOSP répond à cette exigence en disposant de commandes dans la barre de notification.
[C-3-6] DOIT allouer la largeur et la hauteur minimales suivantes pour la fenêtre PIP lorsqu'une application ne déclare aucune valeur pour
AndroidManifestLayout_minWidth
etAndroidManifestLayout_minHeight
:- Les appareils dont la valeur Configuration.uiMode est différente de
UI_MODE_TYPE_TELEVISION
DOIVENT allouer une largeur et une hauteur minimales de 108 dp. - Les appareils dont la valeur Configuration.uiMode est définie sur
UI_MODE_TYPE_TELEVISION
DOIVENT allouer une largeur minimale de 240 dp et une hauteur minimale de 135 dp.
- Les appareils dont la valeur Configuration.uiMode est différente de
Début des nouvelles exigences pour Android 15
Si les implémentations d'appareils incluent plusieurs zones d'affichage compatibles avec Android et les rendent disponibles pour les applications, elles:
- [C-4-1] DOIT être compatible avec le mode multifenêtre.
Si les implémentations de l'appareil sont compatibles avec le ou les modes multifenêtre, elles:
- [C-5-1] DOIT implémenter la version appropriée du niveau d'API des extensions du gestionnaire de fenêtres, comme décrit dans la section Extensions
WindowManager
.
Fin des nouvelles exigences
3.8.15. Encoche
Android est compatible avec un découpage d'écran, comme décrit dans la documentation du SDK. L'API DisplayCutout
définit une zone sur le bord de l'écran qui peut ne pas être fonctionnelle pour une application en raison d'une encoche ou d'un écran incurvé sur le ou les bords.
Si les implémentations de l'appareil incluent une ou plusieurs découpes d'écran:
- [C-1-5] L'écran ne doit PAS comporter de découpe si le format de l'appareil est 1,0 (1:1).
- [C-1-2] Il ne doit pas y avoir plus d'une découpe par arête.
- [C-1-3] DOIT respecter les indicateurs de découpe d'affichage définis par l'application via l'API
WindowManager.LayoutParams
, comme décrit dans le SDK. - [C-1-4] DOIT indiquer les valeurs correctes pour toutes les métriques de découpe définies dans l'API
DisplayCutout
.
3.8.16. Commandes de contrôle des appareils
Android inclut les API ControlsProviderService
et Control
pour permettre aux applications tierces de publier des commandes d'appareil afin d'afficher rapidement l'état et d'effectuer des actions pour les utilisateurs.
Pour connaître les exigences spécifiques à l'appareil, consultez la section 2_2_3.
3.8.17. Presse-papiers
Implémentations de l'appareil:
- [C-0-1] NE DOIT PAS envoyer de données du presse-papiers à un composant, une activité, un service ou via une connexion réseau, sans action explicite de l'utilisateur (par exemple, appuyer sur un bouton de la superposition) ni indication du contenu envoyé, sauf pour les services mentionnés dans la section 9.8.6 Capture de contenu et recherche d'applications.
Si les implémentations d'appareils génèrent un aperçu visible par l'utilisateur lorsque du contenu est copié dans le presse-papiers pour tout élément ClipData
où ClipData.getDescription().getExtras()
contient android.content.extra.IS_SENSITIVE
, elles:
- [C-1-1] L'aperçu visible par l'utilisateur doit être masqué.
L'implémentation de référence AOSP répond à ces exigences concernant le presse-papiers.
3.9. Gestion de l'appareil
Début des nouvelles exigences pour Android 15
Android inclut des fonctionnalités qui permettent aux applications de contrôle des règles relatives aux appareils conscientes de la sécurité d'effectuer des fonctions d'administration des appareils au niveau du système, telles que l'application de stratégies de mot de passe ou l'effacement à distance, via l'API Android Device Administration et les API Device Policy Manager.
Fin des nouvelles exigences
3.9.1. Provisionnement de l'appareil
3.9.1.1. Provisionnement du propriétaire de l'appareil
Si les implémentations d'appareil déclarent android.software.device_admin
, elles:
- [C-1-1] DOIT prendre en charge l'enregistrement d'un client Device Policy (DPC) en tant qu'application propriétaire de l'appareil, comme décrit ci-dessous :
- Lorsque l'implémentation de l'appareil n'a ni utilisateurs ni données utilisateur configurés, elle :
- [C-1-5] DOIT enregistrer l'application DPC en tant qu'application propriétaire de l'appareil ou permettre à l'application DPC de choisir de devenir propriétaire de l'appareil ou propriétaire 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 avec le type MIMEMIME_TYPE_PROVISIONING_NFC
. - [C-1-8] DOIT envoyer l'intent ACTION_GET_PROVISIONING_MODE après le déclenchement du provisionnement du propriétaire de l'appareil afin que l'application DPC puisse choisir de devenir propriétaire de l'appareil ou propriétaire du profil, en fonction des valeurs de
android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES
, sauf si il peut être déterminé à partir du contexte qu'il n'y a qu'une seule option valide. - [C-1-9] DOIT envoyer l'intent ACTION_ADMIN_POLICY_COMPLIANCE à l'application propriétaire de l'appareil si un propriétaire de l'appareil est défini lors du provisionnement, quelle que soit la méthode de provisionnement utilisée. L'utilisateur ne doit pas pouvoir continuer dans l'assistant de configuration tant que l'application Device Owner n'a pas terminé.
- [C-1-5] DOIT enregistrer l'application DPC en tant qu'application propriétaire de l'appareil ou permettre à l'application DPC de choisir de devenir propriétaire de l'appareil ou propriétaire du profil, si l'appareil déclare la compatibilité avec la technologie NFC (communication en champ proche) via le flag de fonctionnalité
- Lorsque l'implémentation de l'appareil comporte des utilisateurs ou des données utilisateur, elle :
- [C-1-7] Vous ne devez plus enregistrer d'application DPC en tant qu'application propriétaire de l'appareil.
- Lorsque l'implémentation de l'appareil n'a ni utilisateurs ni données utilisateur configurés, elle :
Début des nouvelles exigences pour Android 15
[C-1-2] DOIT afficher un avis de divulgation approprié (comme indiqué dans l'AOSP) et obtenir le consentement explicite de l'utilisateur final avant qu'une application ne soit définie en tant que propriétaire de l'appareil, sauf si l'appareil est configuré par programmation pour le mode Démo en magasin avant l'interaction de l'utilisateur final à l'écran. Si les implémentations d'appareils déclarent
android.software.device_admin
, mais incluent également une solution de gestion d'appareils propriétaire et fournissent un mécanisme permettant de promouvoir une application configurée dans leur solution en tant qu'"équivalent du propriétaire de l'appareil" au propriétaire de l'appareil standard tel que reconnu par les API Android DevicePolicyManager standards, elles:[C-2-1] DOIT mettre en place une procédure pour vérifier que l'application spécifique promue appartient à une solution de gestion d'appareils d'entreprise légitime et qu'elle a été configurée dans la solution propriétaire pour disposer des droits équivalents à ceux d'un "propriétaire d'appareil".
[C-2-2] DOIT afficher le même communiqué de consentement du propriétaire de l'appareil AOSP que le flux lancé par
android.app.action.PROVISION_MANAGED_DEVICE
avant d'enregistrer l'application DPC en tant que "Propriétaire de l'appareil".[C-2-3] LE CONSENTEMENT NE DOIT PAS être encodé en dur ni empêcher l'utilisation d'autres applications appartenant au propriétaire de l'appareil.
Fin des nouvelles exigences
3.9.1.2. Provisionnement de profils gérés
Si les implémentations d'appareils déclarent android.software.managed_users
, elles:
- [C-1-1] DOIT implémenter les API permettant à une application de contrôle des règles relatives aux appareils (DPC) de devenir le propriétaire d'un nouveau profil géré.
Début des nouvelles exigences pour Android 15
- [C-1-2] Le processus de provisionnement du profil géré (le 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 être conformes à l'implémentation AOSP.
Fin des nouvelles exigences
[C-1-3] DOIT fournir les affordances utilisateur suivantes dans les paramètres pour indiquer à l'utilisateur quand une fonction système particulière a été désactivée par le contrôleur de règles d'appareil (DPC):
- Icône cohérente ou autre affordance utilisateur (par exemple, l'icône d'informations AOSP en amont) pour indiquer quand un paramètre particulier est limité par un administrateur d'appareil.
- Brève explication fournie par l'administrateur de l'appareil via
setShortSupportMessage
. - Icône de l'application DPC.
[C-1-4] DOIT lancer le gestionnaire pour l'intent ACTION_PROVISIONING_SUCCESSFUL dans le profil professionnel si un propriétaire de profil est défini lorsque le provisionnement est lancé par l'intent android.app.action.PROVISION_MANAGED_PROFILE et que le DPC a implémenté le gestionnaire.
[C-1-5] DOIT envoyer la diffusion ACTION_PROFILE_PROVISIONING_COMPLETE au DPC du profil professionnel lorsque le provisionnement est lancé par l'intent android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-6] DOIT envoyer l'intent ACTION_GET_PROVISIONING_MODE après le déclenchement du provisionnement du propriétaire de profil afin que l'application DPC puisse choisir de devenir propriétaire de l'appareil ou propriétaire du profil, sauf lorsque le provisionnement est déclenché par l'intent android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-7] DOIT envoyer l'intent ACTION_ADMIN_POLICY_COMPLIANCE au profil professionnel lorsqu'un propriétaire de profil est défini lors du provisionnement, quelle que soit la méthode de provisionnement 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 l'application Profile Owner n'a pas terminé.
[C-1-8] DOIT envoyer la diffusion ACTION_MANAGED_PROFILE_PROVISIONED au DPC du profil personnel lorsqu'un propriétaire de profil est défini, quelle que soit la méthode de provisionnement utilisée.
3.9.2. Assistance pour les profils gérés
Si les implémentations d'appareil déclarent android.software.managed_users
, elles:
- [C-1-1] DOIT prendre en charge les profils gérés via les API
android.app.admin.DevicePolicyManager
. - [C-1-2] Un seul profil géré peut être créé.
- [C-1-3] DOIT utiliser un badge d'icône (similaire au badge de travail en amont d'AOSP) pour représenter les applications et widgets gérés, ainsi que d'autres éléments d'interface utilisateur avec badge, tels que "Récents" et "Notifications".
- [C-1-4] DOIT afficher une icône de notification (similaire au badge de travail en amont d'AOSP) pour indiquer quand l'utilisateur se trouve dans une application de profil géré.
- [C-1-5] DOIT afficher un toast indiquant que l'utilisateur se trouve dans le profil géré si et quand l'appareil se réveille (ACTION_USER_PRESENT) et que l'application de premier plan se trouve dans le profil géré.
- [C-1-6] Lorsqu'un profil géré existe, DOIT afficher une affordance visuelle dans le "sélecteur" d'intent pour permettre à l'utilisateur de transférer l'intent du profil géré à l'utilisateur principal ou inversement, si cette fonctionnalité est activée par le contrôleur de stratégie de l'appareil.
- [C-1-7] Lorsqu'un profil géré existe, il DOIT exposer les affordances utilisateur suivantes à la fois pour l'utilisateur principal et le profil géré :
- Comptabilisation distincte de la batterie, de la localisation, des données mobiles et de l'utilisation de l'espace de stockage pour l'utilisateur principal et le profil géré.
- Gestion indépendante des applications VPN installées dans l'utilisateur principal ou le profil géré.
- Gestion indépendante des applications installées dans l'utilisateur principal ou le profil géré.
- Gestion indépendante des comptes dans l'utilisateur principal ou le profil géré.
- [C-1-8] DOIT s'assurer que les applications de numérotation, de contacts et de messagerie préinstallées peuvent rechercher et consulter les informations sur l'appelant du profil géré (le cas échéant) ainsi que celles du profil principal, si le contrôleur de stratégie de l'appareil l'autorise.
- [C-1-9] DOIT s'assurer qu'il répond à toutes les exigences de sécurité applicables à un appareil avec plusieurs utilisateurs activés (voir la section 9.5), même si le profil géré n'est pas comptabilisé comme un autre utilisateur en plus de l'utilisateur principal.
- [C-1-10] Vous devez vous assurer que les données de la capture d'écran sont enregistrées dans l'espace de stockage du profil professionnel lorsqu'une capture d'écran est effectuée avec une fenêtre
topActivity
ayant le focus (celle avec laquelle l'utilisateur a interagi en dernier parmi toutes les activités) et appartenant à une application de profil professionnel. - [C-1-11] NE DOIT PAS capturer d'autres contenus d'écran (barre système, notifications ou tout contenu de profil personnel) sauf les fenêtres de l'application du profil professionnel (pour s'assurer que les données du profil personnel ne sont pas enregistrées dans le profil professionnel).
Si les implémentations de l'appareil déclarent android.software.managed_users
et android.software.secure_lock_screen
, elles:
- [C-2-1] DOIT permettre de spécifier un écran de verrouillage distinct répondant aux exigences suivantes pour accorder l'accès aux applications exécutées dans un profil géré uniquement.
- Les implémentations d'appareils DOIVENT respecter l'intent
DevicePolicyManager.ACTION_SET_NEW_PASSWORD
et afficher une interface permettant de configurer des identifiants d'écran de verrouillage distincts pour le profil géré. - Les identifiants de l'écran de verrouillage du profil géré DOIVENT utiliser les mêmes mécanismes de stockage et de gestion des identifiants que le profil parent, comme indiqué sur le site du projet Open Source Android.
- Les règles de mot de passe du DPC DOIVENT s'appliquer uniquement aux identifiants de l'écran de verrouillage du profil géré, sauf si elles sont appelées sur l'instance
DevicePolicyManager
renvoyée pargetParentProfileInstance
.
- Les implémentations d'appareils DOIVENT respecter l'intent
- Lorsque les contacts du profil géré sont affichés dans le journal des appels préinstallé, l'interface utilisateur de l'appel, les notifications en cours et les appels manqués, les applications de contacts et de messagerie, ils DOIVENT être associés au même badge que celui utilisé pour indiquer les applications du profil géré.
3.9.3. Assistance pour les utilisateurs gérés
Si les implémentations d'appareil déclarent android.software.managed_users
, elles:
- [C-1-1] DOIT fournir une affordance utilisateur pour se déconnecter de l'utilisateur actuel et revenir à l'utilisateur principal dans une session multi-utilisateur lorsque
isLogoutEnabled
renvoietrue
. L'affordance utilisateur DOIT être accessible depuis l'écran de verrouillage sans déverrouiller l'appareil.
Si les implémentations d'appareil déclarent android.software.device_admin
et fournissent une affordance utilisateur sur l'appareil pour ajouter des utilisateurs secondaires, elles:
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'afficher les mêmes informations sur le consentement du propriétaire de l'appareil AOSP qui ont été affichées dans le flux lancé 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 concernant le rôle de gestion des règles de l'appareil
Si les implémentations de l'appareil signalent android.software.device_admin
ou android.software.managed_users
, elles:
- [C-1-1] DOIT prendre en charge le rôle de gestion des règles s'appliquant aux appareils tel que défini dans la section 9.1. L'application qui détient le rôle de gestion des stratégies de l'appareil PEUT être définie 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écrit ci-dessus:
- [C-2-1] Les implémentations d'appareils DOIVENT prendre en charge le provisionnement sans application de titulaire de rôle de gestion des règles d'appareil (AOSP fournit une implémentation de référence).
Si un nom de package est défini pour config_devicePolicyManagement
comme décrit ci-dessus:
- [C-3-1] L'application DOIT être installée sur tous les profils d'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 d'appareil avant le provisionnement en définissant
config_devicePolicyManagementUpdater
.
Si un nom de package est défini pour config_devicePolicyManagementUpdater
comme décrit 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
.
3.9.5. Framework de résolution des règles relatives aux appareils
Si les implémentations de l'appareil signalent android.software.device_admin
ou android.software.managed_users
, elles:
- [C-1-1] DOIT résoudre les conflits de règles relatives aux appareils, comme indiqué dans le framework de résolution des règles relatives aux appareils.
3.10. Accessibilité
Android fournit une couche d'accessibilité qui aide les utilisateurs ayant un handicap à naviguer plus facilement sur leurs appareils. De plus, Android fournit des API de plate-forme qui permettent aux implémentations de services d'accessibilité de recevoir des rappels pour les événements utilisateur et système, et de générer d'autres mécanismes de retour, tels que la synthèse vocale, le retour haptique et la navigation avec le pavé tactile/le pavé directionnel.
Si les implémentations d'appareils sont compatibles avec des services d'accessibilité tiers, elles:
- [C-1-1] DOIT fournir une implémentation du framework d'accessibilité Android, comme décrit dans la documentation du SDK sur les API d'accessibilité.
- [C-1-2] DOIT générer des événements d'accessibilité et transmettre le
AccessibilityEvent
approprié à toutes les implémentationsAccessibilityService
enregistrées, comme indiqué dans le SDK. - [C-1-4] DOIT fournir une affordance utilisateur pour contrôler les services d'accessibilité qui déclarent AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. Notez que pour les implémentations d'appareils avec une barre de navigation système, elles DOIVENT permettre à l'utilisateur de disposer d'un bouton dans la barre de navigation du système pour contrôler ces services.
Si les implémentations de l'appareil incluent des services d'accessibilité préinstallés, elles:
- [C-2-1] DOIT implémenter ces services d'accessibilité préinstallés en tant qu'applications compatibles avec le démarrage direct lorsque le stockage de données est chiffré avec le chiffrement basé sur les fichiers (FBE).
- DOIT fournir un mécanisme dans le flux de configuration prêt à l'emploi permettant aux utilisateurs d'activer les services d'accessibilité pertinents, ainsi que des options pour ajuster la taille de la police, la taille de l'écran et les gestes d'agrandissement.
3.11. Synthèse vocale
Android inclut des API qui permettent aux applications d'utiliser les services de synthèse vocale (TTS) et aux fournisseurs de services de fournir des implémentations de services de synthèse vocale.
Si les implémentations d'appareils signalent la fonctionnalité android.hardware.audio.output:
- [C-1-1] DOIT être compatible avec les API du framework Android TTS.
Si les implémentations d'appareils acceptent l'installation de moteurs TTS tiers, elles:
- [C-2-1] DOIT fournir une affordance utilisateur pour permettre à l'utilisateur de sélectionner un moteur TTS à utiliser au niveau du système.
Début des nouvelles exigences pour Android 15
3.12. TV Input Framework
Le framework d'entrée Android TV (TIF) simplifie la diffusion de contenus en direct sur les appareils Android TV. TIF fournit une API standard pour créer des modules d'entrée qui contrôlent les appareils Android TV.
Si les implémentations de l'appareil sont compatibles avec le TIF:
- [C-1-1] Vous DEVEZ déclarer la fonctionnalité de plate-forme
android.software.live_tv
. - [C-1-2] DOIT prendre en charge toutes les API TIF afin qu'une application qui utilise ces API et le service d'entrées tierces basées sur TIF puisse être installée et utilisée sur l'appareil.
Fin des nouvelles exigences
3.13. Les réglages rapides
Android fournit un composant d'UI de configuration rapide qui permet d'accéder rapidement aux actions fréquemment utilisées ou nécessaires de toute urgence.
Si les implémentations d'appareils incluent un composant d'interface utilisateur des Réglages rapides et sont compatibles avec les Réglages rapides tiers, elles:
- [C-1-1] DOIT permettre à l'utilisateur d'ajouter ou de supprimer les cartes fournies via les API
quicksettings
à partir d'une application tierce. - [C-1-2] NE DOIT PAS ajouter automatiquement une carte d'une application tierce directement aux paramètres rapides.
- [C-1-3] DOIT afficher toutes les cartes ajoutées par l'utilisateur à partir d'applications tierces, ainsi que les cartes de réglage rapide fournies par le système.
3.14. Interface utilisateur multimédia
Si les implémentations d'appareils incluent des applications non activées par 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()
ougetIconUri()
et les titres obtenus viagetTitle()
, comme décrit dansMediaDescription
. Peut raccourcir les titres pour respecter les règles de sécurité (par exemple, en cas de distraction du conducteur).[C-1-3] DOIT afficher l'icône de l'application tierce chaque fois qu'elle affiche du contenu fourni par cette application tierce.
[C-1-4] DOIT permettre à l'utilisateur d'interagir avec l'ensemble de la hiérarchie
MediaBrowser
. PEUT limiter l'accès à une partie de la hiérarchie pour respecter les règles de sécurité (par exemple, en cas de distraction du conducteur), MAIS NE DOIT PAS accorder un traitement préférentiel en fonction du contenu ou du fournisseur de contenu.[C-1-5] DOIT considérer le double appui sur
KEYCODE_HEADSETHOOK
ouKEYCODE_MEDIA_PLAY_PAUSE
commeKEYCODE_MEDIA_NEXT
pourMediaSession.Callback#onMediaButtonEvent
.
3.15. Applis instantanées
Si les implémentations de l'appareil sont compatibles avec les applications instantanées, elles DOIVENT répondre aux exigences suivantes:
- [C-1-1] Les applications instantanées ne doivent être autorisées qu'à utiliser des autorisations dont la valeur
android:protectionLevel
est définie sur"instant"
. - [C-1-2] Les applications instantanées NE DOIVENT PAS interagir avec les applications installées via des intentions implicites, sauf si l'une des conditions suivantes est remplie :
- Le filtre de modèle d'intent du composant est exposé et comporte CATEGORY_BROWSABLE.
- L'action est ACTION_SEND, ACTION_SENDTO ou ACTION_SEND_MULTIPLE.
- La cible est exposée explicitement avec android:visibleToInstantApps
- [C-1-3] Les applications instantanées NE DOIVENT PAS interagir explicitement avec les applications installées, sauf si le composant est exposé via android:visibleToInstantApps.
- [C-1-4] Les applications installées NE DOIVENT PAS voir les informations sur les applications instantanées sur l'appareil, sauf si l'application instantanée se connecte explicitement à l'application installée.
Les implémentations d'appareils DOIVENT fournir les affordances utilisateur suivantes pour interagir avec les applications instantanées. L'AOSP répond aux exigences avec l'UI système, les paramètres et le lanceur par défaut. Implémentations de l'appareil:
- [C-1-5] DOIT fournir une affordance utilisateur permettant d'afficher et de supprimer les applications Instant stockées en cache localement pour chaque package d'application individuel.
- [C-1-6] DOIT fournir une notification utilisateur persistante pouvant être réduite lorsqu'une application instantanée est exécutée au premier plan. Cette notification utilisateur DOIT indiquer que les applications instantanées ne nécessitent pas d'installation et fournir une affordance utilisateur qui redirige l'utilisateur vers l'écran d'informations de l'application dans les paramètres. Pour les applications instantanées lancées via des intents Web, comme défini à l'aide d'un intent dont l'action est définie sur
Intent.ACTION_VIEW
et avec un schéma "http" ou "https", une affordance utilisateur supplémentaire DOIT permettre à l'utilisateur de ne pas lancer l'application instantanée et de lancer le lien associé avec le navigateur Web configuré, si un navigateur est disponible sur l'appareil. - [C-1-7] DOIT permettre d'accéder aux applications Instant exécutées à partir de la fonction "Récents" si elle est disponible sur l'appareil.
[C-1-8] DOIT précharger une ou plusieurs applications ou composants de service avec un gestionnaire d'intent pour les intents listés dans le SDK ici et rendre les intents visibles pour les applications instantanées.
3.16. Association d'un appareil associé
Android est compatible avec l'association d'appareils associés pour gérer plus efficacement l'association avec les appareils associés et fournit l'API CompanionDeviceManager
pour que les applications puissent accéder à cette fonctionnalité.
Si les implémentations d'appareils sont compatibles avec la fonctionnalité d'association d'appareils associés, elles:
- [C-1-1] Vous DEVEZ déclarer le flag de fonctionnalité
FEATURE_COMPANION_DEVICE_SETUP
. - [C-1-2] DOIT s'assurer que les API du package
android.companion
sont entièrement implémentées.
Début des nouvelles exigences pour Android 15
- [C-1-3] DOIT fournir des affordances utilisateur pour que l'utilisateur puisse sélectionner/confirmer qu'un appareil compagnon est présent et opérationnel, qui DOIT utiliser le même message que celui implémenté dans AOSP sans ajout ni modification.
Fin des nouvelles exigences
3.17. Applications lourdes
Si les implémentations de l'appareil déclarent la fonctionnalité FEATURE_CANT_SAVE_STATE
, elles:
- [C-1-1] Une seule application installée doit spécifier
cantSaveState
en cours d'exécution dans le système à la fois. Si l'utilisateur quitte une telle application sans la quitter explicitement (par exemple, en appuyant sur "Accueil" lorsqu'il quitte une activité active du système, au lieu d'appuyer sur "Retour" alors qu'il n'y a plus d'activités actives dans le système), les implémentations de l'appareil DOIVENT donner la priorité à cette application dans la RAM, comme elles le font pour les autres éléments qui doivent rester en cours d'exécution, tels que les services de premier plan. Lorsqu'une telle application est en arrière-plan, le système peut toujours lui appliquer des fonctionnalités de gestion de l'alimentation, telles que la limitation de l'accès au processeur et au réseau. - [C-1-2] DOIT fournir une affordance d'UI pour choisir l'application qui ne participera pas au mécanisme de sauvegarde/restauration d'état normal une fois que l'utilisateur lance une deuxième application déclarée avec l'attribut
cantSaveState
. - [C-1-3] NE DOIT PAS appliquer d'autres modifications de règles aux applications qui spécifient
cantSaveState
, telles que la modification des performances du processeur ou de la priorité de planification.
Si les implémentations de l'appareil ne déclarent pas la fonctionnalité FEATURE_CANT_SAVE_STATE
, elles:
- [C-1-1] DOIT ignorer l'attribut
cantSaveState
défini par les applications et NE DOIT PAS modifier le comportement de l'application en fonction de cet attribut.
3.18. Contacts
Android inclut des API Contacts Provider
pour permettre aux applications de gérer les informations de contact stockées sur l'appareil.
Les données de contact saisies directement sur l'appareil sont généralement synchronisées avec un service Web, mais elles peuvent également ne résider que localement sur l'appareil.
Les contacts qui ne sont stockés que sur l'appareil sont appelés contacts locaux.
Les RawContacts sont "associés à" ou "stockés dans" un compte lorsque les colonnes ACCOUNT_NAME
et ACCOUNT_TYPE
des contacts bruts correspondent aux champs Account.name et Account.type correspondants du compte.
Compte local par défaut: compte pour les contacts bruts qui ne sont stockés que sur l'appareil et qui ne sont pas associés à un compte dans AccountManager. Ils sont créés avec des valeurs null pour les colonnes ACCOUNT_NAME
et ACCOUNT_TYPE
.
Compte local personnalisé: compte pour les contacts bruts qui ne sont stockés que sur l'appareil et qui ne sont pas associés à un compte dans AccountManager. Ils sont créés avec au moins une valeur non nulle pour les colonnes ACCOUNT_NAME
et ACCOUNT_TYPE
.
Implémentations de l'appareil:
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ de ne pas créer de comptes locaux personnalisés.
Si les implémentations de l'appareil utilisent un compte local personnalisé:
- [C-1-1] Le
ACCOUNT_NAME
du compte local personnalisé DOIT être renvoyé parContactsContract.RawContacts.getLocalAccountName
. - [C-1-2] Le
ACCOUNT_TYPE
du compte local personnalisé DOIT être renvoyé parContactsContract.RawContacts.getLocalAccountType
. - [C-1-3] Les 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
etACCOUNT_TYPE
) DOIVENT être insérés dans le compte local personnalisé. - [C-1-4] Les contacts bruts insérés dans le compte local personnalisé NE DOIVENT PAS être supprimés lorsque des comptes sont ajoutés ou supprimés.
- [C-1-5] Les opérations de suppression effectuées sur le compte local personnalisé doivent entraîner la suppression immédiate des contacts bruts (comme si le paramètre
CALLER_IS_SYNCADAPTER
était défini sur "true"), même si le paramètreCALLER\_IS\_SYNCADAPTER
était défini sur "false" ou n'était pas spécifié.
Début des nouvelles exigences pour Android 15
3.19. Paramètres de langue
Implémentations de l'appareil:
- [C-0-1] NE DOIT PAS fournir d'affordance utilisateur permettant de sélectionner un traitement linguistique spécifique au genre pour les langues qui ne prennent pas en charge les traductions spécifiques au genre. Pour en savoir plus, consultez les ressources grammaticales.
Fin des nouvelles exigences
4. Compatibilité du packaging d'applications
Implémentations des appareils:
[C-0-1] DOIT être en mesure d'installer et d'exécuter les fichiers ".apk" Android générés par l'outil "aapt" inclus dans le SDK Android officiel.
- Étant donné que l'exigence ci-dessus peut s'avérer difficile, il est RECOMMANDÉ d'utiliser le système de gestion des paquets de l'implémentation de référence AOSP pour les implémentations d'appareils.
[C-0-2] DOIT être compatible avec la validation des fichiers ".apk" à l'aide du schéma de signature des APK v3.1, du schéma de signature des APK v3, du schéma de signature des APK v2 et de la signature JAR.
[C-0-3] NE DOIT PAS étendre les formats .apk, Android Manifest, bytecode Dalvik ou bytecode RenderScript de manière à empêcher l'installation et l'exécution correcte de ces fichiers sur d'autres appareils compatibles.
[C-0-4] NE DOIT PAS autoriser les applications autres que l'installateur enregistré actuel du package à désinstaller l'application en mode silencieux sans confirmation de l'utilisateur, comme indiqué dans le SDK pour l'autorisation
DELETE_PACKAGE
. Les seules exceptions sont l'application de vérification des paquets système qui gère l'intent PACKAGE_NEEDS_VERIFICATION et l'application de gestion de l'espace de stockage qui gère l'intent ACTION_MANAGE_STORAGE.[C-0-5] DOIT comporter une activité qui gère l'intent
android.settings.MANAGE_UNKNOWN_APP_SOURCES
.[C-0-6] NE DOIT PAS installer de packages d'application à partir de sources inconnues, sauf si l'application qui demande l'installation répond à toutes les exigences suivantes:
- Il DOIT déclarer l'autorisation
REQUEST_INSTALL_PACKAGES
ou définirandroid:targetSdkVersion
sur 24 ou moins. - L'utilisateur doit avoir autorisé l'installation d'applications à partir de sources inconnues.
- Il DOIT déclarer l'autorisation
DOIT fournir une affordance utilisateur pour accorder/révoquer l'autorisation d'installer des applications à partir de sources inconnues par application, mais PEUT choisir de l'implémenter comme une opération sans effet et de renvoyer
RESULT_CANCELED
pourstartActivityForResult()
, si l'implémentation de l'appareil ne souhaite pas permettre aux utilisateurs de faire ce choix. Toutefois, même dans ce cas, ils DOIVENT indiquer à l'utilisateur pourquoi aucun tel choix n'est présenté.[C-0-7] DOIT afficher une boîte de dialogue d'avertissement avec la chaîne d'avertissement fournie à l'utilisateur via l'API système
PackageManager.setHarmfulAppWarning
avant de lancer une activité dans une application qui a été marquée par la même API systèmePackageManager.setHarmfulAppWarning
comme potentiellement dangereuse.DOIT fournir une affordance utilisateur permettant de choisir de désinstaller ou de lancer une application dans la boîte de dialogue d'avertissement.
[C-0-8] DOIT implémenter la prise en charge du système de fichiers incrémentiel, comme indiqué ici.
[C-0-9] DOIT prendre en charge la validation des fichiers .apk à l'aide du schéma de signature des fichiers APK v4 et du schéma de signature des fichiers APK v4.1.
5. Compatibilité multimédia
Implémentations de l'appareil:
- [C-0-1] DOIT prendre en charge les formats multimédias, les encodeurs, les décodeurs, les types de fichiers et les formats de conteneur définis dans la section 5.1 pour chaque codec déclaré par
MediaCodecList
. - [C-0-2] DOIT déclarer et signaler la prise en charge des encodeurs et des décodeurs disponibles pour les applications tierces via
MediaCodecList
. - [C-0-3] DOIT être en mesure de décoder correctement et de mettre à la disposition des applications tierces tous les formats qu'il peut encoder. Cela inclut tous les flux de bits générés par ses encodeurs et les profils signalés dans son
CamcorderProfile
.
Implémentations de l'appareil:
- DOIVENT viser une latence de codec minimale. En d'autres termes, ils doivent :
- NE DOIT PAS consommer et stocker les tampons d'entrée et ne doit les renvoyer qu'une fois traités.
- NE DOIT PAS conserver les tampons décodés plus longtemps que spécifié par la norme (par exemple, SPS).
- NE DOIT PAS conserver les tampons encodés plus longtemps que nécessaire par la structure GOP.
Tous les codecs listés dans la section ci-dessous sont fournis en tant qu'implémentations logicielles dans l'implémentation Android préférée du projet Android Open Source.
Veuillez noter que ni Google ni l'Open Handset Alliance ne font aucune déclaration selon laquelle ces codecs sont exempts de brevets tiers. Les personnes qui souhaitent utiliser ce code source dans des produits matériels ou logiciels sont informées que les implémentations de ce code, y compris dans des logiciels Open Source ou des sharewares, peuvent nécessiter des licences de brevets de la part des titulaires de brevets concernés.
5.1. Codecs multimédias
5.1.1. Encodage audio
Pour en savoir plus, consultez la section 5.1.3. "Détails des codecs audio".
Si les implémentations d'appareils déclarent android.hardware.microphone
, elles DOIVENT prendre en charge l'encodage des formats audio suivants et les mettre à la disposition des applications tierces:
- [C-1-1] PCM/WAVE
- [C-1-2] FLAC
- [C-1-3] Opus
Tous les encodeurs audio DOIVENT être compatibles avec les éléments suivants:
- [C-3-1] Frames audio PCM 16 bits avec ordre d'octets natif via l'API
android.media.MediaCodec
.
5.1.2. Décodage audio
Pour en savoir plus, consultez la section 5.1.3. "Détails des codecs audio".
Si les implémentations d'appareils déclarent prendre en charge la fonctionnalité android.hardware.audio.output
, elles doivent prendre en charge le décodage des formats audio suivants:
- [C-1-1] Profil MPEG-4 AAC (AAC LC)
- [C-1-2] Profil MPEG-4 HE AAC (AAC+)
- [C-1-3] Profil MPEG-4 HE AACv2 (AAC+ amélioré)
- [C-1-4] AAC ELD (AAC à faible latence amélioré)
- [C-1-11] xHE-AAC (profil HE AAC étendu ISO/IEC 23003-3, qui inclut le profil de référence USAC et le profil de contrôle de la plage dynamique ISO/IEC 23003-4)
- [C-1-5] FLAC
- [C-1-6] MP3
- [C-1-7] MIDI
- [C-1-8] Vorbis
- [C-1-9] PCM/WAVE, y compris les formats audio haute résolution jusqu'à 24 bits, le taux d'échantillonnage de 192 kHz et 8 canaux. Notez que cette exigence ne concerne que le décodage et qu'un appareil est autorisé à effectuer un downsampling et un downmix lors de la phase de lecture.
- [C-1-10] Opus
Si les implémentations d'appareils prennent en charge le décodage des tampons d'entrée AAC des flux multicanaux (c'est-à-dire plus de deux canaux) en PCM via le décodeur audio AAC par défaut de l'API android.media.MediaCodec
, les éléments suivants DOIVENT être pris en charge:
- [C-2-1] Le décodage DOIT être effectué sans downmix (par exemple, un flux AAC 5.0 doit être décodé en cinq canaux PCM, un flux AAC 5.1 doit être décodé en six canaux PCM).
- [C-2-2] Les métadonnées de plage dynamique DOIVENT être conformes à la définition de la "Contrôle de la plage dynamique (DRC)" dans la norme ISO/CEI 14496-3, ainsi qu'aux clés DRC
android.media.MediaFormat
pour configurer les comportements liés à la plage dynamique du décodeur audio. Les clés AAC DRC ont été introduites dans l'API 21. Il s'agit de :KEY_AAC_DRC_ATTENUATION_FACTOR
,KEY_AAC_DRC_BOOST_FACTOR
,KEY_AAC_DRC_HEAVY_COMPRESSION
,KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
etKEY_AAC_ENCODED_TARGET_LEVEL
. - [C-SR-1] Il est vivement recommandé que les exigences C-2-1 et C-2-2 ci-dessus soient satisfaites par tous les décodeurs audio AAC.
Lors du décodage de l'audio USAC, MPEG-D (ISO/IEC 23003-4):
- [C-3-1] Les métadonnées de volume et de DRC DOIVENT être interprétées et appliquées conformément au profil de contrôle de la plage dynamique MPEG-D DRC au niveau 1.
- [C-3-2] Le décodeur DOIT se comporter conformément à la configuration définie avec les clés
android.media.MediaFormat
suivantes :KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
etKEY_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 du profil de contrôle de la plage dynamique ISO/CEI 23003-4.
Si ISO/IEC 23003-4 est pris en charge et si les métadonnées ISO/IEC 23003-4 et ISO/IEC 14496-3 sont présentes dans un flux de bits décodé, alors:
- Les métadonnées ISO/CEI 23003-4 doivent prévaloir.
Tous les décodeurs audio DOIVENT être compatibles avec la sortie des éléments suivants:
- [C-6-1] Frames audio PCM 16 bits avec ordre d'octets natif via l'API
android.media.MediaCodec
.
Si les implémentations d'appareils prennent en charge le décodage des tampons d'entrée AAC des flux multicanaux (c'est-à-dire plus de deux canaux) en PCM via le décodeur audio AAC par défaut de l'API android.media.MediaCodec
, les éléments suivants DOIVENT être pris en charge:
- [C-7-1] DOIT pouvoir être configuré par l'application qui utilise le décodage avec la clé
KEY_MAX_OUTPUT_CHANNEL_COUNT
pour contrôler si le contenu est converti en stéréo (lorsque vous utilisez une valeur de 2) ou s'il est diffusé à l'aide du nombre de canaux natif (lorsque vous utilisez une valeur égale ou supérieure à ce nombre). Par exemple, une valeur de 6 ou plus configure un décodeur pour qu'il génère six canaux lorsqu'il reçoit un contenu 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 la clé
KEY_CHANNEL_MASK
, à l'aide des constantesandroid.media.AudioFormat
(par exemple,CHANNEL_OUT_5POINT1
).
Si les implémentations de l'appareil prennent en charge des décodeurs audio autres que le décodeur audio AAC par défaut et sont capables de produire du contenu audio multicanal (c'est-à-dire plus de deux canaux) lorsqu'elles reçoivent du contenu multicanal compressé, procédez comme suit:
- [C-SR-2] Il est FORTEMENT RECOMMANDÉ que le décodeur puisse être configuré par l'application qui utilise le décodage avec la clé
KEY_MAX_OUTPUT_CHANNEL_COUNT
pour contrôler si le contenu est converti en stéréo (lorsque vous utilisez une valeur de 2) ou s'il est diffusé à l'aide du nombre de canaux natif (lorsque vous utilisez une valeur égale ou supérieure à ce nombre). Par exemple, une valeur de 6 ou plus configure un décodeur pour qu'il génère six canaux lorsqu'il reçoit un contenu 5.1. - [C-SR-3] Lors du décodage, il est FORTEMENT RECOMMANDÉ que le décodeur annonce le masque de canaux utilisé sur le format de sortie avec la clé
KEY_CHANNEL_MASK
, à l'aide des constantes android.media.AudioFormat (par exemple :CHANNEL_OUT_5POINT1
).
5.1.3. Détails des codecs audio
Format/Codec | Détails | Types de fichiers/Formats de conteneurs compatibles |
---|---|---|
Profil MPEG-4 AAC (AAC LC) |
Compatibilité avec les contenus mono/stéréo/5.0/5.1 avec des taux d'échantillonnage standards de 8 à 48 kHz. |
|
Profil MPEG-4 HE AAC (AAC+) | Compatibilité avec les contenus mono/stéréo/5.0/5.1 avec des taux d'échantillonnage standards de 16 à 48 kHz. |
|
Profil MPEG-4 HE AACv2 (AAC+ amélioré) |
Compatibilité avec les contenus mono/stéréo/5.0/5.1 avec des taux d'échantillonnage standards de 16 à 48 kHz. |
|
AAC ELD (AAC à faible latence amélioré) | Compatibilité avec le contenu mono/stéréo avec des taux d'échantillonnage standards de 16 à 48 kHz. |
|
USAC | Compatibilité avec le contenu mono/stéréo avec des taux d'échantillonnage standards compris entre 7,35 kHz et 48 kHz. | MPEG-4 (.mp4, .m4a) |
AMR-NB | 4,75 à 12,2 kbit/s échantillonnés à 8 kHz | 3GPP (.3gp) |
AMR-WB | 9 débits de 6,60 kbit/s à 23,85 kbit/s échantillonnés à 16 kHz, comme défini dans la documentation sur le codec AMR-WB (Adaptive Multi-Rate – Wideband Speech Codec) | 3GPP (.3gp) |
FLAC | Pour l'encodeur et le décodeur: au moins les modes mono et stéréo DOIVENT être compatibles. Les taux d'échantillonnage jusqu'à 192 kHz DOIVENT être pris en charge. La résolution 16 bits et 24 bits DOIT être prise en charge. La gestion des données audio FLAC 24 bits DOIT être disponible avec la configuration audio à virgule flottante. |
|
MP3 | Mono/Stéréo 8-320 kbit/s constant (CBR) ou débit variable (VBR) |
|
MIDI | Types MIDI 0 et 1 Versions 1 et 2 de DLS XMF et Mobile XMF. Compatibilité avec les formats de sonnerie RTTTL/RTX, OTA et iMelody |
|
Vorbis | 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. Encoding: 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. |
|
PCM/WAVE | Le codec PCM DOIT prendre en charge le PCM linéaire 16 bits et le format à virgule flottante 16 bits. L'extracteur WAVE doit prendre en charge les formats PCM linéaire 16 bits, 24 bits et 32 bits, ainsi que les formats à virgule flottante 32 bits (taux jusqu'à la limite du matériel). Les taux d'échantillonnage doivent être compatibles entre 8 kHz et 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. |
|
5.1.4. Encodage d'image
Pour en savoir plus, consultez la section 5.1.6. "Détails des codecs d'image".
Les implémentations d'appareils DOIVENT prendre en charge l'encodage des images suivantes:
- [C-0-1] JPEG
- [C-0-2] PNG
- [C-0-3] WebP
- [C-0-4] AVIF
- Les appareils doivent être compatibles avec
BITRATE_MODE_CQ
et le profil de référence.
- Les appareils doivent être compatibles avec
Si les implémentations de l'appareil sont compatibles avec l'encodage HEIC via android.media.MediaCodec
pour le type de contenu multimédia MIMETYPE_IMAGE_ANDROID_HEIC
, elles:
- [C-1-1] DOIT fournir un codec d'encodeur HEVC accéléré par matériel compatible avec le mode de contrôle du débit
BITRATE_MODE_CQ
, le profilHEVCProfileMainStill
et la taille de frame de 512 x 512 px.
5.1.5. Décodage d'image
Pour en savoir plus, consultez la section 5.1.6. "Détails des codecs d'image".
Les implémentations d'appareils DOIVENT prendre en charge le décodage de l'encodage d'image suivant:
- [C-0-1] JPEG
- [C-0-2] GIF
- [C-0-3] PNG
- [C-0-4] BMP
- [C-0-5] WebP
- [C-0-6] Brut
- [C-0-7] AVIF (profil de référence)
Si les implémentations de l'appareil sont compatibles avec le décodage vidéo HEVC, elles:
- [C-1-1] DOIT prendre en charge le décodage des images HEIF (HEIC).
Décodeurs d'images compatibles avec un format à profondeur de bits élevée (9 bits ou plus par canal):
- [C-2-1] DOIT prendre en charge la sortie d'un format équivalent 8 bits si l'application le demande, par exemple via la configuration
ARGB_8888
deandroid.graphics.Bitmap
.
5.1.6. Détails des codecs d'image
Format/Codec | Détails | Types de fichiers/Formats de conteneurs compatibles |
---|---|---|
JPEG | Base+progressive | JPEG (.jpg) |
GIF | GIF (.gif) | |
PNG | PNG (.png) | |
BMP | BMP (.bmp) | |
WebP | WebP (.webp) | |
Brute | ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw) | |
HEIF | Image, collection d'images, séquence d'images | HEIF (.heif), HEIC (.heic) |
AVIF (profil de référence) | Profil de référence pour l'image, la collection d'images et 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 le format de couleur flexible YUV420 8:8:8 (
COLOR_FormatYUV420Flexible
) viaCodecCapabilities
.[C-SR-1] IL EST FORTEMENT RECOMMANDÉ de prendre en charge le format de couleur RGB888 pour le mode Surface d'entrée.
[C-1-3] DOIT prendre en charge au moins un format de couleur YUV420 8:8:8 planaire ou semi-planaire:
COLOR_FormatYUV420PackedPlanar
(équivalent àCOLOR_FormatYUV420Planar
) ouCOLOR_FormatYUV420PackedSemiPlanar
(équivalent àCOLOR_FormatYUV420SemiPlanar
). Il est FORTEMENT RECOMMANDÉ de prendre en charge les deux.
5.1.7. Codecs vidéo
- Pour une qualité acceptable du streaming vidéo Web et des services de visioconférence, les implémentations d'appareils DOIVENT utiliser un codec VP8 matériel qui répond aux exigences.
Si les implémentations de l'appareil incluent un décodeur ou un encodeur vidéo:
[C-1-1] Les codecs vidéo DOIVENT prendre en charge des tailles de tampon d'octets de sortie et d'entrée qui peuvent accueillir le plus grand frame compressé et non compressé possible, comme dicté par la norme et la configuration, mais aussi ne pas surallouer.
[C-1-2] Les encodeurs et les décodeurs vidéo DOIVENT prendre en charge les formats de couleurs flexibles YUV420 8:8:8 (
COLOR_FormatYUV420Flexible
) jusqu'àCodecCapabilities
.[C-1-3] Les encodeurs et décodeurs vidéo DOIVENT prendre en charge au moins un format de couleur YUV420 8:8:8 planaire ou semi-planaire:
COLOR_FormatYUV420PackedPlanar
(équivalent àCOLOR_FormatYUV420Planar
) ouCOLOR_FormatYUV420PackedSemiPlanar
(équivalent àCOLOR_FormatYUV420SemiPlanar
). Il est FORTEMENT RECOMMANDÉ de prendre en charge les deux.[C-SR-1] Il est FORTEMENT RECOMMANDÉ que les encodeurs et les décodeurs vidéo soient compatibles avec au moins un format de couleur YUV420 8:8:8 planaire ou semi-planaire optimisé matériellement (YV12, NV12, NV21 ou format optimisé par le fournisseur équivalent).
[C-1-5] Les décodeurs vidéo compatibles avec un format à profondeur de bits élevée (9 bits ou plus par canal) DOIVENT être compatibles avec la sortie d'un format équivalent à 8 bits si l'application le demande. Cela doit être reflété par la prise en charge d'un format de couleur YUV420 8:8:8 via
android.media.MediaCodecInfo
.
Si les implémentations d'appareils annoncent la compatibilité avec le profil HDR via Display.HdrCapabilities
, elles:
- [C-2-1] DOIT être compatible avec l'analyse et la gestion des métadonnées statiques HDR.
Si les implémentations d'appareils annoncent la prise en charge de l'actualisation intra via FEATURE_IntraRefresh
dans la classe MediaCodecInfo.CodecCapabilities
, elles:
- [C-3-1] DOIT prendre en charge les périodes d'actualisation comprises entre 10 et 60 images et fonctionner avec précision dans les 20% de la période d'actualisation configurée.
Sauf indication contraire de l'application à l'aide de la clé de format KEY_COLOR_FORMAT
, les implémentations de décodeur vidéo:
- [C-4-1] Le format de couleur optimisé pour l'affichage matériel doit être utilisé par défaut si la sortie est configurée à l'aide de Surface.
- [C-4-2] DOIT utiliser par défaut un format de couleur YUV420 8:8:8 optimisé pour la lecture par CPU si la sortie Surface n'est pas utilisée.
5.1.8. Liste des codecs vidéo
Format/Codec | Détails | Types de fichiers/Formats de conteneurs compatibles |
---|---|---|
H.263 |
|
|
H.264 AVC | Pour en savoir plus, consultez les sections 5.2 et 5.3. |
|
H.265 HEVC | Pour en savoir plus, consultez la section 5.3. |
|
MPEG-2 | Main Profile |
|
MPEG-4 SP |
|
|
VP8 | Pour en savoir plus, consultez les sections 5.2 et 5.3. |
|
VP9 | Pour en savoir plus, consultez la section 5.3. |
|
AV1 | Pour en savoir plus, consultez les sections 5.2 et 5.3. |
|
5.1.9. Sécurité des codecs multimédias
Les implémentations d'appareils DOIVENT garantir la conformité aux fonctionnalités de sécurité des codecs multimédias, comme décrit ci-dessous.
Android est compatible avec OMX, une API d'accélération multimédia multiplate-forme, ainsi qu'avec Codec 2.0, une API d'accélération multimédia à faible coût.
Si les implémentations d'appareils sont compatibles avec les contenus multimédias, elles:
- [C-1-1] DOIT prendre en charge les codecs multimédias via les API OMX ou Codec 2.0 (ou les deux), comme dans le Projet Android Open Source, et ne doit pas désactiver ni contourner les protections de sécurité. Cela ne signifie pas spécifiquement que chaque codec DOIT utiliser l'API OMX ou Codec 2.0, mais seulement que la prise en charge d'au moins l'une de ces API DOIT être disponible, et que la prise en charge des API disponibles DOIT inclure les protections de sécurité présentes.
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure la prise en charge de l'API Codec 2.0.
Si les implémentations de l'appareil ne sont pas compatibles avec l'API Codec 2.0, elles:
- [C-2-1] DOIT inclure le codec logiciel OMX correspondant du projet Open Source Android (s'il est disponible) pour chaque format et type multimédia (encodeur ou décodeur) compatible avec l'appareil.
- [C-2-2] Codecs dont le nom commence par "OMX.google." DOIT être basé sur le code source du projet Android Open Source.
- [C-SR-2] Il est FORTEMENT RECOMMANDÉ que les codecs logiciels OMX s'exécutent dans un processus de codec qui n'a pas accès aux pilotes matériels autres que les mappeurs de mémoire.
Si les implémentations de l'appareil sont compatibles avec l'API Codec 2.0, elles:
- [C-3-1] DOIT inclure le codec logiciel Codec 2.0 correspondant du projet Open Source Android (s'il est disponible) pour chaque format et type multimédia (encodeur ou décodeur) compatible avec l'appareil.
- [C-3-2] DOIT héberger les codecs logiciels Codec 2.0 dans le processus de codec logiciel tel que fourni dans le projet Android Open Source pour permettre d'accorder un accès plus précis aux codecs logiciels.
- [C-3-3] Codecs dont le nom commence par "c2.android." DOIT être basé sur le code source du projet Android Open Source.
5.1.10. Caractérisation des codecs multimédias
Si les implémentations d'appareils sont compatibles avec les codecs multimédias, elles:
- [C-1-1] DOIT renvoyer les valeurs correctes de la caractérisation du codec multimédia via l'API
MediaCodecInfo
.
En particulier :
- [C-1-2] Codecs dont le nom commence par "OMX." DOIVENT utiliser les API OMX et avoir des noms conformes aux consignes de dénomination OMX IL.
- [C-1-3] Codecs dont le nom commence par "c2." DOIVENT utiliser l'API Codec 2.0 et avoir des noms conformes aux consignes de dénomination Codec 2.0 pour Android.
- [C-1-4] Codecs dont le nom commence par "OMX.google." ou "c2.android." NE DOIT PAS être caractérisé comme fournisseur ou comme accélération matérielle.
- [C-1-5] Les codecs exécutés dans un processus de codec (fournisseur ou système) ayant accès à des pilotes matériels autres que les alloueurs et les mappeurs de mémoire NE DOIVENT PAS être caractérisés comme des logiciels uniquement.
- [C-1-6] Les codecs qui ne figurent pas dans le projet Android Open Source ou qui ne sont pas basés sur le code source de ce projet DOIVENT être caractérisés comme des fournisseurs.
- [C-1-7] Les codecs qui utilisent l'accélération matérielle DOIVENT être caractérisés comme tels.
- [C-1-8] Les noms de codecs NE DOIVENT PAS être trompeurs. Par exemple, les codecs nommés "décodeurs" DOIVENT prendre en charge le décodage, et ceux nommés "encodeurs" DOIVENT prendre en charge l'encodage. Les codecs dont le nom contient des formats multimédias DOIVENT prendre en charge ces formats.
Si les implémentations de l'appareil 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 réalisables pour les tailles suivantes, si elles sont compatibles avec le codec:
SD (basse qualité) | SD (haute qualité) | HD – 720p | HD – 1080p | UHD | |
---|---|---|---|---|---|
Résolution vidéo |
|
|
|
1 920 x 1 080 px (à l'exception de MPEG4 et AV1) | 3 840 x 2 160 px (HEVC, VP9, AV1) |
- [C-2-2] Les codecs vidéo caractérisés comme accélérés matériellement DOIVENT publier des informations sur les points de performance. Ils DOIVENT chacun lister tous les points de performances standards compatibles (listés dans l'API
PerformancePoint
), sauf s'ils sont couverts par un autre point de performances standards compatible. - De plus, ils DOIVENT publier des points de performance étendus s'ils prennent en charge des performances vidéo soutenues autres que l'une des performances standards listées.
5.2. Encodage vidéo
Si les implémentations de l'appareil sont compatibles avec un encodeur vidéo et le rendent disponible pour les applications tierces, et si vous définissez
MediaFormat.KEY_BITRATE_MODE
sur BITRATE_MODE_VBR
afin que l'encodeur fonctionne en mode débit variable, alors, à condition que cela n'ait pas d'incidence sur le seuil de qualité minimal, le débit encodé :
- NE DOIT PAS dépasser 15% du débit entre les intervalles intraframe (I-frame) sur une fenêtre glissante.
- NE DOIT PAS dépasser 100% du débit sur une fenêtre glissante de 1 seconde.
Si les implémentations de l'appareil sont compatibles avec un encodeur vidéo et le rendent disponible pour les applications tierces, et si elles définissent MediaFormat.KEY_BITRATE_MODE
sur BITRATE_MODE_CBR
pour que l'encodeur fonctionne en mode débit constant, le débit encodé:
- [C-SR-2] Il est FORTEMENT RECOMMANDÉ de ne pas dépasser 15% du débit cible sur une fenêtre glissante de 1 seconde.
Si les implémentations d'appareils incluent un écran intégré dont la diagonale mesure au moins 6,3 cm, ou incluent un port de sortie vidéo ou déclarent la prise en charge d'une caméra via le flag de fonctionnalité android.hardware.camera.any
, elles:
- [C-1-1] DOIT inclure la prise en charge d'au moins l'un des encodeurs vidéo VP8 ou H.264, et le mettre à la disposition des applications tierces.
- DOIT être compatible avec les encodeurs vidéo VP8 et H.264, et les mettre à la disposition des applications tierces.
Si les implémentations de l'appareil sont compatibles avec l'un des encodeurs vidéo H.264, VP8, VP9 ou HEVC et les mettent à la disposition des applications tierces, elles:
- [C-2-1] DOIT prendre en charge les débits configurables dynamiquement.
- DOIT prendre en charge les fréquences d'images variables, où l'encodeur vidéo DOIT déterminer la durée instantanée des images en fonction des codes temporels des tampons d'entrée et allouer son bucket de bits en fonction de cette durée d'image.
Si les implémentations d'appareils sont compatibles avec l'encodeur vidéo MPEG-4 SP et le rendent disponible pour les applications tierces, elles:
- DOIT prendre en charge les débits configurables de manière dynamique pour l'encodeur compatible.
Si les implémentations d'appareils fournissent des encodeurs vidéo ou d'image accélérés par matériel, et prennent en charge une ou plusieurs caméras matérielles connectées ou enfichables exposées via les API android.camera
:
- [C-4-1] Tous les encodeurs vidéo et d'image avec accélération matérielle DOIVENT prendre en charge l'encodage des images de la ou des caméras matérielles.
- DOIT prendre en charge l'encodage des images de la ou des caméras matérielles via tous les encodeurs vidéo ou d'image.
Si les implémentations d'appareils fournissent un encodage HDR, elles:
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ de fournir un plug-in pour l'API de transcodage fluide afin de convertir le format HDR au format SDR.
5.2.1. H.263
Si les implémentations d'appareils sont compatibles avec les encodeurs H.263 et les rendent disponibles pour les applications tierces, elles:
- [C-1-1] DOIT prendre en charge la résolution QCIF (176 x 144) à l'aide du profil de référence de niveau 45. La résolution SQCIF est facultative.
5.2.2. H.264
Si les implémentations de l'appareil sont compatibles avec le codec H.264, elles:
- [C-1-1] DOIT prendre en charge le niveau 3 du profil de référence. Toutefois, la prise en charge de l'ordre des tranches arbitraire (ASO), de l'ordre des macroblocs flexible (FMO) et des tranches redondantes (RS) est FACULTATIVE. De plus, pour assurer la compatibilité avec d'autres appareils Android, il est RECOMMANDÉ que les encodeurs n'utilisent pas ASO, FMO et RS pour le profil de référence.
- [C-1-2] DOIT prendre en charge les profils d'encodage vidéo SD (définition standard) du tableau suivant.
- DOIT prendre en charge le profil principal de niveau 4.
- DOIT prendre en charge les profils d'encodage vidéo HD (haute définition) comme indiqué dans le tableau suivant.
Si les implémentations d'appareils signalent la prise en charge de l'encodage H.264 pour les vidéos en résolution 720p ou 1080p via les API multimédias, elles:
- [C-2-1] DOIT prendre en charge les profils d'encodage du tableau suivant.
SD (basse qualité) | SD (haute qualité) | HD – 720p | HD – 1080p | |
---|---|---|---|---|
Résolution vidéo | 320 x 240 px | 720 x 480 px | 1 280 x 720 px | 1 920 x 1 080 px |
Fréquence d'images de la vidéo | 20 fps | 30 ips | 30 ips | 30 ips |
Débit vidéo | 384 kbit/s | 2 Mbit/s | 4 Mbit/s | 10 Mbit/s |
5.2.3. VP8
Si les implémentations de l'appareil sont compatibles avec le codec VP8, elles:
- [C-1-1] DOIT prendre en charge les profils d'encodage vidéo SD.
- DOIT prendre en charge les profils d'encodage vidéo HD (haute définition) suivants.
- [C-1-2] DOIT être compatible avec l'écriture de fichiers WebM Matroska.
- DOIT fournir un codec VP8 matériel conforme aux exigences de codage matériel RTC du projet WebM, afin de garantir une qualité acceptable des services de streaming vidéo et de visioconférence sur le Web.
Si les implémentations d'appareils indiquent la prise en charge de l'encodage VP8 pour les vidéos en résolution 720p ou 1080p via les API multimédias, elles:
- [C-2-1] DOIT prendre en charge les profils d'encodage du tableau suivant.
SD (basse qualité) | SD (haute qualité) | HD – 720p | HD – 1080p | |
---|---|---|---|---|
Résolution vidéo | 320 x 180 px | 640 x 360 px | 1 280 x 720 px | 1 920 x 1 080 px |
Fréquence d'images de la vidéo | 30 ips | 30 ips | 30 ips | 30 ips |
Débit vidéo | 800 Kbit/s | 2 Mbit/s | 4 Mbit/s | 10 Mbit/s |
5.2.4. VP9
Si les implémentations d'appareils sont compatibles avec le codec VP9, elles:
- [C-1-2] DOIT être compatible avec le profil 0 de niveau 3.
- [C-1-1] DOIT être compatible avec l'écriture de fichiers WebM Matroska.
- [C-1-3] DOIT générer des données CodecPrivate.
- DOIT prendre en charge les profils de décodage HD indiqués dans le tableau suivant.
- [C-SR-1] Il est vivement recommandé de prendre en charge les profils de décodage HD, comme indiqué dans le tableau suivant, en présence d'un encodeur matériel.
SD | HD – 720p | HD – 1080p | UHD | |
---|---|---|---|---|
Résolution vidéo | 720 x 480 px | 1 280 x 720 px | 1 920 x 1 080 px | 3 840 x 2 160 px |
Fréquence d'images de la vidéo | 30 ips | 30 ips | 30 ips | 30 ips |
Débit vidéo | 1,6 Mbit/s | 4 Mbit/s | 5 Mbit/s | 20 Mbit/s |
Si les implémentations d'appareils prétendent prendre en charge le profil 2 ou le profil 3 via les API Media:
- La prise en charge du format 12 bits est FACULTATIVE.
5.2.5. H.265
Si les implémentations de l'appareil sont compatibles avec le codec H.265, elles:
- [C-1-1] DOIT prendre en charge le profil principal de niveau 3 jusqu'à une résolution de 512 x 512.
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge le profil SD 720 x 480 et les profils d'encodage HD, comme indiqué dans le tableau suivant s'il existe un encodeur matériel.
SD | HD – 720p | HD – 1080p | UHD | |
---|---|---|---|---|
Résolution vidéo | 720 x 480 px | 1 280 x 720 px | 1 920 x 1 080 px | 3 840 x 2 160 px |
Fréquence d'images de la vidéo | 30 ips | 30 ips | 30 ips | 30 ips |
Débit vidéo | 1,6 Mbit/s | 4 Mbit/s | 5 Mbit/s | 20 Mbit/s |
5.2.6. AV1
Si les implémentations d'appareils sont compatibles avec le codec AV1, elles:
- [C-1-1] DOIT prendre en charge le profil principal, y compris le contenu 8 bits et 10 bits.
[C-1-2] DOIT publier des données sur les performances, c'est-à-dire des données de rapport sur les performances via les API
getSupportedFrameRatesFor()
ougetSupportedPerformancePoints()
pour les résolutions compatibles indiquées dans le tableau ci-dessous.[C-1-3] DOIT accepter les métadonnées HDR et les transmettre au flux de bits
Si l'encodeur AV1 est accéléré par le matériel, il:
- [C-2-1] DOIT prendre en charge le profil d'encodage HD1080p du tableau ci-dessous, y compris:
SD | HD – 720p | HD – 1080p | UHD | |
---|---|---|---|---|
Résolution vidéo | 720 x 480 px | 1 280 x 720 px | 1 920 x 1 080 px | 3 840 x 2 160 px |
Fréquence d'images de la vidéo | 30 ips | 30 ips | 30 ips | 30 ips |
Débit vidéo | 5 Mbit/s | 8 Mbit/s | 16 Mbit/s | 50 Mbit/s |
5.3. Décodage vidéo
Si les implémentations de l'appareil sont compatibles avec les codecs VP8, VP9, H.264 ou H.265, elles:
- [C-1-1] DOIT prendre en charge la résolution vidéo dynamique et le changement de fréquence d'images via les API Android standards dans le même flux pour tous les codecs VP8, VP9, H.264 et H.265 en temps réel et jusqu'à la résolution maximale prise en charge par chaque codec sur l'appareil.
5.3.1. MPEG-2
Si les implémentations d'appareils sont compatibles avec les décodeurs MPEG-2, elles:
- [C-1-1] DOIT prendre en charge le profil principal de niveau élevé.
5.3.2. H.263
Si les implémentations d'appareils sont compatibles avec les décodeurs H.263, elles:
- [C-1-1] DOIT être compatible avec le profil de référence de niveau 30 (résolutions CIF, QCIF et SQCIF à 30 images/s et 384 kbit/s) et de niveau 45 (résolutions QCIF et SQCIF à 30 images/s et 128 kbit/s).
5.3.3. MPEG-4
Si les implémentations d'appareils sont équipées de décodeurs MPEG-4:
- [C-1-1] DOIT être compatible avec le profil simple de niveau 3.
5.3.4. H.264
Si les implémentations d'appareils sont compatibles avec les décodeurs H.264, elles:
- [C-1-1] DOIT prendre en charge le profil principal de niveau 3.1 et le profil de référence. La prise en charge de l'ordre des tranches arbitraire (ASO, Arbitrary Slice Ordering), de l'ordre des macroblocs flexible (FMO, Flexible Macroblock Ordering) et des tranches redondantes (RS, Redundant Slices) est FACULTATIVE.
- [C-1-2] DOIT être capable de décoder les vidéos avec les profils SD (Standard Definition) listés dans le tableau suivant et encodés avec le profil de référence et le profil principal de niveau 3.1 (y compris 720p30).
- DOIT être capable de décoder les vidéos avec les profils HD (haute définition) comme indiqué dans le tableau suivant.
Si la hauteur indiquée par la méthode Display.getSupportedModes()
est égale ou supérieure à la résolution vidéo, les implémentations de l'appareil:
- [C-2-1] DOIT prendre en charge les profils de décodage vidéo HD 720p indiqués dans le tableau suivant.
- [C-2-2] DOIT prendre en charge les profils de décodage vidéo HD 1080p indiqués dans le tableau suivant.
SD (basse qualité) | SD (haute qualité) | HD – 720p | HD – 1080p | |
---|---|---|---|---|
Résolution vidéo | 320 x 240 px | 720 x 480 px | 1 280 x 720 px | 1 920 x 1 080 px |
Fréquence d'images de la vidéo | 30 ips | 30 ips | 60 FPS | 30 FPS (60 FPS pour la télévision) |
Débit vidéo | 800 Kbit/s | 2 Mbit/s | 8 Mbit/s | 20 Mbit/s |
5.3.5. H.265 (HEVC)
Si les implémentations de l'appareil sont compatibles avec le codec H.265, elles:
- [C-1-1] DOIT prendre en charge le niveau 3 du profil principal et les profils de décodage vidéo SD, comme indiqué dans le tableau suivant.
- DOIT prendre en charge les profils de décodage HD indiqués dans le tableau suivant.
- [C-1-2] DOIT être compatible avec les profils de décodage HD indiqués dans le tableau suivant en cas de présence d'un décodeur matériel.
Si la hauteur indiquée par la méthode Display.getSupportedModes()
est égale ou supérieure à la résolution vidéo, procédez comme suit:
- [C-2-1] Les implémentations d'appareils DOIVENT prendre en charge au moins l'un des formats de décodage H.265 ou VP9 des profils 720p, 1080p et UHD.
SD (basse qualité) | SD (haute qualité) | HD – 720p | HD – 1080p | UHD | |
---|---|---|---|---|---|
Résolution vidéo | 352 x 288 px | 720 x 480 px | 1 280 x 720 px | 1 920 x 1 080 px | 3 840 x 2 160 px |
Fréquence d'images de la vidéo | 30 ips | 30 ips | 30 ips | 30/60 FPS (60 FPS pour les téléviseurs avec décodage matériel H.265) | 60 FPS |
Débit vidéo | 600 Kbits/s | 1,6 Mbit/s | 4 Mbit/s | 5 Mbit/s | 20 Mbit/s |
Si les implémentations d'appareils prétendent être compatibles avec un profil HDR via les API multimédias:
- [C-3-1] Les implémentations d'appareils DOIVENT accepter les métadonnées HDR requises de l'application, ainsi que permettre d'extraire et de générer les métadonnées HDR requises à partir du flux de bits et/ou du conteneur.
- [C-3-2] Les implémentations d'appareils DOIVENT afficher correctement le contenu HDR sur l'écran de l'appareil ou sur un port de sortie vidéo standard (par exemple, (HDMI, par exemple).
5.3.6. VP8
Si les implémentations de l'appareil sont compatibles avec le codec VP8, elles:
- [C-1-1] DOIT prendre en charge les profils de décodage SD du tableau suivant.
- DOIT utiliser un codec VP8 matériel qui répond aux exigences.
- DOIT prendre en charge les profils de décodage HD du tableau suivant.
Si la hauteur indiquée par la méthode Display.getSupportedModes()
est égale ou supérieure à la résolution vidéo, procédez comme suit:
- [C-2-1] Les implémentations d'appareils DOIVENT prendre en charge les profils 720p du tableau suivant.
- [C-2-2] Les implémentations d'appareils DOIVENT prendre en charge les profils 1080p du tableau suivant.
SD (basse qualité) | SD (haute qualité) | HD – 720p | HD – 1080p | |
---|---|---|---|---|
Résolution vidéo | 320 x 180 px | 640 x 360 px | 1 280 x 720 px | 1 920 x 1 080 px |
Fréquence d'images de la vidéo | 30 ips | 30 ips | 30 FPS (60 FPS pour la télévision) | 30 (60 images par secondeTélévision) |
Débit vidéo | 800 Kbit/s | 2 Mbit/s | 8 Mbit/s | 20 Mbit/s |
5.3.7. VP9
Si les implémentations d'appareils sont compatibles avec le codec VP9, elles:
- [C-1-1] DOIT prendre en charge les profils de décodage vidéo SD, comme indiqué dans le tableau suivant.
- DOIT prendre en charge les profils de décodage HD indiqués dans le tableau suivant.
Si les implémentations de l'appareil 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é dans le tableau suivant.
Si la hauteur indiquée par la méthode Display.getSupportedModes()
est égale ou supérieure à la résolution vidéo, procédez comme suit:
- [C-3-1] Les implémentations d'appareils DOIVENT prendre en charge au moins l'un des décodages VP9 ou H.265 des profils 720p, 1080p et UHD.
SD (basse qualité) | SD (haute qualité) | HD – 720p | HD – 1080p | UHD | |
---|---|---|---|---|---|
Résolution vidéo | 320 x 180 px | 640 x 360 px | 1 280 x 720 px | 1 920 x 1 080 px | 3 840 x 2 160 px |
Fréquence d'images de la vidéo | 30 ips | 30 ips | 30 ips | 30 FPS (60 FPS sur les téléviseurs avec décodage matériel du format VP9) | 60 FPS |
Débit vidéo | 600 Kbits/s | 1,6 Mbit/s | 4 Mbit/s | 5 Mbit/s | 20 Mbit/s |
Si les implémentations de l'appareil prétendent être compatibles avec VP9Profile2
ou VP9Profile3
via les API multimédias CodecProfileLevel:
- La prise en charge du format 12 bits est FACULTATIVE.
Si les implémentations de l'appareil prétendent prendre en charge un profil HDR (VP9Profile2HDR
, VP9Profile2HDR10Plus
, VP9Profile3HDR
, VP9Profile3HDR10Plus
) via les 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) de 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 sur l'écran de l'appareil ou sur un port de sortie vidéo standard (par exemple, (HDMI, par exemple).
5.3.8. Dolby Vision
Si les implémentations d'appareils déclarent la prise en charge du décodeur Dolby Vision via HDR_TYPE_DOLBY_VISION
, elles:
- [C-1-1] DOIT fournir un extracteur compatible avec Dolby Vision.
Début des nouvelles exigences pour Android 15
- [C-1-2] DOIT afficher correctement le contenu Dolby Vision soit sur l'écran de l'appareil, soit sur un écran externe connecté via un port de sortie vidéo standard (par exemple, (HDMI, par exemple).
Fin des nouvelles exigences
- [C-1-3] L'ID de piste des couches de base rétrocompatibles (le cas échéant) DOIT être identique à celui de la couche Dolby Vision combinée.
5.3.9. AV1
Si les implémentations d'appareils sont compatibles avec le codec AV1 et le rendent disponible pour les applications tierces, elles:
- [C-1-1] DOIT prendre en charge le profil principal, y compris le contenu 8 bits et 10 bits.
Si les implémentations d'appareils sont compatibles avec le codec AV1 avec un décodeur accéléré par matériel, elles:
- [C-2-1] DOIT être en mesure de décoder au moins les profils de décodage vidéo HD 720p du tableau ci-dessous lorsque la hauteur indiquée par la méthode
Display.getSupportedModes()
est égale ou supérieure à 720p. - [C-2-2] DOIT être en mesure de décoder au moins les profils de décodage vidéo HD 1080p du tableau ci-dessous lorsque la hauteur indiquée par la méthode
Display.getSupportedModes()
est égale ou supérieure à 1080p.
SD | HD – 720p | HD – 1080p | UHD | |
---|---|---|---|---|
Résolution vidéo | 720 x 480 px | 1 280 x 720 px | 1 920 x 1 080 px | 3 840 x 2 160 px |
Fréquence d'images de la vidéo | 30 ips | 30 ips | 30 ips | 30 ips |
Débit vidéo | 5 Mbit/s | 8 Mbit/s | 16 Mbit/s | 50 Mbit/s |
Si les implémentations d'appareils sont compatibles avec le profil HDR via les API multimédias, elles:
- [C-3-1] DOIT prendre en charge l'extraction et la sortie des métadonnées HDR à partir du flux de bits et/ou du conteneur.
- [C-3-2] DOIT afficher correctement le contenu HDR sur l'écran de l'appareil ou sur un port de sortie vidéo standard (par exemple, HDMI).
5.4. Enregistrement audio
Bien que certaines des exigences décrites dans cette section soient listées comme "DÉSIRABLE" depuis Android 4.3, la définition de la compatibilité pour les futures versions prévoit de les remplacer par "OBLIGATOIRE". Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux respectent ces exigences listées comme "DOIT", sinon ils ne pourront pas être compatibles avec Android lors de la mise à niveau vers la future version.
5.4.1. Capture audio brute et informations sur le micro
Si les implémentations d'appareil déclarent android.hardware.microphone
, elles:
[C-1-1] DOIT autoriser la capture de contenu audio brut pour tout flux INPUT
AudioRecord
ouAAudio
ouvert avec succès. Les caractéristiques suivantes doivent être prises en charge au minimum:- Format:PCM linéaire, 16 bits
- Taux d'échantillonnage:8 000, 11 025, 16 000, 44 100 et 48 000 Hz
- Canaux:mono
- Sources audio:
DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
ouVOICE_PERFORMANCE
. Cela s'applique également aux préréglages de saisie équivalents dansAAudio
, par exempleAAUDIO_INPUT_PRESET_CAMCORDER
.
DOIT permettre la capture de contenu audio brut avec les caractéristiques suivantes:
- Format: PCM linéaire, 16 bits et 24 bits
- Taux d'échantillonnage: 8 000, 11 025, 16 000, 22 050, 24 000, 32 000, 44 100 et 48 000 Hz
- Canaux: autant de canaux que de micros sur l'appareil
[C-1-2] DOIT capturer à des taux d'échantillonnage supérieurs sans mise à l'échelle.
[C-1-3] DOIT inclure un filtre anticrénelage approprié lorsque les taux d'échantillonnage indiqués ci-dessus sont capturés avec un sous-échantillonnage.
DOIT permettre la capture de contenu audio brut en qualité radio AM et DVD, ce qui signifie que les caractéristiques suivantes doivent être respectées:
- 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 renseigner correctement les informations sur les micros disponibles sur l'appareil accessibles aux applications tierces via l'APIAudioManager.getMicrophones()
, pour AudioRecord actif à l'aide deMediaRecorder.AudioSources DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
ouVOICE_PERFORMANCE
. Si les implémentations d'appareils permettent de capturer du contenu audio brut en qualité radio AM et DVD, elles:[C-2-1] DOIT capturer sans mise à l'échelle à un format supérieur à 16 000:22 050 ou 44 100:48 000.
[C-2-2] DOIT inclure un filtre anticrénelage approprié pour tout suréchantillonnage ou sous-échantillonnage.
5.4.2. Enregistrer pour la reconnaissance vocale
Si les implémentations d'appareil déclarent android.hardware.microphone
, elles:
- [C-1-1] DOIT capturer la source audio
android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION
à l'un des taux d'échantillonnage, 44 100 et 48 000. - [C-1-2] DOIT, par défaut, désactiver tout traitement audio de réduction du bruit lors de l'enregistrement d'un flux audio à partir de la source audio
AudioSource.VOICE_RECOGNITION
. [C-1-3] DOIT, par défaut, désactiver tout contrôle automatique du gain lors de l'enregistrement d'un flux audio à partir de la source audio
AudioSource.VOICE_RECOGNITION
.DOIT présenter des caractéristiques d'amplitude par rapport à la fréquence à peu près plates dans la plage de fréquences moyennes: plus précisément, ±3 dB de 100 Hz à 4 000 Hz pour chaque micro utilisé pour enregistrer la source audio de reconnaissance vocale.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de présenter des niveaux d'amplitude dans la plage de fréquences basses: en particulier de ±20 dB de 30 Hz à 100 Hz par rapport à la plage de fréquences moyennes pour chaque microphone utilisé pour enregistrer la source audio de reconnaissance vocale.
[C-SR-2] Il est FORTEMENT RECOMMANDÉ de présenter des niveaux d'amplitude dans la plage de fréquences élevées: en particulier de ±30 dB de 4 000 Hz à 22 kHz par rapport à la plage de fréquences moyennes pour chaque microphone utilisé pour enregistrer la source audio de reconnaissance vocale.
DOIT définir la sensibilité d'entrée audio de sorte qu'une source de tonalité sinusoïdale de 1 000 Hz lue à un niveau de pression acoustique (SPL) de 90 dB (mesuré à côté du micro) produise une réponse idéale de 2 500 RMS dans une plage de 1 770 à 3 530 pour les échantillons 16 bits (ou -22,35 dB ± 3 dB à pleine échelle pour les échantillons à virgule flottante/double précision) pour chaque micro utilisé pour enregistrer la source audio de reconnaissance vocale.
DOIT enregistrer le flux audio de reconnaissance vocale de sorte que les niveaux d'amplitude PCM suivent de manière linéaire les variations du niveau de pression acoustique d'entrée sur une plage d'au moins 30 dB, de -18 dB à +12 dB par rapport à 90 dB SPL au niveau du micro.
DOIT enregistrer le flux audio de reconnaissance vocale avec un taux de distorsion harmonique totale (THD) inférieur à 1% pour 1 kHz à un niveau d'entrée de 90 dB SPL au niveau du micro.
Si les implémentations d'appareils déclarent des technologies android.hardware.microphone
et de suppression (réduction) du bruit optimisées pour la reconnaissance vocale, elles:
- [C-2-1] DOIT permettre de contrôler cet effet audio avec l'API
android.media.audiofx.NoiseSuppressor
. - [C-2-2] DOIT identifier de manière unique chaque implémentation de technologie de suppression du bruit via le champ
AudioEffect.Descriptor.uuid
.
5.4.3. Capture pour le redirignement de la lecture
La classe android.media.MediaRecorder.AudioSource
inclut la source audio REMOTE_SUBMIX
.
Si les implémentations d'appareils déclarent à la fois android.hardware.audio.output
et android.hardware.microphone
, elles:
[C-1-1] DOIT implémenter correctement la source audio
REMOTE_SUBMIX
afin que, lorsqu'une application utilise l'APIandroid.media.AudioRecord
pour enregistrer à partir de cette source audio, elle capture un mix de tous les flux audio, à l'exception des éléments suivants:AudioManager.STREAM_RING
AudioManager.STREAM_ALARM
AudioManager.STREAM_NOTIFICATION
5.4.4. Annulation de l'écho acoustique
Si les implémentations d'appareil déclarent android.hardware.microphone
, elles:
- DOIT implémenter une technologie d'annulation de l'écho acoustique (AEC) adaptée à la communication vocale et appliquée au chemin de capture lors de la capture à l'aide de
AudioSource.VOICE_COMMUNICATION
.
Si les implémentations d'appareils fournissent un système d'annulation de l'écho acoustique qui est inséré dans le chemin audio de capture lorsque AudioSource.VOICE_COMMUNICATION
est sélectionné, elles:
- [C-SR-1] Il est FORTEMENT_RECOMMANDÉ de déclarer cela via la méthode de l'API AcousticEchoCanceler AcousticEchoCanceler.isAvailable()
- [C-SR-2] sont FORTEMENT_RECOMMANDÉS pour permettre de contrôler cet effet audio avec l'API AcousticEchoCanceler.
- [C-SR-3] Il est FORTEMENT_RECOMMANDÉ d'identifier de manière unique chaque implémentation de la technologie AEC via le champ AudioEffect.Descriptor.uuid.
5.4.5. Capture simultanée
Si les implémentations d'appareils déclarent android.hardware.microphone
,elles DOIVENT implémenter la capture simultanée comme décrit dans ce document. Plus spécifiquement :
- [C-1-1] DOIT autoriser l'accès simultané au micro par un service d'accessibilité qui capture avec
AudioSource.VOICE_RECOGNITION
et au moins une application qui capture avec n'importe quelAudioSource
. - [C-1-2] DOIT autoriser l'accès simultané au micro par une application préinstallée qui détient un rôle d'Assistant et au moins une application de capture avec n'importe quel
AudioSource
, à l'exception deAudioSource.VOICE_COMMUNICATION
ouAudioSource.CAMCORDER
. - [C-1-3] DOIT couper le son de la capture audio pour toute autre application, à l'exception d'un service d'accessibilité, lorsqu'une application effectue une capture avec
AudioSource.VOICE_COMMUNICATION
ouAudioSource.CAMCORDER
. Toutefois, lorsqu'une application effectue une capture viaAudioSource.VOICE_COMMUNICATION
, une autre application peut capturer l'appel vocal s'il s'agit d'une application privilégiée (préinstallée) disposant de l'autorisationCAPTURE_AUDIO_OUTPUT
. - [C-1-4] Si deux applications ou plus effectuent une capture en même temps et si aucune d'elles n'a d'UI en superposition, celle qui a commencé la capture le plus récemment reçoit l'audio.
5.5. Lecture audio
Android permet aux applications de lire de l'audio via le périphérique de sortie audio, comme défini dans la section 7.8.2.
5.5.1. Lecture audio brute
Si les implémentations d'appareil déclarent android.hardware.audio.output
, elles:
[C-1-1] DOIT permettre la lecture de contenu audio brut avec les caractéristiques suivantes:
- Formats source: PCM linéaire, 16 bits, 8 bits, virgule flottante
- Chaînes: mono, stéréo, configurations multicanaux valides avec jusqu'à huit canaux
- Taux d'échantillonnage (en Hz) :
- 8 000, 11 025, 16 000, 22 050, 24 000, 32 000, 44 100 et 48 000 pour les configurations de canaux indiquées ci-dessus
- 96 000 Hz 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
, elles:
- [C-1-1] DOIT prendre en charge les implémentations
EFFECT_TYPE_EQUALIZER
etEFFECT_TYPE_LOUDNESS_ENHANCER
contrôlables via les sous-classes AudioEffectEqualizer
etLoudnessEnhancer
. - [C-1-2] DOIT prendre en charge l'implémentation de l'API de visualisation, qui peut être contrôlée via la classe
Visualizer
. - [C-1-3] DOIT prendre en charge l'implémentation
EFFECT_TYPE_DYNAMICS_PROCESSING
contrôlable via la sous-classe AudioEffectDynamicsProcessing
.
Début des nouvelles exigences pour Android 15
- [C-1-4] DOIT prendre en charge les effets audio avec entrée et sortie à virgule flottante, lorsque les résultats de l'effet sont renvoyés au pipeline audio du framework. Il s'agit des effets d'insertion ou d'aux typiques tels que l'égaliseur. Un comportement équivalent est fortement recommandé lorsque les résultats de l'effet ne sont pas visibles par le pipeline audio du framework (par exemple, les effets de post-traitement ou de déchargement).
Fin des nouvelles exigences
Début des nouvelles exigences pour Android 15
- [C-1-5] DOIT s'assurer que les effets audio sont compatibles avec plusieurs canaux jusqu'au nombre de canaux du mixeur, également appelé FCC_LIMIT, lorsque les résultats de l'effet sont renvoyés au pipeline audio du framework. Il s'agit des effets d'insertion ou d'auxiliaires standards, mais qui excluent les effets spéciaux tels que le downmix, l'upmix et les effets de spatialisation qui modifient le nombre de canaux. Un comportement équivalent est recommandé lorsque les effets ne sont pas visibles par le pipeline audio du framework (par exemple, les effets de post-traitement ou de déchargement).
Fin des nouvelles exigences
- DOIT prendre en charge les implémentations
EFFECT_TYPE_BASS_BOOST
,EFFECT_TYPE_ENV_REVERB
,EFFECT_TYPE_PRESET_REVERB
etEFFECT_TYPE_VIRTUALIZER
contrôlées via les sous-classesAudioEffect
BassBoost
,EnvironmentalReverb
,PresetReverb
etVirtualizer
. - [C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge les effets en virgule flottante et multicanaux.
5.5.3. Volume de sortie audio
Implémentations d'appareils automobiles:
- DOIT permettre d'ajuster le volume audio séparément pour chaque flux audio à l'aide du type de contenu ou de l'utilisation définis par AudioAttributes et de l'utilisation audio de la voiture telle que définie publiquement dans
android.car.CarAudioManager
.
5.5.4. Déchargement audio
Si les implémentations d'appareils sont compatibles avec la lecture de transfert audio, elles:
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ de couper le contenu audio sans coupure lu entre deux extraits du même format, comme spécifié par l'API AudioTrack gapless et le conteneur multimédia pour MediaPlayer.
5.6. Latence audio
La latence audio correspond au délai de transmission d'un signal audio dans un système. De nombreuses classes d'applications s'appuient sur des latences courtes pour obtenir des effets sonores en temps réel.
Aux fins de cette section, utilisez les définitions suivantes:
- latence de sortie ; Intervalle entre le moment où une application écrit un frame de données encodées en PCM et le moment où le son correspondant est présenté à l'environnement via un transducteur sur l'appareil ou que le signal quitte l'appareil via un port et peut être observé en externe.
- Latence de sortie à froid Temps écoulé entre le démarrage d'un flux de sortie et l'heure de présentation du premier frame en fonction des codes temporels, lorsque le système de sortie audio était inactif et éteint avant la requête.
- latence de sortie continue. La latence de sortie pour les frames suivants, une fois que l'appareil lit de l'audio.
- latence d'entrée ; Intervalle entre le moment où un son est présenté par l'environnement à l'appareil via un transducteur ou un signal sur l'appareil via un port et le moment où une application lit le frame correspondant de données codées PCM.
- perte d'entrée. Portion initiale d'un signal d'entrée inutilisable ou indisponible.
- Latence d'entrée à froid Temps écoulé entre le début du flux et la réception du premier frame valide, lorsque le système d'entrée audio était inactif et éteint avant la requête.
- latence d'entrée continue ; La latence d'entrée pour les images suivantes, lorsque l'appareil capture l'audio.
- latence aller-retour continue ; Somme de la latence d'entrée continue, de la latence de sortie continue et d'une période de tampon. La période de mise en tampon permet à l'application de traiter le signal et de réduire la différence de phase entre les flux d'entrée et de sortie.
- API de file d'attente de tampon PCM OpenSL ES Ensemble des API OpenSL ES liées au PCM dans le NDK Android.
- API audio native AAudio Ensemble des API AAudio dans le NDK Android.
- Code temporel. Paire composée d'une position de frame relative dans un flux et de l'heure estimée à laquelle ce frame entre ou quitte le pipeline de traitement audio sur le point de terminaison associé. Consultez également AudioTimestamp.
- glitch. Interruption temporaire ou valeur d'échantillon incorrecte dans le signal audio, généralement causée par un dépassement de la mémoire tampon pour la sortie, un dépassement de la mémoire tampon pour l'entrée ou toute autre source de bruit numérique ou analogique.
- Écart absolu moyen (MAD) Moyenne de la valeur absolue des écarts par rapport à la moyenne pour un ensemble de valeurs.
Début des nouvelles exigences pour Android 15
La latence de pression-sonnerie (TTL), mesurée par CTS Verifier, correspond au délai entre le moment où l'utilisateur appuie sur l'écran et celui où le son généré par cet appui est entendu sur le haut-parleur. Il s'agit d'une moyenne sur cinq mesures à l'aide de l'API audio native AAudio pour la sortie.
La latence aller-retour (RTL), telle que mesurée par le vérificateur CTS, correspond à la latence moyenne continue sur cinq mesures, mesurée sur un chemin en boucle qui renvoie la sortie à l'entrée, à l'aide de l'API audio native AAudio. Les chemins loopback sont les suivants:
- Haut-parleur/micro: haut-parleur intégré au micro intégré.
- Analogique: prise analogique 3,5 mm et adaptateur de bouclage.
- USB: adaptateur USB vers 3,5 mm et adaptateur de bouclage ou interface audio USB et câbles de bouclage.
FEATURE_AUDIO_LOW_LATENCY. La fonctionnalité
android.hardware.audio.low_latency
est déclarée.FEATURE_AUDIO_PRO. La fonctionnalité
android.hardware.audio.pro
est déclarée.MPC. Classe de performances multimédias.
latence de suivi de la tête ; Temps écoulé entre le mouvement de la tête capturé par l'unité de mesure inertielle (IMU) et la détection par les transducteurs des écouteurs du changement de son causé par ce mouvement.
Fin des nouvelles exigences
Si les implémentations d'appareils déclarent android.hardware.audio.output
, elles DOIVENT respecter les exigences suivantes:
Début des nouvelles exigences pour Android 15
- [C-1-1] Le code temporel de sortie renvoyé par AudioTrack.getTimestamp et
AAudioStream_getTimestamp
est précis à +/- 2 ms.
Fin des nouvelles exigences
[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 prendre moins de 1 000 millisecondes.
Début des nouvelles exigences pour Android 15
- [C-1-4] Les latences aller-retour calculées en fonction des codes temporels d'entrée et de sortie renvoyés par
AAudioStream_getTimestamp
DOIVENT être comprises dans les 200 ms de la latence aller-retour mesurée pourAAUDIO_PERFORMANCE_MODE_NONE
etAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
pour les haut-parleurs, les casques filaires et sans fil.
Fin des nouvelles exigences
Début des nouvelles exigences pour Android 15
Si les implémentations d'appareils déclarent android.hardware.audio.output
, il est FORTEMENT RECOMMANDÉ de respecter ou de dépasser les exigences suivantes:
[C-SR-1] Latence de sortie à froid de 100 millisecondes ou moins sur le chemin de données de l'enceinte.
[C-SR-2] Latence de 80 ms ou moins entre le contact et le son
[C-SR-4] Il est FORTEMENT RECOMMANDÉ que les latences aller-retour calculées en fonction des codes temporels d'entrée et de sortie renvoyés par
AAudioStream_getTimestamp
soient comprises dans les 30 ms de la latence aller-retour mesurée pourAAUDIO_PERFORMANCE_MODE_NONE
etAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
pour les haut-parleurs, les casques filaires et sans fil.
Fin des nouvelles exigences
Début des nouvelles exigences pour Android 15
Si les implémentations d'appareils répondent aux exigences ci-dessus, après tout calibrage initial, lorsque vous utilisez l'API audio native AAudio, pour la latence de sortie continue et la latence de sortie à froid sur au moins un appareil de sortie audio compatible, elles sont les suivantes:
- [C-SR-5] IL EST FORTEMENT RECOMMANDÉ de signaler l'audio à faible latence en déclarant le flag de fonctionnalité
android.hardware.audio.low_latency
. - [C-SR-6] IL EST FORTEMENT RECOMMANDÉ de respecter les exigences concernant l'audio à faible latence via l'API AAudio.
- [C-SR-7] Nous vous recommandons vivement de vous assurer que, pour les flux qui renvoient
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
à partir deAAudioStream_getPerformanceMode()
, la valeur renvoyée parAAudioStream_getFramesPerBurst()
est inférieure ou égale à celle renvoyée parandroid.media.AudioManager.getProperty(String)
pour la clé de propriétéAudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER
.
Fin des nouvelles exigences
Début des nouvelles exigences pour Android 15
Si les implémentations d'appareils ne répondent pas aux exigences de l'audio à faible latence via l'API audio native AAudio, elles:
- [C-2-1] NE DOIT PAS signaler la prise en charge de l'audio à faible latence.
Fin des nouvelles exigences
Si les implémentations d'appareils incluent android.hardware.microphone
, elles DOIVENT respecter les exigences suivantes concernant l'entrée audio:
Début des nouvelles exigences pour Android 15
- [C-3-1] Limitez l'erreur dans les codes temporels d'entrée, tels que renvoyés par AudioRecord.getTimestamp ou
AAudioStream_getTimestamp
, à +/- 2 ms. "Erreur" signifie ici l'écart par rapport à la valeur correcte.
Fin des nouvelles exigences
- [C-3-2] Latence de saisie à froid de 500 millisecondes ou moins.
- [C-3-3] L'ouverture d'un flux d'entrée à l'aide de
AAudioStreamBuilder_openStream()
DOIT prendre moins de 1 000 millisecondes.
Début des nouvelles exigences pour Android 15
Si les implémentations d'appareils incluent android.hardware.microphone
, il est FORTEMENT RECOMMANDÉ de respecter ces exigences concernant l'entrée audio:
- [C-SR-8] Latence d'entrée à froid de 100 millisecondes ou moins sur le chemin de données du micro.
- [C-SR-11] Limitez l'erreur dans les codes temporels d'entrée, tels que renvoyés par AudioRecord.getTimestamp ou
AAudioStream_getTimestamp
, à +/- 1 ms.
Fin des nouvelles exigences
Début des nouvelles exigences pour Android 15
Si les implémentations de l'appareil déclarent android.hardware.audio.output
et android.hardware.microphone
, elles:
- [C-SR-12] Il est vivement recommandé d'avoir une latence aller-retour moyenne continue de 50 ms ou moins sur cinq mesures, avec une déviation absolue moyenne inférieure à 10 ms, sur au moins un chemin compatible.
Fin des nouvelles exigences
Début des nouvelles exigences pour Android 15
Le tableau suivant définit les exigences concernant le RTL pour les implémentations d'appareils portables, comme défini dans la section 2.2.1 qui déclare android.hardware.audio.output
et android.hardware.microphone
.
Appareil et déclarations | RTL (ms) | MAD (ms) | Chemins de bouclage |
---|---|---|---|
Caméra à la main | 250 | 30 | Haut-parleur/micro, analogique 3,5 mm (si compatible), USB (si compatible) |
>= MPC_T (14) | 80 | 15 | au moins un chemin d'accès ; |
FEATURE_AUDIO_LOW_LATENCY | 50 | 10 | au moins un chemin d'accès ; |
FEATURE_AUDIO_PRO | 25 | 5 | au moins un chemin d'accès ; |
FEATURE_AUDIO_PRO | 20 | 5 | analog (si compatible) |
FEATURE_AUDIO_PRO | 25 | 5 | USB (si l'analogique n'est pas pris en charge) |
Fin des nouvelles exigences
Début des nouvelles exigences pour Android 15
Le tableau suivant définit les exigences concernant le TTL pour les implémentations d'appareils portables, comme défini dans la section 2.2.1 qui déclare android.hardware.audio.output
et android.hardware.microphone
.
Appareil et déclarations | TTL (ms) |
---|---|
Caméra à la main | 250 |
>= MPC_T (14) | 80 |
MPC_S (13) | 100 |
FEATURE_AUDIO_PRO | 80 |
Fin des nouvelles exigences
Début des nouvelles exigences pour Android 15
Si les implémentations d'appareils incluent la prise en charge de spatial audio
avec le suivi de la tête et déclarent l'indicateur PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY
, elles:
- [C-4-1] DOIT présenter une latence maximale de suivi de la tête à la mise à jour audio de 300 ms.
Fin des nouvelles exigences
5.7. Protocoles de réseau
Les implémentations d'appareils DOIVENT prendre en charge les protocoles de réseau multimédia 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 doit prendre en charge, 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 être compatible avec les formats de segments multimédias correspondants, comme indiqué dans le tableau des formats de segments multimédias ci-dessous, sur le protocole de streaming HLS, version 7.
[C-1-3] DOIT prendre en charge les formats de charge utile RTSP correspondants, comme indiqué dans le tableau RTSP ci-dessous. Pour connaître les exceptions, veuillez consulter les notes de bas de page du tableau dans la section 5.1.
Formats de segments multimédias
Formats de segments | Référence(s) | Compatibilité avec les codecs requise |
---|---|---|
MPEG-2 Transport Stream | ISO 13818 |
Codecs vidéo :
Codecs audio:
|
AAC avec cadrage ADTS et tags ID3 | ISO 13818-7 | Pour en savoir plus sur l'AAC et ses variantes, consultez la section 5.1.1 . |
WebVTT | WebVTT |
RTSP (RTP, SDP)
Nom du profil | Référence(s) | Compatibilité avec les codecs requise |
---|---|---|
H264 AVC | RFC 6184 | Pour en savoir plus sur le format H264 AVC, consultez la section 5.1.8. |
MP4A-LATM | RFC 6416 | Pour en savoir plus sur l'AAC et ses variantes, consultez la section 5.1.3. |
H263-1998 |
RFC 3551 RFC 4629 RFC 2190 |
Pour en savoir plus sur le format H.263, consultez la section 5.1.8. |
H263-2000 | RFC 4629 | Pour en savoir plus sur le format H.263, consultez la section 5.1.8. |
AMR | RFC 4867 | Pour en savoir plus sur AMR-NB, consultez la section 5.1.3. |
AMR-WB | RFC 4867 | Pour en savoir plus sur AMR-WB, consultez la section 5.1.3. |
MP4V-ES | RFC 6416 | Pour en savoir plus sur MPEG-4 SP, consultez la section 5.1.8. |
mpeg4-generic | RFC 3640 | Pour en savoir plus sur l'AAC et ses variantes, consultez la section 5.1.3. |
MP2T | RFC 2250 | Pour en savoir plus, consultez la section MPEG-2 Transport Stream sous HTTP Live Streaming. |
5.8. Secure Media
Si les implémentations d'appareils sont compatibles avec la sortie vidéo sécurisée et peuvent prendre en charge les surfaces sécurisées, elles:
- [C-1-1] DOIT déclarer la prise en charge de
Display.FLAG_SECURE
.
Si les implémentations d'appareils déclarent être compatibles avec Display.FLAG_SECURE
et le protocole d'affichage sans fil, elles:
- [C-2-1] La liaison doit être sécurisée avec un mécanisme cryptographique puissant tel que HDCP 2.x ou version ultérieure pour les écrans connectés via des protocoles sans fil tels que Miracast.
Si les implémentations d'appareils déclarent la prise en charge de Display.FLAG_SECURE
et de l'écran externe filaire, elles:
- [C-3-1] DOIT être compatible avec HDCP 1.2 ou version ultérieure pour tous les écrans externes connectés via un port filaire accessible par l'utilisateur.
5.9. MIDI (Musical Instrument Digital Interface)
Si les implémentations d'appareils signalent la prise en charge de la fonctionnalité android.software.midi
via la classe android.content.pm.PackageManager
, elles:
[C-1-1] DOIT prendre en charge le MIDI sur tous les transports matériels compatibles avec le MIDI pour lesquels ils fournissent une connectivité générique non MIDI, où ces transports sont:
- Mode hôte USB, section 7.7
- MIDI sur Bluetooth LE dans le rôle de maître, section 7.4.3
[C-1-2] DOIT prendre en charge le transport logiciel MIDI inter-application (appareils MIDI virtuels)
[C-1-3] DOIT inclure libamidi.so (compatibilité MIDI native)
DOIT prendre en charge le mode MIDI sur le périphérique USB, section 7.7
5.10. Audio professionnel
Si les implémentations de l'appareil signalent la prise en charge de la fonctionnalité android.hardware.audio.pro
via la classe android.content.pm.PackageManager, elles:
- [C-1-1] DOIT indiquer la prise en charge de la fonctionnalité
android.hardware.audio.low_latency
.
Début des nouvelles exigences pour Android 15
- [C-1-2] DOIT
avoir une latence audio aller-retour continue, respecter les exigences de latence pourFEATURE_AUDIO_PRO
telles que définies dans la section 5.6 Latence audiode 25 millisecondes ou moins sur au moins un chemin pris en charge.
Fin des nouvelles exigences
- [C-1-3] DOIT inclure un ou plusieurs ports USB compatibles avec le mode hôte USB et le mode périphérique USB.
- [C-1-4] DOIT indiquer la prise en charge de la fonctionnalité
android.software.midi
.
Début des nouvelles exigences pour Android 15
- [C-1-5] DOIT respecter les exigences de
latenceet de latence audio USB à l'aide de l'API audio native AAudio et deAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
.
Fin des nouvelles exigences
- [C-1-6] La latence de sortie à froid doit être inférieure ou égale à 200 ms.
- [C-1-7] La latence d'entrée à froid doit être inférieure ou égale à 200 millisecondes.
Début des nouvelles exigences pour Android 15
- [C-1-8] DOIT avoir une latence moyenne de 80 millisecondes ou moins sur au moins cinq mesures sur le chemin de données du haut-parleur au micro.
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ de respecter les latences définies dans la section 5.6 Latence audio, de 20 millisecondes ou moins, sur cinq mesures avec une déviation absolue moyenne inférieure à cinq millisecondes sur le chemin de l'enceinte au micro.
- [C-SR-2] Il est FORTEMENT RECOMMANDÉ de respecter les exigences de l'audio professionnel en termes de latence audio aller-retour continue, de latence d'entrée à froid et de latence de sortie à froid, ainsi que les exigences audio USB à l'aide de l'API audio native AAudio sur le chemin MMAP.
[C-SR-3] FORTEMENT RECOMMANDÉ pour fournir un niveau de performances de processeur cohérent lorsque l'audio est actif et que la charge du processeur varie. Cela doit être testé à l'aide de l'application Android SynthMark. SynthMark utilise un synthétiseur logiciel exécuté sur un framework audio simulé qui mesure les performances du système. Pour en savoir plus sur les benchmarks, consultez la documentation SynthMark. L'application SynthMark doit être exécutée à l'aide de l'option "Test automatique" et obtenir les résultats suivants:
- voicemark.90 >= 32 voix
- latencymark.fixed.little <= 15 ms
- latencymark.dynamic.little <= 50 ms
DOIT minimiser l'imprécision et la dérive de l'horloge audio par rapport à l'heure normale.
DOIT minimiser la dérive de l'horloge audio par rapport au
CLOCK_MONOTONIC
du processeur lorsque les deux sont actifs.DOIT minimiser la latence audio sur les transducteurs de l'appareil.
DOIT réduire la latence audio via l'audio numérique USB.
DOIT documenter les mesures de la latence audio sur tous les chemins.
DOIT minimiser le jitter dans les temps d'entrée du rappel de finalisation du tampon audio, car cela affecte le pourcentage utilisable de la bande passante du processeur par le rappel.
DOIT ne présenter aucun glitch audio en conditions d'utilisation normales avec la latence indiquée.
DOIT fournir une différence de latence intercanal nulle.
DOIT réduire la latence moyenne MIDI sur tous les transports.
DOIT minimiser la variabilité de la latence MIDI sous charge (jitter) sur tous les transports.
DOIT fournir des codes temporels MIDI précis sur tous les transports.
DOIT réduire le bruit du signal audio sur les transducteurs de l'appareil, y compris la période immédiatement après le démarrage à froid.
DOIT fournir une différence de horloge audio nulle entre les côtés d'entrée et de sortie des points de terminaison correspondants, lorsque les deux sont actifs. Le micro et le haut-parleur de l'appareil, ou l'entrée et la sortie du connecteur audio, sont des exemples de points de terminaison correspondants.
DOIT gérer les rappels de fin de tampon audio pour les côtés d'entrée et de sortie des points de terminaison correspondants sur le même thread lorsque les deux sont actifs, et entrer dans le rappel de sortie immédiatement après le retour du rappel d'entrée. Ou si vous ne pouvez pas gérer les rappels sur le même thread, saisissez le rappel de sortie peu de temps après avoir saisi le rappel d'entrée pour permettre à l'application de disposer d'un timing cohérent pour les côtés d'entrée et de sortie.
DOIT minimiser la différence de phase entre le tamponnage audio HAL pour les côtés d'entrée et de sortie des points de terminaison correspondants.
DOIT réduire la latence tactile.
DOIT minimiser la variabilité de la latence tactile sous charge (jitter).
Fin des nouvelles exigences
Début des nouvelles exigences pour Android 15
Si les implémentations de l'appareil répondent à toutes les exigences ci-dessus, elles:
- [C-SR-4] Il est vivement recommandé de signaler la prise en charge de la fonctionnalité
android.hardware.audio.pro
via la classeandroid.content.pm.PackageManager
.
Fin des nouvelles exigences
Si les implémentations d'appareils incluent un connecteur audio 3,5 mm à quatre conducteurs, elles:
Début des nouvelles exigences pour Android 15
- [C-2-1] DOIT avoir une latence audio aller-retour continue moyenne, comme défini dans la section 5.6 Latence audio, de 20 millisecondes ou moins, sur cinq mesures avec une déviation absolue moyenne inférieure à 5 millisecondes sur le chemin du connecteur audio à l'aide d'un dongle de rebouclage audio.
Fin des nouvelles exigences
Début des nouvelles exigences pour Android 15
- [C-2-2]
[C-SR-5]IL EST FORTEMENT RECOMMANDÉ DEDOIVENT respecter la section Spécifications de l'appareil mobile (connecteur) de la spécification du casque audio filaire (v1.1).
Fin des nouvelles exigences
Si les implémentations d'appareils omettent une prise audio 3,5 mm à quatre conducteurs et incluent un ou plusieurs ports USB compatibles avec le mode hôte USB, elles:
- [C-3-1] DOIT implémenter la classe audio USB.
Début des nouvelles exigences pour Android 15
- [C-3-2] DOIT avoir une latence audio aller-retour continue moyenne de 25 ms ou moins, sur cinq mesures avec une déviation absolue moyenne inférieure à 5 ms sur le port en mode hôte USB à l'aide de la classe audio USB. (cela peut être mesuré à l'aide d'un adaptateur USB-3,5 mm et d'un dongle Audio Loopback, ou à l'aide d'une interface audio USB avec des câbles de raccordement reliant les entrées aux sorties).
- [C-SR-6] Il est FORTEMENT RECOMMANDÉ de prendre en charge les E/S simultanées jusqu'à 8 canaux dans chaque sens, un taux d'échantillonnage de 96 kHz et une profondeur de 24 bits ou 32 bits, lorsqu'ils sont utilisés avec des périphériques audio USB qui répondent également à ces exigences.
- [C-SR-7] Il est vivement recommandé de répondre à ce groupe d'exigences à l'aide de l'API audio native AAudio sur le chemin MMAP.
Fin des nouvelles exigences
Début des nouvelles exigences pour Android 15
Si les implémentations d'appareils incluent un port HDMI, elles:
- DOIT prendre en charge la sortie en stéréo et en huit canaux à une profondeur de 20 bits ou 24 bits et 192 kHz sans perte de profondeur de bits ni reéchantillonnage, dans au moins une configuration.
Fin des nouvelles exigences
5.11. Capturer pour Unprocessed
Android prend en charge l'enregistrement d'audio non traité via la source audio android.media.MediaRecorder.AudioSource.UNPROCESSED
. Dans OpenSL ES, vous pouvez y accéder avec le préréglage d'enregistrement SL_ANDROID_RECORDING_PRESET_UNPROCESSED
.
Si les implémentations d'appareils visent à prendre en charge la source audio non traitée et à la mettre à la disposition des applications tierces, elles:
[C-1-1] DOIT indiquer la prise en charge via la propriété
android.media.AudioManager
PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.[C-1-2] DOIT présenter des caractéristiques d'amplitude par rapport à la fréquence à peu près plates dans la plage de fréquences moyennes: plus précisément ±10 dB de 100 Hz à 7 000 Hz pour chaque micro utilisé pour enregistrer la source audio non traitée.
[C-1-3] DOIT présenter des niveaux d'amplitude dans la plage de basse fréquence: plus précisément, de ±20 dB de 5 Hz à 100 Hz par rapport à la plage de fréquence moyenne pour chaque micro utilisé pour enregistrer la source audio non traitée.
[C-1-4] DOIT présenter des niveaux d'amplitude dans la plage de fréquences élevées: plus précisément, de ±30 dB de 7 000 Hz à 22 kHz par rapport à la plage de fréquences moyennes pour chaque micro utilisé pour enregistrer la source audio non traitée.
[C-1-5] DOIT définir la sensibilité d'entrée audio de sorte qu'une source de tonalité sinusoïdale de 1 000 Hz lue à 94 dB de niveau de pression acoustique (SPL) génère une réponse avec une RMS de 520 pour des échantillons 16 bits (ou -36 dB à pleine échelle pour les échantillons à virgule flottante/double précision) pour chaque micro utilisé pour enregistrer la source audio non traitée.
[C-1-6] Le rapport signal/bruit (SNR) doit être de 60 dB ou plus pour chaque micro utilisé pour enregistrer la source audio non traitée. (alors que le rapport signal/bruit est mesuré comme la différence entre 94 dB SPL et le niveau de pression acoustique équivalent du bruit propre, pondéré A).
[C-1-7] Le taux de distorsion harmonique totale (THD) doit être inférieur à 1% pour 1 kHz à un niveau d'entrée de 90 dB SPL pour chaque micro utilisé pour enregistrer la source audio non traitée.
[C-1-8] Le chemin ne doit comporter aucun autre traitement du signal (par exemple, contrôle automatique du gain, filtre passe-haut ou suppression de l'écho) que le multiplicateur de niveau pour ajuster le niveau à la plage souhaitée. Autrement dit :
- [C-1-9] Si un traitement du signal est présent dans l'architecture pour une raison quelconque, il DOIT être désactivé et ne doit pas entraîner de retard ni de latence supplémentaire sur le chemin du signal.
- [C-1-10] Le multiplicateur de niveau, bien qu'il soit autorisé sur le chemin, NE DOIT PAS entraîner de retard ni de latence sur le chemin du signal.
Toutes les mesures de niveau de pression acoustique sont effectuées directement à côté du micro testé. Pour les configurations à plusieurs micros, ces exigences s'appliquent à chaque micro.
Si les implémentations d'appareils déclarent android.hardware.microphone
, mais ne sont pas compatibles avec la source audio non traitée, elles:
- [C-2-1] DOIT renvoyer
null
pour la méthode de l'APIAudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED)
, afin d'indiquer correctement l'absence de prise en charge. - [C-SR-1] est toujours FORTEMENT RECOMMANDÉ pour répondre au maximum aux exigences du chemin de signal de la source d'enregistrement non traitée.
5.12. Vidéo HDR
Android 13 est compatible avec les technologies HDR, comme décrit dans un document à venir.
Format de pixel
Si un décodeur vidéo annonce la prise en charge de COLOR_FormatYUVP010:
[C-1-1] DOIT être compatible avec le format P010 pour la lecture par CPU (ImageReader, MediaImage, ByteBuffer). Dans Android 13, P010 est assoupli pour permettre une longueur de pas arbitraire pour les plans Y et UV.
[C-1-2] Le tampon de sortie P010 DOIT pouvoir être échantillonné par le GPU (lorsqu'il est alloué avec l'utilisation GPU_SAMPLING). Cela permet aux applications de composer et de mapper des tons personnalisés avec le GPU.
Si un décodeur vidéo annonce la prise en charge de COLOR_Format32bitABGR2101010:
- [C-2-1] DOIT prendre en charge le format RGBA_1010102 pour la surface de sortie et l'affichage lisible par le processeur (sortie ByteBuffer).
Si un encodeur vidéo indique qu'il est compatible avec COLOR_FormatYUVP010:
- [C-3-1] DOIT prendre en charge le format P010 pour la surface d'entrée et l'entrée enregistrable par le processeur (ImageWriter, MediaImage, ByteBuffer).
Si un encodeur vidéo annonce la prise en charge de COLOR_Format32bitABGR2101010:
- [C-4-1] DOIT prendre en charge le format RGBA_1010102 pour la surface d'entrée et l'entrée enregistrable par le processeur (ImageWriter, ByteBuffer). Remarque: La conversion entre différentes courbes de transfert n'est PAS requise pour les encodeurs.
Exigences concernant la capture HDR
Pour tous les encodeurs vidéo compatibles avec les profils HDR, les implémentations d'appareils:
[C-5-1] NE DOIT PAS supposer que les métadonnées HDR sont précises. Par exemple, le frame encodé peut comporter des pixels au-delà du niveau de luminance maximal, ou l'histogramme peut ne pas être représentatif du frame.
DOIT agréger les métadonnées dynamiques HDR pour générer les métadonnées statiques HDR appropriées pour les flux encodés, et doit les générer à la fin de chaque session d'encodage.
Si les implémentations d'appareils sont compatibles avec la capture HDR à l'aide des API CamcorderProfile, elles:
[C-6-1] DOIT également prendre en charge la capture HDR via les API Camera2.
[C-6-2] DOIT prendre en charge au moins un encodeur vidéo accéléré par matériel pour chaque technologie HDR compatible.
[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 pour la technologie HDR) 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 dans le décodeur accéléré matériellement par défaut pour le profil capturé. En d'autres termes, si un appareil peut capturer du contenu HEVC HDR10+, le décodeur HEVC par défaut DOIT pouvoir décoder le flux capturé au format SDR.
Exigences concernant les modifications HDR
Si les implémentations d'appareils incluent des encodeurs vidéo compatibles avec le montage HDR, elles:
- DOIT utiliser une latence minimale pour générer les métadonnées HDR lorsqu'elles ne sont pas présentes et DOIT gérer de manière appropriée les situations où les métadonnées sont présentes pour certains frames et pas pour d'autres. Ces métadonnées DOIVENT être précises (par exemple, représenter la luminance de crête et l'histogramme réels du frame).
Si l'implémentation de l'appareil inclut des codecs compatibles avec FEATURE_HdrEditing
, ces codecs:
[C-7-1] DOIT être compatible avec au moins un profil HDR.
[C-7-2] DOIT être compatible avec
FEATURE_HdrEditing
pour tous les profils HDR annoncés par ce codec. En d'autres termes, ils DOIVENT être compatibles avec la génération de métadonnées HDR lorsqu'elles ne sont pas présentes 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 qui préservent entièrement le signal décodé HDR:
- RGBA_1010102 (déjà dans la courbe de transfert cible) à la fois pour la surface d'entrée et le 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 annoncer la prise en charge de l'extension OpenGL EXT_YUV_target.
6. Compatibilité des outils et options pour les développeurs
6.1. Outils pour les développeurs
Implémentations de l'appareil:
- [C-0-1] DOIT prendre en charge les outils pour les développeurs Android fournis dans le SDK Android.
- Android Debug Bridge (adb)
Début des nouvelles exigences pour Android 15
- [C-0-2] DOIT prendre en charge adb, comme indiqué dans le SDK Android et les commandes shell fournies dans l'AOSP, qui peuvent être utilisées par les développeurs d'applications,y compris
dumpsys
,cmd stats
et Simpleperf.
Fin des nouvelles exigences
- [C-0-11] La commande shell
cmd testharness
doit être prise en charge. La mise à niveau des implémentations d'appareils à partir d'une version antérieure d'Android sans bloc de données persistant peut être exemptée de C-0-11. - [C-0-3] NE DOIT PAS modifier le format ni le contenu des événements système de l'appareil (batterystats, diskstats, fingerprint, graphicsstats, netstats, notification, procstats) enregistrés via la commande dumpsys.
Début des nouvelles exigences pour Android 15
- [C-0-10] DOIT enregistrer, sans omission, et rendre les événements suivants accessibles et disponibles pour la commande shell
cmd stats
et la classe d'API systèmeStatsManager
.- ActivityForegroundStateChanged
- AnomalyDetected
- AppBreadcrumbReported
- AppCrashOccurred
- AppStartOccurred
- BatteryLevelChanged
- BatterySaverModeStateChanged
- BleScanResultReceived
- BleScanStateChanged
- ChargingStateChanged
- DeviceIdleModeStateChanged
- ForegroundServiceStateChanged
- GpsScanStateChanged
- InputDeviceUsageReported
- JobStateChanged
- KeyboardConfigured
- KeyboardSystemsEventReported
- PluggedStateChanged
- ScheduledJobStateChanged
- ScreenStateChanged
- SyncStateChanged
- SystemElapsedRealtime
- TouchpadUsage
- UidProcessStateChanged
- WakelockStateChanged
- WakeupAlarmOccurred
- WifiLockStateChanged
- WifiMulticastLockStateChanged
- WifiScanStateChanged
Fin des nouvelles exigences
- [C-0-4] Le daemon adb côté appareil DOIT être inactif par défaut, et un mécanisme accessible à l'utilisateur DOIT être disponible pour activer le pont de débogage Android.
- [C-0-5] DOIT prendre en charge adb sécurisé. Android est compatible avec adb sécurisé. adb sécurisé active adb sur les hôtes authentifiés connus.
- [C-0-6] DOIT fournir un mécanisme permettant à adb de se connecter à partir d'une machine hôte. Plus spécifiquement :
Si les implémentations d'appareils sans port USB sont compatibles avec le mode périphérique, elles:
- [C-3-1] DOIT implémenter adb via un réseau local (tel qu'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, elles:
- [C-4-1] La méthode
AdbManager#isAdbWifiSupported()
DOIT renvoyertrue
.
Si les implémentations d'appareils acceptent les connexions adb à une machine hôte via Wi-Fi ou Ethernet, et incluent au moins une caméra, elles:
- [C-5-1] La méthode
AdbManager#isAdbWifiQrSupported()
DOIT renvoyertrue
.
Service Dalvik Debug Monitor (ddms)
- [C-0-7] DOIT être compatible avec toutes les fonctionnalités ddms, comme indiqué dans le SDK Android. Comme ddms utilise adb, la prise en charge de ddms DOIT être inactive par défaut, mais DOIT être prise en charge chaque fois que l'utilisateur a activé Android Debug Bridge, comme indiqué ci-dessus.
-
- [C-0-9] DOIT être compatible avec l'outil systrace, comme indiqué dans le SDK Android. Systrace doit être inactif par défaut, et un mécanisme accessible par l'utilisateur doit être disponible pour l'activer.
-
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'exposer un binaire
/system/bin/perfetto
à l'utilisateur du shell dont la ligne de commande est conforme à la documentation de perfetto. - [C-SR-2] Il est FORTEMENT RECOMMANDÉ que le binaire perfetto accepte en entrée une configuration protobuf conforme au schéma défini dans la documentation de perfetto.
- [C-SR-3] Il est FORTEMENT RECOMMANDÉ d'écrire en sortie une 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.
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'exposer un binaire
-
- [C-0-12] DOIT écrire un atome
LMK_KILL_OCCURRED_FIELD_NUMBER
dans le journal statsd lorsqu'une application est arrêtée par le Low Memory Killer.
- [C-0-12] DOIT écrire un atome
Mode Test Harness Si les implémentations d'appareils sont compatibles avec la commande shell
cmd testharness
et exécutentcmd testharness enable
, elles:- [C-2-1] DOIT renvoyer
true
pourActivityManager.isRunningInUserTestHarness()
- [C-2-2] DOIT implémenter le mode Atelier de test comme décrit dans la documentation sur le mode Atelier de test.
- [C-2-1] DOIT renvoyer
Informations sur le travail du GPU
Implémentations de l'appareil:
- [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 point de trace du noyaupower/gpu_work_period
, ou ne pas afficher de données si le point de trace n'est pas compatible. L'implémentation AOSP estframeworks/native/services/gpuservice/gpuwork/
.
- [C-0-13] DOIT implémenter la commande shell
Si les implémentations de l'appareil signalent la prise en charge de Vulkan 1.0 ou version ultérieure via les indicateurs de fonctionnalité android.hardware.vulkan.version
, elles:
- [C-1-1] DOIT fournir une affordance permettant au développeur d'application d'activer/de désactiver les couches de débogage du GPU.
- [C-1-2] Lorsque les couches de débogage du GPU sont activées, le programme doit énumérer les couches dans les bibliothèques fournies par des outils externes (c'est-à-dire qui ne font pas partie de la plate-forme ou du package d'application) situées dans le répertoire de base des applications débogables pour prendre en charge les méthodes d'API vkEnumerateInstanceLayerProperties() et vkCreateInstance().
6.2. Options pour les développeurs
Android permet aux développeurs de configurer les paramètres liés au développement d'applications.
Les implémentations d'appareils DOIVENT fournir une expérience cohérente pour les options pour les développeurs. Elles doivent:
- [C-0-1] DOIT respecter l'intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS pour afficher les paramètres liés au développement d'applications. L'implémentation Android en amont masque le menu "Options pour les développeurs" par défaut et permet aux utilisateurs de lancer les options pour les développeurs après avoir appuyé sept (7) fois sur l'élément de menu Settings > About Device > Build Number (Paramètres > À propos de l'appareil > Numéro de version).
- [C-0-2] Les options pour les développeurs doivent être masquées par défaut.
- [C-0-3] DOIT fournir un mécanisme clair qui ne donne pas de traitement préférentiel à une application tierce par rapport à une autre pour activer les options pour les développeurs. Vous devez fournir un document ou un site Web public décrivant comment activer les options pour les développeurs. Ce document ou ce site Web DOIT être accessible en tant que lien depuis les documents du SDK Android.
- DOIT envoyer une notification visuelle continue à l'utilisateur lorsque les options pour les développeurs sont activées et que la sécurité de l'utilisateur est préoccupante.
- PEUT limiter temporairement l'accès au menu "Options pour les développeurs" en le masquant ou en le désactivant visuellement pour éviter toute distraction dans les cas où la sécurité de l'utilisateur est préoccupante.
7. Compatibilité matérielle
Si un appareil inclut un composant matériel particulier qui dispose d'une API correspondante pour les développeurs tiers:
- [C-0-1] L'implémentation de l'appareil DOIT implémenter cette API comme décrit dans la documentation du SDK Android.
Si une API du SDK interagit avec un composant matériel déclaré comme facultatif et que l'implémentation de l'appareil ne possède pas ce composant:
- [C-0-2] Les définitions de classe complètes (telles que documentées par le SDK) des API de composant DOIVENT toujours ê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.
- [C-0-4] Les méthodes d'API DOIVENT renvoyer des valeurs nulles lorsque cela est autorisé par la documentation du SDK.
- [C-0-5] Les méthodes d'API DOIVENT renvoyer des implémentations sans opération de classes pour lesquelles les valeurs nulles ne sont pas autorisées par la documentation du SDK.
- [C-0-6] Les méthodes d'API NE DOIVENT PAS générer d'exceptions non documentées par la documentation du SDK.
- [C-0-7] Les implémentations d'appareils DOIVENT signaler de manière cohérente des informations de configuration matérielle précises via les méthodes
getSystemAvailableFeatures()
ethasSystemFeature(String)
de la classe android.content.pm.PackageManager pour la même empreinte de compilation.
L'API Telephony est un exemple typique de scénario où ces exigences s'appliquent: même sur les appareils autres que les téléphones, ces API doivent être implémentées comme des opérations sans opération raisonnables.
7.1. Écran et graphismes
Android inclut des fonctionnalités qui ajustent automatiquement les composants d'application et les mises en page de l'interface utilisateur en fonction de l'appareil pour s'assurer que les applications tierces fonctionnent correctement sur différents écrans et configurations matérielles. Un écran compatible avec Android est un écran qui implémente tous les comportements et API décrits dans Android Developers - Screen compatibility overview (Développeurs Android : présentation de la compatibilité de l'écran), cette section (7.1) et ses sous-sections, ainsi que tous les comportements supplémentaires spécifiques au type d'appareil décrits dans la section 2 de ce CDD.
Implémentations de l'appareil:
- [C-0-1] Par défaut, les applications tierces ne doivent s'afficher que sur des écrans compatibles avec Android.
Les unités référencées par les exigences de cette section sont définies comme suit:
- la taille diagonale physique ; Distance en pouces entre deux coins opposés de la partie éclairée de l'écran.
- densité ; Nombre de pixels compris dans une plage linéaire horizontale ou verticale de 1 pouce, exprimé en pixels par pouce (PPI ou PPP). Lorsque des valeurs de ppi et de dpi sont indiquées, les dpi horizontaux et verticaux doivent être compris dans la plage indiquée.
- format. Rapport entre les pixels de la dimension la plus longue et la dimension la plus courte de l'écran. Par exemple, un écran de 480 x 854 pixels correspond à 854/480 = 1,779, soit environ "16:9".
- pixels indépendants de la densité (dp). Unité de pixel virtuel normalisée à une densité d'écran de 160. Pour une densité d et un nombre de pixels p, le nombre de pixels indépendants de la densité dp est calculé comme suit: dp = (160 / d) * p.
7.1.1. Configuration de l'écran
7.1.1.1. Taille et forme de l'écran
Le framework d'UI Android est compatible avec différentes tailles de mise en page d'écran logiques et permet aux applications de interroger la taille de mise en page d'écran de la configuration actuelle via Configuration.screenLayout
avec SCREENLAYOUT_SIZE_MASK
et Configuration.smallestScreenWidthDp
.
Implémentations de l'appareil:
[C-0-1] DOIT indiquer la taille de mise en page correcte pour le
Configuration.screenLayout
, comme défini dans la documentation du SDK Android. Plus précisément, les implémentations d'appareils DOIVENT indiquer les dimensions d'écran logiques en pixels indépendants de la densité (dp) correctes, comme indiqué ci-dessous:- Les appareils dont la valeur
Configuration.uiMode
est définie sur une valeur autre que UI_MODE_TYPE_WATCH et qui indiquent une taillesmall
pourConfiguration.screenLayout
DOIVENT avoir une taille d'au moins 426 dp x 320 dp. - Les appareils qui indiquent une taille
normal
pour leConfiguration.screenLayout
DOIVENT avoir une taille d'au moins 480 dp x 320 dp. - Les appareils qui signalent une taille
large
pour leConfiguration.screenLayout
DOIVENT avoir au moins 640 dp x 480 dp. - Les appareils qui indiquent une taille
xlarge
pour leConfiguration.screenLayout
DOIVENT avoir au moins 960 dp x 720 dp.
- Les appareils dont la valeur
[C-0-2] DOIT respecter correctement la prise en charge déclarée des tailles d'écran par les applications via l'attribut <
supports-screens
> dans le fichier AndroidManifest.xml, comme décrit dans la documentation du SDK Android.POURRAIENT avoir un ou plusieurs écrans compatibles avec Android avec des coins arrondis.
Si les implémentations d'appareils sont compatibles avec les écrans capables de la configuration de taille UI_MODE_TYPE_NORMAL
et utilisent un ou plusieurs écrans physiques avec des coins arrondis pour afficher ces écrans, elles:
[C-1-1] DOIT s'assurer qu'au moins l'une des exigences suivantes est remplie pour chaque affichage de ce type:
- Le rayon des coins arrondis est inférieur ou égal à 38 dp.
- Lorsqu'un cadre de 18 dp x 18 dp est ancré à chaque coin de l'affichage logique, au moins un pixel de chaque cadre est visible à l'écran.
DOIT inclure une affordance utilisateur pour passer au mode d'affichage avec les coins rectangulaires.
Si les implémentations d'appareils ne sont compatibles qu'avec la configuration du clavier NO_KEYS
et qu'elles ont l'intention de signaler la compatibilité avec la configuration du mode d'interface utilisateur UI_MODE_TYPE_NORMAL
, elles:
- [C-4-1] La taille de la mise en page, à l'exclusion des encoches d'affichage, doit être d'au moins 596 dp x 384 dp.
Pour savoir comment implémenter correctement les API de sidecar ou d'extension, consultez la documentation publique de Jetpack WindowManager.
Début des nouvelles exigences pour Android 15
Si les implémentations d'appareils incluent une ou plusieurs zones d'affichage compatibles avec Android qui sont pliables, ou incluent une charnière pliable entre plusieurs zones de panneau d'affichage compatibles avec Android et rendent ces zones d'affichage disponibles pour les applications, elles:
- [C-4-1] DOIT implémenter la version appropriée du niveau d'API des extensions du gestionnaire de fenêtres, comme décrit dans Extensions WindowManager.
Fin des nouvelles exigences
7.1.1.2. Format de l'écran
Cette section a été supprimée dans Android 14.
7.1.1.3. Densité d'écran
Le framework d'UI Android définit un ensemble de densités logiques standards pour aider les développeurs d'applications à cibler les ressources d'application.
Implémentations de l'appareil:
[C-0-1] DOIT indiquer l'une des densités de framework Android listées sur
DisplayMetrics
via l'APIDENSITY_DEVICE_STABLE
. Cette valeur doit être statique pour chaque écran physique. Toutefois, l'appareil peut signaler uneDisplayMetrics.density
différente en fonction des modifications apportées à la configuration de l'écran par l'utilisateur (par exemple, la taille de l'écran) après le démarrage initial.DOIT définir la densité de framework Android standard la plus proche numériquement de la densité physique de l'écran ou une valeur qui correspondrait aux mêmes mesures angulaires équivalentes du champ de vision d'un appareil portable.
Si les implémentations de l'appareil fournissent une affordance permettant de modifier la taille d'affichage de l'appareil, elles:
- [C-1-1] L'affichage ne doit pas être agrandi de plus de 1,5 fois la taille de
DENSITY_DEVICE_STABLE
ni produire une dimension d'écran minimale effective inférieure à 320 dp (équivalent au qualificatif de ressource sw320dp), selon la première éventualité. - [C-1-2] L'affichage ne doit PAS être mis à l'échelle à moins de 0,85 fois la taille de
DENSITY_DEVICE_STABLE
. - Pour garantir une bonne usabilité et des tailles de police cohérentes, nous vous RECOMMANDONS de fournir la mise à l'échelle suivante des options d'affichage natif (tout en respectant les limites spécifiées ci-dessus) :
- Petite: 0,85x
- Par défaut: 1x (échelle d'affichage native)
- Grande: 1,15 x
- Plus grand: x 1,3
- Plus grande : x 1,45
7.1.2. Métriques sur le Réseau Display
Si les implémentations d'appareils incluent l'écran ou la sortie vidéo compatible avec Android sur l'écran ou les écrans compatibles avec Android, elles:
- [C-1-1] DOIT indiquer des valeurs correctes pour toutes les métriques d'affichage compatibles avec Android définies dans l'API
android.util.DisplayMetrics
.
Si les implémentations d'appareils n'incluent pas d'écran intégré ni de sortie vidéo, elles:
- [C-2-1] DOIT indiquer les valeurs correctes de l'écran compatible avec Android, comme défini dans l'API
android.util.DisplayMetrics
pour l'view.Display
par défaut émulé.
7.1.3. Orientation de l'écran
Implémentations de l'appareil:
- [C-0-1] DOIT indiquer les orientations d'écran compatibles (
android.hardware.screen.portrait
et/ouandroid.hardware.screen.landscape
) et DOIT indiquer au moins une orientation compatible. Par exemple, un appareil doté d'un écran en mode paysage à orientation fixe, comme un téléviseur ou un ordinateur portable, DOIT uniquement signalerandroid.hardware.screen.landscape
. - [C-0-2] DOIT indiquer la valeur correcte pour l'orientation actuelle de l'appareil, chaque fois qu'il est interrogé via les API
android.content.res.Configuration.orientation
,android.view.Display.getOrientation()
ou d'autres.
Si les implémentations de l'appareil sont compatibles avec les deux orientations d'écran, elles:
- [C-1-1] DOIT être compatible avec l'orientation dynamique des applications en mode portrait ou paysage. Autrement dit, l'appareil doit respecter la demande de l'application pour une orientation d'écran spécifique.
- [C-1-2] NE DOIT PAS modifier la taille ou la densité de l'écran indiquées lorsque l'orientation change.
- PEUT sélectionner l'orientation portrait ou paysage par défaut.
7.1.4. Accélération graphique 2D et 3D
7.1.4.1. OpenGL ES
Implémentations de l'appareil:
- [C-0-1] DOIT identifier correctement les versions OpenGL ES compatibles (1.1, 2.0, 3.0, 3.1, 3.2) via les API gérées (par exemple, via la méthode
GLES10.getString()
) et les API natives. - [C-0-2] DOIT inclure la prise en charge de toutes les API gérées et API natives correspondantes pour toutes les versions OpenGL ES qu'il a identifiées comme compatibles.
Si les implémentations d'appareils incluent un écran ou une sortie vidéo, elles:
Début des nouvelles exigences pour Android 15
- [C-1-1] DOIT prendre en charge
à la foisOpenGL ES 1.1,et2.0, 3.0 et 3.1, comme indiqué et détaillé dans la documentation du SDK Android.
Fin des nouvelles exigences
Début des nouvelles exigences pour Android 15
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge OpenGL ES 3.1.
Fin des nouvelles exigences
- DOIT être compatible avec OpenGL ES 3.2.
Les tests dEQP OpenGL ES sont partitionnés en plusieurs listes de tests, chacune associée à une date/un numéro de version. Ils se trouvent dans l'arborescence source Android à l'emplacement external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt
. Un appareil compatible avec OpenGL ES à un niveau autodéclaré indique qu'il peut réussir les tests dEQP dans toutes les listes de tests à partir de ce niveau et versions antérieures.
Si les implémentations de l'appareil sont compatibles avec l'une des versions d'OpenGL ES, elles:
- [C-2-1] DOIT signaler via les API gérées OpenGL ES et les API natives toutes les autres extensions OpenGL ES qu'il a implémentées, et inversement DOIT NE PAS signaler les chaînes d'extension qu'il n'est pas compatible.
- [C-2-2] DOIT prendre en charge les extensions
EGL_KHR_image
,EGL_KHR_image_base
,EGL_ANDROID_image_native_buffer
,EGL_ANDROID_get_native_client_buffer
,EGL_KHR_wait_sync
,EGL_KHR_get_all_proc_addresses
,EGL_ANDROID_presentation_time
,EGL_KHR_swap_buffers_with_damage
,EGL_ANDROID_recordable
etEGL_ANDROID_GLES_layers
. - [C-2-3] DOIT indiquer la version maximale des tests dEQP OpenGL ES compatibles via le commutateur de fonctionnalité
android.software.opengles.deqp.level
. - [C-2-4] DOIT prendre en charge au moins la version 132383489 (à partir du 1er mars 2020), comme indiqué dans le flag de fonctionnalité
android.software.opengles.deqp.level
. - [C-2-5] DOIT réussir tous les tests dEQP OpenGL ES figurant dans les listes de tests entre la version 132383489 et la version spécifiée dans le flag de fonctionnalité
android.software.opengles.deqp.level
, pour chaque version d'OpenGL ES compatible. - [C-SR-2] Il est vivement recommandé de prendre en charge les extensions
EGL_KHR_partial_update
etOES_EGL_image_external
. DOIT signaler avec précision, via la méthode
getString()
, tout format de compression de texture compatible, qui est généralement spécifique au fournisseur.DOIT prendre en charge les extensions
EGL_IMG_context_priority
etEGL_EXT_protected_content
.
Si les implémentations de l'appareil déclarent la prise en charge d'OpenGL ES 3.0, 3.1 ou 3.2, elles:
- [C-3-1] DOIT exporter les symboles de fonction correspondants pour ces versions en plus des symboles de fonction OpenGL ES 2.0 dans la bibliothèque libGLESv2.so.
- [C-SR-3] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'extension
OES_EGL_image_external_essl3
.
Si les implémentations de l'appareil sont compatibles avec OpenGL ES 3.2, elles:
- [C-4-1] DOIT être compatible avec l'intégralité du pack d'extensions Android OpenGL ES.
Si les implémentations de l'appareil sont entièrement compatibles avec le pack d'extensions Android OpenGL ES, elles:
- [C-5-1] Vous devez identifier la prise en charge via l'indicateur de fonctionnalité
android.hardware.opengles.aep
.
Si les implémentations d'appareils exposent la prise en charge de l'extension EGL_KHR_mutable_render_buffer
, elles:
- [C-6-1] DOIT également prendre en charge l'extension
EGL_ANDROID_front_buffer_auto_refresh
.
7.1.4.2. Vulkan
Android est compatible avec Vulkan, une API multiplate-forme simple d'utilisation pour les graphismes 3D hautes performances.
Si les implémentations de l'appareil sont compatibles avec OpenGL ES 3.1, elles:
- [C-SR-1] Il est vivement recommandé d'inclure la compatibilité avec Vulkan 1.3.
- [C-4-1] NE DOIT PAS prendre en charge une version de variante Vulkan (c'est-à-dire que la partie variante de la version de base Vulkan DOIT être nulle).
Si les implémentations d'appareils incluent un écran ou une sortie vidéo, elles:
- [C-SR-2] Il est vivement recommandé d'inclure la compatibilité avec Vulkan 1.3.
Les tests dEQP Vulkan sont partitionnés en plusieurs listes de tests, chacune avec une date/version associée. Ils se trouvent dans l'arborescence source Android à l'emplacement external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt
. Un appareil compatible avec Vulkan à un niveau autodéclaré indique qu'il peut réussir les tests dEQP dans toutes les listes de tests à partir de ce niveau et avant.
Si les implémentations de l'appareil incluent la prise en charge de Vulkan:
- [C-1-1] DOIT indiquer la valeur entière correcte avec les indicateurs de fonctionnalité
android.hardware.vulkan.level
etandroid.hardware.vulkan.version
. - [C-1-2] DOIT énumérer au moins un
VkPhysicalDevice
pour l'API native VulkanvkEnumeratePhysicalDevices()
. - [C-1-3] DOIT implémenter entièrement les API Vulkan 1.1 pour chaque
VkPhysicalDevice
énuméré. - [C-1-4] DOIT énumérer les calques, contenus dans des bibliothèques natives nommées
libVkLayer*.so
dans le répertoire de bibliothèques natives du package d'application, via les API natives VulkanvkEnumerateInstanceLayerProperties()
etvkEnumerateDeviceLayerProperties()
. - [C-1-5] NE DOIT PAS énumérer les calques fournis par les bibliothèques en dehors du package d'application, ni fournir d'autres moyens de suivre ou d'intercepter l'API Vulkan, sauf si l'attribut
android:debuggable
de l'application est défini surtrue
ou que les métadonnéescom.android.graphics.injectLayers.enable
sont définies surtrue
. - [C-1-6] DOIT signaler toutes les chaînes d'extension qu'il prend en charge via les API natives Vulkan , et inversement NE DOIT PAS signaler les chaînes d'extension qu'il ne prend pas correctement en charge.
- [C-1-7] DOIT être compatible avec les extensions VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain et VK_KHR_incremental_present.
- [C-1-8] DOIT indiquer la version maximale des tests dEQP Vulkan compatibles via l'indicateur de fonctionnalité
android.software.vulkan.deqp.level
. - [C-1-9] DOIT au moins prendre en charge la version
132317953
(à partir du 1er mars 2019) comme indiqué dans le flag de fonctionnalitéandroid.software.vulkan.deqp.level
. - [C-1-10] Tous les tests Vulkan dEQP des listes de tests entre la version
132317953
et la version spécifiée dans l'indicateur de fonctionnalitéandroid.software.vulkan.deqp.level
DOIVENT réussir. - [C-1-11] NE DOIT PAS énumérer la prise en charge des extensions VK_KHR_video_queue, VK_KHR_video_decode_queue ou VK_KHR_video_encode_queue.
- [C-SR-3] Il est FORTEMENT RECOMMANDÉ de prendre en charge les extensions
VK_KHR_driver_properties
etVK_GOOGLE_display_timing
. - [C-1-12] NE DOIT PAS énumérer la compatibilité avec l'extension VK_KHR_performance_query.
- [C-SR-4] Il est FORTEMENT RECOMMANDÉ de respecter les exigences spécifiées par le profil de référence Android 2022.
- [C-SR-5] Il est vivement recommandé de prendre en charge
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
etVK_EXT_global_priority
. - [C-SR-6] Nous vous RECOMMANDONS vivement d'utiliser
SkiaVk
avec HWUI.
Début des nouvelles exigences pour Android 15
Si les implémentations de l'appareil incluent la prise en charge de Vulkan, elles:
- [C-SR-8] Il est FORTEMENT RECOMMANDÉ de ne pas modifier le chargeur Vulkan.
- [C-1-14] NE DOIT PAS énumérer les extensions d'appareil Vulkan de type "KHR", "GOOGLE" ou "ANDROID", sauf si ces extensions sont incluses dans l'indicateur de fonctionnalité
android.software.vulkan.deqp.level
.
Fin des nouvelles exigences
Si les implémentations de l'appareil ne sont pas compatibles avec Vulkan 1.0, elles:
- [C-2-1] NE DOIT PAS déclarer l'un des commutateurs de fonctionnalité Vulkan (par exemple,
android.hardware.vulkan.level
,android.hardware.vulkan.version
). - [C-2-2] NE DOIT PAS énumérer de
VkPhysicalDevice
pour l'API native VulkanvkEnumeratePhysicalDevices()
.
Si les implémentations de l'appareil incluent la prise en charge de Vulkan 1.1 et déclarent l'un des commutateurs de fonctionnalité Vulkan décrits ici, ils:
[C-3-1] DOIT exposer la prise en charge des types de sémaphores et de poignées externes
SYNC_FD
, ainsi que de l'extensionVK_ANDROID_external_memory_android_hardware_buffer
.[C-SR-7] Il est FORTEMENT RECOMMANDÉ de rendre l'extension
VK_KHR_external_fence_fd
disponible pour les applications tierces et d'autoriser l'application à exporter la charge utile de clôture vers et à importer la charge utile de clôture à partir de descripteurs de fichiers POSIX, comme décrit ici.
7.1.4.3. RenderScript
Implémentations de l'appareil:
- [C-0-1] DOIT être compatible avec Android RenderScript, comme indiqué dans la documentation du SDK Android.
7.1.4.4. Accélération graphique 2D
Android inclut un mécanisme permettant aux applications de déclarer qu'elles souhaitent activer l'accélération matérielle pour les graphiques 2D au niveau de l'application, de l'activité, de la fenêtre ou de la vue à l'aide d'une balise manifeste android:hardwareAccelerated ou d'appels d'API directs.
Implémentations de l'appareil:
- [C-0-1] DOIT activer l'accélération matérielle par défaut et DOIT désactiver l'accélération matérielle si le développeur le demande en définissant android:hardwareAccelerated="false" ou en désactivant l'accélération matérielle directement via les API View Android.
- [C-0-2] DOIT présenter un comportement conforme à la documentation du SDK Android sur l'accélération matérielle.
Android inclut un objet TextureView qui permet aux développeurs d'intégrer directement des textures OpenGL ES accélérées par matériel en tant que cibles de rendu dans une hiérarchie d'UI.
Implémentations de l'appareil:
- [C-0-3] DOIT prendre en charge l'API TextureView et DOIT présenter un comportement cohérent avec l'implémentation Android en amont.
7.1.4.5. Écrans à large gamme de couleurs
Si les implémentations d'appareils indiquent la prise en charge des écrans à large gamme de couleurs via Configuration.isScreenWideColorGamut()
, elles:
- [C-1-1] L'écran doit être CALIBRÉ.
- [C-1-2] L'écran doit couvrir entièrement la gamme de couleurs sRVB dans l'espace xyY CIE 1931.
- [C-1-3] L'écran doit avoir une gamme dont la surface est d'au moins 90% de la gamme DCI-P3 dans l'espace xyY CIE 1931.
- [C-1-4] DOIT être compatible avec OpenGL ES 3.1 ou 3.2 et le signaler correctement.
- [C-1-5] DOIT indiquer la prise en charge des extensions
EGL_KHR_no_config_context
,EGL_EXT_pixel_format_float
,EGL_KHR_gl_colorspace
,EGL_EXT_gl_colorspace_scrgb
,EGL_EXT_gl_colorspace_scrgb_linear
,EGL_EXT_gl_colorspace_display_p3
,EGL_EXT_gl_colorspace_display_p3_linear
etEGL_EXT_gl_colorspace_display_p3_passthrough
. - [C-SR-1] Il est vivement recommandé de prendre en charge
GL_EXT_sRGB
.
À l'inverse, si les implémentations d'appareils ne sont pas compatibles avec les écrans à large gamme de couleurs, elles:
- [C-2-1] DOIT couvrir au moins 100% de l'espace sRGB dans l'espace xyY CIE 1931, bien que la gamme de couleurs de l'écran ne soit pas définie.
7.1.5. Ancien mode de compatibilité des applications
Android spécifie un "mode de compatibilité" dans lequel le framework fonctionne en mode équivalent de taille d'écran "normale" (largeur de 320 dp) pour le bénéfice des anciennes applications qui n'ont pas été développées pour les anciennes versions d'Android antérieures à l'indépendance de la taille d'écran.
7.1.6. Technologie d'écran
La plate-forme Android inclut des API qui permettent aux applications d'afficher des graphiques riches sur un écran compatible avec Android. Les appareils DOIVENT prendre en charge toutes ces API telles que définies par le SDK Android, sauf si cela est spécifiquement autorisé dans ce document.
Tous les écrans Android compatibles d'une implémentation d'appareil:
- [C-0-1] DOIT être capable de générer des graphismes couleur 16 bits.
- DOIT être compatible avec les écrans capables d'afficher des graphiques couleur 24 bits.
- [C-0-2] DOIT être capable d'afficher des animations.
- [C-0-3] Le format de pixel (PAR) doit être compris entre 0,9 et 1,15. Autrement dit, le format de pixel DOIT être proche du format carré (1,0) avec une tolérance de 10 à 15 %.
7.1.7. Écrans secondaires
Android est compatible avec les écrans secondaires compatibles avec Android pour permettre les fonctionnalités de partage multimédia et les API de développement pour accéder aux écrans externes.
Si les implémentations d'appareils sont compatibles avec un écran externe via une connexion filaire, sans fil ou intégrée, elles:
- [C-1-1] DOIT implémenter le service et l'API système
DisplayManager
comme décrit dans la documentation du SDK Android.
7.2. Périphériques d'entrée
Implémentations de l'appareil:
- [C-0-1] DOIT inclure un mécanisme de saisie, tel qu'un écran tactile ou une navigation non tactile, pour naviguer entre les éléments de l'interface utilisateur.
7.2.1. Clavier
Si les implémentations d'appareils incluent la prise en charge d'applications tierces d'éditeur de mode de saisie (IME), elles:
- [C-1-1] Vous DEVEZ déclarer le commutateur de fonctionnalité
android.software.input_methods
. - [C-1-2] DOIT implémenter entièrement
Input Management Framework
- [C-1-3] Un clavier logiciel doit être préinstallé.
Implémentations de l'appareil:
- [C-0-1] NE DOIT PAS inclure de clavier physique qui ne correspond pas à l'un des formats spécifiés dans android.content.res.Configuration.keyboard (QWERTY ou 12 touches).
- DOIT inclure des implémentations de clavier virtuel supplémentaires.
- POURRA inclure un clavier physique.
7.2.2. Navigation non tactile
Android est compatible avec le pavé directionnel, le trackball et la roue comme mécanismes de navigation non tactile.
Implémentations de l'appareil:
- [C-0-1] DOIT indiquer la valeur correcte pour android.content.res.Configuration.navigation.
Si les implémentations d'appareils ne proposent pas de navigation non tactile, elles:
- [C-1-1] DOIT fournir un mécanisme d'interface utilisateur alternatif raisonnable pour la sélection et la modification du texte, compatible avec les moteurs de gestion des entrées. L'implémentation Open Source d'Android en amont inclut un mécanisme de sélection adapté aux appareils qui ne disposent pas d'entrées de navigation non tactiles.
7.2.3. Touches de navigation
Les fonctions Accueil, Récents et Retour, généralement fournies via une interaction avec un bouton physique dédié ou une partie distincte de l'écran tactile, sont essentielles au paradigme de navigation Android et, par conséquent, aux implémentations d'appareils:
- [C-0-1] DOIT fournir une affordance utilisateur pour lancer les applications installées qui ont une activité avec
<intent-filter>
défini avecACTION=MAIN
etCATEGORY=LAUNCHER
ouCATEGORY=LEANBACK_LAUNCHER
pour les implémentations d'appareils de télévision. La fonction "Accueil" DOIT être le mécanisme de cette affordance utilisateur. - DOIT fournir des boutons pour les fonctions "Recents" (Actions récentes) et "Back" (Retour).
Si les fonctions Accueil, Récents ou Retour sont fournies, elles:
- [C-1-1] DOIT être accessible par une seule action (par exemple, appuyer, double-cliquer ou effectuer un geste) si l'une de ces actions est accessible.
- [C-1-2] DOIT indiquer clairement quelle action déclenchera chaque fonction. L'ajout d'une icône visible sur le bouton, l'affichage d'une icône logicielle dans la partie de la barre de navigation de l'écran ou la conduite de l'utilisateur à travers un flux de démonstration guidé par étapes lors de la configuration prête à l'emploi sont des exemples d'indications de ce type.
Implémentations de l'appareil:
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de ne pas fournir le mécanisme d'entrée pour la fonction Menu, car elle est obsolète 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 comme pouvant être annulées. "Annulable" désigne la possibilité pour l'utilisateur d'empêcher l'exécution de la fonction de navigation (par exemple, l'accueil, le retour en arrière, etc.) si le balayage n'est pas relâché au-delà d'un certain seuil.
Si les implémentations d'appareils fournissent la fonction Menu, elles:
- [C-2-1] Le bouton de menu à développer doit s'afficher chaque fois que le pop-up du menu à développer d'action n'est pas vide et que la barre d'action est visible.
- [C-2-2] NE DOIT PAS modifier la position du pop-up à développer d'action affiché en sélectionnant le bouton à développer dans la barre d'action, mais PEUT afficher le pop-up à développer 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 la rétrocompatibilité, elles:
- [C-3-1] DOIT mettre la fonction Menu à la disposition des applications lorsque
targetSdkVersion
est inférieur à 10, soit par un bouton physique, une touche logicielle ou des gestes. Cette fonction de menu doit être accessible, sauf si elle est masquée avec d'autres fonctions de navigation.
Si les implémentations d'appareils fournissent la fonction d'assistance, elles:
- [C-4-1] La fonction d'assistance doit être accessible par une seule action (par exemple, appuyer, double-cliquer ou effectuer un geste) lorsque d'autres touches de navigation sont accessibles.
- [C-SR-3] Nous vous recommandons vivement d'utiliser l'appui prolongé sur la fonction HOME comme interaction désignée.
Si les implémentations d'appareils utilisent une partie distincte de l'écran pour afficher les touches de navigation, elles:
- [C-5-1] Les touches de navigation DOIVENT utiliser une partie distincte de l'écran, qui n'est pas disponible pour les applications, et NE DOIVENT PAS masquer ni interférer d'une autre manière avec la partie de l'écran disponible pour les applications.
- [C-5-2] DOIT mettre à disposition une partie de l'écran pour les applications qui répondent aux exigences définies dans la section 7.1.1.
- [C-5-3] DOIT respecter les indicateurs définis par l'application via la méthode d'API
View.setSystemUiVisibility()
, afin que cette partie distincte de l'écran (également appelée barre de navigation) soit correctement masquée, comme indiqué dans le SDK.
Si la fonction de navigation est fournie sous la forme d'une action gestuelle à l'écran:
- [C-6-1]
WindowInsets#getMandatorySystemGestureInsets()
doit être utilisé UNIQUEMENT pour signaler la zone de reconnaissance gestuelle de Home. - [C-6-2] Les gestes qui commencent dans un rectangle d'exclusion fourni par l'application de premier plan via
View#setSystemGestureExclusionRects()
, mais en dehors deWindowInsets#getMandatorySystemGestureInsets()
, NE DOIVENT PAS être interceptés pour la fonction de navigation tant que le rectangle d'exclusion est autorisé dans la limite d'exclusion maximale, comme indiqué dans la documentation pourView#setSystemGestureExclusionRects()
. - [C-6-3] DOIT envoyer à l'application de premier plan un événement
MotionEvent.ACTION_CANCEL
une fois que les gestes tactiles commencent à être interceptés pour un geste système, si l'application de premier plan a déjà reçu un événementMotionEvent.ACTION_DOWN
. - [C-6-4] DOIT fournir une affordance utilisateur pour passer à une navigation à l'écran basée sur des boutons (par exemple, dans les paramètres).
- DOIT fournir la fonction Accueil en balayant l'écran vers le haut depuis le bord inférieur de l'orientation actuelle de l'écran.
- DOIT fournir la fonctionnalité "Récents" en balayant l'écran vers le haut et en maintenant le geste avant de le relâcher, à partir de la même zone que le geste "Accueil".
- Les gestes qui commencent dans
WindowInsets#getMandatorySystemGestureInsets()
NE DOIVENT PAS être affectés par les rectangles d'exclusion fournis par l'application de premier plan viaView#setSystemGestureExclusionRects()
.
Si une fonction de navigation est fournie à partir de n'importe quel bord gauche ou droit de l'orientation actuelle de l'écran:
- [C-7-1] La fonction de navigation DOIT être "Retour" et fournie sous la forme d'un balayage à partir des bords gauche et droit de l'orientation actuelle de l'écran.
- [C-7-2] Si des panneaux système personnalisables à faire glisser sont fournis sur les bords gauche ou droit, ils DOIVENT être placés dans le tiers supérieur de l'écran avec une indication visuelle claire et persistante indiquant que le glissement vers l'intérieur appelle les panneaux susmentionnés, et donc pas "Retour". Un panneau système PEUT être configuré par un utilisateur de sorte qu'il se trouve en dessous du tiers supérieur des bords de l'écran, mais il NE DOIT PAS occuper plus d'un tiers de la ou des bordures.
- [C-7-3] Lorsque l'application au premier plan a défini les indicateurs View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT ou WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, le balayage depuis les bords DOIT se comporter comme implémenté dans AOSP, comme indiqué dans le SDK.
- [C-7-4] Lorsque l'application au premier plan a défini les indicateurs View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT ou WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, les panneaux système personnalisables à balayer DOIVENT être masqués jusqu'à ce que l'utilisateur affiche ou éclaircisse les barres système (également appelées barre de navigation et barre d'état) telles qu'implémentées dans AOSP.
Si la fonction de navigation arrière est fournie et que l'utilisateur annule le geste Retour, procédez comme suit:
- [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 distribué.
Si la fonction de navigation arrière est fournie, mais que l'application de premier plan n'a PAS d'OnBackInvokedCallback
enregistré, procédez comme suit:
- 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 de l'appareil prennent en charge l'API système setNavBarMode
pour permettre à toute application système disposant de l'autorisation android.permission.STATUS_BAR
de définir le mode de la barre de navigation, elles:
- [C-9-1] DOIT prendre en charge les icônes adaptées aux enfants ou la navigation basée 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 par pointeur, tels que les écrans tactiles, les pavés tactiles et les faux périphériques d'entrée tactile. Les implémentations d'appareils à écran tactile sont associées à un écran de sorte que l'utilisateur ait l'impression de manipuler directement les éléments à l'écran. Étant donné que l'utilisateur touche directement l'écran, le système n'a pas besoin d'affordances supplémentaires pour indiquer les objets manipulés.
Implémentations de l'appareil:
- DOIT disposer d'un système d'entrée de pointeur (souris ou tactile).
- DOIT prendre en charge les pointeurs entièrement suivis de manière indépendante.
Si les implémentations d'appareils incluent un écran tactile (à un seul contact ou mieux) sur un écran principal compatible avec Android, elles:
- [C-1-1] DOIT indiquer
TOUCHSCREEN_FINGER
pour le champ de l'APIConfiguration.touchscreen
. - [C-1-2] DOIT signaler les indicateurs de fonctionnalité
android.hardware.touchscreen
etandroid.hardware.faketouch
.
Si les implémentations d'appareils incluent un écran tactile capable de suivre plusieurs gestes sur un écran principal compatible avec Android, elles:
- [C-2-1] DOIT indiquer les indicateurs de fonctionnalité appropriés
android.hardware.touchscreen.multitouch
,android.hardware.touchscreen.multitouch.distinct
etandroid.hardware.touchscreen.multitouch.jazzhand
correspondant au type d'écran tactile spécifique de l'appareil.
Si les implémentations d'appareils s'appuient sur un périphérique d'entrée externe tel qu'une souris ou un trackball (c'est-à-dire qu'ils ne touchent pas directement l'écran) pour la saisie sur un écran principal compatible avec Android et qu'ils répondent aux exigences de simulation de contact de la section 7.2.5, ils:
- [C-3-1] NE DOIT PAS signaler de flag de fonctionnalité commençant par
android.hardware.touchscreen
. - [C-3-2] DOIT indiquer uniquement
android.hardware.faketouch
. - [C-3-3] DOIT indiquer
TOUCHSCREEN_NOTOUCH
pour le champ d'APIConfiguration.touchscreen
.
7.2.5. Saisie tactile fictive
Une interface tactile simulée fournit un système de saisie utilisateur qui s'approche d'un sous-ensemble des fonctionnalités d'un écran tactile. Par exemple, une souris ou une télécommande qui contrôle un curseur à l'écran s'apparente à un écran tactile, mais l'utilisateur doit d'abord pointer ou sélectionner un élément, puis cliquer. De nombreux périphériques d'entrée tels que la souris, le pavé tactile, la souris sans fil à gyroscope, le pointeur à gyroscope, le joystick et le pavé tactile multipoint peuvent prendre en charge les interactions tactiles simulées. Android inclut la constante de fonctionnalité android.hardware.faketouch, qui correspond à un périphérique d'entrée non tactile (basé sur un pointeur) haute fidélité, tel qu'une souris ou un pavé tactile, qui peut émuler de manière adéquate la saisie tactile (y compris la prise en charge des gestes de base) et indique que l'appareil est compatible avec un sous-ensemble émulé des fonctionnalités de l'écran tactile.
Si les implémentations d'appareils n'incluent pas d'écran tactile, mais un autre système de saisie par pointeur qu'ils souhaitent mettre à disposition, elles:
- DOIT déclarer la prise en charge du flag de fonctionnalité
android.hardware.faketouch
.
Si les implémentations d'appareils déclarent la compatibilité avec android.hardware.faketouch
, elles:
- [C-1-1] DOIT indiquer les positions X et Y absolues à l'écran de l'emplacement du pointeur et afficher un pointeur visuel à l'écran.
- [C-1-2] DOIT signaler l'événement tactile avec le code d'action qui spécifie le changement d'état qui se produit lorsque le pointeur descend ou monte à l'écran.
- [C-1-3] DOIT prendre en charge le pointeur vers le bas et vers le haut sur un objet à l'écran, ce qui permet aux utilisateurs d'émuler un appui sur un objet à l'écran.
- [C-1-4] DOIT prendre en charge le pointeur vers le bas, le pointeur vers le haut, le pointeur vers le bas, puis le pointeur vers le haut au même endroit sur un objet à l'écran dans un délai donné, ce qui permet aux utilisateurs d'émuler un double appui sur un objet à l'écran.
- [C-1-5] DOIT prendre en charge le pointeur vers le bas sur un point arbitraire de l'écran, le déplacement du pointeur vers un autre point arbitraire de l'écran, suivi d'un pointeur vers le haut, ce qui permet aux utilisateurs d'émuler un glissement tactile.
- [C-1-6] DOIT prendre en charge le pointeur vers le bas, puis permettre aux utilisateurs de déplacer rapidement l'objet vers une autre position à l'écran, puis de pointer vers le haut de l'écran, ce qui leur permet de lancer un objet à l'écran.
Si les implémentations d'appareils déclarent la compatibilité avec android.hardware.faketouch.multitouch.distinct
, elles:
- [C-2-1] DOIT déclarer la prise en charge de
android.hardware.faketouch
. - [C-2-2] DOIT prendre en charge le suivi distinct de deux entrées de pointeur indépendantes ou plus.
Si les implémentations d'appareils déclarent la compatibilité avec android.hardware.faketouch.multitouch.jazzhand
, elles:
- [C-3-1] DOIT déclarer la prise en charge de
android.hardware.faketouch
. - [C-3-2] DOIT prendre en charge le suivi distinct de cinq (suivi d'une main avec cinq doigts) ou de plusieurs entrées de pointeur de manière totalement indépendante.
7.2.6. Compatibilité avec les manettes de jeu
7.2.6.1. Mappages des boutons
Implémentations de l'appareil:
- [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 un contrôleur ou sont livrées avec un contrôleur distinct dans la boîte permettant de saisir tous les événements listés dans les tableaux ci-dessous, elles:
- [C-2-1] Vous devez déclarer l'indicateur de fonctionnalité
android.hardware.gamepad
.
Bouton | Utilisation de l'HID2 | Bouton Android |
---|---|---|
A1 | 0x09 0x0001 | KEYCODE_BUTTON_A (96) |
B1 | 0x09 0x0002 | KEYCODE_BUTTON_B (97) |
X1 | 0x09 0x0004 | KEYCODE_BUTTON_X (99) |
Y1 | 0x09 0x0005 | KEYCODE_BUTTON_Y (100) |
Croix directionnelle vers le haut1 Croix directionnelle vers le bas1 |
0x01 0x00393 | AXIS_HAT_Y4 |
Flèche vers la gauche du pavé directionnel 1 Flèche vers la droite du pavé directionnel1 |
0x01 0x00393 | AXIS_HAT_X4 |
Bouton de l'épaule gauche1 | 0x09 0x0007 | KEYCODE_BUTTON_L1 (102) |
Bouton de l'épaule droite1 | 0x09 0x0008 | KEYCODE_BUTTON_R1 (103) |
Clic sur le stick gauche1 | 0x09 0x000E | KEYCODE_BUTTON_THUMBL (106) |
Clic sur le stick droit1 | 0x09 0x000F | KEYCODE_BUTTON_THUMBR (107) |
Retour1 | 0x0c 0x0224 | KEYCODE_BACK (4) |
1 KeyEvent
2 Les utilisations HID ci-dessus doivent être déclarées dans une autorité de certification de manette de jeu (0x01 0x0005).
3 Cette utilisation doit avoir une valeur minimale logique de 0, une valeur maximale logique de 7, une valeur minimale physique de 0, une valeur maximale physique de 315, des unités en degrés et une taille de rapport de 4. La valeur logique est définie comme étant la rotation dans le sens des aiguilles d'une montre à partir de l'axe vertical. Par exemple, une valeur logique de 0 représente l'absence de rotation et la pression sur le bouton "Haut", tandis qu'une valeur logique de 1 représente une rotation de 45 degrés et la pression sur les touches "Haut" et "Gauche".
Commandes analogiques1 | Utilisation des périphériques HID | Bouton Android |
---|---|---|
Gauche | 0x02 0x00C5 | AXIS_LTRIGGER |
Gauche | 0x02 0x00C4 | AXIS_RTRIGGER |
Stick gauche | 0x01 0x0030 0x01 0x0031 |
AXIS_X AXIS_Y |
Stick droit | 0x01 0x0032 0x01 0x0035 |
AXIS_Z AXIS_RZ |
7.2.7. Télécommande
Pour connaître les exigences spécifiques à l'appareil, consultez la section 2.3.1.
7.3. Capteurs
Si les implémentations d'appareils incluent un type de capteur particulier associé à une API pour les développeurs tiers, l'implémentation de l'appareil DOIT implémenter cette API comme décrit dans la documentation du SDK Android et la documentation Open Source Android sur les capteurs.
Implémentations de l'appareil:
- [C-0-1] DOIT signaler avec précision la présence ou l'absence de capteurs conformément à la classe
android.content.pm.PackageManager
. - [C-0-2] DOIT renvoyer une liste précise des capteurs compatibles via les méthodes
SensorManager.getSensorList()
et similaires. - [C-0-3] DOIT se comporter de manière raisonnable pour toutes les autres API de capteurs (par exemple, en renvoyant
true
oufalse
selon les cas lorsque les applications tentent d'enregistrer des écouteurs, en n'appelant pas les écouteurs de capteurs lorsque les capteurs correspondants ne sont pas présents, etc.).
Si les implémentations d'appareils incluent un type de capteur particulier associé à une API correspondante pour les développeurs tiers, ils:
- [C-1-1] DOIT signaler toutes les mesures des capteurs à l'aide des valeurs du système international d'unités (métriques) appropriées pour chaque type de capteur, comme défini dans la documentation du SDK Android.
- [C-1-2] DOIT signaler les données des capteurs avec une latence maximale de 100 millisecondes + 2 * sample_time pour le cas d'un flux de capteurs avec une latence maximale demandée de 0 ms lorsque le processeur d'application est actif. Ce délai n'inclut pas les délais de filtrage.
- [C-1-3] DOIT signaler le premier échantillon du capteur dans les 400 millisecondes + 2 * sample_time de l'activation du capteur. Il est acceptable que cet exemple ait une précision de 0.
- [C-1-4] Pour toute API indiquée par la documentation du SDK Android comme étant un capteur continu, les implémentations d'appareils DOIVENT fournir en continu des échantillons de données périodiques dont le jitter DOIT être inférieur à 3%, où le jitter est défini comme l'écart type de la différence entre les valeurs de code temporel signalées entre les événements consécutifs.
- [C-1-5] Le flux d'événements du capteur DOIT empêcher le processeur de l'appareil d'entrer dans un état de suspension ou de se réveiller d'un état de suspension.
- [C-1-6] DOIT indiquer l'heure de l'événement en nanosecondes, comme défini dans la documentation du SDK Android. Cette valeur représente l'heure à laquelle l'événement s'est produit et est synchronisée avec l'horloge SystemClock.elapsedRealtimeNano().
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'avoir une erreur de synchronisation du code temporel inférieure à 100 millisecondes et DEVRAIT avoir une erreur de synchronisation du code temporel inférieure à 1 milliseconde.
- Lorsque plusieurs capteurs sont activés, la consommation d'énergie NE DOIT PAS dépasser la somme de la consommation d'énergie indiquée pour chaque capteur.
La liste ci-dessus n'est pas exhaustive. Le comportement documenté du SDK Android et des documentations Open Source Android sur les capteurs doit être considéré comme faisant autorité.
Si les implémentations d'appareils incluent un type de capteur particulier associé à une API correspondante pour les développeurs tiers, ils:
- [C-1-6] DOIT définir une résolution non nulle pour tous les capteurs et signaler la valeur via la méthode API
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. (Exemples : capteur d'orientation et capteur d'accélération linéaire.)
Implémentations de l'appareil:
- DOIT implémenter ces types de capteurs lorsqu'ils incluent les capteurs physiques requis, comme décrit dans la section Types de capteurs.
Si les implémentations d'appareils incluent un capteur composite, elles:
- [C-2-1] DOIT implémenter le capteur comme décrit dans la documentation Open Source Android sur les capteurs composites.
Si les implémentations d'appareils incluent un type de capteur particulier qui dispose d'une API correspondante pour les développeurs tiers et que le capteur ne signale qu'une seule valeur, les implémentations d'appareils:
- [C-3-1] DOIT définir la résolution sur 1 pour le capteur et signaler la valeur via la méthode d'API
Sensor.getResolution()
.
Si les implémentations d'appareils incluent un type de capteur particulier compatible avec SensorAdditionalInfo#TYPE_VEC3_CALIBRATION et que le capteur est exposé aux développeurs tiers, ils:
- [C-4-1] Les données fournies NE DOIVENT PAS inclure de paramètres de calibrage fixes, déterminés en usine.
Si les implémentations d'appareils incluent une combinaison d'accéléromètre à trois axes, d'un capteur de gyroscope à trois axes ou d'un capteur de magnétomètre, elles sont:
- [C-SR-2] IL EST FORTEMENT RECOMMANDÉ de s'assurer que l'accéléromètre, le gyroscope et le magnétomètre ont une position relative fixe, de sorte que si l'appareil est transformable (par exemple, pliable), les axes des capteurs restent alignés et cohérents avec le système de coordonnées des capteurs dans tous les états de transformation possibles de l'appareil.
7.3.1. Accéléromètre
Implémentations de l'appareil:
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un accéléromètre 3 axes.
Si les implémentations d'appareils incluent un accéléromètre, elles:
- [C-1-1] DOIT pouvoir signaler des événements jusqu'à 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 être capable de mesurer de la chute libre jusqu'à quatre fois la
gravity(4g)
ou plus sur n'importe quel axe. - [C-1-5] La résolution doit être d'au moins 12 bits.
- [C-1-6] DOIT avoir une déviation standard ne dépassant pas 0,05 m/s^, où la déviation standard doit être calculée par axe sur les échantillons collectés sur une période d'au moins trois secondes au taux d'échantillonnage le plus rapide.
- DOIT signaler les événements jusqu'à au moins 200 Hz.
- DOIT avoir une résolution d'au moins 16 bits.
- DOIT être calibré en cours d'utilisation si les caractéristiques changent au cours du cycle de vie et compensées, et conserver les paramètres de compensation entre les redémarrages de l'appareil.
- DOIT être compensé en température.
Si les implémentations d'appareils incluent un accéléromètre à trois axes, elles:
- [C-2-1] DOIT implémenter et signaler le capteur
TYPE_ACCELEROMETER
. - [C-SR-4] Il est vivement recommandé d'implémenter le capteur composite
TYPE_SIGNIFICANT_MOTION
. - [C-SR-5] Il est vivement recommandé d'implémenter et de signaler le capteur
TYPE_ACCELEROMETER_UNCALIBRATED
. Il est vivement recommandé que les appareils Android répondent à cette exigence afin qu'ils puissent passer à la prochaine version de la plate-forme, où cela pourrait devenir OBLIGATOIRE. - DOIT implémenter les capteurs composites
TYPE_SIGNIFICANT_MOTION
,TYPE_TILT_DETECTOR
,TYPE_STEP_DETECTOR
etTYPE_STEP_COUNTER
comme décrit dans le document du SDK Android.
Si les implémentations d'appareils incluent un accéléromètre à moins de trois axes, elles:
- [C-3-1] DOIT implémenter et signaler le capteur
TYPE_ACCELEROMETER_LIMITED_AXES
. - [C-SR-6] Il est FORTEMENT_RECOMMANDÉ d'implémenter et de signaler le capteur
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
.
Si les implémentations d'appareils incluent un accéléromètre à trois axes et que l'un des capteurs composites TYPE_SIGNIFICANT_MOTION
, TYPE_TILT_DETECTOR
, TYPE_STEP_DETECTOR
ou TYPE_STEP_COUNTER
est implémenté:
- [C-4-1] La somme de leur consommation d'énergie DOIT toujours être inférieure à 4 mW.
- DOIVENT être inférieurs à 2 mW et 0,5 mW lorsque l'appareil est dans un état dynamique ou statique.
Si les implémentations de l'appareil incluent un accéléromètre à trois axes et un capteur de gyroscope à trois axes, elles:
- [C-5-1] DOIT implémenter les capteurs composites
TYPE_GRAVITY
etTYPE_LINEAR_ACCELERATION
. - [C-SR-7] Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur composite
TYPE_GAME_ROTATION_VECTOR
.
Si les implémentations de l'appareil incluent un accéléromètre à trois axes, un capteur de gyroscope à trois axes et un capteur de magnétomètre, elles:
- [C-6-1] DOIT implémenter un capteur composite
TYPE_ROTATION_VECTOR
.
7.3.2. Magnétomètre
Implémentations de l'appareil:
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un magnétomètre (boussole) à trois axes.
Si les implémentations d'appareils incluent un magnétomètre à trois axes, elles:
- [C-1-1] Le capteur
TYPE_MAGNETIC_FIELD
DOIT être implémenté. - [C-1-2] DOIT pouvoir signaler des événements jusqu'à une fréquence d'au moins 10 Hz et DEVRAIT signaler des événements jusqu'à au moins 50 Hz.
- [C-1-3] DOIT respecter le système de coordonnées des capteurs Android, comme indiqué dans les API Android.
- [C-1-4] DOIT être capable de mesurer entre -900 µT et +900 µT sur chaque axe avant de saturer.
- [C-1-5] Le magnétomètre DOIT avoir une valeur de décalage de fer dur inférieure à 700 µT et DEVRAIT avoir une valeur inférieure à 200 µT, en le plaçant loin des champs magnétiques dynamiques (induits par le courant) et statiques (induits par le magnétisme).
- [C-1-6] La résolution doit être égale ou plus dense que 0,6 µT.
- [C-1-7] DOIT prendre en charge le calibrage et la compensation en ligne du biais de fer dur, et préserver les paramètres de compensation entre les redémarrages de l'appareil.
- [C-1-8] La compensation du fer doux DOIT être appliquée. L'étalonnage peut être effectué en cours d'utilisation ou lors de la fabrication de l'appareil.
- [C-1-9] L'écart type, calculé par axe sur les échantillons collectés sur une période d'au moins trois secondes à la fréquence d'échantillonnage la plus élevée, DOIT être inférieur à 1,5 µT. Il DEVRAIT être inférieur à 0,5 µT.
- [C-1-10] DOIT implémenter le capteur
TYPE_MAGNETIC_FIELD_UNCALIBRATED
.
Si les implémentations de l'appareil incluent un magnétomètre à trois axes, un capteur d'accéléromètre et un capteur de gyroscope à trois axes, elles:
- [C-2-1] DOIT implémenter un capteur composite
TYPE_ROTATION_VECTOR
.
Si les implémentations d'appareils incluent un magnétomètre à trois axes et un accéléromètre, elles:
- PEUT implémenter le capteur
TYPE_GEOMAGNETIC_ROTATION_VECTOR
.
Si les implémentations d'appareils incluent un magnétomètre à trois axes, un accéléromètre et un capteur TYPE_GEOMAGNETIC_ROTATION_VECTOR
, elles:
- [C-3-1] DOIT consommer moins de 10 mW.
- DOIT consommer moins de 3 mW lorsque le capteur est enregistré pour le mode par lot à 10 Hz.
7.3.3. GPS
Implémentations de l'appareil:
- [C-SR-1] Il est vivement recommandé d'inclure un récepteur GPS/GNSS.
Si les implémentations d'appareils incluent un récepteur GPS/GNSS et signalent la fonctionnalité aux applications via le flag de fonctionnalité android.hardware.location.gps
, elles:
- [C-1-1] DOIT prendre en charge les sorties de position à une fréquence d'au moins 1 Hz lorsqu'elles sont demandées via
LocationManager#requestLocationUpdate
. - [C-1-2] DOIT être en mesure de déterminer la position en conditions d'espace dégagé (signaux forts, multichemin négligeable, HDOP < 2) sous 10 secondes (temps de première correction rapide), lorsqu'il est connecté à une connexion Internet à débit de données d'au moins 0,5 Mbit/s. Cette exigence est généralement satisfaite par l'utilisation d'une forme de technique GPS/GNSS assistée ou prévue pour réduire le temps de verrouillage GPS/GNSS (les données d'assistance incluent l'heure de référence, l'emplacement de référence et l'éphéméride/l'horloge du satellite).
- [C-1-6] Après avoir effectué un tel calcul de position, les implémentations d'appareils DOIVENT déterminer sa position, en plein ciel, dans les cinq secondes, lorsque les requêtes de localisation sont redémarrées, jusqu'à une heure après le calcul de position initial, même lorsque la requête ultérieure est effectuée sans connexion de données et/ou après un cycle d'alimentation.
En plein ciel après avoir déterminé la position, à l'arrêt ou en mouvement avec une accélération inférieure à 1 mètre par seconde au carré:
- [C-1-3] DOIT pouvoir déterminer la position à 20 mètres près et la vitesse à 0, 5 mètre par seconde près, au moins 95% du temps.
- [C-1-4] DOIT suivre et signaler simultanément via
GnssStatus.Callback
au moins huit satellites d'une constellation. - DOIT pouvoir suivre simultanément au moins 24 satellites, issus de plusieurs constellations (par exemple, GPS + au moins un de Glonass, Beidou ou Galileo).
[C-SR-2] Il est FORTEMENT RECOMMANDÉ de continuer à fournir des sorties de position GPS/GNSS normales via les API du fournisseur de position GNSS lors d'un appel téléphonique d'urgence.
[C-SR-3] Il est FORTEMENT RECOMMANDÉ de signaler les mesures GNSS de toutes les constellations suivies (comme indiqué dans les messages GnssStatus), à l'exception de SBAS.
[C-SR-4] Il est FORTEMENT RECOMMANDÉ de signaler l'AGC et la fréquence de mesure GNSS.
[C-SR-5] Il est FORTEMENT RECOMMANDÉ de signaler toutes les estimations de précision (y compris la direction, la vitesse et la verticale) dans chaque position GPS/GNSS.
[C-SR-6] Il est FORTEMENT RECOMMANDÉ de signaler les mesures GNSS dès qu'elles sont détectées, même si une position calculée à partir du GPS/GNSS n'est pas encore signalée.
[C-SR-7] Il est FORTEMENT RECOMMANDÉ de signaler les pseudo-distances et les taux de pseudo-distance GNSS, qui, dans des conditions d'ensoleillement après avoir déterminé l'emplacement, à l'arrêt ou en mouvement avec une accélération inférieure à 0,2 m/s², sont suffisants pour calculer la position à 20 m près et la vitesse à 0,2 m/s près, au moins 95% du temps.
7.3.4. Gyroscope
Implémentations de l'appareil:
- [C-SR-1] Il est vivement recommandé d'inclure un capteur de gyroscope.
Si les implémentations d'appareils incluent un gyroscope, elles:
- [C-1-1] DOIT pouvoir signaler des événements jusqu'à une fréquence d'au moins 50 Hz.
- [C-1-4] La résolution doit être d'au moins 12 bits.
- [C-1-5] DOIT être compensé en température.
- [C-1-6] DOIT être calibré et compensé pendant l'utilisation, et conserver les paramètres de compensation entre les redémarrages de l'appareil.
- [C-1-7] La variance ne doit pas dépasser 1e-7 rad² / s² par Hz (variance par Hz, ou rad² / s). La variance peut varier avec le taux d'échantillonnage, mais elle DOIT être limitée par cette valeur. En d'autres termes, si vous mesurez la variance du gyro à un taux d'échantillonnage de 1 Hz, elle NE DOIT PAS dépasser 1e-7 rad^2/s^2.
- [C-SR-2] Il est FORTEMENT RECOMMANDÉ que l'erreur de calibrage soit inférieure à 0,01 rad/s lorsque l'appareil est à l'arrêt à température ambiante.
- [C-SR-3] Il est vivement recommandé d'utiliser une résolution de 16 bits ou plus.
- DOIT signaler les événements jusqu'à au moins 200 Hz.
Si les implémentations d'appareils incluent un gyroscope à trois axes, elles:
- [C-2-1] DOIT implémenter le capteur
TYPE_GYROSCOPE
. - [C-SR-4] Nous vous recommandons vivement d'implémenter le capteur
TYPE_GYROSCOPE_UNCALIBRATED
.
Si les implémentations d'appareils incluent un gyroscope à moins de trois axes, elles:
- [C-3-1] DOIT implémenter et signaler le capteur
TYPE_GYROSCOPE_LIMITED_AXES
. - [C-SR-5] Il est FORTEMENT_RECOMMANDÉ d'implémenter et de signaler le capteur
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
.
Si les implémentations de l'appareil incluent un gyroscope à trois axes, un capteur d'accéléromètre et un capteur de magnétomètre, elles:
- [C-4-1] DOIT implémenter un capteur composite
TYPE_ROTATION_VECTOR
.
Si les implémentations de l'appareil incluent un accéléromètre à trois axes et un capteur de gyroscope à trois axes, elles:
- [C-5-1] DOIT implémenter les capteurs composites
TYPE_GRAVITY
etTYPE_LINEAR_ACCELERATION
. - [C-SR-6] Il est vivement recommandé d'implémenter le capteur composite
TYPE_GAME_ROTATION_VECTOR
.
7.3.5. Le baromètre
Implémentations de l'appareil:
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un baromètre (capteur de pression atmosphérique ambiante).
Si les implémentations d'appareils incluent un baromètre, elles:
- [C-1-1] DOIT implémenter et signaler le capteur
TYPE_PRESSURE
. - [C-1-2] DOIT être en mesure de diffuser des événements à 5 Hz ou plus.
- [C-1-3] DOIT être compensé en température.
- [C-SR-2] IL EST FORTEMENT RECOMMANDÉ de pouvoir enregistrer des mesures de pression comprises entre 300 hPa et 1 100 hPa.
- DOIT avoir une précision absolue de 1 hPa.
- DOIT avoir une précision relative de 0,12 hPa sur une plage de 20 hPa (équivalent à une précision d'environ 1 m sur une variation d'environ 200 m au niveau de la mer).
7.3.6. Thermomètre
Si les implémentations d'appareils incluent un thermomètre ambiant (capteur de température), elles:
- [C-1-1] Le
SENSOR_TYPE_AMBIENT_TEMPERATURE
doit être défini pour le capteur de température ambiante, et le capteur doit mesurer la température ambiante (pièce/habitacle du véhicule) à partir de l'endroit où l'utilisateur interagit avec l'appareil en degrés Celsius.
Si les implémentations d'appareils incluent un capteur de thermomètre qui mesure une température autre que la température ambiante, telle que la température du processeur, elles:
- [C-2-1] NE DOIT PAS définir
SENSOR_TYPE_AMBIENT_TEMPERATURE
pour le capteur de température.
Si les implémentations d'appareils incluent un capteur pour surveiller la température cutanée, elles:
- [C-SR-1] Nous vous RECOMMANDONS vivement de prendre en charge l'API PowerManager.getThermalHeadroom.
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 ne signalent qu'une lecture binaire "proche" ou "loin", elles:
- [C-1-1] DOIT mesurer la proximité d'un objet dans la même direction que l'écran. Autrement dit, le capteur de proximité DOIT être orienté pour détecter les objets à proximité de l'écran, car l'objectif principal de ce type de capteur est de détecter un téléphone utilisé par l'utilisateur. Si les implémentations d'appareils incluent un capteur de proximité avec une autre orientation, il NE DOIT PAS être accessible via cette API.
- [C-1-2] Doit avoir une précision d'au moins 1 bit.
- [C-1-3] Vous devez utiliser 0 cm pour la lecture proche et 5 cm pour la lecture éloignée.
- [C-1-4] DOIT indiquer une portée et une résolution maximales de 5.
7.3.9. Capteurs haute fidélité
Si les implémentations d'appareils incluent un ensemble de capteurs de meilleure qualité, comme défini dans cette section, et les mettent à la disposition d'applications tierces, elles:
- [C-1-1] Vous devez identifier la fonctionnalité via l'indicateur de fonctionnalité
android.hardware.sensor.hifi_sensors
.
Si les implémentations de l'appareil déclarent android.hardware.sensor.hifi_sensors
, elles:
[C-2-1] DOIT comporter un capteur
TYPE_ACCELEROMETER
qui:- Doit avoir une plage de mesure d'au moins -8 g à +8 g. Il est fortement recommandé d'avoir une plage de mesure d'au moins -16 g à +16 g.
- Doit avoir une résolution de mesure d'au moins 2 048 LSB/g.
- Doit avoir une fréquence de mesure minimale de 12,5 Hz ou moins.
- DOIT avoir une fréquence de mesure maximale de 400 Hz ou plus ; DOIT prendre en charge le SensorDirectChannel
RATE_VERY_FAST
. - DOIT avoir un bruit de mesure inférieur à 400 μg/√Hz.
- DOIT implémenter une forme non réveillée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 3 000 événements de capteur.
- La consommation d'énergie de la mise en lot doit être inférieure ou égale à 3 mW.
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'avoir une bande passante de mesure de 3 dB d'au moins 80% de la fréquence Nyquist et un spectre de bruit blanc dans cette bande passante.
- L'accélération doit être inférieure à 30 μg √Hz, testée à température ambiante.
- Le changement de biais par rapport à la température doit être ≤ +/- 1 mg/°C.
- La non-linéarité de la ligne d'ajustement doit être inférieure ou égale à 0,5%, et la variation de la sensibilité en fonction de la température doit être inférieure ou égale à 0,03%/°C.
- DOIT avoir une sensibilité croisée de moins de 2,5 % et une variation de la sensibilité croisée de moins de 0,2% dans la plage de température de fonctionnement de l'appareil.
[C-2-2] DOIT avoir un
TYPE_ACCELEROMETER_UNCALIBRATED
avec les mêmes exigences de qualité queTYPE_ACCELEROMETER
.[C-2-3] DOIT comporter un capteur
TYPE_GYROSCOPE
qui:- DOIT avoir une plage de mesure d'au moins -1 000 et +1 000 dps.
- Doit avoir une résolution de mesure d'au moins 16 LSB/dps.
- Doit avoir une fréquence de mesure minimale de 12,5 Hz ou moins.
- DOIT avoir une fréquence de mesure maximale de 400 Hz ou plus ; DOIT prendre en charge le SensorDirectChannel
RATE_VERY_FAST
. - DOIT avoir un bruit de mesure inférieur à 0,014 °/s/√Hz.
- [C-SR-2] Il est FORTEMENT RECOMMANDÉ d'avoir une bande passante de mesure de 3 dB d'au moins 80% de la fréquence Nyquist et un spectre de bruit blanc dans cette bande passante.
- DOIT avoir une marche aléatoire de fréquence inférieure à 0,001 °/s √Hz testée à température ambiante.
- Le biais doit changer de ≤ +/- 0,05 °/ s / °C par rapport à la température.
- La sensibilité doit changer de ≤ 0,02% / °C par rapport à la température.
- La non-linéarité de la droite d'ajustement optimal doit être inférieure ou égale à 0,2%.
- DOIT avoir une densité de bruit de ≤ 0,007 °/s/√Hz.
- L'erreur de calibrage doit être inférieure à 0,002 rad/s dans la plage de température de 10 à 40 °C lorsque l'appareil est à l'arrêt.
- La sensibilité à la gravité doit être inférieure à 0,1 °/s/g.
- DOIT avoir une sensibilité croisée de moins de 4,0 % et une variation de sensibilité croisée de moins de 0,3% dans la plage de température de fonctionnement de l'appareil.
[C-2-4] DOIT avoir un
TYPE_GYROSCOPE_UNCALIBRATED
avec les mêmes exigences de qualité queTYPE_GYROSCOPE
.[C-2-5] DOIT disposer d'un capteur
TYPE_GEOMAGNETIC_FIELD
qui:- DOIT avoir une plage de mesure d'au moins -900 et +900 μT.
- Doit avoir une résolution de mesure d'au moins 5 LSB/uT.
- Doit avoir une fréquence de mesure minimale de 5 Hz ou moins.
- DOIT avoir une fréquence de mesure maximale de 50 Hz ou plus.
- Le bruit de mesure doit être inférieur à 0,5 uT.
[C-2-6] DOIT avoir un
TYPE_MAGNETIC_FIELD_UNCALIBRATED
avec les mêmes exigences de qualité queTYPE_GEOMAGNETIC_FIELD
, et en outre:- DOIT implémenter une forme non réveillée de ce capteur avec une capacité de mise en tampon d'au moins 600 événements de capteur.
- [C-SR-3] Il est FORTEMENT RECOMMANDÉ d'avoir un spectre de bruit blanc allant de 1 Hz à au moins 10 Hz lorsque la fréquence de rapport est de 50 Hz ou plus.
[C-2-7] DOIT comporter un capteur
TYPE_PRESSURE
qui:- DOIT avoir une plage de mesure d'au moins 300 et 1 100 hPa.
- DOIT avoir une résolution de mesure d'au moins 80 LSB/hPa.
- Doit avoir une fréquence de mesure minimale de 1 Hz ou moins.
- DOIT avoir une fréquence de mesure maximale de 10 Hz ou plus.
- Le bruit de mesure doit être inférieur à 2 Pa/√Hz.
- DOIT implémenter une forme non réveillée de ce capteur avec une capacité de mise en tampon d'au moins 300 événements de capteur.
- La consommation d'énergie de la mise en lot doit être inférieure ou égale à 2 mW.
[C-2-8] DOIT avoir un capteur
TYPE_GAME_ROTATION_VECTOR
.[C-2-9] DOIT comporter un capteur
TYPE_SIGNIFICANT_MOTION
qui:- DOIT avoir une consommation d'énergie inférieure à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsque l'appareil est en mouvement.
[C-2-10] DOIT comporter un capteur
TYPE_STEP_DETECTOR
qui:- DOIT implémenter une forme non réveillée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 100 événements de capteur.
- DOIT avoir une consommation d'énergie inférieure à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsque l'appareil est en mouvement.
- La consommation d'énergie de la mise en lot doit être inférieure ou égale à 4 mW.
[C-2-11] DOIT comporter un capteur
TYPE_STEP_COUNTER
qui:- DOIT avoir une consommation d'énergie inférieure à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsque l'appareil est en mouvement.
[C-2-12] DOIT comporter un capteur
TILT_DETECTOR
qui:- DOIT avoir une consommation d'énergie inférieure à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsque l'appareil est en mouvement.
[C-2-13] L'horodatage de l'événement du même événement physique signalé par l'accéléromètre, le gyroscope et le magnétomètre DOIT être compris dans une plage de 2, 5 millisecondes. L'horodatage de l'événement du même événement physique signalé par l'accéléromètre et le gyroscope DOIT être compris entre 0,25 milliseconde et 0,25 milliseconde.
[C-2-14] Les codes temporels des événements du capteur gyroscopique DOIVENT être basés sur la même base temporelle que le sous-système de la caméra et avoir une erreur inférieure à 1 milliseconde.
[C-2-15] DOIT envoyer des échantillons aux applications dans les cinq millisecondes à compter du moment où les données sont disponibles sur l'un des capteurs physiques ci-dessus.
[C-2-16] NE DOIT PAS avoir une consommation d'énergie supérieure à 0,5 mW lorsque l'appareil est statique et à 2 mW lorsque l'appareil 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] Un capteur
TYPE_PROXIMITY
peut être présent, mais s'il l'est, il doit avoir une capacité de mémoire tampon minimale de 100 événements de capteur.
Notez que toutes les exigences de consommation d'énergie de cette section n'incluent pas la consommation d'énergie du processeur d'application. Elle comprend la puissance consommée par l'ensemble de la chaîne de capteurs (le capteur, les circuits de support, tout système de traitement de capteur dédié, etc.).
Si les implémentations d'appareils incluent la prise en charge directe des capteurs, elles:
- [C-3-1] DOIT déclarer correctement la prise en charge des types de canaux directs et du niveau des taux de rapports directs via les API
isDirectChannelTypeSupported
etgetHighestDirectReportRateLevel
. - [C-3-2] DOIT prendre en charge au moins l'un des deux types de canaux directs pour les capteurs pour tous les capteurs qui déclarent prendre en charge le canal direct pour les capteurs.
- DOIT prendre en charge la création de rapports sur les événements via le canal direct du capteur pour le capteur principal (variante sans réveil) des types suivants :
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED
7.3.10. Capteurs biométriques
Pour en savoir plus sur la mesure de la sécurité du déverrouillage biométrique, consultez la documentation sur la mesure de la sécurité biométrique.
Si les implémentations de l'appareil incluent un écran de verrouillage sécurisé, elles:
- DOIT inclure un capteur biométrique
Les capteurs biométriques peuvent être classés en classe 3 (anciennement fort), classe 2 (anciennement faible) ou classe 1 (anciennement commodité) en fonction de leurs taux d'acceptation des falsifications et des imposteurs, ainsi que de la sécurité du pipeline biométrique. Cette classification détermine les fonctionnalités du capteur biométrique pour interagir avec la plate-forme et les applications tierces. Les capteurs doivent respecter des exigences supplémentaires, comme indiqué ci-dessous, s'ils souhaitent être classés en classe 1, classe 2 ou classe 3. Les technologies biométriques de classe 2 et de classe 3 bénéficient de fonctionnalités supplémentaires, comme indiqué ci-dessous.
Si les implémentations de l'appareil mettent un capteur biométrique à la disposition des applications tierces via android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt et android.provider.Settings.ACTION_BIOMETRIC_ENROLL, ils:
- [C-4-1] DOIT respecter les exigences de la biométrie de classe 3 ou de classe 2, telles que définies dans ce document.
- [C-4-2] DOIT reconnaître et respecter chaque nom de paramètre défini comme constante dans la classe Authenticators et toutes les combinaisons de celle-ci. À l'inverse, elles NE DOIVENT PAS respecter ni reconnaître les constantes entières transmises aux méthodes canAuthenticate(int) et setAllowedAuthenticators(int) autres que celles documentées en tant que constantes publiques dans Authenticators et toute combinaison de celles-ci.
- [C-4-3] DOIT implémenter l'action ACTION_BIOMETRIC_ENROLL sur les appareils dotés de technologies biométriques de classe 3 ou de classe 2. Cette action DOIT uniquement présenter les points d'entrée d'enregistrement pour les technologies biométriques de classe 3 ou de classe 2.
Début des nouvelles exigences pour Android 15
- [C-4-4] DOIT autoriser les applications à ajouter du contenu personnalisé à
BiometricPrompt
à l'aide des formats d'affichage de contenuPromptContentView
. Les formats d'affichage du contenu NE DOIVENT PAS être étendus pour autoriser les images, les liens, les contenus interactifs ou d'autres formes de médias qui ne font pas déjà partie de l'APIBiometricPrompt
. Vous pouvez apporter des ajustements stylistiques qui ne modifient pas, n'obscurcissent pas ni ne tronquent ce contenu (par exemple, en modifiant la position, la marge intérieure, les marges et la typographie).
Fin des nouvelles exigences
Si les implémentations de l'appareil sont compatibles avec les données biométriques passives, elles:
- [C-5-1] Une étape de confirmation supplémentaire (par exemple, appuyer sur un bouton) DOIT être requise par défaut.
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ de disposer d'un paramètre permettant aux utilisateurs de remplacer les préférences de l'application et de toujours exiger une étape de confirmation.
- [C-SR-2] Il est FORTEMENT RECOMMANDÉ de sécuriser l'action de confirmation afin qu'un système d'exploitation ou un noyau compromis ne puisse pas l'usurper. Par exemple, cela signifie que l'action de confirmation basée sur un bouton physique est acheminée via une broche d'entrée/sortie (GPIO) à usage général uniquement d'un élément sécurisé (SE) qui ne peut être piloté que par une pression sur un bouton physique.
- [C-5-2] DOIT également implémenter un flux d'authentification implicite (sans étape de confirmation) correspondant à setConfirmationRequired(boolean), que les applications peuvent définir pour les flux de connexion.
Si les implémentations d'appareils comportent plusieurs capteurs biométriques, elles:
[C-7-1] Lorsqu'une empreinte biométrique est verrouillée (c'est-à-dire qu'elle est désactivée jusqu'à ce que l'utilisateur déverrouille l'appareil avec l'authentification principale) ou verrouillée de manière limitée dans le temps (c'est-à-dire qu'elle est temporairement désactivée jusqu'à ce que l'utilisateur attende un intervalle de temps) en raison d'un trop grand nombre de tentatives infructueuses, le système doit également verrouiller toutes les autres empreintes biométriques d'une classe biométrique inférieure. En cas de verrouillage limité dans le temps, le délai d'inactivité pour la validation biométrique DOIT être le délai d'inactivité maximal de toutes les biométries en cas de verrouillage limité dans le temps.
[C-SR-12] Il est FORTEMENT RECOMMANDÉ, lorsqu'une empreinte biométrique est verrouillée (c'est-à-dire qu'elle est désactivée jusqu'à ce que l'utilisateur déverrouille l'appareil avec l'authentification principale) ou verrouillée de manière limitée dans le temps (c'est-à-dire qu'elle est temporairement désactivée jusqu'à ce que l'utilisateur attende un intervalle de temps) en raison de trop de tentatives infructueuses, de verrouiller également toutes les autres empreintes biométriques de la même classe biométrique. En cas de verrouillage limité dans le temps, il est vivement recommandé que le délai d'inactivité pour la validation biométrique soit le délai d'inactivité maximal de toutes les biométries en cas de verrouillage limité dans le temps.
[C-7-2] DOIT demander à l'utilisateur de fournir l'authentification principale recommandée (par exemple, code, schéma, mot de passe) pour réinitialiser le compteur de verrouillage en cas de verrouillage biométrique. Les biométriques de classe 3 peuvent être autorisées à réinitialiser le compteur de verrouillage pour une biométrie verrouillée de la même classe ou d'une classe inférieure. Les données biométriques de classe 2 ou de classe 1 NE DOIVENT PAS être autorisées à effectuer une opération de réinitialisation du verrouillage pour toute donnée biométrique.
[C-SR-3] Il est FORTEMENT RECOMMANDÉ de ne demander qu'une seule authentification biométrique par authentification (par exemple, si les capteurs d'empreinte digitale et de reconnaissance faciale sont disponibles sur l'appareil, onAuthenticationSucceeded doit être envoyé après la confirmation de l'un d'eux).
Pour que les implémentations d'appareils autorisent l'accès aux clés du keystore aux applications tierces, elles doivent:
- [C-6-1] DOIT respecter les exigences de la classe 3 telles que définies dans cette section 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 que l'authentification est appelée avec un CryptoObject.
Si les implémentations d'appareils souhaitent traiter un capteur biométrique comme un capteur de classe 1 (anciennement Commodité), elles doivent:
- [C-1-1] Le taux de fausse acceptation doit être inférieur à 0,002%.
- [C-1-2] DOIT indiquer que ce mode peut être moins sécurisé qu'un code, un schéma ou un mot de passe sécurisés, et énumérer clairement les risques de l'activer si les taux d'acceptation des attaques par hameçonnage et par usurpation d'identité sont supérieurs à 7 %, comme mesuré par les protocoles de test biométriques Android.
- [C-1-9] DOIT demander à l'utilisateur de fournir l'authentification principale recommandée (par exemple, (code, schéma, mot de passe) après un maximum de vingt fausses tentatives et un temps de retour d'au moins 90 secondes pour la validation biométrique. Une fausse tentative correspond à une qualité de capture adéquate (BIOMETRIC_ACQUIRED_GOOD) qui ne correspond pas à une empreinte biométrique enregistrée.
- [C-SR-4] Nous vous RECOMMANDONS vivement de réduire le nombre total de fausses tentatives de vérification biométrique spécifié dans [C-1-9] si les taux d'acceptation des faux et des imposteurs sont supérieurs à 7 %, comme mesuré par les protocoles de test des technologies biométriques Android.
- [C-1-3] Le système doit limiter le nombre de tentatives de vérification biométrique, où une tentative incorrecte est celle dont la qualité de capture (
BIOMETRIC_ACQUIRED_GOOD
) est adéquate, mais qui ne correspond pas à une empreinte biométrique enregistrée. - [C-SR-5] Il est FORTEMENT RECOMMANDÉ de limiter la fréquence des tentatives pendant au moins 30 secondes après cinq tentatives incorrectes pour la validation biométrique, en fonction du nombre maximal de tentatives incorrectes par [C-1-9]. Une tentative incorrecte est une tentative avec une qualité de capture adéquate (BIOMETRIC_ACQUIRED_GOOD) qui ne correspond pas à une empreinte biométrique enregistrée.
- [C-SR-6] Il est FORTEMENT RECOMMANDÉ de placer toute logique de limitation de débit dans le TEE.
- [C-1-10] DOIT désactiver l'authentification biométrique une fois que le délai d'expiration de l'authentification principale a été déclenché pour la première fois, comme décrit dans [C-0-2] de la section 9.11.
- [C-1-11] DOIT avoir un taux d'acceptation des attaques par falsification et usurpation d'identité inférieur à 30%, avec (1) un taux d'acceptation des attaques par falsification et usurpation d'identité pour les espèces d'instruments d'attaque par présentation (PAI) de niveau A inférieur à 30 % et (2) un taux d'acceptation des attaques par falsification et usurpation d'identité pour les espèces de PAI de niveau B inférieur à 40%, mesuré par les protocoles de test biométrique Android.
- [C-1-4] DOIT empêcher l'ajout de nouvelles données biométriques sans d'abord établir une chaîne de confiance en demandant à l'utilisateur de confirmer les identifiants existants ou d'en ajouter de nouveaux (code/schéma/mot de passe) sécurisés par le TEE. L'implémentation du projet Android Open Source fournit le mécanisme dans le framework pour ce faire.
Début des nouvelles exigences pour Android 15
- [C-1-5] L'appareil DOIT supprimer complètement toutes les données biométriques identifiables d'un utilisateur lorsque son compte est supprimé (y compris via une réinitialisation d'usine) ou lorsque l'authentification primaire recommandée (par exemple, un code, un schéma ou un mot de passe) est supprimée.
Fin des nouvelles exigences
- [C-1-6] DOIT respecter l'indicateur individuel pour cette empreinte biométrique (par exemple,
DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT
,DevicePolicymanager.KEYGUARD_DISABLE_FACE
ouDevicePolicymanager.KEYGUARD_DISABLE_IRIS
).
Début des nouvelles exigences pour Android 15
- [C-1-7] DOIT demander à l'utilisateur de fournir l'authentification primaire recommandée (par exemple, un code, un schéma ou un mot de passe) toutes les 24 heures ou moins.
Remarque: La mise à niveau des appareils lancés sous Android 9 ou version antérieure DOIT demander à l'utilisateur de fournir l'authentification primaire recommandée (code, schéma, mot de passe, par exemple) toutes les 72 heures ou moins.
Fin des nouvelles exigences
Début des nouvelles exigences pour Android 15
- [C-1-8] L'application DOIT demander à l'utilisateur de fournir l'authentification primaire recommandée (par exemple, un code, un schéma ou un mot de passe) ou une biométrie de classe 3 (FORTE) après l'un des événements suivants :
- un délai d'inactivité de quatre heures ; OU
- Trois tentatives d'authentification biométrique échouées.
- Le délai avant expiration d'inactivité et le nombre d'échecs d'authentification sont réinitialisés après toute confirmation réussie des identifiants de l'appareil.
Remarque: La mise à niveau des appareils lancés avec Android 9 ou version antérieure PEUT être exemptée de la règle C-1-8.
Fin des nouvelles exigences
- [C-SR-7] Il 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É de disposer d'un taux de faux rejet inférieur à 10%, mesuré sur l'appareil.
- [C-SR-9] Il est FORTEMENT RECOMMANDÉ de disposer d'une latence inférieure à une seconde, mesurée à partir du moment où la biométrie est détectée jusqu'au déverrouillage de l'écran, pour chaque biométrie enregistrée.
- [C-1-12] Le taux d'acceptation des attaques par falsification et usurpation d'identité doit être inférieur à 40 % par type d'instrument d'attaque par présentation (PAI), tel que mesuré par les protocoles de test biométriques Android.
- [C-SR-13] Il est FORTEMENT RECOMMANDÉ de définir un taux d'acceptation des attaques par falsification et par usurpation d'identité ne dépassant pas 30 % par type d'instrument d'attaque par présentation (PAI), tel que mesuré par les protocoles de test biométriques Android.
- [C-SR-8] Il est FORTEMENT RECOMMANDÉ de disposer d'un taux de faux rejet inférieur à 10%, mesuré sur l'appareil.
Début des nouvelles exigences pour Android 15
- [C-1-15] DOIT permettre aux utilisateurs de supprimer un ou plusieurs enregistrements biométriques.
Fin des nouvelles exigences
[C-SR-14] Il est FORTEMENT RECOMMANDÉ de divulguer la classe biométrique du lecteur biométrique et les risques correspondants de l'activer.
[C-SR-17] Il est vivement recommandé d'implémenter les nouvelles interfaces AIDL (par exemple,
IFace.aidl
etIFingerprint.aidl
).
Si les implémentations d'appareils souhaitent traiter un capteur biométrique comme un capteur de classe 2 (anciennement faible), elles doivent:
- [C-2-1] DOIT respecter toutes les exigences de la classe 1 ci-dessus.
- [C-2-2] DOIT avoir un taux d'acceptation des attaques par falsification et usurpation d'identité inférieur à 20%, avec (1) un taux d'acceptation des attaques par falsification et usurpation d'identité pour les espèces d'instruments d'attaque par falsification et usurpation d'identité de niveau A inférieur à 20 % et (2) un taux d'acceptation des attaques par falsification et usurpation d'identité des espèces d'instruments d'attaque par falsification et usurpation d'identité de niveau B inférieur à 30%, mesuré par les protocoles de test biométrique Android.
- [C-SR-15] Il est FORTEMENT RECOMMANDÉ de définir un taux d'acceptation des attaques par falsification et usurpation d'identité ne dépassant pas 20 % par type d'instrument d'attaque par présentation (PAI), tel que mesuré par les protocoles de test biométriques Android.
- [C-2-3] DOIT effectuer la mise en correspondance biométrique dans un environnement d'exécution isolé en dehors de l'espace utilisateur ou du kernel Android, tel que l'environnement d'exécution sécurisé (TEE), sur une puce avec un canal sécurisé vers l'environnement d'exécution isolé ou sur une machine virtuelle protégée qui répond aux exigences de la section 9.17.
- [C-2-4] Toutes les données identifiables DOIVENT être chiffrées et authentifiées de manière cryptographique afin qu'elles ne puissent pas être acquises, lues ni modifiées en dehors de l'environnement d'exécution isolé ou d'une puce avec un canal sécurisé vers l'environnement d'exécution isolé, comme indiqué dans les consignes d'implémentation sur le site du projet Android Open Source ou d'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 les données biométriques basées sur une caméra, pendant l'authentification ou l'enregistrement biométrique :
- DOIT faire fonctionner la caméra dans un mode qui empêche la lecture ou la modification des images de la caméra en dehors de l'environnement d'exécution isolé ou d'une puce avec un canal sécurisé vers l'environnement d'exécution isolé 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 à caméra unique RVB, les cadres de la caméra PEUVENT être lisibles en dehors de l'environnement d'exécution isolé pour prendre en charge des opérations telles que l'aperçu pour l'enregistrement, mais NE DOIVENT PAS être modifiables.
- [C-2-6] NE DOIT PAS permettre aux applications tierces de distinguer les enregistrements biométriques individuels.
- [C-2-7] NE DOIT PAS autoriser l'accès non chiffré aux données biométriques identifiables ni à toute donnée dérivée de celles-ci (telles que les représentations vectorielles continues) au processeur d'application en dehors du contexte du TEE ou de la machine virtuelle protégée contrôlée par un hyperviseur qui répond aux exigences de la section 9.17. La mise à niveau des appareils lancés avec Android 9 ou version antérieure n'est pas exemptée de C-2-7.
[C-2-8] DOIT disposer d'un pipeline de traitement sécurisé de sorte qu'une compromission du système d'exploitation ou du noyau ne puisse pas permettre l'injection directe de données pour s'authentifier faussement en tant qu'utilisateur. Remarque: Si les implémentations d'appareils sont déjà lancées sur Android 9 ou version antérieure et ne peuvent pas répondre à l'exigence C-2-8 via une mise à jour du logiciel système, elles PEUVENT être exemptées de cette exigence.
[C-SR-10] Il est FORTEMENT RECOMMANDÉ d'inclure la détection de l'activité pour toutes les modalités biométriques et la détection de l'attention pour la biométrie faciale.
[C-2-9] DOIT mettre le capteur biométrique à la disposition des applications tierces.
Si les implémentations d'appareils souhaitent traiter un capteur biométrique comme un capteur de classe 3 (anciennement Fort), elles doivent:
- [C-3-1] DOIT respecter toutes les exigences de la classe 2 ci-dessus, à l'exception de [C-1-7] et [C-1-8].
- [C-3-2] L'implémentation du keystore doit être basée sur du matériel.
- [C-3-3] DOIT avoir un taux d'acceptation des attaques par falsification et par usurpation d'identité inférieur à 7%, avec (1) un taux d'acceptation des attaques par falsification et par usurpation d'identité pour les espèces d'instruments d'attaque par falsification de l'identité (PAI) de niveau A inférieur à 7 % et (2) un taux d'acceptation des attaques par falsification et par usurpation d'identité des espèces de PAI de niveau B inférieur à 20%, mesuré par les protocoles de test biométriques Android.
- [C-3-4] DOIT demander à l'utilisateur de fournir l'authentification primaire recommandée (par exemple, un code, un schéma ou un mot de passe) toutes les 72 heures ou moins.
- [C-3-5] L'ID de l'authentificateur doit être généré à nouveau pour toutes les biométries de classe 3 compatibles sur l'appareil si l'une d'elles est réenregistrée.
- [C-3-6] Les clés du keystore basées sur la biométrie doivent être activées pour les applications tierces.
- [C-SR-16] Il est FORTEMENT RECOMMANDÉ de définir un taux d'acceptation des attaques par falsification et usurpation d'identité ne dépassant pas 7% par type d'instrument d'attaque par présentation (PAI), tel que mesuré par les protocoles de test biométriques Android.
Si les implémentations de l'appareil contiennent un lecteur d'empreinte digitale sous l'écran (UDFPS), elles:
- [C-SR-11] FORTEMENT RECOMMANDÉ pour éviter que la zone tactile de l'UDFPS n'interfère avec la navigation à trois boutons (que certains utilisateurs peuvent nécessiter à des fins d'accessibilité).
7.3.11. Capteur de position
Implémentations de l'appareil:
- Peut être compatible avec un capteur de position à six degrés de liberté.
Si les implémentations d'appareils sont compatibles avec un capteur de position à six degrés de liberté, elles:
- [C-1-1] DOIT implémenter et signaler le capteur
TYPE_POSE_6DOF
. - [C-1-2] DOIT être plus précis que le vecteur de rotation seul.
7.3.12. Capteur d'angle de charnière
Si les implémentations de l'appareil sont compatibles avec un capteur d'angle de charnière, elles:
- [C-1-1] DOIT implémenter et signaler
TYPE_HINGLE_ANGLE
. - [C-1-2] DOIT prendre en charge au moins deux lectures entre 0 et 360 degrés (inclus, c'est-à-dire y compris 0 et 360 degrés).
- [C-1-3] DOIT renvoyer un capteur de réveil pour
getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE)
.
7.3.13. IEEE 802.1.15.4 (UWB)
Si les implémentations d'appareils incluent la prise en charge de la norme 802.1.15.4 et exposent la fonctionnalité à une application tierce, elles:
- [C-1-2] DOIT signaler l'indicateur de fonctionnalité matérielle
android.hardware.uwb
. - [C-1-3] DOIT prendre en charge tous les ensembles de configuration suivants (combinaisons prédéfinies de paramètres FIRA UCI) définis dans l'implémentation AOSP.
CONFIG_ID_1
: portéeSTATIC STS DS-TWR
unicast définie par FiRa, mode différé, intervalle de mesure de la portée de 240 ms.CONFIG_ID_2
: portéeSTATIC STS DS-TWR
de un à plusieurs définie par FiRa, mode différé, intervalle de mesure de la portée de 200 ms. Cas d'utilisation type: un smartphone interagit avec de nombreux appareils connectés.CONFIG_ID_3
: identique àCONFIG_ID_1
, sauf que les données d'angle d'arrivée (AoA) ne sont pas enregistrées.CONFIG_ID_4
: identique àCONFIG_ID_1
, sauf que le mode de sécurité P-STS est activé.CONFIG_ID_5
: identique àCONFIG_ID_2
, sauf que le mode de sécurité P-STS est activé.CONFIG_ID_6
: identique àCONFIG_ID_3
, sauf que le mode de sécurité P-STS est activé.CONFIG_ID_7
: identique àCONFIG_ID_2
, sauf que le mode de clé de contrôle individuelle P-STS est activé.
- [C-1-4] DOIT fournir une affordance utilisateur permettant à l'utilisateur d'activer ou de désactiver la radio UWB.
- [C-1-5] Les applications utilisant la radio UWB doivent OBLIGATOIREMENT disposer de l'autorisation
UWB_RANGING
(dans le groupe d'autorisationsNEARBY_DEVICES
).
Réussir les tests de conformité et de certification pertinents définis par les organisations de normalisation, y compris la FIRA, la CCC et la CSA, permet de s'assurer que la norme 802.1.15.4 fonctionne correctement.
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 lié à la réalisation d'appels vocaux et à l'envoi de messages SMS, ou à l'établissement de données mobiles via un réseau mobile (par exemple, GSM, CDMA, LTE, NR). Un appareil compatible avec la "téléphonie" peut choisir d'offrir tout ou partie des services d'appel, de messagerie et de données en fonction du produit.
- Android peut être utilisé sur des appareils qui n'incluent pas de matériel de téléphonie. Autrement dit, Android est compatible avec des appareils autres que des téléphones.
Si les implémentations d'appareils incluent la téléphonie GSM ou CDMA, elles:
- [C-1-1] DOIT déclarer le flag de fonctionnalité
android.hardware.telephony
et les autres sous-flags de fonctionnalité en fonction de la technologie. - [C-1-2] DOIT implémenter une compatibilité complète avec l'API de cette technologie.
- DOIT autoriser tous les types de services mobiles disponibles (2G, 3G, 4G, 5G, etc.) lors des 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, elles:
- [C-2-1] Vous DEVEZ implémenter l'intégralité des API 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 pour rendre la fonctionnalité eSIM disponible pour les développeurs tiers, elles:
- [C-3-1] Vous devez déclarer le commutateur de fonctionnalité
android.hardware.telephony.euicc
.
Si les implémentations d'appareils ne définissent pas la propriété système ro.telephony.iwlan\_operation\_mode
sur "ancienne", elles:
- [C-4-1] NE DOIT PAS signaler NETWORK_TYPE_IWLAN via NetworkRegistrationInfo#getAccessNetworkTechnology() lorsque NetworkRegistrationInfo#getTransportType() est signalé comme TRANSPORT_TYPE_WWAN pour la même instance NetworkRegistrationInfo.
Si les implémentations d'appareils acceptent un seul enregistrement IMS (IP Multimedia Subsystem) pour les fonctionnalités de service de téléphonie multimédia (MMTEL) et de service de communication enrichi (RCS) et doivent respecter les exigences des opérateurs de téléphonie mobile concernant l'utilisation d'un seul enregistrement IMS pour tout le trafic de signalisation IMS, elles:
- [C-5-1] DOIT déclarer le flag de fonctionnalité
android.hardware.telephony.ims
et fournir une implémentation complète de l'API ImsService pour MMTEL et l'API User Capability Exchange du RCS. - [C-5-2] DOIT déclarer le flag de fonctionnalité
android.hardware.telephony.ims.singlereg
et fournir une implémentation complète de l'API SipTransport, de l'API GbaService, des indications de porteuses dédiées à l'aide du HAL IRadio 1.6 et du provisionnement via un serveur de configuration automatique (ACS) ou un autre mécanisme de provisionnement propriétaire à l'aide de l'API de configuration IMS.
Si les implémentations de l'appareil signalent la fonctionnalité android.hardware.telephony
:
- [C-6-1] Les
SmsManager#sendTextMessage
etSmsManager#sendMultipartTextMessage
doivent entraîner des appels correspondants àCarrierMessagingService
pour fournir la fonctionnalité de messagerie.SmsManager#sendMultimediaMessage
etSmsManager#downloadMultimediaMessage
DOIVENT entraîner des appels correspondants àCarrierMessagingService
pour fournir la fonctionnalité de messagerie multimédia. - [C-6-2] L'application désignée par
android.provider.Telephony.Sms#getDefaultSmsPackage
DOIT utiliser les API SmsManager lors de l'envoi et de la réception de messages SMS et MMS. L'implémentation de référence AOSP dans packages/apps/Messaging répond à cette exigence. - [C-6-3] L'application qui répond à
Intent#ACTION_DIAL
DOIT accepter la saisie de codes de numérotation arbitraires au format*#*#CODE#*#*
et déclencher une diffusionTelephonyManager#ACTION_SECRET_CODE
correspondante. - [C-6-4] L'application qui répond à
Intent#ACTION_DIAL
DOIT utiliserVoicemailContract.Voicemails#TRANSCRIPTION
pour afficher la transcription de la messagerie vocale visuelle aux utilisateurs si elle est compatible avec cette fonctionnalité. - [C-6-5] DOIT représenter tous les SubscriptionInfo avec des UUID de groupe équivalents en tant qu'abonnement unique dans toutes les affordances visibles par l'utilisateur qui affichent et contrôlent les informations de la carte SIM. Exemples de telles affordances : interfaces de paramètres correspondant à
Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS
ouEuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
. - [C-6-6] NE DOIT PAS afficher ni autoriser le contrôle de tout SubscriptionInfo avec un UUID de groupe non nul et un bit opportuniste dans toutes les affordances visibles par l'utilisateur qui permettent de configurer ou de contrôler les paramètres de la carte SIM.
Si les implémentations de l'appareil signalent la fonctionnalité android.hardware.telephony
et fournissent une barre d'état du système, procédez comme suit:
- [C-7-1] DOIT sélectionner un abonnement actif représentatif pour un UUID de groupe donné à afficher auprès de l'utilisateur dans toutes les affordances fournissant des informations sur l'état de la SIM. La barre d'état de l'icône du signal de téléphonie mobile ou la carte des paramètres rapides sont des exemples de telles affordances.
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ de choisir l'abonnement aux données actif comme abonnement représentant, sauf si l'appareil est en appel vocal, auquel cas il est FORTEMENT RECOMMANDÉ de choisir l'abonnement vocal actif comme abonnement représentant.
Si les implémentations de l'appareil signalent la fonctionnalité android.hardware.telephony
:
- [C-6-7] DOIT être capable d'ouvrir et d'utiliser simultanément le nombre maximal de canaux logiques (20 au total) pour chaque UICC, conformément à la norme ETSI TS 102 221.
- [C-6-8] N'appliquez PAS automatiquement ni sans confirmation explicite de l'utilisateur l'un des comportements suivants aux applications de l'opérateur actives (comme indiqué par
TelephonyManager#getCarrierServicePackageName
) :- Révoquer ou limiter l'accès au réseau
- Révoquer des autorisations
- Limiter l'exécution des 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 de l'appareil signalent la fonctionnalité android.hardware.telephony
et que tous les abonnements non opportunistes actifs qui partagent un UUID de groupe sont désactivés, supprimés physiquement de l'appareil ou marqués comme opportunistes, l'appareil:
- [C-8-1] DOIT désactiver automatiquement tous les abonnements opportunistes actifs restants du même groupe.
Si les implémentations de l'appareil incluent la téléphonie GSM, mais pas la téléphonie CDMA:
- [C-9-1] NE DOIT PAS déclarer
PackageManager#FEATURE_TELEPHONY_CDMA
. - [C-9-2] DOIT générer une exception
IllegalArgumentException
lors de tentatives de définition de types de réseau 3GPP2 dans des masques de bits de type de réseau préférés ou autorisés. - [C-9-3] DOIT renvoyer une chaîne vide à partir de
TelephonyManager#getMeid
.
Si les implémentations de l'appareil sont compatibles avec les eUICC avec plusieurs ports et profils, elles:
- [C-10-1] Vous DEVEZ déclarer l'indicateur de fonctionnalité
android.hardware.telephony.euicc.mep
.
7.4.1.1. 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 la fonctionnalité de blocage des numéros
- [C-1-2] DOIT implémenter entièrement
BlockedNumberContract
et l'API correspondante, comme décrit dans la documentation du SDK. [C-1-3] DOIT bloquer tous les appels et messages provenant d'un numéro de téléphone dans 'BlockedNumberProvider' sans aucune interaction avec les applications. La seule exception est lorsque le blocage des numéros est temporairement levé, comme décrit dans la documentation du SDK.
[C-1-4] DOIT écrire au fournisseur du journal des appels de la plate-forme pour un appel bloqué et DOIT filtrer les appels avec
BLOCKED_TYPE
en dehors de la vue du journal des appels par défaut dans l'application Téléphone préinstallée.[C-1-5] NE DOIT PAS écrire au fournisseur de téléphonie pour un message bloqué.
[C-1-6] DOIT implémenter une UI de gestion des numéros bloqués, qui est ouverte avec l'intent renvoyé par la méthode
TelecomManager.createManageBlockedNumbersIntent()
.[C-1-7] NE DOIT PAS permettre aux utilisateurs secondaires de consulter ni de modifier les numéros bloqués sur l'appareil, car la plate-forme Android suppose que l'utilisateur principal a le contrôle total des services de téléphonie, une seule instance, sur l'appareil. L'interface utilisateur liée au blocage DOIT être masquée pour les utilisateurs secondaires, et la liste de blocage DOIT toujours être respectée.
DOIT migrer les numéros bloqués vers le fournisseur lorsqu'un appareil passe à Android 7.0.
DOIT fournir une affordance utilisateur pour afficher les appels bloqués dans l'application du téléphone préinstallée.
7.4.1.2. API Telecom
Si les implémentations d'appareils signalent android.hardware.telephony.calling
, elles:
- [C-1-1] DOIT être compatible avec les API
ConnectionService
décrites dans le SDK. - [C-1-2] DOIT afficher un nouvel appel entrant et fournir à l'utilisateur la possibilité d'accepter ou de refuser l'appel entrant lorsque l'utilisateur est en ligne avec une application tierce qui n'est pas compatible avec la fonctionnalité de mise en attente spécifiée via
CAPABILITY_SUPPORT_HOLD
. - [C-1-3] L'application doit implémenter InCallService.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ d'informer l'utilisateur que répondre à un appel entrant mettra fin à un appel en cours.
L'implémentation AOSP répond à ces exigences par une notification d'alerte qui indique à l'utilisateur que répondre à un appel entrant entraînera l'abandon de l'autre appel.
[C-SR-2] Il est FORTEMENT RECOMMANDÉ de précharger l'application de numérotation par défaut qui affiche une entrée de journal des appels et le nom d'une application tierce dans son journal des appels lorsque l'application tierce définit la clé supplémentaire
EXTRA_LOG_SELF_MANAGED_CALLS
surPhoneAccount
surtrue
.[C-SR-3] Il est FORTEMENT RECOMMANDÉ de gérer les événements
KEYCODE_MEDIA_PLAY_PAUSE
etKEYCODE_HEADSETHOOK
du casque audio pour les APIandroid.telecom
comme suit:- Appelez
Connection.onDisconnect()
lorsqu'un appui bref sur l'événement de touche est détecté pendant un appel en cours. - Appelez
Connection.onAnswer()
lorsqu'un appui bref sur l'événement de touche est détecté lors d'un appel entrant. - Appelez
Connection.onReject()
lorsqu'un appui prolongé sur l'événement de touche est détecté lors d'un appel entrant. - Activez/Désactivez le son de
CallAudioState
.
- Appelez
7.4.1.3. Déchargement du keepalive NAT-T sur le réseau mobile
Implémentations de l'appareil:
- DOIT inclure la prise en charge de l'externalisation du keepalive cellulaire.
Si les implémentations d'appareils prennent en charge le transfert de keepalive mobile et exposent la fonctionnalité aux applications tierces, elles:
- [C-1-1] DOIT être compatible avec l'API SocketKeepAlive.
- [C-1-2] DOIT prendre en charge au moins un slot keepalive simultané sur le réseau mobile.
- [C-1-3] DOIT prendre en charge autant d'emplacements de keepalive mobiles simultanés que la HAL de la radio mobile.
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge au moins trois emplacements de keepalive mobile par instance radio.
Si les implémentations d'appareils n'incluent pas la prise en charge de l'externalisation du keepalive mobile, elles:
- [C-2-1] DOIT renvoyer ERROR_UNSUPPORTED.
7.4.2. IEEE 802.11 (Wi-Fi)
Implémentations de l'appareil:
- DOIT inclure la prise en charge d'une ou de plusieurs formes de 802.11.
Si les implémentations d'appareils incluent la prise en charge de la norme 802.11 et exposent la fonctionnalité à une application tierce, elles:
- [C-1-1] DOIT implémenter l'API Android correspondante.
- [C-1-2] DOIT signaler l'indicateur de fonctionnalité matérielle
android.hardware.wifi
. - [C-1-3] Vous DEVEZ implémenter l'API multicast comme décrit dans la documentation du SDK.
Début des nouvelles exigences pour Android 15
- [C-1-4] DOIT prendre en charge le DNS multicast (mDNS) et NE DOIT PAS filtrer les paquets mDNS (224.0.0.251 ou ff02::fb) à tout moment de l'opération, y compris lorsque l'écran n'est pas à l'état actif, sauf si l'abandon ou le filtrage de ces paquets est nécessaire pour respecter les limites de consommation d'énergie requises par les exigences réglementaires applicables au marché cible.
- [C-1-4] DOIT être compatible avec le mDNS et NE DOIT PAS filtrer les paquets mDNS (224.0.0.251 ou ff02::fb) à tout moment de l'opération, y compris lorsque l'écran n'est pas à l'état actif, sauf si le verrouillage multicast n'est pas maintenu et que les paquets sont filtrés par APF. Les paquets ne sont pas nécessaires pour répondre à toute opération mDNS actuellement demandée par les applications via les API NsdManager. Toutefois, l'appareil PEUT filtrer les paquets mDNS si cela est nécessaire pour respecter les plages de consommation d'énergie requises par les exigences réglementaires applicables au marché cible.
Fin des nouvelles exigences
- [C-1-5] NE DOIT PAS traiter l'appel de la méthode d'API
WifiManager.enableNetwork()
comme une indication suffisante pour changer leNetwork
actuellement actif, qui est utilisé par défaut pour le trafic de l'application et est renvoyé par les méthodes d'APIConnectivityManager
telles quegetActiveNetwork
etregisterDefaultNetworkCallback
. En d'autres termes, ils ne peuvent désactiver l'accès à Internet fourni par un autre fournisseur de réseau (par exemple, les données mobiles) que s'ils valident avec succès que le réseau Wi-Fi fournit un accès à Internet. - [C-1-6] Il est FORTEMENT RECOMMANDÉ, lorsque la méthode de l'API
ConnectivityManager.reportNetworkConnectivity()
est appelée, de réévaluer l'accès à Internet sur leNetwork
et, une fois que l'évaluation détermine que leNetwork
actuel ne fournit plus d'accès à Internet, de passer à un autre réseau disponible (par exemple, les données mobiles) qui fournit un accès à Internet. - [C-1-7] DOIT randomiser l'adresse MAC source et le numéro de séquence des trames de requête de sonde, une fois au début de chaque analyse, lorsque l'unité STA est déconnectée.
- [C-1-8] DOIT utiliser une adresse MAC cohérente (NE DOIT PAS randomiser l'adresse MAC à mi-parcours d'une analyse).
- [C-1-9] DOIT itérer le numéro de séquence de la requête de sonde comme d'habitude (séquentiellement) entre les requêtes de sonde d'une analyse.
- [C-1-10] DOIT randomiser le numéro de séquence de la requête de sonde entre la dernière requête de sonde d'une analyse et la première requête de sonde de l'analyse suivante.
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ de randomiser l'adresse MAC source utilisée pour toutes les communications STA avec un point d'accès (PA) lors de l'association et de l'association.
- 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 une option permettant de contrôler la randomisation par SSID (FQDN pour Passpoint) avec des options non randomisées et randomisées, et DOIT définir le mode par défaut pour que les nouvelles configurations Wi-Fi soient randomisées.
- [C-SR-2] Il est vivement recommandé d'utiliser un BSSID aléatoire pour tous les points d'accès qu'il crée.
- L'adresse MAC DOIT être randomisée et persistante par SSID utilisé par l'AP.
- L'APPAREIL PEUT offrir à 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 incluent la prise en charge du mode économie d'énergie Wi-Fi tel que défini dans la norme IEEE 802.11, elles:
- DOIT désactiver le mode d'économie d'énergie du Wi-Fi chaque fois qu'une application acquiert un verrouillage
WIFI_MODE_FULL_HIGH_PERF
ouWIFI_MODE_FULL_LOW_LATENCY
via les APIWifiManager.createWifiLock()
etWifiManager.WifiLock.acquire()
, et que le verrouillage est actif. - [C-3-2] La latence aller-retour moyenne entre l'appareil et un point d'accès lorsque l'appareil est en mode Verrouillage Wi-Fi à faible latence (
WIFI_MODE_FULL_LOW_LATENCY
) DOIT être inférieure à la latence en mode Verrouillage Wi-Fi hautes performances (WIFI_MODE_FULL_HIGH_PERF
). - [C-SR-3] Ils sont FORTEMENT RECOMMANDÉS pour réduire la latence aller-retour Wi-Fi chaque fois qu'un verrouillage à faible latence (
WIFI_MODE_FULL_LOW_LATENCY
) est acquis et prend effet.
Si les implémentations d'appareils sont compatibles avec le Wi-Fi et l'utilisent pour la recherche de position, elles:
- [C-2-1] DOIT fournir une affordance utilisateur pour activer/désactiver la valeur lue via la méthode API
WifiManager.isScanAlwaysAvailable
.
7.4.2.1. Wi-Fi Direct
Implémentations de l'appareil:
- DOIT inclure la prise en charge de Wi-Fi Direct (Wi-Fi peer-to-peer).
Si les implémentations d'appareils sont compatibles avec Wi-Fi Direct, elles:
- [C-1-1] DOIT implémenter l'API Android correspondante comme décrit dans la documentation du SDK.
- [C-1-2] DOIT signaler la fonctionnalité matérielle
android.hardware.wifi.direct
. - [C-1-3] DOIT être compatible avec le fonctionnement normal du Wi-Fi.
- [C-1-4] DOIT prendre en charge les opérations Wi-Fi et Wi-Fi Direct simultanément.
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ de randomiser l'adresse MAC source pour toutes les nouvelles connexions Wi-Fi Direct.
7.4.2.2. Configuration du lien direct en tunnel Wi-Fi
Implémentations de l'appareil:
- DOIT inclure la compatibilité avec la configuration de liaison directe en tunnel Wi-Fi (TDLS), comme décrit dans la documentation du SDK Android.
Si les implémentations de l'appareil incluent la prise en charge de TDLS et que TDLS est activé par l'API WiFiManager, elles:
- [C-1-1] DOIT déclarer la prise en charge de TDLS via
WifiManager.isTdlsSupported
. - Vous DEVEZ utiliser TDLS uniquement lorsque c'est possible ET avantageux.
- DOIT avoir une heuristique et NE PAS utiliser TDLS lorsque ses performances peuvent être inférieures à celles du point d'accès Wi-Fi.
7.4.2.3. Wi-Fi Aware
Implémentations de l'appareil:
- DOIT inclure la prise en charge de Wi-Fi Aware.
Si les implémentations d'appareils sont compatibles avec Wi-Fi Aware et exposent la fonctionnalité aux applications tierces, elles:
- [C-1-1] Vous DEVEZ implémenter les API
WifiAwareManager
comme décrit dans la documentation du SDK. - [C-1-2] Vous DEVEZ déclarer l'option de fonctionnalité
android.hardware.wifi.aware
. - [C-1-3] DOIT prendre en charge les opérations Wi-Fi et Wi-Fi Aware simultanément.
- [C-1-4] DOIT randomiser l'adresse de l'interface de gestion Wi-Fi Aware à des intervalles de 30 minutes maximum et chaque fois que Wi-Fi Aware est activé, sauf si une opération de mesure de la portée Aware est en cours ou si un chemin de données Aware est actif (la randomisation n'est pas attendue tant que le chemin de données est actif).
Si les implémentations de l'appareil sont compatibles avec Wi-Fi Aware et la localisation Wi-Fi, comme décrit dans la section 7.4.2.5, et qu'elles exposent ces fonctionnalités aux applications tierces, elles:
- [C-2-1] DOIT implémenter les API de découverte basée sur la position: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm et onServiceDiscoveredWithinRange.
7.4.2.4. Wi-Fi Passpoint
Si les implémentations de l'appareil sont compatibles avec la norme 802.11 (Wi-Fi), elles:
- [C-1-1] DOIT être compatible avec Wi-Fi Passpoint.
- [C-1-2] DOIT implémenter les API
WifiManager
liées à Passpoint comme décrit dans la documentation du SDK. - [C-1-3] DOIT être compatible avec la norme IEEE 802.11u, en particulier en ce qui concerne la découverte et la sélection de réseaux, tels que le service d'annonces génériques (GAS, Generic Advertisement Service) et le protocole ANQP (Access Network Query Protocol).
- [C-1-4] Vous devez déclarer le commutateur de fonctionnalité
android.hardware.wifi.passpoint
. - [C-1-5] DOIT suivre l'implémentation AOSP pour détecter, faire correspondre et associer des réseaux Passpoint.
- [C-1-6] DOIT prendre en charge au moins le sous-ensemble de protocoles de provisionnement d'appareils suivant, tel que défini dans la version R2 de la norme Passpoint de la Wi-Fi Alliance: authentification EAP-TTLS et SOAP-XML.
- [C-1-7] DOIT traiter le certificat du serveur AAA comme décrit dans la spécification Hotspot 2.0 R3.
- [C-1-8] DOIT permettre à l'utilisateur de contrôler le provisionnement via le sélecteur Wi-Fi.
- [C-1-9] Les configurations Passpoint doivent être conservées lors des redémarrages.
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge la fonctionnalité d'acceptation des conditions d'utilisation.
- [C-SR-2] Il est FORTEMENT RECOMMANDÉ de prendre en charge la fonctionnalité d'informations sur les lieux.
Si un bouton de désactivation de la commande utilisateur Passpoint global est fourni, les implémentations:
- [C-3-1] Le point d'accès doit être activé par défaut.
7.4.2.5. Position Wi-Fi (délai aller-retour Wi-Fi, RTT)
Implémentations de l'appareil:
- DOIT inclure la prise en charge de la position Wi-Fi.
Si les implémentations de l'appareil sont compatibles avec la localisation Wi-Fi et exposent la fonctionnalité aux applications tierces, elles:
- [C-1-1] Vous DEVEZ implémenter les API
WifiRttManager
comme décrit dans la documentation du SDK. - [C-1-2] Vous DEVEZ déclarer l'option de fonctionnalité
android.hardware.wifi.rtt
. - [C-1-3] L'adresse MAC source doit être RANDONNÉE pour chaque rafale RTT exécutée lorsque l'interface Wi-Fi sur laquelle le RTT est exécuté n'est pas associée à un point d'accès.
- [C-1-4] DOIT être précis à ± 2 mètres pour une bande passante de 80 MHz au 68e percentile (calculé avec la fonction de distribution cumulative).
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ de le signaler avec une précision de 1,5 mètre à une bande passante de 80 MHz au 68e percentile (calculé avec la fonction de distribution cumulée).
7.4.2.6. Déchargement du keepalive Wi-Fi
Implémentations de l'appareil:
- DOIT inclure la prise en charge de l'externalisation du keepalive Wi-Fi.
Si les implémentations d'appareils prennent en charge le transfert de keepalive Wi-Fi et exposent la fonctionnalité aux applications tierces, elles:
- [C-1-1] DOIT être compatible avec l'API SocketKeepAlive.
- [C-1-2] DOIT prendre en charge au moins trois emplacements keepalive simultanés via le Wi-Fi
Si les implémentations d'appareils n'incluent pas la prise en charge de l'externalisation du keepalive Wi-Fi, elles:
- [C-2-1] DOIT renvoyer
ERROR_UNSUPPORTED
.
7.4.2.7. Wi-Fi Easy Connect (protocole de provisionnement d'appareils)
Implémentations de l'appareil:
- DOIT inclure la prise en charge de Wi-Fi Easy Connect (DPP).
Si les implémentations d'appareils sont compatibles avec Wi-Fi Easy Connect et exposent la fonctionnalité aux applications tierces, elles:
- [C-1-1] La méthode WifiManager#isEasyConnectSupported() DOIT renvoyer
true
.
7.4.2.8. Validation du certificat de serveur Wi-Fi d'entreprise
Si le certificat du serveur Wi-Fi n'est pas validé ou si le nom de domaine du serveur Wi-Fi n'est pas défini, les implémentations de l'appareil:
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ de ne pas proposer à l'utilisateur la possibilité d'ajouter manuellement un réseau Wi-Fi d'entreprise dans l'application Paramètres.
7.4.2.9. Trust On First Use (TOFU)
Si les implémentations d'appareils sont compatibles avec la confiance lors du premier usage (TOFU) et permettent à l'utilisateur de définir des configurations WPA/WPA2/WPA3-Enterprise, elles:
- [C-4-1] DOIT fournir à l'utilisateur une option lui permettant d'utiliser le tofu.
7.4.3. Bluetooth
Si les implémentations de l'appareil sont compatibles avec le profil Bluetooth Audio, elles:
- DOIT être compatible avec les codecs audio avancés et les codecs audio Bluetooth (par exemple, LDAC)
Si les implémentations de l'appareil sont compatibles avec HFP, A2DP et AVRCP:
- DOIT être compatible avec au moins cinq appareils connectés au total.
Si les implémentations d'appareils déclarent la fonctionnalité android.hardware.vr.high_performance
, elles:
- [C-1-1] DOIT être compatible avec Bluetooth 4.2 et l'extension de la longueur des données Bluetooth LE.
Android est compatible avec le Bluetooth et le Bluetooth à basse consommation.
Si les implémentations de l'appareil incluent la prise en charge du Bluetooth et du Bluetooth à basse consommation, elles:
- [C-2-1] Vous DEVEZ déclarer les fonctionnalités de plate-forme pertinentes (
android.hardware.bluetooth
etandroid.hardware.bluetooth_le
respectivement) et implémenter les API de la plate-forme. - DOIT implémenter les profils Bluetooth pertinents tels que A2DP, AVRCP, OBEX, HFP, etc., en fonction de l'appareil.
Si les implémentations de l'appareil sont compatibles avec le Bluetooth à basse consommation (BLE), elles:
- [C-3-1] DOIT déclarer la fonctionnalité matérielle
android.hardware.bluetooth_le
. - [C-3-2] DOIT activer les API Bluetooth basées sur le GATT (Generic Attribute Profile) comme décrit dans la documentation du SDK et dans android.bluetooth.
- [C-3-3] DOIT indiquer la valeur correcte pour
BluetoothAdapter.isOffloadedFilteringSupported()
pour indiquer si la logique de filtrage des classes d'API ScanFilter est implémentée. - [C-3-4] DOIT indiquer la valeur correcte pour
BluetoothAdapter.isMultipleAdvertisementSupported()
afin d'indiquer si la publicité à faible consommation est prise en charge. [C-3-5] DOIT implémenter un délai avant expiration de l'adresse privée résoluble (RPA) de 15 minutes maximum et faire pivoter l'adresse à l'expiration pour protéger la confidentialité des utilisateurs lorsque l'appareil utilise activement le BLE pour l'analyse ou la publicité. Pour éviter les attaques par cassage de délai, les intervalles de délai DOIVENT également être randomisés entre cinq et 15 minutes.
DOIT prendre en charge le transfert de la logique de filtrage vers le chipset Bluetooth lors de l'implémentation de l'API ScanFilter.
DOIT prendre en charge le transfert de l'analyse groupée vers le chipset Bluetooth.
DOIT prendre en charge les annonces multiples avec au moins quatre emplacements.
Si les implémentations d'appareils sont compatibles avec le Bluetooth LE et utilisent le Bluetooth LE pour la localisation, elles:
- [C-4-1] DOIT fournir une affordance utilisateur pour activer/désactiver la valeur lue via l'API système
BluetoothAdapter.isBleScanAlwaysAvailable()
.
Si les implémentations d'appareils incluent la prise en charge du Bluetooth LE et du profil d'appareils auditifs, comme décrit dans la section Compatibilité audio des appareils auditifs avec Bluetooth LE, elles:
- [C-5-1] DOIT renvoyer
true
pour BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).
Si les implémentations de l'appareil incluent la prise en charge du Bluetooth ou du Bluetooth à basse consommation, elles:
- [C-6-1] DOIT restreindre l'accès à toutes les métadonnées Bluetooth (telles que les résultats de la recherche) qui pourraient être utilisées pour déduire la position de l'appareil, sauf si l'application à l'origine de la demande réussit une vérification d'autorisation
android.permission.ACCESS_FINE_LOCATION
en fonction de son état actuel en premier plan/en 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'il ne dérive pas la position à partir du Bluetooth, les développeurs doivent:
- [C-6-2] L'accès au Bluetooth doit être contrôlé derrière le
android.permission.ACCESS_FINE_LOCATION
.
Si les implémentations de l'appareil renvoient true
pour l'API BluetoothAdapter.isLeAudioSupported()
, elles:
- [C-7-1] DOIT prendre en charge le client unicast.
- [C-7-2] DOIT être compatible avec la PHY 2 M.
- [C-7-3] DOIT prendre en charge la publicité étendue LE.
- [C-7-4] DOIT prendre en charge au moins deux connexions CIS dans un CIG.
- [C-7-5] DOIT activer simultanément le client unicast BAP, le coordinateur de groupe CSIP, le serveur MCP, le contrôleur VCP et le serveur CCP.
- [C-SR-1] Nous vous RECOMMANDONS vivement d'activer le client unicast HAP.
Si les implémentations de l'appareil renvoient true
pour l'API BluetoothAdapter.isLeAudioBroadcastSourceSupported()
, elles:
- [C-8-1] DOIT prendre en charge au moins deux liens BIS dans un BIG.
- [C-8-2] DOIT activer simultanément la source de diffusion BAP et l'assistant de diffusion BAP.
- [C-8-3] DOIT prendre en charge la publicité périodique LE.
Si les implémentations de l'appareil renvoient true
pour l'API BluetoothAdapter.isLeAudioBroadcastAssistantSupported()
, elles:
- [C-9-1] DOIT être compatible avec PAST (Periodic Advertising Sync Transfer).
- [C-9-2] DOIT être compatible avec la publicité périodique LE.
Si les implémentations d'appareil déclarent FEATURE_BLUETOOTH_LE
, elles:
- [C-10-1] Les mesures RSSI doivent se situer entre +/-9 dB pour 95% des mesures à une distance de 1 m d'un appareil de référence transmettant à
ADVERTISE_TX_POWER_HIGH
dans un environnement en visibilité directe. - [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ées), soient comprises entre +/-3 dB les unes des autres pour 95% des mesures.
- [C-SR-2] Il est FORTEMENT RECOMMANDÉ de mesurer et de compenser le décalage de réception pour s'assurer que le RSSI BLE médian est de -60 dBm +/- 10 dB à 1 m d'un appareil de référence transmettant à
ADVERTISE_TX_POWER_HIGH
, où les appareils sont orientés de sorte qu'ils se trouvent sur des "plans parallèles", les écrans étant orientés dans la même direction. - [C-SR-3] Il est FORTEMENT RECOMMANDÉ de mesurer et de compenser le décalage de transmission pour s'assurer que le RSSI BLE médian est de -60 dBm +/- 10 dB lors de la numérisation à partir d'un appareil de référence situé à 1 m et transmettant à
ADVERTISE_TX_POWER_HIGH
, où les appareils sont orientés de sorte qu'ils se trouvent sur des "plans parallèles", leurs écrans étant orientés dans la même direction.
Nous vous RECOMMANDONS vivement de suivre la procédure de configuration des mesures spécifiée dans la section Conditions requises pour le calibrage de la présence.
7.4.4. Communication en champ proche
Implémentations de l'appareil:
- DOIT inclure un transceiver et du matériel associé pour la communication en champ proche (NFC).
- [C-0-1] Vous DEVEZ implémenter les API
android.nfc.NdefMessage
etandroid.nfc.NdefRecord
, même si elles n'incluent pas la compatibilité avec la technologie NFC ni ne déclarent la fonctionnalitéandroid.hardware.nfc
, car les classes représentent un format de représentation des données indépendant du protocole.
Si les implémentations d'appareils incluent du matériel NFC et prévoient de le mettre à la disposition d'applications tierces, elles:
- [C-1-1] Vous DEVEZ signaler la fonctionnalité
android.hardware.nfc
à partir de la méthodeandroid.content.pm.PackageManager.hasSystemFeature()
. - DOIT être capable de lire et d'écrire des messages NDEF via les normes NFC suivantes, comme indiqué ci-dessous:
- [C-1-2] DOIT être capable de fonctionner comme lecteur/enregistreur NFC Forum (tel que défini par la spécification technique du NFC Forum NFCForum-TS-DigitalProtocol-1.0) via les normes NFC suivantes :
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- Types de tags NFC Forum 1, 2, 3, 4 et 5 (définis par le forum NFC)
[C-SR-1] Il est vivement recommandé de pouvoir lire et écrire des messages NDEF ainsi que des données brutes via les normes NFC suivantes. Notez que, bien que les normes NFC soient définies comme "FORTEMENT RECOMMANDÉES", la définition de la compatibilité pour une future version prévoit de les remplacer par "OBLIGATOIRE". Ces normes sont facultatives dans cette version, mais elles seront obligatoires dans les versions ultérieures. Nous vous recommandons vivement de respecter ces exigences dès maintenant pour les appareils existants et les nouveaux qui exécutent cette version d'Android afin qu'ils puissent passer aux futures versions de la plate-forme.
[C-1-13] DOIT interroger toutes les technologies compatibles en mode découverte NFC.
DOIT être en mode découverte NFC lorsque l'appareil est actif, l'écran actif et l'écran de verrouillage déverrouillé.
DOIT être en mesure de lire le code-barres et l'URL (si encodés) des produits code-barres NFC Thinfilm.
Notez que les liens publics ne sont pas disponibles pour les spécifications JIS, ISO et NFC Forum citées ci-dessus.
Android est compatible avec le mode 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 de l'ID d'application (AID), elles:
- [C-2-1] DOIT indiquer la constante de fonctionnalité
android.hardware.nfc.hce
. - [C-2-2] DOIT prendre en charge les API NFC HCE telles que définies dans le SDK Android.
Si les implémentations d'appareils incluent un chipset de contrôleur NFC compatible avec la technologie HCE pour NfcF et implémentent la fonctionnalité pour les applications tierces, elles:
- [C-3-1] DOIT indiquer la constante de fonctionnalité
android.hardware.nfc.hcef
. - [C-3-2] DOIT implémenter les API d'émulation de carte NfcF telles que définies dans le SDK Android.
Si les implémentations d'appareils incluent la compatibilité NFC générale décrite dans cette section et les technologies MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF sur MIFARE Classic) dans le rôle de lecteur/écrivain, elles:
- [C-4-1] DOIT implémenter les API Android correspondantes, comme indiqué dans la documentation du SDK Android.
- [C-4-2] DOIT signaler la fonctionnalité
com.nxp.mifare
à partir de la méthodeandroid.content.pm.PackageManager.hasSystemFeature
(). Notez qu'il ne s'agit pas d'une fonctionnalité Android standard et qu'elle n'apparaît donc pas en tant que constante dans la classeandroid.content.pm.PackageManager
.
7.4.5. Protocoles et API réseau
7.4.5.1. Capacité réseau minimale
Implémentations de l'appareil:
- [C-0-1] DOIT prendre en charge une ou plusieurs formes de mise en réseau de données. Plus précisément, les implémentations d'appareils DOIVENT prendre en charge au moins une norme de données capable de 200 kbit/s ou plus. EDGE, HSPA, EV-DO, 802.11g, Ethernet et PAN Bluetooth sont des exemples de technologies qui répondent à cette exigence.
- DOIT également prendre en charge au moins une norme de données sans fil courante, telle que 802.11 (Wi-Fi), lorsqu'une norme de réseau physique (telle qu'Ethernet) est la connexion de données principale.
- PEUT implémenter plusieurs formes de connectivité de données.
7.4.5.2. IPv6
Implémentations de l'appareil:
- [C-0-2] DOIT inclure une pile réseau IPv6 et prendre en charge la communication IPv6 à l'aide des API gérées, telles que
java.net.Socket
etjava.net.URLConnection
, ainsi que des API natives, telles que les socketsAF_INET6
. - [C-0-3] Vous devez activer IPv6 par défaut.
- DOIT s'assurer que la communication IPv6 est aussi fiable qu'IPv4, par exemple :
- [C-0-4] La connectivité IPv6 doit être maintenue en mode veille.
- [C-0-5] La limitation de débit NE DOIT PAS entraîner la perte de connectivité IPv6 de l'appareil sur un réseau conforme à la norme IPv6 qui utilise des durées de vie de RA d'au moins 180 secondes.
- DOIT s'assurer que la communication IPv6 est aussi fiable qu'IPv4, par exemple :
- [C-0-6] DOIT fournir aux applications tierces une connectivité IPv6 directe au réseau lorsqu'elles sont connectées à un réseau IPv6, sans aucune forme de traduction d'adresse ou de port localement sur l'appareil. Les API gérées telles que
Socket#getLocalAddress
ouSocket#getLocalPort
, ainsi que les API NDK telles quegetsockname()
ouIPV6_PKTINFO
DOIVENT renvoyer l'adresse IP et le port réellement utilisés pour envoyer et recevoir des paquets sur le réseau, et qui sont visibles en tant qu'adresse IP et port source pour les serveurs Internet (Web).
Le niveau de compatibilité IPv6 requis dépend du type de réseau, comme indiqué dans les exigences suivantes.
Si les implémentations de l'appareil sont compatibles avec le Wi-Fi, elles:
- [C-1-1] DOIT être compatible avec le fonctionnement en double pile et en IPv6 uniquement sur le Wi-Fi.
Si les implémentations de l'appareil sont compatibles avec Ethernet, elles:
- [C-2-1] DOIT prendre en charge le fonctionnement à double pile et IPv6 uniquement sur Ethernet.
Si les implémentations de l'appareil sont compatibles avec les données mobiles, elles:
- [C-3-1] DOIT prendre en charge le fonctionnement IPv6 (IPv6 uniquement et éventuellement double pile) sur le réseau mobile.
Si les implémentations d'appareils sont compatibles avec plusieurs types de réseaux (par exemple, Wi-Fi et données mobiles) :
- [C-4-1] L'appareil DOIT simultanément respecter les exigences ci-dessus sur chaque réseau lorsqu'il est connecté simultanément à plusieurs types de réseaux.
7.4.5.3. Portails captifs
Un portail captif désigne un réseau qui nécessite une connexion pour accéder à Internet.
Si les implémentations d'appareils fournissent une implémentation complète de android.webkit.Webview API
, elles:
- [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 du portail captif, en envoyant cet intent, lors de l'appel de l'API systèmeConnectivityManager#startCaptivePortalApp(Network, Bundle)
. - [C-1-2] DOIT effectuer la détection des portails captifs et prendre en charge la connexion via l'application du portail captif lorsque l'appareil est connecté à n'importe quel type de réseau, y compris un réseau mobile/cellulaire, un réseau Wi-Fi, un réseau Ethernet ou un réseau Bluetooth.
- [C-1-3] DOIT prendre en charge la connexion aux portails captifs à l'aide du DNS en texte clair lorsque l'appareil est configuré pour utiliser le mode strict du DNS privé.
- [C-1-4] Vous devez utiliser un DNS chiffré conformément à la documentation du SDK pour
android.net.LinkProperties.getPrivateDnsServerName
etandroid.net.LinkProperties.isPrivateDnsActive
pour tout trafic réseau qui ne communique pas explicitement avec le portail captif. - [C-1-5] DOIT s'assurer que, lorsque l'utilisateur se connecte à un portail captif, 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 réseau Java telles que java.net.Socket et les API natives telles queconnect()
) 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 de l'appareil:
- [C-0-1] Le paramètre de synchronisation automatique maître doit être activé par défaut pour que la méthode
getMasterSyncAutomatically()
renvoie "true".
7.4.7. Économiseur de données
Si les implémentations d'appareils incluent une connexion limitée, elles sont:
- [C-SR-1] Nous vous recommandons vivement de proposer le mode Économiseur de données.
Si les implémentations de l'appareil fournissent le mode Économiseur de données, elles:
- [C-1-1] DOIT prendre en charge toutes les API de la classe
ConnectivityManager
, comme décrit dans la documentation du SDK
Si les implémentations de l'appareil ne fournissent pas le mode Économiseur de données, elles:
- [C-2-1] DOIT renvoyer la valeur
RESTRICT_BACKGROUND_STATUS_DISABLED
pourConnectivityManager.getRestrictBackgroundStatus()
- [C-2-2] NE DOIT PAS diffuser
ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED
.
7.4.8. Composants sécurisés
Si les implémentations d'appareils sont compatibles avec les éléments sécurisés compatibles avec l'API Open Mobile et les mettent à la disposition des applications tierces, elles:
[C-1-1] DOIT énumérer les lecteurs d'éléments sécurisés disponibles via l'API
android.se.omapi.SEService.getReaders()
.[C-1-2] DOIT déclarer les indicateurs de fonctionnalité appropriés via
android.hardware.se.omapi.uicc
pour l'appareil avec des éléments sécurisés basés sur UICC,android.hardware.se.omapi.ese
pour l'appareil avec des éléments sécurisés basés sur eSE etandroid.hardware.se.omapi.sd
pour l'appareil avec des éléments sécurisés basés sur SD.
7.4.9. UWB
Si les implémentations d'appareils incluent la prise en charge de la norme 802.1.15.4 et exposent la fonctionnalité à une application tierce, elles:
- [C-1-1] DOIT implémenter l'API Android correspondante dans android.uwb.
- [C-1-2] DOIT indiquer l'indicateur de fonctionnalité matérielle android.hardware.uwb.
- [C-1-3] DOIT être compatible avec tous les profils UWB pertinents définis dans l'implémentation Android.
- [C-1-4] DOIT fournir une affordance utilisateur permettant à l'utilisateur d'activer ou de désactiver la radio UWB.
- [C-1-5] Les applications utilisant la radio UWB doivent OBLIGATOIREMENT disposer de l'autorisation UWB_RANGING (dans le groupe d'autorisations NEARBY_DEVICES).
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ de réussir les tests de conformité et de certification pertinents définis par les organismes de normalisation, y compris la FIRA, la CCC et la CSA.
- [C-1-6] DOIT s'assurer que les mesures de distance sont comprises entre +/- 15 cm pour 95 % des mesures dans l'environnement en ligne de mire à une distance de 1 m dans une chambre non réfléchissante.
- [C-1-7] DOIT s'assurer que la médiane des mesures de distance à 1 mètre de l'appareil de référence se situe entre [0,75 m, 1,25 m], où la distance de référence est mesurée à partir du bord supérieur du DUT.
- [C-SR-2] Il est FORTEMENT RECOMMANDÉ de suivre la procédure de configuration des mesures spécifiée dans les Exigences de calibrage de la présence.
7.5. Caméras
Si les implémentations d'appareils incluent au moins une caméra, elles:
- [C-1-1] Vous DEVEZ déclarer le commutateur de fonctionnalité
android.hardware.camera.any
. - [C-1-2] Une application DOIT pouvoir allouer simultanément trois bitmaps RGBA_8888 égaux à la taille des images produites par le capteur d'appareil photo de la plus haute résolution sur l'appareil, lorsque l'appareil photo est ouvert à des fins d'aperçu de base et de capture d'image.
- [C-1-3] DOIT s'assurer que l'application d'appareil photo par défaut préinstallée qui gère les intents
MediaStore.ACTION_IMAGE_CAPTURE
,MediaStore.ACTION_IMAGE_CAPTURE_SECURE
ouMediaStore.ACTION_VIDEO_CAPTURE
est chargée de supprimer la position de l'utilisateur dans les métadonnées de l'image avant de l'envoyer à l'application destinataire lorsque l'application destinataire ne dispose pas deACCESS_FINE_LOCATION
.
Si les implémentations d'appareils sont compatibles avec la sortie HDR 10 bits, elles:
- [C-2-1] DOIT prendre en charge au moins le profil HDR HLG pour chaque appareil photo compatible avec la sortie 10 bits.
- [C-2-2] DOIT prendre en charge la sortie 10 bits pour la caméra arrière principale ou la caméra avant principale.
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge la sortie 10 bits pour les deux caméras principales.
- [C-2-3] DOIT prendre en charge les mêmes profils HDR pour toutes les sous-caméras physiques compatibles avec BACKWARD_COMPATIBLE d'une caméra logique et la caméra logique elle-même.
Pour les appareils photo logiques compatibles avec le HDR 10 bits qui implémentent l'API android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO
:
- [C-3-1] DOIT permettre de basculer entre toutes les caméras physiques rétrocompatibles via le contrôle
CONTROL_ZOOM_RATIO
de la caméra logique.
7.5.1. Caméra arrière
Une caméra arrière est une caméra orientée vers l'extérieur qui capture des scènes à l'opposé de l'appareil, comme une caméra traditionnelle. Sur les appareils portables, il s'agit d'une caméra située sur le côté de l'appareil, à l'opposé de l'écran.
Implémentations de l'appareil:
- DOIT inclure une caméra arrière.
Si les implémentations d'appareils incluent au moins une caméra arrière, elles:
- [C-1-1] DOIT signaler les indicateurs de fonctionnalité
android.hardware.camera
etandroid.hardware.camera.any
. - [C-1-2] DOIT avoir une résolution d'au moins 2 mégapixels.
- Le pilote de l'appareil photo DOIT implémenter la mise au point automatique matérielle ou logicielle (transparente pour le logiciel d'application).
- POURRAIENT avoir un matériel à mise au point fixe ou à profondeur de champ étendue (EDOF, Extended Depth of Field).
- POURRA inclure un flash.
Si la caméra inclut un flash:
- [C-2-1] Le flash ne doit PAS être allumé lorsqu'une instance
android.hardware.Camera.PreviewCallback
a été enregistrée sur une surface d'aperçu de l'appareil photo, sauf si l'application a explicitement activé le flash en activant les attributsFLASH_MODE_AUTO
ouFLASH_MODE_ON
d'un objetCamera.Parameters
. Notez que cette contrainte ne s'applique pas à l'application d'appareil photo système intégrée de l'appareil, mais uniquement aux applications tierces qui utilisentCamera.PreviewCallback
.
7.5.2. Caméra avant
Une caméra avant est une caméra orientée vers l'utilisateur qui est généralement utilisée pour prendre une photo de l'utilisateur, par exemple pour les visioconférences et les applications similaires. Sur les appareils portables, il s'agit d'une caméra située du même côté de l'appareil que l'écran.
Implémentations de l'appareil:
- POURRAIENT inclure une caméra avant.
Si les implémentations d'appareils incluent au moins une caméra avant, elles:
- [C-1-1] DOIT signaler les indicateurs de fonctionnalité
android.hardware.camera.any
etandroid.hardware.camera.front
. - [C-1-2] DOIT avoir une résolution d'au moins VGA (640 x 480 pixels).
- [C-1-3] NE DOIT PAS utiliser une caméra avant par défaut pour l'API Camera et NE DOIT PAS configurer l'API pour qu'elle traite une caméra avant comme la caméra arrière par défaut, même si elle est la seule caméra de l'appareil.
- [C-1-4] L'aperçu de l'appareil photo DOIT être mis en miroir horizontalement par rapport à l'orientation spécifiée par l'application lorsque l'application actuelle a demandé explicitement que l'écran de l'appareil photo soit pivoté via un appel à la méthode
android.hardware.Camera.setDisplayOrientation()
. À l'inverse, l'aperçu DOIT être mis en miroir le long de l'axe horizontal par défaut de l'appareil lorsque l'application actuelle ne demande pas explicitement que l'écran de l'appareil photo soit pivoté via un appel à la méthodeandroid.hardware.Camera.setDisplayOrientation()
. - [C-1-5] NE DOIT PAS refléter les flux d'images fixes ou vidéo capturés qui sont renvoyés aux rappels d'application ou enregistrés dans le stockage multimédia.
- [C-1-6] DOIT refléter l'image affichée par le postview de la même manière que le flux d'images d'aperçu de l'appareil photo.
- PEUVENT inclure des fonctionnalités (comme l'autofocus, le flash, etc.) disponibles pour les caméras arrière, comme décrit dans la section 7.5.1.
Si les implémentations d'appareils peuvent être pivotées par l'utilisateur (par exemple, automatiquement via un accéléromètre ou manuellement via une entrée utilisateur):
- [C-2-1] L'aperçu de l'appareil photo DOIT être inversé horizontalement par rapport à l'orientation actuelle de l'appareil.
7.5.3. Caméra externe
Une caméra externe est une caméra qui peut être physiquement connectée ou dissociée de l'implémentation de l'appareil à tout moment et peut faire face dans n'importe quelle direction (par exemple, les caméras USB).
Implémentations de l'appareil:
- PEUT inclure la compatibilité avec une caméra externe qui n'est pas nécessairement toujours connectée.
Si les implémentations de l'appareil sont compatibles avec une caméra externe, elles:
- [C-1-1] Vous DEVEZ déclarer les indicateurs de fonctionnalité de la plate-forme
android.hardware.camera.external
etandroid.hardware camera.any
. - [C-1-2] DOIT être compatible avec la classe vidéo USB (UVC 1.0 ou version ultérieure) si la caméra externe se connecte via le port hôte USB.
- [C-1-3] L'appareil doit réussir les tests CTS de la caméra avec un appareil photo externe physique connecté. Pour en savoir plus sur les tests CTS de l'appareil photo, consultez source.android.com.
- DOIT prendre en charge les compressions vidéo telles que MJPEG pour permettre le transfert de flux non encodés de haute qualité (c'est-à-dire des flux d'images bruts ou compressés indépendamment).
- Peut être compatible avec plusieurs caméras.
- Peut prendre en charge l'encodage vidéo basé sur la caméra.
Si l'encodage vidéo basé sur l'appareil photo est compatible:
- [C-2-1] Un flux non encodé / MJPEG simultané (résolution VGA ou supérieure) DOIT être accessible à l'implémentation de l'appareil.
7.5.4. Comportement de l'API Camera
Android inclut deux packages d'API pour accéder à l'appareil photo. L'API android.hardware.camera2 la plus récente expose le contrôle de l'appareil photo de niveau inférieur à l'application, y compris des flux de streaming/rafales efficaces sans copie et des commandes par frame de l'exposition, du gain, des gains de balance des blancs, de la conversion des couleurs, du débruitage, de l'accentuation, etc.
L'ancien package d'API, android.hardware.Camera
, est marqué comme obsolète dans Android 5.0, mais il devrait toujours être disponible pour les applications. Les implémentations d'appareils Android DOIVENT assurer la prise en charge continue de l'API, comme décrit dans cette section et dans le SDK Android.
Toutes les fonctionnalités communes entre la classe android.hardware.Camera obsolète et le package android.hardware.camera2 plus récent DOIVENT avoir des performances et une qualité équivalentes dans les deux API. Par exemple, avec des paramètres équivalents, la vitesse et la précision du mode autofocus doivent être identiques, et la qualité des images capturées doit être la même. Les fonctionnalités qui dépendent des différentes sémantiques des deux API ne sont pas tenues d'avoir la même vitesse ni la même qualité, mais DOIVENT correspondre le plus étroitement possible.
Les implémentations d'appareils DOIVENT implémenter les comportements suivants pour les API liées à la caméra, pour toutes les caméras disponibles. Implémentations de l'appareil:
- [C-0-1] Vous devez utiliser
android.hardware.PixelFormat.YCbCr_420_SP
pour les données d'aperçu fournies aux rappels d'application lorsqu'une application n'a jamais appeléandroid.hardware.Camera.Parameters.setPreviewFormat(int)
. - [C-0-2] DOIT également être au format d'encodage NV21 lorsqu'une application enregistre une instance
android.hardware.Camera.PreviewCallback
et que le système appelle la méthodeonPreviewFrame()
et que le format d'aperçu est YCbCr_420_SP, les données du byte[] transmises àonPreviewFrame()
. Autrement dit, NV21 DOIT être la valeur par défaut. - [C-0-3] DOIT prendre en charge le format YV12 (comme indiqué par la constante
android.graphics.ImageFormat.YV12
) pour les aperçus de l'appareil photo pour les caméras avant et arrière pourandroid.hardware.Camera
. (L'encodeur vidéo matériel et la caméra peuvent utiliser n'importe quel format de pixel natif, mais l'implémentation de l'appareil DOIT prendre en charge la conversion en YV12.) - [C-0-4] DOIT prendre en charge les formats
android.hardware.ImageFormat.YUV_420_888
etandroid.hardware.ImageFormat.JPEG
en sortie via l'APIandroid.media.ImageReader
pour les appareilsandroid.hardware.camera2
qui annoncent la fonctionnalitéREQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE
dansandroid.request.availableCapabilities
. - [C-0-5] Vous devez toujours implémenter l'API Camera complète incluse dans la documentation du SDK Android, que l'appareil inclue ou non un autofocus matériel ou d'autres fonctionnalités. Par exemple, les appareils photo qui ne disposent pas d'autofocus DOIVENT toujours appeler les instances
android.hardware.Camera.AutoFocusCallback
enregistrées (même si cela n'a aucune pertinence pour un appareil photo sans autofocus). Notez que cela s'applique aux appareils photo avant. Par exemple, même si la plupart des appareils photo avant ne sont pas compatibles avec le mode autofocus, les rappels d'API doivent toujours être "faussés" comme décrit. - [C-0-6] DOIT reconnaître et respecter chaque nom de paramètre défini comme constante dans la classe
android.hardware.Camera.Parameters
et la classeandroid.hardware.camera2.CaptureRequest
. À l'inverse, les implémentations d'appareils NE DOIVENT PAS respecter ni reconnaître les constantes de chaîne transmises à la méthodeandroid.hardware.Camera.setParameters()
, à l'exception de celles documentées en tant que constantes surandroid.hardware.Camera.Parameters
. Autrement dit, les implémentations d'appareils DOIVENT prendre en charge tous les paramètres d'appareil photo standards si le matériel le permet, et NE DOIVENT PAS prendre en charge les types de paramètres d'appareil photo personnalisés. Par exemple, les implémentations d'appareils compatibles avec la capture d'images à l'aide de techniques d'imagerie HDR (High Dynamic Range) DOIVENT prendre en charge le paramètre de l'appareil photoCamera.SCENE_MODE_HDR
. - [C-0-7] DOIT indiquer le niveau de compatibilité approprié avec la propriété
android.info.supportedHardwareLevel
, comme décrit dans le SDK Android, et indiquer les options de fonctionnalité du framework appropriées. - [C-0-8] DOIT également déclarer les fonctionnalités individuelles de la caméra
android.hardware.camera2
via la propriétéandroid.request.availableCapabilities
et déclarer les indicateurs de fonctionnalité appropriés. DOIT définir l'indicateur de fonctionnalité si l'un de ses appareils photo connectés est compatible avec la fonctionnalité. - [C-0-9] DOIT diffuser l'intent
Camera.ACTION_NEW_PICTURE
chaque fois qu'une nouvelle photo est prise par l'appareil photo et que l'entrée de la photo a été ajoutée au store multimédia. - [C-0-10] DOIT diffuser l'intent
Camera.ACTION_NEW_VIDEO
chaque fois qu'une nouvelle vidéo est enregistrée par la caméra et que l'entrée de l'image a été ajoutée au store multimédia. - [C-0-11] Toutes les caméras doivent être accessibles via l'API
android.hardware.Camera
obsolète, mais également via l'APIandroid.hardware.camera2
. - [C-0-12] DOIT s'assurer que l'apparence du visage n'est PAS modifiée, y compris, mais sans s'y limiter, en modifiant la géométrie du visage, la couleur de la peau du visage ou l'adoucissement de la peau du visage pour toute API
android.hardware.camera2
ouandroid.hardware.Camera
. - [C-SR-1] Pour les appareils équipés de plusieurs caméras RGB à proximité et orientées dans la même direction, il est FORTEMENT RECOMMANDÉ de prendre en charge un appareil photo logique qui liste la capacité
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
, composée de toutes les caméras RGB orientées dans cette direction en tant que sous-appareils physiques.
Si les implémentations d'appareils fournissent une API de caméra propriétaire aux applications tierces:
- [C-1-1] Vous DEVEZ implémenter une telle API d'appareil photo à l'aide de l'API
android.hardware.camera2
. - PEUT fournir des tags et/ou des extensions de fournisseur à l'API
android.hardware.camera2
.
7.5.5. Orientation de l'appareil photo
Si les implémentations de l'appareil comportent une caméra avant ou arrière, la ou les caméras :
- [C-1-1] DOIT être orienté de sorte à faire correspondre la dimension longue de l'appareil photo à la dimension longue de l'écran. Autrement dit, lorsque l'appareil est tenu en mode paysage, les appareils photo DOIVENT capturer des images en mode paysage. Cela s'applique quelle que soit l'orientation naturelle de l'appareil, c'est-à-dire aux appareils en mode paysage et en mode portrait.
Les appareils qui répondent à tous les critères suivants sont exemptés de l'exigence ci-dessus:
- L'appareil implémente des écrans à géométrie variable, tels que des écrans pliables ou à charnière.
- Lorsque l'état de pliage ou de charnière de l'appareil change, l'appareil passe de l'orientation portrait principale à l'orientation paysage principale (ou inversement).
- Implémentations d'appareils que l'utilisateur ne peut pas faire pivoter, comme les appareils automobiles.
7.6. Mémoire et stockage
7.6.1. Mémoire et stockage minimums
Implémentations de l'appareil:
- [C-0-1] DOIT inclure un gestionnaire de téléchargement que les applications PEUVENT utiliser pour télécharger des fichiers de données. Elles DOIVENT être capables de télécharger des fichiers individuels d'au moins 100 Mo à l'emplacement par défaut du "cache".
7.6.2. Stockage partagé de l'application
Implémentations de l'appareil:
- [C-0-1] DOIT proposer un espace de stockage à partager entre les applications, souvent appelé "stockage externe partagé", "stockage partagé par les applications" ou par le chemin d'accès Linux "/sdcard" sur lequel il est installé.
- [C-0-2] DOIT être configuré avec un espace de stockage partagé installé par défaut, c'est-à-dire "prêt à l'emploi", que le stockage soit implémenté sur un composant de stockage interne ou sur un support de stockage amovible (par exemple, un port de carte numérique sécurisé).
- [C-0-3] Le stockage partagé de l'application DOIT être installé directement sur le chemin d'accès Linux
sdcard
ou inclure un lien symbolique Linux desdcard
au point d'installation réel. - [C-0-4] Vous DEVEZ activer le stockage avec portée par défaut pour toutes les applications ciblant le niveau d'API 29 ou supérieur, sauf dans les cas suivants :
- Lorsque l'application a demandé
android:requestLegacyExternalStorage="true"
dans son fichier manifeste.
- Lorsque l'application a demandé
- [C-0-5] DOIT masquer les métadonnées de localisation, telles que les balises EXIF GPS, stockées dans les fichiers multimédias lorsque ces fichiers sont accessibles via
MediaStore
, sauf lorsque l'application appelante détient l'autorisationACCESS_MEDIA_LOCATION
.
Les implémentations d'appareils PEUVENT répondre aux exigences ci-dessus en utilisant l'une des méthodes suivantes:
- Un espace de stockage amovible accessible à l'utilisateur, tel qu'un port de carte Secure Digital (SD).
- Partie du stockage interne (non amovible) implémentée dans le projet Android Open Source (AOSP).
Si les implémentations d'appareils utilisent un stockage amovible pour répondre aux exigences ci-dessus, elles:
- [C-1-1] L'interface utilisateur doit comporter un message toast ou pop-up avertissant l'utilisateur lorsqu'aucun support de stockage n'est inséré dans le port.
- [C-1-2] DOIT inclure un support de stockage au format FAT (par exemple, une carte SD) ou indiquer sur la boîte et tout autre matériel disponible au moment de l'achat que le support de stockage doit être acheté séparément.
Si les implémentations d'appareils utilisent une partie de l'espace de stockage non amovible pour répondre aux exigences ci-dessus, elles:
- DOIT utiliser l'implémentation AOSP du stockage partagé de l'application interne.
- PEUT partager l'espace de stockage avec les données privées de l'application.
Si les implémentations d'appareils disposent d'un port USB compatible avec le mode périphérique USB, elles:
- [C-3-1] DOIT fournir un mécanisme permettant d'accéder aux données du stockage partagé de l'application à partir d'un ordinateur hôte.
- DOIT exposer le contenu des deux chemins de stockage de manière transparente via le service d'analyseur multimédia d'Android et
android.provider.MediaStore
. - PEUT utiliser le stockage de masse USB, mais DOIT utiliser le protocole de transfert multimédia pour répondre à cette exigence.
Si les implémentations d'appareils disposent d'un port USB avec mode périphérique USB et sont compatibles avec le protocole de transfert multimédia, elles:
- DOIT être compatible avec l'hôte MTP Android de référence, Android File Transfer.
- DOIT indiquer une classe d'appareil USB de 0x00.
- DOIT indiquer un nom d'interface USB de "MTP".
7.6.3. Adoptable Storage
Si l'appareil est censé être mobile, contrairement à la télévision, les implémentations de l'appareil sont les suivantes:
- [C-SR-1] IL EST FORTEMENT RECOMMANDÉ d'implémenter le stockage adoptable dans un emplacement stable à long terme, car une déconnexion accidentelle peut entraîner une perte ou une corruption de données.
Si le port de l'appareil de stockage amovible se trouve dans un emplacement stable à long terme, tel que le compartiment de la batterie ou une autre protection, les implémentations de l'appareil sont les suivantes:
- [C-SR-2] IMPLÉMENTATION FORTEMENT RECOMMANDÉE du stockage adoptable.
7.7. USB
Si les implémentations d'appareils disposent d'un port USB, elles:
- DOIT être compatible avec le mode périphérique USB et DOIT être compatible avec le mode hôte USB.
- DOIT prendre en charge la désactivation de la signalisation de données via USB.
7.7.1. Mode périphérique USB
Si les implémentations de l'appareil incluent un port USB compatible avec le mode périphérique:
- [C-1-1] Le port DOIT être connectable à un hôte USB doté d'un port USB Type-A ou Type-C standard.
- [C-1-2] DOIT indiquer la valeur correcte de
iSerialNumber
dans le descripteur d'appareil standard USB viaandroid.os.Build.SERIAL
. - [C-1-3] DOIT détecter les chargeurs 1,5 A et 3,0 A conformément à la norme de résistance Type-C et DOIT détecter les modifications de la publicité s'ils sont compatibles avec l'USB Type-C.
- [C-SR-1] Le port DOIT utiliser le facteur de forme USB micro-B, micro-AB ou Type-C. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin qu'ils puissent passer aux futures versions de la plate-forme.
- [C-SR-2] Le port DOIT se trouver en bas de l'appareil (selon l'orientation naturelle) ou activer la rotation logicielle de l'écran pour toutes les applications (y compris l'écran d'accueil), afin que l'affichage s'affiche correctement lorsque l'appareil est orienté avec le port en bas. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin qu'ils puissent passer aux futures versions de la plate-forme.
- [C-SR-3] DOIT implémenter la prise en charge de la consommation d'un courant de 1,5 A pendant le chirp HS et le trafic, comme spécifié dans la spécification de recharge de la batterie USB, version 1.2. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin qu'ils puissent passer aux futures versions de la plate-forme.
- [C-SR-4] Il est vivement recommandé de ne pas prendre en charge les méthodes de recharge propriétaires qui modifient la tension Vbus au-delà des niveaux par défaut ou qui modifient les rôles de source/piège, car cela peut entraîner des problèmes d'interopérabilité avec les chargeurs ou les appareils compatibles avec les méthodes de recharge USB standard. Bien que cette fonctionnalité soit "FORTEMENT RECOMMANDÉE", nous pourrons exiger que tous les appareils Type-C soient entièrement compatibles avec les chargeurs Type-C standards dans les futures versions d'Android.
- [C-SR-5] Il est vivement recommandé de prendre en charge la distribution d'alimentation pour le transfert de données et l'échange de rôles d'alimentation lorsqu'ils sont compatibles avec l'USB Type-C et le mode hôte USB.
- DOIT prendre en charge la recharge haute tension et les modes alternatifs tels que la sortie d'écran.
- DOIT implémenter l'API et la spécification Android Open Accessory (AOA) comme indiqué dans la documentation du SDK Android.
Si les implémentations d'appareils incluent un port USB et implémentent la spécification AOA, elles:
- [C-2-1] DOIT déclarer la 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" à la fin de la chaîne
iInterface
de description de l'interface du stockage de masse USB.
7.7.2. Mode hôte USB
Si les implémentations d'appareils incluent un port USB compatible avec le mode hôte, elles:
- [C-1-1] DOIT implémenter l'API hôte USB Android 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 prendre en charge la connexion de périphériques USB standards. En d'autres termes, il DOIT :
- Disposer d'un port de type C sur l'appareil ou être fourni avec un ou plusieurs câbles permettant d'adapter un port propriétaire sur l'appareil à un port USB Type-C standard (appareil USB Type-C).
- Disposer d'un port de type A sur l'appareil ou être fourni avec un ou plusieurs câbles permettant d'adapter un port propriétaire sur l'appareil à un port USB de type A standard.
- Disposer d'un port micro-AB sur l'appareil, qui DOIT être fourni avec un câble permettant de le connecter à un port Type-A standard.
- [C-1-3] NE DOIT PAS être fourni avec un adaptateur permettant de convertir les ports USB de type A ou micro-AB en port de type C (récepteur).
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'implémenter la classe audio USB, comme indiqué dans la documentation du SDK Android.
- DOIT prendre en charge la recharge de l'appareil périphérique USB connecté en mode hôte ; annoncer un courant de source d'au moins 1,5 A, comme spécifié dans la section "Paramètres de terminaison" de la spécification de la version 1.2 du câble et du connecteur USB Type-C pour les connecteurs USB Type-C ou utiliser la plage de courant de sortie du port en aval de recharge (CDP) comme spécifié dans les spécifications de recharge de la batterie USB, version 1.2 pour les connecteurs Micro-AB.
- DOIT implémenter et prendre en charge les normes USB Type-C.
Si les implémentations d'appareils incluent un port USB compatible avec le mode hôte et la classe audio USB, elles:
- [C-2-1] DOIT être compatible avec la classe USB HID.
- [C-2-2] DOIT prendre en charge la détection et le mappage des champs de données HID suivants spécifiés dans les tables d'utilisation USB HID et la requête d'utilisation des commandes vocales aux constantes
KeyEvent
comme indiqué ci-dessous :- Page d'utilisation (0xC) ID d'utilisation (0x0CD):
KEYCODE_MEDIA_PLAY_PAUSE
- Page d'utilisation (0xC) ID d'utilisation (0x0E9):
KEYCODE_VOLUME_UP
- Page d'utilisation (0xC) ID d'utilisation (0x0EA):
KEYCODE_VOLUME_DOWN
- Page d'utilisation (0xC) ID d'utilisation (0x0CF):
KEYCODE_VOICE_ASSIST
- Page d'utilisation (0xC) ID d'utilisation (0x0CD):
Si les implémentations d'appareils incluent un port USB compatible avec le mode hôte et le Storage Access Framework (SAF), elles:
- [C-3-1] DOIT reconnaître tous les appareils MTP (Media Transfer Protocol) connectés à distance et rendre leurs contenus accessibles via les intents
ACTION_GET_CONTENT
,ACTION_OPEN_DOCUMENT
etACTION_CREATE_DOCUMENT
. .
Si les implémentations d'appareils incluent un port USB compatible avec le mode hôte et USB Type-C, elles:
- [C-4-1] DOIT implémenter la fonctionnalité de port à double rôle telle que définie par la spécification USB Type-C (section 4.5.1.3.3). Pour les ports à double rôle, sur les appareils qui incluent une prise audio 3,5 mm, la détection de la prise USB (mode hôte) PEUT être désactivée par défaut, mais l'utilisateur doit pouvoir l'activer.
- [C-SR-2] Il est vivement recommandé de prendre en charge DisplayPort, et de prendre en charge les débits de données USB SuperSpeed. Il est vivement recommandé de prendre en charge la distribution d'alimentation pour le transfert de rôle de données et d'alimentation.
- [C-SR-3] Il est vivement recommandé de NE PAS prendre en charge le mode accessoire de l'adaptateur audio, comme décrit dans l'annexe A de la spécification de la version 1.2 du câble et du connecteur USB Type-C.
- DOIT implémenter le modèle Try.* le plus adapté au facteur de forme de l'appareil. Par exemple, un appareil portable DOIT implémenter le modèle Try.SNK.
7.8. Audio
7.8.1. Micro
Si les implémentations d'appareils incluent un micro, elles:
- [C-1-1] DOIT indiquer la constante de fonctionnalité
android.hardware.microphone
. - [C-1-2] DOIT respecter les exigences d'enregistrement audio de la section 5.4.
- [C-1-3] DOIT respecter les exigences de latence audio de la section 5.6.
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'enregistrement à ultrasons comme décrit dans la section 7.8.3.
Si les implémentations d'appareils omettent un micro, elles:
- [C-2-1] NE DOIT PAS signaler la constante de fonctionnalité
android.hardware.microphone
. - [C-2-2] L'API d'enregistrement audio doit être implémentée au moins en tant que no-ops, conformément à la section 7.
7.8.2. Sortie audio
Si les implémentations d'appareils incluent un haut-parleur ou un port de sortie audio/multimédia pour un périphérique de sortie audio tel qu'une prise audio 3,5 mm à quatre conducteurs ou un port en mode hôte USB utilisant la classe audio USB, elles:
- [C-1-1] DOIT indiquer la constante de fonctionnalité
android.hardware.audio.output
. - [C-1-2] DOIT respecter les exigences de lecture audio de la section 5.5.
- [C-1-3] DOIT respecter les exigences de latence audio de la section 5.6.
- [C-SR-1] IL EST FORTEMENT RECOMMANDÉ de prendre en charge la lecture proche des ultrasons, comme décrit dans la section 7.8.3.
Si les implémentations d'appareils n'incluent pas de haut-parleur ni de port de sortie audio, elles:
- [C-2-1] NE DOIT PAS signaler la fonctionnalité
android.hardware.audio.output
. - [C-2-2] Les API liées à la sortie audio doivent être implémentées en tant que no-ops au moins.
Aux fins de cette section, un "port de sortie" est une interface physique telle qu'une prise audio 3, 5 mm, un port HDMI ou un port en mode hôte USB avec classe audio USB. La prise en charge de la sortie audio via des protocoles radio tels que le Bluetooth, le Wi-Fi ou le réseau mobile ne peut pas être considérée comme incluant un "port de sortie".
7.8.2.1. Ports audio analogiques
Pour être compatible avec les casques et autres accessoires audio utilisant la prise audio 3,5 mm dans l'écosystème Android, si les implémentations d'appareils incluent un ou plusieurs ports audio analogiques, elles:
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure au moins un port audio avec une prise jack audio 3,5 mm à quatre conducteurs.
Si les implémentations d'appareils sont dotées d'une prise audio 3,5 mm à quatre conducteurs, elles:
- [C-1-1] DOIT être compatible avec la lecture audio sur des casques stéréo et des casques stéréo avec micro.
- [C-1-2] DOIT être compatible avec les connecteurs audio TRRS avec la séquence de broches CTIA.
- [C-1-3] DOIT prendre en charge la détection et le mappage sur les codes de touche pour les trois plages d'impédance équivalente suivantes entre le micro et les conducteurs de terre sur la prise audio :
- 70 ohms ou moins:
KEYCODE_HEADSETHOOK
- 210-290 ohms:
KEYCODE_VOLUME_UP
- 360-680 ohms:
KEYCODE_VOLUME_DOWN
- 70 ohms ou moins:
- [C-1-4] DOIT déclencher
ACTION_HEADSET_PLUG
lors de l'insertion d'une prise, mais uniquement après que tous les contacts de la prise ont touché leurs segments correspondants sur la prise. - [C-1-5] DOIT être capable de piloter au moins 150 mV ± 10% de la tension de sortie sur une impédance d'enceinte de 32 ohms.
- [C-1-6] La tension de polarisation du micro doit être comprise entre 1,8 V et 2,9 V.
- [C-1-7] DOIT détecter et mapper sur le code de touche la plage d'impédance équivalente suivante entre les conducteurs du micro et de la terre sur la prise audio :
- 110 à 180 ohms:
KEYCODE_VOICE_ASSIST
- 110 à 180 ohms:
- [C-SR-2] Il est FORTEMENT RECOMMANDÉ de prendre en charge les prises audio avec l'ordre de sortie OMTP.
- [C-SR-3] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'enregistrement audio à partir de casques stéréo avec micro.
Si les implémentations d'appareils disposent d'un connecteur audio 3,5 mm à quatre conducteurs et sont compatibles avec un micro, et qu'elles diffusent le android.intent.action.HEADSET_PLUG
avec le micro à valeur supplémentaire défini sur 1, elles:
- [C-2-1] DOIT prendre en charge la détection du micro sur l'accessoire audio branché.
7.8.2.2. Ports audio numériques
Pour connaître les exigences spécifiques à l'appareil, consultez la section 2.2.1.
7.8.3. Quasi-échographie
L'audio proche des ultrasons correspond à la bande de fréquences de 18,5 kHz à 20 kHz.
Implémentations de l'appareil:
- DOIT signaler correctement la prise en charge de la fonctionnalité audio proche des ultrasons via l'API AudioManager.getProperty comme suit:
Si PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND
est défini sur "true", les exigences suivantes DOIVENT être remplies par les sources audio VOICE_RECOGNITION
et UNPROCESSED
:
- [C-1-1] La réponse moyenne en puissance du micro dans la bande de 18,5 kHz à 20 kHz DOIT être inférieure de 15 dB à la réponse à 2 kHz.
- [C-1-2] Le rapport signal/bruit non pondéré du micro entre 18,5 kHz et 20 kHz pour un son de 19 kHz à -26 dBFS DOIT être d'au moins 50 dB.
Si PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND
est "true":
- [C-2-1] La répo