Notícias de dispositivos móveis, gadgets, aplicativos Android

O documento de compatibilidade com o Android Nougat revela partes do plano do Google de levar os OEMs a um Android mais unificado

nougat_montelimar_1

Em todas as principais versões do Android, o Google lança um Documento de Definição de Compatibilidade do Android, que estabelece as regras do Google para OEMs do Android para que esses dispositivos sejam aprovados para serem enviados com os serviços do Google, incluindo a Play Store. Com o Android Nougat, a empresa esperou alguns meses para liberar esse documento e, hoje, ele finalmente chegou. O documento de 85 páginas detalha os planos do Google para OEMs para Android e, embora a maior parte do documento seja relativamente sem importância para a maioria das pessoas, há alguns pontos que vale a pena falar sobre…

“Extensões do Android”

O primeiro grande ponto de discussão, descoberto por, é “Extensões do Android”. Embora não saibamos completamente o que o Google tem reservado para isso, parece que ele poderia ser usado pelo Google para ignorar fabricantes e operadoras para enviar atualizações da API do AOSP para todo o ecossistema Android de uma só vez. Atualmente, os APKs que acionam as “Extensões Android” no Google Pixel e no LG V20 são em geral folhas em branco, mas com o tempo o Google poderia usar isso para enviar mais atualizações ao núcleo do Android sem exigir atualizações completas do sistema.

Com isso dito, de explica isso melhor do que eu posso:

Temos uma teoria: “Extensões do Android” é um plano para trazer o modelo de aplicativo facilmente atualizável para as APIs do AOSP. Como o Google Play Services, acreditamos que este aplicativo será um pacote de calços de API que o Google pode atualizar sempre que quiser. A diferença é que tudo no Play Services é uma API do Google de código fechado, enquanto as “Extensões do Android” seriam coleções de códigos AOSP atualizados entregues diretamente ao seu dispositivo pela Play Store. A estipulação do CDD que os OEMs “DEVEM pré-carregar a implementação do AOSP” é reveladora. Isso diz que 1) esse é o código AOSP e 2) Os OEMs não têm permissão para “personalizá-lo”.

E aqui está o texto direto do CDD:

3.1.1. Extensões Android

O Android inclui o suporte da extensão das APIs gerenciadas, mantendo a mesma versão no nível da API. As implementações de dispositivos Android DEVEM pré-carregar a implementação AOSP da biblioteca compartilhada ExtShared e dos serviços ExtServices com versões superiores ou iguais às versões mínimas permitidas para cada nível da API. Por exemplo, Android 7.0 implementações de dispositivos, executando o nível 24 da API DEVE incluir pelo menos a versão 1.

Google pode forçar os OEMs a parar de usar padrões proprietários de cobrança

Outra mudança importante é que este documento é o Google tentando afastar os OEMs dos padrões de cobrança proprietários. Se você me perguntar, este é o aspecto mais importante para o consumidor deste documento. No momento, existem vários “padrões” de carregamento rápido diferentes no mercado – Qualcomm Quick Charge, OnePlus Dash Charge, Motorola Turbo Charging, Huawei SuperCharge, Huawei SuperCharge, MediaTek Pump Express e OPPO VOOC apenas para citar alguns. Embora o Quick Charge seja o padrão mais usado atualmente, ele não funciona em todos os telefones, e o Google quer mudar isso.

Nós recomendamos:  O Inbox by Gmail está lembrando alguns usuários para enviar e-mails de acompanhamento, outros lembretes possivelmente chegando mais tarde

Nos dispositivos Pixel e Nexus do ano passado, o Google usa o USB Power Delivery para carregamento rápido. Isso não apenas permite o carregamento em jejum, mas também é compatível com todos os chipsets. Isso significa que, em um mundo perfeito, todos poderiam usar os mesmos carregadores rápidos em todos os smartphones. No atual CDD do Android, o Google está “recomendando fortemente” que os OEMs adotem o USB PD, mais tarde o Google poderá forçar essa funcionalidade, conforme indicado:

Os dispositivos tipo C são RECOMENDADOS para não oferecer suporte a métodos de carregamento proprietários que modificam a tensão Vbus além dos níveis padrão ou alteram as funções de coletor / fonte, pois podem resultar em problemas de interoperabilidade com os carregadores ou dispositivos compatíveis com os métodos padrão de fornecimento de energia USB. Embora isso seja chamado de “FORTE RECOMENDADO”, em futuras versões do Android, podemos exigir todos os dispositivos tipo C para oferecer suporte à interoperabilidade total com carregadores padrão tipo C

O Nougat não requer APIs do Vulkan

Outra coisa descoberta no CDD é a confirmação de que o Nougat não requer um chipset capaz de usar APIs do Vulkan para executar. Havia boatos de que esse era o principal motivo do Google para derrubar dispositivos como o Nexus 5 bem como OEMs para descartar dispositivos executados em chipsets Qualcomm mais antigos, mas claramente, esse não é o problema que pensávamos ser.

Implementações de dispositivo, se não incluindo o suporte das APIs do Vulkan:

  • DEVE reportar 0 VkPhysicalDevices através da chamada vkEnumeratePhysicalDevices.
  • NÃO DEVE excluir nenhum dos sinalizadores do recurso Vulkan PackageManager # FEATURE_VULKAN_HARDWARE_LEVEL e PackageManager # FEATURE_VULKAN_HARDWARE_VERSION.

O suporte a várias janelas deve seguir o AOSP

