Controles de atualização unificados

Os Controles Unificados de Atualização (UUC, na sigla em inglês) oferecem aos administradores de TI uma maneira única e consistente de controlar quando as atualizações de software são baixadas e aplicadas em dispositivos Android da empresa, para que as atualizações não interrompam as operações comerciais.

Com uma política de UUC, é possível controlar as atualizações dos seguintes componentes de software:

• Atualizações do SO emitidas pelo fabricante do dispositivo (OEM), incluindo atualizações principais e secundárias do SO e atualizações de segurança.
• Atualizações do sistema do Google Play (Mainline).
• Serviços do sistema do Google, como o Google Play Services e o WebView do sistema Android, em grupo ou um app por vez.

As regras de UUC são definidas no campo unifiedUpdatePolicy de um recurso Policy. O app Android Device Policy (ADP) é o ponto de decisão central no dispositivo para o UUC.

Pré-requisitos

Antes de configurar o UUC, verifique os seguintes requisitos:

• Sua solução de EMM pode criar e atualizar políticas para uma empresa.
• Os dispositivos são da empresa, configurados como totalmente gerenciados ou com um perfil de trabalho em um dispositivo da empresa. A UUC não é compatível com dispositivos pessoais.
• Os dispositivos atendem à versão mínima do Android compatível com cada destino de atualização que você quer controlar, conforme mostrado na tabela a seguir:

Considerações e limitações

Analise as seguintes considerações e limitações antes de planejar sua integração com o UUC:

• Assistente de configuração inicial: as políticas de UUC não são aplicadas enquanto o dispositivo está no assistente de configuração inicial. Atualizações críticas do Google Play ou do agente OTA do OEM podem ocorrer durante a configuração do dispositivo.
• Atualizações antecipadas após a configuração: as políticas de UUC podem não se aplicar a atualizações automáticas que começam imediatamente após a configuração do dispositivo, como atualizações antecipadas do Google Play Services, antes que a política chegue ao ADP.
• Módulos OTA agrupados: as atualizações OTA do OEM podem conter versões atualizadas de módulos da Mainline e serviços do sistema do Google. A instalação de uma atualização OTA do OEM atualiza automaticamente esses componentes incluídos.
• Atualizações do sistema do Google Play (Mainline): o UUC controla a atualização do Mainline como uma única unidade, de modo que os pacotes individuais do Mainline não podem ser controlados de forma independente. O UUC só controla o início da fase de download: depois que um download do Mainline começa, ele não pode ser interrompido. Se uma regra BLOCK for aplicada depois que o download começar, a atualização ainda será concluída na próxima reinicialização do dispositivo.
• Atualizações manuais durante períodos de bloqueio: para atualizações do sistema do Google Play (Mainline) e serviços do sistema do Google, uma regra BLOCK só impede atualizações automáticas. Os usuários ainda podem atualizar manualmente esses componentes, mesmo quando uma regra BLOCK está ativa. Isso será abordado em uma versão futura.
• Aplicativos isentos: o UUC não gerencia atualizações para o app da Google Play Store ou o app ADP.

Entender as políticas de UUC

Um UnifiedUpdatePolicy consiste em uma lista ordenada de objetos Rule. Cada regra especifica:

• um identificador (id) definido pela sua solução de EMM;
• um ou mais destinos de atualização de software
• etapas de avaliação opcionais
• um ou mais predicados opcionais que contêm condições baseadas em tempo
• um resultado que determina como a atualização é processada

Avaliação de regras

Ao avaliar uma atualização pendente, o ADP considera todas as regras que se aplicam ao destino e ao estágio dessa atualização, na ordem em que aparecem em rules. O ADP seleciona a primeira regra em que o predicado é avaliado como true e aplica o resultado, como uma instrução if-else encadeada. Se nenhum predicado de regra for avaliado como true, o cliente de atualização responsável pelo componente gerenciará a atualização normalmente.

Identificadores de regras

Cada regra requer um id de até 64 caracteres definido pela sua solução de EMM. O id não pode estar vazio e precisa ser exclusivo entre as regras de uma política.

Atualizar metas

