Exclusivo: três dos melhores recursos do Android 11 não estarão em todos os dispositivos

Todos os anos, o Google lança uma nova versão do sistema operacional Android. O Google lançou o primeiro Android 11 Developer Preview em fevereiro, seguido pela segunda, terceira e quarta prévias para desenvolvedores nos últimos meses. No início deste mês, o Google revelou o primeiro Android 11 Beta e falei detalhadamente sobre os melhores recursos para os usuários aproveitarem e para os desenvolvedores implementarem. No entanto, agora aprendemos que três dos principais recursos do Android 11 não estarão disponíveis em todos os dispositivos Android.

Para entender como isso é possível, temos que explicar brevemente como o sistema operacional Android é distribuído pelo Google para fabricantes de smartphones. Android é um sistema operacional de código aberto licenciado sob Apache 2.0, o que significa que qualquer pessoa, desde desenvolvedores independentes até grandes empresas, é livre para modificar e distribuir o sistema operacional em seus próprios dispositivos. A maioria dos novos recursos do sistema operacional que o Google revelou para o Android 11 farão parte do Android Open Source Project (AOSP) que o smartphone os fabricantes de dispositivos baseiam seu próprio software, mas a licença Apache 2.0, como mencionei antes, permite que qualquer pessoa modifique o software como quiser ajustar. Para manter a consistência nas APIs e no comportamento da plataforma entre dispositivos Android, o Google agrupa a distribuição dos Google Mobile Services (que inclui aplicativos e estruturas como Google Play Store e Google Play Services) com contratos de licença que exigem que os dispositivos cumpram as regras do Google "

Programa de compatibilidade Android" (entre outros requisitos). O Programa de Compatibilidade do Android consiste em vários conjuntos de testes automatizados e um conjunto de regras enumeradas no Android Documento de definição de compatibilidade (CDD).

No CDD, o Google lista recursos de software e hardware que os fabricantes de dispositivos "DEVEM" implementar, são apenas "FORTEMENTE RECOMENDADOS" para implementar ou "NÃO DEVEM" implementar. Se um recurso estiver listado como implementação "OBRIGATÓRIA", o fabricante do dispositivo deverá adicionar esse recurso ou não poderá enviar aplicativos do Google em seus dispositivos. Se um recurso estiver listado como "NÃO DEVE" ser implementado, o fabricante do dispositivo não poderá adicionar esse recurso ou não poderá agrupar aplicativos do Google. Por fim, se um recurso estiver listado como “FORTEMENTE RECOMENDADO”, cabe ao fabricante do dispositivo decidir se deseja ou não implementar o recurso. O CDD é um documento em constante mudança, mesmo antes de sua publicação todos os anos após o lançamento público de uma nova versão do Android. O Google atualiza frequentemente o documento para remover recursos, alterar o idioma para ser mais claro e relaxar os requisitos com base no feedback de seus parceiros. No entanto, assim que o Google tornar público um CDD para uma versão específica do Android, esses requisitos serão definidos para dispositivos certificados pelo Google que executam essa versão do sistema operacional Android.

O CDD do Android 11 não se tornará público até o final deste ano, provavelmente no início de setembro. No entanto, desenvolvedor @deletarscape compartilhou uma cópia de pré-lançamento de um documento que detalha as mudanças que ocorrerão no CDD, dando-nos uma visão antecipada de como o Google está moldando o Android 11 em todo o ecossistema. A grande maioria das mais de 60 alterações no CDD não são muito interessantes para os usuários – elas descrevem como os fabricantes de dispositivos precisam implementar certas APIs, declarar certos recursos e implementar certos kernels características. No entanto, 3 das alterações no CDD chamaram a nossa atenção porque se referem a alguns dos recursos mais interessantes do Android 11. Aqui está o que descobrimos.

Controles de dispositivos

Controles de dispositivos é um recurso do Android 11 que permite que controles de automação residencial inteligentes sejam mostrados no menu de energia. Você pode desligar as luzes, abrir a porta da garagem, ligar o aspirador de pó, alterar a temperatura da sua casa e fazer muito mais sem abrir uma dúzia de aplicativos domésticos inteligentes diferentes. O Google adicionou APIs que os desenvolvedores de aplicativos domésticos inteligentes podem usar para exibir controles no menu de energia. Achamos que este é um recurso interessante que finalmente traz seu smartphone para a casa inteligente. Infelizmente, não há exigência para que os OEMs realmente o implementem. Se um OEM achar que o recurso é ruim ou quiser seguir um caminho diferente (como permitir apenas controles domésticos de dispositivos em seu próprio ecossistema), então eles podem simplesmente desativar o suporte para dispositivos Controles.