Um recurso que os OEMs têm há muito tempo, mas o Google esperou na implementação é de várias janelas. Não foi até o Nougat que o Google adicionou esse recurso como parte do sistema operacional, mas ainda havia a preocupação de que os OEMs tentassem tornar o recurso “próprio”. Felizmente, eles não terão a chance. Uma parte do CDD afirma estritamente que os OEMs não podem implementar nenhum formulário com várias janelas além do encontrado no AOSP. Já podemos ver isso em ação em dispositivos equipados com Nougat como o Huawei Mate 9 e LG V20.

Nós recomendamos:  Pebble lança loja de aplicativos no Android, novos aplicativos do eBay, Evernote e Time Warner Cable

Também digno de nota, os OEMs têm a opção de não implementar várias janelas, se optarem por fazê-lo. Na maioria das vezes, é improvável que os OEMs pule esse recurso, mas eu pude vê-lo absolutamente acontecendo em dispositivos com telas pequenas com desempenho inadequado.

3.8.14. Multi-windows

Uma implementação de dispositivo PODE optar por não implementar nenhum modo de várias janelas, mas se tiver a capacidade de exibir várias atividades ao mesmo tempo, DEVE implementar esses modos de várias janelas, de acordo com os comportamentos de aplicativos e APIs descritos no A documentação do suporte ao modo de várias janelas do Android SDK e atende aos seguintes requisitos.

Todos os smartphones Android devem oferecer suporte ao bloqueio de chamadas

A última grande coisa que apontaremos em relação ao bloqueio de chamadas. No Nougat, os OEMs devem oferecer suporte ao bloqueio de números para chamadas e mensagens. Isso inclui adicionar uma interface do usuário para gerenciar números bloqueados. Também podemos ver isso em ação no Huawei Mate 9 que está executando o Nougat.

7.4.1.1. Compatibilidade de bloqueio de números
As implementações de dispositivos de telefonia Android DEVEM incluir suporte a bloqueio de números e:

  • DEVE implementar totalmente o BlockedNumberContract e a API correspondente, conforme descrito na documentação do SDK.
  • DEVE bloquear todas as chamadas e mensagens de um número de telefone em ‘BlockedNumberProvider’ sem qualquer interação com os aplicativos. A única exceção é quando o bloqueio de números é temporariamente aumentado, conforme descrito na documentação do SDK.
  • NÃO DEVE gravar no provedor de log de chamadas da plataforma para uma chamada bloqueada.
  • NÃO DEVE escrever para o provedor de telefonia para obter uma mensagem bloqueada.
  • DEVE implementar uma interface de gerenciamento de números bloqueados, que é aberta com a intenção retornada pelo método TelecomManager.createManageBlockedNumbersIntent ().
  • NÃO DEVE permitir que usuários secundários visualizem ou editem os números bloqueados no dispositivo, pois a plataforma Android pressupõe que o usuário principal tenha controle total dos serviços de telefonia, uma única instância, no dispositivo. Todas as UI relacionadas ao bloqueio DEVEM estar ocultas para usuários secundários e a lista de bloqueios DEVE ainda ser respeitada.
  • DEVE migrar os números bloqueados para o provedor quando um dispositivo é atualizado para o Android 7.0.

Estas são apenas algumas das grandes mudanças do CDD da Nougat – existem, sem dúvida, muito mais. Apenas a partir deles, porém, podemos ver que o Google está trabalhando passo a passo para recuperar partes do Android e podemos ver esses resultados no Nougat. Listamos algumas outras alterações abaixo.

Android Auto

O Nougat CDD revela especificações atualizadas sobre os requisitos de hardware para aparelhos de som Android Auto, incluindo o tamanho e a resolução. Também mostra que os sensores de temperatura usados ​​com o Android Auto devem medir a cabine do veículo.

  • Os dispositivos Android Automotive DEVEM ter uma tela com o tamanho físico da diagonal maior ou igual a 6 polegadas.
  • Os dispositivos Android Automotive DEVEM ter um tamanho de tela de pelo menos 750 dp x 480 dp.
  • Para implementações do Android Automotive, SENSOR_TYPE_AMBIENT_TEMPERATURE DEVE medir a temperatura dentro da cabine do veículo.

Áudio

O documento também apresenta informações sobre como os dispositivos Android devem lidar com controles remotos em fones de ouvido conectados por meio de um 3Fone de ouvido de 5 mm.

7.8.2.1 Portas de áudio analógico

Para ser compatível com os fones de ouvido e outros acessórios de áudio usando o 3.5mm plug de áudio em todo o ecossistema Android, se uma implementação de dispositivo incluir uma ou mais portas de áudio analógicas, pelo menos uma das portas de áudio DEVE ser uma 4 condutor 3Jack de áudio de 5 mm. Se uma implementação de dispositivo tiver um 4 condutor 3Entrada de áudio de 5 mm, é:

DEVE apoiar a detecção e o mapeamento para os códigos-chave para os seguintes 3 faixas de impedância equivalente entre o microfone e os condutores de terra no plugue de áudio:

  • 70 ohm ou menos : KEYCODE_HEADSETHOOK
  • 210-290 Ohm : KEYCODE_VOLUME_UP
  • 360-680 Ohm : KEYCODE_VOLUME_DOWN

Gerenciador de pacotes

O Nougat também adiciona um requisito para a instalação de APKs. Mais detalhes podem ser encontrados aqui.

O gerenciador de pacotes DEVE suportar a verificação de arquivos “.apk” usando o APK Signature Scheme v2.

Exibição

Nós recomendamos:  Quer acompanhar o preço das criptomoedas no Android? Faça isso com esses aplicativos

As configurações que alteram a densidade / tamanho da exibição devem seguir a implementação do AOSP:

As implementações de dispositivos são fortemente recomendadas para fornecer aos usuários uma configuração para alterar o tamanho da tela. Se houver uma implementação para alterar o tamanho da tela do dispositivo, DEVE se alinhar com a implementação do AOSP