Avantages d'Android 9 pour les applications d'entreprise

Cette page présente les API d'entreprise, les fonctionnalités et les modifications de comportement disponibles dans Android 9.

Interface utilisateur du profil professionnel

Android 9 (niveau d'API 28) inclut des modifications de l'interface utilisateur dans le lanceur d'applications par défaut pour aider les utilisateurs à séparer les applications personnelles et professionnelles. Les fabricants d'appareils compatibles avec cette fonctionnalité peuvent présenter les applications des utilisateurs dans des onglets professionnel et personnel distincts. Nous avons également facilité l'activation et la désactivation du profil professionnel pour les utilisateurs d'appareils en ajoutant un bouton dans l'onglet "Travail" du lanceur d'applications.

Figure 1. Onglets personnel et onglet professionnel du lanceur d'applications par défaut avec bouton de profil professionnel

Lors du provisionnement des profils professionnels et des appareils gérés, Android 9 inclut des illustrations animées pour aider les utilisateurs d'appareils à comprendre ces fonctionnalités.

Passer d'un profil à l'autre

Android 9 inclut des API permettant de lancer une autre instance d'application dans un profil différent afin d'aider les utilisateurs à changer de compte. Par exemple, une application de messagerie peut fournir une UI permettant à l'utilisateur de basculer entre le profil personnel et le profil professionnel pour accéder à deux comptes de messagerie. Toutes les applications peuvent appeler ces API pour lancer l'activité principale de la même application si elle est déjà installée dans l'autre profil. Pour ajouter le changement de compte interprofils à votre application, suivez les étapes ci-dessous pour appeler les méthodes de la classe CrossProfileApps:

  1. Appelez getTargetUserProfiles() pour obtenir la liste des profils dans lesquels vous pouvez lancer une autre instance de l'application. Cette méthode vérifie que l'application est installée dans les profils.
  2. Appelez getProfileSwitchingIconDrawable() pour obtenir une icône que vous pouvez utiliser pour représenter un autre profil.
  3. Appelez getProfileSwitchingLabel() pour obtenir le texte localisé invitant l'utilisateur à changer de profil.
  4. Appelez startMainActivity() pour lancer une instance de votre application dans un autre profil.

Vérifiez que l'activité principale que vous souhaitez lancer est déclarée dans le fichier manifeste de votre application, avec une action d'intent ACTION_MAIN et inclut une catégorie d'intent CATEGORY_LAUNCHER.

Activer ou désactiver les profils professionnels par programmation

Le lanceur d'applications par défaut (ou les applications ayant l'autorisation MANAGE_USERS ou MODIFY_QUIET_MODE) peut activer ou désactiver le profil professionnel en appelant UserManager.requestQuietModeEnabled(). Vous pouvez inspecter la valeur renvoyée pour savoir si l'utilisateur doit confirmer ses identifiants avant que l'état ne change. Comme le changement peut ne pas se produire instantanément, écoutez la diffusion ACTION_MANAGED_PROFILE_AVAILABLE ou ACTION_MANAGED_PROFILE_UNAVAILABLE pour savoir quand mettre à jour l'interface utilisateur.

Votre application peut vérifier l'état du profil professionnel en appelant UserManager.isQuietModeEnabled().

Verrouiller n'importe quelle application sur un appareil

À partir d'Android 9, les propriétaires d'appareils et les propriétaires de profils (des utilisateurs secondaires) peuvent verrouiller n'importe quelle application sur l'écran d'un appareil en mettant l'application en mode tâches verrouillées. Auparavant, les développeurs d'applications devaient ajouter la prise en charge du mode tâches verrouillées dans leurs applications. Android 9 étend également les API de tâches de verrouillage aux propriétaires de profils d'utilisateurs secondaires non affiliés. Suivez les étapes ci-dessous pour verrouiller une application à l'écran:

  1. Appelez DevicePolicyManager.setLockTaskPackages() pour ajouter des applications à la liste d'autorisation pour le mode tâches verrouillées.
  2. Appelez ActivityOptions.setLockTaskEnabled() pour lancer une application figurant sur la liste d'autorisation en mode tâches verrouillées.

Pour arrêter une application en mode tâches verrouillées, supprimez-la de la liste d'autorisation de ce mode à l'aide de DevicePolicyManager.setLockTaskPackages().

Activer les fonctionnalités de l'UI du système

