En esta guía para desarrolladores, se explica cómo el controlador de políticas del dispositivo (DPC) puede administrar las actualizaciones del sistema Android en nombre del usuario del dispositivo.
Introducción
Los dispositivos Android pueden recibir e instalar actualizaciones inalámbricas (OTA) del sistema y el 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. DPC Puede tener un dispositivo completamente administrado (denominado propietario del dispositivo) o un perfil de trabajo. (denominado 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 comprobar si hay actualizaciones pendientes
Una actualización pendiente es una actualización del sistema para un dispositivo que aún no se instaló. Tu DPC puede ayudar a los administradores de TI a comprobar qué dispositivos tienen actualizaciones del sistema pendientes. o pedir a los usuarios de dispositivos que instalen actualizaciones críticas de manera oportuna.
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. El
El siguiente ejemplo muestra cómo puedes saber cuándo se realizó una actualización pendiente por primera vez.
disponibles 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 de los dispositivos la nueva actualización. En Android 8.0 o versiones posteriores, el sistema también notifica a los propietarios de los perfiles.
En tu subclase DeviceAdminReceiver, anula el
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 sistema
llama a este método más de una vez para una sola actualización, así que comprueba el estado de la actualización
antes de responder. Llama a getPendingSystemUpdate() para obtener más información sobre las
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 período de mantenimiento diario (sin interacción del usuario). Establece el inicio y la finalización del período de mantenimiento diario como minutos de durante el día, cuando se crea una nueva política de ventanas.
- Pospuesto
- Pospone la instalación de actualizaciones del sistema durante 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 posposición
El sistema limita cada actualización a un aplazamiento de 30 días. El período comienza cuando el sistema primero pospone la actualización, y establecer nuevas políticas de postergación 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 transcurran 30 días sin una actualización nueva, el sistema le solicitará instalar todas las actualizaciones pendientes. Más adelante, cuando haya una nueva actualización del sistema disponible, se reiniciará el período de 30 días.
Cómo establecer una política
Puedes establecer 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() El siguiente código
de 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 el momento en que un dispositivo
instala actualizaciones, puedes crear y establecer una nueva política. Para quitar una política de un
dispositivo, llama a setSystemUpdatePolicy() y pasa null como el argumento policy.
Después de que tu DPC quite una política, el usuario del dispositivo verá notificaciones de cualquier
actualizaciones del sistema disponibles.
Las apps pueden llamar a getSystemUpdatePolicy() para obtener la
política actual para el dispositivo. Si este método muestra null, significa que no se configuró una política en este momento.
Períodos de congelación
Suspender la versión del SO durante períodos críticos, como días feriados u otras horas de actividad los propietarios de dispositivos pueden suspender las actualizaciones del sistema durante un máximo de 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.
- Las actualizaciones del sistema para el SO no están instaladas.
- Los usuarios de dispositivos no pueden buscar actualizaciones del sistema de forma manual en Configuración.
El sistema aplica un margen obligatorio de 60 días después de cualquier suspensión definida. para evitar que el dispositivo se congele indefinidamente. Recuerda, el sistema que se congela las actualizaciones pueden impedir que los dispositivos reciban actualizaciones críticas.
Debes establecer períodos de suspensión 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 configurar un período sin actualización
Puedes establecer períodos de inactividad en Android 9 (nivel de API 28) o versiones posteriores. Un dispositivo El propietario establece un período de suspensión en una política de actualización del sistema antes de establecerla. para el dispositivo. Los pasos son los siguientes:
- Crea una nueva política de actualización del sistema (o bien obtén la actual).
- Para establecer los períodos de suspensión en la política, llama a
setFreezePeriods() - Establece la política y los períodos de suspensión del dispositivo mediante una llamada a
setSystemUpdatePolicy()
Debido a que el período sin actualización se repite anualmente, las fechas de inicio y finalización del período están representados por 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. El siguiente ejemplo muestra cómo puedes establecer dos períodos sin actualización 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 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:
- Ningún período sin actualización es 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 de inmovilizació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 calcular los períodos de inactividad y omite 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 eliminar el bloqueo del dispositivo, haz lo siguiente: período, ejecuta el siguiente comando en Android Debug Bridge Shell (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 (línea principal)
Las actualizaciones del sistema de Google Play (también denominadas actualizaciones de línea principal) son se descargan automáticamente, pero requieren que se reinicie el dispositivo para instalarse. Estos las 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. Los reinicios activados por la política de actualización del sistema instalarán la actualización del sistema de Google/OEM asociada y cualquier actualización del sistema de Google Play que se haya descargado 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, es posible usar la herramienta de reversión de actualizaciones del sistema de Google Play (GPSUR). que se usa para recuperar el estado del dispositivo debido a una actualización del sistema de Google Play problemática instalación. Los usuarios avanzados deben usar esta herramienta o cuando el personal de asistencia técnica se lo indique, ya que puede provocar la pérdida de datos. Cómo usar el GPSUR herramienta:
- Si estás ejecutando Android Debug Bridge (adb) en tu máquina, detente
el servicio de adb antes de continuar para que no interfiera con el
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 esta lista no contienen 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 la ventana modal Confirm Rollback y haz clic en Confirm.
- Espera a que se complete la reversión. Una vez completada, una reversión exitosa aparecerá la ventana modal y se reiniciará el dispositivo. Ya puedes desenchufar el dispositivo.
Recursos adicionales
Para obtener más información sobre las actualizaciones del sistema, lee el artículo sobre OTA del Proyecto de código abierto de Android Actualizaciones.