Présentation de l'administration des appareils

Abandon de l'administrateur d'appareils. À partir d'Android 9 (niveau d'API 28), certaines règles d'administration seront marquées comme obsolètes par l'administrateur de l'appareil. Nous vous recommandons de vous préparer dès maintenant à ce changement. Pour apprendre et les options de migration, consultez la documentation <ph type="x-smartling-placeholder"></ph> Abandon de l'administrateur d'appareils.

Android prend en charge les applications d'entreprise via API Android Device Administration. L'API Device Administration fournit des informations sur les appareils au niveau du système. Ces API vous permettent de créer qui sont utiles en entreprise, dans lesquelles les équipes informatiques les professionnels ont besoin d'un contrôle approfondi sur les appareils de leurs employés. Par exemple, l'application de messagerie Android intégrée a exploité ces API pour améliorer Prise en charge d'Exchange. Via l'application E-mail, les administrateurs Exchange peuvent : appliquer des règles relatives aux mots de passe, y compris des mots de passe alphanumériques ou numériques ; sur tous vos appareils. Les administrateurs peuvent aussi effacer à distance rétablir les paramètres d'usine) des appareils perdus ou volés. Synchronisation des utilisateurs Exchange leurs e-mails et leurs données d'agenda.

Ce document s'adresse aux développeurs qui souhaitent développer des applications pour les appareils Android. Il aborde les différentes fonctionnalités fournies par l'API Device Administration afin de renforcer la sécurité des les appareils des employés qui fonctionnent sous Android.

Remarque : Pour en savoir plus sur la création d'une règle professionnelles Contrôleur pour les déploiements Android for Work, consultez la page Créer un outil de contrôle des règles relatives aux appareils

Mode propriétaire de l'appareil headless