Lorsque le mode tâches verrouillées est activé, les propriétaires d'appareils et de profils peuvent activer certaines fonctionnalités d'UI du système sur l'appareil en appelant DevicePolicyManager.setLockTaskFeatures() et en transmettant un champ bit des flags de fonctionnalité suivants:

Vous pouvez appeler DevicePolicyManager.getLockTaskFeatures() pour obtenir la liste des fonctionnalités disponibles sur un appareil lorsque le mode tâches verrouillées est activé. Lorsqu'un appareil quitte le mode tâches verrouillées, il revient à l'état exigé par d'autres règles relatives aux appareils.

Supprimer les boîtes de dialogue d'erreur

Dans certains environnements, tels que les démonstrations en magasin ou l'affichage d'informations publiques, vous ne souhaitez peut-être pas afficher de boîtes de dialogue d'erreur aux utilisateurs. Un outil de contrôle des règles relatives aux appareils (DPC) peut supprimer les boîtes de dialogue d'erreur système pour les applications qui ont planté ou qui ne répondent pas en ajoutant la restriction utilisateur DISALLOW_SYSTEM_ERROR_DIALOGS. Cette restriction affecte toutes les boîtes de dialogue lorsqu'elle est appliquée par le propriétaire d'un appareil, mais seules les boîtes de dialogue d'erreur affichées pour l'utilisateur principal ou secondaire sont supprimées lorsque la restriction est appliquée par les propriétaires de profils. Cette restriction n'affecte pas les profils professionnels.

Sous Android 9, les applications exécutées en mode plein écran immersif n'affichent pas l'info-bulle de rappel en mode tâches verrouillées. L'info-bulle de rappel est un panneau présenté aux utilisateurs (au premier lancement) et expliquant comment quitter le mode immersif.

Assurer la compatibilité avec plusieurs utilisateurs sur des appareils dédiés

Android 9 introduit le concept d'utilisateur éphémère pour les appareils dédiés (anciennement appelés COSU). Les utilisateurs éphémères sont des utilisateurs à court terme destinés aux cas où plusieurs utilisateurs partagent un seul appareil dédié. Cela inclut les sessions publiques d'utilisateurs sur des appareils tels que les kiosques à la bibliothèque ou les kiosques d'accueil, ainsi que les sessions persistantes entre un ensemble fixe d'utilisateurs sur des appareils, comme les travailleurs postés.

Les utilisateurs éphémères doivent être créés en arrière-plan. Ils sont créés en tant qu'utilisateurs secondaires sur un appareil et sont supprimés (avec les applications et les données associées) lorsqu'ils sont arrêtés, remplacés ou redémarrés. Pour créer un utilisateur éphémère, les propriétaires d'appareils peuvent:

  1. Définissez l'option MAKE_USER_EPHEMERAL lorsque vous appelez DevicePolicyManager.createAndManageUser().
  2. Appelez DevicePolicyManager.startUserInBackground() pour démarrer l'utilisateur éphémère en arrière-plan.

Notez que les applications ciblant Android 9 doivent intercepter UserManager.UserOperationException lors de l'appel de createAndManageUser(). Appelez la méthode getUserOperationResult() de l'exception pour savoir pourquoi l'utilisateur n'a pas été créé.

Recevoir des notifications d'événements

Le DeviceAdminReceiver reçoit des notifications pour les événements suivants:

Afficher des messages d'événement pour les utilisateurs

Les propriétaires d'appareils peuvent configurer les messages à afficher aux utilisateurs lorsqu'ils démarrent et terminent leur session:

Se déconnecter et arrêter les utilisateurs

Les propriétaires d'appareils peuvent utiliser DevicePolicyManager.setLogoutEnabled() pour spécifier si la déconnexion est activée pour les utilisateurs secondaires. Pour vérifier si la déconnexion est activée, appelez DevicePolicyManager.isLogoutEnabled().

Les propriétaires de profils des utilisateurs secondaires peuvent appeler DevicePolicyManager.logoutUser() pour arrêter l'utilisateur secondaire et revenir à l'utilisateur principal.

Les propriétaires d'appareils peuvent utiliser DevicePolicyManager.stopUser() pour arrêter un utilisateur secondaire spécifié.

Mise en cache du package

