Android 11 AMA: sem capturas de tela de rolagem, inicialização de aplicativos mais rápida e muito mais

Ontem, o Google lançou Android 11 Beta 2, trazendo o SDK finalizado, o NDK, as superfícies voltadas para aplicativos, os comportamentos da plataforma e as restrições em interfaces não SDK para desenvolvedores. Hoje, o Google está respondendo a perguntas relacionadas ao Android 11 na comunidade /r/AndroidDev do Reddit depois de responder a perguntas na semana passada. Aqui está um resumo de tudo o que aprendemos com o AMA (Ask Me Anything) do Google.

Um dos recursos mais esperados do Android 11 não estará disponível quando o sistema operacional sai da versão beta em 8 de setembro: Capturas de tela de rolagem. Inicialmente planejado para lançamento no Android 11, o Google confirmou agora que o recurso “não foi adequado para R”. Visualização do desenvolvedor do Android 11 1 e todas as versões DP e Beta subsequentes têm um botão de espaço reservado para fazer uma captura de tela de rolagem que pode ser

apareceu manualmente com um comando de desenvolvedor oculto, mas tocar no botão simplesmente mostra uma mensagem informando que o recurso "não está implementado".

Esperávamos que o recurso chegasse a uma versão beta ou mesmo apenas à versão estável, mas parece que isso simplesmente não vai acontecer.

Esta notícia será compreensivelmente perturbadora para alguns usuários. Afinal, muitos OEMs têm esse recurso em seus próprios softwares há anos, então por que o Google está demorando tanto para adicioná-lo aos telefones Pixel? Conforme explicado por Dan Sandler, da equipe System UI do Google, o problema é que o Google quer fazer tudo certo. Algumas implementações de captura de tela de rolagem simplesmente emulam uma rolagem e depois juntam várias capturas de tela conforme a tela se move. Se você já lidou com automação de UI no Android, sabe que isso nem sempre funciona, pois, como menciona o Sr. Sandler, os aplicativos pode usar "um RecyclerView padrão ou implementar seu próprio mecanismo de rolagem acelerado por OpenGL". Como o Google planeja implementar esse recurso não apenas para smartphones Pixel, mas para todo o ecossistema Android como parte do AOSP, eles precisam ter certeza vai funcionar todos aplicativos e não apenas "um ou dois aplicativos escolhidos a dedo em um dispositivo específico".

Porque a equipe teve que “focar [seus] recursos limitados”, especialmente devido aos desafios trazidos pelo COVID-19, a equipe decidiu colocar as capturas de tela de rolagem em segundo plano para uma versão futura do Android.

Novo requisito de CDD para informar os usuários sobre restrições de segundo plano

Não é nenhum segredo que muitos OEMs de Android, especialmente os chineses, têm restrições agressivas a aplicativos executados em segundo plano. Alguns desenvolvedores ficaram tão frustrados com a morte de seus aplicativos em segundo plano que se uniram para criar um site chamado "Não mate meu aplicativo"para classificar os OEMs com base em quão mal eles lidam com processos de aplicativos em segundo plano. Esses mesmos desenvolvedores até recentemente fez uma referência para que os usuários possam testar a agressividade com que seu dispositivo mata aplicativos em segundo plano. A razão pela qual muitos OEMs adoram eliminar processos de aplicativos em segundo plano é complicada, mas acho que é melhor explicada neste comentário do Redditor /u/possivelmente questionável. O comentário descreve a complicada situação do desenvolvimento de aplicativos Android na China, como as empresas de tecnologia chinesas estão envolvidos em complicar ainda mais as coisas e como a falta de serviços do Google contribui para o contínuo bagunça.

Independentemente disso, muitos desenvolvedores de aplicativos estão compreensivelmente frustrados com esses ajustes no comportamento da plataforma Android, o que resultou em desenvolvedores empurrando um comentário perguntando ao Google o que eles estão fazendo a respeito para o topo do Reddit AMA. Aqui está a resposta do Google:

Há algumas coisas a serem tiradas dessa resposta. Primeiro, o Google deseja que os OEMs sejam mais transparentes com os usuários sobre as restrições de aplicativos em segundo plano que estão aplicando. Verifiquei o documento de definição de compatibilidade (CDD) do Android 11 (não lançado) e encontrei a seguinte adição proposta à Seção 3.5 - Compatibilidade comportamental da API:

Se as implementações de dispositivos implementarem um mecanismo proprietário para restringir aplicativos e esse mecanismo for mais restritivo do que o bucket de espera “Raro” no AOSP, eles:

[C-1-5] DEVE informar os usuários se as restrições de aplicativos são aplicadas automaticamente a um aplicativo. (NOVO) Essas informações NÃO DEVEM ser fornecidas antes de 24 horas antes da aplicação de tais restrições.

