EDLA versus GMS versus AOSP: o que cada termo significa para dispositivos empresariais

Resposta Direta

EDLA, GMS e AOSP não são três sistemas operacionais Android equivalentes. O AOSP é a base de plataforma de código aberto. O GMS é um conjunto de aplicativos e APIs do Google licenciado separadamente e adicionado a uma build Android. Materiais públicos de OEMs e parceiros descrevem o EDLA como uma via de licenciamento para categorias elegíveis de dispositivos empresariais embarcarem essa camada GMS. Esta análise não localizou uma especificação pública geral do Google para o EDLA que cubra elegibilidade, testes, taxas e escopo de modelos; trate o EDLA como uma alegação que exige evidências específicas do modelo, fornecidas pelo OEM ou pela contraparte de licenciamento aplicável.

Comece com um Modelo em Camadas, Não com Três Opções Paralelas

O rótulo de um folheto indica ao comprador qual pergunta fazer; ele não responde a todas as perguntas do projeto. Trate os termos como camadas diferentes.

Como as Camadas se Relacionam

Um dispositivo comercializado como EDLA continua sendo baseado em Android. A decisão não é “EDLA ou GMS ou AOSP”. Pergunte qual build Android o dispositivo usa, se a camada Google está legitimamente licenciada, qual via se aplica à categoria do dispositivo e se os requisitos do projeto foram validados.

O que o AOSP Significa

A visão geral do AOSP descreve o código-fonte do Android disponível publicamente e modificável, a partir do qual fabricantes de dispositivos podem criar variantes. O programa de Compatibilidade Android exige separadamente o Documento de Definição de Compatibilidade (CDD) aplicável e o CTS para a compatibilidade Android. Isso comprova que o AOSP pode servir de base de plataforma e que a compatibilidade é um estado adicional que precisa ser evidenciado. Não comprova licenciamento GMS, comportamento de aplicativos, gerenciamento empresarial, atualizações, nem que uma build AOSP seja exclusivamente offline ou restrita a aplicativos privados. Identifique a build exata, as dependências de distribuição e de nuvem, as evidências de compatibilidade, os testes de aplicativos, a via de gerenciamento e o responsável pelo ciclo de vida, em vez de aceitar “AOSP” como uma arquitetura completa.

O que o GMS Significa

O Google define o Google Mobile Services como um conjunto licenciado de aplicativos e APIs do Google que não faz parte do AOSP; o conjunto pode variar conforme a disponibilidade e os requisitos de cada país. O Google Play services é uma camada de serviços no dispositivo usada pelos SDKs do Google, e não é sinônimo de todo o GMS. Uma alegação legítima de GMS identifica uma camada de software Google licenciada, mas não comprova que todos os aplicativos, SDKs, fluxos de conta, canais de aplicativos gerenciados ou veredictos do Play Integrity exigidos funcionem para o aplicativo e o mercado em questão.

• Inventarie os aplicativos, APIs, contas, canal de distribuição, serviços em segundo plano, comportamento offline e chamadas de integridade exigidos; teste-os na build cotada.
• Não carregue um requisito de integridade obsoleto para um novo briefing: o Google declara que o SafetyNet Attestation foi totalmente desativado em janeiro de 2025.
• Registre e teste a implementação do Play Integrity no aplicativo de produção, em vez de deduzi-la a partir do rótulo do dispositivo.

O que o EDLA Significa — e o que as Evidências Públicas Não Dizem

O texto explicativo sobre EDLA da BenQ descreve o EDLA como o que permite o GMS embutido em soluções empresariais como lousas inteligentes, e a página de parceiros da Kuori descreve uma parceria EDLA para displays comerciais compatíveis com GMS. A página pública de parceiros do Android Enterprise do Google direciona alguns requisitos de programas de dispositivos a materiais de parceiros ou contatos comerciais, em vez de publicar uma especificação geral do EDLA. Essas fontes de fornecedores e parceiros comprovam um uso de mercado documentado em torno de serviços Google licenciados em categorias elegíveis de dispositivos empresariais. Elas não comprovam os termos contratuais privados do Google, a elegibilidade universal, o status de outro fornecedor, nem o status de todo quiosque, display, terminal, telefone ou tablet.

• Trate a BenQ e a Kuori como descrições de fornecedor/parceiro, não como termos oficiais do programa do Google.
• Exija uma declaração que especifique o modelo exato, o SKU, a versão do Android, a build, o mercado, o responsável pela alegação e as evidências aplicáveis.
• Não aceite uma frase de folheto ou o ícone visível da Play Store como evidência suficiente.

