Prévia do desenvolvedor do Android 11: todos os novos recursos de privacidade e segurança

O Google lançou o primeiro Android 11 Developer Preview para Pixel 2, 3, 3a e 4. Aqui estão todos os novos recursos de privacidade e segurança anunciados.

Antes do previsto, o Google lançou hoje o primeiro Developer Preview da próxima versão do sistema operacional Android: Android 11. As imagens do sistema estão disponíveis para Pixel 2, Pixel 3, Pixel 3a, Pixel 4, mas se você não possui um desses dispositivos, você também pode experimentar o Developer Preview por meio do emulador Android Studio ou do Generic System Imagem. Embora o Google esteja guardando a maioria dos novos recursos interessantes para usuários e desenvolvedores para um grande anúncio no Google I/O 2020, a empresa compartilhou uma infinidade de mudanças que estão disponíveis no primeiro Developer Preview. Aqui está um resumo de todos os novos recursos relacionados à privacidade e segurança que o Google anunciou no Android 11 Developer Preview 1.

Visualização 1 do desenvolvedor do Android 11 – Novos recursos de privacidade

Acesso com permissão única

O Android controla quais tipos de dados os aplicativos podem acessar por meio de seu sistema de permissão. Antes do Android 6.0 Marshmallow, os aplicativos solicitavam permissões durante a instalação, então os usuários tinham que decidir se concordavam com um aplicativo com determinadas permissões antes de instalá-lo. O Android 6.0 Marshmallow introduziu permissões de tempo de execução para um conjunto selecionado de permissões confidenciais, incluindo acesso à localização, acesso ao microfone e acesso à câmera. As permissões de tempo de execução só podem ser concedidas após a instalação, e o aplicativo que as solicita deve solicitar ao usuário por meio de uma caixa de diálogo fornecida pelo sistema para permitir o acesso. Finalmente, no Android 10, o Google introduziu uma versão especial da permissão de tempo de execução que permite ao usuário conceder acesso apenas enquanto o aplicativo estiver em uso ativo; no entanto, o Google introduziu apenas a opção “enquanto o aplicativo está em uso” para permissão de localização.

No Android 11, o Google oferece aos usuários um controle mais refinado sobre outras permissões confidenciais, incluindo acesso à câmera e ao microfone. A empresa introduziu um novo recurso de “permissão única” no Android 11 Developer Preview que permite que o usuário conceda temporariamente a um aplicativo acesso a uma permissão, desde que esse aplicativo esteja no primeiro plano. Depois que o usuário sai do aplicativo, o aplicativo perde o acesso a essa permissão e deve solicitá-la novamente.

Mudanças no armazenamento com escopo

Em Android 10 beta 2, o Google propôs uma mudança radical na forma como os aplicativos acessam o armazenamento externo no Android. (O armazenamento externo, aqui, é definido como os dados visíveis para o usuário e outros aplicativos localizados em /data/media.) O A mudança, apelidada de "Scoped Storage", teve como objetivo eliminar o uso excessivamente amplo do READ_EXTERNAL_STORAGE permissão. Muitos aplicativos na Google Play Store solicitavam e recebiam acesso a todo o armazenamento externo onde os usuários salvavam seus documentos privados, fotos, vídeos e outros arquivos. Com o armazenamento com escopo, os aplicativos, por padrão, só teriam a capacidade de ver seus diretórios de dados privados. Se um aplicativo tiver a permissão READ_EXTERNAL_STORAGE sob a aplicação do armazenamento com escopo, ele poderá visualizar determinados arquivos de mídia acessíveis por meio da API MediaStore. Como alternativa, o aplicativo pode usar o Storage Access Framework para que o usuário selecione manualmente os arquivos por meio do seletor de arquivos do sistema. Finalmente, aplicativos que precisam de amplo acesso ao armazenamento externo, como gerenciadores de arquivos, podem usar o Storage Access Framework para solicitar o usuário conceda ao aplicativo acesso ao diretório raiz do armazenamento externo, concedendo assim acesso a todos os seus subdiretórios, também.

A aplicação do armazenamento com escopo foi definida para entrar em vigor em todos os aplicativos no Android 10, mas após feedback e críticas dos desenvolvedores, Google relaxou as mudanças, exigindo-os apenas para aplicativos direcionados ao nível de API 29 (Android 10). Após 1º de agosto de 2020, todos os novos aplicativos enviados à Google Play Store deverão ser direcionados ao Android 10, e o mesmo se aplica a todas as atualizações de aplicativos existentes após 1º de novembro de 2020. Além disso, no Android 11, os desenvolvedores de aplicativos gerenciadores de arquivos deve enviar um formulário de declaração ao Google ter amplo acesso ao armazenamento externo; uma vez aceitos, os aplicativos gerenciadores de arquivos terão uma visualização não filtrada do MediaStore, mas não terão acesso a diretórios de aplicativos externos.

