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

Os dispositivos Android podem receber e instalar atualizações OTA (over-the-air) no sistema e no software do 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 atualizações do sistema, enquanto os proprietários de perfis só podem informar 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. O DPC pode ajudar os administradores de TI a verificar quais dispositivos têm atualizações do sistema pendentes e talvez pedir aos usuários que instalem as 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. O exemplo abaixo mostra como descobrir quando uma atualização pendente ficou disponível 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 fica disponível, o sistema Android notifica os proprietários do dispositivo 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, substitua 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ível (sem interação do usuário). A configuração desse tipo de política instala imediatamente todas as atualizações pendentes que podem ser adiadas ou que estão 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 pela primeira vez, e a definição de novas políticas de adiamento não prorroga 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. Depois, quando uma nova atualização do sistema é disponibilizada, 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 a política atual do 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 outros momentos de pico, 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 congelar as atualizações do sistema pode 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 buffers 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. O proprietário do dispositivo 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 precisa começar pelo menos 60 dias após o término de qualquer período de congelamento anterior. O exemplo a seguir mostra como definir dois períodos de congelamento para uma política de atualização do sistema:

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

O dia de início e o dia de término são incluídos. 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 algum desses testes falha.

Para receber 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 chamar 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 calcular 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 se há 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 transferidas por download automaticamente, mas o dispositivo precisa ser reiniciado para ser instalado. Essas atualizações não acionam uma reinicialização automática. Em vez disso, elas são instaladas na 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.

Reverter uma atualização

Em alguns casos, a ferramenta Reversões de atualizações do sistema do Google Play (GPSUR) pode ser usado para recuperar o estado do dispositivo devido a uma atualização do sistema do Google Play problemática e instalação. Esta ferramenta deve ser utilizada por usuários avançados ou quando instruído a fazer pela equipe de suporte, já que pode resultar em perda de dados. Veja como usar o GPSUR ferramenta:

  1. Se você tiver o Android Debug Bridge (adb) em execução no computador, pare serviço adb antes de prosseguir, para que não interfira na o processo de reversão. Para interromper o adb, execute adb kill-server.
  2. Abra a ferramenta GPSUR.
  3. Clique em Permitir acesso ao adb para que a ferramenta possa se comunicar com o dispositivo de teste pelo adb.
  4. Clique em Adicionar novo dispositivo.
  5. Selecione seu dispositivo na lista e clique em Conectar. Esta lista pode não contém o nome completo do dispositivo.
  6. Na tela do seu dispositivo, selecione Sempre permitir neste computador e clique em Clique em OK para aceitar a conexão da depuração USB.
  7. Selecione o dispositivo conectado no navegador.
  8. O texto do botão na página deve mudar de Nenhuma reversão disponível para Reverta atualizações recentes se houver reversões disponíveis no dispositivo. Clique em Reverter atualizações recentes.
  9. Leia os avisos no modal Confirm Rollback e clique em Confirm.
  10. Aguarde a conclusão da reversão. Quando terminar, uma Reversão bem-sucedida modal aparecerá e o dispositivo será reiniciado. Você já pode desconectar dispositivo.

Outros recursos

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