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 invocada por un administrador de dispositivos. Te recomendamos que comiences a prepararte ahora para este cambio. Para aprender más para ver las opciones de migración, lee Baja del administrador de dispositivos.
Android es compatible con apps empresariales, ya que ofrece API de administración de dispositivos Android La API de administración de dispositivos brinda de administración de identidades y accesos a nivel del sistema. Estas APIs te permiten crear de seguridad en la nube que son útiles en entornos empresariales, en los que los equipos de TI profesionales requieren un amplio control sobre los dispositivos de los empleados. Por ejemplo, el app de correo electrónico de Android aprovechó estas APIs para mejorar Compatibilidad con Exchange. Con la aplicación Correo, los administradores de Exchange pueden aplicar políticas de contraseñas, incluidas contraseñas alfanuméricas PINs en todos los dispositivos Los administradores también pueden limpiar de manera remota (es decir, restablecer los valores predeterminados de fábrica) de teléfonos perdidos o robados. Los usuarios de Exchange pueden sincronizar su correo electrónico y sus datos de calendario.
Este documento está dirigido a desarrolladores que deseen desarrollar soluciones para dispositivos con Android. Se analizan las diversas funciones que proporciona la API de administración de dispositivos para brindar mayor seguridad a dispositivos para empleados con tecnología Android.
Nota: Para obtener información sobre cómo crear una política de trabajo, haz lo siguiente: Controlador para implementaciones de Android for Work, consulta Crea un controlador de política de dispositivo.
Modo de propietario de dispositivo sin interfaz gráfica
Android 14 (nivel de API 34) incorpora el modo de usuario del sistema sin interfaz gráfica (dispositivos en
cuál
UserManager.isHeadlessSystemUserMode
muestra true). En el modo de usuario del sistema sin interfaz gráfica, el usuario del sistema es un
usuario en segundo plano y depende de usuarios adicionales en primer plano para el usuario final
interacción. En Android 14, también se incluye
modo afiliado de propietario de dispositivo sin interfaz gráfica,
lo que agrega un propietario de perfil a todos
usuarios afiliados
que no sea el usuario del sistema en el que está configurado el propietario del dispositivo.
En dispositivos configurados con un usuario del sistema sin interfaz gráfica (en los que el usuario del sistema
se ejecuta en segundo plano), solo las políticas de dispositivo que tienen un alcance global
(políticas que se aplican a todos los usuarios) se aplican al usuario en primer plano.
o usuarios. Consulta
addUserRestriction
para conocer los detalles.
Los fabricantes de dispositivos Android pueden consultar el orientación publicado 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 de dispositivos que los usuarios instalar en sus dispositivos. La app de administración de dispositivos aplica y políticas de seguridad. Funciona de la siguiente manera:
- Un administrador del sistema escribe una app de administración de dispositivos que aplica de seguridad de dispositivos remotos/locales. Estas políticas podrían estar hard-coded la aplicación, o la aplicación puede recuperar políticas de un tercero de forma dinámica. servidor.
- La app se instala en los dispositivos de los usuarios. Android
que actualmente no tienen
una solución de aprovisionamiento automatizado. Algunas formas en que un administrador del sistema
distribuir la app a los usuarios son las siguientes:
- 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 le solicita al usuario que habilite la app de administración de dispositivos. Cómo y cuándo sucede esto depende de cómo se implementa la app.
- Una vez que los usuarios habiliten la app de administración de dispositivos, estarán sujetos a sus políticas. Por lo general, cumplir con esas políticas conlleva beneficios, como los siguientes: 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, si establece una una contraseña que infrinja los lineamientos), depende de la aplicación decidir cómo manejar esto. Sin embargo, esto normalmente no hará que el usuario sea sincronizar datos.
Si un dispositivo intenta conectarse a un servidor que requiere políticas compatibles con la API de administración de dispositivos, la conexión no de los usuarios. Por el momento, la API de administración de dispositivos no permite de servicios. En otras palabras, si un dispositivo (por ejemplo, un dispositivo heredado) no no admiten todas las políticas indicadas, no hay forma de permitir que que el dispositivo se conecte.
Si un dispositivo contiene varias apps de administración habilitadas, la política más estricta es de manera forzosa. No hay forma de orientarse a un administrador en particular .
Para desinstalar una app de administración de dispositivos existente, los usuarios deben hacer lo siguiente: primero debes cancelar el registro de la app como administrador.
Políticas
En un entorno empresarial, los dispositivos de los empleados cumplir con un estricto conjunto de políticas que rigen el uso del dispositivo. El La API de administración de dispositivos admite las políticas enumeradas en la Tabla 1. Ten en cuenta que, actualmente, la API de administración de dispositivos solo admite contraseñas para la bloqueo:
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, puede exigir que el PIN o las contraseñas tengan al menos seis caracteres. |
| Se requiere contraseña alfanumérica | Requiere que las contraseñas tengan un 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 de todos los administradores o de 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 minúsculas letras requeridas en la contraseña de todos los administradores o de 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 y que se requieren 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(), que fuerza
que los usuarios actualicen sus contraseñas luego de que haya transcurrido un período determinado.
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 del cuando el dispositivo limpia sus datos. La API de administración de dispositivos también permite a los administradores restablecer de forma remota la configuración de fábrica del dispositivo. Esto protege los datos en caso de que el si pierdes el dispositivo o te lo roban. |
| Tiempo máximo de bloqueo por inactividad | Establece el tiempo transcurrido desde que el usuario tocó la pantalla por última vez. presionaste un botón antes de que el dispositivo bloquee la pantalla. Cuando esto sucede, los usuarios deberá ingresar su PIN o contraseña 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 se requiere sea una inhabilitación permanente. La cámara se puede habilitar o inhabilitar de manera dinámica según el contexto, el tiempo, etcétera. Esta opción se introdujo en Android 4.0. |
Otras funciones
Además de cumplir con las políticas mencionadas en la tabla anterior, el dispositivo La API de Administration 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 API de administración de dispositivos
de muestra, que se incluye en las muestras de SDK (disponible a través del
Android SDK Manager) y se encuentran 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 con una interfaz de usuario que le permite habilitar la app de administración de dispositivos. Una vez habilitó la aplicación, puede usar los botones de la interfaz de usuario para lo siguiente:
- Configurar la calidad de la contraseña
- Especificar los requisitos de la contraseña del usuario, como longitud mínima, la cantidad mínima de caracteres numéricos que debe contener, y así sucesivamente.
- Configurar la contraseña. Si la contraseña no cumple con los requisitos políticas, el sistema muestra un error.
- Establece cuántos intentos de contraseña fallidos pueden ocurrir antes de que se limpie el dispositivo. (es decir, restablecido 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 reutilicen una de las últimas n 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 cerraduras.
- 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 del sistema pueden usar la API de administración de dispositivos para escribir una app que aplique la aplicación de la política de seguridad de dispositivos remotos/locales. Esta sección se resumen los pasos para crear una administración de dispositivos .
Cómo crear el manifiesto
Para usar la API de administración de dispositivos, la cuenta de servicio del manifiesto debe incluir lo siguiente:
- Una subclase de
DeviceAdminReceiverque incluya lo siguiente:- El permiso
BIND_DEVICE_ADMIN. - La capacidad de responder a
ACTION_DEVICE_ADMIN_ENABLEDexpresada 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 la app de ejemplo.
ApiDemos/res/values/strings.xmlPara obtener más información sobre los recursos, consulta Recursos para aplicacionesandroid:label="@string/activity_sample_device_admin"se refiere a la etiqueta de la actividad legible por el usuario.android:label="@string/sample_device_admin"se refiere a la etiqueta legible por el usuario del permiso.android:description="@string/sample_device_admin_description"hace referencia a es la descripción legible por el usuario del permiso. Una descripción suele ser más larga y más informativo que una etiqueta.
android:permission="android.permission.BIND_DEVICE_ADMIN"es un permiso que debe cumplir una subclaseDeviceAdminReceiverpara garantizar que solo el sistema pueda interactuar con el receptor (ninguna app puede obtener este permiso). Esta evita que otras apps abusen de tu app de administración de dispositivos.android.app.action.DEVICE_ADMIN_ENABLEDes el método principal acción que debe controlar una subclaseDeviceAdminReceiverpara que se pueda pueden administrar un dispositivo. Se establece en el receptor cuando el usuario habilita la app de administración de dispositivos. Por lo general, tu código se encarga de estoonEnabled()Para que sea compatible, el receptor también debe requieren el permisoBIND_DEVICE_ADMINpara que otras apps no se puede abusar de él.- Cuando un usuario habilita la app de administración de dispositivos, el receptor permiso para realizar acciones en respuesta a la transmisión de un sistema determinado eventos. Cuando surge un evento adecuado, la app puede imponer una política. Para ejemplo, si el usuario intenta establecer una nueva contraseña que no cumple con la política la app puede pedirle al usuario que elija una contraseña diferente que cumpla con los requisitos.
- Evita cambiar el nombre del receptor después de publicar tu app. Si el nombre en el
en el manifiesto, se inhabilita el administrador del dispositivo cuando los usuarios actualizan la aplicación. 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 brindan información específica del administrador de dispositivos, según el análisis de la claseDeviceAdminInfoEste es el contenido 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ñas tu app de administración de dispositivos, no necesitas incluya todas las políticas, solo las que sean relevantes para su aplicación.
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 intent sin procesar que envía el
en un sistema de archivos. Tu app de administración de dispositivos debe incluir una
la subclase
DeviceAdminReceiver. DevicePolicyManager- Una clase para administrar las políticas aplicadas en un dispositivo. La mayoría de los clientes de
esta clase debe haber publicado un
DeviceAdminReceiverque el usuario tiene habilitado actualmente. ElDevicePolicyManageradministra políticas para una o más instancias deDeviceAdminReceiver DeviceAdminInfo- Esta clase se usa para especificar metadatos para 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 usar DeviceAdminReceiver y
APIs de 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 una subclase
DeviceAdminReceiver La clase DeviceAdminReceiver
consiste en una serie de devoluciones de llamada que se activan cuando eventos determinados
de que ocurran cambios.
En su subclase DeviceAdminReceiver, la app de ejemplo
solo muestra una notificación Toast en respuesta a un
eventos. 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 más importantes que debe controlar una app de administración habilitando la app. El usuario debe habilitar explícitamente la app para las políticas que se deben aplicar. Si el usuario elige no habilitar la app esta seguirá presente en el dispositivo, pero sus políticas no se aplicarán de manera forzosa y el usuario no obtener cualquiera de los beneficios de la aplicación.
El proceso de habilitar la app comienza cuando el usuario realiza una
acción que activa el ACTION_ADD_DEVICE_ADMIN
. En la
app de ejemplo, esto sucede cuando el usuario hace clic en el botón Habilitar
Admin.
Cuando el usuario hace clic en la casilla de verificación Habilitar administrador, cambios para solicitar al usuario 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
onPreferenceChange()
devolución de llamada. 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
cambios para solicitar al usuario 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
agregar al administrador del dispositivo al sistema (o permitirle rechazarlo).
Cuando la app necesita realizar una operación que depende de la
de administración del dispositivo habilitada, confirma que la app
activo. Para ello, usa el método DevicePolicyManager.
isAdminActive() Ten en cuenta que DevicePolicyManager
el método isAdminActive() toma un 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.
de manera forzosa en un dispositivo. DevicePolicyManager administra las políticas de una
o más instancias de 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 aplicar las
política de contraseñas del dispositivo. En la API de administración de dispositivos, la contraseña solo se aplica a
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 un contraseña que contenga, al menos, caracteres alfabéticos (o cualquier otro símbolo).
PASSWORD_QUALITY_ALPHANUMERIC- El usuario debe ingresar un contraseña que contenga al menos tanto caracteres numéricos como alfabéticos (o otros símbolos).
PASSWORD_QUALITY_NUMERIC- El usuario debe ingresar una contraseña Debe contener al menos caracteres numéricos.
PASSWORD_QUALITY_COMPLEX- El usuario debe haber ingresado una contraseña que contenga al menos una letra, un dígito numérico y un símbolo especial.
PASSWORD_QUALITY_SOMETHING- El esta política requiere algún tipo de la contraseña, pero no le importa cuál es.
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. Para
Por ejemplo, podrías establecer una política que establezca que las contraseñas deben contener al menos
n letras mayúsculas. Estos son los métodos para ajustar la contraseña
contenidos:
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 el mínimo especificado del conjunto de datos. 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 establecer la cantidad máxima permitida de intentos para ingresar la contraseña antes del se limpió el dispositivo (es decir, se 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 la
setPasswordExpirationTimeout()
método para establecer el vencimiento de una contraseña, expresado como un delta en milisegundos desde que el administrador del dispositivo configura el tiempo de espera de vencimiento. 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 la
setPasswordHistoryLength()
para restringir las interacciones de los usuarios
capacidad de reutilizar contraseñas anteriores. Este método toma una length
que especifica la cantidad de antigüedad
que almacenan las contraseñas. Si esta política está activa, los usuarios no pueden ingresar un nuevo
que coincida con las últimas n contraseñas. Esto evita
que los usuarios usen la misma contraseña una y otra vez. Esta política suele usarse
junto con
setPasswordExpirationTimeout(),
lo que obliga a los usuarios
que actualicen sus contraseñas luego de que haya transcurrido un período determinado.
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 establecer el período máximo de inactividad del usuario que puede ocurrir antes de que bloqueos del dispositivo. 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 el método DevicePolicyManager
wipeData() para restablecer la configuración de fábrica. Esta información es útil
en caso de pérdida o robo del dispositivo. Con frecuencia, la decisión de limpiar el dispositivo es la
resultado del cumplimiento de ciertas condiciones. Por ejemplo, puedes usar
setMaximumFailedPasswordsForWipe() para indicar que se debe
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 su
parámetro de configuración es una máscara binaria 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.
Puedes controlar si la cámara está inhabilitada con el
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 la
setStorageEncryption()
para establecer una política que requiera la encriptación del área de almacenamiento, si es 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 el ejemplo de la API de administración de dispositivos para ver un ejemplo completo de cómo habilitar la encriptación de almacenamiento.
Muestras de código adicionales
Android AppRestrictionEnforcer y DeviceOwner Las muestras también muestran el uso de las APIs que se abordan en esta página.