LiteRT no Google Play services: apps Android menores e GPU mais rápida

A atualização do LiteRT publicada pelo Google em 28 de outubro de 2026 é importante para quem desenvolve Android porque muda onde fica a infraestrutura de machine learning no dispositivo. Aplicativos elegíveis não precisam mais empacotar o runtime completo do LiteRT e o acelerador de GPU dentro do próprio aplicativo; eles podem usar o LiteRT no Google Play services. O resultado prático é um download menor, um runtime compartilhado que pode ser atualizado separadamente e um caminho mais claro para inferência por GPU usando a API moderna CompiledModel.

O que mudou no LiteRT do Google Play services

LiteRT é o runtime de inferência no dispositivo do Android para modelos de machine learning personalizados. O Google afirma que ele processa mais de um trilhão de inferências por dia em bilhões de dispositivos. A nova versão adiciona inferência por GPU alimentada pelo ML Drift, com desempenho cerca de 1,4 vez maior que o antigo GPU delegate nos testes do Google. O novo caminho usa CompiledModel, sucessor moderno da antiga API Interpreter.

A outra mudança importante é o empacotamento. Nos testes do Google, aplicativos que trocaram uma cópia própria do LiteRT pelo runtime do Play services ficaram cerca de 8 MB menores. O runtime e o acelerador de GPU são distribuídos uma vez pelo Google Play services, em vez de serem repetidos em cada APK. O Google também diz que mais de 100 mil aplicativos Android ainda empacotam sua própria cópia do LiteRT ou TensorFlow Lite, então pequenas economias podem se acumular em grande escala.

Isso não significa que todo aplicativo ficará exatamente 8 MB menor. O resultado depende dos modelos, bibliotecas, configuração de ABI e outras dependências. A decisão correta é medir o tamanho de download e instalação antes e depois da migração, sem transformar o número divulgado em garantia.

Por que um runtime compartilhado ajuda

Um runtime compartilhado responde a três restrições comuns do mobile: tamanho do download, armazenamento do aparelho e coordenação de atualizações. Remover uma biblioteca de inferência duplicada pode acelerar a primeira instalação e deixar mais espaço para os dados do usuário. A equipe também passa a empacotar e testar menos binários nativos por arquitetura.

Há ainda um segundo benefício: atualizações do runtime podem chegar pelo componente da plataforma, sem esperar que cada equipe publique um novo APK ou App Bundle. Isso não elimina o trabalho de compatibilidade do aplicativo. É preciso validar saídas do modelo, fallback, permissões e cobertura de dispositivos. A vantagem é que o calendário do runtime fica menos preso ao calendário de lançamento do app.

O Google cita o aplicativo Google AI Edge Gallery como exemplo real. O recurso Scrapbook usa LiteRT no Google Play services para segmentação de imagens, oferecendo uma referência de IA no dispositivo voltada ao usuário final, não apenas um benchmark.

CompiledModel é o destino da migração

Equipes que usam a antiga API Interpreter podem continuar executando esse código na CPU ao mudar para o pacote do Play services. Para usar a GPU, é necessário migrar para CompiledModel e passar o ambiente LiteRT ao criar o CompiledModel. A lógica geral pode permanecer parecida, mas a migração ainda exige revisão: inspecionar o diff, compilar o app, comparar saídas e testar em aparelhos físicos representativos.

O Agent Mode do Android Studio agora inclui uma skill do LiteRT para automatizar a primeira etapa. O desenvolvedor pode pedir a migração de código TensorFlow Lite para CompiledModel ou usar @litert-runtime. A skill atualiza dependências, reescreve chamadas Interpreter, configura GPU com fallback de CPU e pode criar um novo app LiteRT. O repositório oficial de Android skills no GitHub é um bom ponto de partida, mas alterações geradas devem ser tratadas como rascunho.

Checklist para uma migração segura

Registre primeiro tamanho de download, tamanho instalado, tempo de inicialização a frio, latência da primeira inferência, comportamento sustentado da GPU, consumo de bateria e precisão do modelo. Depois identifique quais modelos e APIs realmente rodam na CPU ou GPU; nem todo modelo se beneficia do mesmo delegate ou caminho de execução.

Migre uma funcionalidade pequena antes de alterar o aplicativo inteiro. Mantenha um fallback de CPU, compare as saídas dentro de uma tolerância definida e teste cenários de pouca memória e aparelhos antigos. Verifique se a disponibilidade e o comportamento de versão do Google Play services correspondem aos países e aparelhos atendidos. Por fim, use uma barreira de release para conferir o App Bundle, erros do runtime, latência e qualidade do modelo antes de ampliar a distribuição.

O calendário de descontinuação também importa. O Google diz que o antigo GPU delegate e as APIs de delegate personalizado estão obsoletos em favor da aceleração GPU do CompiledModel, do Compiler Plugin e das APIs Dispatch. O NNAPI será removido a partir de 2027. SDKs antigos recebem apenas correções críticas de segurança. Versões já publicadas continuam funcionando, mas código com APIs obsoletas pode deixar de compilar contra o SDK mais recente.

Para comparar ferramentas Android, apps de IA e software para dispositivos, visite o catálogo de software da BTTC e os guias do blog de tecnologia da BTTC.

Perguntas frequentes

A conclusão é direta: LiteRT no Google Play services tira a infraestrutura comum de inferência de cada APK e a coloca em um canal compartilhado do Android. A oportunidade é reduzir o tamanho do app e acelerar a GPU; a responsabilidade continua sendo validar compatibilidade, qualidade do modelo e comportamento em aparelhos reais antes do lançamento.