Android 14 (niveau d'API 34) introduit le mode Utilisateur système headless (les appareils dans lequel UserManager.isHeadlessSystemUserMode renvoie true). En mode "Headless System User", l'utilisateur système est utilisateur en arrière-plan et compte sur des utilisateurs de premier plan supplémentaires pour l'utilisateur final d'interaction. Android 14 propose également mode affilié sans interface graphique propriétaire de l'appareil, qui ajoute un propriétaire de profil à toutes utilisateurs affiliés autre que l'utilisateur système pour lequel le propriétaire de l'appareil est défini.

Dans les appareils configurés avec un utilisateur système headless (où l'utilisateur système s'exécute en arrière-plan), et ne s'applique qu'aux règles relatives aux appareils qui ont un champ d'application global. (règles applicables à tous les utilisateurs) sont appliquées à l'utilisateur de premier plan. ou utilisateurs. Voir addUserRestriction pour en savoir plus.

<ph type="x-smartling-placeholder">

</ph> Remarque:Sous Android 14 (niveau d'API 34), une application DPC peut être définie en tant que propriétaire d'un appareil configuré en tant que Appareil en mode utilisateur système headless uniquement s'il est compatible avec le mode affilié. Voir HEADLESS_DEVICE_OWNER_MODE_AFFILIATED pour en savoir plus.

Les fabricants d'appareils Android peuvent se référer au conseil publiées sur source.android.com.

Présentation de l'API d'administration des appareils

Voici des exemples de types d'applications qui peuvent utiliser l'API Device Administration:

• Clients de messagerie.
• Applications de sécurité qui effacent à distance les données
• Services et applications de gestion d'appareils.

Fonctionnement

L'API Device Administration vous permet de créer des applications d'administration de l'appareil pour les utilisateurs. installer sur leurs appareils. L'application d'administration de l'appareil applique règles. Fonctionnement :

• Un administrateur système écrit une application d'administration de l'appareil qui applique politiques de sécurité des appareils distants/locaux. Ces règles peuvent être codées en dur l'application, ou celle-ci peut récupérer de façon dynamique des règles à partir d'un Google Cloud.
• L'application est installée sur les appareils des utilisateurs appareils. Android ne disposent actuellement d'aucune solution de provisionnement automatisé. Certaines façons dont un administrateur système peut distribuer l'application aux utilisateurs sont les suivantes: <ph type="x-smartling-placeholder">
  </ph>
  • Google Play.
  • Activation de l'installation depuis un autre magasin.
  • distribuer l'application par d'autres moyens, tels que des e-mails ou des sites Web ;
• Le système invite l'utilisateur à activer l'application d'administration de l'appareil. Comment Le moment où cela se produit dépend de la façon dont l'application est implémentée.
• Une fois que les utilisateurs activent l'application d'administration de l'appareil, ils sont soumis aux ses règles. Le respect de ces règles présente généralement des avantages, tels que l'accès à des données et systèmes sensibles.

Si les utilisateurs n'activent pas l'application d'administration de l'appareil, celle-ci reste sur l'appareil, mais dans un état inactif. Les utilisateurs ne seront pas soumis aux règles de l'application et n'en bénéficieront pas des avantages (par exemple, ils ne pourront peut-être pas synchroniser les données).

Si un utilisateur ne respecte pas les règles (par exemple, si un utilisateur définit un qui enfreint ces consignes), il appartient à l'application de décider comment gérer cela. Toutefois, cela empêche généralement l'utilisateur en mesure de synchroniser des données.

Si un appareil tente de se connecter à un serveur qui exige des règles non prise en charge dans l'API Device Administration, la connexion n'est pas ne sont pas autorisés. Pour le moment, l'API Device Administration n'autorise pas l'accès partiel et le provisionnement. En d'autres termes, si un appareil (un ancien appareil, par exemple) n'est pas compatible avec toutes les règles mentionnées, il n'existe aucun moyen périphérique pour se connecter.

Si un appareil contient plusieurs applications d'administration activées, la règle la plus stricte est application. Il n'est pas possible de cibler un administrateur en particulier. l'application.

Pour désinstaller une application d'administration de l'appareil, les utilisateurs doivent : commencez par annuler l'enregistrement de l'application en tant qu'administrateur.

Règles

Dans une entreprise, les appareils des employés doivent souvent respectent un ensemble de règles strictes régissant l'utilisation de l'appareil. La L'API Device Administration est compatible avec les règles répertoriées dans le tableau 1. Notez que l'API Device Administration n'est actuellement compatible qu'avec les mots de passe d'écran verrouiller:

Tableau 1. Règles compatibles avec l'API Device Administration.

Règle	Description
Mot de passe activé	Nécessite que les appareils demandent un code ou des mots de passe.
Longueur minimale du mot de passe	Définissez le nombre de caractères requis pour le mot de passe. Par exemple : peut exiger un code PIN ou des mots de passe d'au moins six caractères.
Mot de passe alphanumérique requis	Les mots de passe doivent avoir un de lettres et de chiffres. Ils peuvent inclure des caractères symboliques.
Mot de passe complexe requis	Les mots de passe doivent contenir au moins une lettre, un chiffre et un symbole spécial. Introduit dans Android 3.0.
Nombre minimal de lettres requis dans le mot de passe	Le nombre minimum de les lettres requises dans le mot de passe pour tous les administrateurs ou pour un administrateur en particulier. Introduit dans Android 3.0.
Nombre minimal de lettres minuscules requis dans le mot de passe	Le nombre minimal de minuscules les lettres requises dans le mot de passe pour tous les administrateurs ou pour un administrateur en particulier. Introduit dans Android 3.0.
Nombre minimal de caractères autres que des lettres requis dans le mot de passe	Le nombre minimum de caractères autres que des lettres requis dans le mot de passe pour tous les administrateurs ou pour un administrateur particulier. Introduit dans Android 3.0.
Nombre minimal de chiffres requis dans le mot de passe	Nombre minimal de chiffres requis dans le mot de passe pour tous les administrateurs ou pour un mot de passe spécifique. Introduit dans Android 3.0.
Nombre minimal de symboles requis dans le mot de passe	Nombre minimal de symboles requis dans le mot de passe pour tous les administrateurs ou un administrateur en particulier. Introduit dans Android 3.0.
Nombre minimal de lettres majuscules requis dans le mot de passe	Nombre minimal de lettres majuscules requises dans le mot de passe pour tous les administrateurs ou un administrateur en particulier. Introduit dans Android 3.0.
Délai d'expiration du mot de passe	Délai d'expiration du mot de passe, exprimé en millisecondes à partir du moment où l'administrateur de l'appareil a défini le délai d'expiration. Introduit dans Android 3.0.
Restriction de l'historique des mots de passe	Cette règle empêche les utilisateurs de réutiliser les n derniers mots de passe uniques. Cette règle est généralement utilisée conjointement avec setPasswordExpirationTimeout(), qui force aux utilisateurs de mettre à jour leurs mots de passe après un délai spécifié. Introduit dans Android 3.0.
Nombre maximal de tentatives de saisie de mot de passe infructueuses	Spécifie le nombre de fois qu'un utilisateur peut saisir un mot de passe erroné avant que la l'appareil efface ses données. L'API Device Administration permet également aux administrateurs de rétablir la configuration d'usine de l'appareil à distance. Cela permet de sécuriser les données au cas où appareil est perdu ou volé.
Verrouillage de la durée d'inactivité maximale	Définit le temps écoulé depuis la dernière fois que l'utilisateur a touché l'écran ou a appuyé sur un bouton avant que l'appareil ne verrouille l'écran. Dans ce cas, les utilisateurs doivent ressaisir leur code PIN ou leurs mots de passe avant de pouvoir utiliser leurs appareils et accéder aux données. La valeur peut être comprise entre 1 et 60 minutes.
Exiger le chiffrement du stockage	Indique que la zone de stockage doit être chiffrée, si l'appareil le permet. Introduit dans Android 3.0.
Désactiver la caméra	Indique que l'appareil photo doit être désactivé. Notez qu'il n'existe pas soit une désactivation permanente. La caméra peut être activée/désactivée de façon dynamique. en fonction du contexte, de l'heure, etc. Introduit dans Android 4.0.

Autres fonctions

En plus de prendre en charge les règles listées dans le tableau ci-dessus, L'API Administration vous permet d'effectuer les opérations suivantes:

• Invitez l'utilisateur à définir un nouveau mot de passe.
• Verrouiller immédiatement l'appareil
• Effacer les données de l'appareil (c'est-à-dire rétablir sa configuration d'usine)

Application exemple

Les exemples présentés sur cette page sont basés sur l'API Device Administration qui est inclus dans les exemples de SDK (disponibles via le Android SDK Manager) et situé sur votre système en tant que <sdk_root>/ApiDemos/app/src/main/java/com/example/android/apis/app/DeviceAdminSample.java

L'application exemple propose une démonstration des fonctionnalités d'administration de l'appareil. Il présente aux utilisateurs avec une interface utilisateur qui leur permet d'activer l'application d'administration de l'appareil. Une fois s'ils ont activé l'application, ils peuvent utiliser les boutons de l'interface utilisateur pour effectuer les opérations suivantes:

• Définissez la qualité du mot de passe.
• Spécifiez les conditions requises pour le mot de passe de l'utilisateur, telles que la longueur minimale, le nombre minimal de les caractères numériques qu'il doit contenir, etc.
• Définissez le mot de passe. Si le mot de passe n'est pas conforme au , le système renvoie une erreur.
• Définir le nombre de tentatives infructueuses de saisie du mot de passe avant l'effacement des données de l'appareil (c'est-à-dire lorsque sa configuration d'usine a été rétablie).
• Définissez le délai d'expiration du mot de passe.
• Définissez la longueur de l'historique des mots de passe (longueur correspond au nombre d'anciens mots de passe stockés dans l'historique). Cela empêche les utilisateurs de réutiliser l'un des n derniers mots de passe utilisés précédemment.
• Indiquez que la zone de stockage doit être chiffrée, si l'appareil le permet.
• Définir la durée maximale d'inactivité avant l'appareil ces serrures.
• Verrouiller immédiatement l'appareil
• Effacer les données de l'appareil (c'est-à-dire rétablir la configuration d'usine)
• Désactivez la caméra.

Figure 1 : Capture d'écran de l'application exemple

Développer une application d'administration des appareils

Les administrateurs système peuvent utiliser l'API Device Administration pour écrire une application. qui applique l’application des stratégies de sécurité des appareils distants/locaux. Cette section résume les étapes nécessaires à la création d'une administration de périphérique l'application.

Créer le fichier manifeste

Pour utiliser l'API Device Administration, le fichier manifeste doit inclure les éléments suivants:

• Une sous-classe de DeviceAdminReceiver comprenant les éléments suivants: <ph type="x-smartling-placeholder">
  </ph>
  • L'autorisation BIND_DEVICE_ADMIN
  • La possibilité de répondre à l'ACTION_DEVICE_ADMIN_ENABLED un intent, exprimé dans le fichier manifeste sous la forme d'un filtre d'intent.
• Déclaration de règles de sécurité utilisées dans les métadonnées.

Voici un extrait de l'exemple de fichier manifeste d'administration des appareils:

<activity android:name=".app.DeviceAdminSample"
            android:label="@string/activity_sample_device_admin">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.SAMPLE_CODE" />
    </intent-filter>
</activity>
<receiver android:name=".app.DeviceAdminSample$DeviceAdminSampleReceiver"
        android:label="@string/sample_device_admin"
        android:description="@string/sample_device_admin_description"
        android:permission="android.permission.BIND_DEVICE_ADMIN">
    <meta-data android:name="android.app.device_admin"
            android:resource="@xml/device_admin_sample" />
    <intent-filter>
        <action android:name="android.app.action.DEVICE_ADMIN_ENABLED" />
    </intent-filter>
</receiver>

Gardez à l'esprit les points suivants :

• Les attributs suivants font référence aux ressources de chaîne qui, pour l'exemple d'application, se trouvent ApiDemos/res/values/strings.xml Pour en savoir plus sur les ressources, consultez Ressources d'application.
  • android:label="@string/activity_sample_device_admin" fait référence aux libellé lisible pour l'activité.
  • android:label="@string/sample_device_admin" fait référence aux libellé lisible par l'utilisateur pour l'autorisation.
  • android:description="@string/sample_device_admin_description" fait référence à la description lisible par l’utilisateur de l’autorisation. Une description est généralement plus longue et plus informatives que une étiquette.
• android:permission="android.permission.BIND_DEVICE_ADMIN" est une autorisation qu'une sous-classe DeviceAdminReceiver doit pour garantir que seul le système peut interagir avec le récepteur (aucune application ne peut obtenir cette autorisation). Ce empêche les autres applications d'utiliser l'application d'administration de votre appareil de façon abusive.
• android.app.action.DEVICE_ADMIN_ENABLED est l'instance principale action qu'une sous-classe DeviceAdminReceiver doit gérer pour être autorisé à gérer un appareil. Il est défini sur le récepteur lorsque l'utilisateur active l'application d'administration de l'appareil. Votre code gère généralement cela onEnabled() Pour être pris en charge, le récepteur doit également ont besoin de l'autorisation BIND_DEVICE_ADMIN pour que les autres applications ne peut pas en abuser.
• Lorsqu'un utilisateur active l'application d'administration de l'appareil, le destinataire autorisation d'effectuer des actions en réponse à la diffusion d'un système particulier événements. Lorsqu'un événement approprié se produit, l'appli peut imposer une règle. Pour Par exemple, si l'utilisateur tente de définir un nouveau mot de passe qui n'est pas l'application peut inviter l'utilisateur à choisir un autre mot de passe qui répond aux exigences.
• Évitez de modifier le nom du récepteur après avoir publié votre application. Si le nom figurant dans le champ modifications du fichier manifeste, l'administration de l'appareil est désactivée lorsque les utilisateurs mettent à jour l'application. Pour en savoir plus, consultez <receiver>
• android:resource="@xml/device_admin_sample" Il déclare les stratégies de sécurité utilisées dans les métadonnées. Les métadonnées fournissent des informations Informations spécifiques à l'administrateur de l'appareil, analysées par la classe DeviceAdminInfo. Voici le contenu de device_admin_sample.xml:

<device-admin xmlns:android="http://schemas.android.com/apk/res/android">
  <uses-policies>
    <limit-password />
    <watch-login />
    <reset-password />
    <force-lock />
    <wipe-data />
    <expire-password />
    <encrypted-storage />
    <disable-camera />
  </uses-policies>
</device-admin>

Lors de la conception de votre application d'administration d'appareils, vous n'avez pas besoin toutes les règles, seulement celles qui s'appliquent à votre application.

Pour en savoir plus sur le fichier manifeste, consultez le guide du développeur Android.

Implémenter le code

L'API Device Administration comprend les classes suivantes:

DeviceAdminReceiver

Classe de base pour l'implémentation d'un composant d'administration des appareils. Cette classe fournit ce qui facilite l'interprétation des actions d'intent brutes envoyées par le du système d'exploitation. Votre application d'administration des appareils doit inclure un DeviceAdminReceiver.

DevicePolicyManager

Classe permettant de gérer les règles appliquées à un appareil. La plupart des clients de cette classe doit avoir publié un DeviceAdminReceiver que l'utilisateur est actuellement activé. DevicePolicyManager gère les règles pour une ou plusieurs instances DeviceAdminReceiver

DeviceAdminInfo

Cette classe est utilisée pour spécifier les métadonnées. d'un composant d'administrateur de l'appareil.

Ces classes constituent la base d'une application d'administration d'appareils entièrement fonctionnelle. Le reste de cette section explique comment utiliser DeviceAdminReceiver et API DevicePolicyManager pour créer une application d'administration d'appareils.

Sous-classement de DeviceAdminReceiver

Pour créer une application d'administration de l'appareil, vous devez sous-classer DeviceAdminReceiver La classe DeviceAdminReceiver consiste en une série de rappels qui sont déclenchés lorsque des événements particuliers se produisent.

Dans sa sous-classe DeviceAdminReceiver, l'application exemple affiche simplement une notification Toast en réponse à une événements. Exemple :

Kotlin

class DeviceAdminSample : DeviceAdminReceiver() {

    private fun showToast(context: Context, msg: String) {
        context.getString(R.string.admin_receiver_status, msg).let { status ->
            Toast.makeText(context, status, Toast.LENGTH_SHORT).show()
        }
    }

    override fun onEnabled(context: Context, intent: Intent) =
            showToast(context, context.getString(R.string.admin_receiver_status_enabled))

    override fun onDisableRequested(context: Context, intent: Intent): CharSequence =
            context.getString(R.string.admin_receiver_status_disable_warning)

    override fun onDisabled(context: Context, intent: Intent) =
            showToast(context, context.getString(R.string.admin_receiver_status_disabled))

    override fun onPasswordChanged(context: Context, intent: Intent, userHandle: UserHandle) =
            showToast(context, context.getString(R.string.admin_receiver_status_pw_changed))
...
}

Java

public class DeviceAdminSample extends DeviceAdminReceiver {

    void showToast(Context context, String msg) {
        String status = context.getString(R.string.admin_receiver_status, msg);
        Toast.makeText(context, status, Toast.LENGTH_SHORT).show();
    }

    @Override
    public void onEnabled(Context context, Intent intent) {
        showToast(context, context.getString(R.string.admin_receiver_status_enabled));
    }

    @Override
    public CharSequence onDisableRequested(Context context, Intent intent) {
        return context.getString(R.string.admin_receiver_status_disable_warning);
    }

    @Override
    public void onDisabled(Context context, Intent intent) {
        showToast(context, context.getString(R.string.admin_receiver_status_disabled));
    }

    @Override
    public void onPasswordChanged(Context context, Intent intent, UserHandle userHandle) {
        showToast(context, context.getString(R.string.admin_receiver_status_pw_changed));
    }
...
}

Activer l'application

L'un des principaux événements qu'une application d'administration de l'appareil doit gérer est l'utilisateur activer l'application. L'utilisateur doit activer explicitement l'application pour les stratégies à appliquer. Si l'utilisateur choisit de ne pas activer l'application il sera toujours présent sur l'appareil, mais ses règles ne seront pas appliquées et l'utilisateur n'y aura pas accès de bénéficier de tous les avantages de l'application.

Le processus d'activation de l'application commence lorsque l'utilisateur effectue action qui déclenche le ACTION_ADD_DEVICE_ADMIN l'intention. Dans application exemple, cela se produit lorsque l'utilisateur clique sur le bouton Activer Admin.

Lorsque l'utilisateur coche la case Activer l'administrateur, l'écran pour inviter l'utilisateur à activer l'application d'administration de l'appareil, comme illustré sur la figure. 2.

Figure 2. Application exemple: activation de l'application

Vous trouverez ci-dessous le code qui s'exécute lorsque l'utilisateur clique sur la case Activer l'administrateur. Cela a pour effet de déclencher onPreferenceChange() . Ce rappel est appelé lorsque la valeur de cet élément Preference a été modifiée par l'utilisateur et est sur le point d'être définie et/ou persistante. Si l'utilisateur active l'application, l'écran pour inviter l'utilisateur à activer l'application d'administration de l'appareil, comme illustré sur la figure. 2. Sinon, l'application d'administration de l'appareil est désactivée.

Kotlin

override fun onPreferenceChange(preference: Preference, newValue: Any): Boolean {
    if (super.onPreferenceChange(preference, newValue)) return true
    val value = newValue as Boolean
    if (preference == enableCheckbox) {
        if (value != adminActive) {
            if (value) {
                // Launch the activity to have the user enable our admin.
                val intent = Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN).apply {
                    putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, deviceAdminSample)
                    putExtra(DevicePolicyManager.EXTRA_ADD_EXPLANATION,
                            activity.getString(R.string.add_admin_extra_app_text))
                }
                startActivityForResult(intent, REQUEST_CODE_ENABLE_ADMIN)
                // return false - don't update checkbox until we're really active
                return false
            } else {
                dpm.removeActiveAdmin(deviceAdminSample)
                enableDeviceCapabilitiesArea(false)
                adminActive = false
            }
        }
    } else if (preference == disableCameraCheckbox) {
        dpm.setCameraDisabled(deviceAdminSample, value)
    }
    return true
}