Além disso, o Google introduziu outras alterações no armazenamento com escopo no Android 11 Developer Preview. Os aplicativos podem optar por obter o caminho do arquivo bruto e realizar operações de edição em lote para arquivos de mídia no MediaStore. O DocumentsUI foi atualizado para ser mais simples para os usuários. Essas mudanças foram anunciadas no Encontro de Desenvolvedores Android no ano passado, e prometemos melhorias adicionais ao armazenamento com escopo em versões futuras do Android 11.

Visualização 1 do desenvolvedor do Android 11 – Novos recursos de segurança

Suporte para carteira de motorista móvel

Desde o início do ano passado, o Google vem trabalhando no API IdentityCredential e HAL no AOSP. Este recurso estabelece as bases para o armazenamento seguro de documentos de identificação em seu dispositivo móvel e, em particular, carteiras de habilitação móveis em conformidade com a ISO 18013-5. Google oficialmente anunciou esse recurso no Google I/O 2019e agora finalmente tem suporte no Android 11 Developer Preview 1.

O Google não disse muito sobre esse recurso no comunicado à imprensa, mas como o recurso está sendo desenvolvido abertamente, já sabemos muito do que está planejado. No I/O 2019, o Google afirmou que estava trabalhando com a ISO para padronizar a implementação de passaportes eletrônicos; ainda não temos ideia de quando os ePassports estarão disponíveis, mas já existem vários estados dos EUA onde os eDLs são implementados ou estão em fase de teste. O Google também disse que está trabalhando para fornecer uma biblioteca Jetpack para que os desenvolvedores possam criar aplicativos de identidade. Não sabemos quando os desenvolvedores poderão testar esse recurso, pois o suporte adequado requer hardware seguro no dispositivo. O Unidade de processamento segura no Qualcomm Snapdragon 865 suporta a API IdentityCredential, embora possa não suportar o modo de acesso direto da API, uma vez que o SPU está integrado ao SoC; O modo de acesso direto permitiria ao usuário obter uma identificação eletrônica armazenada mesmo quando não há energia suficiente para inicializar o Android. Para mais informações sobre esta API, recomendo lendo nossa cobertura inicial onde Shawn Willden, líder da equipe de segurança apoiada por hardware Android, forneceu sua opinião.

Novos módulos principais do projeto

Uma das maiores mudanças no Android 10 para dispositivos recém-lançados foi a introdução de Linha principal do projeto, que apesar do nome, não tem nada a ver com o suporte ao kernel Linux principal no Android. (A propósito, esse projeto é chamado de Generic Kernel Image e ainda é um trabalho em andamento.) Em vez disso, o objetivo do Project Mainline é Google vai retirar o controle dos principais componentes da estrutura e aplicativos de sistema dos OEMs. Cada módulo Mainline é encapsulado como um APK ou um arquivo APEX e pode ser atualizado pelo Google através da Play Store. O usuário vê as atualizações como uma "Atualização do sistema do Google Play" (GPSU) em seu dispositivo, e as atualizações são lançadas em uma cadência regular como um trem (ou seja, eles são baixados e instalados ao mesmo tempo).

Os benefícios do Projeto Mainline. Fonte: Google.

O Google exige a inclusão de módulos Mainline específicos, que na época do Google I/O 2019 incluíam 13. Agora, o Google está exigindo um total de 20 módulos Mainline no Android 11 Developer Preview 1.

Módulos principais iniciais (@ Google I/O 2019)

Módulos principais atuais (para Android 11 Developer Preview 1)*

ÂNGULO

Login do Portal Cativo

Login do Portal Cativo

Conscriptografar

Conscriptografar

Resolvedor DNS

Resolvedor DNS

IU de documentos

IU de documentos

Serviços Ext

Serviços Ext

Codecs de mídia

Codecs de mídia

Componentes da estrutura de mídia

Componentes da estrutura de mídia

Metadados do Módulo

Metadados do Módulo

Pilha de rede

Pilha de rede

Configuração de permissão de pilha de rede

Configuração de permissão de pilha de rede

Controlador de permissão