Pour simplifier le provisionnement des utilisateurs sur les appareils partagés avec un ensemble fixe d'utilisateurs, tels que les appareils des travailleurs postés, il est possible de mettre en cache les packages nécessaires aux sessions multi-utilisateurs:

  1. Appelez DevicePolicyManager.setKeepUninstalledPackages() pour spécifier la liste des packages à conserver en tant qu'APK. Pour récupérer la liste de ces packages, appelez DevicePolicyManager.getKeepUninstalledPackages().

  2. Appelez DevicePolicyManager.installExistingPackage() pour installer un package qui a été conservé après sa suppression via setKeepUninstalledPackages().

Méthodes et constantes supplémentaires

Android 9 inclut également les méthodes et constantes suivantes pour mieux prendre en charge les sessions utilisateur sur les appareils partagés:

Effacer les données de package et supprimer les comptes

Les propriétaires d'appareils et de profils peuvent appeler clearApplicationUserData() pour effacer les données utilisateur d'un package donné. Pour supprimer un compte de AccountManager, les propriétaires d'appareils et de profils peuvent appeler removeAccount().

Restrictions utilisateur et contrôle accru sur les paramètres

Android 9 introduit un ensemble de restrictions utilisateur pour les DPC, et permet de configurer les APN, l'heure, le fuseau horaire et les paramètres système d'un appareil.

Configurer les APN

Les propriétaires d'appareils peuvent utiliser les méthodes suivantes dans la classe DevicePolicyManager pour configurer les APN sur un appareil:

Configurer l'heure et le fuseau horaire

Les propriétaires d'appareils peuvent utiliser les méthodes suivantes dans la classe DevicePolicyManager pour définir l'heure et le fuseau horaire d'un appareil:

Appliquer des restrictions aux utilisateurs pour des paramètres importants

Android 9 ajoute des restrictions d'utilisateurs pour désactiver des fonctionnalités et des paramètres système. Pour ajouter une restriction, appelez DevicePolicyManager.addUserRestriction() avec l'une des constantes UserManager suivantes:

Si DISALLOW_CONFIG_BRIGHTNESS et DISALLOW_CONFIG_SCREEN_TIMEOUT sont appliqués sur un appareil, les propriétaires peuvent toujours définir les paramètres de luminosité de l'écran, de luminosité de l'écran et de délai de mise en veille de l'écran à l'aide de l'API DevicePolicyManager.setSystemSetting().

Données mesurées

Les propriétaires d'appareils et de profils peuvent empêcher les applications d'utiliser les réseaux de données à l'usage d'un appareil. Un réseau est considéré comme facturé à l'usage lorsque l'utilisateur est sensible à une utilisation intensive des données en raison des coûts, des limites de données, ou des problèmes de batterie et de performances. Pour empêcher les applications d'utiliser des réseaux facturés à l'usage, appelez DevicePolicyManager.setMeteredDataDisabledPackages() en transmettant une liste de noms de packages. Pour récupérer les applications actuellement limitées, appelez DevicePolicyManager.getMeteredDataDisabledPackages().

Pour en savoir plus sur les données facturées à l'usage dans Android, consultez la page Optimiser l'utilisation des données réseau.

Migrer les DPC

