Baja del administrador de dispositivos. A partir de Android 9 (nivel de API 28), algunas políticas de administración se marcarán como obsoletas cuando las invoque un administrador del dispositivo. Te recomendamos que comiences a prepararte ahora para este cambio. Para obtener más información y ver las opciones de migración, consulta Baja del administrador del dispositivo.
Android incluye asistencia para apps empresariales, ya que ofrece la API de administración de dispositivos Android. La API de administración de dispositivos proporciona funciones de administración de dispositivos a nivel del sistema. Estas APIs te permiten crear apps conscientes de la seguridad que son útiles en la configuración empresarial, en la que los profesionales de TI requieren un gran control sobre los dispositivos de los empleados. Por ejemplo, la app de correo electrónico para Android integrada ha aprovechado estas APIs para mejorar la asistencia de Exchange. A través de la app de correo electrónico, los administradores de Exchange pueden aplicar políticas de contraseña, incluidas contraseñas alfanuméricas o PIN numéricos, en todos los dispositivos. Los administradores también pueden limpiar de manera remota (es decir, restablecer los valores predeterminados de fábrica) los teléfonos perdidos o robados. Los usuarios de Exchange pueden sincronizar sus datos de correo electrónico y calendario.
Este documento está destinado a desarrolladores que deseen crear soluciones empresariales para dispositivos que ejecuten Android. Se analizan las diversas funciones proporcionadas por la API de administración de dispositivos para ofrecer una mayor seguridad para los dispositivos de los empleados con la tecnología de Android.
Nota: Para obtener información sobre cómo crear un controlador de políticas de trabajo para implementaciones de Android for Work, consulta Cómo crear un controlador de política de dispositivo.
Modo de propietario del dispositivo sin interfaz gráfica
Android 14 (nivel de API 34) presenta el modo de usuario del sistema sin cabeza (dispositivos en los que UserManager.isHeadlessSystemUserMode muestra true). En este modo, el usuario del sistema es un usuario en segundo plano y depende de usuarios en primer plano adicionales para la interacción del usuario final. Android 14 también presenta un modo afiliado de propietario de dispositivo sin cabeza, que agrega un propietario de perfil a todos los usuarios afiliados, excepto al usuario del sistema en el que se configura el propietario del dispositivo.
En los dispositivos configurados con un usuario del sistema sin cabeza (en el que el usuario del sistema se ejecuta en segundo plano), solo se aplican al usuario o usuarios en primer plano las políticas del dispositivo que tienen un alcance global (políticas que se aplican a todos los usuarios). Consulta addUserRestriction para obtener más información.
Los fabricantes de dispositivos Android pueden consultar la guía publicada en source.android.com.
Descripción general de la API de administración de dispositivos
Estos son ejemplos de los tipos de apps que podrían usar la API de administración de dispositivos:
- Clientes de correo electrónico
- Apps de seguridad que limpian de manera remota
- Servicios y apps de administración de dispositivos
¿Cómo funciona?
Usas la API de administración de dispositivos para escribir apps de administración que los usuarios instalan en sus dispositivos. La app de administración de dispositivos aplica las políticas deseadas. Funciona de la siguiente manera:
- Un administrador del sistema escribe una app de administración de dispositivos que aplica las políticas de seguridad de dispositivos remotos y locales. Estas políticas podrían estar codificadas en la app, o la app podría obtener de forma dinámica políticas de un servidor de terceros.
- La app se instala en los dispositivos de los usuarios. Actualmente, Android no tiene una solución de aprovisionamiento automatizado. Estas son algunas de las formas en que un administrador de sistemas podría distribuir la app a los usuarios:
- Mediante el uso de Google Play
- Mediante la habilitación de la instalación desde otra tienda
- Mediante la distribución de la app a través de otros medios, como correos electrónico o sitios web
- El sistema solicita al usuario que habilite la app de administración de dispositivos. La forma y el momento en que esto suceda dependerán de cómo se implemente la app.
- Cuando los usuarios habilitan la app de administración de dispositivos, están sujetos a sus políticas. Por lo general, el cumplimiento de esas políticas conlleva beneficios, como el acceso a sistemas y datos sensibles.
Si los usuarios no habilitan la app de administración de dispositivos, esta permanece en el dispositivo, pero en estado inactivo. Los usuarios no estarán sujetos a sus políticas y, por el contrario, no obtendrán ninguno de los beneficios de la app, por ejemplo, quizás no puedan sincronizar datos.
Si un usuario no cumple con las políticas (por ejemplo, establece una contraseña que infringe las pautas), la app puede decidir cómo procesarlo. Sin embargo, por lo general, esto provocará que el usuario no pueda sincronizar datos.
Si un dispositivo intenta conectarse a un servidor que requiere políticas no admitidas en la API de administración de dispositivos, no se permitirá la conexión. Actualmente, la API de administración de dispositivos no permite el aprovisionamiento parcial. En otras palabras, si un dispositivo (por ejemplo, uno heredado) no admite todas las políticas indicadas, no hay manera de permitir su conexión.
Si un dispositivo contiene varias apps de administración habilitadas, se aplica la política más estricta. No hay forma de segmentar una app de administración en particular.
Para desinstalar una app de administración de dispositivos existente, los usuarios deben cancelar el registro de la app como administrador.
Políticas
En una configuración empresarial, con frecuencia, los dispositivos de los empleados deben cumplir con un conjunto estricto de políticas que rigen el uso del dispositivo. La API de administración de dispositivos admite las políticas enumeradas en la Tabla 1. Ten en cuenta que la API de administración de dispositivos actualmente solo admite contraseñas para el bloqueo de pantalla:
Tabla 1: Políticas compatibles con la API de administración de dispositivos
| Política | Descripción |
|---|---|
| Contraseña habilitada | Requiere que los dispositivos soliciten PIN o contraseñas. |
| Longitud mínima de la contraseña | Establece la cantidad requerida de caracteres para la contraseña. Por ejemplo, puedes solicitar que el PIN o las contraseñas tengan seis caracteres como mínimo. |
| Se requiere contraseña alfanumérica | Se requiere que las contraseñas tengan una combinación de letras y números. Pueden incluir caracteres simbólicos. |
| Se requiere una contraseña compleja | Se requiere que las contraseñas contengan al menos una letra, un dígito numérico y un símbolo especial. Esta opción se introdujo en Android 3.0. |
| Se requiere una cantidad mínima de letras en la contraseña | La cantidad mínima de letras requeridas en la contraseña para todos los administradores o uno en particular. Esta opción se introdujo en Android 3.0. |
| Se requiere una cantidad mínima de letras minúsculas en la contraseña | La cantidad mínima de letras minúsculas requeridas en la contraseña para todos los administradores o uno en particular. Esta opción se introdujo en Android 3.0. |
| Se requiere una cantidad mínima de caracteres que no sean letras en la contraseña | La cantidad mínima de caracteres que no sean letras requeridos en la contraseña para todos los administradores o uno en particular. Esta opción se introdujo en Android 3.0. |
| Cantidad mínima de dígitos numéricos requeridos en la contraseña | La cantidad mínima de dígitos numéricos requeridos en la contraseña para todos los administradores o uno en particular. Esta opción se introdujo en Android 3.0. |
| Cantidad mínima de símbolos requeridos en la contraseña | La cantidad mínima de símbolos requeridos en la contraseña para todos los administradores o uno en particular. Esta opción se introdujo en Android 3.0. |
| Cantidad mínima de letras mayúsculas requeridas en la contraseña | La cantidad mínima de letras mayúsculas requeridas en la contraseña para todos los administradores o uno en particular. Esta opción se introdujo en Android 3.0. |
| Tiempo de espera de caducidad de la contraseña | Indica cuándo caducará la contraseña y se expresa como un delta en milisegundos desde que el administrador del dispositivo configura el tiempo de espera de caducidad. Esta opción se introdujo en Android 3.0. |
| Restricción del historial de contraseñas | Esta política impide que los usuarios vuelvan a usar las últimas n contraseñas únicas.
Por lo general, esta política se usa junto con setPasswordExpirationTimeout(), lo que obliga a los usuarios a actualizar sus contraseñas después de transcurrido un período de tiempo especificado.
Esta opción se introdujo en Android 3.0. |
| Intentos máximos de contraseña fallida | Especifica cuántas veces un usuario puede ingresar una contraseña incorrecta antes de que el dispositivo limpie sus datos. La API de administración de dispositivos también permite que los administradores restablezcan el dispositivo de forma remota a los valores predeterminados de fábrica. Esto protege los datos en caso de pérdida o robo del dispositivo. |
| Tiempo máximo de bloqueo por inactividad | Configura el período de tiempo desde la última vez que el usuario tocó la pantalla o presionó un botón antes de que el dispositivo bloquee la pantalla. Cuando esto sucede, los usuarios deben ingresar su PIN o contraseñas nuevamente antes de poder usar sus dispositivos y acceder a los datos. El valor puede ser de entre 1 y 60 minutos. |
| Encriptación de almacenamiento obligatoria | Especifica que el área de almacenamiento se debe encriptar, si el dispositivo lo admite. Esta opción se introdujo en Android 3.0. |
| Inhabilitar cámara | Especifica que la cámara debe estar inhabilitada. Ten en cuenta que no es necesario que sea una inhabilitación permanente. La cámara se puede habilitar o inhabilitar de forma dinámica según el contexto, el momento, etc. Esta opción se introdujo en Android 4.0. |
Otras funciones
Además de admitir las políticas enumeradas en la tabla anterior, la API de administración de dispositivos te permite hacer lo siguiente:
- Solicitar al usuario que configure una nueva contraseña
- Bloquear el dispositivo de inmediato
- Limpiar los datos del dispositivo (es decir, restablecer los valores predeterminados de fábrica del dispositivo)
App de ejemplo
Los ejemplos que se usan en esta página se basan en la muestra de la API de administración de dispositivos, que se incluye en las muestras de SDK (disponibles a través de Android SDK Manager) y se encuentra en tu sistema como <sdk_root>/ApiDemos/app/src/main/java/com/example/android/apis/app/DeviceAdminSample.java.
La app de muestra ofrece una demostración de las funciones de administración de dispositivos. Presenta a los usuarios una interfaz de usuario que les permite habilitar la app de administración de dispositivos. Cuando hayan habilitado la app, podrán usar los botones de la interfaz de usuario para hacer lo siguiente:
- Configurar la calidad de la contraseña
- Especificar los requisitos para la contraseña del usuario, como la longitud mínima, la cantidad mínima de caracteres numéricos que debe contener, etc.
- Configurar la contraseña. Si la contraseña no cumple con las políticas especificadas, el sistema muestra un error.
- Establece cuántos intentos fallidos de contraseña pueden ocurrir antes de que el dispositivo se limpie (es decir, se restablezca a la configuración de fábrica).
- Establecer cuándo caducará la contraseña
- Establecer la longitud del historial de contraseñas (la longitud se refiere a la cantidad de contraseñas antiguas almacenadas en el historial). Esto evita que los usuarios vuelvan a usar una de las n últimas contraseñas que usaron anteriormente.
- Especificar que el área de almacenamiento debe estar encriptada, si el dispositivo lo admite
- Establece la cantidad máxima de tiempo de inactividad que puede transcurrir antes de que el dispositivo se bloquee.
- Hacer que el dispositivo se bloquee de inmediato
- Limpiar los datos del dispositivo (es decir, restablecer la configuración de fábrica)
- Inhabilitar la cámara
Figura 1: Captura de pantalla de la app de muestra
Cómo desarrollar una app de administración de dispositivos
Los administradores de sistemas pueden usar la API de administración de dispositivos para escribir una app que cumpla con la aplicación de la política de seguridad del dispositivo remoto o local. En esta sección, se resumen los pasos necesarios para crear una app de administración de dispositivos.
Cómo crear el manifiesto
Para usar la API de administración de dispositivos, el manifiesto de la app debe incluir lo siguiente:
- Una subclase de
DeviceAdminReceiverque incluya lo siguiente:- El permiso
BIND_DEVICE_ADMIN. - La capacidad de responder al intent
ACTION_DEVICE_ADMIN_ENABLED, expresada en el manifiesto como un filtro de intents
- El permiso
- Una declaración de las políticas de seguridad que se usan en los metadatos
Aquí hay un extracto del manifiesto de muestra de la administración de dispositivos:
<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>
Ten en cuenta lo siguiente:
- Los siguientes atributos se refieren a los recursos de cadenas que residen en
ApiDemos/res/values/strings.xmlpara la app de ejemplo. Para obtener más información sobre los recursos, consulta Recursos para aplicaciones.android:label="@string/activity_sample_device_admin"se refiere a la etiqueta legible por el usuario para la actividad.android:label="@string/sample_device_admin"se refiere a la etiqueta legible por el usuario para el permiso.android:description="@string/sample_device_admin_description"se refiere a la descripción legible por el usuario del permiso. Por lo general, una descripción es más larga y más informativa que una etiqueta.
android:permission="android.permission.BIND_DEVICE_ADMIN"es un permiso que debe tener una subclaseDeviceAdminReceiverpara garantizar que solo el sistema pueda interactuar con el receptor (ninguna app puede obtener este permiso). Esto evita que otras apps abusen de tu app de administración de dispositivos.android.app.action.DEVICE_ADMIN_ENABLEDes la acción principal que debe procesar una subclaseDeviceAdminReceiverpara poder administrar un dispositivo. Se configura en el receptor cuando el usuario habilita la app de administración de dispositivos. Por lo general, tu código controla esto enonEnabled(). Para ser admitido, el receptor también debe requerir el permisoBIND_DEVICE_ADMINpara que otras apps no puedan abusar de él.- Cuando un usuario habilita la app de administración de dispositivos, eso le da permiso al receptor para realizar acciones en respuesta a la transmisión de eventos particulares del sistema. Cuando surge un evento adecuado, la app puede imponer una política. Por ejemplo, si el usuario intenta establecer una nueva contraseña que no cumple con los requisitos de la política, la app puede solicitarle al usuario que elija otra contraseña que cumpla con los requisitos.
- Evita cambiar el nombre del receptor después de publicar tu app. Si el nombre del manifiesto cambia, el administrador de dispositivos se inhabilita cuando los usuarios actualizan la app. Para obtener más información, consulta
<receiver>. android:resource="@xml/device_admin_sample"declara las políticas de seguridad que se usan en los metadatos. Los metadatos proporcionan información adicional específica para el administrador de dispositivos, según el análisis de la claseDeviceAdminInfo. Estos son los contenidos 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>
Cuando diseñes tu app de administración de dispositivos, no necesitas incluir todas las políticas, solo las que sean relevantes para tu app.
Para obtener más información sobre el archivo de manifiesto, consulta la Guía para desarrolladores de Android.Cómo implementar el código
La API de administración de dispositivos incluye las siguientes clases:
DeviceAdminReceiver- Clase base para implementar un componente de administración de dispositivos. Esta clase proporciona una conveniencia para interpretar las acciones de intents sin procesar que envía el sistema. La app de administración de dispositivos debe incluir una subclase
DeviceAdminReceiver. DevicePolicyManager- Una clase para administrar las políticas aplicadas en un dispositivo. La mayoría de los clientes de esta clase deben haber publicado un
DeviceAdminReceiverque el usuario tenga habilitado actualmente. ElDevicePolicyManageradministra las políticas de una o más instanciasDeviceAdminReceiver.
DeviceAdminInfo- Esta clase se usa para especificar los metadatos de un componente de administrador de dispositivos.
Estas clases proporcionan la base para una app de administración de dispositivos completamente funcional. En el resto de esta sección, se describe cómo debes usar las APIs DeviceAdminReceiver y DevicePolicyManager para escribir una app de administración de dispositivos.
Cómo subclasificar DeviceAdminReceiver
Para crear una app de administración de dispositivos, debes crear la subclase DeviceAdminReceiver. La clase DeviceAdminReceiver consiste en una serie de devoluciones de llamadas que se activan cuando ocurren eventos particulares.
En su subclase DeviceAdminReceiver, la app de ejemplo simplemente muestra una notificación Toast en respuesta a eventos particulares. Por ejemplo:
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));
}
...
}
Cómo habilitar la app
Uno de los eventos principales que debe controlar una app de administrador de dispositivos es que el usuario habilite la app. El usuario debe habilitar la app de forma explícita para que se apliquen las políticas. Si el usuario decide no habilitar la app, seguirá presente en el dispositivo, pero sus políticas no se aplicarán y el usuario no obtendrá ninguno de los beneficios de la app.
El proceso de habilitar la app comienza cuando el usuario realiza una acción que activa el intent ACTION_ADD_DEVICE_ADMIN. En la app de ejemplo, esto sucede cuando el usuario hace clic en la casilla de verificación Habilitar administrador.
Cuando el usuario hace clic en la casilla de verificación Habilitar administrador, la pantalla cambia para solicitarle que active la app de administración de dispositivos, como se muestra en la Figura 2.
Figura 2: App de muestra: activación de la app
A continuación, se muestra el código que se ejecuta cuando el usuario hace clic en la casilla de verificación Habilitar administrador. Esto tiene el efecto de activar la devolución de llamada de onPreferenceChange(). Esta devolución de llamada se invoca cuando el usuario cambia el valor de este Preference y está a punto de configurarlo o conservarlo. Si el usuario habilita la app, la pantalla cambia para solicitarle que active la app de administración de dispositivos, como se muestra en la Figura 2. De lo contrario, se inhabilita la app de administración de dispositivos.
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 línea intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN,
mDeviceAdminSample) indica que mDeviceAdminSample (que es un componente DeviceAdminReceiver) es la política de destino.
Esta línea invoca la interfaz de usuario que se muestra en la Figura 2, que guía a los usuarios a través de la adición del administrador de dispositivos al sistema (o les permite rechazarlo).
Cuando la app necesita realizar una operación que depende de que la app de administración de dispositivos esté habilitada, confirma que la app esté activa. Para ello, usa isAdminActive() del método DevicePolicyManager. Observa que isAdminActive() del método DevicePolicyManager toma un componente DeviceAdminReceiver como su argumento:
Kotlin
private lateinit var dpm: DevicePolicyManager ... private fun isActiveAdmin(): Boolean = dpm.isAdminActive(deviceAdminSample)
Java
DevicePolicyManager dpm;
...
private boolean isActiveAdmin() {
return dpm.isAdminActive(deviceAdminSample);
}
Administración de políticas
DevicePolicyManager es una clase pública para administrar políticas aplicadas en un dispositivo. DevicePolicyManager administra las políticas para una o más instancias DeviceAdminReceiver.
Obtienes un controlador para el DevicePolicyManager de la siguiente manera:
Kotlin
dpm = getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager
Java
DevicePolicyManager dpm =
(DevicePolicyManager)getSystemService(Context.DEVICE_POLICY_SERVICE);
En esta sección, se describe cómo usar DevicePolicyManager para realizar tareas administrativas:
- Cómo configurar políticas de contraseña
- Configurar el bloqueo del dispositivo
- Realizar limpieza de datos
Cómo configurar las políticas de contraseña
DevicePolicyManager incluye APIs para configurar y hacer cumplir la política de contraseña del dispositivo. En la API de administración de dispositivos, la contraseña solo se aplica al bloqueo de pantalla. En esta sección, se describen tareas comunes relacionadas con la contraseña.
Cómo configurar una contraseña para el dispositivo
En este código, se muestra una interfaz del usuario que le solicita que configure una contraseña:
Kotlin
Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD).also { intent ->
startActivity(intent)
}
Java
Intent intent = new Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD); startActivity(intent);
Cómo configurar la calidad de la contraseña
La calidad de la contraseña puede ser una de las siguientes constantes DevicePolicyManager:
PASSWORD_QUALITY_ALPHABETIC- El usuario debe ingresar una contraseña que contenga, como mínimo, caracteres alfabéticos (u otros símbolos).
PASSWORD_QUALITY_ALPHANUMERIC- El usuario debe ingresar una contraseña que contenga, como mínimo, tanto caracteres numéricos como alfabéticos (u otros símbolos).
PASSWORD_QUALITY_NUMERIC- El usuario debe ingresar una contraseña que contenga, como mínimo, caracteres numéricos.
PASSWORD_QUALITY_COMPLEX- El usuario debe haber ingresado una contraseña que contenga, como mínimo, una letra, un dígito numérico y un símbolo especial.
PASSWORD_QUALITY_SOMETHING- La política requiere algún tipo de contraseña, pero no le importa cuál sea.
PASSWORD_QUALITY_UNSPECIFIED- La política no tiene requisitos para la contraseña.
Por ejemplo, de esta forma debes configurar la política de contraseñas para que requiera una contraseña alfanumérica:
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);
Cómo configurar los requisitos de contenido de contraseña
A partir de Android 3.0, la clase DevicePolicyManager incluye métodos que te permiten ajustar el contenido de la contraseña. Por ejemplo, puedes configurar una política que establezca que las contraseñas deben contener, como mínimo, n letras mayúsculas. Estos son los métodos para ajustar el contenido de una contraseña:
setPasswordMinimumLetters()setPasswordMinimumLowerCase()setPasswordMinimumUpperCase()setPasswordMinimumNonLetter()setPasswordMinimumNumeric()setPasswordMinimumSymbols()
Por ejemplo, en este fragmento, se indica que la contraseña debe tener, como mínimo, 2 letras mayúsculas:
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);
Cómo configurar la longitud mínima de la contraseña
Puedes especificar que una contraseña debe tener al menos la longitud mínima especificada. Por ejemplo:
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);
Cómo configurar la cantidad máxima de intentos de contraseña fallidos
Puedes configurar la cantidad máxima permitida de intentos fallidos de contraseña antes de limpiar el dispositivo (es decir, restablecer la configuración de fábrica). Por ejemplo:
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);
Cómo configurar el tiempo de espera de caducidad de contraseña
A partir de Android 3.0, puedes usar el método setPasswordExpirationTimeout() para configurar cuándo caducará una contraseña, expresado como un delta en milisegundos desde que el administrador del dispositivo configura el tiempo de espera de caducidad. Por ejemplo:
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);
Cómo restringir la contraseña en base al historial
A partir de Android 3.0, puedes usar el método setPasswordHistoryLength() para limitar la habilidad de los usuarios de volver a usar contraseñas antiguas. Este método toma un parámetro de longitud que especifica cuántas contraseñas antiguas se almacenan. Cuando esta política está activa, los usuarios no pueden ingresar una nueva contraseña que coincida con las últimas n contraseñas. Esto evita que los usuarios usen la misma contraseña una y otra vez. Por lo general, esta política se usa junto con setPasswordExpirationTimeout(), lo que obliga a los usuarios a actualizar sus contraseñas después de transcurrido un período de tiempo especificado.
Por ejemplo, en este fragmento se prohíbe a los usuarios volver a usar cualquiera de sus últimas 5 contraseñas:
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);
Cómo configurar el bloqueo del dispositivo
Puedes configurar el período máximo de inactividad del usuario que puede ocurrir antes de que el dispositivo se bloquee. Por ejemplo:
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);
También puedes indicarle de forma programática que el dispositivo se bloquee de inmediato:
Kotlin
private lateinit var dpm: DevicePolicyManager dpm.lockNow()
Java
DevicePolicyManager dpm; dpm.lockNow();
Cómo realizar la limpieza de datos
Puedes usar wipeData() del método DevicePolicyManager para restablecer la configuración de fábrica del dispositivo. Esto es útil si el dispositivo se pierde o lo roban. A menudo, la decisión de limpiar el dispositivo es el resultado del cumplimiento de ciertas condiciones. Por ejemplo, puedes usar setMaximumFailedPasswordsForWipe() para indicar que un dispositivo se debe limpiar después de una cantidad específica de intentos fallidos para ingresar la contraseña.
Limpias los datos de la siguiente manera:
Kotlin
private lateinit var dpm: DevicePolicyManager dpm.wipeData(0)
Java
DevicePolicyManager dpm; dpm.wipeData(0);
El método wipeData() toma como parámetro una máscara de bits de opciones adicionales. Actualmente, el valor debe ser 0.
Inhabilitar la cámara
A partir de Android 4.0, puedes inhabilitar la cámara. Ten en cuenta que no es necesario que sea una inhabilitación permanente. La cámara se puede habilitar o inhabilitar de forma dinámica en función del contexto, el momento, etc.
Para controlar si la cámara está inhabilitada, usa el método setCameraDisabled(). Por ejemplo, en este fragmento se establece que la cámara se habilite o inhabilite en función de la configuración de una casilla de verificación:
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());
Encriptación de almacenamiento
A partir de Android 3.0, puedes usar el método setStorageEncryption() para configurar una política que requiera la encriptación del área de almacenamiento, cuando sea compatible.
Por ejemplo:
Kotlin
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName ... dpm.setStorageEncryption(deviceAdminSample, true)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; ... dpm.setStorageEncryption(deviceAdminSample, true);
Consulta la muestra de la API de administración de dispositivos para obtener un ejemplo completo de cómo habilitar la encriptación de almacenamiento.
Muestras de código adicionales
Los ejemplos de AppRestrictionEnforcer de Android y DeviceOwner demuestran aún más el uso de las APIs que se abordan en esta página.