Resumo do Android Q AMA: o que o Google disse sobre o Android 10 no Reddit

No ano passado, a equipe Android do Google organizou um Ask Me Anything (AMA) no subreddit /r/AndroidDev do Reddit para responder perguntas sobre o Visualização do desenvolvedor Android P. Este ano, a equipe de engenharia que trabalha na versão beta do Android Q respondeu a perguntas no Reddit. A AMA começou em 1º de agosto às 12h PST e terminou cerca de uma hora e meia depois. 33 engenheiros do Google estiveram envolvidos no AMA, respondendo a uma série de perguntas no curto espaço de tempo que o AMA durou. Aqui está nosso resumo de todas as novas informações que aprendemos.

Android Q AMA: tudo o que aprendemos com o Google

Participantes da equipe beta do Android Q

• Adam Cohen: TLM no iniciador do Android/IU do sistema
• Adam Powell: TLM no kit de ferramentas/estrutura de UI; visualizações, ciclo de vida, fragmentos, bibliotecas de suporte
• Alan Viverette: TLM, Jetpack/AndroidX
• Allen Huang: PM para UI, iniciador, notificações, integrações de pesquisa e muito mais!
• André Sappirstein: TLM nas configurações do Android
• Brahim Elbouchikhi: Diretor PM para Android Machine Learning e Câmera (API NN, Kit ML, CameraX, Plataforma de Câmera)
• Chad Brubaker: Engenheiro de software, Segurança da plataforma Android
• Charmaine D'Silva: PM para privacidade
• Chet Haase: Defensor-chefe do Android, relações com desenvolvedores
• Diana Wang: PM, compatibilidade de aplicativos, uso de API não SDK, ART, NDK
• Dianne Hackborn: Gerente da equipe de framework Android (Recursos, Gerenciador de Janelas, Gerenciador de Atividades, Multiusuário, Impressão, Acessibilidade, etc.)
• E. K. Chung: Diretor de UX
• Lago Ian: Engenheiro de Software, Jetpack (Fragmentos, Navegação, Componentes de Arquitetura)
• Iliyan Malchev: Engenheiro de software principal, linha principal do projeto
• Jacob Lehrbaum: Diretor de relações com desenvolvedores para Android
• Jake Wharton: Engenheiro de software, Jetpack
• Jamal Eason: PM, Android Studio
• Jeff Bailey: TLM, Projeto de Código Aberto Android (AOSP)
• Jeff Sharkey: Engenheiro de Software, Estrutura Android
• Jeffrey van Gogh: Android Studio, Compiladores
• Jen Chai: PM, localização e contexto, autenticação, preenchimento automático, uso de API não SDK, ART
• Karen Ng: PM de grupo para ferramentas de desenvolvedor Android, Android Studio, Android Toolkit e Jetpack
• Paulo Bankhead: Diretor de gerenciamento de produtos, Google Play
• Rohan Xá: Gerente de produto, UI do sistema Android
• Romain cara: Gerente da equipe Android Toolkit/Jetpack
• Sagar Kamdar: Diretor de gerenciamento de produtos, Android
• Sábado K: Diretor de Engenharia, Conectividade Android
• Selim Cinek: Engenheiro de software, UI do sistema Android
• Stephanie Saad Cuthbertson: Diretor sênior de gerenciamento de produtos, Android
• Sumir Kataria: Engenheiro de Software, Jetpack (WorkManager)
• Travis McCoy: PM, plataforma Android
• Trystan parado: Engenheiro ilustre, líder de interface e inteligência do sistema Android
• Vinit Modi: PM, câmera Android

consulte Mais informação

Os OEMs não podem mais encerrar aplicativos quando o usuário os remove recentemente

Se você já usou um smartphone de uma marca chinesa, provavelmente já lidou com recursos irritantes de "otimização de bateria" que mate todos os seus aplicativos favoritos em segundo plano. Esse comportamento não é apenas irritante para os usuários que esperam que determinados aplicativos continuem sendo executados em segundo plano por qualquer motivo, mas também é irritante para os desenvolvedores que sofrem críticas negativas de usuários que não entendem que não é o aplicativo falta. Enquanto o Google está ainda não abordando totalmente esse assunto (eles ignoraram o problema, afirmando que esse comportamento é provavelmente já viola os requisitos do Documento de definição de compatibilidade do Android), a empresa é agindo contra uma mudança de comportamento de "economia de bateria" empregada por alguns OEMs.

