Présentation de l'administration des appareils

Abandon de l'outil d'administration des appareils À partir d'Android 9 (niveau d'API 28), certaines règles d'administration seront marquées comme obsolètes lorsqu'elles seront appelées par un administrateur d'appareil. Nous vous recommandons de commencer à vous préparer dès maintenant à ce changement. Pour en savoir plus et découvrir les options de migration, consultez Abandon de l'administration des appareils.

Android prend en charge les applications d'entreprise en proposant l'API Android Device Administration. L'API Device Administration fournit des fonctionnalités d'administration des appareils au niveau du système. Ces API vous permettent de créer des applications axées sur la sécurité qui sont utiles dans les environnements d'entreprise, où les professionnels de l'informatique ont besoin d'un contrôle étendu sur les appareils des employés. Par exemple, l'application de messagerie Android intégrée utilise ces API pour améliorer la compatibilité avec Exchange. Grâce à l'application de messagerie, les administrateurs Exchange peuvent appliquer des règles de mot de passe (y compris des mots de passe alphanumériques ou des codes numériques) sur tous les appareils. Les administrateurs peuvent également effacer à distance (c'est-à-dire rétablir la configuration d'usine) les téléphones perdus ou volés. Les utilisateurs d'Exchange peuvent synchroniser leurs données de messagerie et d'agenda.

Ce document est destiné aux développeurs qui souhaitent développer des solutions d'entreprise pour les appareils Android. Il présente les différentes fonctionnalités de l'API Device Administration, qui renforcent la sécurité des appareils Android des employés.

Remarque : Pour en savoir plus sur la création d'un Work Policy Controller pour les déploiements Android for Work, consultez Créer un contrôleur de règles relatives aux appareils.

Mode propriétaire de l'appareil headless