Java

@Override
public boolean onPreferenceChange(Preference preference, Object newValue) {
    if (super.onPreferenceChange(preference, newValue)) {
        return true;
    }
    boolean value = (Boolean) newValue;
    if (preference == enableCheckbox) {
        if (value != adminActive) {
            if (value) {
                // Launch the activity to have the user enable our admin.
                Intent intent = new Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN);
                intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, deviceAdminSample);
                intent.putExtra(DevicePolicyManager.EXTRA_ADD_EXPLANATION,
                        activity.getString(R.string.add_admin_extra_app_text));
                startActivityForResult(intent, REQUEST_CODE_ENABLE_ADMIN);
                // return false - don't update checkbox until we're really active
                return false;
            } else {
                dpm.removeActiveAdmin(deviceAdminSample);
                enableDeviceCapabilitiesArea(false);
                adminActive = false;
            }
        }
    } else if (preference == disableCameraCheckbox) {
        dpm.setCameraDisabled(deviceAdminSample, value);
    }
    return true;
}

La ligne intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, mDeviceAdminSample) indique que mDeviceAdminSample (qui est un composant DeviceAdminReceiver) est la règle cible. Cette ligne appelle l'interface utilisateur illustrée à la figure 2, qui guide les utilisateurs à travers ajouter l'administrateur de l'appareil au système (ou lui permettre de le refuser).

