Abandon de l'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 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 est compatible avec les applications d'entreprise grâce à 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 sécurisées qui sont utiles dans un environnement 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 E-mail intégrée à Android a exploité ces API pour améliorer la compatibilité avec Exchange. Via l'application E-mail, les administrateurs Exchange peuvent appliquer des règles de mots 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 restaurer les paramètres d'usine) des téléphones perdus ou volés. Les utilisateurs d'Exchange peuvent synchroniser leurs e-mails et leurs données d'agenda.
Ce document est destiné aux développeurs qui souhaitent développer des solutions d'entreprise pour les appareils Android. Elle décrit les différentes fonctionnalités fournies par l'API Device Administration pour renforcer la sécurité des appareils des employés fonctionnant sous Android.
Remarque : Pour savoir comment créer un outil Work Policy Controller pour 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 (appareils sur lesquels UserManager.isHeadlessSystemUserMode renvoie true). Dans ce mode, l'utilisateur système est un utilisateur en arrière-plan qui s'appuie sur des utilisateurs supplémentaires au premier plan pour interagir avec l'utilisateur final. Android 14 introduit également un mode affilié propriétaire d'appareil sans interface graphique, 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 headless (où l'utilisateur système s'exécute en arrière-plan), seules les règles relatives aux appareils de portée globale (règles applicables à tous les utilisateurs) sont appliquées à l'utilisateur ou aux utilisateurs de 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 qui peuvent utiliser l'API Device Administration:
- Clients de messagerie
- Applications de sécurité qui effacent des données à distance
- Services et applications de gestion des appareils
Comment ça marche ?
L'API Device Administration vous permet d'écrire des applications d'administration que les utilisateurs installent sur leurs appareils. L'application d'administration de l'appareil applique les règles souhaitées. Fonctionnement :
- Un administrateur système écrit une application d'administration d'appareil qui applique des règles de sécurité locales ou à distance. Ces règles peuvent être codées en dur dans l'application, ou celle-ci peut extraire dynamiquement des règles d'un serveur tiers.
- L'appli est installée sur les appareils des utilisateurs. Actuellement, Android ne dispose pas de solution de provisionnement automatisé. Un administrateur système peut distribuer l'application aux utilisateurs comme suit :
- Google Play.
- Activation de l'installation à partir d'un autre magasin
- Distribution de 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. La manière dont cela se produit et à quel moment dépend de la manière dont l'application est implémentée.
- Une fois que les utilisateurs activent l'application d'administration des appareils, ils sont soumis à ses règles. Le respect de ces règles présente 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, celle-ci reste sur l'appareil, mais inactive. Les utilisateurs ne seront pas soumis à ses règles et 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), c'est à l'application de décider comment gérer le problème. Toutefois, cela empêche généralement l'utilisateur de synchroniser les données.
Si un appareil tente de se connecter à un serveur nécessitant des règles non compatibles avec l'API Device Administration, la connexion ne sera pas autorisée. L'API Device Administration n'autorise pas le provisionnement partiel pour le moment. En d'autres termes, si un appareil (par exemple, un ancien appareil) n'est pas compatible avec toutes les règles mentionnées, il n'y a aucun moyen 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'existe aucun moyen de cibler une application d'administration particulière.
Pour désinstaller une application d'administration d'appareil existante, les utilisateurs doivent d'abord annuler son enregistrement en tant qu'administrateur.
Règles
Dans un environnement d'entreprise, il est souvent nécessaire que les appareils des employés respectent un ensemble strict de règles régissant leur utilisation. 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 pour le verrouillage de l'écran:
Tableau 1. Règles compatibles avec l'API Device Administration.
| Règlement | Description |
|---|---|
| Mot de passe activé | Nécessite que les appareils demandent un code ou un mot de passe. |
| Longueur minimale du mot de passe | Définissez le nombre de caractères requis pour le mot de passe. Par exemple, vous pouvez exiger que le code PIN ou les mots de passe comportent au moins six caractères. |
| Mot de passe alphanumérique requis | Nécessite que les mots de passe combinent des lettres et des chiffres. Ils peuvent contenir des caractères symboliques. |
| Mot de passe complexe requis | Nécessite que les mots de passe contiennent 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 minimal de lettres requis 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 | Nombre minimal de lettres minuscules requis dans le mot de passe pour tous les administrateurs ou pour un administrateur donné. Introduit dans Android 3.0. |
| Nombre minimal de caractères autres que des lettres requis dans le mot de passe | Nombre minimal de caractères autres que des lettres requis dans le mot de passe pour tous les administrateurs ou pour un utilisateur donné. 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 de tous les administrateurs ou d'un seul d'entre eux. Introduit dans Android 3.0. |
| Nombre minimal de symboles requis dans le mot de passe | Le nombre minimal de symboles requis dans le mot de passe pour tous les administrateurs ou pour un utilisateur donné. Introduit dans Android 3.0. |
| Nombre minimal de lettres majuscules requis dans le mot de passe | Le nombre minimal de lettres majuscules requis dans le mot de passe pour tous les administrateurs ou pour un administrateur donné. Introduit dans Android 3.0. |
| Expiration du mot de passe | Délai d'expiration du mot de passe, exprimé en millisecondes entre le moment où l'administrateur de l'appareil définit 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 oblige les utilisateurs à mettre à jour leurs mots de passe après un certain temps.
Introduit dans Android 3.0. |
| Nombre maximal de tentatives de saisie du mot de passe | Indique le nombre de fois qu'un utilisateur peut saisir le mauvais mot de passe avant que l'appareil n'efface ses données. L'API Device Administration permet également aux administrateurs de rétablir à distance les paramètres d'usine de l'appareil. Cela permet de sécuriser les données en cas de perte ou de vol de l'appareil. |
| Verrouillage de la durée d'inactivité maximale | Définit le temps écoulé depuis que l'utilisateur a touché l'écran ou appuyé sur un bouton pour la dernière fois avant que l'appareil ne verrouille l'écran. Dans ce cas, les utilisateurs doivent saisir à nouveau leur code ou leur mot 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 l'appareil photo | Indique que l'appareil photo doit être désactivé. Notez qu'il ne doit pas nécessairement s'agir d'une désactivation permanente. Vous pouvez activer/désactiver la caméra 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 répertorié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.
- Verrouillez 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 de l'API Device Administration, qui est inclus dans les exemples de SDK (disponibles via 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. Elle 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 liées 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 stratégies spécifiées, le système renvoie une erreur.
- Définissez le nombre de tentatives infructueuses de saisie du mot de passe qui peuvent se produire avant que l'appareil ne soit effacé (c'est-à-dire, sa configuration d'usine).
- Définissez le délai d'expiration du mot de passe.
- Définissez la longueur de l'historique des mots de passe (la 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.
- Spécifiez que la zone de stockage doit être chiffrée, si l'appareil le permet.
- Définissez la durée maximale d'inactivité pouvant s'écouler avant le verrouillage de l'appareil.
- Verrouillez l'appareil immédiatement.
- Effacer les données de l'appareil (par exemple, 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 d'appareils
Les administrateurs système peuvent utiliser l'API Device Administration pour écrire une application qui applique les règles de sécurité des appareils distants/locaux. 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
DeviceAdminReceivercomprenant les éléments suivants :- L'autorisation
BIND_DEVICE_ADMIN - Capacité à répondre à l'intent
ACTION_DEVICE_ADMIN_ENABLED, exprimée dans le fichier manifeste en tant que filtre d'intent.
- L'autorisation
- Déclaration des règles de sécurité utilisées dans les métadonnées.
Voici un extrait de l'exemple de fichier manifeste d'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>
Gardez à l'esprit les points suivants :
- Les attributs suivants font référence aux ressources de chaîne qui se trouvent dans
ApiDemos/res/values/strings.xmlpour l'exemple d'application. Pour en savoir plus sur les ressources, consultez la section Ressources d'application.android:label="@string/activity_sample_device_admin"fait référence au libellé de l'activité lisible par l'utilisateur.android:label="@string/sample_device_admin"fait référence au libellé lisible de 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'une étiquette.
android:permission="android.permission.BIND_DEVICE_ADMIN"est une autorisation qu'une sous-classeDeviceAdminReceiverdoit avoir pour garantir 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 l'application d'administration de votre appareil.android.app.action.DEVICE_ADMIN_ENABLEDest l'action principale qu'une sous-classeDeviceAdminReceiverdoit gérer pour être autorisée à 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 cette opération dansonEnabled(). Pour être pris en charge, le récepteur doit également nécessiter l'autorisationBIND_DEVICE_ADMINafin que d'autres applications ne puissent pas l'utiliser de manière abusive.- Lorsqu'un utilisateur active l'application d'administration de l'appareil, cela donne au destinataire l'autorisation d'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 non conforme aux exigences de la règle, l'application peut l'inviter à choisir un autre mot de passe conforme aux exigences.
- Évitez de modifier le nom du récepteur après avoir publié votre application. Si le nom indiqué dans le fichier manifeste change, l'administrateur de l'appareil est désactivé lorsque les utilisateurs mettent à jour l'application. Pour en savoir plus, consultez
<receiver>. android:resource="@xml/device_admin_sample"déclare les règles 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 classeDeviceAdminInfo. Voici le contenu dedevice_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 une 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.
Pour en savoir plus sur le fichier manifeste, consultez le guide des développeurs Android.Implémenter le code
L'API Device Administration comprend les classes suivantes:
DeviceAdminReceiver- Classe de base permettant d'implémenter un composant d'administration d'appareils. Cette classe permet d'interpréter plus facilement les actions d'intent brut envoyées par le système. Votre application d'administration des appareils doit inclure une sous-classe
DeviceAdminReceiver. DevicePolicyManager- Classe permettant de gérer les règles appliquées à un appareil. La plupart des clients de cette classe doivent avoir publié un
DeviceAdminReceiverque l'utilisateur a actuellement activé. LeDevicePolicyManagergère les règles d'une ou de plusieurs instancesDeviceAdminReceiver. DeviceAdminInfo- Cette classe permet de spécifier des métadonnées pour 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 décrit 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 est constituée d'une série de rappels 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. Par 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 d'appareil doit gérer est l'activation de l'application par l'utilisateur. L'utilisateur doit l'activer explicitement pour que les règles soient appliquées. Si l'utilisateur choisit de ne pas activer l'application, celle-ci sera toujours présente sur l'appareil, mais ses règles ne seront pas appliquées et il 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'exemple d'application, cela se produit lorsque l'utilisateur clique sur la case Enable Admin (Activer l'administration).
Lorsque l'utilisateur clique sur la case à cocher Enable Admin (Activer l'administration), l'écran change pour inviter l'utilisateur à activer l'application d'administration de l'appareil, comme illustré dans 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 Enable Admin (Activer la fonctionnalité Admin). Cela a pour effet de déclencher le rappel onPreferenceChange(). Ce rappel est invoqué lorsque la valeur de ce Preference a été modifiée par l'utilisateur et qu'elle est sur le point d'être définie et/ou conservée. Si l'utilisateur active l'application, l'écran 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.
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 tout au long de l'ajout de 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() utilise un composant DeviceAdminReceiver 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 appliquées sur un appareil. DevicePolicyManager gère les règles d'une ou de plusieurs instances DeviceAdminReceiver.
Vous obtenez un handle vers le 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 des tâches administratives:
Définir des règles de 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:
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 correspondre à l'une des constantes DevicePolicyManager suivantes:
PASSWORD_QUALITY_ALPHABETIC- L'utilisateur doit saisir un mot de passe contenant au moins une lettre (ou un autre symbole).
PASSWORD_QUALITY_ALPHANUMERIC- L'utilisateur doit saisir un mot de passe contenant au moins à la fois des caractères numériques et des caractères 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 ce que c'est.
PASSWORD_QUALITY_UNSPECIFIED- La règle ne comporte aucune exigence concernant le mot de passe.
Par exemple, voici comment vous devez définir la stratégie 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 concernant le contenu des mots de passe
À partir d'Android 3.0, la classe DevicePolicyManager inclut des méthodes qui vous permettent d'affiner le contenu du mot de passe. 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'ajuster 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:
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 avoir au moins la longueur minimale spécifiée. Par 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 de saisie du mot de passe
Vous pouvez définir le nombre maximal autorisé de tentatives de saisie du mot de passe avant qu'il ne soit effacé (c'est-à-dire, en rétablissant la configuration d'usine). Par 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 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 en delta en millisecondes à partir du moment où l'administrateur de l'appareil définit le délai d'expiration. Par 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 le mot de passe en fonction de l'historique
À partir d'Android 3.0, vous pouvez utiliser la méthode setPasswordHistoryLength() pour empêcher 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 de nouveau mot de passe correspondant aux n derniers mots de passe. Cela empêche les utilisateurs d'utiliser le même mot de passe à l'infini. Cette règle est généralement utilisée conjointement avec setPasswordExpirationTimeout(), qui oblige les utilisateurs à mettre à jour leurs mots de passe après un certain temps.
Par exemple, cet extrait 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 d'inactivité maximale de l'utilisateur pouvant se produire avant le verrouillage de l'appareil. Par 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 l'appareil pour qu'il se verrouille immédiatement:
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. Cela est utile en cas de perte ou de vol de l'appareil. Souvent, la décision d'effacer les données de l'appareil est le résultat de certaines conditions. Par exemple, vous pouvez utiliser setMaximumFailedPasswordsForWipe() pour indiquer qu'un appareil doit être effacé après un nombre spécifique de tentatives de saisie du mot de passe infructueuses.
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 comme paramètre un masque de bits d'options supplémentaires. Actuellement, la valeur doit être égale à 0.
Désactiver l'appareil photo
À partir de la version 4.0 d'Android, vous pouvez désactiver la caméra. Notez qu'il ne doit pas nécessairement s'agir d'une désactivation permanente. Vous pouvez activer/désactiver la caméra de façon dynamique en fonction du contexte, de l'heure, etc.
Vous pouvez contrôler si l'appareil photo est désactivé à l'aide de la méthode setCameraDisabled(). Par exemple, l'extrait suivant définit l'activation ou la désactivation de la caméra 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 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, lorsqu'elle est disponible.
Par 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 voir 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.