En esta guía para desarrolladores, se explica cómo el controlador de política de dispositivo (DPC) administrar las actualizaciones del sistema Android en nombre del usuario del dispositivo.
Introducción
Los dispositivos Android pueden recibir e instalar actualizaciones inalámbricas del sistema. y software de aplicaciones. Android notifica al usuario del dispositivo que una actualización del sistema está disponible y el usuario del dispositivo puede instalar la actualización de inmediato o más tarde.
Mediante tu DPC, un administrador de TI puede administrar las actualizaciones del sistema para el usuario del dispositivo. Los DPCs pueden ser propietarios de un dispositivo completamente administrado (llamado propietario del dispositivo) o de un perfil de trabajo (llamado propietario del perfil). En la tabla 1, se muestra cómo los propietarios de dispositivos pueden administrar el sistema actualizaciones, mientras que los propietarios de perfiles solo pueden enviar información sobre las actualizaciones del sistema.
Tabla 1: Las tareas disponibles para los DPC dependen del modo de propietario
Cómo buscar actualizaciones pendientes
Una actualización pendiente es una actualización del sistema para un dispositivo que aún no se instaló. El DPC puede ayudar a los administradores de TI a verificar qué dispositivos tienen actualizaciones del sistema pendientes y, tal vez, pedirles a los usuarios que instalen las actualizaciones críticas de inmediato.
Propietarios de dispositivos y perfiles que ejecutan Android 8.0 (nivel de API 26) o versiones posteriores
puede comprobar si un dispositivo tiene una actualización del sistema pendiente. Llamada
DevicePolicyManager.getPendingSystemUpdate()
que muestra null
si el dispositivo está actualizado. Si hay una actualización del sistema pendiente,
el método devuelve información sobre la actualización.
Más información sobre una actualización pendiente
Después de llamar a getPendingSystemUpdate()
, puedes inspeccionar los datos
El valor de SystemUpdateInfo
para obtener más información sobre la actualización pendiente. En el siguiente ejemplo, se muestra cómo puedes averiguar cuándo una actualización pendiente estuvo disponible por primera vez para el dispositivo:
Kotlin
val firstAvailable = dpm.getPendingSystemUpdate(adminName)?.receivedTime firstAvailable?.let { Log.i(TAG, "Update first available: ${Date(firstAvailable)}") }
Java
SystemUpdateInfo updateInfo = dpm.getPendingSystemUpdate(adminName); if (updateInfo != null) { Long firstAvailable = updateInfo.getReceivedTime(); Log.i(TAG, "Update first available: " + new Date(firstAvailable)); }
Devoluciones de llamada del sistema
Cuando hay una actualización disponible, el sistema Android notifica a los propietarios del dispositivo sobre la nueva actualización. En Android 8.0 o versiones posteriores, el sistema también notifica a los propietarios de los perfiles.
En la subclase DeviceAdminReceiver
, anula la devolución de llamada onSystemUpdatePending()
. No es necesario que registres ni promociones tu DPC para recibir la devolución de llamada. Es posible que el sistemallame a este método más de una vez para una sola actualización, por lo que debes verificar el estado de la actualización antes de responder. Llama a getPendingSystemUpdate()
para obtener más información sobre la actualización del sistema en la devolución de llamada. En el siguiente ejemplo, se muestra cómo puedes hacerlo:
Kotlin
/** * Called when a new update is available. */ override fun onSystemUpdatePending(context: Context?, intent: Intent?, receivedTime: Long) { // System update information is supported in API level 26 or higher. if (Build.VERSION.SDK_INT < Build.VERSION_CODES.O) { return } val updateInfo = getManager(context) .getPendingSystemUpdate(getWho(context)) ?: return if (updateInfo.securityPatchState == SystemUpdateInfo.SECURITY_PATCH_STATE_TRUE) { // Perhaps install because this is a security patch. // ... } }
Java
/** * Called when a new update is available. */ public void onSystemUpdatePending (Context context, Intent intent, long receivedTime) { // System update information is supported in API level 26 or higher. if (Build.VERSION.SDK_INT < Build.VERSION_CODES.O) { return; } SystemUpdateInfo updateInfo = getManager(context) .getPendingSystemUpdate(getWho(context)); if (updateInfo == null) { return; } if (updateInfo.getSecurityPatchState() == SystemUpdateInfo.SECURITY_PATCH_STATE_TRUE) { // Perhaps install because this is a security patch. // ... } }
Cuando un sistema tiene más de un DPC, por ejemplo, perfiles de trabajo en entornos el propietario del dispositivo y del perfil recibirán la devolución de llamada.
Actualizar políticas
El propietario de un dispositivo puede configurar un sistema local para controlar cuándo se instalan las actualizaciones. política de actualización de un dispositivo. La política de actualización del sistema puede ser de uno de estos tres tipos:
- Automático
- Instala actualizaciones del sistema en cuanto se instalan disponibles (sin interacción del usuario). Si estableces este tipo de política, se instalarán inmediatamente las actualizaciones pendientes. que podrían posponerse o esperar un período de mantenimiento.
- Con ventanas
- Instala actualizaciones del sistema durante un mantenimiento diario (sin interacción del usuario). Establece el inicio y el final del período de mantenimiento diario, como minutos del día, cuando crees una nueva política con ventanas.
- Pospuesto
- Aplaza la instalación de actualizaciones del sistema por 30 días. Después de los 30 días finalizado el período de prueba, el sistema le solicitará al usuario del dispositivo que instale la actualización.
Períodos de aplazamiento
El sistema limita cada actualización a un aplazamiento de 30 días. El período comienza cuando el sistema pospone la actualización por primera vez y establecer nuevas políticas de aplazamiento no extenderá el período.
Además de posponer, es posible que Android no pueda instalar una actualización para otras por ejemplo, falta de conectividad, espacio insuficiente en el disco o batería baja.
El sistema restablece el temporizador de 30 días de posposición si se produce una actualización diferente. disponibles durante el período, lo que les da a los administradores de TI la oportunidad de probar el sistema combinado actualizaciones. Una vez que hayan pasado 30 días sin una actualización nueva, el sistema le solicitará al usuario que instale todas las actualizaciones pendientes. Más tarde, cuando una nueva actualización del sistema disponible, el período de 30 días comenzará de nuevo.
Cómo establecer una política
Puedes configurar políticas de actualización en Android 8.0 (nivel de API 26) o versiones posteriores. Para especificar cuándo el dispositivo debe instalar actualizaciones del sistema, crea una instancia de SystemUpdatePolicy
con uno de los tres tipos descritos anteriormente. Para establecer una política, el propietario del dispositivo llama al método DevicePolicyManager
setSystemUpdatePolicy()
En el siguiente ejemplo de código, se muestra cómo puedes hacerlo. Para ver un ejemplo de política con ventanas, consulta la documentación de SystemUpdatePolicy
.
Kotlin
// Create the system update policy to postpone installation for 30 days. val policy = SystemUpdatePolicy.createPostponeInstallPolicy() // Get a DevicePolicyManager instance to set the policy on the device. val dpm = context.getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager val adminName = getComponentName(context) // Set the policy. dpm.setSystemUpdatePolicy(adminName, policy)
Java
// Create the system update policy to postpone installation for 30 days. SystemUpdatePolicy policy = SystemUpdatePolicy.createPostponeInstallPolicy(); // Get a DevicePolicyManager instance to set the policy on the device. DevicePolicyManager dpm = (DevicePolicyManager) context .getSystemService(Context.DEVICE_POLICY_SERVICE); ComponentName adminName = getComponentName(context); // Set the policy. dpm.setSystemUpdatePolicy(adminName, policy);
Las instancias de políticas no se pueden cambiar una vez que se crean. Para cambiar cuándo un dispositivo instala actualizaciones, puedes crear y configurar una política nueva. Para quitar una política de un
dispositivo, llama a setSystemUpdatePolicy()
y pasa null
como el argumento policy
.
Después de que tu DPC quita una política, el usuario del dispositivo ve notificaciones sobre las actualizaciones del sistema disponibles.
Las apps pueden llamar a getSystemUpdatePolicy()
para obtener la política actual del dispositivo. Si este método muestra null
, significa que no se configuró una política en este momento.
Períodos de inmovilización
Para inmovilizar la versión del SO durante períodos críticos, como las festividades o otras épocas ocupadas, los propietarios de dispositivos pueden suspender las actualizaciones del sistema hasta por 90 días. Cuando un elemento El dispositivo se encuentra en un período sin actualización, se comporta de la siguiente manera:
- El dispositivo no recibe notificaciones sobre actualizaciones del sistema pendientes.
- No se instalan las actualizaciones del SO.
- Los usuarios de dispositivos no pueden buscar actualizaciones del sistema de forma manual en Configuración.
El sistema aplica un período de búfer obligatorio de 60 días después de cualquier período sin actualización para evitar que el dispositivo no se actualice por tiempo indefinido. Recuerda, el sistema que se congela las actualizaciones pueden impedir que los dispositivos reciban actualizaciones críticas.
Estableces períodos de inactividad en una política de actualización. No puedes establecer períodos sin actualización estableciendo una política. Cuando el dispositivo esté fuera de los períodos de bloqueo que hayas establecido, la se aplica el comportamiento normal de las políticas (automático, con ventanas o pospuesto).
Cómo establecer un período de inactividad
Puedes configurar períodos sin actualización en Android 9 (nivel de API 28) o versiones posteriores. El propietario de un dispositivo establece un período sin actualización en una política de actualización del sistema antes de configurar la política para el dispositivo. Estos son los pasos:
- Crea una política de actualización del sistema nueva (o obtén la actual).
- Para establecer los períodos de inactividad en la política, llama a
setFreezePeriods()
. - Llama a
setSystemUpdatePolicy()
para establecer la política y los períodos de inactividad del dispositivo.
Debido a que el período sin actualización se repite anualmente, las fechas de inicio y finalización del período se representan con valores de mes y día. El día de inicio debe comenzar a la hora al menos 60 días después de la finalización de cualquier período sin actualización anterior. En el siguiente ejemplo, se muestra cómo puedes establecer dos períodos de inactividad para una política de actualización del sistema existente:
Kotlin
// Get the existing policy from the DevicePolicyController instance. val policy = dpm.systemUpdatePolicy ?: return try { // Set the two annual freeze periods on the policy for our retail // point-of-sale devices. val summerSale = FreezePeriod( MonthDay.of(6, 1), MonthDay.of(7, 31)) // Jun 1 - Jul 31 inclusive val winterSale = FreezePeriod( MonthDay.of(11, 20), MonthDay.of(1, 12)) // Nov 20 - Jan 12 inclusive policy.freezePeriods = Arrays.asList(summerSale, winterSale) // Set the policy again to activate the freeze periods. dpm.setSystemUpdatePolicy(adminName, policy) } catch (e: SystemUpdatePolicy.ValidationFailedException) { // There must be previous periods recorded on the device because // summerSale and winterSale don’t overlap and are separated by more // than 60 days. Report the overlap ... }
Java
// Get the existing policy from the DevicePolicyController instance. SystemUpdatePolicy policy = dpm.getSystemUpdatePolicy(); try { // Set the two annual freeze periods on the policy for our // retail point-of-sale devices. FreezePeriod summerSale = new FreezePeriod( MonthDay.of(6, 1), MonthDay.of(7, 31)); // Jun 1 - Jul 31 inclusive FreezePeriod winterSale = new FreezePeriod( MonthDay.of(11, 20), MonthDay.of(1, 12)); // Nov 20 - Jan 12 inclusive policy.setFreezePeriods(Arrays.asList(summerSale, winterSale)); // Don’t forget to set the policy again to activate the freeze periods. dpm.setSystemUpdatePolicy(adminName, policy); } catch (SystemUpdatePolicy.ValidationFailedException e) { // There must be previous periods recorded on the device because summerSale // and winterSale don’t overlap and are separated by more than 60 days. // Report the overlap ... }
Tanto el día de inicio como el día de finalización son inclusivos. Si el día de inicio es mayor que el día de finalización (como winterSale
en el ejemplo anterior), el período sin actualizaciones se extiende al año siguiente.
Al establecer el bloqueo períodos en una política de actualización del sistema, Android prueba los siguientes requisitos:
- No se puede establecer un período de inactividad superior a 90 días.
- El intervalo entre períodos sin actualización es de al menos 60 días.
- Los períodos de bloqueo no se superponen.
- No hay períodos sin actualización duplicados.
Al establecer la política de actualización del sistema en un dispositivo, Android repite estas pruebas. e incluye los períodos sin actualización actuales o anteriores del dispositivo.
Android arroja un SystemUpdatePolicy.ValidationFailedException
cuando falla alguna de estas pruebas.
Para obtener una lista de los períodos de suspensión establecidos anteriormente en un objeto de política de actualización del sistema, haz lo siguiente:
todas las apps instaladas pueden llamar
SystemUpdatePolicy.getFreezePeriods()
En el siguiente ejemplo, se llama a este método para registrar los períodos de inactividad de un dispositivo:
Kotlin
// Log any freeze periods that might be set on a system update policy. dpm.systemUpdatePolicy?.freezePeriods?.forEach { Log.i(TAG, "Freeze period: $it") }
Java
// Log any freeze periods that might be set on a system update policy. SystemUpdatePolicy currentPolicy = dpm.getSystemUpdatePolicy(); if (currentPolicy != null) { // A policy might not be set. for (FreezePeriod freezePeriod : currentPolicy.getFreezePeriods()) { Log.i(TAG, "Freeze period: " + freezePeriod.toString()); } }
Años bisiestos
Android usa el calendario ISO 8601 (también llamado calendario gregoriano) para calcula períodos sin actualización e ignora los años bisiestos. Esto significa que el 29 de febrero no se reconoce como una fecha válida y se trata como si fuera el 28 de febrero. Por lo tanto, el 29 de febrero no se cuenta cuando se calcula la duración de un período de inactividad.
Desarrollo y pruebas
Mientras desarrollas y pruebas la función de actualización del sistema del DPC, puedes deberá crear muchos períodos sin actualización. Porque Android busca un intervalo de 60 días. entre los períodos sin actualización anteriores, es posible que no puedas establecer un nuevo período sin actualización sin borrar primero el registro de períodos anteriores. Para borrar el registro del período de inactividad del dispositivo, ejecuta el siguiente comando en el shell de Android Debug Bridge (adb):
adb shell dpm clear-freeze-period-record
Para confirmar que un dispositivo se encuentra en un período sin actualización, verifica que el usuario para las actualizaciones del sistema está inhabilitada.
Actualizaciones del sistema de Google Play (principales)
Las actualizaciones del sistema de Google Play (también llamadas actualizaciones de Mainline) se descargan automáticamente, pero requieren que se reinicie el dispositivo para instalarlas. Estas actualizaciones no activarán un reinicio automático, sino que se instalarán en el próximo reinicio iniciado por el usuario, el administrador o la política. Reinicios activados por el sistema de actualización instalará la actualización del sistema de Google/OEM asociada y cualquier actualizaciones del sistema de Google Play descargadas anteriormente.
Las actualizaciones del sistema de Google Play también se pueden instalar manualmente. Para ello, navega a Configuración > Acerca de > Versión de Android > Actualización del sistema de Google Play
Revierte una actualización
En algunos casos, la herramienta de reversión de actualizaciones del sistema de Google Play (GPSUR) se puede usar para recuperar el estado del dispositivo debido a una instalación problemática de la actualización del sistema de Google Play. Esta herramienta la deben utilizar los usuarios avanzados o cuando se indique que lo hagan. y el personal de asistencia, ya que se pueden perder datos. Cómo usar el GPSUR herramienta:
- Si tienes Android Debug Bridge (adb) ejecutándose en tu máquina, detén el servicio de adb antes de continuar para que no interfiera con el proceso de reversión. Para detener adb, ejecuta
adb kill-server
. - Abre la herramienta GPSUR.
- Haz clic en Allow ADB access para permitir a la herramienta comunicarse con tu dispositivo de prueba a través de adb.
- Haz clic en Add new device.
- Selecciona tu dispositivo de la lista y haz clic en Connect. Es posible que la lista no contenga el nombre completo del dispositivo.
- En la pantalla del dispositivo, selecciona Permitir siempre para esta computadora y haz clic en OK para aceptar la conexión de depuración por USB.
- Selecciona el dispositivo conectado en el navegador.
- El texto del botón de la página debe cambiar de No hay reversiones disponibles a Revierte las actualizaciones recientes si hay reversiones disponibles en tu dispositivo. Haz clic en Revertir actualizaciones recientes.
- Lee las advertencias en el cuadro modal Confirm Rollback y haz clic en Confirm.
- Espera a que se complete la reversión. Cuando se complete, aparecerá un diálogo Rollback Successful y se reiniciará el dispositivo. Es seguro desenchufar tu dispositivo.
Recursos adicionales
Para obtener más información sobre las actualizaciones del sistema, lee la documentación sobre Actualizaciones OTA del Proyecto de código abierto de Android.