Les outils de contrôle des règles relatives aux appareils (DPC) peuvent transférer la propriété d'un appareil ou d'un profil professionnel à un autre. Vous pouvez transférer la propriété pour déplacer certaines fonctionnalités vers l'API Android Management, pour migrer des appareils à partir de votre ancien DPC ou pour aider les administrateurs informatiques à migrer vers votre EMM. Étant donné que vous ne faites que modifier la propriété de l'outil DPC, vous ne pouvez pas utiliser cette fonctionnalité pour modifier le type de gestion (par exemple, migrer d'un appareil géré vers un profil professionnel ou inversement).

Vous pouvez utiliser la ressource XML des règles d'administration des appareils pour indiquer que cette version de votre DPC est compatible avec la migration. Un DPC cible indique qu'il peut être propriétaire en incluant un élément nommé <support-transfer-ownership>. L'exemple ci-dessous montre comment procéder dans le fichier XML d'administration de l'appareil de votre DPC:

<device-admin xmlns:android="http://schemas.android.com/apk/res/android">
    <support-transfer-ownership />
    <uses-policies>
        <limit-password />
        <watch-login />
        <reset-password />
    </uses-policies>
</device-admin>

Les DPC qui souhaitent migrer la propriété vers la nouvelle application DPC peuvent vérifier si la version d'un DPC cible est compatible avec la migration en appelant la méthode DeviceAdminInfo supportsTransferOwnership(). Avant de transférer la propriété, il est de la responsabilité du DPC source de vérifier le DPC cible en comparant les signatures d'application. La classe PackageManager inclut des méthodes permettant d'utiliser des signatures de signature de code.

Android gère le système et les règles utilisateur du DPC source via un transfert de propriété. Les DPC n'ont pas besoin de les migrer. Un DPC source peut transmettre des données personnalisées au DPC cible à l'aide de paires clé/valeur dans un élément PersistableBundle. Après un transfert réussi, le DPC cible peut récupérer ces données en appelant DevicePolicyManager.getTransferOwnershipBundle().

Les étapes à suivre pour transférer la propriété d'un appareil géré ou d'un profil professionnel sont les mêmes:

  1. Le DPC source vérifie que la version du DPC cible est compatible avec la migration et confirme que la signature de l'application du DPC cible correspond à une valeur attendue.
  2. Le DPC source appelle transferOwnership() pour démarrer le transfert.
  3. Le système définit le DPC cible comme administrateur actif et le définit comme propriétaire de l'appareil géré ou du profil professionnel.
  4. L'outil DPC cible reçoit le rappel onTransferOwnershipComplete() et peut se configurer lui-même à l'aide des valeurs de l'argument bundle.
  5. En cas de problème lors du transfert, le système revient à l'outil DPC source. Si votre DPC source doit confirmer que le transfert de propriété a réussi, appelez isAdminActive() pour vérifier que le DPC source n'est plus l'administrateur actif.

Toutes les applications exécutées dans le profil professionnel reçoivent la diffusion ACTION_PROFILE_OWNER_CHANGED lorsque le propriétaire du profil change. Les applications exécutées sur un appareil géré reçoivent l'annonce ACTION_DEVICE_OWNER_CHANGED lorsque le propriétaire de l'appareil change.

Profils professionnels sur des appareils entièrement gérés

Le transfert de deux instances d'un DPC exécuté en tant que propriétaire d'appareil et propriétaire de profil s'effectue en deux étapes. Lorsque le profil personnel et le profil professionnel sont affiliés, effectuez le transfert dans l'ordre suivant:

  1. Commencez par transférer la propriété du profil professionnel.
  2. Attendez que le rappel DeviceAdminReceiver onTransferAffiliatedProfileOwnershipComplete() confirme que le profil professionnel a été transféré vers l'outil DPC cible.
  3. Enfin, transférez la propriété de l'appareil géré au DPC cible.

Reporter les mises à jour Over The Air (OTA)

Les propriétaires d'appareils peuvent reporter les mises à jour système OTA des appareils jusqu'à 90 jours afin de figer la version de l'OS exécutée sur ces appareils lors de périodes critiques (par exemple, les jours fériés). Le système applique une mémoire tampon obligatoire de 60 jours après une période de blocage définie pour éviter de figer l'appareil indéfiniment.

Pendant une période de blocage:

  • Les appareils ne reçoivent aucune notification concernant les mises à jour OTA en attente.
  • Les appareils n'installent aucune mise à jour OTA de l'OS.
  • Les utilisateurs d'appareils ne peuvent pas rechercher manuellement les mises à jour OTA dans les paramètres.

Pour définir une période de blocage, appelez SystemUpdatePolicy.setFreezePeriods(). Étant donné que la période de gel se répète chaque année, les dates de début et de fin de la période sont représentées par des entiers, qui comptent le nombre de jours écoulés depuis le début de l'année. Le jour de début doit commencer au moins 60 jours après la fin de toute période de gel précédente. Les propriétaires d'appareils peuvent appeler SystemUpdatePolicy.getFreezePeriods() pour obtenir la liste des périodes de blocage précédemment définies sur l'objet de stratégie de mise à jour du système. DevicePolicyManager.getSystemUpdatePolicy() a été mis à jour pour renvoyer toutes les périodes de blocage définies par le propriétaire de l'appareil.

Restreindre le partage dans un profil professionnel

Les propriétaires de profils peuvent empêcher les utilisateurs de partager des données à caractère personnel avec un profil professionnel sur l'appareil en ajoutant la restriction utilisateur DISALLOW_SHARE_INTO_MANAGED_PROFILE. Cette restriction empêche la gestion et le partage des intents suivants:

  • Les applications de profil personnel qui partagent des données et des fichiers avec les applications du profil professionnel
  • Applications de profil professionnel sélectionnant des éléments du profil personnel, par exemple des images ou des fichiers

Une fois cette restriction définie, votre DPC peut toujours autoriser les intents d'activité interprofils en appelant addCrossProfileIntentFilter().

Clés matérielles sécurisées et certificats de machine

Android 9 ajoute des API pour vous aider à utiliser des clés et des certificats que vous pouvez combiner pour identifier les appareils de manière sécurisée. Un DPC exécuté en mode propriétaire de profil ou propriétaire d'appareil, ou un programme d'installation de certificats délégués, peut effectuer les tâches suivantes:

  • Générez des clés et des certificats dans le matériel sécurisé (tel qu'un environnement d'exécution sécurisé (TEE) ou un composant sécurisé (SE)) de l'appareil Android. Les clés générées ne quittent jamais le matériel sécurisé et peuvent être utilisées à partir de Android KeyChain. Appelez DevicePolicyManager.generateKeyPair() en fournissant l'algorithme (voir KeyPairGenerator) et tous les ID matériels que vous souhaitez faire certifier, tels que le numéro de série ou le code IMEI. Pour en savoir plus sur les modifications matérielles sécurisées, consultez la page Améliorations de la sécurité d'Android 9.
  • Associez un certificat à une clé générée par l'appareil. Appelez DevicePolicyManager.setKeyPairCertificate() en fournissant l'alias de la clé existante et la chaîne de certificats, en commençant par le certificat d'entité finale et en incluant la chaîne de confiance dans l'ordre.
  • Vérifiez que le matériel sécurisé protège la clé avant de l'utiliser. Pour vérifier quels mécanismes protègent la clé, suivez les étapes décrites dans Attestation de clé.
  • Les propriétaires d'appareils et les programmes d'installation de certificats délégués peuvent recevoir une instruction signée contenant les ID matériels des appareils avec les versions du système Android. Appelez DevicePolicyManager.generateKeyPair() en transmettant un ou plusieurs des éléments ID_TYPE_BASE_INFO, ID_TYPE_SERIAL, ID_TYPE_IMEI ou ID_TYPE_MEID dans l'argument idAttestationFlags. Le certificat renvoyé inclut les ID matériels dans l'enregistrement d'attestation. Si vous ne souhaitez pas inclure les ID matériels, transmettez 0. Les propriétaires de profils ne peuvent recevoir des informations sur le fabricant que (en transmettant ID_TYPE_BASE_INFO). Pour vérifier que l'appareil peut attester des ID, appelez isDeviceIdAttestationSupported().
  • Empêchez les utilisateurs d'appareils d'utiliser les clés d'entreprise de manière abusive (dans les tâches non liées à l'entreprise) en rendant les certificats de clé non sélectionnables. Le système n'inclut pas les certificats non sélectionnables dans le panneau du sélecteur. Dans votre méthode de rappel DeviceAdminReceiver.onChoosePrivateKeyAlias(), renvoyez l'alias à votre clé d'entreprise afin que le système sélectionne automatiquement le certificat pour le compte de l'utilisateur. Pour rendre une clé non sélectionnable, appelez les méthodes DevicePolicyManager suivantes :