Android 14 (niveau d'API 34) introduit le mode utilisateur du système headless (appareils sur lesquels UserManager.isHeadlessSystemUserMode renvoie true). En mode utilisateur du système headless, l'utilisateur du système est un utilisateur en arrière-plan et s'appuie sur des utilisateurs supplémentaires au premier plan pour l'interaction avec l'utilisateur final. Android 14 introduit également un mode affilié du propriétaire d'appareil headless, qui ajoute un propriétaire de profil à tous les utilisateurs affiliés autres que l'utilisateur système sur lequel le propriétaire de l'appareil est défini.

Sur les appareils configurés avec un utilisateur système sans interface graphique (où l'utilisateur système s'exécute en arrière-plan), seules les règles relatives aux appareils qui sont globales (règles applicables à tous les utilisateurs) sont appliquées à l'utilisateur ou aux utilisateurs au premier plan. Pour en savoir plus, consultez addUserRestriction.

Les fabricants d'appareils Android peuvent se référer aux conseils publiés sur source.android.com.

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

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

• Clients de messagerie.
• Applications de sécurité qui effectuent un effacement à distance.
• Services et applications de gestion des appareils.

Fonctionnement

Vous utilisez l'API Device Administration pour écrire des applications d'administration d'appareils que les utilisateurs installent sur leurs appareils. L'application d'administration de l'appareil applique les règles souhaitées. Voici comment cela fonctionne :

• Un administrateur système écrit une application d'administration d'appareil qui applique des règles de sécurité locales/distantes pour l'appareil. Ces règles peuvent être codées en dur dans l'application, ou l'application peut récupérer dynamiquement des règles à partir d'un serveur tiers.
• L'application est installée sur les appareils des utilisateurs. Android ne dispose pas actuellement d'une solution de provisionnement automatisée. Voici quelques-unes des méthodes qu'un administrateur système peut utiliser pour distribuer l'application aux utilisateurs :
  • Google Play.
  • Activation de l'installation depuis un autre magasin.
  • Distribuer l'application par d'autres moyens, par exemple par e-mail ou sur des sites Web
• Le système invite l'utilisateur à activer l'application d'administration de l'appareil. Le moment et la manière dont cela se produit dépendent de la façon dont l'application est implémentée.
• Une fois que les utilisateurs ont activé l'application d'administration de l'appareil, ils sont soumis à ses règles. Le respect de ces règles confère généralement des avantages, tels que l'accès à des systèmes et des données sensibles.

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

Si un utilisateur ne respecte pas les règles (par exemple, s'il définit un mot de passe qui ne respecte pas les consignes), l'application doit décider de la manière de gérer ce problème. Toutefois, cela empêchera généralement l'utilisateur de synchroniser les données.

Si un appareil tente de se connecter à un serveur qui nécessite des règles non compatibles avec l'API Device Administration, la connexion ne sera pas autorisée. L'API Device Administration ne permet pas actuellement le provisionnement partiel. En d'autres termes, si un appareil (par exemple, un appareil ancien) n'est pas compatible avec toutes les règles indiquées, il n'est pas possible de l'autoriser à se connecter.

Si un appareil contient plusieurs applications d'administration activées, la règle la plus stricte est appliquée. Il n'est pas possible de cibler une application d'administration spécifique.

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

Règles

Dans un environnement d'entreprise, les appareils des employés doivent souvent respecter un ensemble de règles strictes qui régissent l'utilisation de l'appareil. L'API Device Administration est compatible avec les règles listées dans le tableau 1. Notez que l'API Device Administration n'est actuellement compatible qu'avec les mots de passe pour le verrouillage de l'écran :

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

Autres fonctionnalités

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

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

Application exemple

Les exemples utilisés sur cette page sont basés sur l'exemple d'API Device Administration, qui est inclus dans les exemples du SDK (disponibles via Android SDK Manager) et se trouve sur votre système à l'emplacement <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 des appareils. Il présente aux utilisateurs une interface utilisateur qui leur permet d'activer l'application d'administration de l'appareil. Une fois l'application activée, 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 exigences relatives au mot de passe de l'utilisateur, telles que la longueur minimale, le nombre minimal de caractères numériques qu'il doit contenir, etc.
• Définissez le mot de passe. Si le mot de passe n'est pas conforme aux règles spécifiées, le système renvoie une erreur.
• Définissez le nombre de tentatives de saisie du mot de passe infructueuses autorisées avant que les données de l'appareil ne soient effacées (c'est-à-dire avant que la configuration d'usine ne soit 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 fait référence 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 qu'ils ont utilisés.
• Spécifiez que la zone de stockage doit être chiffrée, si l'appareil le permet.
• Définissez la durée maximale d'inactivité qui peut s'écouler avant que l'appareil ne se verrouille.
• Verrouiller l'appareil immédiatement.
• Effacer les données de l'appareil (c'est-à-dire rétablir la configuration d'usine)
• Désactiver la caméra

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

Développer une application d'administration d'appareils

Les administrateurs système peuvent utiliser l'API Device Administration pour écrire une application qui applique des règles de sécurité à distance ou en local sur les appareils. Cette section résume les étapes de création d'une application d'administration d'appareils.

Créer le fichier manifeste

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

• Une sous-classe de DeviceAdminReceiver qui inclut les éléments suivants :
  • L'autorisation BIND_DEVICE_ADMIN.
  • La capacité à répondre à l'intent ACTION_DEVICE_ADMIN_ENABLED, exprimée dans le fichier manifeste en tant que filtre d'intent.
• Déclaration des règles de sécurité utilisées dans les métadonnées.

Voici un extrait de l'exemple de fichier manifeste de l'administration de l'appareil :

<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>

Remarques :

• Les attributs suivants font référence à des ressources de chaîne qui, pour l'application exemple, se trouvent dans ApiDemos/res/values/strings.xml. Pour en savoir plus sur les ressources, consultez Ressources d'applications.
  • android:label="@string/activity_sample_device_admin" fait référence au libellé compréhensible de l'activité.
  • android:label="@string/sample_device_admin" fait référence au libellé lisible par l'utilisateur pour l'autorisation.
  • android:description="@string/sample_device_admin_description" fait référence à la description de l'autorisation lisible par l'utilisateur. Une description est généralement plus longue et plus informative qu'un libellé.
• android:permission="android.permission.BIND_DEVICE_ADMIN" est une autorisation qu'une sous-classe DeviceAdminReceiver doit posséder pour s'assurer que seul le système peut interagir avec le récepteur (aucune application ne peut obtenir cette autorisation). Cela empêche d'autres applications d'utiliser de manière abusive votre application d'administration de l'appareil.
• android.app.action.DEVICE_ADMIN_ENABLED est l'action principale qu'une sous-classe DeviceAdminReceiver doit gérer pour être autorisée à gérer un appareil. Cette valeur est définie sur le récepteur lorsque l'utilisateur active l'application d'administration de l'appareil. Votre code gère généralement cela dans onEnabled(). Pour être compatible, le récepteur doit également exiger l'autorisation BIND_DEVICE_ADMIN afin que d'autres applications ne puissent pas en abuser.
• Lorsqu'un utilisateur active l'application d'administration de l'appareil, le récepteur est autorisé à effectuer des actions en réponse à la diffusion d'événements système particuliers. Lorsqu'un événement approprié se produit, l'application peut imposer une règle. Par exemple, si l'utilisateur tente de définir un nouveau mot de passe qui ne répond pas aux exigences de la règle, l'application peut l'inviter à 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 change dans le 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" déclare les stratégies de sécurité utilisées dans les métadonnées. Les métadonnées fournissent des informations supplémentaires spécifiques à l'administrateur de l'appareil, telles qu'elles sont 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>

Lorsque vous concevez votre application d'administration d'appareils, vous n'avez pas besoin d'inclure toutes les règles, mais seulement celles qui sont pertinentes pour votre application.

Implémenter le code

L'API Device Administration inclut les classes suivantes :

DeviceAdminReceiver

Classe de base pour l'implémentation d'un composant d'administration d'appareil. Cette classe permet d'interpréter facilement les actions d'intent brutes envoyées par le système. Votre application d'administration d'appareils doit inclure une sous-classe DeviceAdminReceiver.

DevicePolicyManager

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

DeviceAdminInfo

Cette classe permet de spécifier les métadonnées d'un composant d'administrateur d'appareil.

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

Sous-classement de DeviceAdminReceiver

Pour créer une application d'administration d'appareil, vous devez sous-classer DeviceAdminReceiver. La classe DeviceAdminReceiver se compose d'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 à des événements particuliers. Exemple :

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))
...
}

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 événements majeurs qu'une application d'administration d'appareil doit gérer est l'activation de l'application par l'utilisateur. L'utilisateur doit explicitement activer l'application pour que les règles soient appliquées. Si l'utilisateur choisit de ne pas activer l'application, elle sera toujours présente sur l'appareil, mais ses règles ne seront pas appliquées et l'utilisateur ne bénéficiera d'aucun des avantages de l'application.