Lorsque l'application doit effectuer une opération qui dépend de la l'application d'administration de l'appareil en cours d'activation, cela confirme que l'application est actif. Pour ce faire, elle utilise la méthode DevicePolicyManager. isAdminActive() Notez que DevicePolicyManager La méthode isAdminActive() prend un DeviceAdminReceiver composant comme argument:

Kotlin

private lateinit var dpm: DevicePolicyManager
...
private fun isActiveAdmin(): Boolean = dpm.isAdminActive(deviceAdminSample)

Java

DevicePolicyManager dpm;
...
private boolean isActiveAdmin() {
    return dpm.isAdminActive(deviceAdminSample);
}

Gestion des règles

DevicePolicyManager est une classe publique permettant de gérer les règles. sur un appareil. DevicePolicyManager gère des règles pour une personne ou plusieurs instances DeviceAdminReceiver.

Vous obtenez un handle vers DevicePolicyManager comme suit:

Kotlin

dpm = getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager

Java

DevicePolicyManager dpm =
    (DevicePolicyManager)getSystemService(Context.DEVICE_POLICY_SERVICE);

Cette section explique comment utiliser DevicePolicyManager pour effectuer tâches administratives:

• Définir des règles de mots de passe
• Configurer le verrouillage de l'appareil
• Effacer les données