En combinant ces API, les entreprises peuvent identifier les appareils de manière sécurisée et confirmer leur intégrité avant d'accorder l'accès:

  1. L'appareil Android génère une nouvelle clé privée dans le matériel sécurisé. Étant donné que la clé privée ne quitte jamais le matériel sécurisé, elle reste secrète.
  2. L'appareil utilise la clé pour créer et envoyer une requête de signature de certificat (CSR) au serveur. La requête de signature de certificat inclut l'enregistrement d'attestation contenant les ID d'appareil.
  3. Le serveur valide la chaîne de certificats (en mode root sur un certificat Google) et extrait les métadonnées de l'appareil de l'enregistrement d'attestation.
  4. Le serveur confirme que le matériel sécurisé protège la clé privée et que les ID d'appareil correspondent aux enregistrements de l'entreprise. Le serveur peut également vérifier que les versions du système Android et du correctif respectent les conditions requises.
  5. Le serveur génère un certificat à partir de la requête de signature de certificat et l'envoie à l'appareil.
  6. L'appareil associe le certificat à la clé privée (qui est restée dans le matériel sécurisé) permettant aux applications de se connecter aux services d'entreprise.

Autres API, fonctionnalités et modifications de sécurité

ID des journaux de sécurité et des journaux réseau

Android 9 inclut les ID dans les journaux de sécurité et d'activité réseau. L'ID numérique augmente de manière monotone pour chaque événement, ce qui permet aux administrateurs informatiques de détecter plus facilement les lacunes dans leurs journaux. Étant donné que les journaux de sécurité et les journaux réseau sont des collections distinctes, le système conserve des valeurs d'ID distinctes.