Le processus d'activation de l'application commence lorsque l'utilisateur effectue une action qui déclenche l'intent ACTION_ADD_DEVICE_ADMIN. Dans l'application exemple, cela se produit lorsque l'utilisateur coche la case Enable Admin (Activer l'administrateur).

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

Figure 2. Application exemple : activer l'application

Voici le code qui est exécuté lorsque l'utilisateur coche la case Enable Admin (Activer l'administrateur). Cela a pour effet de déclencher le rappel onPreferenceChange(). Ce rappel est appelé lorsque la valeur de ce Preference a été modifiée par l'utilisateur et est sur le point d'être définie et/ou conservée. Si l'utilisateur active l'application, l'affichage change pour l'inviter à activer l'application d'administration de l'appareil, comme illustré dans la figure 2. Sinon, l'application d'administration de l'appareil est désactivée.

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
}

@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 pour ajouter l'administrateur de l'appareil au système (ou leur permet de le refuser).

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

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

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

Gérer des règles

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

Vous obtenez un handle vers DevicePolicyManager comme suit :

dpm = getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager

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

Cette section explique comment utiliser DevicePolicyManager pour effectuer des tâches d'administration :

• Définir des règles relatives aux 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 la règle relative aux mots de passe de l'appareil. Dans l'API Device Administration, le mot de passe ne s'applique qu'au 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 :

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

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 mot de passe contenant au moins des caractères alphabétiques (ou d'autres symboles).

PASSWORD_QUALITY_ALPHANUMERIC

L'utilisateur doit saisir un mot de passe contenant à la fois des caractères numériques et alphabétiques (ou d'autres symboles).

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

