Gerenciar atualizações do sistema

Este guia do desenvolvedor explica como o controlador de política de dispositivo (DPC) pode gerenciar atualizações do sistema Android em nome do usuário do dispositivo.

Introdução

Dispositivos Android podem receber e instalar atualizações OTA no sistema e software de aplicativo. O Android notifica o usuário do dispositivo de que uma atualização do sistema está disponível e o usuário do dispositivo pode instalar a atualização imediatamente ou mais tarde.

Com o DPC, um administrador de TI pode gerenciar as atualizações do sistema para o usuário do dispositivo. DPCs pode ter um dispositivo totalmente gerenciado (chamado de proprietário do dispositivo) ou um perfil de trabalho. (chamado de proprietário do perfil). A tabela 1 mostra como os proprietários de dispositivos podem gerenciar o sistema atualizações, enquanto os proprietários de perfis só podem relatar informações sobre atualizações do sistema.

Tabela 1: as tarefas disponíveis para DPCs dependem do modo de proprietário

Tarefa Proprietário de dispositivo Perfil de proprietário
Verificar se há atualizações pendentes do sistema
Receber callbacks quando novas atualizações do sistema estiverem disponíveis
Definir uma política de atualização local para controlar quando o Android instala atualizações do sistema
Congelar a versão do SO durante períodos críticos

Verificar se há atualizações pendentes

Uma atualização pendente é uma atualização do sistema de um dispositivo que ainda não foi instalado. Seu DPC pode ajudar os administradores de TI a verificar quais dispositivos têm atualizações pendentes do sistema. peça aos usuários do dispositivo para instalar atualizações críticas imediatamente.

Proprietários de dispositivos e perfis com o Android 8.0 (nível 26 da API) ou versões mais recentes pode verificar se um dispositivo tem uma atualização do sistema pendente. Ligação DevicePolicyManager.getPendingSystemUpdate() que retornará null se o dispositivo estiver atualizado. Se uma atualização do sistema estiver pendente, o método retorna informações sobre a atualização.

Saiba mais sobre uma atualização pendente

Depois de chamar getPendingSystemUpdate(), é possível inspecionar o SystemUpdateInfo para saber mais sobre a atualização pendente. A o exemplo a seguir mostra como descobrir quando uma atualização pendente foi realizada pela primeira vez disponíveis para o 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));
}

Callbacks do sistema

Quando uma atualização é disponibilizada, o sistema Android notifica os proprietários do dispositivo sobre a nova atualização. No Android 8.0 ou versões mais recentes, o sistema também notifica os proprietários de perfis.

Na subclasse DeviceAdminReceiver, modifique o Callback onSystemUpdatePending(). Você não precisa registrar ou anunciar seu DPC para receber o callback. O sistema pode chamar esse método mais de uma vez para uma única atualização. Portanto, verifique o status da atualização antes de responder. Ligue para getPendingSystemUpdate() e saiba mais sobre a atualização do sistema no callback. O exemplo a seguir mostra como fazer isso:

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.
    // ...
  }
}

Quando um sistema tem mais de um DPC, por exemplo, perfis de trabalho em contas totalmente dispositivos, o proprietário do dispositivo e o proprietário do perfil receberão o callback.

Atualizar políticas

Um proprietário de dispositivo pode controlar quando atualizações são instaladas configurando um sistema local política de atualização para um dispositivo. Há três tipos de política de atualização do sistema:

Automático
Instala as atualizações do sistema assim que elas se tornam disponíveis (sem interação do usuário). A definição desse tipo de política instala imediatamente todas as atualizações pendentes que podem ser adiadas ou aguardando uma janela de manutenção.
Com janela
Instala atualizações do sistema durante uma manutenção diária (sem interação do usuário). Defina o início e o fim da janela de manutenção diária, como minutos de do dia, ao criar uma nova política em janela.
Adiado
Adia a instalação de atualizações do sistema por 30 dias. Após o período de 30 dias for encerrado, o sistema solicitará que o usuário do dispositivo instale a atualização.

Períodos de adiamento

O sistema limita cada atualização a um adiamento de 30 dias. O período começa quando o sistema adia a atualização primeiro, e definir novas políticas de adiamento estender o período.

Além do adiamento, o Android pode não conseguir instalar uma atualização para outros por alguns motivos, como falta de conectividade, espaço em disco insuficiente ou pouca bateria.

O sistema redefinirá o timer de 30 dias caso ocorra uma atualização diferente. disponíveis durante o período. Assim, os administradores de TI têm a chance de testar o sistema combinado atualizações. Após 30 dias sem uma nova atualização, o sistema solicita que o usuário instale todas as atualizações pendentes. Mais tarde, quando uma nova atualização do sistema se tornar disponível, o período de 30 dias começa novamente.

Como definir uma política

É possível definir políticas de atualização no Android 8.0 (nível 26 da API) ou versões mais recentes. Para especificar quando o dispositivo deve instalar as atualizações do sistema, crie uma instância do SystemUpdatePolicy usando um dos três tipos descritos acima. Para definir uma política, o proprietário do dispositivo chama o método DevicePolicyManager setSystemUpdatePolicy(). O código a seguir exemplo mostra como fazer isso. Para conferir um exemplo de política em janela, a documentação 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);

