O Google Play em breve forçará os desenvolvedores a fazer upload de App Bundles em vez de APKs, levantando questões de segurança incômodas sobre o requisito.
Novembro passado, Google anunciou que os desenvolvedores serão obrigados a publicar novos aplicativos na Play Store usando o formato Android App Bundle (AAB) em vez de um APK. Outro dia, o Google lembrou aos desenvolvedores esse próximo requisito, desencadeando uma tempestade de controvérsias de usuários que acreditam que o Google está eliminando APKs, eliminando o sideload, prejudicando lojas de aplicativos de terceiros e tudo mais.
É verdade que os Android App Bundles são muito diferentes do formato APK clássico com o qual você está acostumado, tanto como usuário quanto como desenvolvedor. Embora existam alguns benefícios em usar App Bundles, há um aspecto importante em criá-los que preocupa alguns desenvolvedores e especialistas em segurança.
Neste artigo, abordaremos as críticas que vimos à mudança para Android App Bundles, bem como algumas soluções propostas, e também falaremos sobre a solução proposta pelo Google para esses problemas.
Fundo
Antes que isso aconteça, precisamos falar um pouco sobre como funciona a distribuição de aplicativos no Android em geral. Se você já sabe como funcionam a assinatura de aplicativos e os App Bundles, pode pular esta parte.
APKs
Na maioria das vezes, os aplicativos Android são distribuídos dentro de arquivos APK. Um APK contém todos os códigos e recursos de um aplicativo, além de alguns recursos de segurança, como um manifesto de assinatura. Quando um APK é instalado, ele basicamente é copiado para uma pasta específica e adicionado a um banco de dados interno de aplicativos instalados.
Assinaturas
Durante a instalação, a assinatura desse aplicativo também é verificada para garantir que seja válida. Se o aplicativo já estiver instalado, o Android compara a assinatura do novo aplicativo com o que já está instalado. Se a assinatura não for válida ou não corresponder, o Android se recusará a instalar o aplicativo.
Essa verificação de assinatura é uma parte importante da segurança no Android. Isso garante que o aplicativo que você está instalando seja válido e pelo menos da mesma fonte daquele que você já instalou. Por exemplo, se você instalar, digamos, meu aplicativo Lockscreen Widgets da Play Store, você pode ter certeza razoável de que fui eu quem o assinou e que é autêntico. Se você tentar instalar uma atualização para Lockscreen Widgets de algum site obscuro de terceiros e ela falhar, você saberá que alguém violou esse APK, possivelmente para adicionar malware.
A chave usada para assinar um aplicativo é (idealmente) nunca divulgado publicamente. Isso é conhecido como chave privada. A chave privada é então usada para gerar a chave mostrada na assinatura do aplicativo, conhecida como chave pública. É isso que o Android e as lojas de aplicativos usam para verificar a validade de um aplicativo. Não vou entrar em detalhes sobre como exatamente você pode gerar uma chave pública sem expor a chave privada, pois isso envolve muita matemática de criptografia. Se você quiser mais detalhes, confira Documentação do Google sobre assinatura de APKs ou faça alguma pesquisa sobre funções matemáticas unidirecionais.
Outro recurso das assinaturas de aplicativos é a capacidade de restringir permissões apenas a aplicativos com assinaturas correspondentes. O Android faz isso internamente para muitas funções, onde apenas aplicativos assinados com a mesma chave da estrutura podem acessar determinados recursos.
Pacotes de aplicativos
Agora que demos uma visão geral rápida de APKs e assinaturas, vamos falar sobre App Bundles. É aqui que entram os recursos do APK. Recursos são coisas como layouts, imagens, áudio, etc. Basicamente, eles são qualquer coisa que não seja código. Para melhor suportar diferentes configurações de exibição e diferentes idiomas, os desenvolvedores podem criar várias versões do mesmo recurso que são usadas dependendo do dispositivo e do idioma.
Mas em um APK, todos esses recursos existem, não importa qual você use. E eles ocupam espaço. Dependendo da complexidade do seu aplicativo, pode haver muitos recursos não utilizados para vários dispositivos. É para isso que os App Bundles foram criados. Os desenvolvedores podem gerar um App Bundle assim como um APK, e esse App Bundle pode então ser carregado na Play Store, assim como um APK.
O Google então usa esse App Bundle para gerar vários APKs diferentes para diferentes configurações de dispositivos. Cada App Bundle contém apenas os recursos necessários para essa configuração. Quando um usuário baixa esse aplicativo, ele recebe o APK gerado que corresponde à sua configuração. Isso ajuda a reduzir o tamanho de download e instalação de aplicativos, economizando largura de banda e espaço de armazenamento.
Obviamente, instalar um APK específico para o seu dispositivo significa que será mais difícil copiá-lo para outro dispositivo e instalá-lo sem problemas. Dependendo da sua perspectiva, isso pode ser bom ou ruim. Por um lado, dificulta a pirataria, já que os usuários não possuem mais o aplicativo completo. Por outro lado, torna mais difícil o arquivamento legítimo de aplicativos, pelo mesmo motivo.
Assinatura de aplicativos
Como os Android App Bundles não são APKs, você não pode simplesmente abrir um arquivo AAB e instalá-lo diretamente em um dispositivo. Quando você carrega um na Play Store, o Google usa o pacote para gerar diferentes arquivos APK (não assinados). Esses APKs devem ser assinados antes de serem instalados.
Em vez de pedir ao desenvolvedor para assinar e recarregar os APKs gerados, o Google gerencia a assinatura por conta própria. A Play Store usa uma nova chave criada ou pede ao desenvolvedor a chave que ele usa para assinar APKs. Com qualquer uma das opções, o Google cuida da assinatura pública para o desenvolvedor e fornece um upload chave. O Google usa a chave de upload para verificação interna e garante que o App Bundle (ou APK em alguns casos) que o desenvolvedor está enviando é o correto.
Se uma chave de upload for comprometida ou perdida, os desenvolvedores poderão solicitar uma nova, e a chave de assinatura usada para distribuir o aplicativo permanecerá inalterada.
Há muito mais sobre a assinatura de aplicativos, mas isso é relevante para este artigo. Se desejar, você pode ler mais sobre App Bundles e App Signing em este artigo do Medium por Wojtek Kaliciński.
Crítica
Na teoria e na prática, os App Bundles são ótimos. Eles reduzem o uso de dados e o tamanho da instalação, tudo sem que o usuário precise fazer nada. Mas devido à forma como é implementado, alguns desenvolvedores e pesquisadores de segurança levantaram preocupações nos últimos meses. Antes de resumir essas preocupações, gostaria de dizer que a maior parte do que está escrito abaixo é diretamente baseado em uma série de artigos pelo desenvolvedor Mark Murphy de CommonsWare. Você definitivamente deveria conferir seus artigos, pois eles trazem mais detalhes e críticas da perspectiva de um desenvolvedor.
Segurança
No modelo de distribuição clássico, um desenvolvedor mantém privada a chave que usa para assinar um APK. Nunca é compartilhado com o público e apenas pessoas autorizadas devem ter acesso a ele. Isso garante que apenas essas pessoas possam gerar um APK válido.
Mas se você usa App Bundles na Play Store, o Google é quem gerencia a chave que assina os APKs que os usuários recebem. O padrão comportamento para novos aplicativos enviados ao Google Play a partir de agosto de 2021 é que o Google crie sua própria chave de distribuição, que mantém privada do desenvolvedor.
Envio de desenvolvedores novos aplicativos farão com que o Google gerencie sua chave privada por padrão, embora os desenvolvedores enviem atualizações para aplicativos existentes pode continuar usando APKs ou eles podem mudar para a distribuição AAB gerando uma nova chave para o Google usar para novos usuários. Aplicativos existentes não são obrigatórios para mudar da distribuição de APK para Android App Bundles, embora essa opção esteja disponível para eles, caso escolham. Depois de alguma resistência, o Google vai até tornar isso possível para fazer upload de sua própria chave privada para o Google assinar, para aplicativos novos e existentes. Nenhuma dessas situações é ideal, pois não importa o que aconteça, o Google terá acesso à sua chave privada se você quiser. use Android App Bundles (e os desenvolvedores não têm escolha se quiserem enviar um novo aplicativo depois de agosto 2021!)
Embora estejamos confiantes de que o Google leva a segurança muito a sério, não há nenhuma empresa no mundo que esteja imune a violações de dados. Se a chave que o Google usa para assinar seu aplicativo para distribuição estiver em uma dessas violações, qualquer pessoa poderá assinar uma versão do seu aplicativo e fazer com que pareça que foi assinado por você. E alguns desenvolvedores e especialistas em segurança não estão satisfeitos com essa possibilidade. É uma possibilidade muito, muito pequena, sim, mas o fato de ser uma possibilidade assusta alguns na comunidade de segurança da informação.
Fazer com que os desenvolvedores assinem APKs do Android significa que qualquer pessoa pode verificar os APKs do Google Play, sem necessidade de confiança cega. É um design elegante que fornece segurança verificável. Os App Bundles invertem isso e parecem estruturados para promover o aprisionamento do fornecedor. Existem muitas abordagens técnicas alternativas que forneceriam pequenos APKs ainda assinados pelos desenvolvedores, mas não dariam preferência ao Play. Por exemplo, todas as variantes do APK podem ser geradas e assinadas pelo desenvolvedor e depois carregadas em qualquer loja de aplicativos.
Certamente há argumentos a serem feitos sobre se é melhor deixar o armazenamento seguro de chaves privadas nas mãos do Google ou de desenvolvedores individuais. Mas esses desenvolvedores (provavelmente) geralmente não usam um repositório central para suas chaves. Ao forçar os desenvolvedores a usar o Play App Signing, um invasor mal-intencionado só precisa violar a segurança do Google uma vez para recuperar milhares ou milhões de chaves.
Para saber se vale a pena, aqui está o que o Google diz sobre como protege sua chave de assinatura em sua infraestrutura:
[blockquote author="Wojtek Kaliciński, Android Developer Advocate no Google"]Quando você usa o Play App Signing, suas chaves são armazenadas na mesma infraestrutura que o Google usa para armazenar suas próprias chaves.
O acesso às chaves é regido por ACLs rigorosas e trilhas de auditoria invioláveis para todas as operações.
Todos os artefatos gerados e assinados com a chave do desenvolvedor são disponibilizados para você no Google Play Console para inspeção/atestado.
Além disso, para evitar a perda de chaves, fazemos backups muito frequentes do nosso armazenamento primário. Esses backups são fortemente criptografados e testamos regularmente a restauração desses backups.
Se você quiser saber mais sobre a infraestrutura técnica do Google, leia o Documentos técnicos sobre segurança do Google Cloud.[/bloco de citação]
Tão bom quanto isso, todos os sons, perdas e roubos ainda são possíveis. E as trilhas de auditoria apenas ajudam a prevenir ataques futuros; eles não receberão as chaves violadas de volta.
Potencial para modificações não autorizadas
Um grande problema na forma como o Google configurou os App Bundles é a possibilidade de modificações não autorizadas serem adicionadas a um aplicativo. O processo de extração de APKs de um App Bundle envolve inerentemente modificações, uma vez que o Google precisa construir manualmente cada APK. Enquanto O Google prometeu que não injeta e não irá injetar ou modificar código, o problema com o processo do App Bundle é que ele tem o poder de fazer isso.
Aqui estão alguns exemplos do que uma empresa na posição do Google tem o poder de fazer:
Digamos que exista um aplicativo de mensagens seguro que as pessoas usem para se comunicar sem o risco de vigilância governamental. Esta poderia ser uma ferramenta extremamente útil para pessoas que protestam contra um governo autoritário, ou mesmo para pessoas que desejam apenas manter sua privacidade. Esse governo, querendo ver o que os usuários do aplicativo estão dizendo, poderia tentar coagir o Google a adicionar um backdoor de vigilância ao código do aplicativo.
Este exemplo é um pouco mais inócuo, mas também é algo que preocupa algumas pessoas. Digamos que haja um aplicativo que recebe milhões de downloads por dia, mas não contém nenhum anúncio ou análise. Essa é uma enorme fonte de dados sem nenhuma maneira de acessá-los. O Google, sendo uma empresa de publicidade, pode querer acessar esses dados.
No modelo APK clássico de distribuição de aplicativos, o Google não pode modificar os aplicativos sem alterar a assinatura. Se o Google alterar a assinatura, especialmente em um aplicativo popular, as pessoas notarão porque a atualização não será instalada. Mas com App Bundles e App Signing, o Google poderia injetar silenciosamente seu próprio código em aplicativos antes de distribuí-los. A assinatura não mudaria porque o Google seria o proprietário da chave de assinatura.
Para ser claro, esses exemplos são incrivelmente improváveis de acontecer. O Google tende a simplesmente sair completamente dos mercados problemáticos, em vez de se adaptar. Mas mesmo que seja improvável, ainda é possível. Só porque uma empresa promete que algo não vai acontecer, ela não garante isso.
Transparência de código
O Google, ouvindo essas preocupações, introduziu esta semana um novo recurso chamado Transparência de código para pacotes de aplicativos. A transparência do código permite que um desenvolvedor crie essencialmente uma segunda assinatura que é enviada aos usuários com o aplicativo. Essa assinatura extra deve ser criada a partir de uma chave privada separada à qual somente o desenvolvedor tenha acesso. No entanto, existem algumas limitações para este método.
A transparência do código cobre apenas o código. Isso pode parecer óbvio dado o nome, mas também significa que não permite que os usuários verifiquem os recursos, o manifesto ou qualquer outra coisa que não seja um arquivo DEX ou uma biblioteca nativa. Embora modificações maliciosas em arquivos sem código geralmente tenham muito menos impacto, ainda é uma falha na segurança do aplicativo.
Outro problema com a transparência do código é que não há verificação inerente. Para um, é um recurso opcional, portanto, os desenvolvedores devem se lembrar de incluí-lo em cada novo APK que enviarem. No momento, isso deve ser feito a partir da linha de comando e com uma versão do bundletool isso não vem com o Android Studio. Mesmo quando um desenvolvedor o inclui, o Android não possui nenhum tipo de verificação integrada para verificar se o manifesto de transparência do código corresponde ao código do aplicativo.
Cabe ao usuário final verificar por si mesmo comparando o manifesto com uma chave pública que o desenvolvedor pode fornecer ou enviando o APK ao desenvolvedor para verificação.
Embora a transparência do código permita a confirmação de que nenhum código em um aplicativo foi modificado, ela não inclui nenhum tipo de verificação para outras partes de um aplicativo. Também não há confiança inerente no processo. Você poderia argumentar que, se não confia no Google, provavelmente estará à altura da tarefa de verificar de forma independente, mas por que deveria fazê-lo?
Existem outros problemas com o recurso Transparência de Código, como apontou por Mark Murphy de CommonsWare. Recomendo a leitura do artigo dele para uma análise mais aprofundada do recurso.
Conveniência e escolha do desenvolvedor
Um terceiro (e último neste artigo) motivo pelo qual alguns desenvolvedores discordam dos App Bundles é a redução da conveniência e da escolha.
Se um desenvolvedor criar um novo aplicativo na Play Store depois que o Google começar a exigir App Bundles e ele escolher a opção padrão de permitir que o Google gerencie a chave de assinatura, eles nunca terão acesso a essa assinatura chave. Se o mesmo desenvolvedor quiser distribuir esse aplicativo em outra loja de aplicativos, ele terá que usar sua própria chave, que não corresponderá à do Google.
Isso significa que os usuários terão que instalar e atualizar do Google Play ou de fontes de terceiros. Se quiserem alterar a fonte, deverão desinstalar completamente o aplicativo, potencialmente perdendo dados, e reinstalá-lo. Agregadores de APK como APKMirror também terá que lidar com várias assinaturas oficiais para o mesmo aplicativo. (Tecnicamente, eles já precisam fazer isso porque a assinatura de aplicativos permite criar uma chave nova e mais segura para novos usuários, mas será pior para eles e para outros sites quando todos tem fazer isso.)
A resposta do Google a esse problema é usar o App Bundle Explorer ou o Artifact Explorer no Play Console para baixar os APKs resultantes do pacote enviado. Da mesma forma que a transparência do código, esta não é uma solução completa. Os APKs baixados do Play Console serão divididos para diferentes perfis de dispositivos. Embora o Play Console suporte o upload de vários APKs para uma versão de um aplicativo, muitos outros canais de distribuição não.
Assim, muitos dos benefícios do uso de App Bundles desaparecem quando os desenvolvedores gerenciam várias lojas, dificultando a distribuição. Com notícias que Janelas 11 é ganhando suporte para aplicativos Android graças à Amazon Appstore, alguns acreditam que a exigência de App Bundles desencorajará os desenvolvedores de distribuir na Amazon. Claro, a principal preocupação do Google é com sua própria loja de aplicativos, mas é exatamente isso que os colocou em maus lençóis com os concorrentes levando-os a fazer pequenas mudanças conciliatórias sobre como as lojas de aplicativos de terceiros funcionam no Android.
Alguns problemas relacionados a várias lojas são a interconectividade de aplicativos e os testes rápidos.
Vamos começar com a interconectividade dos aplicativos. Você já baixou um aplicativo que bloqueia recursos atrás de um acesso pago? Quase definitivamente. Alguns desenvolvedores colocam os recursos em uma compra dentro do aplicativo, mas outros podem optar por fazer um aplicativo pago separado. Quando esse aplicativo complementar é instalado, os recursos do aplicativo principal são desbloqueados.
Mas o que impede alguém de instalar o complemento de uma fonte pirata? Bem, existem muitas opções para desenvolvedores, mas pelo menos uma envolve o uso de permissões protegidas por assinatura. Digamos que o aplicativo principal declare uma permissão protegida por assinatura. O aplicativo complementar declara então que deseja usar essa permissão. Idealmente, o aplicativo complementar também terá algum tipo de funcionalidade de verificação de licença, que se conecta à Internet para garantir que o usuário seja legítimo.
Se ambos os aplicativos tiverem a mesma assinatura, o Android concederá permissão ao aplicativo complementar e as verificações de proteção contra pirataria serão aprovadas. Se o aplicativo complementar não tiver a assinatura correta, a permissão não será concedida e a verificação falhará.
Com o modelo clássico de distribuição de APK, um usuário pode obter qualquer aplicativo de qualquer fonte legítima e pronto. Com o modelo padrão atual do App Bundle, as assinaturas nos aplicativos principais e complementares não corresponderão. O Google criará uma chave exclusiva para cada aplicativo. O desenvolvedor sempre pode eliminar a permissão protegida por assinatura e usar a verificação direta de hash de assinatura, mas isso é muito menos seguro.
E depois há testes rápidos. Os usuários enviam e-mails aos desenvolvedores o tempo todo sobre problemas em seus aplicativos. Às vezes, esses problemas são soluções simples: reproduza o problema, encontre o problema, corrija-o e carregue uma nova versão. Mas às vezes não são. Às vezes, os desenvolvedores não conseguem reproduzir um problema. Eles podem consertar o que acham que é o problema, mas então o usuário precisa testá-lo. Agora suponha que o usuário instalou o aplicativo por meio do Google Play.
Com o modelo APK, um desenvolvedor pode alterar algum código, construir e assinar um novo APK e enviá-lo ao usuário para teste. Como a assinatura do APK de teste corresponde àquela que o usuário instalou, é um processo simples atualizar, testar e reportar. Com App Bundles, isso desmorona. Como o Google assina o APK que o usuário instalou originalmente, ele não corresponderá à assinatura do APK enviado pelo desenvolvedor. Se este aplicativo for publicado após o prazo dos App Bundles, o desenvolvedor nem mesmo terá acesso às chaves que o Google usa. Para testar, o usuário teria que desinstalar o aplicativo atual antes de instalar a versão de teste.
Há muitos problemas aqui. Primeiro, há inconvenientes, tanto do lado do desenvolvedor quanto do usuário. Ter que desinstalar o aplicativo apenas para testar uma correção não é divertido. E se o problema desaparecer? Foram as alterações feitas pelo desenvolvedor ou porque o usuário limpou efetivamente os dados do aplicativo? A Play Store possui testes internos, que supostamente permitem que os desenvolvedores façam compilações e distribuições rápidas, mas exige que o usuário desinstale a versão de lançamento primeiro. Isso realmente não resolve nada.
Caso tudo isso pareça um monte de bobagens hipotéticas, aqui está um exemplo muito real de um desenvolvedor que terá esses problemas se deixar o Google gerar uma chave privada para eles: João Dias. Ele é o desenvolvedor do Tasker, junto com vários aplicativos de plug-in, incluindo o pacote AutoApps. Com a nova exigência de App Bundles, o ciclo de desenvolvimento de João pode ficar muito mais complicado, pelo menos para novos aplicativos. Enviar versões de teste diretamente será menos conveniente. A verificação de licenças será menos eficaz.
Isso pode parecer um caso extremo, mas não é como se João fosse um pequeno desenvolvedor e é provável que ele não esteja sozinho. Existem muitos aplicativos na Play Store que dependem da verificação de assinatura para detectar usuários ilegítimos.
É claro que, com a nova opção para os desenvolvedores enviarem suas próprias chaves de assinatura para o Google, esses problemas são pelo menos um pouco atenuados. Mas os desenvolvedores precisam ativar a opção para cada aplicativo. Caso contrário, as interconexões falharão e o suporte rápido exigirá o upload de um pacote para o Google e a espera pela geração dos APKs, antes de enviar o APK correto ao usuário. Além disso, isso ainda significa que eles precisam compartilhar sua chave privada, o que nos traz de volta às preocupações que discutimos anteriormente.
Soluções
Este é um problema antigo, visto que os requisitos do App Bundle foram divulgados meses atrás, portanto, algumas soluções foram propostas nesse ínterim.
Uma solução é evitar a necessidade de assinatura de aplicativos do Play. Em vez de gerar um App Bundle que o Google processa em APKs e sinais, esse processamento poderia ser feito pelo Android Studio. Em seguida, os desenvolvedores podem simplesmente fazer upload de um ZIP cheio de APKs assinados localmente para cada configuração que o Google teria gerado.
Com essa solução, o Google não precisaria de acesso às chaves dos desenvolvedores. O processo seria muito semelhante ao modelo clássico de distribuição de APK, mas envolveria vários APKs menores, em vez de apenas um.
Outra solução é simplesmente não exigir o uso de App Bundles e continuar permitindo que os desenvolvedores carreguem APKs assinados localmente. Embora os pacotes de aplicativos possam ser uma experiência melhor para o usuário em muitos casos, alguns aplicativos não se beneficiam de serem divididos por configuração, com tamanho mínimo redução.
Se o Google implementasse essas duas soluções, um desenvolvedor que deseja usar App Bundles não terá que lidar em vez de assinar com o Google, e um desenvolvedor cujo aplicativo não se beneficiará muito com o formato não precisará usá-lo em todos.
Respostas do Google
Autoassinatura
Quando eles foram questionados pela primeira vez sobre permitir que os desenvolvedores cuidassem da assinatura de App Bundles, a resposta do Google foi muito evasiva:
[blockquote author = ""] Então, falei brevemente sobre a exigência do próximo ano para que novos aplicativos usem pacotes de aplicativos, e uma coisa que vem com isso é que, por extensão, exigiremos a assinatura de aplicativos do Play. Portanto, os desenvolvedores precisarão gerar a chave de assinatura do aplicativo no Play ou fazer upload de sua própria chave no Play… porque isso é um pré-requisito para pacotes de aplicativos. Ouvimos dos desenvolvedores que alguns deles simplesmente não querem fazer isso. Eles não querem que as chaves sejam gerenciadas pelo Play. E atualmente isso não é possível se você quiser usar pacotes de aplicativos.
Mas ouvimos esse feedback e... não posso falar sobre nada agora, não temos nada a anunciar, mas estamos analisando como podemos aliviar algumas dessas preocupações. Não precisa necessariamente permitir manter sua própria chave durante o upload de pacotes. Estamos analisando diferentes opções. Simplesmente não temos uma solução para anunciar agora. Mas ainda temos cerca de um ano até o requisito, então estou realmente esperançoso de que teremos uma resposta para os desenvolvedores sobre isso.[/blockquote]
Isso foi no final de novembro do ano passado e nada parece ter acontecido. Faltando apenas alguns meses para o O requisito de App Bundles entra em vigor, ainda não há uma maneira de os desenvolvedores lidarem com a assinatura de seus próprios aplicativos. Embora o Google tenha agora tornado possível carregar sua própria chave para aplicativos novos e existentes, isso ainda tira a parte de assinatura das mãos do desenvolvedor.
Mudanças de código
Embora o Google tenha prometido especificamente que a Play Store não modificará o código do aplicativo, uma promessa não é uma garantia. Com App Bundles e App Signing, não há nenhuma limitação técnica que saibamos que impeça o Google de modificar aplicativos enviados antes da distribuição.
O Google introduziu Transparência de código como um recurso opcional e, embora ajude um pouco, tem seu quinhão de problemas, como discutimos anteriormente.
Pacotes feitos por você mesmo
Quando o Google foi questionado sobre permitir que os desenvolvedores criassem seus próprios "pacotes" de aplicativos (ZIPs contendo APKs divididos), a resposta foi basicamente "não vamos fazer isso":
Provavelmente não conforme descrito na pergunta, pois isso tornaria o processo de publicação ainda mais difícil para os desenvolvedores e, na verdade, queremos torná-lo mais simples e seguro. No entanto, mais uma vez, ouvimos esse feedback e estaremos analisando opções de como tornar isso possível, mas provavelmente não da maneira descrita aqui.
Curiosamente, a justificativa do Google parece ser que isso tornaria a publicação mais complicada. No entanto, o Google ainda pode automatizar o processo como parte da caixa de diálogo de geração de APK no Android Studio. Além disso, se o aplicativo em questão estiver sendo distribuído em várias lojas, isso tornaria o processo de publicação mais simples, já que os desenvolvedores não teriam que gerenciar múltiplas chaves de assinatura e reclamações de Usuários.
E com a introdução da transparência do código, parece que a complicação não é exatamente um problema, afinal. A transparência do código, pelo menos por enquanto, exige que o desenvolvedor use uma ferramenta de linha de comando e que os usuários verifiquem explicitamente a validade do aplicativo que são servidos. Isso é mais complicado do que um processo de criação de pacotes por conta própria e não está claro por que essa é a solução que o Google prefere.
Daqui para frente
Os App Bundles serão o formato de distribuição obrigatório para novos aplicativos enviados ao Google Play a partir de 1º de agosto. Embora o Google tenha abordado pelo menos um pouco a maioria das questões levantadas por desenvolvedores e especialistas em segurança, as respostas deixam muito a desejar. Há muitos benefícios óbvios nos App Bundles como formato de distribuição de próxima geração, mas sempre haverá preocupações persistentes em fornecer ao Google o controle parcial ou total da assinatura de aplicativos.
As respostas e os esforços do Google são certamente apreciados, mas alguns, como Mark Murphy, sentem que não foram longe o suficiente. Com soluções como pacotes feitos por você mesmo não sendo implementadas e o prazo para Android App Bundles sendo exigido rapidamente se aproximando, não parece que os desenvolvedores do Google Play conseguirão manter o controle total de seus aplicativos por muito tempo. mais longo.
Falaremos sobre as implicações do requisito do Android App Bundle em um espaço do Twitter no final da tarde, então junte-se a nós!