Appelez SecurityEvent.getId(), DnsEvent.getId() ou ConnectEvent.getId() pour obtenir la valeur de l'ID. Le système réinitialise l'ID chaque fois qu'un DPC active la journalisation ou lorsque l'appareil redémarre. Les journaux de sécurité récupérés en appelant DevicePolicyManager.retrievePreRebootSecurityLogs() n'incluent pas ces ID.

Journalisation de sécurité

La journalisation de sécurité attribue un niveau de journalisation à chaque SecurityEvent. Pour obtenir le niveau de journalisation, appelez getLogLevel(). Cette méthode renvoie une valeur de niveau de journalisation pouvant être LEVEL_INFO, LEVEL_WARNING ou LEVEL_ERROR.

Android 9 enregistre les événements répertoriés dans le tableau ci-dessous dans les journaux de sécurité. Pour vérifier la balise d'un événement, appelez getTag(). Pour récupérer les données d'événement, appelez getData().

Taguer Description de l'événement
TAG_CERT_AUTHORITY_INSTALLED Tentative d'installation d'un nouveau certificat racine dans le stockage d'identifiants du système.
TAG_CERT_AUTHORITY_REMOVED Tentative de suppression d'un certificat racine du stockage des identifiants dans le système.
TAG_CERT_VALIDATION_FAILURE Un contrôle de validation du certificat Wi-Fi a échoué lors de la connexion.
TAG_CRYPTO_SELF_TEST_COMPLETED Le système a effectué l'autotest cryptographique.
TAG_KEYGUARD_DISABLED_FEATURES_SET Une application d'administration a désactivé des fonctionnalités de l'écran de verrouillage d'un appareil ou d'un profil professionnel.
TAG_KEY_DESTRUCTION Tentative de suppression d'une clé cryptographique.
TAG_KEY_GENERATED Tentative de génération d'une nouvelle clé cryptographique.
TAG_KEY_IMPORT Tentative d'importation d'une nouvelle clé cryptographique.
TAG_KEY_INTEGRITY_VIOLATION Android a détecté une clé de chiffrement ou d'authentification endommagée.
TAG_LOGGING_STARTED La journalisation de sécurité a démarré l'enregistrement.
TAG_LOGGING_STOPPED Le journal de sécurité a arrêté l'enregistrement.
TAG_LOG_BUFFER_SIZE_CRITICAL Le tampon du journal de sécurité a atteint 90% de sa capacité.
TAG_MAX_PASSWORD_ATTEMPTS_SET Une application d'administration a défini le nombre maximal autorisé de tentatives de saisie d'un mot de passe incorrect.
TAG_MAX_SCREEN_LOCK_TIMEOUT_SET Une application d'administration a défini un délai maximal de verrouillage de l'écran.
TAG_MEDIA_MOUNT Support de stockage amovible monté sur l'appareil.
TAG_MEDIA_UNMOUNT L'appareil a désinstallé le support de stockage amovible.
TAG_OS_SHUTDOWN Le système Android s'est arrêté.
TAG_OS_STARTUP Le système Android a démarré.
TAG_PASSWORD_COMPLEXITY_SET Une application d'administration a défini des exigences de complexité des mots de passe.
TAG_PASSWORD_EXPIRATION_SET Une application d'administration a défini une durée d'expiration des mots de passe.
TAG_PASSWORD_HISTORY_LENGTH_SET Une application d'administration a défini une durée pour l'historique des mots de passe, ce qui empêche les utilisateurs de réutiliser d'anciens mots de passe.
TAG_REMOTE_LOCK Une application d'administration a verrouillé l'appareil ou le profil professionnel.
TAG_USER_RESTRICTION_ADDED Une application d'administration a défini une restriction utilisateur.
TAG_USER_RESTRICTION_REMOVED Une application d'administration a supprimé une restriction utilisateur.
TAG_WIPE_FAILURE Échec de la tentative d'effacement des données d'un appareil ou d'un profil professionnel.