(Nota) A Parada Forçada é considerada mais restritiva do que "Rara" e DEVE cumprir todos os requisitos de 3.5.1, incluindo o novo 3.5.1/C-1-5

Basicamente, o Google não impede os OEMs de implementar seus próprios recursos restritivos de eliminação de aplicativos. Eles exigem apenas que os OEMs informem os usuários se as restrições de seus aplicativos estão sendo aplicadas automaticamente. Um OEM pode mostrar uma caixa de diálogo informando que interromperá a execução de aplicativos em segundo plano que consomem bateria no em segundo plano, e o usuário pode consentir sem perceber que os aplicativos que ele realmente deseja executar em segundo plano também estão afetado! O Google está atribuindo aos desenvolvedores o ônus de lidar com os casos em que seu aplicativo é encerrado inesperadamente em segundo plano. Na verdade, o comentário do Reddit destaca o novo "motivos de saída do processo do aplicativo" API que pode informar aos desenvolvedores se seu aplicativo foi encerrado pelo usuário, pelo sistema operacional ou se simplesmente travou.

Por outro lado, o Google está finalmente abordando a prática injusta dos OEMs que permitem que certos aplicativos privilegiados contornem as restrições de aplicativos em segundo plano. Esta postagem média do desenvolvedor Timothy Asiimwe entra em detalhes sobre aplicativos como WhatsApp, Facebook e outros aplicativos que estão automaticamente isentos das duras restrições de fundo de alguns softwares OEM. O Google diz que “exige que os fabricantes de dispositivos não criem listas de permissão para os principais aplicativos”. Não sabemos como isso será aplicado, mas é bom saber que os OEMs finalmente serão forçados a tratar os desenvolvedores terceirizados em pé de igualdade, não importa quão grandes ou pequenos sejam seus aplicativos são.

Por fim, o Google também menciona como o Android 11 “adicionou medidas extras para evitar comportamento abusivo por aplicativos com comportamento inadequado”, tornando menos atraente para os OEMs eliminar agressivamente processos em segundo plano. A empresa não detalhou o que essas “medidas extras” implicam, no entanto.

Backups aprimorados de dispositivo para dispositivo

No mês passado, detectamos uma alteração na documentação do Android 11 que sugeriu suporte para melhores backups de dados locais. No Android 11, o sistema desconsiderará o atributo do manifesto allowBackup para qualquer aplicativo direcionado ao nível 30 da API quando o usuário iniciar uma migração de arquivos do aplicativo "de dispositivo para dispositivo". O Googler Eliot Stock diz que esse recurso tem como objetivo tornar "muito mais fácil para os fabricantes de telefones criarem ferramentas de migração de dispositivo para dispositivo", como o "excelente produto Smart Switch da Samsung" para ajudar a "garantir que os aplicativos sejam transferidos de maneira mais confiável entre dispositivos do ponto de vista do usuário". Infelizmente, isso não se aplica a backups baseados em nuvem, já que o Google quer “dar aos desenvolvedores de software controle sobre o que acontece com os dados do aplicativo." Dessa forma, o Android 11 ainda respeitará o atributo permitBackup para qualquer backup e restauração baseado em nuvem, como por meio do Google Drive integrado do Google Play Service. cópia de segurança. Por último, o Google reconhece que o limite máximo de backup de 25 MB por aplicativo pode não ser suficiente para alguns desenvolvedores, então eles estão procurando maneiras de resolver isso. Porém, backups locais para um PC não estão sendo considerados e o Google reitera seu plano de descontinuar o backup do adb em uma versão futura do Android.

Os desenvolvedores são incentivados a implementar métodos de migração de dados sem atrito. O nova biblioteca Block Store, que faz parte da Biblioteca de serviços de identidade do Google, foi projetado para facilitar o login em aplicativos restaurados da nuvem em novos dispositivos, mas cabe aos desenvolvedores escolher se desejam ou não implementar isso biblioteca.

Velocidades mais rápidas de inicialização de aplicativos com processo de leitura antecipada de E/S (IORap)

O Google está sempre experimentando maneiras de melhorar o desempenho do Android. Um dos recursos pouco conhecidos adicionados ao Android 10 é chamado Unspecialized App Process Pool (USAP). Esse recurso elimina a bifurcação do Zygote durante o processo de inicialização do aplicativo, economizando aproximadamente cerca de 5 ms na velocidade média de inicialização do aplicativo em um dispositivo Pixel 2. O recurso está atualmente desabilitado por padrão no AOSP, e o Google explica que seu uso adicional de memória ainda precisa de testes. O que é mais interessante, porém, é um novo recurso que chega ao Android 11 chamado I/O Read Ahead Process (IORap). De acordo com o Google, esse recurso levará a “inicializações a frio mais de 5% mais rápidas, com casos de herói chegando a 20% mais rápido”. Este recurso "buscará previamente artefatos de aplicativos (como código e recursos) durante o processo de inicialização" para impulsionar o lançamento do aplicativo velocidades.