Définir des règles relatives aux mots de passe

DevicePolicyManager inclut des API permettant de définir et d'appliquer règles relatives aux mots de passe de l'appareil. Dans l'API Device Administration, le mot de passe ne s'applique le verrouillage de l'écran. Cette section décrit les tâches courantes liées aux mots de passe.

Définir un mot de passe pour l'appareil

Ce code affiche une interface utilisateur invitant l'utilisateur à définir un mot de passe:

Kotlin

Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD).also { intent ->
    startActivity(intent)
}

Java

Intent intent = new Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD);
startActivity(intent);

Définir la qualité du mot de passe

La qualité du mot de passe peut être l'une des constantes DevicePolicyManager suivantes:

PASSWORD_QUALITY_ALPHABETIC

L'utilisateur doit saisir un un mot de passe contenant au moins des lettres (ou d'autres symboles).

PASSWORD_QUALITY_ALPHANUMERIC

L'utilisateur doit saisir un un mot de passe contenant au moins à la fois des chiffres et des lettres (ou (un autre symbole).

PASSWORD_QUALITY_NUMERIC

L'utilisateur doit saisir un mot de passe contenant au moins des caractères numériques.

PASSWORD_QUALITY_COMPLEX

L'utilisateur doit avoir saisi un mot de passe contenant au moins une lettre, un chiffre et un symbole spécial.