Cada regra precisa especificar uma lista não vazia de targets sem duplicatas. Especificar vários destinos em uma única regra equivale a definir várias regras em sequência, cada uma com um único destino, na mesma ordem.

A tabela a seguir descreve os valores de targetType compatíveis:

Etapas da avaliação

Para destinos OS_UPDATE_WITH_API_LEVEL_CHANGE e OS_UPDATE_WITHOUT_API_LEVEL_CHANGE, é possível especificar o stages em que uma regra é avaliada:

• STAGE_DOWNLOAD: a regra é avaliada antes do download da atualização.
• STAGE_APPLY: a regra é avaliada antes de realizar uma ação que aplica a atualização, como acionar uma reinicialização automática.

Se stages estiver vazio, a regra será avaliada em todas as etapas. Observação: para destinos GOOGLE_SYSTEM_SERVICES, SINGLE_APP e GOOGLE_PLAY_SYSTEM_UPDATE, os estágios são ignorados.

Predicados

Um predicate define condições baseadas em tempo em que uma regra é correspondente, como os dias da semana, um período do dia (com granularidade de hora), um intervalo de datas no fuso horário local do dispositivo ou há quanto tempo a atualização está disponível para o dispositivo (em múltiplos de 24 horas).

Todas as condições definidas em um único predicado são combinadas usando um AND lógico. Um predicado vazio ou omitido sempre é avaliado como true. Para ver a lista completa de campos de predicado e as restrições deles, consulte a documentação de referência Predicate.

Ao configurar janelas de horário (timeOfDayLowerBound e timeOfDayUpperBound), lembre-se das seguintes regras de avaliação:

• Limites de hora: os limites de hora do dia são avaliados como hh:00:00 no fuso horário local do dispositivo. timeOfDayUpperBound fecha a janela no horário especificado (por exemplo, um limite inferior de 9 e um limite superior de 17 abrange de 09:00 a 17:00).
• Ordem de limite válida: quando os dois limites são definidos na mesma regra, timeOfDayUpperBound precisa ser estritamente maior que timeOfDayLowerBound. Se timeOfDayUpperBound for menor ou igual a timeOfDayLowerBound ou estiver definido como 0 (00:00), o predicado será avaliado como false.
• Janelas de fim do dia e noturnas: para estender uma janela até o fim do dia (24:00), omita timeOfDayUpperBound. Para definir uma janela noturna que abranja a meia-noite (por exemplo, de 22:00 a 04:00), divida a janela em duas regras sequenciais: uma regra noturna com apenas timeOfDayLowerBound definido ({ "hours": 22 }) e uma regra matinal com apenas timeOfDayUpperBound definido ({ "hours": 4 }, segmentando o dia seguinte se daysOfWeek estiver definido).

Resultados

Um outcome especifica como o ADP instrui o agente de atualização a prosseguir quando o predicado de uma regra é avaliado como true. A tabela a seguir descreve os valores de outcomeType compatíveis:

Limites máximos de adiamento

A UUC permite adiar atualizações com um resultado BLOCK ou USER_PROMPT até um período máximo de adiamento para cada destino de atualização. Quando uma atualização estiver disponível por mais tempo do que o período máximo de adiamento, qualquer resultado de BLOCK ou USER_PROMPT será substituído pelo padrão, e o cliente de atualização gerenciará a atualização normalmente.

A tabela a seguir lista os limites máximos de adiamento por destino e modo de gerenciamento:

Precedência de systemUpdate

Antes de adicionar unifiedUpdatePolicy a uma política, revise as configurações de systemUpdate e recrie o comportamento necessário com as regras de UUC. Por exemplo, para manter as atualizações do SO fora do horário de funcionamento, use uma regra BLOCK como a de Bloquear as principais atualizações do SO durante o horário de funcionamento.

Esse comportamento de precedência é diferente dos DPCs personalizados que usam o SDK da AMAPI, em que um SystemUpdatePolicy do AOSP tem precedência sobre o UUC para atualizações OTA do OEM. Para mais detalhes, consulte Precedência de SystemUpdatePolicy do AOSP. Se um serviço de gerenciamento de atualizações específico do OEM (como uma solução OTA empresarial) estiver ativo no dispositivo, ele também terá precedência sobre o UUC para atualizações do SO do OEM (OS_UPDATE_WITH_API_LEVEL_CHANGE e OS_UPDATE_WITHOUT_API_LEVEL_CHANGE).