“Para ajudar com a situação, adicionamos um teste CTS no Android Q para garantir que um aplicativo não seja encerrado ao ser retirado de Recentes.”

Android R pode trazer mais mudanças nas capturas de tela do que esperávamos

Google planeja adicionar rolando capturas de tela no Android R, mas ao mesmo tempo, o A equipe Android é "analisando de perto como [eles] podem melhorar toda a experiência de tela [X] para R." Assim, podemos veja outras melhorias no comportamento da captura de tela (E do screencast) na próxima versão principal do Android.

Esclarecendo o novo modo desktop do Android Q

O primeira versão beta pública do Android Q trouxe uma interface de modo desktop oculta para o AOSP e o Pixel Launcher. Embora o Google toquei brevemente no recurso durante uma sessão do Google I/O, nunca ouvimos diretamente do Google como o novo recurso se encaixa no ecossistema Android. Google agora esclarece:

"No Q AOSP, o 'modo desktop' é uma opção de desenvolvedor voltada para desenvolvedores de aplicativos. Ele permite que eles testem seus aplicativos em ambientes com vários monitores e em modo de janela de formato livre. Anteriormente, não havia uma maneira conveniente de testar o comportamento do aplicativo em uma tela secundária e com janelas redimensionáveis ​​livremente no Android padrão. Este recurso não é produzido por si só e não se destina a usuários regulares no momento. No entanto, é a base da plataforma Android para os OEMs inovarem e criarem excelentes produtos."

Assim, podemos esperar que os OEMs se baseiem no modo desktop nativo do Android Q. Por exemplo, o OnePlus 7 Pro suporta exibição via HDMI, então é possível que OxygenOS 10 baseado no Android Q terá sua própria interface de modo desktop no futuro. Também esperamos que o Google aproveite o recurso para o próximo Pixel 4.

Modo escuro baseado em tempo

O Android Q finalmente traz um recurso amplamente solicitado: modo escuro em todo o sistema. Atualmente, o modo escuro pode ser ativado manualmente em Configurações ou por meio de um bloco Configurações rápidas, ou pode ser ativado automaticamente quando a Economia de bateria estiver ativada. Antes do Android Q, havia uma opção para ativar o modo escuro com base na hora do dia, mas essa opção foi descontinuada. De acordo com Chris Banes:

"Existem alguns motivos pelos quais isso está obsoleto (não removido) no AppCompat v1.1.0: ele exige que os aplicativos solicitem as permissões de localização sejam precisas e, mesmo com uma localização válida, os cálculos da hora do nascer/pôr do sol podem ser bugado."

Quando questionado sobre esses bugs, o Sr. Banes afirma que "calcular o nascer/pôr do sol é notoriamente difícil, especialmente para locais próximos a pólos norte/sul." Um usuário abre o Night Light, disponível desde o Android 7.1 Nougat, que pode ser alternado automaticamente com base no pôr do sol/nascer do sol horários. Banes então afirma que, como Night Light usa CalendarAstronomer de UTI4J, ele usa um "grande pedaço de código do qual não gostaríamos que o AppCompat dependesse". No entanto, a equipe faz estado que esse recurso é "algo que [eles] estarão investigando".

Suporte obrigatório para API Camera2/Camera HAL3 para dispositivos de inicialização Android Q

O Google introduziu a API Camera2 para definir melhor como os aplicativos podem interagir com as câmeras individuais conectadas ao seu smartphone. Enquanto o Google encorajar fornecedores de smartphones "exponham todas as suas câmeras físicas aos desenvolvedores", muitos fornecedores optam por não fazê-lo, embora "a API em si não seja prevenindo-os hoje." Isso significa que muitos aplicativos de câmera de terceiros não podem usar os módulos de câmera secundários ou terciários em dispositivos modernos. smartphones. No entanto, estão sendo feitos progressos à medida que o Android Q melhora LÓGICA_MULTI_CÂMERA, uma API que oferece aos desenvolvedores melhor acesso a todas as câmeras em um dispositivo e que dá aos OEMs controle sobre o consumo de energia e o gerenciamento de vários estados de câmeras.

Além disso, o Google afirma que adicionou requisitos para todos os dispositivos lançados com Android Q para oferecer suporte nativo à API Camera2/Camera HAL3. De acordo com Vinit Modi:

"A partir do Android P, novos dispositivos com 1 GB ou mais de RAM são necessários para usar HALv3/camera2 nativamente. Android Q em diante, todos os novos dispositivos são obrigados a suportar nativamente HALv3/camera2. Infelizmente, as atualizações do HALv1 para o HALv3 são bastante complexas e podem ter consequências inesperadas, por isso tivemos que limitar o escopo a novos dispositivos."

Curiosamente, a declaração de Modi sobre RAM normal para dispositivos de lançamento Android P contradiz o que o Google nos disse anteriormente e o que foi publicado na página on-line do Image Test Suite.

Temas dinâmicos de aplicativos com Jetpack Compose

A estrutura de temas OMS da Sony foi adicionada ao AOSP há alguns lançamentos, mas é apenas destinado a OEMs para construir. Nós já sabemos disso Google é contra o uso de sobreposições de recursos de tempo de execução pelos usuários para aplicativos temáticos, mas para os desenvolvedores, a empresa está na esperança É isso aí IU do Jetpack Compose estrutura apresentará "abordagens interessantes para temas dinâmicos".

Back-end Vulkan para Skia para renderizar a IU

Ano passado, vimos uma discussão entre os engenheiros do Google falando sobre seus planos de fazer com que a estrutura Android use a API gráfica Vulkan para renderização de IU. Embora agora seja possível ativar o back-end acelerado por hardware Vulkan sem o seu telefone travando, não ouvimos nenhum plano concreto do Google sobre quando eles planejam lançar esses mudanças. Esta AMA não responde a essa pergunta, mas pelo menos temos a confirmação de que ainda está em andamento. De acordo com Romain Guy:

“A equipe está trabalhando em um backend Vulkan para Skia, o renderizador 2D usado pelo Android, mas ele não está habilitado por padrão atualmente. A UI e o Canvas ainda passam pelo OpenGL ES."

Tornando a barra de gestos do Android Q mais dinâmica

Alguns no XDA ainda pensam isso Os novos gestos do Android são uma bagunça, mas pessoalmente acho que eles estão bem. Se você brincar um pouco com os novos gestos do Android Q, notará que a barra de gestos não se move com o dedo. Ele também permanece em telas onde não é necessário, como a tela inicial ou a visão geral de aplicativos recentes. Allen Huang diz que eles "concordam totalmente que há oportunidades" para tornar a "linha de navegação menos estática". Ele ainda diz que "isso é algo em que estamos trabalhando - mas também equilibrando para que não seja uma distração aparecendo/desaparecendo."

Melhorias na estrutura de acesso ao armazenamento

As muitas mudanças no Android Q melhoraram muito o segurança e privacidade da plataforma. Uma dessas mudanças, chamada “Scoped Storage”, limita o acesso dos aplicativos aos arquivos no armazenamento externo de uma forma que faz sentido; aplicativos de música não deveriam precisar ver sua galeria, por exemplo. Os aplicativos gerenciadores de arquivos em execução no Android Q precisam usar uma API chamada Storage Access Framework para continuar funcionando normalmente, mas alguns desenvolvedores veem esta API como inferior ao que estava disponível anteriormente. Jeff Sharkey do Google diz a equipe abordou algumas das reclamações destes desenvolvedores:

“Fizemos algumas melhorias de desempenho SAF nas versões mais recentes do Android Q Beta; você poderia comparar seus benchmarks com o Beta mais recente? Certifique-se também de usar um ContentProviderClient ao executar qualquer operação em massa."

O Project Treble melhorou a adoção do Android Pie em comparação ao Android Oreo

Já vimos como o Project Treble, uma importante rearquitetura de baixo nível da estrutura Android, melhorou a adoção de versões mais recentes do sistema operacional Android. O Google credita a Treble por trás da grande quantidade de fornecedores de smartphones que aderiram ao Android P beta ano passado e AndroidQ beta este ano. Iliyan Malchev, líder do Projeto Treble e Linha principal engenheiro, diz que a adoção do Android Pie foi "3 vezes" maior que a do Android Oreo no final de 2018.

No mesmo comentário, Dick Dougherty brinca que métricas mais úteis estão em desenvolvimento para o gráfico de distribuição da versão Android. O gráfico foi última atualização em maio, mas seus dados são mais úteis para jornalistas do que para desenvolvedores de aplicativos.

