Cette page présente les nouvelles API d'entreprise, les nouvelles fonctionnalités et les modifications de comportement introduites dans Android 10.
Profils professionnels pour les appareils appartenant à l'entreprise
Android 10 introduit de nouvelles fonctionnalités de provisionnement et d'attestation pour les appareils détenus par l'entreprise qui ne nécessitent qu'un profil professionnel.
Amélioration des outils de configuration des profils professionnels
Vous pouvez provisionner des profils professionnels sur les appareils Android 10 et versions ultérieures enregistrés à l'aide d'un code QR ou du déploiement sans intervention. Lors du provisionnement d'un appareil détenu par l'entreprise, un nouvel extra d'intent permet aux applications d'outil de contrôle des règles relatives aux appareils (DPC) de lancer la configuration d'un profil professionnel ou entièrement géré. Une fois un profil professionnel créé ou une gestion complète établie, les DPC doivent lancer des écrans de conformité aux règles pour appliquer les règles initiales.
Dans le fichier manifeste de votre DPC, déclarez un nouveau filtre d'intent pour GET_PROVISIONING_MODE dans une activité et ajoutez l'autorisation BIND_DEVICE_ADMIN pour empêcher les applications arbitraires de démarrer l'activité. Exemple :
<activity
android:name=".GetProvisioningModeActivity"
android:label="@string/app_name"
android:permission="android.permission.BIND_DEVICE_ADMIN">
<intent-filter>
<action
android:name="android.app.action.GET_PROVISIONING_MODE" />
<category android:name="android.intent.category.DEFAULT"/>
</intent-filter>
</activity>
Lors du provisionnement, le système lance l'activité associée au filtre d'intent. L'objectif de cette activité est de spécifier un mode de gestion (profil professionnel ou entièrement géré).
Il peut être utile de récupérer les extras de provisionnement avant de déterminer le mode de gestion approprié pour l'appareil. L'activité peut appeler getIntent() pour récupérer les éléments suivants :
Les DPC peuvent également créer un intent de résultat et y ajouter les extras suivants :
EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE: ajoutez au bundle existant ou créez-en un. Ce bundle est envoyé en tant qu'intent supplémentaire lorsque votre DPC lance ses écrans de conformité aux règles.EXTRA_PROVISIONING_ACCOUNT_TO_MIGRATE: ne spécifiez un compte à migrer que si vous ajoutez un compte professionnel lors du provisionnement du profil professionnel.EXTRA_PROVISIONING_SKIP_EDUCATION_SCREENS
Pour définir le mode de gestion sur l'appareil, appelez putExtra(DevicePolicyManager.EXTRA_PROVISIONING_MODE,desiredProvisioningMode), où desiredProvisioningMode est :
- Profil professionnel :
PROVISIONING_MODE_MANAGED_PROFILE - Entièrement géré :
PROVISIONING_MODE_FULLY_MANAGED_DEVICE
Terminez le provisionnement du profil professionnel ou entièrement géré en renvoyant les détails du provisionnement à la configuration via setResult(RESULT_OK,
Intent) et fermez tous les écrans actifs avec finish().
Une fois le provisionnement terminé, une nouvelle intention est disponible pour les DPC afin de lancer leurs écrans de conformité et d'appliquer les paramètres de règles initiaux. Sur les appareils dotés d'un profil professionnel, les écrans de conformité s'affichent dans le profil professionnel. Votre DPC doit s'assurer que les écrans de conformité sont affichés aux utilisateurs, même s'ils quittent le flux de configuration.
Dans le fichier manifeste de votre DPC, déclarez un nouveau filtre d'intent pour ADMIN_POLICY_COMPLIANCE dans une activité et ajoutez l'autorisation BIND_DEVICE_ADMIN pour empêcher les applications arbitraires de démarrer l'activité. Exemple :
<activity
android:name=".PolicyComplianceActivity"
android:label="@string/app_name"
android:permission="android.permission.BIND_DEVICE_ADMIN">
<intent-filter>
<action android:name="android.app.action.ADMIN_POLICY_COMPLIANCE" />
<category android:name="android.intent.category.DEFAULT"/>
</intent-filter>
</activity>
Votre DPC doit utiliser cette nouvelle intention au lieu d'écouter la diffusion ACTION_PROFILE_PROVISIONING_COMPLETE.
L'activité associée au filtre d'intent peut appeler getIntent() pour récupérer EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE.
Après avoir vérifié la conformité aux règles, ADMIN_POLICY_COMPLIANCE doit renvoyer setResult(RESULT_OK,
Intent) et fermer tous les écrans actifs avec finish().
Les appareils entièrement gérés renvoient les utilisateurs à l'écran d'accueil. Les appareils avec profil professionnel invitent les utilisateurs à ajouter leur compte personnel avant de les rediriger vers l'écran d'accueil.
Attestation de l'ID de l'appareil avec profil professionnel
Les DPC définis comme administrateurs d'un profil professionnel provisionné à l'aide de l'enregistrement sans contact peuvent obtenir des ID d'appareil attestés par le matériel sécurisé, tels qu'un code IMEI ou un numéro de série du fabricant. L'appareil doit inclure un matériel sécurisé (tel qu'un environnement d'exécution sécurisé (TEE) ou un composant sécurisé (SE)) et être compatible avec l'attestation de l'ID de l'appareil et l'enregistrement sans contact.
Le composant administrateur d'un profil professionnel peut appeler DevicePolicyManager.generateKeyPair() en transmettant une ou plusieurs des valeurs ID_TYPE_SERIAL, ID_TYPE_IMEI ou ID_TYPE_MEID pour l'argument idAttestationFlags.
Pour en savoir plus sur l'extraction et la validation des ID d'appareil, consultez Vérifier les paires de clés intégrées au matériel avec l'attestation des clés.
Améliorations apportées au profil professionnel
De nouvelles API sont disponibles pour la prise en charge de la visibilité de l'agenda entre les profils et du blocage à l'échelle de l'appareil des installations d'applications provenant de sources inconnues.
Profil professionnel, sources inconnues à l'échelle de l'appareil
Les applications téléchargées à partir de sources autres que Google Play (ou d'autres plates-formes de téléchargement d'applications fiables) sont appelées applications de sources inconnues. Dans Android 10, les administrateurs de profils professionnels peuvent empêcher tout utilisateur ou profil d'installer des applications provenant de sources inconnues n'importe où sur l'appareil en ajoutant la nouvelle restriction utilisateur DISALLOW_INSTALL_UNKNOWN_SOURCES_GLOBALLY.
Toutefois, après avoir ajouté cette restriction, une personne utilisant l'appareil peut toujours installer des applications à l'aide d'adb.
Pour éviter que les utilisateurs n'installent par erreur des applications provenant de sources inconnues, nous vous recommandons d'ajouter cette restriction utilisateur, car elle ne nécessite pas l'installation des services Google Play. Si vous souhaitez prendre en charge les anciennes versions d'Android, vous pouvez définir une valeur de configuration gérée pour Google Play.
Limiter les périphériques d'entrée autorisés aux profils professionnels
Lorsque les administrateurs de profils professionnels appellent DevicePolicyManager.setPermittedInputMethods(), les utilisateurs sont uniquement limités aux méthodes de saisie autorisées dans leur profil professionnel au lieu de l'ensemble de l'appareil. Ils ont ainsi un contrôle total sur les méthodes de saisie sur la partie personnelle de leur appareil.
Effacer les profils professionnels en mode silencieux
Ajout de l'indicateur WIPE_SILENTLY à DevicePolicyManager.wipeData().
Si l'indicateur est défini, les utilisateurs ne recevront pas de notification après l'effacement de leur profil professionnel à l'aide de wipeData().
Nouvelles fonctionnalités pour les appareils entièrement gérés
Android 10 propose de nouvelles fonctionnalités et API pour les appareils entièrement gérés, y compris les mises à jour système manuelles, l'extension du provisionnement par code QR et NFC pour inclure les identifiants d'un réseau Wi-Fi EAP, et la compatibilité avec DNS sur TLS.
Installation manuelle d'une mise à jour du système
Dans Android 10, les administrateurs d'appareils entièrement gérés peuvent installer les mises à jour du système à l'aide d'un fichier de mise à jour du système. Les mises à jour manuelles du système permettent aux administrateurs informatiques d'effectuer les opérations suivantes :
- Testez une mise à jour sur un petit nombre d'appareils avant de l'installer à grande échelle.
- Évitez les téléchargements en double sur les réseaux à bande passante limitée.
- Échelonnez les installations ou mettez à jour les appareils uniquement lorsqu'ils ne sont pas utilisés.
Tout d'abord, un administrateur informatique définit une règle de report des mises à jour système pour retarder l'installation automatique (si nécessaire). Ensuite, le DPC d'un appareil appelle installSystemUpdate() avec le chemin d'accès à un fichier de mise à jour du système du fabricant de l'appareil. Transmettez un objet InstallSystemUpdateCallback que le système peut utiliser pour signaler les erreurs qui se produisent avant le redémarrage de l'appareil. En cas de problème, le système appelle onInstallUpdateError() avec le code d'erreur.
Une fois l'appareil redémarré, votre DPC doit confirmer l'installation à l'aide d'une API de version, telle que Build.FINGERPRINT. Si la mise à jour échoue, signalez-le à un administrateur informatique.
Provisionnement Wi-Fi EAP
Dans Android 10, les codes QR et les données NFC utilisés pour la préparation de l'appareil peuvent contenir des informations de configuration et des identifiants EAP, y compris des certificats. Lorsqu'une personne scanne un code QR ou appuie sur un tag NFC, l'appareil s'authentifie automatiquement sur un réseau Wi-Fi local à l'aide du protocole EAP et lance le processus de provisionnement sans aucune saisie manuelle supplémentaire.
Pour authentifier le Wi-Fi à l'aide d'EAP, ajoutez un extra EXTRA_PROVISIONING_WIFI_SECURITY_TYPE avec la valeur "EAP". Pour spécifier l'authentification EAP, vous pouvez ajouter les extras de provisionnement suivants à votre intention :
EXTRA_PROVISIONING_WIFI_EAP_METHODEXTRA_PROVISIONING_WIFI_IDENTITYEXTRA_PROVISIONING_WIFI_ANONYMOUS_IDENTITYEXTRA_PROVISIONING_WIFI_DOMAINEXTRA_PROVISIONING_WIFI_PHASE2_AUTHEXTRA_PROVISIONING_WIFI_USER_CERTIFICATEEXTRA_PROVISIONING_WIFI_CA_CERTIFICATE
Compatibilité avec le DNS privé
Les organisations peuvent utiliser DNS sur TLS (appelé DNS privé sur les appareils Android) pour éviter les fuites de requêtes DNS, y compris celles des noms d'hôte internes. Les composants d'administration des appareils entièrement gérés peuvent contrôler les paramètres DNS privé de l'appareil. Pour définir le mode DNS privé, appelez :
setGlobalPrivateDnsModeOpportunistic()pour que l'appareil utilise un DNS privé lorsque le système peut détecter un serveur de noms compatible.setGlobalPrivateDnsModeSpecifiedHost()pour spécifier le nom d'hôte d'un serveur de noms compatible avec la RFC7858 dans l'argumentprivateDnsHost.
Lorsque votre DPC appelle l'une de ces méthodes, le système renvoie PRIVATE_DNS_SET_NO_ERROR si l'appel a abouti. Sinon, elle renvoie une erreur.
Pour récupérer le mode DNS privé et l'hôte définis sur un appareil, appelez getGlobalPrivateDnsMode() et getGlobalPrivateDnsHost().
Vous pouvez empêcher les utilisateurs de modifier les paramètres DNS privé en ajoutant la restriction utilisateur DISALLOW_CONFIG_PRIVATE_DNS.
Exemption du mode Blocage du VPN
Le mode de blocage du VPN permet à un DPC de bloquer tout trafic réseau qui n'utilise pas le VPN. Les administrateurs des appareils entièrement gérés et des profils professionnels peuvent exempter des applications du mode verrouillé. Les applications exemptées utilisent un VPN par défaut, mais se connectent automatiquement à d'autres réseaux si le VPN n'est pas disponible. Les applications exemptées qui se voient également refuser explicitement l'accès au VPN n'utiliseront que d'autres réseaux.
Pour exempter une application du mode verrouillé, appelez la nouvelle méthode DevicePolicyManager setAlwaysOnVpnPackage() qui accepte une liste de packages d'applications exemptées. Tous les packages d'application ajoutés par le DPC doivent être installés sur l'appareil lorsque la méthode est appelée. Si une application est désinstallée et réinstallée, elle doit être à nouveau exemptée. Pour obtenir les applications précédemment exemptées du mode Verrouillage, appelez getAlwaysOnVpnLockdownWhitelist().
Pour aider les administrateurs d'appareils entièrement gérés et de profils professionnels à obtenir l'état du mode verrouillé, Android 10 ajoute la méthode isAlwaysOnVpnLockdownEnabled().
Nouveaux niveaux d'accès à la délégation
Android 10 étend la liste des fonctions qu'un DPC peut déléguer à d'autres applications plus spécialisées. Android regroupe les méthodes d'API nécessaires à une tâche dans des scopes. Pour déléguer un champ d'application, appelez setDelegatedScopes() et transmettez un ou plusieurs des champs d'application suivants :
DELEGATION_NETWORK_LOGGINGpour déléguer la consignation de l'activité réseauDELEGATION_CERT_SELECTIONpour déléguer la sélection de certificats
Android 10 introduit la nouvelle classe DelegatedAdminReceiver pour les applications déléguées. Le système utilise ce récepteur de diffusion pour envoyer des rappels de type DPC aux applications déléguées. Les applications pour lesquelles la journalisation de l'activité réseau et la sélection de certificats ont été déléguées doivent implémenter cette classe. Pour ajouter ce composant à une application déléguée, procédez comme suit :
- Ajoutez une sous-classe de
DelegatedAdminReceiverà l'application déléguée. - Déclarez
<receiver>dans le fichier manifeste d'application, en ajoutant une action de filtre d'intent pour chaque rappel. Par exemple,ACTION_NETWORK_LOGS_AVAILABLEouACTION_CHOOSE_PRIVATE_KEY_ALIAS. - Protégez le récepteur de diffusion avec l'autorisation
BIND_DEVICE_ADMIN.
L'extrait suivant montre le fichier manifeste d'application d'une application déléguée unique qui gère à la fois la journalisation réseau et la sélection de certificats :
<receiver android:name=".app.DelegatedAdminReceiver"
android:permission="android.permission.BIND_DELEGATED_ADMIN">
<intent-filter>
<action android:name="android.app.admin.action.NETWORK_LOGS_AVAILABLE">
<action android:name="android.app.action.CHOOSE_PRIVATE_KEY_ALIAS">
</intent-filter>
</receiver>
Consignation de l'activité réseau
Pour aider les entreprises à détecter et à suivre les logiciels malveillants, les DPC peuvent enregistrer les connexions TCP et les résolutions DNS par le système. Dans Android 10, les administrateurs d'appareils entièrement gérés peuvent déléguer la journalisation du réseau à une application spécialisée.
Pour récupérer les journaux réseau une fois que le système a mis un lot à disposition, les applications déléguées doivent d'abord créer une sous-classe DelegatedAdminReceiver (décrite précédemment). Dans votre sous-classe, implémentez le rappel onNetworkLogsAvailable() en suivant les instructions de la section Récupérer les journaux.
Les applications déléguées peuvent appeler les méthodes DevicePolicyManager suivantes (en transmettant null pour l'argument admin) :
Pour éviter de perdre des journaux, les DPC ne doivent pas activer la journalisation du réseau s'ils prévoient de déléguer à une autre application. L'application déléguée doit activer et collecter les journaux réseau. Une fois qu'un DPC délègue la journalisation du réseau, il ne reçoit plus de rappels onNetworkLogsAvailable().
Pour savoir comment signaler la journalisation de l'activité réseau à partir d'une application déléguée, consultez le guide du développeur Journalisation de l'activité réseau.
Sélection du certificat
Dans Android 10, les administrateurs des appareils entièrement gérés, des profils professionnels et des utilisateurs secondaires peuvent déléguer la sélection des certificats à une application spécialisée.
Pour sélectionner un alias de certificat, les applications déléguées doivent d'abord créer une sous-classe de DelegatedAdminReceiver (décrit précédemment). Dans votre sous-classe, implémentez le rappel onChoosePrivateKeyAlias() et renvoyez un alias pour un certificat préféré ou, pour inviter l'utilisateur à sélectionner un certificat, renvoyez null.
Abandon des règles d'administration des appareils
Android 10 empêche les applications et les DPC d'appliquer les anciennes règles d'administrateur de l'appareil. Nous recommandons aux clients et aux partenaires de passer aux appareils entièrement gérés ou aux profils professionnels. Les règles suivantes génèrent un SecurityException lorsqu'elles sont appelées par un administrateur d'appareil ciblant Android 10 :
USES_POLICY_DISABLE_CAMERAUSES_POLICY_DISABLE_KEYGUARD_FEATURESUSES_POLICY_EXPIRE_PASSWORDUSES_POLICY_LIMIT_PASSWORD
Certaines applications utilisent l'administrateur de l'appareil pour l'administration des appareils grand public. Par exemple, verrouiller et effacer les données d'un appareil égaré. Pour ce faire, les règles suivantes restent disponibles :
Pour en savoir plus sur ces modifications, consultez Arrêt de l'administrateur de l'appareil.
Nouvelles fonctionnalités pour les applications
Les applications ciblant Android 10 peuvent interroger la complexité du verrouillage de l'écran définie sur un appareil avant d'afficher des données confidentielles ou de lancer des fonctionnalités critiques. Les applications qui appellent l'API KeyChain bénéficient d'améliorations du comportement, tandis que de nouvelles fonctionnalités sont également disponibles pour les applications VPN.
Contrôle qualité du verrouillage de l'écran
À partir d'Android 10, les applications dotées de fonctionnalités critiques nécessitant un verrouillage de l'écran peuvent interroger la complexité du verrouillage de l'écran d'un appareil ou d'un profil professionnel. Les applications nécessitant un verrouillage d'écran plus sécurisé peuvent rediriger l'utilisateur vers les paramètres de verrouillage d'écran du système, ce qui lui permet de mettre à jour ses paramètres de sécurité.
Pour vérifier la qualité du verrouillage de l'écran :
- Ajoutez la nouvelle autorisation
REQUEST_PASSWORD_COMPLEXITYau fichier manifeste de votre application. - Appelez
DevicePolicyManager.getPasswordComplexity(). La complexité est divisée en quatre catégories :
Pour lancer les paramètres de verrouillage de l'écran système, utilisez ACTION_SET_NEW_PASSWORD avec l'extra EXTRA_PASSWORD_COMPLEXITY. Les options qui ne répondent pas à la complexité spécifiée dans l'extra d'intent sont grisées. Les utilisateurs peuvent choisir parmi les options de verrouillage d'écran disponibles ou quitter l'écran.
Bonne pratique : Affichez un message dans votre application avant de lancer la page de verrouillage de l'écran du système. Lorsque votre application reprend, appelez à nouveau DevicePolicyManager.getPasswordComplexity(). Si un verrouillage de l'écran plus sécurisé est toujours requis, limitez l'accès au lieu d'inviter les utilisateurs à mettre à jour leurs paramètres de sécurité à plusieurs reprises.
Compatibilité avec le proxy HTTP dans les applications VPN
Dans Android 10, les applications VPN peuvent définir un proxy HTTP pour leur connexion VPN. Pour ajouter un proxy HTTP, une application VPN doit configurer une instance ProxyInfo avec un hôte et un port avant d'appeler VpnService.Builder.setHttpProxy().
Le système et de nombreuses bibliothèques réseau utilisent ce paramètre de proxy, mais le système n'oblige pas les applications à utiliser un proxy pour les requêtes HTTP.
Pour obtenir un exemple de code montrant comment définir un proxy HTTP, consultez l'application exemple ToyVPN.
Modes de service VPN
Les applications VPN peuvent déterminer si le service est en cours d'exécution en raison de l'option VPN permanent et si le mode Verrouillage est actif. De nouvelles méthodes ajoutées dans Android 10 peuvent vous aider à ajuster votre interface utilisateur. Par exemple, vous pouvez désactiver votre bouton de déconnexion lorsque le VPN permanent contrôle le cycle de vie de votre service.
Les applications VPN peuvent appeler les méthodes VpnService suivantes après s'être connectées au service et avoir établi l'interface locale :
isAlwaysOn()pour savoir si le système a démarré le service en raison du VPN permanentisLockdownEnabled()pour savoir si le système bloque les connexions qui n'utilisent pas le VPN.
L'état "Toujours activé" reste le même lorsque votre service est en cours d'exécution, mais l'état du mode Verrouillage peut changer.
Améliorations apportées au trousseau
Android 10 introduit plusieurs améliorations liées à l'API KeyChain.
Lorsqu'une application appelle KeyChain.choosePrivateKeyAlias(), les appareils équipés d'Android 10 ou version ultérieure filtrent la liste des certificats parmi lesquels un utilisateur peut choisir en fonction des émetteurs et des algorithmes de clé spécifiés dans l'appel.
Par exemple, lorsqu'un serveur TLS envoie un message Certificate Request (Demande de certificat) dans le cadre d'un handshake TLS et que le navigateur appelle KeyChain.choosePrivateKeyAlias(), l'invite de sélection de certificat n'inclut que les options correspondant au paramètre "issuers" (émetteurs). Si aucune option correspondante n'est disponible ou si aucun certificat n'est installé sur l'appareil, l'invite de sélection ne s'affiche pas.
De plus, KeyChain ne nécessite plus qu'un appareil soit doté d'un verrouillage de l'écran pour que des clés ou des certificats CA puissent être importés.