O investimento no mercado imobiliário é um jeito fantástico para gerar um fluxo de renda passiva e expandir seu patrimônio. Inúmeros estudos apontam que o investimento em imóveis criou mais milionários durante a história do que qualquer outro tipo de investimento (como este estudo e este). Então, por que não há mais pessoas fazendo isso?
Eu me perguntei exatamente isso há alguns após conversar com um grupo de amigos sobre o sucesso que tive com o mercado imobiliário e após escutar o porquê eles achavam que isso não era para eles.
A maioria deles achava que era algo muito difícil de aprender e dominar. Havia etapas demais, a curva de aprendizado era muito íngreme e havia muita possibilidade de cometer erros para alguém que estava apenas começando, especialmente ao analisar o desempenho financeiro de possíveis propriedades para investimento.
Tradicionalmente, a maioria dos investidores usava planilhas para fazer os cálculos, que só funcionava se você soubesse o que iria calcular e a forma como faria isso. Mas, se você não sabe essas informações, é muito fácil cometer erros e deixar alguns detalhes passarem batidos. Ninguém quer cometer erros matemáticos antes de uma grande compra, como uma propriedade para investimento.
Por onde começo?
Foi aí que tive a ideia de criar o DealCheck: uma ferramenta de análise de propriedade fácil de usar e baseada na nuvem para agentes e investidores imobiliários. Meu objetivo era criar uma plataforma que ajudasse novos investidores a aprender os macetes e evitar erros onerosos, mas, ao mesmo tempo, fornecer a flexibilidade para realizar análises mais avançadas com o clique de um botão.
Tornando o investimento imobiliário mais fácil e acessível.
Eu trabalhava como engenheiro de front-end na época, então já sabia que podia desenvolver a IU por conta própria, mas e o back-end, o armazenamento de dados, a autenticação e várias outras coisas necessárias para um aplicativo na nuvem completamente funcional?
Não conhecia ninguém que eu poderia incluir como cofundador, então comecei a pesquisar quais tecnologias e plataformas eu poderia aproveitar para me ajudar com a infraestrutura de back-end e do servidor.
O Firebase aparecia constantemente e comecei a procurar mais detalhes sobre ele. Na época, ele havia acabado de ser adquirido pelo Google e sua coleção de módulos BaaS (back-end-como-serviço) parecia oferecer a solução exata que eu precisava para criar o DealCheck.
Fiquei impressionado principalmente com a documentação de cada recurso e a maneira como todas as tecnologias diferentes podiam ser reunidas para criar uma plataforma unificada.
Logo abri uma conta e comecei a criar o primeiro MVP do app.
Como o único desenvolvedor no projeto, eu tinha pouco tempo e recursos para gastar desenvolvendo o back-end. Assim, decidi usar cada recurso do Firebase que estava disponível na época.
Meu objetivo, na realidade, era escrever o mínimo possível de código do lado do servidor e, em vez disso, me concentrar em aproveitar os diferentes módulos do Firebase para resolver três desafios específicos:
O primeiro desafio era a autenticação e o gerenciamento de usuários. Os usuários do DealCheck precisavam criar contas para que pudessem visualizar e analisar as propriedades em qualquer dispositivo (falarei mais sobre isso depois). Eu queria poder fazer login com e-mail, Facebook ou uma conta do Google.
O Firebase Authentication foi desenvolvido especialmente para esse propósito, e usei o recurso para gerenciar grande parte do processo do fluxo de gerenciamento. Como ele vem pronto, tem compatibilidade com a maioria das redes sociais, vinculação de credenciais em redes cruzadas e operações básicas de gerenciamento de conta, como alterações de e-mail, redefinições de senha e exclusões de conta.
Não precisava de qualquer código no lado de servidor. Eu só precisava criar uma IU no front-end.
Login com e-mail, Facebook e Google oferecido pelo Firebase.
Outro benefício do Firebase é que o Firebase Authentication se vincula diretamente ao produto Realtime Database para criar permissões declarativas e estrutura de controle de acesso que seja fácil de implementar e manter. Isso me ajudou a garantir que os dados do usuário fossem protegidos contra acesso não autorizado e facilitassem o compartilhamento de informações entre usuários.
O armazenamento de dados era o próximo item na lista. Eu queria que os usuários do DealCheck pudessem usar o app e analisar as propriedades on-line, no iOS e no Android. Por isso, eu precisava de uma solução de banco de dados baseada na nuvem e em tempo real que pudesse sincronizar dados entre dispositivos.
Sincronizar dados na Web e em dispositivos móveis não é fácil!
O Firebase Realtime Database é uma solução de banco de dados NoSQL baseada em JSON, que foi projetada exatamente para essa finalidade. Eu fiquei surpreso com o bom funcionamento dela. Usei as vinculações oficiais do AngularJS do Firebase no front-end para ler e gravar diretamente a partir do cliente.
Precisei trabalhar um pouco mais na parte móvel para implementar um modo off-line com sincronização após reconexões, mas, no geral, o código necessário para fazer tudo funcionar foi mínimo.
Como mencionei, o Firebase Authentication vinculou diretamente ao banco de dados para facilitar o controle de acesso. Assim, meu trabalho aqui havia terminado. Pude configurar backups diários de todos os dados automaticamente com apenas o clique de um botão.
Até agora, eu não havia escrito sequer uma linha de código no lado do servidor, e tudo estava sendo gerenciado diretamente pelo cliente. No entanto, à medida que o desenvolvimento do DealCheck avançou, eu sabia que precisaria de um servidor para gerenciar algumas operações que não poderiam ser feitas no cliente.
Eu não tinha muita experiência com manutenção de servidor e DevOps, mas felizmente, o produto Firebase Cloud Functions conseguiu atender a todas as minhas necessidades. As Cloud Functions são basicamente funções de objetivo único, que podem ser acionadas (ou executadas) com base em uma solicitação HTTP ou eventos específicos oriundos do Authentication, do Realtime Database ou de outros produtos do Firebase.
Cada função pode ser executada uma vez com base em um evento específico que acionará a execução da tarefa descrita. Você não precisa se preocupar com provisionar uma instância de servidor ou gerenciar uma carga. Tudo é feito automaticamente pelo Firebase.
Sabe o que é ainda mais legal? As Cloud Functions podem acessar os intervalos do Realtime Database e Cloud Storage do mesmo projeto, realizando operações neles no lado do servidor, quando necessário.
É assim que o DealCheck processa pagamentos de assinatura pelo Stripe, valida recibos de assinatura móvel pelo Apple e Google Play, se integra a APIs de terceiros e atualiza o registro de bancos de dados sem interação de usuários.
Incluindo dados de vendas comparáveis de fornecedores terceirizados para o DealCheck.
As Cloud Functions são como “cola” que unem toda a infraestrutura de back-end.
A primeira versão do app do DealCheck foi desenvolvida e lançada em menos de 5 meses, e eu estava sozinho na equipe de desenvolvimento. Eu realmente não achava que seria possível sem o Firebase oferecendo a infraestrutura de back-end. Talvez o projeto nem fosse lançado.
Embora o Firebase seja incrível para o desenvolvimento rápido de MVP, ele certamente foi projetado para também alimentar aplicativos de produção. À medida que o DealCheck cresceu de um pequeno projeto secundário para um dos apps imobiliários mais populares com mais de 100 mil usuários, todos os produtos do Firebase que usamos se dimensionaram para oferecer suporte para o aumento de carga.
Além disso, a interoperabilidade fantástica de todos os módulos do Firebase nos permite desenvolver e lançar novos recursos muito mais rapidamente porque precisa de menos código e possui fácil configuração.
Então, na próxima vez que você estiver pensando em desenvolver um projeto ambicioso com uma equipe pequena, confira como o Firebase pode ajudar você a reduzir o tempo de desenvolvimento e fornecer um pacote de ferramentas eficazes que crescem junto com sua empresa.
Foi exatamente assim como o DealCheck cresceu de uma ideia simples para tornar a análise de propriedades mais rápida e fácil para um app que ajuda dezenas de milhares de pessoas a aumentar seu patrimônio e renda passiva com verdadeiro investimento imobiliário. É uma experiência realmente incrível e gratificante ver seu trabalho afetar positivamente tantas pessoas, e isso não seria possível sem o Firebase.
O programa Recompensas de segurança do Android (ASR, na sigla em inglês) foi criado em 2015 para recompensar os pesquisadores que encontram e relatam problemas de segurança, ajudando a manter o ecossistema do Android protegido. Nos últimos quatro anos, premiamos mais de 1.800 relatórios e pagamos mais de US$ 4 milhões.
Hoje estamos expandindo o programa e aumentando os valores das recompensas. Anunciamos um prêmio máximo de US$ 1 milhão por uma exploração de execução remota de código em cadeia completa com persistência que comprometa o elemento de segurança Titan M em dispositivos Pixel. Além disso, lançaremos um programa específico que oferece um bônus de 50% para explorações encontradas em versões de visualização específicas para desenvolvedores do Android, o que significa que nosso maior prêmio agora é de US$ 1,5 milhão.
Como mencionado em uma postagem anterior do blog, em 2019, a Gartner avaliou o Pixel 3 com Titan M com as classificações mais “fortes” na seção de segurança integrada em todos os dispositivos verificados. Por isso, criamos um prêmio dedicado a recompensar os pesquisadores por explorações encontradas que contornem as proteções dos elementos de segurança.
Além das explorações que envolvem o Pixel Titan M, adicionamos outras categorias ao programa de recompensas, como as relacionadas a exfiltração de dados e desvio do bloqueio de tela. Essas recompensas chegam a US$ 500 mil, dependendo da categoria de exploração. Para ver todos os detalhes, consulte a página das regras do programa Recompensas de segurança do Android.
Agora que falamos sobre as novidades, recapitularemos fatos marcantes deste ano. Veja alguns destaques de 2019:
A maior recompensa paga a um membro da comunidade de pesquisa foi por um relatório de Guang Gong (@oldfresher), da Alpha Lab, Qihoo 360 Technology Co. Ltd. Esse relatório detalhou a primeira cadeia de exploração de execução remota de código com um clique no dispositivo Pixel 3. Guang Gong recebeu US$ 161.337 do Programa de recompensas de segurança do Android e US$ 40 mil do Programa de recompensas do Chrome, totalizando US$ 201.337. A recompensa combinada de US$ 201.337 também é o maior valor pago por uma única cadeia de exploração em todos os programas de recompensa de vulnerabilidade do Google (VRP, na sigla em inglês). As vulnerabilidades do Chrome apresentadas no relatório foram corrigidas no Chrome 77.0.3865.75 e lançadas em setembro, protegendo os usuários dessa cadeia de exploração.
Queremos agradecer a todos os nossos pesquisadores por contribuírem com a segurança do ecossistema do Android. Se você tiver interesse em se tornar um pesquisador, confira nossa Bughunter University para ter informações sobre como começar.
A partir de hoje, 21 de novembro de 2019, as novas recompensas entram em vigor. Todos os relatórios enviados antes de 21 de novembro de 2019 serão recompensados com base na tabela de recompensas anterior.
A temporada de caça aos bugs está aberta!
Quando se trata de serviços gerenciados do Kubernetes, o Google Kubernetes Engine (GKE) é uma ótima escolha se você procura por uma plataforma de orquestração de contêineres que ofereça escalonabilidade avançada e flexibilidade de configuração. O GKE oferece controle completo sobre todos os aspectos da orquestração de contêineres, desde rede e armazenamento até a forma como a capacidade de observação é configurada. Além disso, ele é compatível em casos de uso de aplicativos com estado. No entanto, caso seu aplicativo não precise desse nível de configuração e monitoramento de cluster, o Cloud Run totalmente gerenciado pode ser a solução certa para você.
O Cloud Run totalmente gerenciado é uma plataforma sem servidor ideal para microsserviços em contêiner sem estado, que não exigem recursos do Kubernetes como namespaces, localização conjunta de contêineres nos pods (arquivos secundários) ou alocação e gerenciamento de nós.
O Cloud Run, uma plataforma gerenciada de computação sem servidor, oferece diversos recursos e benefícios:
Implantação fácil de microsserviços. É possível implantar um microsserviço em contêiner com um único comando, sem a necessidade de outra configuração específica do serviço.
Experiência do desenvolvedor simples e unificada. Cada microsserviço é implementado como uma imagem do Docker, a unidade de implantação do Cloud Run.
Execução sem servidor escalonável. O escalonamento de um microsserviço implantado no Cloud Run gerenciado é feito automaticamente com base na quantidade de solicitações recebidas. Não é necessário configurar nem gerenciar um cluster do Kubernetes completo. Se não houver solicitações, o Cloud Run gerenciado escalonará para zero. Ou seja, nenhum recurso será usado.
Compatibilidade com códigos escritos em qualquer linguagem. O Cloud Run usa contêineres como base. Assim, é possível escrever códigos em qualquer linguagem, usando qualquer binário e biblioteca.
O Cloud Run está disponível em duas configurações: como um serviço totalmente gerenciado do Google Cloud e como o Cloud Run para Anthos (essa opção implanta o Cloud Run no cluster do Anthos GKE). Se você já usa o Anthos, o Cloud Run para Anthos pode implantar contêineres no seu cluster. Assim, é possível acessar tipos de máquinas personalizados, suporte de rede adicional e GPUs para melhorar os serviços do Cloud Run. Os serviços gerenciados do Cloud Run e os clusters do GKE podem ser criados e administrados completamente do console e da linha de comando.
O melhor disso é que é possível mudar sua escolha, alternando do Cloud Run gerenciado ao Cloud Run para Anthos ou vice-versa, sem precisar implementar o serviço novamente.
Para ilustrar esses pontos, vejamos um exemplo de caso de uso: um serviço que adiciona, atualiza, exclui e lista endereços.
É possível implementar esse serviço de gerenciamento de endereços por meio da criação de um microsserviço em contêiner para cada operação. Após as imagens terem sido criadas e registradas em um registro de contêiner, você pode implantá-las no Cloud Run gerenciado com apenas um comando. Quando os quatro comandos forem executados (uma implantação para cada microsserviço), o serviço estará ativo e operará em uma plataforma completamente sem servidor. A imagem a seguir mostra a implantação usando o Cloud Spanner como o banco de dados subjacente.
Para casos de uso como esse, o Cloud Run gerenciado é uma ótima escolha porque o serviço de gerenciamento de endereços não exige configurações complexas, de acordo com o que é compatível com o Kubernetes. Além disso, esse serviço não precisa de gerenciamento de cluster 24 horas por dia nem supervisão operacional. A execução desse serviço de gerenciamento de endereços como contêineres no Cloud Run é a melhor estratégia para a carga de trabalho de produção.
Por ser uma plataforma de computação gerenciada, o Cloud Run gerenciado é compatível com configurações essenciais: é possível definir as solicitações simultâneas máximas que um único contêiner recebe, o tamanho da memória de alocação para o contêiner e o tempo limite da solicitação. Não são necessárias configurações nem operações de gerenciamento adicionais.
O Cloud Run gerenciado e o GKE são ofertas poderosas para diferentes casos de uso. Antes de escolher, verifique se entendeu os requisitos de serviço funcionais e não funcionais, como a capacidade de escalonar para zero ou de controlar a configuração detalhada.
Pode ser que você queira usar as duas opções ao mesmo tempo. Uma empresa pode ter aplicativos complexos com base em microsserviços que exijam os recursos avançados de configuração do GKE e outros que, mesmo sem essa necessidade, queiram aproveitar a facilidade de uso e a escalonabilidade do Cloud Run.
Para saber mais sobre o Cloud Run, acesse nosso site e siga o guia rápido.
As primeiras impressões são muito importantes no local de trabalho. Muitas vezes, elas ocorrem por meio de documentos ou apresentações que compartilhamos com outras pessoas. Erros ortográficos ou gramaticais podem causar distrações e fazer com que uma proposta pareça não profissional, algo que todos nós queremos evitar. Estamos focados em oferecer recursos de escrita mais úteis no G Suite para auxiliar você a fazer seu melhor trabalho. Por isso, no começo do ano, apresentamos as novas ferramentas de correção gramatical no Documentos Google para ajudar as pessoas a escrever de forma mais rápida e precisa. Com a ajuda do aprendizado de máquina, já são mais de 100 milhões de sugestões de gramática sinalizadas a cada semana.
Avanço das sugestões de gramática com a tradução automática neuralAtualmente, o sistema de correção gramatical do Google usa a tecnologia de tradução automática. Cada sugestão é tratada como uma tarefa de tradução. Nesse caso, o conteúdo é traduzido do idioma da “gramática incorreta” para o idioma da “gramática correta”. Em um nível básico, a tradução automática substitui e reorganiza as palavras de um idioma de origem para um idioma de destino. Por exemplo, a substituição de uma palavra originária do inglês (“hello”) para uma palavra em espanhol (“hola”).
Com os avanços mais recentes da nossa equipe de pesquisa na área de processamento de linguagens, possibilitados pela tradução automática neural, estamos melhorando significativamente a maneira como corrigimos erros linguísticos por meio da correção de gramática neural no Documentos Google.
Como funcionaComo a Correção de erros gramaticais (GEC, na sigla em inglês) pode ser vista como uma “tradução” de sentenças gramaticalmente erradas para frases corretas, é possível aplicar modelos sequenciais desenvolvidos para tradução automática neural a essa tarefa. Para treinar modelos de qualidade, geralmente precisamos de milhões ou bilhões de exemplos de dados paralelos em que cada amostra de treinamento consista em uma sentença no idioma de origem pareada com a tradução no idioma de destino. Ao contrário de outras tarefas de tradução automática (como traduzir do inglês para o francês), há pouquíssimos dados paralelos para GEC. Com o objetivo de superar esse desafio, desenvolvemos dois métodos contrastantes para gerar grandes quantidades de dados paralelos para GEC.
O primeiro método traduz sentenças corretas para algum outro idioma e, em seguida, passa novamente para inglês, causando perda de qualidade.
O segundo método extrai pares origem/destino dos históricos de edição da Wikipédia com uma quantidade mínima de filtros.
Você pode ler mais sobre GEC e algumas das nossas abordagens neste artigo.
Para garantir que seria viável implantar os modelos no Documentos Google sem usar uma quantidade absurda de recursos de computação, usamos Unidades de Processamento de Tensor (TPUs, na sigla em inglês). As TPUs forneceram aumentos substanciais no desempenho de muitos outros produtos do Google, inclusive a Escrita inteligente no Gmail. Além disso, usamos a biblioteca do TensorFlow de código aberto do Google, Lingvo. Com ela, foi possível testar facilmente alterações de modelagem e otimizar de forma cuidadosa como as sugestões seriam geradas pelos núcleos de TPU.
O que isso significa para os redatoresQual o significado disso para você? Ao aplicar modelos de tradução automática neural à correção gramatical, conseguimos corrigir muitos outros erros gramaticais que você pode cometer enquanto escreve. Para lançar essas melhorias, fizemos muitos testes com o objetivo de garantir que as mudanças sejam mais úteis. Veja alguns exemplos do nosso processo de avaliação que demonstram os recursos da correção de gramática neural:
Qual o tempo verbal mesmo?
O correto é “steak” ou “stake”?
A mudança para o método de tradução automática neural apresenta um aumento notável no resultado de sugestões de correção gramatical no Documentos Google. Esperamos que essa atualização possa continuar facilitando sua escrita.
use_preemptible_nodepool()
copydata
train
train(2)
"invisible"
"activatable"
autofocus
font-optical-sizing
list-style-type
disc
decimal
::before
list-style-position
Worklet.addModule()
AbortError
SyntaxError
self.serviceWorker
self.serviceWorker.state
error
load
<script>
A Hugging Face é a startup líder em PLN com mais de mil empresas, incluindo Bing, Apple e Monzo, usando a biblioteca da organização em processos de produção. Todos os exemplos usados neste tutorial estão disponíveis no Colab. Encontre os links nas seções correspondentes.
A Hugging Face é uma startup focada no PLN e tem uma grande comunidade que trabalha em código aberto, usando especialmente a biblioteca Transformers. A 🤗/Transformers é uma biblioteca baseada em python que expõe uma API para o uso de diversas arquiteturas de transformação conhecidas, como BERT, RoBERTa, GPT-2 ou DistilBERT. Esses recursos geram resultados de ponta em diferentes tarefas do PLN, como classificação de texto, extração de informações, resposta a perguntas e geração de texto. Essas arquiteturas são pré-treinadas com vários conjuntos de pesos. Para dar os primeiros passos com a Transformers, você só precisa instalar o pacote pip:
pip install transformers
A biblioteca teve um crescimento veloz no PyTorch e foi portada recentemente para o TensorFlow 2.0, oferecendo uma API que funciona com a API fit do Keras, o TensorFlow Extended e TPUs 👏. Esta postagem do blog é dedicada ao uso da biblioteca Transformers com o TensorFlow. Com a API do Keras e o TPUStrategy do TensorFlow, é possível ajustar um modelo de transformação de última geração.
A Transformers é baseada no conceito de modelos de transformação pré-treinados. Esses modelos de transformação têm diferentes formas, tamanhos e arquiteturas e incluem maneiras próprias de aceitar dados de entrada: via tokenização.
A biblioteca é baseada em três classes principais: configuração, tokenização e modelo.
A vantagem da biblioteca Transformers está no uso de uma API simples e independente de modelo. O carregamento de um modelo pré-treinado, junto com o tokenizador, pode ser feito usando algumas linhas de código. Veja um exemplo de carregamento de modelos BERT e GPT-2 do TensorFlow, bem como os tokenizadores relacionados:
Os pesos são transferidos por download do intervalo S3 da Hugging Face e armazenados em cache localmente na sua máquina. Os modelos estão prontos para inferências ou podem ser ajustados, se necessário. Vejamos como isso funciona na prática.
Graças a alguns métodos disponíveis na biblioteca Transformer, ficou mais fácil ajustar um modelo. As partes a seguir são criadas da seguinte forma:
Criamos um notebook do Colab para ajudar você com o processo de codificação. Aproveitaremos o pacote tensorflow_datasets para o carregamento de dados. O Tensorflow-dataset oferece um tf.data.Dataset, que pode ser alimentado no nosso método glue_convert_examples_to_features.
Esse método utilizará o tokenizador para tokenizar a entrada e adicionar tokens especiais no início e no final das sequências, caso eles sejam exigidos pelo modelo (como [SEP], [CLS], </s> ou <s>, por exemplo). Isso retornará um tf.data.Dataset contendo as entradas com recursos.
Em seguida, podemos usar uma ordem aleatória desse conjunto de dados e agrupá-lo em lotes de 32 unidades usando os métodos padrão tf.data.Dataset.
Treinar um modelo usando o método fit do Keras nunca foi tão simples. Agora que temos a configuração do canal de entrada, podemos definir os hiperparâmetros e chamar o método fit do Keras com nosso conjunto de dados.
Usar uma estratégia oferece a você um controle maior sobre o que acontece durante o treinamento. Ao alternar entre estratégias, o usuário pode selecionar a forma distribuída usada para treinar o modelo: de várias GPUs a TPUs.
Até o momento, o TPUStrategy é a única maneira certeira de treinar um modelo em uma TPU usando o TensorFlow 2. Criar um loop personalizado usando uma estratégia é ainda mais útil, já que as estratégias podem ser facilmente alternadas, e o treinamento em várias GPUs não exige quase mudanças no código.
A configuração desse loop é um pouco trabalhosa. Por isso, aconselhamos você a abrir o notebook do Colab a seguir para ter uma melhor compreensão do assunto em questão. Você não encontrará detalhes sobre a tokenização como na primeira edição, mas verá como criar um canal de entrada que será usado pelo TPUStrategy.
O recurso usa o intervalo do Google Cloud Platform para hospedar dados, devido à complexidade do gerenciamento de TPUs em sistemas de arquivos locais. O notebook do Codelab está disponível aqui.
A principal vantagem da biblioteca Transformers é seu modelo de API simples e independente. Ao atuar como um front-end para modelos que geram resultados avançados em PLN, ela facilita muito a alternância entre modelos de acordo com a tarefa em questão.
Como exemplo, veja o script completo para ajustar BERT em uma tarefa de classificação idiomática (MRPC):
No entanto, em um ambiente de produção, a memória é escassa. Você poderia usar um modelo menor e mudar para DistilBERT, por exemplo. Para isso, basta alterar as duas primeiras linhas para as novas opções:
Como uma plataforma que hospeda mais de 10 arquiteturas de transformação, a 🤗/Transformers facilita o uso, o ajuste e a comparação dos modelos que transfiguraram o aprendizado detalhado para o campo do PLN. O recurso funciona como back-end para muitos aplicativos descendentes que utilizam modelos de transformação e é usado nos processos de produção em diversas empresas diferentes. Se você tiver perguntas ou questões, use nosso repositório do GitHub.
Kevin Chyn, biblioteca do Android
Curtis Belmonte, biblioteca do Android
Com o lançamento do Android 10 (API de nível 29), os desenvolvedores agora podem usar a API biométrica, parte da biblioteca AndroidX Biometric, para todas as necessidades de autenticação do usuário no dispositivo. A equipe da biblioteca e segurança do Android adicionou diversos recursos significativos à biblioteca AndroidX Biometric.Com isso, todo o comportamento biométrico do Android 10 é disponibilizado a todos os dispositivos que executam o Android 6.0 (API de nível 23) ou versões posteriores. A API é compatível com vários formatos de autenticação biométrica. Com ela, os desenvolvedores podem verificar com muito mais facilidade se determinado dispositivo tem sensores biométricos. Caso não haja nenhum sensor biométrico, a API permitirá que os desenvolvedores especifiquem se querem usar as credenciais do dispositivo nos aplicativos.
Os recursos não beneficiam apenas os desenvolvedores. Fabricantes de dispositivos e OEMs também têm bastante a comemorar. A biblioteca agora oferece uma API otimizada e padronizada para OEMs integrarem suporte a todos os tipos de sensores biométricos nos dispositivos. Além disso, a biblioteca tem suporte integrado para autenticação facial no Android 10. Assim, os fornecedores não precisam criar uma implementação personalizada.
A classe FingerprintManager foi introduzida no Android 6.0 (API de nível 23). Atualmente, e até o Android 9 (API de nível de 28), a API era compatível somente com sensores de impressão digital e sem IU. Os desenvolvedores precisavam criar uma IU de impressão digital própria.
FingerprintManager
Com base no feedback dos desenvolvedores, o Android 9 introduziu uma política da IU de impressão digital padronizada. O BiometricPrompt também foi introduzido para abranger mais sensores além da impressão digital. Além de fornecer uma IU segura e familiar para autenticação do usuário, isso permitiu que uma pequena superfície de API mantida pelos desenvolvedores acessasse a variedade de hardware biométrico disponível em dispositivos OEM. Agora, os OEMs podem personalizar a IU com os recursos e a iconografia necessários para expor novas biometrias, como contornos de sensores em exibição. Com isso, os desenvolvedores de aplicativos não precisam se preocupar em executar implementações personalizadas específicas de dispositivos para autenticação biométrica.
BiometricPrompt
Ou seja, no Android 10, a equipe introduziu alguns recursos essenciais para transformar a API biométrica em um balcão único para a autenticação do usuário no aplicativo. Com o BiometricManager, os desenvolvedores podem verificar se um dispositivo é compatível com a autenticação biométrica. Além disso, o método setDeviceCredentialAllowed() foi adicionado para oferecer aos desenvolvedores a opção de usar o PIN, o padrão ou a senha de um dispositivo em vez da credencial biométrica, caso faça sentido para o aplicativo.
BiometricManager
setDeviceCredentialAllowed()
A equipe incluiu todos os recursos biométricos do Android 10 à dependência Gradle do androidx.biometric. Assim, uma interface única e consistente é disponibilizada até o Android 6.0 (API de nível 23).
androidx.biometric
A dependência Gradle do androidx.biometric é uma biblioteca de suporte para as classes Biometric da biblioteca Android. Na API 29 e versões posteriores, a biblioteca usa as classes em android.hardware.biometrics e FingerprintManager até a API 23 e a credencial de confirmação até a API 21. Devido à variedade de APIs, é altamente recomendado usar a biblioteca de suporte androidx, independentemente do nível de API executado no seu aplicativo.
Biometric
android.hardware.biometrics
androidx
Para usar a API biométrica no seu aplicativo, siga as etapas abaixo:
$biometric_version é a versão mais recente da biblioteca
$biometric_version
def biometric_version= '1.0.0-rc02' implementation "androidx.biometric:biometric:$biometric_version"
O BiometricPrompt precisa ser recriado todas as vezes que houver a criação de Activity/Fragment. Isso precisa ser feito no onCreate() ou onCreateView() para que BiometricPrompt.AuthenticationCallback possa começar a receber os callbacks adequadamente.
Activity
Fragment
onCreate()
onCreateView()
BiometricPrompt.AuthenticationCallback
Para verificar se o dispositivo é compatível com a autenticação biométrica, adicione a lógica a seguir:
val biometricManager = BiometricManager.from(context) if (biometricManager.canAuthenticate() == BiometricManager.BIOMETRIC_SUCCESS){ // TODO: show in-app settings, make authentication calls. }
O construtor BiometricPrompt requer um Executor e um objeto AuthenticationCallback. Com o Executor, é possível especificar um thread que será usado para a execução dos callbacks.
Executor
AuthenticationCallback
O AuthenticationCallback tem três métodos:
onAuthenticationSucceeded()
onAuthenticationError()
onAuthenticationFailed()
O snippet a seguir mostra uma maneira de implementar o Executor e como instanciar o BiometricPrompt:
private fun instanceOfBiometricPrompt(): BiometricPrompt { val executor = ContextCompat.getmainExecutor(context) val callback = object: BiometricPrompt.AuthenticationCallback() { override fun onAuthenticationError(errorCode: Int, errString: CharSequence) { super.onAuthenticationError(errorCode, errString) showMessage("$errorCode :: $errString") } override fun onAuthenticationFailed() { super.onAuthenticationFailed() showMessage("Authentication failed for an unknown reason") } override fun onAuthenticationSucceeded(result: BiometricPrompt.AuthenticationResult) { super.onAuthenticationSucceeded(result) showMessage("Authentication was successful") } } val biometricPrompt = BiometricPrompt(context, executor, callback) return biometricPrompt }
A instanciação do BiometricPrompt precisa ser concluída no início do ciclo de vida do fragmento ou da atividade (por exemplo,em onCreate ou onCreateView). Isso garante que a instância atual sempre receberá adequadamente os callbacks de autenticação.
onCreate
onCreateView
Após ter um objeto BiometricPrompt, chame biometricPrompt.authenticate(promptInfo) para solicitar a autenticação ao usuário. Se o aplicativo exigir que o usuário autentique usando uma biometria forte ou precisar executar operações criptográficas no repositório de chaves, use authenticate(PromptInfo, CryptoObject).
biometricPrompt.authenticate(promptInfo)
authenticate(PromptInfo, CryptoObject)
Essa chamada mostrará a IU adequada ao usuário, com base no tipo da credencial biométrica usada para autenticação, como impressão digital, rosto ou íris. Como desenvolvedor, você não precisa saber qual o tipo de credencial é usado para autenticação, a API cuida disso tudo para você.
Essa chamada requer um objeto BiometricPrompt.PromptInfo. Um PromptInfo é onde você define o texto exibido na solicitação: como o título, subtítulo e a descrição. Sem um PromptInfo, não fica claro ao usuário final qual aplicativo está solicitando a credencial biométrica. Com o PromptInfo também é possível especificar se será permitido que dispositivos incompatíveis com a autenticação biométrica concedam acesso por meio das credenciais do dispositivo, como senha, PIN ou padrão usados para desbloquear o dispositivo.
BiometricPrompt.PromptInfo
PromptInfo
Veja este exemplo de loop de declaração PromptInfo:
private fun getPromptInfo(): BiometricPrompt.PromptInfo { val promptInfo = BiometricPrompt.PromptInfo.Builder() .setTitle("My App's Authentication") .setSubtitle("Please login to get access") .setDescription("My App is using Android biometric authentication") .setDeviceCredentialAllowed(true) .build() return promptInfo }
Para ações que requerem uma etapa de confirmação, como transações e pagamentos, recomendamos usar a opção padrão: setConfirmationRequired(true). Ela adicionará um botão de confirmação à IU, conforme exibido na Imagem 2.
setConfirmationRequired(true)
setConfirmationRequired(false)
Agora que já realizou todas as etapas obrigatórias, solicite a autenticação do usuário.
val canAuthenticate = biometricManager.canAuthenticate() if (canAuthenticate == BiometricManager.BIOMETRIC_SUCCESS) { biometricPrompt.authenticate(promptInfo) } else { Log.d(TAG, "could not authenticate because: $canAuthenticate") }
Está tudo pronto! Agora você pode executar a autenticação, usando credenciais biométricas, em qualquer dispositivo que opere no Android 6.0 (API de nível 23) ou versões posteriores.
Como o ecossistema continua a evoluir rapidamente, a equipe da biblioteca do Android pensa constantemente em formas de oferecer suporte a longo prazo para OEMs e desenvolvedores. Devido à IU com base no sistema consistente da biblioteca biométrica, os desenvolvedores não precisam se preocupar com requisitos específicos do dispositivo, e os usuários têm uma experiência mais confiável.
Será ótimo receber feedback de desenvolvedores e OEMs sobre como fortalecer, simplificar a utilização e melhorar o suporte de diversos casos de uso.
Para ver exemplos detalhados que exibem casos de uso adicionais e demonstram como você pode integrar essa biblioteca ao seu aplicativo, confira nosso repositório. Ele contém aplicativos de amostra funcionais que usam a biblioteca. Também é possível ler o guia do desenvolvedor associado e a referência da API para saber mais.