PASSWORD_QUALITY_SOMETHING

Le requiert une sorte de de mot de passe, mais peu importe.

PASSWORD_QUALITY_UNSPECIFIED

La règle ne requiert aucune exigence concernant le mot de passe.

Par exemple, voici comment vous définiriez la règle de mot de passe pour exiger un mot de passe alphanumérique:

Kotlin

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
...
dpm.setPasswordQuality(deviceAdminSample, DevicePolicyManager.PASSWORD_QUALITY_ALPHANUMERIC)

Java

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
...
dpm.setPasswordQuality(deviceAdminSample, DevicePolicyManager.PASSWORD_QUALITY_ALPHANUMERIC);

Définir les exigences relatives au contenu des mots de passe

À partir d'Android 3.0, la classe DevicePolicyManager comprend des méthodes qui vous permettent d’affiner le contenu du mot de passe. Pour Par exemple, vous pouvez définir une stratégie qui stipule que les mots de passe doivent contenir au moins n lettres majuscules. Voici les méthodes permettant d'affiner contenus:

• setPasswordMinimumLetters()
• setPasswordMinimumLowerCase()
• setPasswordMinimumUpperCase()
• setPasswordMinimumNonLetter()
• setPasswordMinimumNumeric()
• setPasswordMinimumSymbols()

Par exemple, cet extrait indique que le mot de passe doit comporter au moins deux lettres majuscules:

Kotlin

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val pwMinUppercase = 2
...
dpm.setPasswordMinimumUpperCase(deviceAdminSample, pwMinUppercase)

Java

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
int pwMinUppercase = 2;
...
dpm.setPasswordMinimumUpperCase(deviceAdminSample, pwMinUppercase);

Définir la longueur minimale du mot de passe

Vous pouvez spécifier qu'un mot de passe doit comporter au moins la valeur minimale spécifiée Exemple :

Kotlin

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val pwLength: Int = ...
...
dpm.setPasswordMinimumLength(deviceAdminSample, pwLength)

Java

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
int pwLength;
...
dpm.setPasswordMinimumLength(deviceAdminSample, pwLength);

Définir le nombre maximal de tentatives infructueuses de saisie du mot de passe

Vous pouvez définir le nombre maximal autorisé de tentatives infructueuses de saisie du mot de passe avant que le les données de l'appareil sont effacées (c'est-à-dire que sa configuration d'usine est rétablie). Exemple :

Kotlin

val dPM:DevicePolicyManager
private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val maxFailedPw: Int = ...
...
dpm.setMaximumFailedPasswordsForWipe(deviceAdminSample, maxFailedPw)

Java

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
int maxFailedPw;
 ...
dpm.setMaximumFailedPasswordsForWipe(deviceAdminSample, maxFailedPw);

Définir le délai d'expiration du mot de passe

À partir de la version 3.0 d'Android, vous pouvez utiliser le setPasswordExpirationTimeout() permettant de définir la date d'expiration d'un mot de passe, exprimée en millisecondes à partir du moment où l'administrateur de l'appareil définit le délai d'expiration. Exemple :

Kotlin

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val pwExpiration: Long = ...
...
dpm.setPasswordExpirationTimeout(deviceAdminSample, pwExpiration)

Java

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
long pwExpiration;
...
dpm.setPasswordExpirationTimeout(deviceAdminSample, pwExpiration);

Limiter les mots de passe en fonction de l'historique