Configurar a política de UUC

É possível definir, recuperar e limpar o campo unifiedUpdatePolicy em um recurso de política e verificar a conformidade dos dispositivos que usam a política.

Definir a política de UUC

Para configurar o UUC, adicione um objeto unifiedUpdatePolicy à política. Para aplicar a política de UUC sem alterar as outras configurações de uma política atual, chame enterprises.policies.patch com updateMask=unifiedUpdatePolicy:

PATCH https://androidmanagement.googleapis.com/v1/enterprises/{enterpriseId}/policies/{policyId}?updateMask=unifiedUpdatePolicy

{
  "unifiedUpdatePolicy": {
    "rules": [
      {
        "id": "Block Policy",
        "targets": [
          {
            "targetType": "OS_UPDATE_WITH_API_LEVEL_CHANGE"
          }
        ],
        "predicate": {
          "daysOfWeek": [
            "MONDAY",
            "TUESDAY",
            "WEDNESDAY",
            "THURSDAY",
            "FRIDAY"
          ],
          "timeOfDayLowerBound": { "hours": 9 },
          "timeOfDayUpperBound": { "hours": 17 }
        },
        "outcome": {
          "outcomeType": "BLOCK"
        }
      }
    ]
  }
}

A política atualizada é aplicada a todos os dispositivos que a usam. O ADP avalia as regras em cada dispositivo sempre que uma atualização está disponível para um componente controlado.

Recuperar a política de UUC

Para ler as regras de UUC configuradas, chame enterprises.policies.get e inspecione o campo unifiedUpdatePolicy da política retornada:

GET https://androidmanagement.googleapis.com/v1/enterprises/{enterpriseId}/policies/{policyId}

Limpar a política de UUC

Para remover todas as regras de UUC de uma política, chame enterprises.policies.patch com updateMask=unifiedUpdatePolicy e um corpo de solicitação que não contenha unifiedUpdatePolicy:

PATCH https://androidmanagement.googleapis.com/v1/enterprises/{enterpriseId}/policies/{policyId}?updateMask=unifiedUpdatePolicy

{}

Exemplos de configuração de política

Os exemplos a seguir mostram o objeto unifiedUpdatePolicy para cenários comuns. Aplique-as com enterprises.policies.patch, conforme descrito em Definir a política de UUC. Os mesmos cenários estão disponíveis como código Kotlin e Java em Configurar controles de atualização unificados com o SDK da AMAPI.

Bloquear atualizações importantes do SO durante o horário de funcionamento

A regra a seguir bloqueia as principais atualizações do SO (OS_UPDATE_WITH_API_LEVEL_CHANGE) das 9h às 17h, de segunda a sexta-feira:

{
  "unifiedUpdatePolicy": {
    "rules": [
      {
        "id": "Block Policy",
        "targets": [
          {
            "targetType": "OS_UPDATE_WITH_API_LEVEL_CHANGE"
          }
        ],
        "predicate": {
          "daysOfWeek": [
            "MONDAY",
            "TUESDAY",
            "WEDNESDAY",
            "THURSDAY",
            "FRIDAY"
          ],
          "timeOfDayLowerBound": { "hours": 9 },
          "timeOfDayUpperBound": { "hours": 17 }
        },
        "outcome": {
          "outcomeType": "BLOCK"
        }
      }
    ]
  }
}

Forçar atualizações do SO por idade da atualização

A regra a seguir força as principais atualizações do SO que estão disponíveis para o dispositivo há até sete dias (604800s):

{
  "unifiedUpdatePolicy": {
    "rules": [
      {
        "id": "Force Policy",
        "targets": [
          {
            "targetType": "OS_UPDATE_WITH_API_LEVEL_CHANGE"
          }
        ],
        "predicate": {
          "updateAgeUpperBound": "604800s"
        },
        "outcome": {
          "outcomeType": "FORCE"
        }
      }
    ]
  }
}

Bloquear atualizações de um único app de serviço do sistema do Google