La règle nécessite un mot de passe, mais peu importe lequel.

PASSWORD_QUALITY_UNSPECIFIED

La règle n'impose aucune exigence pour le mot de passe.

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

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

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

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

Depuis Android 3.0, la classe DevicePolicyManager inclut des méthodes qui vous permettent d'ajuster le contenu du mot de passe. Par exemple, vous pouvez définir une règle stipulant que les mots de passe doivent contenir au moins n lettres majuscules. Voici les méthodes permettant d'affiner le contenu d'un mot de passe :

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

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

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

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 longueur minimale spécifiée. Exemple :

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

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 de tentatives de saisie de mot de passe infructueuses autorisées avant que l'appareil ne soit effacé (c'est-à-dire rétabli à sa configuration d'usine). Exemple :

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

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

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

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

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

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

Restreindre le mot de passe en fonction de l'historique

À partir d'Android 3.0, vous pouvez utiliser la méthode setPasswordHistoryLength() pour limiter la possibilité pour les utilisateurs de réutiliser d'anciens mots de passe. Cette méthode utilise un paramètre length, qui spécifie le nombre d'anciens mots de passe stockés. Lorsque cette règle est active, les utilisateurs ne peuvent pas saisir un nouveau mot de passe correspondant aux n derniers mots de passe. Cela empêche les utilisateurs d'utiliser le même mot de passe à plusieurs reprises. Cette règle est généralement utilisée conjointement avec setPasswordExpirationTimeout(), qui force les utilisateurs à modifier leur mot de passe après un certain temps.

Par exemple, cet extrait empêche les utilisateurs de réutiliser l'un de leurs cinq derniers mots de passe :

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

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

Définir le verrouillage de l'appareil

Vous pouvez définir la durée maximale d'inactivité de l'utilisateur avant que l'appareil ne se verrouille. Exemple :

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

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

Vous pouvez également indiquer de manière programmatique à l'appareil de se verrouiller immédiatement :

private lateinit var dpm: DevicePolicyManager
dpm.lockNow()

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. Cette fonctionnalité est utile en cas de perte ou de vol de l'appareil. La décision d'effacer l'appareil est souvent prise lorsque certaines conditions sont remplies. Par exemple, vous pouvez utiliser setMaximumFailedPasswordsForWipe() pour indiquer qu'un appareil doit être effacé après un certain nombre de tentatives de saisie de mot de passe infructueuses.

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

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

DevicePolicyManager dpm;
dpm.wipeData(0);

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

Désactiver la caméra

À partir d'Android 4.0, vous pouvez désactiver l'appareil photo. Notez que cette désactivation n'est pas nécessairement permanente. 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 à l'aide de la méthode setCameraDisabled(). Par exemple, cet extrait de code active ou désactive la caméra en fonction d'un paramètre de case à cocher :

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

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

Chiffrement du stockage

À partir d'Android 3.0, vous pouvez utiliser la méthode setStorageEncryption() pour définir une règle exigeant le chiffrement de la zone de stockage, si possible.

Exemple :

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

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

Consultez l'exemple d'API Device Administration pour obtenir un exemple complet d'activation du chiffrement du stockage.

Autres exemples de code

Les exemples Android AppRestrictionEnforcer et DeviceOwner illustrent davantage l'utilisation des API abordées sur cette page.