À partir de la version 3.0 d'Android, vous pouvez utiliser le setPasswordHistoryLength() pour limiter le nombre d'utilisateurs la possibilité de réutiliser d'anciens mots de passe. Cette méthode prend une valeur length qui spécifie le nombre d'anciennes les mots de passe sont stockés. Lorsque cette règle est active, les utilisateurs ne peuvent pas saisir mot de passe correspondant aux n derniers mots de passe. Cela permet d'éviter les utilisateurs d’utiliser le même mot de passe encore et encore. Cette règle est généralement utilisée en conjonction avec setPasswordExpirationTimeout(), ce qui oblige les utilisateurs de mettre à jour leurs mots de passe après un certain temps.

Par exemple, l'extrait suivant interdit aux utilisateurs de réutiliser leurs cinq derniers mots de passe:

Kotlin

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val pwHistoryLength = 5
...
dpm.setPasswordHistoryLength(deviceAdminSample, pwHistoryLength)

Java

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
int pwHistoryLength = 5;
...
dpm.setPasswordHistoryLength(deviceAdminSample, pwHistoryLength);

Configurer le verrouillage de l'appareil

Vous pouvez définir la période maximale d'inactivité des utilisateurs pouvant survenir avant le les verrouillages de l'appareil. Exemple :

Kotlin

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val timeMs: Long = 1000L * timeout.text.toString().toLong()
...
dpm.setMaximumTimeToLock(deviceAdminSample, timeMs)

Java

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
...
long timeMs = 1000L*Long.parseLong(timeout.getText().toString());
dpm.setMaximumTimeToLock(deviceAdminSample, timeMs);

Vous pouvez également programmer le verrouillage immédiat de l'appareil:

Kotlin

private lateinit var dpm: DevicePolicyManager
dpm.lockNow()

Java

DevicePolicyManager dpm;
dpm.lockNow();

Effacer les données

Vous pouvez utiliser la méthode DevicePolicyManager. wipeData() pour rétablir la configuration d'usine de l'appareil. C'est utile en cas de perte ou de vol de l'appareil. Souvent, la décision d'effacer les données d'un appareil résultat de certaines conditions. Par exemple, vous pouvez utiliser setMaximumFailedPasswordsForWipe() pour indiquer qu'un appareil doit être effacées après un nombre spécifique de tentatives infructueuses de saisie du mot de passe.

Pour effacer les données, procédez comme suit:

Kotlin

private lateinit var dpm: DevicePolicyManager
dpm.wipeData(0)

Java

DevicePolicyManager dpm;
dpm.wipeData(0);

La méthode wipeData() utilise son un masque de bits d'options supplémentaires. Actuellement, la valeur doit être 0.

Désactiver la caméra

Sous Android 4.0, vous pouvez désactiver la caméra. Notez qu'il n'est pas nécessaire que cette désactivation soit définitive. La caméra peut être activée/désactivée de manière dynamique en fonction du contexte, de l'heure, etc.

Vous pouvez contrôler si la caméra est désactivée ou non à l'aide des setCameraDisabled(). Par exemple, l'extrait de code ci-dessous permet d'activer ou de désactiver l'appareil photo en fonction d'une case à cocher:

Kotlin

private lateinit var disableCameraCheckbox: CheckBoxPreference
private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
...
dpm.setCameraDisabled(deviceAdminSample, mDisableCameraCheckbox.isChecked)

Java

private CheckBoxPreference disableCameraCheckbox;
DevicePolicyManager dpm;
ComponentName deviceAdminSample;
...
dpm.setCameraDisabled(deviceAdminSample, mDisableCameraCheckbox.isChecked());

Chiffrement du stockage

À partir de la version 3.0 d'Android, vous pouvez utiliser le setStorageEncryption() permettant de définir une règle exigeant le chiffrement de l'espace de stockage, le cas échéant.

Exemple :

Kotlin

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
...
dpm.setStorageEncryption(deviceAdminSample, true)

Java

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
...
dpm.setStorageEncryption(deviceAdminSample, true);

Consultez l'exemple de l'API Device Administration pour découvrir comment activer le chiffrement du stockage.

Autres exemples de code

La règle Android AppRestrictionEnforcer et DeviceOwner qui illustrent plus en détail l'utilisation des API abordées sur cette page.