Défi sur l'écran de verrouillage du profil professionnel

À partir d'Android 9, les propriétaires de profils peuvent demander aux utilisateurs de définir une question d'authentification distincte sur l'écran de verrouillage pour leur profil professionnel à l'aide de la restriction utilisateur DISALLOW_UNIFIED_PASSWORD. Pour vérifier si un utilisateur a défini la même question d'authentification sur l'écran de verrouillage pour son appareil et son profil professionnel, appelez DevicePolicyManager.isUsingUnifiedPassword().

Si un appareil dispose d'un écran de verrouillage de profil professionnel distinct, DevicePolicyManager.setMaximumTimeToLock() définit un délai de mise en veille de l'écran de verrouillage uniquement pour le profil professionnel et non pour l'ensemble de l'appareil.

Accès aux outils pour les développeurs

Pour vous aider à conserver les données professionnelles dans le profil professionnel, l'outil Android Debug Bridge (adb) ne peut pas accéder aux répertoires ni aux fichiers du profil professionnel.

Compatibilité avec plus d'options biométriques

Android 9 offre un contrôle ultraprécis de l'authentification biométrique matérielle dans l'écran de verrouillage d'un profil professionnel. Appelez la méthode DevicePolicyManager.setKeyguardDisabledFeatures() existante avec KEYGUARD_DISABLE_FACE et KEYGUARD_DISABLE_IRIS. Pour désactiver toutes les méthodes d'authentification biométrique fournies par l'appareil, ajoutez KEYGUARD_DISABLE_BIOMETRICS.

Abandon des règles d'administration des appareils

Android 9 marque les règles listées ci-dessous comme obsolètes pour les DPC à l'aide de l'administrateur de l'appareil. Les règles continuent de fonctionner dans Android 9 comme auparavant. À partir de la version Android 10, les mêmes règles génèrent une exception SecurityException lorsqu'elles sont appelées par un administrateur de l'appareil.

Certaines applications utilisent l'administration des appareils pour les appareils grand public. (par exemple, verrouiller et effacer un appareil égaré). Les règles suivantes restent disponibles pour activer cette fonctionnalité:

Pour en savoir plus sur ces modifications, consultez Abandon de l'administration des appareils.

Enregistrement par code QR simplifié

Bibliothèque de codes QR intégrée

Android 9 est fourni avec une bibliothèque QR afin de simplifier le provisionnement des appareils par code QR. Les administrateurs informatiques n'ont plus besoin de saisir manuellement les informations Wi-Fi pour configurer un appareil. À la place, avec Android 9, il est possible d'inclure ces informations Wi-Fi dans un code QR. Lorsqu'un administrateur informatique scanne le code QR avec un appareil détenu par l'entreprise, celui-ci se connecte automatiquement au Wi-Fi et lance le processus de provisionnement sans intervention manuelle supplémentaire.

La méthode de provisionnement par code QR permet de spécifier les informations Wi-Fi avec les extras suivants:

Définir la date et le fuseau horaire à l'aide d'options de provisionnement supplémentaires

La méthode de provisionnement par code QR prend en charge le provisionnement d'extras pour définir l'heure et le fuseau horaire d'un appareil:

Options d'effacement des données

Les administrateurs d'appareils peuvent afficher un message personnalisé pour les utilisateurs lorsqu'ils suppriment un profil professionnel ou un utilisateur secondaire. Ce message aide les utilisateurs d'appareils à comprendre que leur administrateur informatique a supprimé le profil professionnel ou l'utilisateur secondaire. Appelez wipeData(int, CharSequence) et fournissez un court message explicatif. Lorsqu'il est appelé par l'utilisateur principal ou le propriétaire de l'appareil, le système n'affiche pas de message et commence à rétablir la configuration d'usine de l'appareil.

Pour supprimer les données d'abonnement d'une carte SIM eUICC intégrée, appelez wipeData() et incluez WIPE_EUICC dans l'argument flags.

Méthodes pour les propriétaires de fiches affiliés

Les propriétaires de profils affiliés peuvent utiliser les méthodes suivantes: