Postado por Vlad Radu, gerente de produtos, Google Play e Diana Wong, gerente de produtos, Android
As CPUs de 64 bits oferecem experiências mais rápidas e ricas aos usuários. Acrescentar uma versão de 64 bits do seu app proporciona melhorias de desempenho, abre o caminho para futuras inovações e prepara você para dispositivos que tenham somente hardware de 64 bits.
Queremos ajudar você a se preparar e sabemos que você precisa de tempo para planejar. Oferecemos suporte para CPUs de 64 bits desde o Android 5.0 Lollipop e anunciamos em 2017 que os apps que usam código nativo devem oferecer a versão de 64 bits (além da versão de 32 bits). Nesta postagem, apresentaremos informações e cronogramas mais detalhados para facilitar o máximo possível a transição em 2019.
A partir de 1º de agosto de 2019:
A partir de 1º de agosto de 2021:
O requisito não se aplica a:
Não mudaremos nossa política de suporte para 32 bits. O Google Play continuará a oferecer apps para dispositivos de 32 bits. Esse requisito significa que apps com código nativo de 32 bits também precisarão ter uma versão adicional de 64 bits.
Para a maioria dos desenvolvedores, é esperado que a mudança para 64 bits seja simples. Muitos apps são escritos completamente em código não nativo (por exemplo, linguagem de programação Java ou Kotlin) e não precisam de mudanças no código.
Todos os desenvolvedores: Esta é uma visão geral das etapas que você precisará realizar para estar em conformidade com o requisito de 64 bits. Para ver um esquema mais detalhado desse processo, consulte nossa documentação específica.
Inspecione seu APK ou pacote de app em busca de código nativo. Verifique se há arquivos .so usando o APK Analyzer. Identifique se eles foram desenvolvidos com seu próprio código ou foram importados por um SDK ou uma biblioteca que você esteja usando. Se não houver arquivos .so no seu APK, você já está em conformidade com o requisito de 64 bits.
Ative arquiteturas de 64 bits e recompile o código nativo (arquivos .so) importado pelo seu próprio código. Consulte a documentação para ver mais detalhes.
Desenvolvedores de jogos: Todos os três mecanismos mais usados são compatíveis atualmente com 64 bits (Unreal e Cocos2d desde 2015, e Unity desde 2018). Entendemos que migrar para um mecanismo de jogo de terceiros é um processo complicado com tempos de ciclo demorados.
Como o Unity passou recentemente a oferecer suporte para 64 bits nas versões 2017.4 e 2018.2, oferecemos uma extensão automática para jogos existentes que usem as versões 5.6 ou anteriores até agosto de 2021. O Unity oferece guias que podem ajudar você com o processo de upgrade para uma versão compatível com 64 bits.
Proprietários de SDK e bibliotecas: Atualize para a conformidade com 64 bits assim que possível para dar tempo para os desenvolvedores de apps se adaptarem e informe-os sobre o assunto. Inscreva e registre seu SDK para receber atualizações sobre as ferramentas e informações mais recentes que podem ajudar você a atender seus clientes.
Agradecemos e parabenizamos o trabalho daqueles que já oferecem suporte para 64 bits. Se você ainda não está entre eles, recomendamos começar o processo para atender ao requisito de 64 bits o quanto antes. Atualizaremos nossa documentação de desenvolvedores com mais informações sobre como verificar a conformidade do seu app conforme nos aproximarmos do prazo final.
Estamos ansiosos para ver o futuro que as CPUs de 64 bits podem oferecer em áreas como inteligência artificial, aprendizado de máquina e dispositivos móveis imersivos. O suporte para 64 bits prepara o ecossistema para a inovação proporcionada pelos recursos de computação avançada de dispositivos de 64 bits e para os futuros dispositivos Android com suporte somente para código de 64 bits.
★ ★ ★ ★ ★
Publicado por Alberto Medina, mediador de desenvolvedores em tecnologia AMP e WordPress, Google
Para fazer com que usuários iniciantes tenham prática com sites e conteúdo na Web, o projeto AMP permite uma experiência com páginas móveis aceleradas de qualidade excepcional no WordPress. Ao longo do último ano, tivemos muito trabalho para melhorar a qualidade do plug-in AMP oficial e hoje estamos lançando a versão 1.0-stable do plug-in AMP oficial para WordPress.
A versão 1.0 do plug-in integra perfeitamente o fluxo de trabalho de criação de conteúdo AMP com a criação de conteúdo padrão do WordPress, tanto no modelo de edição clássico quanto no editor Gutenberg. Mais especificamente, uma experiência AMP nativa é compatível com esse lançamento. Isso permite que sites WordPress sejam construídos inteiramente com AMP, sem uma versão AMP duplicada de uma página em “modo pareado”.
Veja alguns recursos e funcionalidades da versão 1.0:
Convidamos você a experimentar a nova versão:
O plug-in AMP oficial para WordPress fornece ferramentas e funcionalidades essenciais para a criação de conteúdo AMP. É importante lembrar que o plug-in não é uma solução completa para “AMPlificar seu site”, mas tem funções que servem para permitir um ecossistema AMP compatível com o WordPress.
O que vem a seguir é uma jornada para que esse ecossistema seja adotado. Conforme seguimos por essa estrada, mais plug-ins e temas serão disponibilizados de forma criativa e com total compatibilidade AMP. Assim, os proprietários de sites encontrarão facilmente componentes que são compatíveis com AMP e poderão criar sites completos ao selecionar plug-ins da página de plug-ins/temas do WordPress.org.
No futuro, esperamos ter soluções completas que possam ser usadas pelos proprietários de sites para fornecer experiências AMP incríveis de maneira fácil, independentemente do nível de experiência que tiverem. Nosso objetivo final é a alta qualidade de conteúdo AMP em todos os sites do WordPress.
Junte-se a nós nessa jornada e compartilhe seu feedback sobre a versão mais recente. Estamos animados com o potencial que o plug-in tem de melhorar a experiência do usuário na Web e ansiosos pelo que está por vir.
Publicado por Ashish Shah, gerente de produtos, RA e RV do Google
A magia da realidade aumentada está na forma em que ela mescla o mundo digital e o físico. Para que as experiências em RA sejam realmente imersivas, os objetos digitais precisam parecer realistas, como se estivessem mesmo ali com você. Esse é um ponto que continuamos a priorizar enquanto trabalhamos na atualização do ARCore e do Sceneform, nossa biblioteca de renderização 3D para desenvolvedores Java.
Hoje, com o lançamento do ARCore 1.6, trazemos outras melhorias que ajudarão você a criar experiências mais realistas e atraentes, inclusive melhor controle de planos e diversas melhorias de iluminação no Sceneform.
Com 250 milhões de dispositivos compatíveis com o ARCore, os desenvolvedores podem trazer essas experiências para uma base de usuários ainda maior e em expansão.
As versões anteriores do Sceneform tinham a cor amarela como padrão para a otimização da luz ambiente. A versão 1.6 tem como padrão o neutro e o branco. Isso está mais de acordo com a forma que a luz aparece no mundo real, fazendo com que os objetos digitais pareçam mais naturais. Veja as diferenças abaixo.
Essa mudança também fará com que os objetos renderizados com o Sceneform pareçam afetados mais naturalmente pela cor e pela luz ao seu redor. Caso você esteja visualizando um objeto em RA durante o pôr do sol, por exemplo, ele aparecerá iluminado por tons de vermelho e laranja, assim como os objetos reais na paisagem.
Além disso, atualizamos a imagem do ambiente interno do Sceneform para fornecer uma cena mais neutra para seu app. Isso será mais perceptível ao visualizar reflexos em superfícies metálicas lisas.
Para ajudar você a melhorar ainda mais a qualidade e a interação nos seus apps de RA, adicionamos captura de tela e gravação ao Sceneform. Esse é um fator que diversos desenvolvedores solicitaram para ajudar com gravações de demonstração e prototipagem. Também pode ser usado como um recurso de face externa, permitindo que seus usuários compartilhem capturas de tela e vídeos nas mídias sociais com maior facilidade, o que pode ajudar a divulgar seu app.
Você pode acessar essa funcionalidade por meio da API de espelhamento de superfície para a classe do SceneView. A API permite que você mostre a visualização Sceneform na tela de um dispositivo ao mesmo tempo em que a renderização é feita em outra superfície (como a superfície de entrada do Android MediaRecorder).
As novas atualizações do Sceneform e do ARCore já estão disponíveis. Também incluída nessas novas versões está a compatibilidade com novos dispositivos, como o Samsung Galaxy A3 e o Huawei P20 Lite, que estarão na lista de dispositivos compatíveis com o ARCore. Confira maiores informações no site do desenvolvedor ARCore..
“Bem-vindo ao GDG São Francisco. Posso falar sobre...”
“Benvenuto a GDG San Francisco. Posso darti informazioni…”
“Bienvenidos a GDG San Francisco. Puedo contarte sobre…”
“Willkommen bei der GDG San Francisco. Ich kann dir mehr über unsere…”
Existem dispositivos Android de todos os tamanhos, formas e densidades de tela. É por isso que sou um grande fã da usar recursos vetorizados que não dependem de resolução. Mas o que exatamente eles são? Quais são os benefícios? Quais são os custos? Quando devem ser usados? Como devem ser criados e usados? Nesta série de postagens, gostaria de explorar esses questionamentos e explicar por que eu acho que a grande maioria dos recursos dos aplicativos deve ser composta por vetores e como aproveitá-los ao máximo.
A maioria dos formatos de imagem (png, jpeg, bmp, gif, webp, etc.) são rasterizados. Isso significa que eles descrevem a imagem como uma grade fixa de pixels. Sendo assim, são definidos em uma resolução específica e não conseguem entender informações sobre seu conteúdo, apenas a cor de cada pixel. Gráficos vetoriais, no entanto, descrevem a imagem como uma série de formas definidas em um tamanho de tela abstrato.
Os recursos vetorizados têm três benefícios principais. Eles são:
As imagens vetoriais podem ser redimensionadas com facilidade porque a descrição é feita em uma tela de tamanho abstrato. Assim, você pode aumentar ou diminuir a tela e redesenhar a imagem no tamanho desejado. Os recursos rasterizados, porém, podem se deteriorar ao serem redimensionados. A diminuição do tamanho dos recursos rasterizados costuma funcionar (já que você está descartando informações), mas aumentar o tamanho deles pode criar artefatos como distorções ou faixas porque os pixels que estiverem faltando precisarão ser interpolados.
É por isso que no Android precisamos oferecer diversas versões de cada recurso rasterizado para telas de diferentes densidades:
O Android seleciona a maior densidade aproximada e diminui o tamanho (se necessário). Devido à tendência de dispositivos com densidade de tela cada vez mais alta, os criadores de aplicativos precisam continuar gerando, incluindo e lançando versões cada vez maiores dos mesmos recursos. É importante lembrar que os dispositivos modernos não usam intervalos de densidade exatos. O Pixel 3 XL, por exemplo, é em 552 dpi, algo entre xxh dpi e xxxh dpi. Dessa forma, os recursos serão redimensionados com frequência.
Graças à excelente capacidade de redimensionamento dos recursos vetorizados, você pode adicionar um único recurso com a segurança de que ele funcionará em todas as densidades de tela.
Os recursos vetorizados são geralmente* mais compactos do que os rasterizados, pelo fato de você só precisar incluir uma única versão e pela compressão eficiente.
Por exemplo, aqui temos uma alteração feita no aplicativo Google I/O em que trocamos uma série de ícones PNG rasterizados por vetores, economizando 482 KB. Embora possa não parecer muito, esse resultado foi apenas com relação a pequenos ícones. Quando se trata de imagens maiores, como ilustrações, a economia é ainda mais relevante.
Esta ilustração, por exemplo, do fluxo de integração de um aplicativo I/O do ano passado:
Na época, não conseguimos substituir essa imagem por um VectorDrawable porque os gradientes ainda não eram amplamente compatíveis (spoiler: agora são!), então tivemos que lançar uma versão rasterizada. Usando um vetor, teríamos uma redução de 30% no tamanho e um resultado melhor :
Enquanto as divisões da configuração de densidade do Android App Bundle trazem benefícios semelhantes ao fornecer somente os recursos de densidade necessários ao dispositivo, um VectorDrawable geralmente será menor e além eliminará a necessidade de continuar criando recursos rasterizados cada vez maiores.
Por descrever seu conteúdo, ao invés de “achatar” as informações em pixels, as imagens vetoriais trazem novas e interessantes possibilidades como animação, interatividade ou temas dinâmicos. Falaremos mais sobre isso nas próximas postagens.
Os vetores têm algumas desvantagens que precisam ser consideradas:
Como mencionado anteriormente, os recursos vetorizados descrevem o conteúdo e, portanto, precisam ser inflados e desenhados antes do uso.
Há duas etapas para isso:
Essas duas etapas são proporcionais à complexidade do vetor e ao tipo de operação realizada. Se você usar formas muito intricadas, a análise para transformá-las em um caminho será mais demorada. De forma semelhante, mais operações de desenho levarão mais tempo para serem realizadas (e algumas são mais caras, como as operações de recorte). Abordaremos novamente esse assunto em uma postagem futura sobre a determinação dos custos.
Para vetores estáticos, o desenho precisa ser realizado somente uma vez e pode então ser armazenado em cache em um Bitmap. Os vetores animados não podem fazer essa otimização porque as propriedades são necessariamente alteradas, exigindo redesenho.
Compare isso com recursos rasterizados como o PNG, que só precisa decodificar o conteúdo do arquivo, algo que foi amplamente otimizado com o passar do tempo.
Esse é o principal ponto a ser considerado ao comparar os prós e os contras da rasterização e da vetorização. Os vetores proporcionam os benefícios mencionados acima, mas ao custo de uma renderização mais cara. No início do Android, os dispositivos eram menos poderosos e as densidades de tela variavam pouco. Atualmente, os dispositivos Android são mais poderosos e têm uma enorme variedade de densidades de tela. É por isso que eu acredito ser a hora de todos os aplicativos mudarem para recursos vetorizados.
Devido à natureza do formato, os vetores são ótimos para descrever alguns recursos, como ícones simples. Eles são péssimos para codificar imagens fotográficas, em que é mais difícil descrever o conteúdo com uma série de formas. Nesse caso, seria muito mais eficiente usar um formato rasterizado (como o webp). É claro que há muitas variações, então tudo depende da complexidade do recurso.
Nenhuma ferramenta de design (que eu conheça) pode criar VectorDrawables diretamente. Isso significa que há uma etapa de conversão a partir de outros formatos. Isso pode complicar o fluxo de trabalho entre designers e desenvolvedores. Trataremos desse tópico em detalhes em uma postagem futura.
Se você já trabalhou com formatos de imagem vetorial, já deve ter visto o formato SVG (gráficos vetoriais escalonáveis, na sigla em inglês), o padrão do setor na Web. Esse formato é eficiente, estabelecido e tem ferramentas consagradas, mas é também um padrão amplo . Ele inclui muitos recursos complexos como a execução de javascript arbitrário, efeitos de desfoque e filtro ou a incorporação de outras imagens, até mesmo gifs animados. O Android é executado em dispositivos móveis restritos, portanto, oferecer suporte a toda a especificação do SVG não era uma meta realista.
No entanto, o SVG inclui uma especificação de caminho que define como descrever e desenhar formas. Com essa API, você pode expressar a maioria das formas vetoriais. De modo geral, o Android é compatível com a especificação de caminho do SVG (e alguns adicionais).
Além disso, ao definir seu próprio formato, o VectorDrawable pode ser integrado a recursos da plataforma Android. Ele trabalha, por exemplo, com os recursos de sistema do Android para referenciar @colors, @dimens ou @strings, funcionando com atributos de tema ou AnimatedVectorDrawable usando animadores padrão.
Como mencionado, o VectorDrawable é compatível com a especificação de caminho do SVG, o que permite especificar uma ou várias formas a serem desenhadas. Ele é escrito como um documento XML semelhante a este:
Observe que você precisa especificar o tamanho intrínseco do recurso, que seria o tamanho que ele teria ao ser definido em um ImageView wrap_content. Os tamanhos da segunda janela de visualização definem a tela virtual ou coordenam o espaço no qual todos os comandos de desenho subsequentes são definidos. As dimensões intrínsecas e da janela de visualização podem variar (mas devem estar na mesma proporção): é possível definir os vetores em uma tela 1x1 se você desejar.
O elemento <vector> contém um ou muitos elementos <path>. Eles podem ser nomeados para referência posterior (como no caso de animações), mas é essencial que especifiquem um elemento pathData que descreva a forma. Essa string de aparência complexa pode ser compreendida como uma série de comandos controlando uma caneta em uma tela virtual:
Os comandos acima movem a caneta virtual, desenham uma linha até outro ponto, elevam e movem a caneta, para então desenhar uma nova linha. Com apenas os quatro comandos mais comuns, podemos descrever praticamente qualquer forma (há outros comandos, veja a especificação):
(Comandos em letra maiúscula usam coordenadas absolutas e aqueles em letra minúscula usam coordenadas relativas)
Você pode se perguntar se esse nível de detalhes é necessário. Não é possível conseguir isso com arquivos SVG? Embora você não precise ler um caminho e entender o que ele desenhará, ter um entendimento básico do que um VectorDrawable está fazendo é extremamente útil e necessário para compreender alguns dos recursos avançados que abordaremos depois.
Os caminhos por si só não desenham nada. Eles precisam ser traçados e/ou preenchidos.
A segunda parte desta série entrará em mais detalhes sobre as diferentes maneiras de preencher/traçar caminhos.
Você também pode definir grupos de caminhos. Isso permite que você defina transformações que serão aplicadas a todos os caminhos dentro do grupo.
Observe que você não pode girar, dimensionar ou traduzir caminhos individuais. Se desejar fazer isso, será necessário colocá-los em um grupo. Essas transformações fazem pouco sentido para imagens estáticas que poderiam “incorporá-las” em seus caminhos diretamente, mas são extremamente úteis no caso de animações.
Você também pode definir clip-paths, ou seja, mascarar a área na qual outros caminhos do mesmo grupo podem desenhar. Eles são definidos da mesma maneira que os caminhos.
Uma limitação importante é que os clip-paths não podem ser suavizados.
Esse exemplo (que eu tive que aumentar muito de tamanho para poder mostrar o efeito) demonstra duas abordagens de desenho do ícone de um obturador de câmera. A primeira desenha os caminhos, enquanto a segunda desenha um quadrado sólido, mascarado com a forma do obturador. O ato de mascarar pode criar efeitos interessantes (especialmente no caso de animações), mas é relativamente caro. Assim, procure evitá-lo, desenhando a forma de um modo diferente.
Os caminhos podem ser ajustados: é só desenhar um subconjunto do caminho inteiro. É possível ajustar caminhos preenchidos, mas os resultados podem ser surpreendentes! É mais comum ajustar caminhos traçados.
Você pode ajustar do início ou do fim de um caminho. Também é possível aplicar um deslocamento a qualquer ajuste. Eles são definidos como uma fração do caminho [0,1]. Veja como a definição de diferentes valores de ajuste altera a parte da linha que é desenhada. Perceba também que os deslocamentos podem fazer com que os valores de ajuste “se agrupem”. Mais uma vez, essa propriedade não faz muito sentido para imagens estáticas, mas é útil para animações.
O elemento vetor raiz é compatível com uma propriedade alfa [0, 1]. Os grupos não têm propriedade alfa, mas caminhos individuais são compatíveis com fillAlpha/strokeAlpha.
Espero que esta postagem ajude a compreender o que são os recursos vetorizados e os prós e contras deles. O formato vetorial do Android é eficiente e tem amplo suporte. Levando em consideração a variedade de dispositivos no mercado, o uso de recursos vetorizados deveria ser a escolha padrão, deixando a rasterização apenas para casos especiais. Junte-se a nós nas próximas postagens para saber mais:
Em breve: Desenho de um caminhoEm breve: Criação de recursos vetorizados para AndroidEm breve: Uso de recursos vetorizados em aplicativos AndroidEm breve: Criação de perfil do Android VectorDrawables