A gravação de tela ainda é um WIP

Os primeiros betas do Android Q adicionaram um sinalizador de recurso para um gravador de tela básico, mas a própria plataforma melhorou bastante a utilidade da gravação de tela ao permitindo que aplicativos capturem o áudio de outros aplicativos. Stephanie Saad Cuthbertson disse que a equipe estava considerando “como poderíamos melhorar as necessidades de gravação de tela ainda ontem”. Outras marcas de smartphones como OnePlus, ASUS, Huawei e Samsung têm gravadores de tela robustos que podem gravar o áudio interno, então o Google estará tentando se atualizar aqui.

Tema escuro todas as coisas!

Caso você tenha perdido, o Google está adicionando o modo escuro à maioria de seus aplicativos. Stephanie Saad Cuthbertson diz esperar que todos os “aplicativos principais” suportem um tema sombrio “no lançamento oficial [Android Q]”. Até o Google Chrome, que atualmente força o recarregamento da página quando o tema escuro em todo o sistema estiver ativado, será atualizado para não ser mais atualizado quando o tema for mudado.

Sim, lançadores de terceiros funcionarão com gestos (eventualmente)

Os gestos do Android são uma espécie de quebrado quando você usa um iniciador de terceiros. Isso ocorre porque a IU de aplicativos recentes está contida no aplicativo inicializador de ações e o Google ainda não descobri uma maneira de ter as mesmas transições perfeitas que vemos ao usar gestos com o Pixel padrão Lançador. Adam Cohen afirma Os planos do Google para resolver esses problemas “o mais rápido possível após o lançamento”. Ele diz ainda que a incompatibilidade "será resolvida na atualização pós-Q e suportada para novos dispositivos lançados com P."

Partições Dinâmicas/Lógicas não estão aqui para eliminar ROMs personalizadas

Para apoiar Atualizações dinâmicas do sistema no Android Q, certos dispositivos como o Google Pixel 3 e o Pixel 3 XL fazem uso de partições lógicas. Essas partições podem ser redimensionadas dinamicamente. Esta mudança tem provou ser um desafio para fazer o acesso root funcionar, e alguns desenvolvedores estão preocupados com o fato de ROMs personalizados estarem sendo direcionados. Iliyan Malchev nos garante que a intenção não é restringir ROMs customizados. Como ele explica:

"As partições dinâmicas não se destinam a restringir o que você pode fazer com ROMs personalizados. Elas são simplesmente um solução para o problema de tamanhos fixos de partição e falta de uma maneira segura de reparticionar dispositivos em OTA. Antes das partições dinâmicas, se um OEM cometesse um erro no dimensionamento, por ex. a partição do sistema, então eles seria restringido por essa escolha, tornando praticamente impossível atualizar um dispositivo após um certo apontar. Alguns OEMs reparticionam seus dispositivos em OTA por uma questão de prática, mas isso a) não é oficialmente suportado no Android eb) alterar a tabela de partição é considerado bastante arriscado. As partições dinâmicas visam aliviar o problema introduzindo um nível de indireção entre a tabela de partição física e o sistema operacional. Isso, por sua vez, nos permite ajustar com segurança os tamanhos das partições no OTA. Quanto às ROMs personalizadas, você não deve ficar mais limitado do que está hoje com o que pode fazer. O suporte a ROMs personalizadas é e continua a ser algo que cada OEM decide habilitar."

Linha principal do projeto - Módulo ART e duração do suporte

Mainline é uma nova iniciativa do Google que visa padronizar determinadas bibliotecas e pacotes para que possam ser atualizados independentemente das atualizações da plataforma. Alguns se perguntam por que o Android Runtime (ART) ainda não é um módulo Mainline, mas me disseram no Google I/O que a complexidade envolvida na modularização do ART impediu-os de incluí-lo como um dos pacotes iniciais do APEX. Como explicado por Iliyan Malchev e Diana Wong:

"Fazer atualizações no Runtime (especialmente correções de desempenho e GC e bibliotecas principais) é definitivamente algo que estamos explorando no contexto da linha principal. Podemos ver muitos benefícios em poder tornar essas atualizações consistentes em todos os dispositivos e em vários lançamentos com a linha principal. É também um enorme desafio técnico enquanto pensamos em como fazer isso da melhor forma para os desenvolvedores e provavelmente um esforço de vários anos. Não é algo que a Mainline possa fazer atualmente, mas certamente é algo em que estamos pensando."