O Google também “fez melhorias nos perfis usados ​​para otimizar o caminho da classe de inicialização e a imagem do sistema” o que melhorará o desempenho do aplicativo e reduzirá o custo de memória e armazenamento associado ao sistema artefatos. Essas mudanças beneficiarão principalmente dispositivos com maiores quantidades de RAM, embora o Google não tenha dito qual é o limite para onde veremos mais benefícios.

Mudanças no armazenamento com escopo do Android 11 - Por que o acesso a /Downloads é restrito?

Aplicativos direcionados ao Android 11 e que usam a intenção ACTION_OPEN_DOCUMENT_TREE para solicitar acesso a diretórios específicos no externo storage não poderá mais solicitar aos usuários acesso ao diretório raiz do armazenamento externo (/data/media/{user}), o Download diretório (/data/media{user}/Download) ou qualquer um dos diretórios de dados específicos do aplicativo no armazenamento externo (/Android/data ou /Android/obb). Por que o acesso ao diretório de download é restrito? De acordo com o Google Roxanna Aliabadi, é porque a pasta de download “corre o maior risco de conter informações privadas”. Por exemplo, os usuários que baixam seus impostos devoluções ou extratos bancários não deveriam se preocupar com a possibilidade de aplicativos abusarem de seu acesso de leitura contínua ao diretório. O Google diz que o seletor de documentos terá “texto atualizado... para indicar que o Android restringiu determinadas pastas a ser selecionado." Esperamos que isso reduza a confusão sobre por que eles não podem conceder acesso a aplicativos a determinados diretórios não mais.

Para obter mais informações sobre as próximas alterações na política de armazenamento com escopo e jogo, consulte este artigo.

Tópicos diversos

• A posição do Google sobre root/modding
  • Jeff Bailey, da equipe AOSP do Google, reitera a posição da empresa em apoiar a escolha. O Google “continuará a garantir que a modificação/rooting da linha de dispositivos Pixel seja possível”, mas também “apoiará a escolha dos OEMs de não permitirem que seus dispositivos para ser enraizado." Além disso, o Google está dando aos desenvolvedores de software a opção de "não permitir que seu software seja executado em dispositivos enraizados", em referência às mudanças recentes no detecção de violação de software da API SafetyNet Attestation.
• O que aconteceu com "abrir e definir como padrão"?
  • Android 10 feito é um pouco chato definir um aplicativo como gerenciador padrão para links específicos, o que o Google diz ter sido feito para proteger os usuários de “aplicativos exploradores”. Google recuou sobre esta mudança depois de repensar, fazendo uma “série de mudanças nos bastidores” para proteger o usuário.
• Usando a API Vulkan Graphics para renderizar a IU?
  • O Google eventualmente planeja usar a API Vulkan Graphics para renderizar a IU, o que produzirá algumas melhorias de desempenho. Isso é ainda está sendo avaliado, mas a empresa não tinha detalhes específicos para compartilhar.
• CallScreeningService ausente em muitos dispositivos
  • Aplicativos Android podem implementar o API CallScreeningService para interceptar novas chamadas recebidas e efetuadas, permitindo identificar o chamador e aceitar ou rejeitar a chamada. Embora esta seja uma API oficialmente documentada, aparentemente existem muitos OEMs que não a implementam adequadamente, de acordo com o desenvolvedor /u/_zeromod_. Google confirma que esta API seja validada pelo Compatibility Test Suite (CTS), um conjunto de testes automatizado que todos os dispositivos devem passar para serem considerados compatíveis com Android. Por alguma razão, esta API retorna null quando chamada em dispositivos de OEMs como Huawei, Vivo, Xiaomi ou Samsung, então é provável que esses OEMs tenham um bug em seu software.
• Não há planos para uma estrutura de plugin de áudio
  • Um desenvolvedor perguntou ao Google se eles planejam implementar uma estrutura de plug-in de áudio como o Audio Units da Apple, mas a resposta é que é improvável que isso aconteça num futuro próximo.

Você pode ler todas as respostas da equipe de engenharia do Android aqui. A equipe fala um pouco sobre Java, Kotlin, o sistema de compilação Android, a API CameraX e outros tópicos em alguns comentários. Também há vários comentários sobre Wear OS, Android TV e Android Auto, mas o Google reitera principalmente seu trabalho existente nessas plataformas e diz aos desenvolvedores para ficarem atentos para mais informações durante o "Android além dos telefones" semana que começa dia 10 de agosto.