Quando o Google adicionou pela primeira vez os controles de dispositivos ao CDD em 25 de fevereiro de 2020, eles exigiram sua inclusão adicionando um requisito "OBRIGATÓRIO" na Seção 2.2.3 - Requisitos de software portátil. Porém, em 20 de maio de 2020, o Google atualizou o texto para retirar a proposta “DEVE”. A nova Seção 3.8.16 - Controles de Dispositivos descreve como o recurso deve ser implementado, mas na verdade não exige que ele seja implementado em primeiro lugar! Esperamos que os OEMs não desativem esse recurso bacana, mas não há como saber se eles o desativaram até que estejam prontos para revelar seus próprios sabores de Android construídos sobre o Android 11, o que não acontecerá até alguns meses depois agora.

Seção 3.8.16 proposta (nova) - Controles de dispositivos (atualizado em 20/05/2020)

3.8.16 Controles de dispositivos

O Android inclui APIs ControlsProviderService e Control para permitir que os desenvolvedores publiquem controles de dispositivos para status e ações rápidas para os usuários.

3.8.16.1 Recursos para usuários de controles de dispositivos

Se os dispositivos implementarem controles de dispositivos, eles:

• [C-1-1] DEVE relatar que o sinalizador android.software.controls.feature é VERDADEIRO
• [C-1-2] DEVE fornecer ao usuário a capacidade de adicionar, editar, selecionar e operar os favoritos do usuário a partir dos controles registrados pelos aplicativos de terceiros por meio de android.service.controls. ControlsProviderService e android.service.controls. APIs de controle.
• [C-1-3] DEVE fornecer acesso a esta capacidade do usuário dentro de três interações do Launcher
• [C-1-4] DEVE renderizar com precisão neste recurso do usuário o nome e o ícone de cada aplicativo de terceiros que fornece controles por meio do android.service.controls. API ControlsProviderService, bem como qualquer ícone especificado, texto de status, tipo de dispositivo, nome, estrutura, zona, cor personalizada e legenda fornecida pelo android.service.controls. API de controle

Por outro lado, se as implementações de dispositivos não implementarem tais controles, então elas

• [C-2-1] DEVE relatar Nulo para ControlsProviderService e APIs de controle.

consulte Mais informação

Conversas em notificações

Uma das maiores vantagens do Android em relação ao iOS é a forma como o primeiro lida com as notificações. Essa lacuna na usabilidade ficará ainda maior no Android 11 com a introdução de “Conversas”. No Android 11, notificações de aplicativos de mensagens são agrupados e mostrados em uma seção separada no painel de notificação acima da maioria dos outros notificações. Isso permite que você veja e responda mensagens rapidamente, sem precisar percorrer todas as outras notificações pendentes. Infelizmente, essa mudança bacana nas notificações pode não estar disponível em todos os dispositivos. O Google está dando aos OEMs a opção de escolher se desejam “agrupar e exibir notificações de conversas antes notificações que não são de conversa." Os OEMs frequentemente personalizam o painel de notificação e, portanto, não é surpresa que o Google esteja dando aos OEMs uma escolha aqui. Ainda assim, é lamentável que o Google não opte por impor mais consistência nas notificações no Android 11.

Alterações propostas na Seção 3.8.3.1 - Apresentação de Notificações (Atualizado em 08/04/2020)

Se as implementações de dispositivos permitirem que aplicativos de terceiros notifiquem os usuários sobre eventos importantes, eles:

...

O Android R apresenta suporte para notificação de conversa, que é uma notificação que usa NotificationManager. MessageStyle e fornece um ID de atalho de pessoas publicado.

As implementações de dispositivos são:

• [H-SR] FORTEMENTE RECOMENDADO agrupar e exibir notificações de conversa antes de não conversar notificações, com exceção de notificações de serviço em primeiro plano em andamento e importância: alta notificações.

Se as notificações de conversa forem agrupadas em uma seção separada, as implementações de dispositivos

• [H-1-8] DEVE exibir notificações de conversa antes das notificações que não são de conversa, com exceção de notificações de serviço em primeiro plano em andamento e importância: notificações altas.

As implementações de dispositivos são:

• [H-SR] FORTEMENTE RECOMENDADO fornecer acesso às seguintes ações a partir de notificações de conversas: exibir esta conversa como um balão se o aplicativo fornecer os dados necessários para os balões

A implementação do AOSP atende a esses requisitos com a UI do sistema, configurações e inicializador padrão.

consulte Mais informação

IdentityCredential - carteiras de motorista móveis

Por fim, um dos recursos que mais me entusiasma é a API IdentityCredential. Como detalhamos no ano passado, a API IdentityCredential foi projetada para permitir que aplicativos armazenem documentos de identidade, como carteiras de motorista móveis, no dispositivo. Vários países (e alguns estados dos EUA) ao redor do mundo já permitem que seus cidadãos armazenem suas carteiras de motorista em um aplicativo móvel. No entanto, o Google está trabalhando para tornar isso mais seguro, armazenando os dados off-line em um ambiente seguro.