Se você seguir o AOSP Gerrit, verá que o Google ainda assim tem sido dedicado no trabalho criando um Runtime APEX. Atualmente, eles parecem estar dividindo Bionic e ART/libcore em módulos APEX separados.

Em relação aos benefícios do Project Mainline, um usuário perguntou sobre a duração das atualizações do Mainline. Em resposta, Iliyan Malchev diz que “esta é uma questão de política que ainda estamos avaliando, mas queremos atualizar os módulos Mainline em um dispositivo pelo maior tempo possível”. Desenvolvedor reconhecido pelo XDA luca020400 questionado se módulos Mainline pré-construídos serão fornecidos para que desenvolvedores de ROM personalizados possam mesclar atualizações e, em resposta, Jeff Bailey reitera que "os módulos que estão se separando do AOSP terão versões de origem correspondentes a cada versão do módulo." Já podemos ver a progressão de novos módulos APEX no AOSP, como um para o API de redes neurais.

CameraX encontra kit de ML

No I/O deste ano, o Google apresentou o Biblioteca CameraX Jetpack. Esta biblioteca foi projetada para tornar mais fácil para os desenvolvedores o suporte à API Camera2 do Android, mantendo a compatibilidade desde o Android Lollipop. Vinit Modi provoca que a empresa está trabalhando na integração do CameraX com Kit de aprendizado de máquina, o Firebase SDK de aprendizado de máquina do Google, para que os desenvolvedores possam alimentar quadros de imagem no kit de ML para análise.

Extensões do fornecedor CameraX e data de lançamento

O desenvolvedor de um aplicativo de câmera lamenta o fato de que recursos avançados de câmera, como o Night Sight do Google Pixel, não estão acessíveis a aplicativos de câmera de terceiros. Supõe-se que isso possa ser resolvido com extensões de fornecedores CameraX, às quais Jeff Sharkey, do Google diz que “todos os dispositivos Pixel são otimizados para CameraX Core”. Ele brinca que “o aspecto Extensões será suportado em dispositivos novos e futuros”. Além disso, o Google está "trabalhando com vários fabricantes para poder levar os recursos de seus dispositivos aos desenvolvedores e usuários." Embora não seja confirmado diretamente, é possível que vejamos recursos como Visão noturna no Google Pixel 4 ficam disponíveis para aplicativos de câmera de terceiros que usam a biblioteca CameraX.

Sr. Sharkey afirma que o Google está planejando uma versão beta para o final deste ano.

Melhorias no gerenciamento de memória no Android Q

O Pixel 3 foi criticado por ter numerosos problemas pós-lançamento, mas o Google fez muito para resolver esses problemas por meio de vários atualizações pós-lançamento. O gerenciamento de memória tem sido um dos aspectos mais fracos do Pixel 3, mas as coisas devem melhorar um pouco no lançamento do Android Q. De acordo com Selim Cinek:

"No SystemUI, por exemplo, tivemos vários grandes esforços de refatoração em Q para reduzir o uso de RAM de notificações e outras superfícies."

Finalmente teremos ADB sem fio?

Se quiser depurar seu telefone sem fio, você terá que fazer root no seu dispositivo. Jamal Eason da equipe do Android Studio diz que eles estão atualmente abordando a viabilidade desse recurso.

O Google ainda testa em tablets?

Desenvolvedor reconhecido pelo XDA Luke1337 perguntou se o Google ainda testa AOSP UX em tablets. É uma pergunta justa, considerando o escassez de bons tablets Android e a bugs presentes nas versões atuais. Allen Huang diz que o Google ainda “testa e faz correções a cada ano” e que a empresa está trabalhando em estreita colaboração com parceiros “para garantir uma boa experiência no tablet Android”.

---

Há muito mais postagens no tópico completo no Reddit. O que abordei aqui resume todas as novas informações que obtivemos, mas vários Googlers (especialmente Dianne Hackborn) discutem seu raciocínio por trás do corte do recurso X ou da não implementação de Y permissão. Recomendo que você leia o AMA completo se quiser entender um pouco melhor a tomada de decisões da equipe Android.

Leia o AMA completo em /r/AndroidDev