Controlador de permissão

Dados de fuso horário

Dados de fuso horário

Novo módulo de permissões

Novo módulo de provedor de mídia

Novo módulo API de redes neurais (NNAPI)

*Observação: no momento da publicação, o Google não nos forneceu a lista completa dos módulos Mainline atualmente necessários. Atualizaremos esta tabela assim que tivermos a lista completa.

Alterações biométricas imediatas

Torta Android 9 introduzida a API BiometricPrompt, uma API unificada para hardware de autenticação biométrica. A API fornece aos desenvolvedores uma maneira de desafiar o usuário por meio de dados biométricos salvos, sejam impressões digitais, rosto ou íris. Antes do BiometricPrompt, os desenvolvedores tinham que criar sua própria caixa de diálogo de autenticação e usar a API FingerprintManager, que suportava apenas autenticação de impressão digital, para desafiar o usuário. Nos smartphones Galaxy com scanners de íris, os desenvolvedores tiveram que usar o SDK da Samsung para desafiar o usuário. Com o BiometricPrompt, os desenvolvedores podem desafiar o usuário com qualquer método biométrico compatível, e o sistema fornece a caixa de diálogo ao usuário. Assim, os desenvolvedores não precisam mais se preocupar em fornecer suporte específico para um determinado tipo de hardware biométrico e também não precisam mais codificar a interface do usuário para a caixa de diálogo de autenticação. O Hardware de reconhecimento facial seguro do Pixel 4, por exemplo, pode ser usado para autenticação em aplicativos que usam BiometricPrompt.

Autenticação facial usando BiometricPrompt.

O que há de novo no BiometricPrompt no Android 11 Developer Preview 1? O Google adicionou três novos tipos de autenticador: forte, fraco e credencial de dispositivo. Antes do Android 11, os desenvolvedores só podiam consultar o hardware biométrico seguro do dispositivo – scanner de impressão digital, scanner de reconhecimento facial 3D ou scanner de íris – ao usar o BiometricPrompt. A partir do Android 11 Developer Preview 1, os desenvolvedores também podem consultar métodos biométricos considerados “fracos”, como as soluções de reconhecimento facial baseadas em software encontradas em muitos telefones. Por exemplo, Google vários telefones Samsung Galaxy anteriormente colocados na lista negra por retornar um autenticador de reconhecimento facial fraco ao tentar autenticação baseada em criptografia. Agora cabe ao desenvolvedor decidir qual nível de granularidade de autenticação biométrica seu aplicativo precisa.

Armazenamento seguro e compartilhamento de BLOBs

Uma nova API chamada BlobstoreManager tornará mais fácil e seguro para os aplicativos compartilharem blobs de dados entre si. O Google cita aplicativos que compartilham modelos de aprendizado de máquina como um caso de uso ideal da nova API BlobstoreManager.

Endurecimento da plataforma

Em um esforço para reduzir a superfície de ataque do Android, o Google usa Desinfetantes LLVM para identificar "bugs de uso indevido de memória e comportamento indefinido potencialmente perigoso". O Google agora está expandindo o uso desses sanitizadores baseados em compilador para vários componentes críticos de segurança, incluindo BoundSan, IntSan, CFI e Shadow-Call Stack. Para detectar problemas de memória na produção, o Google está habilitando "marcação de ponteiro de heap" para todos os aplicativos direcionados ao Android 11 ou superior. A marcação de ponteiro de heap é suportada em dispositivos ARMv8 de 64 bits com suporte de kernel para ARM Top-byte Ignore (TBI), um recurso no qual "o hardware ignora o byte superior de um ponteiro ao acessar a memória." O Google alerta os desenvolvedores que essas melhorias de proteção podem "revelam falhas de aplicativos mais repetíveis/reproduzíveis", portanto, os desenvolvedores devem testar exaustivamente seus aplicativos no novo Android 11 Developer Visualização. Para encontrar e corrigir muitos erros de memória no sistema, o Google usou uma ferramenta de detecção de erros de memória chamada AddressSanitizer assistido por hardware (HWASan). O Google está oferecendo imagens de sistema pré-construídas habilitadas para HWASan no servidor de compilação AOSP caso você esteja interessado em encontrar e corrigir erros de memória em seus próprios aplicativos.


O Google certamente anunciará recursos adicionais para proteger a privacidade do usuário e melhorar a segurança, portanto, fique de olho em nossa cobertura do Android 11 para se manter atualizado.

Notícias do Android 11 no XDA