Para controlar um app específico que faz parte dos serviços do sistema do Google, como o WebView do sistema Android (com.google.android.webview), defina targetType como SINGLE_APP e forneça o packageName do app em singleApp. A regra a seguir bloqueia as atualizações do WebView das 9h às 17h, de segunda a sexta-feira:

{
  "unifiedUpdatePolicy": {
    "rules": [
      {
        "id": "Block Webview Policy",
        "targets": [
          {
            "targetType": "SINGLE_APP",
            "singleApp": {
              "packageName": "com.google.android.webview"
            }
          }
        ],
        "predicate": {
          "daysOfWeek": [
            "MONDAY",
            "TUESDAY",
            "WEDNESDAY",
            "THURSDAY",
            "FRIDAY"
          ],
          "timeOfDayLowerBound": { "hours": 9 },
          "timeOfDayUpperBound": { "hours": 17 }
        },
        "outcome": {
          "outcomeType": "BLOCK"
        }
      }
    ]
  }
}

Combinar várias regras em todas as segmentações de atualização

Como as regras são avaliadas em ordem, é possível combinar várias regras para bloquear atualizações durante janelas específicas e forçar atualizações fora delas.

O exemplo a seguir aplica duas regras sequenciais nas quatro segmentações por categoria (OS_UPDATE_WITH_API_LEVEL_CHANGE, OS_UPDATE_WITHOUT_API_LEVEL_CHANGE, GOOGLE_SYSTEM_SERVICES e GOOGLE_PLAY_SYSTEM_UPDATE):

1. Bloqueie todas as atualizações durante o horário de funcionamento (de segunda a sexta-feira, das 9h às 17h).
2. Fora do horário de funcionamento, force as atualizações que estão disponíveis há até sete dias.

{
  "unifiedUpdatePolicy": {
    "rules": [
      {
        "id": "Block Policy - rule1",
        "targets": [
          { "targetType": "OS_UPDATE_WITH_API_LEVEL_CHANGE" },
          { "targetType": "OS_UPDATE_WITHOUT_API_LEVEL_CHANGE" },
          { "targetType": "GOOGLE_SYSTEM_SERVICES" },
          { "targetType": "GOOGLE_PLAY_SYSTEM_UPDATE" }
        ],
        "predicate": {
          "daysOfWeek": [
            "MONDAY",
            "TUESDAY",
            "WEDNESDAY",
            "THURSDAY",
            "FRIDAY"
          ],
          "timeOfDayLowerBound": { "hours": 9 },
          "timeOfDayUpperBound": { "hours": 17 }
        },
        "outcome": {
          "outcomeType": "BLOCK"
        }
      },
      {
        "id": "Force Policy - rule2",
        "targets": [
          { "targetType": "OS_UPDATE_WITH_API_LEVEL_CHANGE" },
          { "targetType": "OS_UPDATE_WITHOUT_API_LEVEL_CHANGE" },
          { "targetType": "GOOGLE_SYSTEM_SERVICES" },
          { "targetType": "GOOGLE_PLAY_SYSTEM_UPDATE" }
        ],
        "predicate": {
          "updateAgeUpperBound": "604800s"
        },
        "outcome": {
          "outcomeType": "FORCE"
        }
      }
    ]
  }
}

Restringir atualizações até uma data específica

É possível usar dateLowerBound e dateUpperBound para restringir ou permitir atualizações em um período específico do calendário no fuso horário local do dispositivo. A regra a seguir bloqueia as atualizações para as quatro segmentações por categoria até 14 de março de 2026:

{
  "unifiedUpdatePolicy": {
    "rules": [
      {
        "id": "block_until_date",
        "targets": [
          { "targetType": "OS_UPDATE_WITH_API_LEVEL_CHANGE" },
          { "targetType": "OS_UPDATE_WITHOUT_API_LEVEL_CHANGE" },
          { "targetType": "GOOGLE_SYSTEM_SERVICES" },
          { "targetType": "GOOGLE_PLAY_SYSTEM_UPDATE" }
        ],
        "predicate": {
          "dateUpperBound": { "year": 2026, "month": 3, "day": 14 }
        },
        "outcome": {
          "outcomeType": "BLOCK"
        }
      }
    ]
  }
}