As instâncias de política não podem ser alteradas depois de criadas. Para mudar quando um dispositivo instalar atualizações, poderá criar e definir uma nova política. Para remover uma política de um dispositivo, chame setSystemUpdatePolicy() transmitindo null como o argumento policy. Depois que o DPC remover uma política, o usuário do dispositivo verá notificações de qualquer atualizações do sistema disponíveis.

Os apps podem chamar getSystemUpdatePolicy() para receber política atual para o dispositivo. Se o método retornar null, isso significa que uma não está definida no momento.

Períodos de congelamento

Para congelar a versão do SO em períodos críticos, como feriados ou outras atividades os proprietários de dispositivos podem suspender as atualizações do sistema por até 90 dias. Quando um dispositivo estiver em um período de congelamento, ele se comportará da seguinte maneira:

  • O dispositivo não recebe notificações sobre atualizações pendentes do sistema.
  • As atualizações do sistema para o SO não são instaladas.
  • Os usuários de dispositivos não podem verificar manualmente se há atualizações do sistema nas Configurações.

O sistema aplica um período de buffer obrigatório de 60 dias após qualquer congelamento definido para evitar o congelamento do dispositivo indefinidamente. Lembre-se de que o congelamento do sistema podem impedir que os dispositivos recebam atualizações críticas.

Figura 1. Dois períodos de congelamento definidos para um dispositivo
Calendário mostrando dois períodos de congelamento em um ano com reservas de 60 dias.

Você define períodos de congelamento em uma política de atualização. Não é possível definir períodos de congelamento sem a definição de uma política. Quando o dispositivo estiver fora dos períodos de congelamento definidos, o um comportamento normal (automático, em janelas ou adiado) será aplicado.

Como definir um período de congelamento

Você pode definir períodos de congelamento no Android 9 (nível 28 da API) ou versões mais recentes. Um dispositivo o proprietário define um período de congelamento em uma política de atualização do sistema antes de definir a política para o dispositivo. As etapas são:

  1. Crie uma nova política de atualização do sistema ou receba a atual.
  2. Defina os períodos de congelamento na política chamando setFreezePeriods()
  3. Defina a política e congele os períodos para o dispositivo chamando setSystemUpdatePolicy()

Como o período de congelamento é repetido anualmente, as datas de início e término da são representados pelos valores de mês e dia. A data de início deve começar em no mínimo 60 dias após o término do período de congelamento anterior. O exemplo a seguir mostra como você pode definir dois períodos de congelamento para uma política de atualização do 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 o dia de início quanto o dia de término são inclusivos. Se o dia de início for posterior que o dia de término (como winterSale no exemplo anterior), o congelamento se estende até o ano seguinte.

Ao definir congelamento períodos em uma política de atualização do sistema, o Android testa estes requisitos:

  • Nenhum período de congelamento superior a 90 dias.
  • O intervalo entre os períodos de congelamento é de pelo menos 60 dias.
  • Os períodos de congelamento não se sobrepõem.
  • Não há períodos de congelamento duplicados.

Ao definir a política de atualização do sistema para um dispositivo, o Android repete esses testes e inclui todos os períodos de congelamento atuais ou anteriores do dispositivo.

O Android gera uma SystemUpdatePolicy.ValidationFailedException quando em algum desses testes.

Para obter uma lista de períodos de congelamento definidos anteriormente em um objeto de política de atualização do sistema, todos os apps instalados podem ligar SystemUpdatePolicy.getFreezePeriods() O seguinte exemplo chama este método para registrar os períodos de congelamento de um 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());
  }
}

Anos bissextos

O Android usa o calendário ISO 8601 (também chamado de calendário gregoriano) para calculam períodos de congelamento e ignora anos bissextos. Isso significa que 29 de fevereiro não é reconhecida como uma data válida e é tratada como se fosse 28 de fevereiro. Portanto, 29 de fevereiro não é contado ao calcular a duração de uma pausa período

Desenvolvimento e teste

Enquanto desenvolve e testa o recurso de atualização do sistema do seu DPC, você pode precisamos criar muitos períodos de congelamento. Como o Android verifica um intervalo de 60 dias entre períodos de congelamento anteriores, talvez não seja possível definir um novo período sem antes limpar o registro de períodos passados. Para limpar o congelamento do dispositivo ponto final, execute o seguinte comando no Android Debug Bridge (adb):

adb shell dpm clear-freeze-period-record

Você pode confirmar se um dispositivo está em um período de congelamento verificando se o usuário para atualizações do sistema está desativada.

Atualizações do sistema do Google Play (Mainline)

As atualizações do sistema do Google Play (também chamadas de atualizações de Mainline) são: baixado automaticamente, mas o dispositivo precisa ser reiniciado para ser instalado. Esses atualizações automáticas não acionam uma reinicialização automática. Em vez disso, elas são instaladas a próxima reinicialização do usuário, administrador ou política iniciada. Reinicializações acionadas pelo sistema de atualização do sistema instalará a atualização do sistema Google/OEM associada e quaisquer das atualizações do sistema do Google Play transferidas por download anteriormente.

As atualizações do sistema do Google Play também podem ser instaladas manualmente. Configurações > Sobre > Versão do Android > Atualização do sistema do Google Play.

Outros recursos

Para saber mais sobre as atualizações do sistema, leia a página OTA do Android Open Source Project Updates.