Quando o EDLA É Relevante

Os exemplos públicos de EDLA analisados aqui se concentram em displays interativos e comerciais. Isso justifica perguntar sobre o EDLA quando um fornecedor o invoca para uma categoria de dispositivo empresarial fora do caminho habitual de telefones ou tablets; isso não estabelece uma lista completa de dispositivos elegíveis. Para um telefone, tablet ou dispositivo portátil convencional, pergunte se a build exata de embarque é legitimamente licenciada com GMS e certificada Play Protect. Essa verificação comprova um estado de certificação observado, não o comportamento do EMM, a duração das atualizações, a aprovação regional ou o fluxo de trabalho em campo. Registre o resultado associado ao modelo/SKU/build e, em seguida, use o guia de decisão de implantação GMS versus AOSP para avaliar a adequação de aplicativo, gerenciamento, provisionamento e ciclo de vida.

Aplique Cinco Portões Antes de uma Cotação ou Decisão sobre Amostra

Use esses portões para um display comercializado como EDLA, um dispositivo portátil GMS convencional ou um terminal industrial baseado em AOSP. Cada portão produz um registro que pode ser testado ou contestado antes de o projeto se tornar um compromisso de compra.

1. 1Congele a linha de base do dispositivo: registre o fator de forma, o fabricante, o modelo exato e o SKU regional, a versão do Android, o número de firmware/build, o nível de patch de segurança e qualquer unidade de computação modular.
2. 2Audite as dependências de aplicativo e serviço: liste todos os aplicativos Google, SDKs, fluxos de conta, canais de distribuição, serviços em segundo plano e comportamentos offline exigidos; teste o aplicativo real.
3. 3Verifique as evidências de licenciamento aplicáveis: identifique o responsável pela alegação e o modelo/build/mercado exatos que ela cobre; separe o uso da fonte AOSP, a compatibilidade Android, a certificação Play Protect, o licenciamento GMS e o status EDLA descrito pelo fornecedor.
4. 4Valide o gerenciamento e a inscrição separadamente: identifique o modo de propriedade, o EMM, o DPC ou agente, o canal de aplicativos, o requisito de modo quiosque, a via de provisionamento, o modelo de conta e o procedimento de recuperação.
5. 5Confirme a região e o ciclo de vida: registre a disponibilidade por país, o responsável pelas atualizações, a declaração de suporte de SO e segurança, a via de OTA, o comportamento de redefinição, o caminho de substituição, as limitações conhecidas e os gatilhos de revalidação.

Mantenha o Android Enterprise, o EMM, o Zero-Touch e o AER Separados

A visão geral do Android Enterprise do Google descreve um console de EMM, um componente de política no dispositivo e o Google Play gerenciado. A visão geral de gerenciamento de dispositivos do AOSP documenta os conceitos de proprietário do dispositivo, proprietário do perfil, DPC e estrutura de políticas. Os requisitos do Android Enterprise Recommended são um sinal de programa separado e versionado. Licenciamento, arquitetura de gerenciamento, provisionamento e AER são, portanto, camadas de evidência distintas.

Aceite Evidências, Não Rótulos

Antes de aprovar uma amostra, colete evidências não confidenciais que possam acompanhar o dispositivo até a produção. A amostra deve comprovar o fluxo de trabalho exigido, não todas as capacidades sugeridas por um rótulo.

Atribua as Responsabilidades

Este é um modelo de planejamento, não um contrato universal. A Vantora pode coordenar uma análise de viabilidade de plataforma e ajudar a transformar alegações em requisitos testáveis. Ela não concede licenças do Google, não certifica dispositivos EDLA, não opera o locatário de EMM de um cliente nem promete uma via de licenciamento para todos os modelos.

Solicite uma Análise de Viabilidade de Plataforma

Compartilhe um briefing com dados sensíveis removidos, contendo a categoria do dispositivo, o modelo/SKU candidato, os países-alvo, a faixa de quantidade, a build Android, as dependências de aplicativo, os serviços Google exigidos, a pilha de gerenciamento, as expectativas de atualização e as prioridades de aceitação. Nomes de clientes finais e material de licença privado não são necessários para uma análise inicial. O guia de métodos de provisionamento de dispositivos Android pode ajudar a definir a próxima decisão de gerenciamento e inscrição.