O código-fonte do Android 11 inclui a API IdentityCredential (que os desenvolvedores chamarão para armazenar documentos de identidade no telefone ambiente seguro) e o IdentityCredential HAL (que faz interface com o ambiente seguro do telefone), mas os OEMs não são obrigados a implementá-los. Quando o Google propôs pela primeira vez a inclusão do IdentityCredential no CDD em 10 de janeiro de 2020, eles o listaram como um requisito. No entanto, eles flexibilizaram esse requisito em 18 de março de 2020 e agora apenas recomendam fortemente que os OEMs ofereçam suporte a esse recurso. Não estamos surpresos que o Google tenha flexibilizado esse requisito – adicionar uma mudança que impacte o ambiente de execução confiável exigirá esforço dos OEMs para ser implementado. É possível que os OEMs simplesmente precisem de mais tempo para se prepararem para essa mudança. Para os usuários, porém, isso significa que não há garantia de que seu smartphone Android 11 específico suporte o armazenamento seguro de uma carteira de motorista móvel no ambiente seguro do telefone.

Devemos observar que não há limitação técnica que impeça a adoção generalizada do sistema IdentityCredential entre dispositivos Android 11. Um dos requisitos para implementação do sistema IdentityCredential é que o dispositivo possua um Trusted Execution Ambiente (TEE) ou um processador seguro dedicado no qual um "aplicativo confiável" interage com a identidade armazenada documentos. Desde o Android 7.0 Nougat, o Google exige que todos os dispositivos Android modernos suportem um "ambiente de execução isolado" (por Seção 2.2.5 - Modelo de Segurança no CDD). Dispositivos com processadores ARM normalmente apresentam ARM Zona de confiança TEE, e o Google fornece o SO confiável que roda no TrustZone. A presença de um TEE é suficiente para suportar o sistema IdentityCredential, embora seria mais seguro se as credenciais fossem armazenadas em uma CPU segura incorporada (como no Unidade de processamento segura de alguns processadores Qualcomm Snapdragon) ou uma CPU discreta e segura (como em Titã M do Google ou Os novos chips de segurança da Samsung). Notavelmente, dispositivos com CPUs seguras discretas também podem suportar o recurso "modo de acesso direto" do sistema IdentityCredential, o que permitirá ao usuário obter seu documento de identidade mesmo quando não houver energia suficiente no dispositivo para inicializar o sistema operacional principal.

Seção 9.11.3 proposta (nova) - Credencial de identidade (atualizada em 18/03/2020)

O Sistema de Credenciais de Identidade permite que desenvolvedores de aplicativos armazenem e recuperem documentos de identidade do usuário.

Implementações de dispositivos:

• [C-SR] são FORTEMENTE RECOMENDADOS para implementar o Sistema de Credenciais de Identidade.

Se as implementações de dispositivos implementarem o Sistema de Credenciais de Identidade, elas:

• [C-0-1] DEVE retornar não nulo para o IdentityCredentialStore#getInstance() método.
• [C-0-2] DEVE implementar as APIs `android.security.identity.*` com código comunicando-se com um confiável aplicativo em execução em um ambiente de execução confiável (TEE) ou em um ambiente seguro dedicado processador. A aplicação confiável deve ser implementada de forma que o Base de computação confiável para o sistema de credenciais de identidade não inclui o sistema operacional Android.

consulte Mais informação

O Google também está trabalhando em uma biblioteca IdentityCredential Jetpack para tornar mais fácil para os desenvolvedores adicionar suporte para armazenamento seguro de identidades documentos no Android, mas o verdadeiro desafio será fazer com que os governos autorizem aplicativos que usam essa API para armazenar com segurança identificações governamentais. De acordo com Engajamento, a Coreia do Sul acaba de lançar suporte para armazenamento de carteiras de motorista em um aplicativo móvel, então estamos começando a ver um aumento na aceitação dessa tecnologia. Eu, por exemplo, estou animado para ver onde isso vai dar, porque significará uma coisa a menos para carregar comigo quando eu sair de casa.

---

O documento que obtivemos listava as alterações no CDD na data em que essas alterações foram feitas. As últimas alterações foram feitas em 10 de junho de 2020, o que significa que o documento que temos está bastante atualizado. É possível que o Google renegue essas mudanças e torne todos os requisitos novamente antes do lançamento público do Android 11, mas duvidamos que o Google de repente faça o CDD mais rigoroso. Essas mudanças provavelmente foram relaxadas devido ao feedback dos OEMs, que terão que voltar atrás e implementar esses recursos, caso ainda não estivessem planejados para fazê-lo. Isso leva tempo, esforço e dinheiro, o que atrasaria ainda mais o lançamento do Android 11 para dispositivos que não são do Google. Ainda assim, se o Google tornar esses recursos obrigatórios mais uma vez, publicaremos uma atualização no Portal XDA.