Atualizações OTA silenciosas em toda uma frota

"Atualização OTA" (over-the-air) é um termo muito usado e pouco explicado. Para quem gerencia uma frota de Android TV Box, a pergunta que importa não é o que significa, e sim: consigo atualizar mil dispositivos sem que ninguém note que algo aconteceu, e sem ir fisicamente a nenhum deles?

Por que instalar um app no Android não é trivial a distância

Em um telefone normal, instalar ou atualizar um app exige que o usuário toque em "Instalar" e confirme a caixa de diálogo de permissões. O Android é projetado assim de propósito: para que nenhum app consiga instalar outro sem a aprovação do usuário. Essa é uma boa decisão de segurança para um telefone pessoal, e um problema sério quando você precisa atualizar 500 STBs em hotéis e não há nenhum humano na frente da tela para tocar em "Aceitar".

Há dois caminhos técnicos para resolver isso:

• Via app de sistema com permissões elevadas. Se o agente de gestão está instalado como app de sistema (parte da imagem do dispositivo, não um app baixado pelo usuário), ele pode usar a API PackageInstaller do Android para instalar pacotes sem mostrar a caixa de confirmação ao usuário. Essa é a forma mais limpa e não exige root.
• Via acesso root. Em dispositivos com root, o agente pode instalar pacotes diretamente no nível de sistema. Funciona, mas depende de o dispositivo ter root habilitado — algo que muitos fabricantes bloqueiam ou que se perde na próxima atualização de firmware do fabricante.

Uma plataforma séria suporta os dois caminhos e prioriza o primeiro, porque ele continua funcionando mesmo quando o dispositivo perde o root ou nunca teve.

O que uma atualização remota bem feita precisa garantir

1. Zero interação do usuário. Nenhuma caixa de diálogo, nenhuma notificação que interrompa o que está na tela.
2. Confirmação de resultado. O sistema central precisa saber, dispositivo por dispositivo, se a atualização foi aplicada corretamente ou falhou — não presumir isso.
3. Novas tentativas sem intervenção manual. Se um dispositivo estava desligado ou sem conexão durante a implantação, ele precisa receber a atualização no próximo check-in, sem que alguém tenha que disparar o comando novamente.
4. Possibilidade de reversão. Se uma atualização introduzir um bug crítico, precisa existir uma forma de voltar à versão anterior em toda a frota, não só no dispositivo onde você notou primeiro.

Como o AdminSTB resolve isso

O pipeline de atualizações do AdminSTB usa o app de sistema instalado no dispositivo para aplicar o pacote via PackageInstaller, sem interação do usuário. Se o dispositivo não tiver o agente como app de sistema, ele faz fallback para instalação via root quando disponível. Em ambos os casos, o resultado de cada atualização é reportado no ciclo de telemetria seguinte, então o dashboard sempre reflete qual versão cada dispositivo está executando — não uma suposição.

É o mesmo mecanismo que permite atualizar clientes de IPTV, apps de sinalização digital ou o próprio agente em toda a frota a partir de um único comando no dashboard, sem coordenar visitas nem depender de o usuário final fazer algo.