--- title: "Android ganha painel unificado para empresas enxergarem a segurança dos dispositivos" author: "Gustavo Ramos O. Klein" date: "2026-09-19 08:00:00-03" category: "Segurança & Privacidade" url: "http://desbugados.scale.press/portal/desbugados/post/2026/09/19/android-ganha-painel-unificado-para-empresas-enxergarem-a-seguranca-dos-dispositivos/md" --- ## Resumo - O Google anunciou em 17 de setembro de 2026 as bibliotecas AndroidX Security State 1.1.0 e Security State Provider 1.0.0. - A proposta substitui a dependência de um único indicador de nível de patch de segurança, o SPL. - O sistema detalha o estado de segurança do sistema operacional, dos módulos do Project Mainline e do kernel. - DSPL mostra o patch instalado, PSPL indica o nível publicado mais recente e ASPL registra o nível disponível para instalação. - A solução permite verificar a correção de CVEs específicos e registrar correções retroativas declaradas por fabricantes. - Aplicativos bancários, serviços financeiros e ferramentas MDM poderão avaliar o estado real do dispositivo antes de liberar dados sensíveis. - A integração já existe com atualizações do Google Play, enquanto a adoção pelos clientes de atualização dos fabricantes continua em expansão. --- O **[Google](https://blog.google/security/android-security-state-libraries)** anunciou em **17 de setembro de 2026** a disponibilização em versão estável das bibliotecas AndroidX Security State 1.1.0 e Security State Provider 1.0.0, uma camada padronizada para que empresas e aplicativos consultem o estado de segurança de dispositivos Android. A novidade responde a um problema prático: o SPL, ou nível de patch de segurança, concentra a leitura em um único indicador, enquanto a nova proposta separa a análise por componente. A documentação técnica registra ainda que as bibliotecas chegaram ao repositório Maven em 9 de setembro de 2026. O que muda para quem administra celulares corporativos? Em vez de interpretar uma data isolada, será possível consultar quais correções foram instaladas, publicadas ou disponibilizadas para instalação, conforme a integração de cada componente. ## O que o Android passa a enxergar Até aqui, o modelo baseado em um único **SPL** oferecia uma referência geral para o nível de atualização do aparelho, mas não apresentava, na mesma leitura, a situação individual de cada parte do sistema. As bibliotecas Security State e Security State Provider foram criadas justamente para substituir essa dependência e oferecer uma visão mais detalhada. A nova abordagem considera o **sistema operacional** e os módulos de sistema do Project Mainline, conjunto de componentes que recebe atualizações separadas dentro do Android. Essa divisão aproxima a consulta técnica da pergunta que uma equipe de segurança realmente precisa responder: qual parte do dispositivo está corrigida e qual ainda depende de uma atualização? Essa decomposição também alcança o **kernel**, a camada central responsável por intermediar o funcionamento do sistema, além dos demais componentes monitorados. Em vez de tratar o telefone como uma caixa única, a solução permite avaliar patches instalados, publicados e pendentes. Patch, neste contexto, é uma correção distribuída para tratar problemas de segurança. A diferença prática está na qualidade da conversa entre o dispositivo e as ferramentas que precisam avaliá-lo: uma plataforma de gestão passa a receber informações sobre o estado de partes específicas, e não apenas uma data geral associada ao aparelho. É essa leitura mais granular que sustenta as métricas introduzidas pelo Google. ## As três métricas que montam a leitura A primeira métrica é o **DSPL**, sigla de Device SPL, que informa o nível de patch instalado e em execução no dispositivo. Ele responde à pergunta mais direta da verificação: qual correção está efetivamente ativa naquele componente? A informação descreve o estado presente do aparelho, permitindo distinguir aquilo que já foi aplicado do que apenas foi anunciado ou disponibilizado. Essa diferença importa porque uma atualização publicada por um fabricante não significa, por si só, que ela já esteja instalada no celular analisado. O DSPL funciona como o ponto de partida da conversa entre o dispositivo e o aplicativo que consulta sua segurança. Na sequência, o **PSPL**, ou Published SPL, indica o nível de patch mais recente registrado no boletim oficial. Ele funciona como uma referência externa para comparar o que o componente está executando com a correção mais nova publicada. Se o DSPL responde ao que está instalado, o PSPL mostra qual é o nível reconhecido como mais recente no boletim. A separação entre essas duas informações evita que uma única data esconda a diferença entre o estado atual e a atualização oficialmente publicada. Para a equipe responsável por políticas de acesso, essa comparação oferece uma base mais clara para identificar defasagens. A terceira métrica é o **ASPL**, ou Available SPL, que mostra o nível disponível para instalação por meio do cliente de atualização. Aqui aparece uma distinção adicional: o patch pode já estar publicado, mas ainda depender do mecanismo que o disponibiliza ao aparelho. O ASPL registra essa disponibilidade e ajuda a diferenciar uma correção que ainda não chegou ao fluxo de instalação daquela que já pode ser aplicada. Com DSPL, PSPL e ASPL consultados por componente, a análise deixa de depender de uma única fotografia e passa a reunir o que está ativo, o que foi publicado e o que está disponível para instalação. ## Como aplicativos e fabricantes usam os dados Com essa leitura por componente, o mecanismo também permite verificar se **CVEs específicos** foram corrigidos. CVE é o identificador usado para localizar uma falha de segurança conhecida, e a consulta direcionada permite relacionar a vulnerabilidade ao estado informado pelo dispositivo. O sistema ainda suporta correções retroativas, chamadas de backported, declaradas pelos fabricantes por meio de arquivos XML. Essa possibilidade atende a situações em que a correção de uma falha precisa ser registrada mesmo quando a numeração geral do patch não conta toda a história. A análise deixa de perguntar apenas qual é a data do aparelho e passa a investigar se a falha que interessa foi tratada. A camada de publicação complementa essa verificação ao permitir que os **fabricantes dos aparelhos, chamados de OEMs**, declarem a disponibilidade de correções retroativas em arquivos XML. O formato padronizado dá ao sistema uma maneira de receber essa informação e apresentá-la às ferramentas que consultam o estado de segurança. O papel dessa biblioteca é diferente do papel da biblioteca voltada aos aplicativos: uma organiza a informação fornecida pelos fabricantes, enquanto a outra permite que os consumidores dessa informação façam a avaliação. Essa separação cria uma ponte entre quem produz a atualização e quem precisa decidir se um dispositivo pode acessar determinado recurso. Do lado dos aplicativos, a biblioteca **androidx.security.state** foi direcionada a serviços sensíveis à segurança e a ferramentas de gerenciamento de dispositivos, conhecidas como MDM. Em termos práticos, uma solução MDM administra aparelhos usados por uma organização e precisa saber se eles atendem às regras internas antes de permitir determinadas ações. A documentação cita aplicativos bancários, serviços financeiros e soluções de gestão como exemplos de consumidores dessa informação. Esses sistemas poderão basear decisões de acesso a dados sensíveis no estado real de segurança do dispositivo, em vez de considerar somente uma data genérica de patch. A qualidade da decisão passa a depender da informação que o aparelho consegue apresentar. Do outro lado dessa ponte está a biblioteca **androidx.security.state.provider**, voltada aos OEMs e aos desenvolvedores de clientes de atualização OTA. OTA é a distribuição de atualizações diretamente para o dispositivo, sem que o usuário precise instalar o pacote por outro meio. O objetivo do provider é permitir que esses clientes publiquem, de forma padronizada, a disponibilidade de atualizações para o sistema. Assim, o aplicativo que consulta a segurança e o fabricante que disponibiliza a correção passam a falar por meio de uma estrutura comum. Essa interoperabilidade reduz a distância entre o dado técnico da atualização e a decisão tomada por um serviço que depende dele. ## O que muda para as empresas agora A conexão já começou com as atualizações do **Google Play System Updates** e com o Google Over-The-Air, identificado como GOTA. Isso significa que parte dos mecanismos de atualização do próprio Google já está integrada à leitura proposta pelas bibliotecas. A integração com clientes de atualização dos fabricantes ainda está em expansão, portanto a cobertura não depende apenas da existência das bibliotecas, mas também da adoção do provider por quem distribui atualizações para os aparelhos. Para as empresas, essa diferença ajuda a calibrar expectativas: o padrão estável já existe, enquanto a participação dos fabricantes continua sendo ampliada. Para uma organização, a consequência mais concreta aparece em políticas de acesso baseadas no modelo **"zero trust"**, no qual cada acesso precisa ser avaliado com base em evidências do dispositivo. Um aplicativo bancário pode consultar se uma falha específica foi corrigida; uma ferramenta MDM pode verificar o nível instalado antes de liberar dados sensíveis; e o fabricante pode informar que uma correção está disponível para instalação. O próximo passo anunciado é a expansão da integração dos clientes de atualização dos OEMs, enquanto as bibliotecas já oferecem as métricas necessárias para separar o que está instalado, publicado e disponível. O painel unificado começa, portanto, como uma linguagem comum entre atualização, gerenciamento e decisão de acesso.