Android 14
8 avril 2024
2. Types d'appareils
Voir révision
Démarrer de nouvelles exigences
Si les implémentations d'appareils portables déclarent
FEATURE_BLUETOOTH_LE, elles :- [ 7.4 .3/H-1-3] DOIT mesurer et compenser le décalage Rx pour garantir que le RSSI BLE médian est de -50 dBm +/-15 dB à 1 m de distance 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 Tx pour garantir que le RSSI BLE médian est de -50 dBm +/-15 dB lors du balayage à partir d'un appareil de référence positionné à 1 m de distance et transmettant à
ADVERTISE_TX_POWER_HIGH.
- [ 7.4 .3/H-1-3] DOIT mesurer et compenser le décalage Rx pour garantir que le RSSI BLE médian est de -50 dBm +/-15 dB à 1 m de distance d'un appareil de référence transmettant à
Voir révision
Si les implémentations d'appareils portables prennent en charge l'API système
HotwordDetectionServiceou un autre mécanisme de détection de mots clés sans indication d'accès au micro, elles :- [9.8/H-1-6] NE DOIT PAS permettre à plus de 100 octets de données d'être transmis hors du service de détection de mot clé pour chaque résultat de mot clé réussi , à l'exception des données audio transmises via HotwordAudioStream .
Voir révision
Remplacer [9.8/H-1-13] par :
- [9.8/H-SR-3] Sont FORTEMENT RECOMMANDÉS de redémarrer le processus hébergeant le service de détection de mots clés au moins une fois toutes les heures ou tous les 30 événements déclencheurs matériels, selon la première éventualité.
Voir révision
Exigences supprimées [9.8.2/H-4-3], [9.8.2/H-4-4], [9.8.2/H-5-3].
Voir révision
Si les implémentations d'appareils portables renvoient
android.os.Build.VERSION_CODES.Upourandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, alors elles :- [ 7.5 /H-1-3] DOIT prendre en charge la propriété
android.info.supportedHardwareLevelcommeFULLou mieux pour la caméra principale arrière etLIMITEDou mieux pour la caméra principale avant.
- [ 7.5 /H-1-3] DOIT prendre en charge la propriété
Voir révision
Si les implémentations d'appareils de télévision ne disposent pas d'un écran intégré, mais prennent en charge un écran externe connecté via HDMI, elles :
- [ 5.8 /T-0-1] DOIT définir le mode de sortie HDMI sur la résolution la plus élevée pour le format de pixel choisi qui fonctionne avec un taux de rafraîchissement de 50 Hz ou 60 Hz pour l'écran externe, en fonction du taux de rafraîchissement vidéo de la région dans laquelle l'appareil est vendu. DOIT
régler le mode de sortie HDMI pour sélectionner la résolution maximale qui peut être prise en charge avec un taux de rafraîchissement de 50 Hz ou 60 Hz.
- [ 5.8 /T-0-1] DOIT définir le mode de sortie HDMI sur la résolution la plus élevée pour le format de pixel choisi qui fonctionne avec un taux de rafraîchissement de 50 Hz ou 60 Hz pour l'écran externe, en fonction du taux de rafraîchissement vidéo de la région dans laquelle l'appareil est vendu. DOIT
3. Logiciel
3.5.1. Restriction d'application :
Voir révision
- Exigence supprimée [C-1-9]
5. Compatibilité multimédia
Voir révision
Si les implémentations de périphériques déclarent la prise en charge du décodeur Dolby Vision via
HDR_TYPE_DOLBY_VISION, elles :- [C-1-3] DOIT définir l' ID de piste de la ou des couches de base rétrocompatibles (le cas échéant) pour qu'il soit identique à l'ID de piste de la couche Dolby Vision combinée.
7. Compatibilité matérielle
7.1.1.1. Taille et forme de l'écran :
Voir révision
Si les implémentations de périphériques prennent en charge les écrans compatibles avec la configuration de taille
UI_MODE_TYPE_NORMALet utilisent un ou plusieurs affichages physiques avec des coins arrondis pour restituer ces écrans, elles :- [C-1-1] DOIT garantir qu'au moins une des exigences suivantes est remplie pour chacun de ces affichages :
- Lorsqu'une case
de 15et 18 dp par1518 dp est ancrée à chaque coin de l'affichage logique, au moins un pixel de chaque case est visible sur l'écran.
- Lorsqu'une case
- [C-1-1] DOIT garantir qu'au moins une des exigences suivantes est remplie pour chacun de ces affichages :
Voir révision
Rétablissement des exigences suivantes :
Si les implémentations de périphériques déclarent
FEATURE_BLUETOOTH_LE, elles :[C-SR-2] Sont FORTEMENT RECOMMANDÉS de mesurer et de compenser le décalage Rx pour garantir que le RSSI BLE médian est de -60 dBm +/-10 dB à 1 m de distance d'un appareil de référence transmettant à
ADVERTISE_TX_POWER_HIGH, où les appareils sont orientés de telle sorte qu'ils soient sur des « plans parallèles » avec des écrans orientés dans la même direction.[C-SR-3] Sont FORTEMENT RECOMMANDÉS de mesurer et de compenser le décalage Tx pour garantir que le RSSI BLE médian est de -60 dBm +/-10 dB lors du balayage à partir d'un appareil de référence positionné à 1 m de distance et de la transmission à
ADVERTISE_TX_POWER_HIGH, où les appareils sont orientés. de telle sorte qu'ils se trouvent sur des « plans parallèles » avec des écrans orientés dans la même direction.
Voir révision
Les exigences [C-10-3] et [C-10-4] ont été déplacées vers 2.2.1. Matériel .
- [C-10-3] DOIT mesurer et compenser le décalage Rx pour garantir que le RSSI BLE médian est de -55 dBm +/-10 dB à 1 m de distance d'un appareil de référence transmettant à
ADVERTISE_TX_POWER_HIGH. - [C-10-4] DOIT mesurer et compenser le décalage Tx pour garantir que le RSSI BLE médian est de -55 dBm +/-10 dB lors du balayage à partir d'un appareil de référence positionné à 1 m de distance et transmettant à
ADVERTISE_TX_POWER_HIGH.
20 novembre 2023
2. Types d'appareils
Voir révision
Si les implémentations d'appareils portables déclarent la prise en charge de n'importe quel ABI 64 bits (avec ou sans ABI 32 bits) :
Voir révision
- [ 7.5 /H-1-13] DOIT prendre en charge la capacité
LOGICAL_MULTI_CAMERApour la caméra principale orientée vers l'arrière s'il y a plus d'une caméra RVB orientée vers l'arrière.
- [ 7.5 /H-1-13] DOIT prendre en charge la capacité
Voir révision
[ 5.8 /T-0-1] DOIT définir le mode de sortie HDMI sur la résolution la plus élevée pour le format SDR ou HDR choisi qui fonctionne avec un taux de rafraîchissement de 50 Hz ou 60 Hz pour l'écran externe.
DOIT définir le mode de sortie HDMI pour sélectionner la résolution maximale pouvant être prise en charge avec un taux de rafraîchissement de 50 Hz ou 60 Hz.
Voir révision
- [9/W-0-1] DOIT déclarer la
android.hardware.security.model.compatible feature.
- [9/W-0-1] DOIT déclarer la
6. Compatibilité des outils et des options de développement
6.1. Outils de développement :
Voir révision
- [C-0-12] DOIT écrire un
LMK_KILL_OCCURRED_FIELD_NUMBERAtom dans le
Voir révision
- [C-0-13] DOIT implémenter la commande shell
dumpsys gpu --gpuworkpour afficher
- [C-0-12] DOIT écrire un
9. Compatibilité des modèles de sécurité
Voir révision
Si les implémentations de périphériques utilisent un noyau Linux capable de prendre en charge SELinux, elles :
Voir révision
Si les implémentations de périphériques utilisent un noyau autre que Linux ou Linux sans SELinux, elles :
4 octobre 2023
2. Types d'appareils
2.2. Exigences de l'ordinateur de poche :
Voir révision
Les implémentations d'appareils Android sont classées comme ordinateurs de poche si elles répondent à tous les critères suivants :
- Avoir une taille d'écran en diagonale physique comprise entre 4 pouces
et 3,3 pouces (ou 2,5 pouces pour les implémentations d'appareils livrées au niveau API 29 ou antérieur)à 8 pouces.
Démarrer de nouvelles exigences
- Avoir une interface de saisie à écran tactile.
- Avoir une taille d'écran en diagonale physique comprise entre 4 pouces
Voir révision
Implémentations d'appareils portables :
- [ 7.1 .1.1/H-0-1] DOIT avoir au moins un
écran compatible Android qui répond à toutes les exigences décrites dans ce document.écran qui mesure au moins 2,2" sur le bord court et 3,4" sur le bord long.
Si les implémentations d’appareils portables prennent en charge la rotation de l’écran du logiciel, elles :
- [ 7.1 .1.1/H-1-1]* DOIT faire en sorte que l'écran logique mis à disposition pour les applications tierces mesure au moins 2 pouces sur le(s) bord(s) court(s) et 2,7 pouces sur le(s) bord(s) long(s). Les appareils livrés avec le niveau d'API Android 29 ou une version antérieure PEUVENT être exemptés de cette exigence.
Si les implémentations d’appareils portables ne prennent pas en charge la rotation de l’écran logiciel, elles :
- [ 7.1 .1.1/H-2-1]* DOIT faire en sorte que l'écran logique mis à disposition pour les applications tierces mesure au moins 2,7 pouces sur le(s) bord(s) court(s). Les appareils livrés avec le niveau d'API Android 29 ou une version antérieure PEUVENT être exemptés de cette exigence.
Démarrer de nouvelles exigences
[ 7.1 .1.1/H-0-3]* DOIT mapper chaque affichage
UI_MODE_NORMALmis à disposition pour les applications tierces sur une zone d'affichage physique dégagée d'au moins 2,2 pouces sur le bord court et de 3,4 pouces sur le bord long.[ 7.1 .1.3/H-0-1]* DOIT définir la valeur de
DENSITY_DEVICE_STABLEà 92 % ou plus que la densité physique réelle de l'affichage correspondant.
Si les implémentations de périphériques portables déclarent
android.hardware.audio.outputetandroid.hardware.microphone, elles :[ 5.6 /H-1-1] DOIT avoir une latence aller-retour continue moyenne de 300 millisecondes ou moins sur 5 mesures, avec un écart absolu moyen inférieur à 30 ms , sur les chemins de données suivants : "haut-parleur vers microphone", 3,5 mm adaptateur de bouclage (si pris en charge), bouclage USB (si pris en charge).
[ 5.6 /H-1-2] DOIT avoir une latence moyenne de 300 millisecondes ou moins sur au moins 5 mesures sur le chemin de données du haut-parleur au microphone.
Si les implémentations d’appareils portables incluent au moins un actionneur haptique, elles :
- [ 7.10 /H]* NE DEVRAIT PAS utiliser un actionneur haptique (vibrateur) à masse rotative excentrique (ERM).
- [ 7.10 / H]* DEVRAIT implémenter toutes les constantes publiques pour une haptique claire dans android.view.HapticFeedbackConstants , à savoir (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START et GES TURE_END).
- [ 7.10 /H]* DEVRAIT implémenter toutes les constantes publiques pour des haptiques claires dans android.os.VibrationEffect , à savoir (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK et EFFECT_DOUBLE_CLICK) et toutes les constantes publiques
PRIMITIVE_*réalisables pour des haptiques riches dans android.os.VibrationEffect.Composition , à savoir ( CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Certaines de ces primitives, telles que LOW_TICK et SPIN, ne peuvent être réalisables que si le vibrateur peut prendre en charge des fréquences relativement basses. - [7.10/H]* DEVRAIT suivre les instructions pour mapper les constantes publiques dans android.view.HapticFeedbackConstants aux constantes android.os.VibrationEffect recommandées, avec les relations d'amplitude correspondantes.
- [ 7.10 /H]* DEVRAIT suivre l'évaluation de la qualité des API createOneShot() et createWaveform() .
- [ 7.10 /H]* DEVRAIT vérifier que le résultat de l'API publique android.os.Vibrator.hasAmplitudeControl() reflète correctement les capacités de leur vibrateur.
- [ 7.10 /H]* DEVRAIT positionner l'actionneur à proximité de l'endroit où l'appareil est généralement tenu ou touché par les mains.
Si les implémentations d'appareils portables incluent au moins un actionneur résonant linéaire 7.10 à usage général , elles :
- [ 7.10 /H] DEVRAIT positionner l'actionneur à proximité de l'endroit où l'appareil est généralement tenu ou touché par les mains.
- [ 7.10 /H] DEVRAIT déplacer l'actionneur haptique sur l'axe X (gauche-droite) de l'orientation
portraitnaturel de l'appareil .
Si les implémentations d'appareils portables disposent d'un actionneur haptique à usage général qui est un actionneur résonant linéaire (LRA) sur l'axe X, elles :
- [ 7.10 /H] DEVRAIT que la fréquence de résonance du LRA de l'axe X soit inférieure à 200 Hz.
- [ 7.1 .1.1/H-0-1] DOIT avoir au moins un
Voir révision
Les implémentations d'appareils portables DOIVENT prendre en charge les formats de codage vidéo suivants et les mettre à la disposition des applications tierces :
- [ 5.2 /H-0-3] AV1
Les implémentations d'appareils portables DOIVENT prendre en charge les formats de décodage vidéo suivants et les mettre à la disposition des applications tierces :
- [ 5.3 /H-0-6] AV1
Voir révision
Si les implémentations d'appareils incluant la touche de navigation de la fonction récente comme détaillé dans la section 7.2.3 modifient l'interface, elles :
- [ 3.8 .3/H-1-1] DOIT implémenter le comportement d'épinglage d'écran et fournir à l'utilisateur un menu de paramètres pour activer la fonctionnalité.
Si les implémentations d'appareils portables incluent la prise en charge des API
ControlsProviderServiceetControlet permettent aux applications tierces de publier des contrôles d'appareil , alors elles :- [ 3.8 .16/H-1-6] Les mises en œuvre de dispositifs DOIVENT restituer avec précision les possibilités de l'utilisateur comme suit :
- Si l'appareil a défini
config_supportsMultiWindow=trueet que l'application déclare les métadonnéesMETA_DATA_PANEL_ACTIVITYdans la déclarationControlsProviderService, y compris le ComponentName d'une activité valide (telle que définie par l'API), alors l'application DOIT intégrer ladite activité dans cette capacité utilisateur. - Si l'application ne déclare pas de métadonnées
META_DATA_PANEL_ACTIVITY, elle DOIT alors restituer les champs spécifiés tels que fournis par l'APIControlsProviderServiceainsi que tous les champs spécifiés fournis par les API de contrôle .
- 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] en utilisantEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLSlors du lancement de l'activité intégrée.
Si les implémentations d'appareils permettent aux utilisateurs de passer des appels de toute sorte, ils
- [ 7.4.1.2 /H-0-1] DOIT déclarer l'indicateur de fonctionnalité
android.software.telecom. - [ 7.4.1.2 /H-0-2] DOIT mettre en œuvre le cadre de télécommunications .
2.2.4. Performances et puissance :
Voir révision
Implémentations d'appareils portables :
- [ 8.5 /H-0-1] DOIT fournir une autorisation utilisateur
dans le menu Paramètrespour voir toutes les applications avec des services de premier plan actifs ou des tâches initiées par l'utilisateur, y compris la durée de chacun de ces services depuis son démarrage comme décrit dans le document SDK. .et la possibilité d'arrêter une application qui exécute un service de premier plan ou une tâche lancée par l'utilisateur.avec la possibilité d'arrêter une application qui exécute un service de premier plan et d'afficher toutes les applications qui ont des services de premier plan actifs ainsi que la durée de chacun de ces services depuis son démarrage comme décrit dans le document SDK .- Certaines applications PEUVENT être exemptées d'être arrêtées ou répertoriées dans une telle accessibilité utilisateur comme décrit dans le document SDK .
- [ 8.5 /H-0-1] DOIT fournir une autorisation utilisateur
- [ 8.5 /H-0-2]DOIT fournir à l'utilisateur la possibilité d'arrêter une application qui exécute un service de premier plan ou une tâche initiée par l'utilisateur.
Voir révision
Si les implémentations de périphériques déclarent la prise en charge de android.hardware.telephony , elles :
- [ 9.5 /H-1-1] NE DOIT PAS définir
UserManager.isHeadlessSystemUserModesurtrue.
Si les implémentations d'appareil disposent d'un écran de verrouillage sécurisé et incluent un ou plusieurs agents de confiance, qui implémentent l'API du système TrustAgentService , elles :
- [ 9.11.1 /H-1-1] DOIT demander à l'utilisateur l'une des méthodes d'authentification principales recommandées (par exemple : code PIN, modèle, mot de passe) plus d'une fois toutes les 72 heures.
Si les implémentations de périphériques portables définissent UserManager.isHeadlessSystemUserMode sur true , elles
Si les implémentations d'appareils portables prennent en charge 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 mots clés ne peut transmettre des données qu'au système,
ContentCaptureServiceou au service de reconnaissance vocale sur l'appareil créé parSpeechRecognizer#createOnDeviceSpeechRecognizer(). - [9.8/H-1-6] NE DOIT PAS permettre à plus de 100 octets de données (à l'exclusion des flux audio) d'être transmis hors du service de détection de mots clés pour chaque résultat de mot clé réussi.
- [9.8/H-1-15] DOIT garantir que les flux audio fournis sur les résultats de mots clés réussis sont transmis dans un sens depuis le service de détection de mots clés vers le service d'interaction vocale.
Si les implémentations d'appareil incluent une application qui utilise l'API système HotwordDetectionService , ou un mécanisme similaire pour la détection de mots clés sans indication d'utilisation du micro, l'application :
- [9.8/H-2-3] 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 (en totalité ou partiellement) l'audio, ou des contenus audio sans rapport avec le mot clé lui-même, à l'exception du
ContentCaptureServiceou service de reconnaissance vocale sur l'appareil.
Si les implémentations d'appareils portables prennent en charge l'API système VisualQueryDetectionService ou un autre mécanisme de détection de requêtes sans indication d'accès au micro et/ou à la caméra, elles :
- [9.8/H-3-1] DOIT s'assurer que le service de détection de requêtes peut uniquement transmettre des données au système, ou
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 hors de
VisualQueryDetectionService, sauf versContentCaptureServiceou le service de reconnaissance vocale sur l'appareil. - [9.8/H-3-3] DOIT afficher un avis utilisateur dans l'interface utilisateur 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 une caméra).
- [9.8/H-3-4] DOIT afficher un indicateur de microphone et afficher la requête de l'utilisateur détectée dans l'interface utilisateur juste après la détection de la requête de l'utilisateur.
- [9.8/H-3-5] NE DOIT PAS permettre à une application installable par l'utilisateur de fournir le service de détection visuelle des requêtes.
Voir révision
Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.T pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , alors elles :
- DOIT répondre aux exigences multimédias répertoriées dans la section 2.2.7.1 du CDD Android 13 .
Démarrer de nouvelles exigences
Si les implémentations d'appareils portables renvoientandroid.os.Build.VERSION_CODES.U pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , alors elles :- [5.1/H-1-1] DOIT annoncer le nombre maximum de sessions de décodeur vidéo matériel qui peuvent être exécutées simultanément dans n'importe quelle combinaison de codecs via les méthodes
CodecCapabilities.getMaxSupportedInstances()etVideoCapabilities.getSupportedPerformancePoints(). - [5.1/H-1-2] DOIT prendre en charge 6 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ées simultanément avec 3 sessions à une résolution de 1080p à 30 ips. et 3 sessions à une résolution 4k à 30 ips, sauf AV1. Les codecs AV1 ne doivent prendre en charge que la résolution 1080p, mais doivent toujours prendre en charge 6 instances à 1080p30fps.
- [5.1/H-1-3] DOIT annoncer le nombre maximum de sessions d'encodeur vidéo matériel qui peuvent être exécutées simultanément dans n'importe quelle combinaison de codecs via les méthodes
CodecCapabilities.getMaxSupportedInstances()etVideoCapabilities.getSupportedPerformancePoints(). - [5.1/H-1-4] DOIT prendre en charge 6 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ées simultanément avec 4 sessions à une résolution de 1080p à 30 ips. et 2 sessions à une résolution 4k à 30 ips, sauf AV1. Les codecs AV1 ne doivent prendre en charge que la résolution 1080p, mais doivent toujours prendre en charge 6 instances à 1080p30fps.
- [5.1/H-1-5] DOIT annoncer le nombre maximum de sessions d'encodeur et de décodeur vidéo matériel qui peuvent être exécutées simultanément dans n'importe quelle combinaison de codecs via les méthodes
CodecCapabilities.getMaxSupportedInstances()etVideoCapabilities.getSupportedPerformancePoints(). - [5.1/H-1-6] DOIT prendre en charge 6 instances de sessions de décodeur vidéo matériel et 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ées simultanément avec 3 sessions en 4K. Résolution à 30 ips (sauf AV1), dont au plus 2 sessions d'encodeur et 3 sessions à une résolution de 1080p. Les codecs AV1 ne doivent prendre en charge que la résolution 1080p, mais doivent toujours prendre en charge 6 instances à 1080p30fps.
- [5.1/H-1-19] DOIT prendre en charge 3 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 fonctionnant simultanément à une résolution de 4K à 30 ips. (sauf AV1) dont au plus 1 est une session d'encodeur, qui pourrait être configurée au format d'entrée RGBA_1010102 via une surface GL. La génération de métadonnées HDR par l'encodeur n'est pas requise en cas d'encodage à partir de la surface GL. Les sessions de codec AV1 ne doivent prendre en charge que la résolution 1080p, même lorsque cette exigence nécessite la 4K.
- [5.1/H-1-7] DOIT avoir une latence d'initialisation du codec de 40 ms ou moins pour une session de codage vidéo 1080p ou inférieure pour tous les encodeurs vidéo matériels lorsqu'ils sont sous charge. La charge ici est définie comme une session simultanée de transcodage vidéo uniquement de 1080p à 720p utilisant des 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 de 50 ms ou moins.
- [5.1/H-1-8] DOIT avoir une latence d'initialisation du codec de 30 ms ou moins pour une session de codage audio à débit binaire de 128 kbps ou inférieur pour tous les encodeurs audio lorsqu'ils sont sous charge. La charge ici est définie comme une session simultanée de transcodage vidéo uniquement de 1080p à 720p utilisant des codecs vidéo matériels ainsi que l'initialisation de l'enregistrement audio-vidéo 1080p.
- [5.1/H-1-9] DOIT prendre en charge 2 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ées simultanément à une résolution 4k à 30 ips (sauf AV1) pour les deux 8- bit (SDR) et contenu HDR 10 bits. Les sessions de codec AV1 ne doivent prendre en charge que la résolution 1080p, même lorsque cette exigence nécessite la 4K.
- [5.1/H-1-10] DOIT prendre en charge 3 instances de sessions de décodeur vidéo matériel non sécurisées ainsi qu'1 instance de session de décodeur vidéo matériel sécurisée (4 instances au total) (AVC, HEVC, VP9, AV1 ou version ultérieure) dans n'importe quel codec. combinaison fonctionnant simultanément avec 3 sessions à une résolution 4K à 30 ips (sauf AV1) qui comprend une session de décodeur sécurisé et 1 session sécurisée nn à une résolution de 1080p à 30 ips où au plus 2 sessions peuvent être en HDR 10 bits. Les sessions de codec AV1 ne doivent prendre en charge que la résolution 1080p, même lorsque cette exigence nécessite la 4K.
- [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 sur l'appareil.
- [5.1/H-1-12] DOIT avoir une latence d'initialisation du codec de 40 ms ou moins pour une session de décodage vidéo de 1080p ou moins pour tous les décodeurs vidéo matériels lorsqu'ils sont sous charge. Le chargement ici est défini comme une session simultanée de transcodage vidéo uniquement de 1080p à 720p utilisant des 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 de 50 ms ou moins.
- [5.1/H-1-13] DOIT avoir une latence d'initialisation du codec de 30 ms ou moins pour une session de décodage audio à débit binaire de 128 kbps ou inférieur pour tous les décodeurs audio lorsqu'ils sont sous charge. Le chargement ici est défini comme une session simultanée de transcodage vidéo uniquement de 1080p à 720p utilisant des codecs vidéo matériels ainsi que l'initialisation de la lecture audio-vidéo 1080p.
- [5.1/H-1-14] DOIT prendre en charge le décodeur matériel AV1 Main 10, niveau 4.1 et le grain du film.
- [5.1/H-1-15] DOIT avoir au moins 1 décodeur vidéo matériel prenant en charge 4K60.
- [5.1/H-1-16] DOIT avoir au moins 1 encodeur vidéo matériel prenant en charge 4K60.
- [5.3/H-1-1] NE DOIT PAS perdre plus d'une image en 10 secondes (c'est-à-dire moins de 0,167 % de perte d'image) pour une session vidéo 4K à 60 ips sous charge.
- [5.3/H-1-2] NE DOIT PAS perdre plus d'une image toutes les 10 secondes lors d'un changement de résolution vidéo dans une session vidéo à 60 ips sous charge pour une session 4K.
- [5.6/H-1-1] DOIT avoir une latence tap-to-tone de 80 millisecondes ou moins en utilisant le test tap-to-tone de CTS Verifier.
- [5.6/H-1-2] DOIT avoir une latence audio aller-retour de 80 millisecondes ou moins sur au moins un chemin de données pris en charge.
- [5.6/H-1-3] DOIT prendre en charge l'audio >=24 bits pour la sortie stéréo sur des prises audio de 3,5 mm si présentes et sur l'audio USB s'il est pris en charge sur l'ensemble du chemin de données pour les configurations à faible latence et de streaming. Pour la configuration à faible latence, AAudio doit être utilisé par l'application en mode de rappel à faible latence. Pour la configuration du streaming, un Java AudioTrack doit être utilisé par l'application. Dans les configurations à faible latence et en streaming, le récepteur de sortie HAL doit accepter
AUDIO_FORMAT_PCM_24_BIT,AUDIO_FORMAT_PCM_24_BIT_PACKED,AUDIO_FORMAT_PCM_32_BITouAUDIO_FORMAT_PCM_FLOATpour son format de sortie cible. - [5.6/H-1-4] DOIT prendre en charge >= les périphériques audio USB à 4 canaux (ceci est utilisé par les contrôleurs DJ pour prévisualiser les chansons.)
- [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 canal 7.1.4 et de spatialiser ou de mixer correctement tous les canaux en stéréo.
- [5.6/H-SR] Sont FORTEMENT RECOMMANDÉS pour 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_ALLavec les capacités de décryptage de contenu ci-dessous.
| Taille minimale de l'échantillon | 4 Mo |
| Nombre minimum de sous-échantillons – H264 ou HEVC | 32 |
| Nombre minimum de sous-échantillons - VP9 | 9 |
| Nombre minimum de sous-échantillons - AV1 | 288 |
| Taille minimale du tampon de sous-échantillon | 1 Mo |
| Taille minimale du tampon de chiffrement générique | 500 Ko |
| Nombre minimum de sessions simultanées | 30 |
| Nombre minimum de clés par session | 20 |
| Nombre total minimum de clés (toutes les sessions) | 80 |
| Nombre total minimum de clés DRM (toutes les sessions) | 6 |
| Taille du message | 16 Ko |
| Images décryptées par seconde | 60 images par seconde |
- [5.1/H-1-17] DOIT avoir au moins un décodeur d'image matériel prenant en charge le profil de base AVIF.
- [5.1/H-1-18] DOIT prendre en charge l'encodeur AV1 qui peut encoder une résolution jusqu'à 480p à 30 ips et 1 Mbps.
-
[5.12/H-1-1] DOIT[5.12/H-SR] sont fortement recommandés pour prendre en charge la fonctionnalitéFeature_HdrEditingpour tous les encodeurs matériels AV1 et HEVC présents sur l'appareil. - [5.12/H-1-2] DOIT prendre en charge le format de couleur RGBA_1010102 pour tous les encodeurs matériels AV1 et HEVC présents sur l'appareil.
- [5.12/H-1-3] DOIT annoncer la prise en charge de l'extension EXT_YUV_target pour échantillonner à partir de textures YUV en 8 et 10 bits.
- [7.1.4/H-1-1] DOIT avoir au moins 6 superpositions matérielles dans le compositeur matériel de l'unité de traitement des données (DPU) (HWC), dont au moins 2 sont capables d'afficher du contenu vidéo de 10 bits.
Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.U pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS et incluent la prise en charge d'un encodeur matériel AVC ou HEVC, alors elles :
- [5.2/H-2-1] DOIT respecter l'objectif de qualité minimale défini par les courbes débit-distorsion du codeur vidéo pour les codecs matériels AVC et HEVC, tels que définis dans la documentation à venir.
Voir révision
android.os.Build.VERSION_CODES.U pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , alors elles :- [ 7.5 /H-1-1] DOIT avoir une caméra principale orientée vers l'arrière avec une résolution d'au moins 12 mégapixels prenant en charge la capture vidéo à 4k à 30 ips. La caméra arrière principale est la caméra arrière avec l’ID de caméra le plus bas.
- [ 7.5 /H-1-2] DOIT avoir une caméra frontale principale avec une résolution d'au moins 6 mégapixels et prendre en charge la capture vidéo à 1080p à 30 ips. La caméra frontale principale est la caméra frontale avec l’ID de caméra le plus bas.
- [ 7.5 /H-1-3] DOIT prendre en charge la propriété
android.info.supportedHardwareLevelcomme FULL ou mieux pour les deux caméras principales. - [ 7.5 /H-1-4] DOIT prendre en charge
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIMEpour les deux caméras principales. - [ 7.5 /H-1-5] DOIT avoir une latence de capture JPEG de la caméra2 < 1 000
900ms pour une résolution de 1 080p telle que mesurée par le test de performance de la caméra CTS dans des conditions d'éclairage ITS (3 000 K) pour les deux caméras principales. - [ 7.5 /H-1-6] DOIT avoir une latence de démarrage de la caméra2 (caméra ouverte jusqu'à la première image de prévisualisation) < 500 ms telle que mesurée par le test de performance de la caméra CTS dans des conditions d'éclairage ITS (3 000 K) pour les deux caméras principales.
- [ 7.5 /H-1-8] DOIT prendre en charge
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAWetandroid.graphics.ImageFormat.RAW_SENSORpour la caméra arrière principale. - [ 7.5 /H-1-9] DOIT avoir une caméra principale orientée vers l'arrière prenant en charge 720p ou 1080p à 240 ips.
- [ 7.5 /H-1-10] DOIT avoir un ZOOM_RATIO minimum < 1,0 pour les caméras principales s'il y a une caméra RVB ultra-large orientée dans la même direction.
- [ 7.5 /H-1-11] DOIT mettre en œuvre une diffusion simultanée avant-arrière sur les caméras principales.
- [ 7.5 /H-1-12] DOIT prendre en charge
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATIONpour les caméras avant et arrière principales. - [ 7.5 /H-1-13] DOIT prendre en charge la capacité
LOGICAL_MULTI_CAMERApour les caméras principales s'il y a plus d'une caméra RVB orientée dans la même direction. - [ 7.5 /H-1-14] DOIT prendre en charge la capacité
STREAM_USE_CASEpour les caméras avant et arrière principales. - [ 7.5 /H-1-15] DOIT prendre en charge les extensions des modes
Bokeh etNuit via les extensions CameraX et Camera2 pour les caméras principales. - [ 7.5 /H-1-16] DOIT prendre en charge la capacité 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.
Voir révision
android.os.Build.VERSION_CODES.U pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , alors elles :- [7.1.1.1/H-2-1] DOIT avoir une résolution d'écran d'au moins 1080p.
- [7.1.1.3/H-2-1] DOIT avoir une densité d'écran d'au moins 400 dpi.
- [7.1.1.3/H-3-1] DOIT avoir un écran HDR prenant en charge une moyenne d'au moins 1 000 nits.
- [7.6.1/H-2-1] DOIT avoir au moins 8 Go de mémoire physique.
Voir révision
android.os.Build.VERSION_CODES.U pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , alors elles :- [8.2/H-1-1] DOIT garantir des performances d'écriture séquentielle d'au moins 150 Mo/s.
- [8.2/H-1-2] DOIT garantir des performances d'écriture aléatoire d'au moins 10 Mo/s.
- [8.2/H-1-3] DOIT garantir des performances de lecture séquentielle d'au moins 250 Mo/s.
- [8.2/H-1-4] DOIT garantir des performances de lecture aléatoire d'au moins 100 Mo/s.
- [8.2/H-1-5] DOIT garantir des performances de lecture et d'écriture séquentielles parallèles avec des performances de lecture 2x et 1x écriture d'au moins 50 Mo/s.
Voir révision
Les mises en œuvre d'appareils de télévision DOIVENT prendre en charge les formats de codage vidéo suivants et les mettre à la disposition des applications tierces :
- [ 5.2 /T-0-3]AV1
Les mises en œuvre 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.2 /T-0-7] AV1
Voir révision
Si les implémentations d'appareil disposent d'un écran de verrouillage sécurisé et incluent un ou plusieurs agents de confiance, qui implémentent l'API du système TrustAgentService , elles :
- [ 9.11.1 /W-1-1] DOIT demander à l'utilisateur l'une des méthodes d'authentification principales recommandées (par exemple : code PIN, modèle, mot de passe) plus d'une fois toutes les 72 heures.
Voir révision
Si les implémentations d'appareils incluent la prise en charge de la diffusion radio AM/FM et exposent la fonctionnalité à n'importe quelle application, elles :
- [ 7.4
.10/A-0-1] DOIT déclarer la prise en charge deFEATURE_BROADCAST_RADIO.
Une caméra de vue extérieure est une caméra qui image des scènes en dehors de la mise en œuvre de l'appareil, comme la caméra de recul.
Implémentations d'appareils automobiles :
- DEVRAIT inclure une ou plusieurs caméras de vue extérieures.
Si les implémentations de dispositifs automobiles incluent une caméra de vue extérieure, pour une telle caméra, elles :
- [ 7.5 /A-1-1] NE DOIT PAS disposer de caméras de vue extérieures accessibles via les API de caméra Android , à moins qu'elles ne soient conformes aux exigences principales des caméras.
- [ 7.5 /A-SR-1] Sont FORTEMENT RECOMMANDÉS de ne pas faire pivoter ou refléter horizontalement l'aperçu de la caméra.
- [ 7.5 /A-SR-2] Sont FORTEMENT RECOMMANDÉS d'avoir une résolution d'au moins 1,3 mégapixels.
- DEVRAIT avoir un matériel à mise au point fixe ou EDOF (profondeur de champ étendue).
- PEUT avoir une mise au point automatique matérielle ou une mise au point automatique logicielle implémentée dans le pilote de la caméra.
Si les implémentations de dispositifs automobiles incluent une ou plusieurs caméras de vue extérieure et chargent le service de système de vue extérieure (EVS), alors pour une telle caméra, elles :
- [ 7.5 /A-2-1] NE DOIT PAS faire pivoter ou refléter horizontalement l'aperçu de la caméra.
Implémentations d'appareils automobiles :
- PEUT inclure une ou plusieurs caméras disponibles pour des applications tierces.
Si les implémentations de dispositifs automobiles incluent au moins une caméra et la mettent à la disposition d'applications tierces, elles :
- [ 7.5 /A-3-1] DOIT signaler l'indicateur de fonctionnalité
android.hardware.camera.any. - [ 7.5 /A-3-2] NE DOIT pas déclarer la caméra comme caméra système .
- PEUT prendre en charge les caméras externes décrites dans la section 7.5.3 .
- PEUT inclure des fonctionnalités (telles que la mise au point automatique, etc.) disponibles pour les caméras orientées vers l'arrière, comme décrit dans la section 7.5.1 .
Une caméra orientée vers l'arrière désigne une caméra orientée vers le monde qui peut être située à n'importe quel endroit du véhicule et fait face à l'extérieur de l'habitacle du véhicule ; c'est-à-dire qu'il image des scènes de l'autre côté de la carrosserie du véhicule, comme la caméra de recul.
Une caméra frontale désigne une caméra orientée vers l'utilisateur qui peut être située à n'importe quel endroit du véhicule et fait face à l'intérieur de l'habitacle du véhicule ; c'est-à-dire qu'il image l'utilisateur, comme pour la vidéoconférence et les applications similaires.
Implémentations d'appareils automobiles :
- [7.5/A-SR-1] Sont FORTEMENT RECOMMANDÉS d'inclure une ou plusieurs caméras orientées vers le monde.
- PEUT inclure une ou plusieurs caméras orientées vers l'utilisateur.
- [7.5 / a-sr-2] sont fortement recommandés pour prendre en charge le streaming simultané de plusieurs caméras.
Si les implémentations des périphériques automobiles incluent au moins une caméra qui est orientée dans le monde, pour une telle caméra, elles:
- [7.5 / A-1-1] doit être orienté de sorte que la longue dimension de la caméra s'aligne sur le plan XY des axes de capteur automobile Android.
- [7.5 / a-sr-3] sont fortement recommandés pour avoir du matériel fixe ou EDOF (profondeur de champ étendue).
- [7.5 / A-1-2] Doit avoir la principale caméra du monde en tant que caméra orientée vers le monde avec l'ID de caméra le plus bas.
Si les implémentations des périphériques automobiles incluent au moins une caméra qui est orientée vers les utilisateurs, pour une telle caméra:
- [7.5 / A-2-1] La caméra principale orientée utilisateur doit être la caméra orientée utilisateur avec l'ID de caméra le plus bas.
- Peut être orienté de sorte que la longue dimension de la caméra s'aligne sur le plan XY des axes de capteur automobile Android.
Si les implémentations de périphériques automobiles incluent une caméra accessible via android.hardware.Camera ou android.hardware.camera2 , alors ils:
- [7.5 / A-3-1] doit se conformer aux exigences de la caméra de base dans la section 7.5.
Si les implémentations de périphériques automobiles incluent une caméra qui n'est pas accessible via android.hardware.Camera ou android.hardware.camera2 , alors ils:
- [7.5 / A-4-1] doit être accessible via le service système de vue étendue.
Si les implémentations des périphériques automobiles incluent une ou plusieurs caméras accessibles via le service système de vue étendue, pour une telle caméra, ils:
- [7.5 / A-5-1] ne doit pas tourner ou refléter horizontalement l'aperçu de la caméra.
- [7.5 / a-sr-4] sont fortement recommandés par une résolution d'au moins 1,3 mégapixel.
Si les implémentations des périphériques automobiles incluent une ou plusieurs caméras accessibles via à la fois le service système étendu et android.hardware.Camera ou android.hardware.Camera2 API alors, pour une telle caméra, ils: ils:
- [7.5 / A-6-1] doit signaler le même ID de la caméra.
Si les implémentations des périphériques automobiles fournissent une API de caméra propriétaire, elles:
- [7.5 / A-7-1] doit implémenter une telle API de la caméra à l'aide de l'API
android.hardware.camera2ou API Système de vue étendue.
Voir révision
Implémentations des périphériques automobiles:
- [ 3.8 / A-0-1] ne doit pas autoriser les utilisateurs secondaires complets qui ne sont pas l'utilisateur de premier plan actuel de lancer des activités et d'avoir accès à l'interface utilisateur sur des écrans.
Voir révision
Si les implémentations de périphériques automobiles déclarent android.hardware.microphone , ils:
- [ 9.8.2 / a-1-1] doit afficher l'indicateur de microphone lorsqu'une application accéde aux données audio à partir du microphone, mais pas lorsque le microphone n'est accessible que par
HotwordDetectionService,SOURCE_HOTWORD,ContentCaptureServiceou applications tenant les rôles appelés dans la section 9.1 avec l'identifiant CDD [C-4-X]. - [ 9.8.2 / a-1-2] ne doit pas masquer l'indicateur de microphone pour les applications système qui ont des interfaces utilisateur visibles ou une interaction utilisateur direct.
- [ 9.8.2 / A-1-3] Doit fournir une abondance de l'utilisateur pour basculer le microphone dans l'application Paramètres.
Si les implémentations de périphériques automobiles déclarent android.hardware.camera.any , alors ils:
- [ 9.8.2 / A-2-1] doit afficher l'indicateur de la caméra lorsqu'une application accéde aux données de la caméra en direct, mais pas lorsque l'appareil photo n'est accessible que par des applications tenant les rôles tels que définis
appelésdans la section 9.1 avec l'identifiant CDD [C-4-X][C-3-X].
- [ 9.8.2 / A-2-3] Doit fournir une abondance de l'utilisateur pour basculer l'appareil photo dans l'application Paramètres.
- [ 9.8.2 / A-2-4] Doit afficher des applications récentes et actives à l'aide de la caméra comme renvoyée à partir de
PermissionManager.getIndicatorAppOpUsageData(), ainsi que les messages d'attribution qui leur sont associés.
Si les implémentations de périphériques ont un écran de verrouillage sécurisé et incluent un ou plusieurs agents de fiducie, qui met en œuvre l'API du système TrustAgentService , ils:
- [ 9.11.1 / a-1-1] Doit défier l'utilisateur pour l'une des méthodes d'authentification primaires recommandées (par exemple: broche, modèle, mot de passe) plus fréquemment qu'une fois toutes les 336 heures.
3. Logiciels
3.1. Compatibilité API gérée :
Voir révision
Implémentations de l'appareil:
- [C-0-8] ne doit pas prendre en charge l'installation d'applications ciblant un niveau d'API inférieur à 23.
3.2.3.5. Intention de l'application conditionnelle :
Voir révision
Si les implémentations de périphériques rapportent
android.hardware.nfc.uiccouandroid.hardware.nfc.ese, elles:- [C-19-1] doit implémenter l'API d'intention NFCADAPTER.ACTION_TRANSACTION_DETECTÉ (en tant que «EVT_TRANSACTION» défini par la spécification technique de l'association GSM TS.26 - Exigences du combiné NFC) .
3.3.1. Interfaces binaires d'application :
Voir révision
Implémentations de l'appareil:
- [C-0-12] Doit exporter des symboles de fonction pour les symboles de fonction
Vulkan 1.0Vulkan 1.1 Core, ainsi que pour leVK_KHR_surface,VK_KHR_android_surfacelibvulkan.soVK_KHR_swapchain,VK_KHR_maintenance1, etVK_KHR_get_physical_device_properties2. Notez que même si tous les symboles doivent être présents, la section 7.1.4.2 décrit plus en détail les exigences pour la mise en œuvre complète de chaque fonctions correspondantes.
- [C-0-12] Doit exporter des symboles de fonction pour les symboles de fonction
Voir révision
Si les implémentations de périphériques incluent une sortie d'écran ou de vidéo, elles:
- [C-1-5]
RAINBOWEXPRESSIVEVIBRANTandroid.theme.customization.theme_stylestonalesFRUIT_SALADcouleur dynamique à l'aideSPRITZstyles deTONAL_SPOTde couleur énumérés dans lesSettings.THEME_CUSTOMIZATION_OVERLAY_PACKAGESMONOCHROMATIC.
- [C-1-5]
3.8.8. Commutation d'activité :
Voir révision
Si les implémentations de périphériques, y compris la touche de navigation des fonctions récentes, sont détaillées dans la section 7.2.3 modifier l'interface, elles:
- [C-1-2] doit implémenter le comportement d'épinglage de l'écran et fournir à l'utilisateur un menu Paramètres pour basculer la fonctionnalité.
3.9.2 Support de profil géré :
Voir révision
Si les implémentations de périphériques déclarent
android.software.managed_users, ils:- [C-1-10] doit s'assurer que les données de capture d'écran sont enregistrées dans le stockage du profil de travail lorsqu'une capture d'écran est capturée avec une fenêtre
topActivityqui a une mise au point (celle avec laquelle l'utilisateur a interagi parmi toutes les activités) et appartient à un profil de travail application . - [C-1-11] ne doit pas capturer aucun autre contenu d'écran (barre système, notifications ou tout contenu de profil personnel) à l'exception de la fenêtre / fenêtres de l'application de profil de travail lors de l'enregistrement d'une capture d'écran dans le profil de travail (pour s'assurer que les données de profil personnel sont non enregistré dans le profil de travail).
- [C-1-10] doit s'assurer que les données de capture d'écran sont enregistrées dans le stockage du profil de travail lorsqu'une capture d'écran est capturée avec une fenêtre
3.9.5 Cadre de résolution des politiques de l'appareil : nouvelle section
Voir révision
Si les implémentations de périphérique rapportent
android.software.device_adminouandroid.software.managed_users, alors ils:- [C-1-1] doit résoudre les conflits de politique de dispositif tels que documentés dans la documentation AOSP.
5. Compatibilité multimédia
Voir révision
Les implémentations de périphériques doivent prendre en charge l'encodage du codage d'image suivant:
- [C-0-4] AVIF
- Les périphériques doivent prendre en charge
BITRATE_MODE_CQet le profil de base.
- Les périphériques doivent prendre en charge
- [C-0-4] AVIF
Voir révision
Les implémentations de périphériques doivent prendre en charge le décodage du codage d'image suivant:
[C-0-7] AVIF (profil de base)
5.1.6. Détails des codecs d'image :
Voir révision
Format / codec Détails Types de fichiers pris en charge / formats de conteneurs JPEG Base + progressive Jpeg (.jpg) GIF Gif (.gif) PNG Png (.png) PGB BMP (.bmp) WebP Webp (.webp) Brut 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 base) Image, collection d'images, profil de base de séquence d'images Contaiteur Heif (.AVIF) 5.1.8. Liste des codecs vidéo :
Voir révision
Format / codec Détails Types de fichiers / formats de conteneur à prendre en charge H.263 - 3GPP (.3gp)
- MPEG-4 (.mp4)
- Matroska (.mkv, décoder uniquement)
H.264 AVC Voir section 5.2 et 5.3 pour plus de détails - 3GPP (.3gp)
- MPEG-4 (.mp4)
- MPEG-2 TS (.ts, non cherche)
- Matroska (.mkv, décoder uniquement)
H.265 HEVC Voir la section 5.3 pour plus de détails - MPEG-4 (.mp4)
- Matroska (.mkv, décoder uniquement)
Mpeg-2 Profil principal - MPEG2-TS (.ts, non cherche)
- MPEG-4 (.mp4, décoder uniquement)
- Matroska (.mkv, décoder uniquement)
MPEG-4 SP - 3GPP (.3gp)
- MPEG-4 (.mp4)
- Matroska (.mkv, décoder uniquement)
VP8 Voir section 5.2 et 5.3 pour plus de détails - Webm (.webm)
- Matroska (.mkv)
VP9 Voir la section 5.3 pour plus de détails - Webm (.webm)
- Matroska (.mkv)
AV1 Voir section 5.2 et section 5.3 pour plus de détails - MPEG-4 (.mp4)
- Matroska (.mkv, décoder uniquement)
5.1.10. Caractérisation du codec média :
Voir révision
Si les implémentations de périphériques prennent en charge 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 prises en charge par le codec:
SD (basse qualité) SD (haute qualité) HD 720p HD 1080p Euh Résolution vidéo - 176 x 144 px (H263, MPEG2, MPEG4)
- 352 x 288 px (Encodeur MPEG4, H263, MPEG2)
- 320 x 180 px (VP8, VP8)
- 320 x 240 px (autre)
- 704 x 576 px (H263)
- 640 x 360 px (VP8, VP9)
- 640 x 480 px (Encodeur MPEG4)
- 720 x 480 px (autre, AV1 )
- 1408 x 1152 px (H263)
- 1280 x 720 px (autre, AV1 )
1920 x 1080 px (autre que MPEG4, AV1 ) 3840 x 2160 px (HEVC, VP9, AV1 ) Voir révision
Si les implémentations de périphériques prennent en charge n'importe quel encodeur vidéo et la mettent à la disposition des applications tierces, elles:- Ne devrait pas l'être, sur deux fenêtres coulissantes, plus de 15% sur le jeu de binaire entre les intervalles intraframe (I-Frame).
- Ne devrait pas être supérieur à 100% sur le débit binaire sur une fenêtre coulissante de 1 seconde.
Si les implémentations de l'appareil prennent en charge n'importe quel encodeur vidéo et la mettez à la disposition des applications tierces, et définissez le
MediaFormat.KEY_BITRATE_MODEàBITRATE_MODE_VBRafin que le codeur fonctionne en mode de débit variable, alors, tant qu'il n'a pas d'impact sur le plancher de qualité minimale , le débit binaire codé:-
[C-5-1] ne doitpas être, sur une fenêtre coulissante, plus de 15% sur le jeu de binaire entre les intervalles intraframe (I-Frame). -
[C-5-2] doitne pas être supérieur à 100% sur le débit binaire sur une fenêtre coulissante de 1 seconde.
Si les implémentations de périphériques prennent en charge n'importe quel encodeur vidéo et la mettez à la disposition des applications tierces et définissez le
MediaFormat.KEY_BITRATE_MODEsurBITRATE_MODE_CBRafin que le codeur fonctionne en mode de débit constant, puis le débit binaire codé:-
[C-6-1] doit[C-Sr-2] est fortement recommandé de ne pas dépasser 15% sur le débit binaire cible sur une fenêtre coulissante de 1 seconde.
Voir révision
Si les implémentations de périphériques prennent en charge les encodeurs H.263 et le mettent à la disposition des applications tierces, elles:
- [C-1-1] doit prendre en charge la résolution QCIF (176 x 144) en utilisant le niveau de profil de base 45. La résolution SQCIF est facultative.
-
Devrait prendre en charge les débits de binde configurables pour l'encodeur pris en charge.
Voir révision
Si les implémentations de périphériques prennent en charge le codec H.265, ils:
- [C-1-1] doit prendre en charge le niveau principal de profil 3 jusqu'à 512 x 512 .
-
Devrait prendre en charge les profils d'encodage HD comme indiqué dans le tableau suivant. - [C-SR-1] sont fortement recommandés pour prendre en charge le profil SD 720 x 480 et les profils de codage HD comme indiqué dans le tableau suivant s'il existe un codeur matériel.
5.2.6. AV1 : nouvelle section
Voir révision
Si les implémentations de périphériques prennent en charge AV1 Codec, ils: ils:
- [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 de performances, c'est-à-dire les données de performances du rapport via les API
getSupportedFrameRatesFor()ougetSupportedPerformancePoints()pour les résolutions prises en charge dans le tableau ci-dessous.[C-1-3] Doit accepter les métadonnées HDR et la sortir dans le flux Bits
Si le codeur AV1 est accéléré du matériel, alors il:
- [C-2-1] doit prendre en charge jusqu'à et y compris le profil de codage HD1080P du tableau ci-dessous:
Dakota du Sud HD 720p HD 1080p Euh Résolution vidéo 720 x 480 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 px Frame rate vidéo 30 ips 30 ips 30 ips 30 ips Bitrate vidéo 5 Mbit/s 8 Mbps 16 Mbps 50 Mbps Voir révision
Si les implémentations de périphériques prennent en charge les décodeurs H.263, ils:
- [C-1-1] doit prendre en charge le niveau de profil de base 30 (résolutions CIF, QCIF et SQCIF @ 30fps 384Kbps) et niveau 45 (résolutions QCIF et SQCIF à 30fps 128Kbps) .
Voir révision
Si les implémentations de périphériques prennent en charge le codec AV1, ils:- [C-1-1] doit prendre en charge le profil 0, y compris le contenu 10 bits.
Si les implémentations de périphériques prennent en charge le codec AV1 et la mettent à la disposition des 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 de périphériques prennent en charge le codec AV1 avec un décodeur accéléré du matériel, ils: ils:
- [C-2-1] doit être capable de décoder au moins les profils de décodage vidéo HD 720p du tableau ci-dessous lorsque la hauteur rapportée par
Display.getSupportedModes()est égale ou supérieure à 720p. - [C-2-2] doit être capable de décoder au moins les profils de décodage vidéo HD 1080p du tableau ci-dessous lorsque la hauteur rapportée par
Display.getSupportedModes()est égale ou supérieure à 1080p.
Dakota du Sud HD 720p HD 1080p Euh Résolution vidéo 720 x 480 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 px Frame rate vidéo 30 ips 30 ips 30 ips 30 ips Bitrate vidéo 5 Mbit/s 8 Mbps 16 Mbps 50 Mbps Si les implémentations de périphériques prennent en charge le profil HDR via les API média, alors ils:
- [C-3-1] doit prendre en charge l'extraction et la sortie des métadonnées HDR à partir du flux BitsTream 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.2. Capture pour la reconnaissance vocale :
Voir révision
Si les implémentations de périphériques déclarent
android.hardware.microphone, elles:- Devrait définir une sensibilité à l'entrée audio de sorte qu'une source de tonalité sinusoïdale de 1000 Hz jouée à 90 dB le niveau de pression sonore (SPL) (mesurée
à une distance de 30 cm decôté au microphone) donne une réponse idéale de RMS 2500 dans une plage de 1770 et 3530 pour des échantillons 16 bits (ou -22,35 dB ± 3DB à pleine échelle pour les échantillons de points flottants / double précision) pour chaque microphone utilisé pour enregistrer la source audio de reconnaissance vocale.
- Devrait définir une sensibilité à l'entrée audio de sorte qu'une source de tonalité sinusoïdale de 1000 Hz jouée à 90 dB le niveau de pression sonore (SPL) (mesurée
Voir révision
Si les implémentations de périphériques déclarent la fonctionnalité
android.hardware.audio.output, elles:- [C-1-4] doit prendre en charge les effets audio avec une entrée et une sortie à virgule flottante.
- [C-1-5] doit s'assurer que les effets audio prennent en charge plusieurs canaux jusqu'au nombre de canaux de mélangeurs également connus sous le nom de FCC_LIMIT.
Voir révision
Si les implémentations de périphériques déclarent
android.hardware.audio.outputelles sont fortement recommandées pour répondre ou dépasser les exigences suivantes:- [C-SR-4] L'horodatage de sortie renvoyé par AudioTrack.gettimestamp et
AAudioStream_getTimestampest précis à +/- 1 ms.
- [C-SR-4] Les latences aller-retour calculées basées sur les horodatages d'entrée et de sortie renvoyées par
AAudioStream_getTimestampsont fortement recommandées pour être à moins de 30 ms de la latence d'emploi mesurée pourAAUDIO_PERFORMANCE_MODE_NONEetAAUDIO_PERFORMANCE_MODE_LOW_LATENCYpour les conférenciers, les talques d'évacuation et de fil.
- [C-SR-4] L'horodatage de sortie renvoyé par AudioTrack.gettimestamp et
7. Compatibilité matérielle
7.1. Affichage et graphiques :
Voir révision
Android comprend des installations qui ajustent automatiquement les actifs d'application et les dispositions d'interface utilisateur de manière appropriée pour l'appareil afin de garantir que les applications tierces fonctionnent bien sur une
variété de configurations matérielles .variété d'affichages matériels et configurations. Un affichage compatible Android est un écran d'affichage qui met en œuvre tous les comportements et API décrits dans Android Developers - Présentation de la compatibilité des écrans , cette section (7.1) et ses sous-sections, ainsi que tout comportement spécifique de type d'appareil supplémentaire documenté dans la section 2 de la section 2 de la section 2 de la section 2 de la section 2 de Ce CDD.Sur les écrans compatibles Android où toutes les applications compatibles Android tierces peuvent s'exécuter, les implémentations de périphériques doivent correctement implémenter ces API et comportements, comme détaillé dans cette section.Démarrer de nouvelles exigences
Implémentations de l'appareil:
- [C-0-1] doit, par défaut, rendre les applications tierces uniquement sur des écrans compatibles Android.
Les unités référencées par les exigences de cette section sont définies comme suit:
- Taille diagonale physique . La distance en pouces entre deux coins opposés de la partie illuminée de l'écran.
-
points par pouce (dpi)densité . Le nombre de pixels englobés par une portée horizontale ou verticale linéaire de 1 ” , exprimée en pixels par pouce (PPI ou DPI) . Lorsque les valeursDPIPPI et DPI sont répertoriées, le DPI horizontal et vertical doit se situer dans la plage énumérée . - ratio d'aspect . Le rapport des pixels de la dimension plus longue à la dimension plus courte de l'écran. Par exemple, un affichage de 480x854 pixels serait 854/480 = 1,779, ou à peu près «16: 9».
- Pixel indépendant de la densité (DP) .
L'unité de pixels virtuelle normalisée à une densité d'écrand'écran de 160 dpide 160. Pour une densité D, et un certain nombre de pixels P, le nombre de pixels indépendants de la densité est calculé comme:pixels = dps * (densité / 160)dp = (160 / d) * p .
7.1.1.1. Taille et forme de l'écran :
Voir révision
Si les implémentations de périphériques prennent en charge les écrans capables de la configuration de taille
UI_MODE_TYPE_NORMALetincluentdes affichages physiques compatibles Android avec des coins arrondis pour rendre ces écrans , ils: ils:- [C-1-1] doit s'assurer qu'au moins l'une des exigences suivantes est remplie pour chacun de ces écrans :
- Le rayon des coins arrondis est inférieur ou égal à 38 dp.
Lorsqu'une boîte de 15 DP par 15 DP est ancrée dans chaque coin de l'écran logique, au moins un pixel de chaque boîte est visible à l'écran.
Devrait inclure la rédaction de l'utilisateur pour passer au mode d'affichage avec les coins rectangulaires.
Démarrer de nouvelles exigences
Si les implémentations de périphériques ne sont capables que de la configuration du clavier
NO_KEYSet ont l'intention de signaler la prise en charge de la configuration du mode d'interface utilisateurUI_MODE_TYPE_NORMAL, elles: elles:- [C-4-1] Doit avoir une taille de disposition, à l'exclusion de toute découpe d'affichage, d'au moins 596 dp x 384 dp ou plus.
Si les implémentations de périphériques incluent un ou plusieurs écrans compatibles Android qui est pliable, ou comprend une charnière pliante entre plusieurs panneaux d'affichage et met à disposition de ces affichages pour rendre des applications tierces, elles: elles:
- [C-2-1] doit implémenter la dernière version stable disponible de l' API Extensions ou la version stable de l'API SideCar à utiliser par la bibliothèque de Window Manager Jetpack .
Si les implémentations de périphériques incluent un ou plusieurs écrans compatibles Android qui est pliable, ou comprend une charnière pliante entre plusieurs panneaux d'affichage et si la charnière ou le pli traverse une fenêtre d'application pleine écran, elles:
- [C-3-1] doit signaler la position, les limites et l'état de la charnière ou le pliant à travers des extensions ou des API de side-car à l'application.
Si les implémentations de l'appareil comprennent une ou plusieurs zones d'affichage compatibles Android qui sont pliables, ou incluent une charnière pliante entre plusieurs zones de panneaux d'affichage compatibles Android et rendre ces zones d'affichage à la disposition des applications, elles:
- [C-4-1] doit implémenter la version correcte du niveau d'API d'extensions du gestionnaire de fenêtres comme décrit dans la documentation à venir.
7.1.1.2. Ratio d'aspect d'écran : supprimé
Voir révision
Implémentations de l'appareil:
- [C-0-1]
Par défaut, les implémentations de périphériquesne doivent signalerqu'uneseule des densités de framework Android répertoriées surDisplayMetricsvia l' APIDENSITY_DEVICE_STABLEet cette valeur doit être une valeur statique pour chaque affichage physiquene doit pas changer à tout moment; Cependant,cependant , le périphérique peut signaler unedensité arbitrairedifférenteDisplayMetrics.densityen fonction des modifications de configuration d'affichage apportées par l'utilisateur (par exemple, la taille de l'affichage) définie après le démarrage initial.
- Les implémentations de l'appareil doivent définir la densité du cadre Android standard qui est numériquement la plus proche de la densité physique de l'écran, à moins que la densité logique pousse la taille de l'écran rapportée en dessous du minimum pris en charge. Si la densité du cadre Android standard qui est numériquement la plus proche de la densité physique se traduit par une taille d'écran plus petite que la taille d'écran compatible la plus petite prise en charge (320 dp largeur), les implémentations de périphériques doivent signaler la densité de framework Android standard la plus basse suivante.
Démarrer de nouvelles exigences
- Devrait définir la densité du cadre Android standard qui est numériquement la plus proche de la densité physique de l'écran, ou une valeur qui mapperait aux mêmes mesures de champ angulaire équivalent d'un dispositif portable.
Si les implémentations de l'appareil fournissent,
il y aune récompense pour modifier la taille d'affichage de l'appareil , elles :- [C-1-1]
La taille de l'affichage ne doit pas être mise à l'échellene doit pas faire évoluer l'affichage supérieur à 1,5 foisDENSITY_DEVICE_STABLEdensité nativeou produire une dimension d'écran minimale efficace inférieure à 320 dp (équivalent à la qualification de ressources SW320DP), selon la première fois. - [C-1-2]
La taille de l'affichage ne doit pas être mise à l'échelle dene pas faire évoluer l'affichage inférieur à 0,85 fois ladensité nativeDENSITY_DEVICE_STABLE.
- [C-0-1]
Voir révision
Si les implémentations de périphériques incluent la prise en charge de Vulkan
1.0 ou plus, elles: elles:[C-1-3] doit implémenter pleinement les API
Vulkan 1.0Vulkan 1.1 pour chaqueVkPhysicalDeviceénuméré.[C-1-5] ne doit pas énumérer les couches fournies par les bibliothèques en dehors du package d'application, ni fournir d'autres moyens de traçage ou d'interception de l'API Vulkan, à moins que l'application ait l'attribut
android:debuggableEnsemble commetrueou les métadonnéescom.android.graphics.injectLayers.enableset totrue.
- Devrait prendre en charge
VkPhysicalDeviceProtectedMemoryFeaturesetVK_EXT_global_priority.
- [C-1-13] doit satisfaire aux exigences spécifiées par le profil Android Basline 2021 .
[C-SR-5] sont fortement recommandés pour prendre en charge
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemoryetVK_EXT_global_priority.[C-SR-6] sont fortement recommandés d'utiliser
SkiaVkavec HWUI.
Si les implémentations de périphériques incluent la prise en charge de Vulkan 1.1 et déclarent l'un des indicateurs de fonctionnalité Vulkan décrits ici , ils:
- [C-SR-7] sont fortement recommandés pour rendre l'extension
VK_KHR_external_fence_fdà la disposition des applications tierces et activer l'application pour exporter la charge utile de clôture et importer la charge utile de clôture à partir de descripteurs de fichiers POSIX comme décrit ici .
7.3.10. Capteurs biométriques :
Voir révision
Si les implémentations de périphériques ont plusieurs capteurs biométriques, ils:
[C-7-1] Doit, lorsqu'un biométrique est dans le lock-out (c'est-à-dire que la biométrique est désactivée jusqu'à ce que l'utilisateur se déverrouille avec authentification principale) ou le lock-out lié à l'heure (c'est-à-dire que le biométrique est temporairement désactivé jusqu'à ce que l'utilisateur attend un intervalle de temps) En raison de trop de tentatives infructueuses, verrouillez également toutes les autres biométriques d'une classe biométrique inférieure. Dans le cas du lock-out limité dans le temps, le temps de backoff pour la vérification biométrique doit être le temps de backoff maximum de toutes les biométriques dans le lock-out limité.
[C-SR-12] sont fortement recommandés, lorsqu'un biométrique est en lock-out (c'est-à-dire que le biométrique est désactivé jusqu'à ce que l'utilisateur se déverrouille avec l'authentification principale) ou le verrouillage lié à l'heure (c'est-à-dire que le biométrique est temporairement désactivé jusqu'à ce que l'utilisateur attend un temps pendant un certain temps Interval) en raison de trop de tentatives infructueuses, pour verrouiller également toutes les autres biométriques de la même classe biométrique. Dans le cas du lock-out limité dans le temps, le temps de backoff pour la vérification biométrique est fortement recommandé d'être le temps de backoff maximum de toutes les biométriques dans le verrouillage limité dans le temps.
[C-7-2] doit contester l'utilisateur de l'authentification primaire recommandée (par exemple: broche, modèle, mot de passe) pour réinitialiser le compteur de verrouillage pour un biométrique verrouillé. La biométrie de classe 3 peut être autorisée à réinitialiser le compteur de verrouillage pour une biométrique verrouillée de la même classe ou inférieure. La biométrie de classe 2 ou de classe 1 ne doit pas être autorisée à terminer une opération de verrouillage de réinitialisation pour toute biométrie.
Si les implémentations de dispositifs souhaitent traiter un capteur biométrique comme classe 1 (anciennement commodité ), ils:
[C-1-12] Doit avoir un taux d'acceptation parodie et imposteur pas supérieur à 40% par espèce d'instrument d'attaque de présentation (PAI) , mesuré par les protocoles d'essai de biométrie Android .
[C-SR-13] sont fortement recommandés pour avoir un taux d'acceptation parodie et imposteur pas supérieur à 30% par espèce d'instrument d'attaque de présentation (PAI) , tel que mesuré par les protocoles d'essai de biométrie Android .
[C-SR-14] sont fortement recommandés pour divulguer la classe biométrique du capteur biométrique et les risques correspondants de l'activer.
[C-SR-17] sont fortement recommandés pour mettre en œuvre les nouvelles interfaces AIDL (telles que
IFace.aidletIFingerprint.aidl).
Si les implémentations de dispositifs souhaitent traiter un capteur biométrique comme classe 2 (anciennement faible ), ils:
- [C-SR-15] sont fortement recommandés par avoir un taux d'acceptation parodie et imposteur pas supérieur à 20% par espèce d'instrument d'attaque de présentation (PAI) , tel que mesuré par les protocoles d'essai de biométrie Android .
- [C-2-3] doit effectuer la correspondance biométrique dans un environnement d'exécution isolée en dehors de l'utilisateur Android ou de l'espace du noyau, comme l'environnement d'exécution de confiance (TEE),
ousur une puce avec un canal sécurisé vers l'environnement d'exécution isolée ou sur protégé Machine virtuelle qui répond aux exigences de la section 9.17 . - [C-2-4] Doit avoir toutes les données identifiables cryptées et authentifiées cryptographiquement de telle sorte qu'elles ne peuvent pas être acquises, lues ou modifiées en dehors de l'environnement d'exécution isolée ou une puce avec un canal sécurisé vers l'environnement d'exécution isolée, tel que documenté dans les directives de mise en œuvre sur le site du projet open source Android ou une machine virtuelle protégée contrôlée par l'hyperviseur qui répond aux exigences de la section 9.17 .
- [C-2-5] pour la biométrie basée sur la caméra, tandis que l'authentification ou l'inscription basée sur la biométrique se produit:
- Doit faire fonctionner la caméra dans un mode qui empêche les cadres de caméra d'être lus ou modifiés à l'extérieur de l'environnement d'exécution isolée ou une puce avec un canal sécurisé vers l'environnement d'exécution isolée ou une machine virtuelle protégée contrôlée par l'hyperviseur qui répond aux exigences de la section 9.17 .
- Pour les solutions RVB monomares, les cadres de caméra peuvent être lisibles en dehors de l'environnement d'exécution isolée pour prendre en charge les opérations telles que l'aperçu pour l'inscription, mais ne doivent toujours pas être modifiables.
- [C-2-7] ne doit pas permettre un accès non crypté à des données biométriques identifiables ou à toute données en dérive (telles que des intégres) au processeur d'application en dehors du contexte du TEE ou de la machine virtuelle protégée contrôlée par l'hyperviseur qui répond aux exigences dans la section 9.17 . Les appareils de mise à niveau lancés sur Android version 9 ou antérieurs ne sont pas exemptés du C-2-7.
Si les implémentations de dispositifs souhaitent traiter un capteur biométrique comme classe 3 (anciennement fort ), ils:
- [C-SR-16] sont fortement recommandés pour avoir un taux d'acceptation d'usurpation et d'imposteur pas supérieur à 7% par espèce d'instrument d'attaque de présentation (PAI) , tel que mesuré par les protocoles d'essai de biométrie Android .
7.3.13. IEEE 802.1.15.4 (UWB) :
Voir révision
Si les implémentations de périphériques incluent la prise en charge du 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éfinies dans l'implémentation AOSP.
-
CONFIG_ID_1:STATIC STS DS-TWRdéfinie par FIRA, Mode différé, intervalle de télévision 240 ms. -
CONFIG_ID_2: STS statique un-à-plusieurs définis par FIRASTATIC STS DS-TWR, Mode différé, intervalle de télévision 200 ms. Cas d'utilisation typique: le téléphone intelligent interagit avec de nombreux appareils intelligents. -
CONFIG_ID_3: Identique àCONFIG_ID_1, les données à l'exception de l'angle d'arrivée (AOA) ne sont pas rapportées. -
CONFIG_ID_4: identique àCONFIG_ID_1, sauf que le mode de sécurité P-STS est activé. -
CONFIG_ID_5: identique àCONFIG_ID_2, sauf que le mode de sécurité P-STS est activé. -
CONFIG_ID_6: identique àCONFIG_ID_3, sauf que le mode de sécurité P-STS est activé. -
CONFIG_ID_7: identique àCONFIG_ID_2, sauf que le mode de clé de contrôle individuel du contrôle individuel est activé.
-
- [C-1-4] Doit fournir une abondance de l'utilisateur pour permettre à l'utilisateur de basculer l'état de radio UWB sur / désactivé.
- [C-1-5] doit appliquer que les applications à l'aide de la radio UWB contiennent l'autorisation
UWB_RANGING(sous le groupe d'autorisationNEARBY_DEVICES).
Passer les tests de conformité et de certification pertinents définis par les organisations standard, y compris FIRA , CCC et CSA, aide à garantir correctement les fonctions 802.1.15.4.
- [C-1-2] Doit signaler l'indicateur de fonctionnalité matérielle
Voir révision
La «téléphonie» utilisée par les API Android et ce document se réfère spécifiquement au matériel lié à la mise en place d'appels vocaux et à l'envoi de messages SMS , ou à l'établissement de données mobiles via un réseau GSM ou CDMA GSM (par exemple GSM, CDMA, LTE, NR) ou CDMA. Un appareil prenant en charge la «téléphonie» peut choisir d'offrir une partie ou la totalité des services d'appel, de messagerie et de données comme correspond au produit.
via un réseau GSM ou CDMA. Bien que ces appels vocaux puissent ou non être à commutation de paquets, ils sont aux fins d'Android considérés comme indépendants de toute connectivité de données qui peut être implémentée à l'aide du même réseau. En d'autres termes, la fonctionnalité et les API de la téléphonie Android se réfèrent spécifiquement aux appels vocaux et aux SMS. Par exemple, les implémentations de périphériques qui ne peuvent pas placer les appels ou envoyer / recevoir des SMS ne sont pas considérées comme un périphérique de téléphonie, qu'elles utilisent un réseau cellulaire pour la connectivité des données.Voir révision
Si les implémentations de périphériques incluent la prise en charge du 802.11 et exposent la fonctionnalité à une application tierce, elles:
- [C-1-4] doit prendre en charge la multidiffusion DNS (MDNS) et ne doit pas filtrer les paquets MDNS (224.0.0.251 ou ff02 :: fb ) à tout moment de fonctionnement, y compris lorsque l'écran n'est pas dans un état actif, sauf si baisser ou tomber ou tomber Le filtrage de ces paquets est nécessaire pour rester dans les plages de consommation d'énergie requises par les exigences réglementaires applicables au marché cible.
Pour les implémentations de périphériques de télévision Android, même en cas d'alimentation de secours.
- [C-1-4] doit prendre en charge la multidiffusion DNS (MDNS) et ne doit pas filtrer les paquets MDNS (224.0.0.251 ou ff02 :: fb ) à tout moment de fonctionnement, y compris lorsque l'écran n'est pas dans un état actif, sauf si baisser ou tomber ou tomber Le filtrage de ces paquets est nécessaire pour rester dans les plages de consommation d'énergie requises par les exigences réglementaires applicables au marché cible.
Voir révision
Si les implémentations de périphériques déclarent fonctionnalités_bluetooth_le, elles:
- [C-SR-2] sont fortement recommandés pour mesurer et compenser le décalage Rx pour s'assurer que le RSSI médian est -60 dBm +/- 10 dB à 1 m de distance d'un dispositif de référence transmis à
ADVERTISE_TX_POWER_HIGH, où les périphériques sont orientés de telle sorte qu'ils sont sur des «plans parallèles» avec des écrans face à la même direction. - [C-SR-3] sont fortement recommandés pour mesurer et compenser le décalage TX pour s'assurer que le RSSI médian est -60 dBm +/- 10 dB lors de la numérisation à partir d'un dispositif de référence positionné à 1 m de distance et en transmettant à
ADVERTISE_TX_POWER_HIGH, où les appareils sont orientés de sorte qu'ils sont sur des «plans parallèles» avec des écrans face à la même direction.
- [C-10-3] Doit mesurer et compenser le décalage RX pour garantir que le RSSI médian est -55 dbm +/- 10 dB à 1 m de distance d'un dispositif de référence transmettant sur
ADVERTISE_TX_POWER_HIGH. - [C-10-4] Doit mesurer et compenser le décalage TX pour garantir que le RSSI médian est -55 dbm +/- 10 dB lors de la numérisation à partir d'un périphérique de référence positionné à 1 m de distance et en transmettant sur
ADVERTISE_TX_POWER_HIGH.
Si les implémentations de périphériques prennent en charge Bluetooth version 5.0, alors elles:
- [C-SR-4] sont fortement recommandés pour fournir un soutien à:
- Le 2M Phy
- Le codec phy
- Extension publicitaire LE
- Publicité périodique
- Au moins 10 ensembles de publicité
- Au moins 8 connexions simultanées LE. Chaque connexion peut être dans l'une ou l'autre des rôles de topologie de connexion.
- La confidentialité de la couche Link Le Link
- Une taille de "liste de résolution" d'au moins 8 entrées
- [C-SR-2] sont fortement recommandés pour mesurer et compenser le décalage Rx pour s'assurer que le RSSI médian est -60 dBm +/- 10 dB à 1 m de distance d'un dispositif de référence transmis à
Voir révision
- [C-1-7] doit s'assurer que la médiane des mesures de distance à 1 m du dispositif de référence est à l'intérieur de [0,75 m, 1,25 m], où la distance de vérité au sol est mesurée à partir du bord supérieur du DUT.
tenu face vers le haut et incliné 45 degrés.
- [C-1-7] doit s'assurer que la médiane des mesures de distance à 1 m du dispositif de référence est à l'intérieur de [0,75 m, 1,25 m], où la distance de vérité au sol est mesurée à partir du bord supérieur du DUT.
7.5.1. Caméra orientée vers l'arrière :
Voir révision
Une caméra orientée vers l'arrière est une caméra située sur le côté de l'appareil en face de l'écran; Autrement dit, il images des scènes de l'autre côté de l'appareil, comme une caméra traditionnelle.
Une caméra orientée vers l'arrière est une caméra orientée mondiale qui images des scènes de l'autre côté de l'appareil, comme une caméra traditionnelle; Sur les appareils portables, c'est une caméra située sur le côté de l'appareil en face de l'écran.
7.5.2. Avant face à la caméra :
Voir révision
Une caméra frontale est une caméra située du même côté de l'appareil que l'écran; Autrement dit, une caméra généralement utilisée pour image l'utilisateur, comme pour la conférence vidéo et les applications similaires.
A front-facing camera is a user-facing camera that is typically used to image the user, such as for video conferencing and similar applications; on handheld devices, that is a camera located on the same side of the device as the display.
See revision
An external camera is a camera that can be physically attached or detached from the device implementation at any time and can face any direction; such as USB cameras.
See revision
Device implementations MUST implement the following behaviors for the camera-related APIs, for all available cameras. Device implementations:
- [C-SR-1] For devices with multiple RGB cameras in close proximity and facing in the same direction, it is STRONGLY RECOMMENDED to support a logical camera device that lists capability
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, consisting of all of the RGB cameras facing that direction as physical sub-devices.
- [C-SR-1] For devices with multiple RGB cameras in close proximity and facing in the same direction, it is STRONGLY RECOMMENDED to support a logical camera device that lists capability
See revision
Devices that fulfill all of the following criteria are exempt from the requirement above:
- Device implementations that are not capable of being rotated by the user such as automotive devices.
See revision
Devices intended to be hand-held or worn may include a general purpose haptic actuator, available to applications for purposes including getting attention through ringtones, alarms, notifications, as well as general touch feedback.
If device implementations DO NOT include such a general purpose haptic actuator, they:
- [7.10/C] MUST return false for
Vibrator.hasVibrator().
If device implementations DO include at least one such general purpose haptic actuator, they:
- [C-1-1] MUST return true for
Vibrator.hasVibrator(). - SHOULD NOT use an eccentric rotating mass (ERM) haptic actuator (vibrator).
- SHOULD implement all public constants for clear haptics in
android.view.HapticFeedbackConstantsnamely (CLOCK_TICK,CONTEXT_CLICK,KEYBOARD_PRESS,KEYBOARD_RELEASE,KEYBOARD_TAP,LONG_PRESS,TEXT_HANDLE_MOVE,VIRTUAL_KEY,VIRTUAL_KEY_RELEASE,CONFIRM,REJECT,GESTURE_STARTandGESTURE_END). - SHOULD implement all public constants for clear haptics in
android.os.VibrationEffectnamely (EFFECT_TICK,EFFECT_CLICK,EFFECT_HEAVY_CLICKandEFFECT_DOUBLE_CLICK) and all feasible publicPRIMITIVE_*constants for rich haptics inandroid.os.VibrationEffect.Compositionnamely (CLICK,TICK,LOW_TICK,QUICK_FALL,QUICK_RISE,SLOW_RISE,SPIN,THUD). Some of these primitives, such asLOW_TICKandSPINmay only be feasible if the vibrator can support relatively low frequencies. - SHOULD follow the guidance for mapping public constants in
android.view.HapticFeedbackConstantsto the recommendedandroid.os.VibrationEffectconstants, with the corresponding amplitude relationships. - SHOULD use these linked haptic constants mappings .
- SHOULD follow quality assessment for
createOneShot()andcreateWaveform()APIs. - SHOULD verify that the result of the public
android.os.Vibrator.hasAmplitudeControl()API correctly reflects their vibrator's capabilities. - SHOULD verify the capabilities for amplitude scalability by running
android.os.Vibrator.hasAmplitudeControl().
If device implementations follow the haptic constants mapping, they:
- SHOULD verify the implementation status by running
android.os.Vibrator.areAllEffectsSupported()andandroid.os.Vibrator.arePrimitivesSupported()APIs. - SHOULD perform a quality assessment for haptic constants.
- SHOULD verify and update if needed the fallback configuration for unsupported primitives as described in the implementation guidance for constants.
- SHOULD provide fallback support to mitigate the risk of failure as described here .
See Section 2.2.1 for device-specific requirements.
- [7.10/C] MUST return false for
9. Security Model Compatibility
See revision
Device implementations:
- [C-0-4] MUST have one and only one implementation of both user interfaces.
If device implementations pre-install any packages that hold any of the System UI Intelligence , System Ambient Audio Intelligence , System Audio Intelligence , System Notification Intelligence , System Text Intelligence , or System Visual Intelligence roles, the packages:
- [C-4-1] MUST fulfill all requirements outlined for device implementations in sections
"9.8.6 Content Capture""9.8.6 OS-level and ambient data and 9.8.15 Sandboxed API implementations".
- [C-4-2] MUST NOT have android.permission.INTERNET permission. This is stricter than the STRONGLY RECOMMENDED listed in section 9.8.6.
- [C-4-3] MUST NOT bind to other apps, except for the following system apps: Bluetooth, Contacts, Media, Telephony, SystemUI, and components providing Internet APIs. This is stricter than the STRONGLY RECOMMENDED listed in section 9.8.6.
If device implementations include a default application to support the
VoiceInteractionServicethey:- [C-5-1] MUST NOT grant
ACCESS_FINE_LOCATIONas the default for that application.
See revision
If device implementations create the additional user profile discussed above, then they:
- [C-4-5] MUST visually distinguish the dual instance application icons when the icons are presented to users.
- [C-4-6] MUST provide a user-affordance to delete entire clone profile data.
- [C-4-7] MUST uninstall all Clone apps, delete the private app data directories and their content, and delete Clone profile data, when the user chooses to delete entire Clone profile data.
- SHOULD prompt the user to delete entire Clone Profile data when the last clone app is deleted.
- [C-4-8] MUST inform the user that app data will be deleted when the clone application is uninstalled, or provide an option to users to keep app data when the application is uninstalled from the device.
- [C-4-9] MUST delete the private app data directories and their content, when the user chooses to delete the data during uninstall.
[C-4-1] MUST allow the below intents originating from the additional profile to be handled by applications of the primary user on the device:
-
Intent.ACTION_VIEW -
Intent.ACTION_SENDTO -
Intent.ACTION_SEND -
Intent.ACTION_EDIT -
Intent.ACTION_INSERT -
Intent.ACTION_INSERT_OR_EDIT -
Intent.ACTION_SEND_MULTIPLE -
Intent.ACTION_PICK -
Intent.ACTION_GET_CONTENT -
MediaStore.ACTION_IMAGE_CAPTURE -
MediaStore.ACTION_VIDEO_CAPTURE
-
[C-4-2] MUST inherit all device policy user restrictions and selected non-user restrictions(list below) applied on the primary user of the device to this additional user profile.
[C-4-3] MUST only allow writing contacts from this additional profile via the following intents:
[C-4-4] MUST NOT have contact syncs running for applications running in this additional user profile.
- [C-4-14] MUST have separate permission and storage management for the applications running in this additional profile
- [C-4-5] MUST only allow applications in the additional profile that have a launcher activity to access contacts that are already accessible to the parent user profile.
See revision
A Memory Safety technology is a technology that mitigates at least the following classes of bugs with a high (> 90%) probability in applications that use the
android:memtagModemanifest option:- heap buffer overflow
- use after free
- double free
- wild free (free of a non-malloc pointer)
Device implementations:
- [C-SR-15] Are STRONGLY RECOMMENDED to set
ro.arm64.memtag.bootctl_supported.
If device implementations set the system property
ro.arm64.memtag.bootctl_supportedto true, they:[C-3-1] MUST allow the system property
arm64.memtag.bootctlto accept a comma-separated list of the following values, with the desired effect applied on the next subsequent reboot:-
memtag: a Memory Safety technology as defined above is enabled -
memtag-once: a Memory Safety technology as defined above is transiently enabled, and is automatically disabled upon, next reboot -
memtag-off: a Memory Safety technology as defined above is disabled
-
[C-3-2] MUST allow the shell user to set
arm64.memtag.bootctl.[C-3-3] MUST allow any process to read
arm64.memtag.bootctl.[C-3-4] MUST set
arm64.memtag.bootctlto the currently requested state upon boot, it MUST also update the property, if the device implementation allows to modify the state without changing the system property.[C-SR-16] Are STRONGLY RECOMMENDED to show a Developer Setting that sets memtag-once and reboots the device. With a compatible bootloader, the Android Open Source Project meets the above requirements through the MTE bootloader protocol .
- [C-SR-17] Are STRONGLY RECOMMENDED to show a Setting in the Security Settings menu that allows the user to enable
memtag.
See revision
Device implementations:
- [C-0-2] MUST display a user warning and obtain explicit user consent allowing any sensitive information that is displayed on the user's screen to be captured
enabled that includes exactly the same message as AOSPwhenevereach and every time a session to capture the screencasting or screen recordingisenabledstarted via theMediaProjection.createVirtualDisplay(),VirtualDeviceManager.createVirtualDisplay(), or proprietary APIs.MUST NOT provide users an affordance to disable future display of the user consent.
[C-SR-1] Are STRONGLY RECOMMENDED to display a user warning which is exactly the same message as implemented in AOSP but CAN be altered as long as the message clearly warns the user that any sensitive information on the user's screen is captured.
[C-0-4] MUST NOT provide users an affordance to disable future prompts of the user consent to capture the screen, unless the session is started by a system app that the user has allowed to
associate()with theandroid.app.role.COMPANION_DEVICE_APP_STREAMINGor theandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMINGdevice profile.
- [C-0-2] MUST display a user warning and obtain explicit user consent allowing any sensitive information that is displayed on the user's screen to be captured
9.8.6. OS-level and ambient data : This section was renamed from Content Capture and App Search to OS-level and ambient data .
See revision
Android, through the System APIs
ContentCaptureService,AugmentedAutofillService,AppSearchGlobalManager.query, or by other proprietary meansapplication data interactions between the applications and the usersensitive data :- Any screen or other data sent via the
AugmentedAutofillServiceto the system. - Any screen or other data accessible via
Content CaptureAPI. - Any screen or other data accessible via
FieldClassificationServiceAPI - Any application data passed to the system via the
AppSearchManagerAPI and accessible viaAppSearchGlobalManager.query.
- Any other events that an application provides to the system via the
Content CaptureAPI or orAppSearchManagerAPI a similarly capable Android and proprietary API.
- Audio data obtained as a result of using
SpeechRecognizer#onDeviceSpeechRecognizer()by the Speech Recognizer Implementation. - Audio data obtained in background (continuously) through
AudioRecord,SoundTriggeror other Audio APIs, and not resulting in a user-visible indicator - Camera data obtained in background (continuously) through CameraManager or other Camera APIs, and not resulting in a user-visible indicator
If device implementations capture any of the data above, they:
[C-1-3] MUST only send all such data
and the logoff the device using a privacy-preserving mechanism , except with explicit user consent every time the data is shared . The privacy-preserving mechanism is defined as “those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users”, to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such asRAPPOR).[C-1-5] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.6
Content CaptureOS-level and ambient data ), except with explicit user consent every time it is partagé. Unless such functionality is built as an Android SDK API (AmbientContext,HotwordDetectionService).[C-1-6] MUST provide user affordance to erase such data that the
ContentCaptureServiceifwhen the data is stored in any form on the device. If the user chooses to erase the data, MUST remove all collected historical data.
- [C-SR-3] Are STRONGLY RECOMMENDED to be implemented with Android SDK API or a similar OEM-owned open-source repository; and / or be performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementations).
Android, through
SpeechRecognizer#onDeviceSpeechRecognizer()provides ability to perform speech recognition on the device, without involving the network. Any implementation of on-device SpeechRecognizer MUST follow the policies outlined in this section.- Any screen or other data sent via the
9.8.10. Connectivity Bug Report :
See revision
If device implementations declare the
android.hardware.telephonyfeature flag, they:- [C-1-4] Reports generated using
BUGREPORT_MODE_TELEPHONYMUST contain at least the following information:-
SubscriptionManagerServicedump
-
- [C-1-4] Reports generated using
9.8.14. Credential Manager : Removed
9.8.15. Sandboxed API Implementations : New section
See revision
Android, through a set of delegate APIs provides a mechanism to process secure OS-level and ambient data. Such processing can be delegated to a preinstalled apk with privileged access and reduced communication capabilities, known as a Sandboxed API Implementation.
Any Sandboxed API implementation:
- [C-0-1] MUST NOT request the INTERNET permission.
- [C-0-2] MUST only access the internet through structured APIs backed by publicly available open-source implementations using privacy-preserving mechanisms, or indirectly via Android SDK APIs. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST keep the services separate from other system components (eg not binding the service or sharing process IDs) except for the following:
- Telephony, Contacts, System UI, and Media
- [C-0-4] MUST NOT allow users to replace the services with a user-installable application or service
- [C-0-5] MUST only allow the preinstalled services to capture such data. Unless the replacement capability is built into AOSP (eg for Digital Assistant Apps).
- [C-0-6] MUST NOT allow any apps other than the preinstalled services mechanism to be able to capture such data. Unless such capture capability is implemented with an Android SDK API.
- [C-0-7] MUST provide user affordance to disable the services.
- [C-0-8] MUST NOT omit user affordance to manage Android permissions that are held by the services and follow the Android permissions model as described in Section 9.1. Autorisation .
9.8.16. Continuous Audio and Camera data : New section
See revision
In addition to requirements outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, and 9.8.15 Sandboxed API implementations, implementations that make use of Audio data obtained in background (continuously) through AudioRecord, SoundTrigger or other Audio APIs OR Camera data obtained in background (continuously) through CameraManager or other Camera APIs:
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
- This access is performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementation), through a package holding one or more of the following roles: System UI Intelligence , System Ambient Audio Intelligence , System Audio Intelligence , System Notification Intelligence , System Text Intelligence , or System Visual Intelligence .
- The access is performed through a sandbox, implemented and enforced via mechanisms in AOSP (
HotwordDetectionService,WearableSensingService,VisualQueryDetector). - Audio access is performed for assistive purposes by the Digital Assistant application, supplying
SOURCE_HOTWORDas an audio source. - The access is performed by the system and implemented with open-source code.
- [C-SR-1] Is STRONGLY RECOMMENDED to require user consent for every functionality utilizing such data, and be disabled by default.
- [C-SR-2] STRONGLY RECOMMENDED to apply the same treatment (ie follow the restrictions outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, 9.8.15 Sandboxed API implementations, and 9.8.16 Continuous Audio and Camera data) to Camera data coming from a remote wearable device.
If the Camera data is supplied from a remote wearable device and accessed in an unencrypted form outside Android OS, sandboxed implementation or a sandboxed functionality built by
WearableSensingManager, then they:- [C-1-1] MUST indicate to the remote wearable device to display an additional indicator there.
If devices provide capability to engage with a Digital Assistant Application without the assigned keyword (either handling generic user queries, or analyzing user presence through camera):
- [C-2-1] MUST ensure such implementation is provided by a package holding the
android.app.role.ASSISTANTrole. - [C-2-2] MUST ensure such implementation utilizes
HotwordDetectionServiceand/orVisualQueryDetectionServiceAndroid APIs.
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
9.8.17. Telemetry : New section
See revision
Android stores system and app logs using StatsLog APIs. These logs are managed via StatsManager APIs which can be used by privileged system applications.
StatsManager also provides a way to collect data categorized as privacy sensitive from devices with a privacy preserving mechanism. In particular,
StatsManager::queryAPI provides the ability to query restricted metric categories defined in StatsLog .Any implementation querying and collecting restricted metrics from StatsManager:
- [C-0-1] MUST be the sole application/implementation on the device and hold the
READ_RESTRICTED_STATSpermission. - [C-0-2] MUST only send telemetry data and the log of the device using a privacy-preserving mechanism. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST NOT associate such data with any user identity (such as Account ) on the device.
- [C-0-4] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.17 Privacy-preserving Telemetry).
- [C-0-5] MUST provide a user affordance to enable/disable privacy-preserving telemetry collection, use, and sharing.
- [C-0-6] MUST provide user affordance to erase such data that the implementation collects if the data is stored in any form on the device. If the user chose to erase the data, MUST remove all data currently stored on the device.
- [C-0-7] MUST disclose underlying privacy-preserving protocol implementation in an open source repository.
- [C-0-8 ]MUST enforce data egress policies in this section to gate collection of data in restricted metric categories defined in StatsLog .
- [C-0-1] MUST be the sole application/implementation on the device and hold the
See revision
Device implementationsIf device implementations have the ability to verify file content on the per-page basis, then they :
[
C-0-3C-2-1 ] support cryptographically verifying file contentagainst a trusted keywithout reading the whole file.[
C-0-4C-2-2 ] MUST NOT allow the read requests on a protected file to succeed when the read contentdo not verify against a trusted keyis not verified per [C-2-1] above .
- [C-2-4] MUST return file checksum in O(1) for enabled files.
See revision
The Android Keystore System allows app developers to store cryptographic keys in a container and use them in cryptographic operations through the KeyChain API or the Keystore API . Device implementations:
- [C-0-3] MUST limit the number of failed primary authentication attempts.
- [C-SR-2] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations add or modify the authentication methods to unlock the lock screen if based on a known secret and use a new authentication method to be treated as a secure way to lock the screen, then:
- [C-SR-3] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-2-1] A PIN of a length less than 6 digits MUST NOT allow automatic entry without user interaction to avoid revealing the PIN length.
9.11.1. Secure Lock Screen, Authentication and Virtual Devices :
See revision
Device implementations:
- [C-0-1] MUST limit the number of failed primary authentication attempts.
- [C-SR-5] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations set a numerical PIN as the recommended primary authentication method, then:
- [C-SR-6] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-SR-7] A PIN of a length less than 6 digits is STRONGLY RECOMMENDED NOT to allow automatic entry without user interaction to avoid revealing the PIN length.
If device implementations have a secure lock screen and include one or more trust agent, which implements the
TrustAgentServiceSystem API, they:[C-7-8] The user MUST be challenged for one of the recommended primary authentication (eg: PIN, pattern, password) methods at least once every 72 hours or less unless the safety of the user (eg driver distraction) is of préoccupation.If device implementations allow applications to create secondary virtual displays and support associated input events such as via VirtualDeviceManager and the displays are not marked with VIRTUAL_DISPLAY_FLAG_SECURE, they:
[C-13-10] MUST disable installation of apps initiated from virtual devices.9.17. Android Virtualization Framework :
See revision
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*), the Android host:- [C-1-1] MUST support all the APIs defined by the
android.system.virtualmachinepackage. - [C-1-2] MUST NOT modify the Android SELinux and permission model for the management of Protected Virtual Machines (pVM) .
- [C-1-3] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow rules present.
- [C-1-4] MUST only allow platform signed code & privileged apps
MUST NOT allow untrusted code (eg 3p apps)to create and run aProtected Virtual MachinepVM . Note: This might change in future Android releases.
- [C-1-5] MUST NOT allow a
Protected Virtual MachinepVM to execute code that is not part of the factory image or their updates.Anything that is not covered by Android Verified Boot (eg files downloaded from the Internet or sideloaded) MUST NOT be allowed to be run in a Protected Virtual Machine.
- [C-1-5] MUST only allow a non-debuggable pVM to execute code from the factory image or their platform updates which also includes any updates to privileged apps.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*), then anyProtected Virtual MachinepVM instance:- [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a
Protected Virtual MachinepVM . - [C-2-2] MUST NOT allow a
Protected Virtual MachinepVM to run an operating system that is not signed by the device implementor or OS vendor. - [C-2-3] MUST NOT allow a
Protected Virtual MachinepVM to execute data as code (eg SELinux neverallow execmem).
- [C-2-4] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy/microdroid provided in the upstream Android Open Source Project (AOSP).
- [C-2-5] MUST implement
Protected Virtual MachinepVM defense-in-depth mechanisms (eg SELinux for pVMs) even for non-Microdroid operating systems. - [C-2-6] MUST ensure that the pVM fails
firmware refusesto boot ifit cannot verify the initialimages that the VM will run cannot be verified. La vérification doit être effectuée à l'intérieur de la machine virtuelle. - [C-2-7] MUST ensure that the pVM fails
firmware refusesto boot if the integrity of the instance.img is compromised.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*), then the hypervisor:- [C-3-1] MUST ensure that memory pages exclusively owned by a VM (either pVM or host VM) are accessible only to the virtual machine itself or the hypervisor, not by other virtual machines - either protected or non-protected.
MUST NOT allow any pVM to have access to a page belonging to another entity (ie other pVM or hypervisor), unless explicitly shared by the page owner. This includes the host VM. This applies to both CPU and DMA accesses. - [C-3-2] MUST wipe a page after it is used by a pVM and before it is returned to the host (eg the pVM is destroyed).
- [C-
3-3SR-1 ] Is STRONGLY RECOMMENDED to ensureMUST ensurethat that the pVM firmware is loaded and executed prior to any code in a pVM. - [C-3-4] MUST ensure that each VM derives a per-VM secret which
{Boot Certificate Chain (BCC) and Compound Device Identifier (CDIs) provided to a pVM instancecan only be derived by that particular VM instance and changes upon factory reset and OTA.
If the device implements support for the Android Virtualization Framework APIs, then across all areas:
- [C-4-1] MUST NOT provide functionality to a pVM that allows bypassing the Android Security Model.
If the device implements support for the Android Virtualization Framework APIs, then:
- [C-5-1] MUST be capable to support Isolated Compilation but may disable Isolated Compilation feature on the device shipment
of an ART runtime update.
If the device implements support for the Android Virtualization Framework APIs, then for Key Management:
- [C-6-1] MUST root DICE chain at a point that the user cannot modify, even on unlocked devices. (To ensure it cannot be spoofed).
- [C- SR-2
6-2] Is STRONGLY RECOMMENDED to use DICE as the per-VM secret derivation mechanism.MUST do DICE properly ie provide the correct values.
- [C-1-1] MUST support all the APIs defined by the