Definição de compatibilidade do Android 8.0

1. Introdução

Este documento enumera os requisitos que precisam ser atendidos para que os dispositivos sejam compatíveis com o Android 8.0.

O uso de “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY” e “OPTIONAL” é conforme o padrão IETF definido na RFC2119.

Conforme usado neste documento, um "implementador de dispositivo" ou "implementador" é uma pessoa ou organização que desenvolve uma solução de hardware/software com o Android 8.0. Uma "implementação de dispositivo" ou "implementação" é a solução de hardware/software desenvolvida.

Para serem consideradas compatíveis com o Android 8.0, as implementações de dispositivos PRECISAM atender aos requisitos apresentados nesta definição de compatibilidade, incluindo todos os documentos incorporados por referência.

Quando essa definição ou os testes de software descritos na seção 10 forem silenciosos, ambíguos ou incompletos, será responsabilidade do implementador do dispositivo garantir a compatibilidade com as implementações atuais.

Por esse motivo, o Android Open Source Project é a implementação de referência e preferida do Android. É ALTAMENTE RECOMENDÁVEL que os implementadores de dispositivos baseiem suas implementações o máximo possível no código-fonte "upstream" disponível no Projeto de código aberto do Android. Embora alguns componentes possam ser hipoteticamente substituídos por implementações alternativas, é ALTAMENTE RECOMENDADO não seguir essa prática, já que passar nos testes de software vai se tornar muito mais difícil. É responsabilidade do implementador garantir a compatibilidade comportamental total com a implementação padrão do Android, incluindo e além do conjunto de testes de compatibilidade. Por fim, observe que algumas substituições e modificações de componentes são explicitamente proibidas por este documento.

Muitos dos recursos vinculados neste documento são derivados diretamente ou indiretamente do SDK do Android e são funcionalmente idênticos às informações na documentação do SDK. Em qualquer caso em que esta definição de compatibilidade ou o Compatibility Test Suite discordar da documentação do SDK, a documentação do SDK será considerada oficial. Todos os detalhes técnicos fornecidos nos recursos vinculados neste documento são considerados parte desta definição de compatibilidade.

1.1 Estrutura do documento

1.1.1. Requisitos por tipo de dispositivo

A seção 2 contém todos os requisitos que se aplicam a um tipo de dispositivo específico. Cada subseção da Seção 2 é dedicada a um tipo de dispositivo específico.

Todos os outros requisitos, que se aplicam universalmente a qualquer implementação de dispositivo Android, estão listados nas seções após a Seção 2. Esses requisitos são mencionados como "Requisitos básicos" neste documento.

1.1.2. ID do requisito

O ID de requisito é atribuído para requisitos obrigatórios.

  • O ID é atribuído apenas para requisitos obrigatórios.
  • Os requisitos FORTEMENTE RECOMENDADOS são marcados como [SR], mas o ID não é atribuído.
  • O ID consiste em : ID do tipo de dispositivo - ID da condição - ID do requisito (por exemplo, C-0-1).

Cada ID é definido da seguinte forma:

  • ID do tipo de dispositivo (mais informações em 2. Tipos de dispositivo
    • C: Core (requisitos aplicados a qualquer implementação de dispositivo Android)
    • H: Dispositivo portátil Android
    • T: dispositivo Android TV
    • A: Implementação do Android Automotive
    • Guia: implementação em tablets Android
  • ID da condição
    • Quando o requisito é incondicional, esse ID é definido como 0.
    • Quando o requisito é condicional, o número 1 é atribuído à primeira condição, e o número aumenta em 1 na mesma seção e no mesmo tipo de dispositivo.
  • ID do requisito
    • Esse ID começa em 1 e aumenta em 1 na mesma seção e na mesma condição.

1.1.3. ID do requisito na seção 2

O ID do requisito na Seção 2 começa com o ID da seção correspondente, seguido pelo ID do requisito descrito acima.

  • O ID na Seção 2 consiste em : ID da seção / ID do tipo de dispositivo - ID da condição - ID do requisito (por exemplo, 7.4.3/A-0-1).

2. Tipos de dispositivo

Embora o Projeto Android Open Source forneça uma pilha de software que pode ser usada para vários tipos e formatos de dispositivos, alguns deles têm um ecossistema de distribuição de aplicativos relativamente melhor estabelecido.

Esta seção descreve esses tipos de dispositivos e outros requisitos e recomendações aplicáveis a cada um deles.

Todas as implementações de dispositivos Android que não se encaixam em nenhum dos tipos de dispositivo descritos PRECISAM atender a todos os requisitos das outras seções desta definição de compatibilidade.

2.1 Configurações do dispositivo

Para saber as principais diferenças na configuração de hardware por tipo de dispositivo, consulte os requisitos específicos do dispositivo que aparecem a seguir nesta seção.

2.2. Requisitos para dispositivos portáteis

Um dispositivo portátil Android se refere a uma implementação de dispositivo Android que normalmente é usado segurando-o na mão, como um player de MP3, smartphone ou tablet.

As implementações de dispositivos Android são classificadas como portáteis se atenderem a todos os seguintes critérios:

  • Ter uma fonte de energia que ofereça mobilidade, como uma bateria.
  • Ter um tamanho físico diagonal da tela de 2,5 a 8 polegadas.

Os requisitos adicionais no restante desta seção são específicos para implementações de dispositivos Android portáteis.

Observação:os requisitos que não se aplicam a dispositivos tablet Android estão marcados com um asterisco.

2.2.1. Hardware

Implementações de dispositivos portáteis:

  • [7.1.1.1/H-0-1] PRECISA ter uma tela com pelo menos 2,5 polegadas de tamanho físico na diagonal.
  • [7.1.1.3/H-SR] É ALTAMENTE RECOMENDADO oferecer aos usuários uma capacidade de mudar o tamanho da tela.(Densidade da tela)
  • [7.1.5/H-0-1] É PRECISO incluir suporte para o modo de compatibilidade de aplicativos legados conforme implementado pelo código de origem aberto do Android. Ou seja, as implementações de dispositivos NÃO PODEM alterar os acionadores ou limites em que o modo de compatibilidade é ativado e NEM o comportamento do próprio modo de compatibilidade.
  • [7.2.1/H-0-1] É PRECISO incluir suporte a editores de método de entrada (IME) de terceiros.
  • [7.2.3/H-0-1] É OBRIGATÓRIO fornecer as funções "Início", "Recentes" e "Voltar".
  • [7.2.3/H-0-2] É PRECISO enviar o evento de pressionar e pressionar longamente da função "Voltar" (KEYCODE_BACK) para o aplicativo em primeiro plano.
  • [7.2.4/H-0-1] É PRECISO oferecer suporte à entrada por touchscreen.
  • [7.3.1/H-SR] É ALTAMENTE RECOMENDADO incluir um acelerômetro de três eixos.

Se as implementações de dispositivos portáteis incluem um acelerômetro de três eixos, elas:

  • [7.3.1/H-1-1] PRECISA ser capaz de informar eventos com frequência de pelo menos 100 Hz.

Se as implementações de dispositivos portáteis incluem um giroscópio, elas:

  • [7.3.4/H-1-1] PRECISA ser capaz de informar eventos com frequência de pelo menos 100 Hz.

Implementações de dispositivos portáteis que podem fazer uma chamada de voz e indicar qualquer valor diferente de PHONE_TYPE_NONE em getPhoneType:

  • [7.3.8/H] DEVE incluir um sensor de proximidade.

Implementações de dispositivos portáteis:

  • [7.3.12/H-SR] É RECOMENDADO oferecer suporte ao sensor de pose com seis graus de liberdade.
  • [7.4.3/H]PRECISA incluir suporte a Bluetooth e Bluetooth LE.

Se as implementações de dispositivos portáteis incluem uma conexão com medição, elas:

  • [7.4.7/H-1-1] É OBRIGATÓRIO fornecer o modo de economia de dados.

Implementações de dispositivos portáteis:

  • [7.6.1/H-0-1] É PRECISO ter pelo menos 4 GB de armazenamento não volátil disponível para dados privados do aplicativo (também conhecidos como partição "/data").
  • [7.6.1/H-0-2] PRECISA retornar "true" para ActivityManager.isLowRamDevice() quando houver menos de 1 GB de memória disponível para o kernel e o espaço do usuário.

Se as implementações de dispositivos portáteis forem de 32 bits:

  • [7.6.1/H-1-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 512 MB se qualquer uma das seguintes densidades for usada:

    • 280 dpi ou menos em telas pequenas/normais*
    • ldpi ou menor em telas extragrandes
    • mdpi ou menor em telas grandes

  • [7.6.1/H-2-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 608 MB se qualquer uma das seguintes densidades for usada:

    • xhdpi ou superior em telas pequenas/normais*
    • hdpi ou mais em telas grandes
    • mdpi ou superior em telas extragrandes

  • [7.6.1/H-3-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 896 MB se qualquer uma das densidades a seguir for usada:

    • 400 dpi ou mais em telas pequenas/normais*
    • xhdpi ou superior em telas grandes
    • tvdpi ou superior em telas extragrandes

  • [7.6.1/H-4-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 1344 MB se qualquer uma das seguintes densidades for usada:

    • 560 dpi ou mais em telas pequenas/normais*
    • 400 dpi ou mais em telas grandes
    • xhdpi ou superior em telas extragrandes

Se as implementações de dispositivos portáteis forem de 64 bits:

  • [7.6.1/H-5-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 816 MB se qualquer uma das seguintes densidades for usada:

    • 280 dpi ou menos em telas pequenas/normais*
    • ldpi ou menor em telas extragrandes
    • mdpi ou menor em telas grandes

  • [7.6.1/H-6-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 944 MB se qualquer uma das densidades a seguir for usada:

    • xhdpi ou superior em telas pequenas/normais*
    • hdpi ou mais em telas grandes
    • mdpi ou superior em telas extragrandes

  • [7.6.1/H-7-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 1.280 MB se qualquer uma das seguintes densidades for usada:

    • 400 dpi ou mais em telas pequenas/normais*
    • xhdpi ou superior em telas grandes
    • tvdpi ou superior em telas extragrandes

  • [7.6.1/H-8-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 1824 MB se qualquer uma das seguintes densidades for usada:

    • 560 dpi ou mais em telas pequenas/normais*
    • 400 dpi ou mais em telas grandes
    • xhdpi ou superior em telas extragrandes

A "memória disponível para o kernel e o espaço do usuário" acima se refere ao espaço de memória fornecido, além de qualquer memória já dedicada a componentes de hardware, como rádio, vídeo e assim por diante, que não estão sob o controle do kernel nas implementações do dispositivo.

Implementações de dispositivos portáteis:

  • [7.6.2/H-0-1] NÃO é permitido fornecer um armazenamento compartilhado de aplicativos menor que 1 GiB.
  • [7.7.1/H] DEVE incluir uma porta USB com suporte ao modo periférico.

Se as implementações de dispositivos portáteis incluírem uma porta USB com suporte ao modo periférico, elas:

  • [7.7.1/H-1-1] É OBRIGATÓRIO implementar a API Android Open Accessory (AOA).

Implementações de dispositivos portáteis:

  • [7.8.1/H-0-1] É necessário incluir um microfone.
  • [7.8.2/H-0-1] É PRECISO ter uma saída de áudio e declarar android.hardware.audio.output.

Se as implementações de dispositivos portáteis incluem suporte ao modo de RV, elas:

  • [7.9.1/H-1-1] É OBRIGATÓRIO declarar o recurso android.software.vr.mode.

Se as implementações do dispositivo declararem o recurso android.software.vr.mode, elas:

  • [7.9.1/H-2-1] É OBRIGATÓRIO incluir um aplicativo que implemente android.service.vr.VrListenerService e possa ser ativado por aplicativos de RV usando android.app.Activity#setVrModeEnabled.

Se as implementações de dispositivos portáteis forem capazes de atender a todos os requisitos para declarar a flag de recurso android.hardware.vr.high_performance, elas:

  • [7.9.2/-1-1] É PRECISO declarar a flag de recurso android.hardware.vr.high_performance.

2.2.2. Multimídia

As implementações de dispositivos portáteis precisam ter suporte à seguinte codificação de áudio:

  • [5.1.1/H-0-1] AMR-NB
  • [5.1.1/H-0-2] AMR-WB
  • [5.1.1/H-0-3] Perfil MPEG-4 AAC (AAC LC)
  • [5.1.1/H-0-4] Perfil MPEG-4 HE AAC (AAC+).
  • [5.1.1/H-0-5] AAC ELD (AAC aprimorado com atraso baixo)

As implementações de dispositivos portáteis precisam oferecer suporte à seguinte decodificação de áudio:

  • [5.1.2/H-0-1] AMR-NB
  • [5.1.2/H-0-2] AMR-WB

As implementações de dispositivos portáteis PRECISAM oferecer suporte à codificação de vídeo a seguir e disponibilizá-la para aplicativos de terceiros:

  • [5.2/H-0-1] H.264 AVC
  • [5.2/H-0-2] VP8

As implementações de dispositivos portáteis precisam ter suporte à seguinte decodificação de vídeo:

  • [5.3/H-0-1] H.264 AVC
  • [5.3/H-0-2] H.265 HEVC
  • [5.3/H-0-3] MPEG-4 SP
  • [5.3/H-0-4] VP8
  • [5.3/H-0-5] VP9

2.2.3. Software

Implementações de dispositivos portáteis:

  • [3.4.1/H-0-1] É PRECISO fornecer uma implementação completa da API android.webkit.Webview.
  • [3.4.2/H-0-1] É PRECISO incluir um aplicativo de navegador independente para navegação geral na Web.
  • [3.8.1/H-SR] É ALTAMENTE RECOMENDADO implementar uma tela de início padrão compatível com a fixação de atalhos e widgets no app.
  • [3.8.1/H-SR] É ALTAMENTE RECOMENDADO implementar um iniciador padrão que ofereça acesso rápido aos atalhos adicionais fornecidos por apps de terceiros pela API ShortcutManager.
  • [3.8.1/H-SR] É ALTAMENTE RECOMENDADO incluir um app de inicialização padrão que mostre selos para os ícones do app.
  • [3.8.2/H-SR] É ALTAMENTE RECOMENDADO oferecer suporte a widgets de apps de terceiros.
  • [3.8.3/H-0-1] É PRECISO permitir que apps de terceiros notifiquem os usuários sobre eventos importantes usando as classes de API Notification e NotificationManager.
  • [3.8.3/H-0-2] É NECESSÁRIO oferecer suporte a notificações avançadas.
  • [3.8.3/H-0-3] É PRECISO oferecer suporte a notificações de alerta.
  • [3.8.3/H-0-4] É PRECISO incluir uma aba de notificações, permitindo que o usuário controle diretamente (por exemplo, responder, adiar, descartar, bloquear) as notificações por meio de recursos para o usuário, como botões de ação ou o painel de controle implementado no AOSP.
  • [3.8.4/H-SR] É ALTAMENTE RECOMENDADO implementar um assistente no dispositivo para processar a ação de assistência.

Se as implementações de dispositivos portáteis Android oferecerem suporte a uma tela de bloqueio, elas:

  • [3.8.10/H-1-1] É PRECISO mostrar as notificações da tela de bloqueio, incluindo o modelo de notificação de mídia.

Se as implementações de dispositivos portáteis oferecerem suporte a uma tela de bloqueio segura, elas:

Implementações de dispositivos portáteis:

  • [3.10/H-0-1] É PRECISO oferecer suporte a serviços de acessibilidade de terceiros.
  • [3.10/H-SR] É ALTAMENTE RECOMENDADO pré-carregar serviços de acessibilidade no dispositivo que sejam comparáveis ou superem a funcionalidade do Switch Access e do TalkBack (para idiomas compatíveis com o mecanismo de conversão de texto em voz pré-carregado), conforme fornecido no projeto de código aberto do Talkback.
  • [3.11/H-0-1] É PRECISO oferecer suporte à instalação de mecanismos de TTS de terceiros.
  • [3.11/H-SR] É ALTAMENTE RECOMENDADO incluir um mecanismo de TTS compatível com os idiomas disponíveis no dispositivo.
  • [3.13/H-SR] É ALTAMENTE RECOMENDADO incluir um componente de interface de configurações rápidas.

Se as implementações de dispositivos portáteis Android declararem suporte a FEATURE_BLUETOOTH ou FEATURE_WIFI, elas:

  • [3.15/H-1-1] É PRECISO oferecer suporte ao recurso de pareamento do dispositivo complementar.

2.2.4. Desempenho e energia

  • [8.1/H-0-1] Latência de frame consistente. A latência inconsistente ou um atraso na renderização de frames NÃO PODE acontecer mais de 5 vezes por segundo e DEVE ser inferior a 1 frame por segundo.
  • [8.1/H-0-2] Latência da interface do usuário. As implementações de dispositivos precisam garantir uma experiência do usuário com baixa latência, rolando uma lista de 10 mil entradas, conforme definido pelo conjunto de testes de compatibilidade do Android (CTS, na sigla em inglês), em menos de 36 segundos.
  • [8.1/H-0-3] Troca de tarefas. Quando vários aplicativos são iniciados, a reabertura de um aplicativo já em execução precisa levar menos de um segundo.

Implementações de dispositivos portáteis:

  • [8.2/H-0-1] É PRECISO garantir um desempenho de gravação sequencial de pelo menos 5 MB/s.
  • [8.2/H-0-2] É PRECISO garantir um desempenho de gravação aleatória de pelo menos 0,5 MB/s.
  • [8.2/H-0-3] É PRECISO garantir um desempenho de leitura sequencial de pelo menos 15 MB/s.
  • [8.2/H-0-4] É PRECISO garantir um desempenho de leitura aleatória de pelo menos 3,5 MB/s.
  • [8.3/H-0-1] Todos os apps isentos dos modos de economia de energia "App Standby" e "Soneca" precisam ser mostrados ao usuário final.
  • [8.3/H-0-2] O acionamento, a manutenção, os algoritmos de ativação e o uso de configurações globais do sistema dos modos de espera do app e de suspensão NÃO PODEM se desviar do Projeto Android Open Source.

Implementações de dispositivos portáteis:

  • [8.4/H-0-1] É obrigatório fornecer um perfil de energia por componente que defina o valor de consumo atual para cada componente de hardware e o consumo aproximado da bateria causado pelos componentes ao longo do tempo, conforme documentado no site do Projeto Android Open Source.
  • [8.4/H-0-2] É OBRIGATÓRIO informar todos os valores de consumo de energia em miliamperes-hora (mAh).
  • [8.4/H-0-3] É OBRIGATÓRIO informar o consumo de energia da CPU por UID de cada processo. O Android Open Source Project atende ao requisito com a implementação do módulo do kernel uid_cputime.
  • [8.4/H-0-4] É OBRIGATÓRIO disponibilizar esse uso de energia ao desenvolvedor do app pelo comando de shell adb shell dumpsys batterystats.
  • [8.4/H] DEVE ser atribuído ao próprio componente de hardware se não for possível atribuir o uso de energia do componente de hardware a um aplicativo.

Se as implementações de dispositivos portáteis incluírem uma tela ou saída de vídeo, elas:

2.2.5. Modelo de segurança

Implementações de dispositivos portáteis:

  • [9.1/H-0-1] É PRECISO permitir que apps de terceiros acessem as estatísticas de uso usando a permissão android.permission.PACKAGE_USAGE_STATS e ofereçam um mecanismo acessível ao usuário para conceder ou revogar o acesso a esses apps em resposta à intent android.settings.ACTION_USAGE_ACCESS_SETTINGS.

2.3. Requisitos de televisão

Um dispositivo Android TV se refere a uma implementação de dispositivo Android que é uma interface de entretenimento para consumir mídia digital, filmes, jogos, apps e/ou TV ao vivo para usuários sentados a cerca de 3 metros de distância (uma interface de usuário "lean back" ou "10 feet").

As implementações de dispositivos Android são classificadas como uma televisão se atenderem a todos os seguintes critérios:

  • Fornecer um mecanismo para controlar remotamente a interface do usuário renderizada na tela, que pode estar a 3 metros de distância do usuário.
  • Ter uma tela integrada com comprimento diagonal maior que 24 polegadas OU incluir uma porta de saída de vídeo, como VGA, HDMI, DisplayPort ou uma porta sem fio para exibição.

Os requisitos adicionais no restante desta seção são específicos para implementações de dispositivos Android TV.

2.3.1. Hardware

Implementações de dispositivos de TV:

  • [7.2.2/T-0-1] É PRECISO ter suporte ao D-pad.
  • [7.2.3/T-0-1] É OBRIGATÓRIO fornecer as funções "Início" e "Voltar".
  • [7.2.3/T-0-2] É PRECISO enviar o evento de pressionamento normal e longo da função "Voltar" (KEYCODE_BACK) para o aplicativo em primeiro plano.
  • [7.2.6.1/T-0-1] É PRECISO incluir suporte a controles de jogos e declarar a flag de recurso android.hardware.gamepad.
  • [7.2.7/T] DEVE fornecer um controle remoto em que os usuários possam acessar entradas de navegação sem toque e teclas de navegação principais.

Se as implementações de dispositivos de TV incluírem um giroscópio, elas:

  • [7.3.4/T-1-1] PRECISA ser capaz de informar eventos com frequência de pelo menos 100 Hz.

Implementações de dispositivos de TV:

  • [7.4.3/T-0-1] É PRECISO ter suporte a Bluetooth e Bluetooth LE.
  • [7.6.1/T-0-1] É PRECISO ter pelo menos 4 GB de armazenamento não volátil disponível para dados privados do aplicativo (também conhecidos como partição "/data").

Se as implementações do dispositivo de TV forem de 32 bits:

  • [7.6.1/T-1-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 896 MB se qualquer uma das densidades a seguir for usada:

    • 400 dpi ou mais em telas pequenas/normais
    • xhdpi ou superior em telas grandes
    • tvdpi ou superior em telas extragrandes

Se as implementações do dispositivo de TV forem de 64 bits:

  • [7.6.1/T-2-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 1.280 MB se qualquer uma das densidades a seguir for usada:

    • 400 dpi ou mais em telas pequenas/normais
    • xhdpi ou superior em telas grandes
    • tvdpi ou superior em telas extragrandes

A "memória disponível para o kernel e o espaço do usuário" acima se refere ao espaço de memória fornecido, além de qualquer memória já dedicada a componentes de hardware, como rádio, vídeo e assim por diante, que não estão sob o controle do kernel nas implementações do dispositivo.

Implementações de dispositivos de TV:

  • [7.8.1/T] DEVE incluir um microfone.
  • [7.8.2/T-0-1] É PRECISO ter uma saída de áudio e declarar android.hardware.audio.output.

2.3.2. Multimídia

As implementações de dispositivos de TV precisam oferecer suporte à seguinte codificação de áudio:

  • [5.1/T-0-1] Perfil MPEG-4 AAC (AAC LC)
  • [5.1/T-0-2] Perfil MPEG-4 HE AAC (AAC+)
  • [5.1/T-0-3] AAC ELD (AAC aprimorado com atraso baixo)

As implementações de dispositivos de TV precisam oferecer suporte à seguinte codificação de vídeo:

  • [5.2/T-0-1] H.264 AVC
  • [5.2/T-0-2] VP8

Implementações de dispositivos de TV:

  • [5.2.2/T-SR] É ALTAMENTE RECOMENDADO oferecer suporte à codificação H.264 de vídeos com resolução de 720p e 1080p.
  • [5.22/T-SR] É ALTAMENTE RECOMENDÁVEL oferecer suporte à codificação H.264 de vídeos com resolução de 1080p a 30 quadros por segundo (QPS).

As implementações de dispositivos de TV precisam oferecer suporte à seguinte decodificação de vídeo:

  • [5.3/T-0-1] H.264 AVC
  • [5.3/T-0-2] H.265 HEVC
  • [5.3/T-0-3] MPEG-4 SP
  • [5.3/T-0-4] VP8
  • [5.3/T-0-5] VP9

As implementações de dispositivos de TV são ALTAMENTE RECOMENDADAS para oferecer suporte à seguinte decodificação de vídeo:

  • [5.3/T-SR] MPEG-2

Se as implementações de dispositivos de TV forem compatíveis com decodificadores H.264, elas:

  • [5.3.4/T-1-1] É PRECISO ter suporte ao perfil de nível 4.2 de perfil alto e ao perfil de decodificação HD 1080p (a 60 QPS).
  • [5.3.4/T-1-2] É PRECISO decodificar vídeos com os dois perfis HD indicados na tabela a seguir e codificados com o perfil de referência, o perfil principal ou o perfil de alta qualidade de nível 4.2

Se as implementações de dispositivos de TV forem compatíveis com o codec H.265 e o perfil de decodificação HD 1080p, elas:

  • [5.3.5/T-1-1] É necessário oferecer suporte ao nível principal do perfil principal de nível 4.1.
  • [5.3.5/T-SR] É ALTAMENTE RECOMENDÁVEL oferecer suporte à taxa de quadros de vídeo de 60 QPS para HD 1080p.

Se as implementações de dispositivos de TV forem compatíveis com o codec H.265 e o perfil de decodificação UHD, então:

  • [5.3.5/T-2-1] O codec PRECISA oferecer suporte ao perfil de nível principal 5 do Main10.

Se as implementações de dispositivos de TV forem compatíveis com o codec VP8, elas:

  • [5.3.6/T-1-1] É PRECISO ter suporte ao perfil de decodificação HD 1080p60.

Se as implementações de dispositivos de TV forem compatíveis com o codec VP8 e 720p, elas:

  • [5.3.6/T-2-1] É PRECISO oferecer suporte ao perfil de decodificação HD 720p60.

Se as implementações de dispositivos de TV forem compatíveis com o codec VP9 e a decodificação de vídeo UHD, elas:

  • [5.3.7/T-1-1] DEVE ter suporte a uma profundidade de cor de 8 bits e DEVE ter suporte ao perfil 2 do VP9 (10 bits).

Se as implementações de dispositivos de TV oferecerem suporte ao codec VP9, ao perfil 1080p e à decodificação de hardware VP9, elas:

  • [5.3.7/T-2-1] É PRECISO ter suporte a 60 fps para 1080p.

Implementações de dispositivos de TV:

  • [5.8/T-SR] É ALTAMENTE RECOMENDADO oferecer suporte à decodificação simultânea de streams seguros. A decodificação simultânea de dois fluxos é ALTAMENTE RECOMENDADA.

Se as implementações de dispositivos forem dispositivos Android TV e oferecerem suporte à resolução 4K, elas:

  • [5.8/T-1-1] É NECESSÁRIO ter suporte a HDCP 2.2 para todas as telas externas com fio.

Se as implementações de dispositivos de TV não oferecerem suporte à resolução 4K, elas:

  • [5.8/T-2-1] É OBRIGATÓRIO ter suporte a HDCP 1.4 para todas as telas externas com fio.

Implementações de dispositivos de TV:

  • [5.5.3/T-0-1] É PRECISO incluir suporte para o Volume principal do sistema e a atenuação do volume de saída de áudio digital nas saídas compatíveis, exceto para a saída de passagem de áudio compactado (em que nenhuma decodificação de áudio é feita no dispositivo).

2.3.3. Software

Implementações de dispositivos de TV:

  • [3/T-0-1] É OBRIGATÓRIO declarar os recursos android.software.leanback e android.hardware.type.television.
  • [3.4.1/T-0-1] É OBRIGATÓRIO fornecer uma implementação completa da API android.webkit.Webview.

Se as implementações de dispositivos Android TV oferecerem suporte a uma tela de bloqueio,elas:

  • [3.8.10/T-1-1] É OBRIGATÓRIO mostrar as notificações da tela de bloqueio, incluindo o modelo de notificação de mídia.

Implementações de dispositivos de TV:

  • [3.8.14/T-SR] É ALTAMENTE RECOMENDADO oferecer suporte ao modo picture-in-picture (PIP) com várias janelas.
  • [3.10/T-0-1] É PRECISO oferecer suporte a serviços de acessibilidade de terceiros.
  • [3.10/T-SR] É ALTAMENTE RECOMENDADO pré-carregar serviços de acessibilidade no dispositivo que sejam comparáveis ou superem a funcionalidade do Switch Access e do TalkBack (para idiomas compatíveis com o mecanismo de conversão de texto em voz pré-carregado), conforme fornecido no projeto de código aberto do TalkBack.

Se as implementações de dispositivos de TV informarem o recurso android.hardware.audio.output, elas:

  • [3.11/T-SR] É ALTAMENTE RECOMENDADO incluir um mecanismo de TTS que ofereça suporte aos idiomas disponíveis no dispositivo.
  • [3.11/T-1-1] É PRECISO oferecer suporte à instalação de mecanismos de TTS de terceiros.

Implementações de dispositivos de TV:

  • [3.12/T-0-1] É NECESSÁRIO oferecer suporte ao TV Input Framework.

2.2.4. Desempenho e energia

  • [8.1/T-0-1] Latência consistente de frames. A latência inconsistente ou um atraso na renderização de frames NÃO PODE acontecer mais de 5 vezes por segundo e DEVE ser inferior a 1 frame por segundo.
  • [8.2/T-0-1] É PRECISO garantir um desempenho de gravação sequencial de pelo menos 5 MB/s.
  • [8.2/T-0-2] É PRECISO garantir um desempenho de gravação aleatória de pelo menos 0,5 MB/s.
  • [8.2/T-0-3] É PRECISO garantir um desempenho de leitura sequencial de pelo menos 15 MB/s.

  • [8.2/T-0-4] É PRECISO garantir um desempenho de leitura aleatória de pelo menos 3,5 MB/s.

  • [8.3/T-0-1] Todos os apps isentos dos modos de economia de energia "App Standby" e "Soneca" precisam ser mostrados ao usuário final.

  • [8.3/T-0-2] O acionamento, a manutenção, os algoritmos de ativação e o uso das configurações globais do sistema dos modos de espera do app e de suspensão NÃO PODEM se desviar do Projeto de código aberto do Android.

Implementações de dispositivos de TV:

  • [8.4/T-0-1] É necessário fornecer um perfil de energia por componente que defina o valor de consumo atual para cada componente de hardware e o consumo aproximado de bateria causado pelos componentes ao longo do tempo, conforme documentado no site do Projeto Android Open Source.
  • [8.4/T-0-2] É OBRIGATÓRIO informar todos os valores de consumo de energia em miliamperes-hora (mAh).
  • [8.4/T-0-3] É PRECISO informar o consumo de energia da CPU por UID de cada processo. O Android Open Source Project atende ao requisito com a implementação do módulo do kernel uid_cputime.
  • [8.4/T] DEVE ser atribuído ao próprio componente de hardware se não for possível atribuir o uso de energia do componente de hardware a um aplicativo.
  • [8.4/T-0-4] É OBRIGATÓRIO disponibilizar esse uso de energia ao desenvolvedor do app pelo comando de shell adb shell dumpsys batterystats.

2.4. Requisitos do relógio

Um dispositivo Android Watch se refere a uma implementação de dispositivo Android destinada a ser usada no corpo, talvez no pulso.

As implementações de dispositivos Android são classificadas como um relógio se atenderem a todos os seguintes critérios:

  • Ter uma tela com o comprimento físico da diagonal no intervalo de 1,1 a 2,5 polegadas.
  • Ter um mecanismo para ser usado no corpo.

Os requisitos adicionais no restante desta seção são específicos para implementações de dispositivos Android Watch.

2.4.1. Hardware

Assista as implementações de dispositivos:

  • [7.1.1.1/W-0-1] É PRECISO ter uma tela com o tamanho físico diagonal na faixa de 1,1 a 2,5 polegadas.

  • [7.2.3/W-0-1] A função "Início" e a função "Voltar" precisam estar disponíveis para o usuário, exceto quando estiverem em UI_MODE_TYPE_WATCH.

  • [7.2.4/W-0-1] É PRECISO oferecer suporte à entrada por touchscreen.

  • [7.3.1/W-SR] É ALTAMENTE RECOMENDADO incluir um acelerômetro de três eixos.

  • [7.4.3/W-0-1] É PRECISO ter suporte a Bluetooth.

  • [7.6.1/W-0-1] É PRECISO ter pelo menos 1 GB de armazenamento não volátil disponível para dados privados do aplicativo (também conhecido como partição "/data")

  • [7.6.1/W-0-2] É PRECISO ter pelo menos 416 MB de memória disponível para o kernel e o espaço do usuário.

  • [7.8.1/W-0-1] É OBRIGATÓRIO incluir um microfone.

  • [7.8.2/W] PODE, mas NÃO DEVE ter saída de áudio.

2.4.2. Multimídia

Nenhum requisito extra.

2.4.3. Software

Assista as implementações de dispositivos:

  • [3/W-0-1] É PRECISO declarar o recurso android.hardware.type.watch.
  • [3/W-0-2] É NECESSÁRIO oferecer suporte a uiMode = UI_MODE_TYPE_WATCH.

Assista as implementações de dispositivos:

Observe as implementações de dispositivos que declaram a flag de recurso android.hardware.audio.output:

  • [3.10/W-1-1] É PRECISO oferecer suporte a serviços de acessibilidade de terceiros.
  • [3.10/W-SR] É ALTAMENTE RECOMENDADO pré-carregar serviços de acessibilidade no dispositivo que sejam comparáveis ou superem a funcionalidade do Switch Access e do TalkBack (para idiomas compatíveis com o mecanismo de conversão de texto em voz pré-carregado), conforme fornecido no projeto de código aberto do TalkBack.

Se as implementações do dispositivo de relógio informarem o recurso android.hardware.audio.output, elas:

  • [3.11/W-SR] É ALTAMENTE RECOMENDADO incluir um mecanismo de TTS compatível com os idiomas disponíveis no dispositivo.

  • [3.11/W-0-1] É PRECISO oferecer suporte à instalação de mecanismos de TTS de terceiros.

2.5. Requisitos automotivos

A implementação do Android Automotive se refere a uma unidade principal de veículo que executa o Android como um sistema operacional para parte ou toda a funcionalidade do sistema e/ou infoentretenimento.

As implementações de dispositivos Android são classificadas como Automotive se declararem o recurso android.hardware.type.automotive ou atenderem a todos os critérios a seguir.

  • São incorporados ou podem ser conectados a um veículo automotivo.
  • Estão usando uma tela na fileira do banco do motorista como tela principal.

Os requisitos adicionais no restante desta seção são específicos para implementações de dispositivos Android Automotive.

2.5.1. Hardware

Implementações de dispositivos automotivos:

  • [7.1.1.1/A-0-1] É PRECISO ter uma tela com pelo menos 6 polegadas de tamanho físico na diagonal.

  • [7.1.1.1/A-0-2] É OBRIGATÓRIO ter um layout de tamanho de tela de pelo menos 750 dp x 480 dp.

  • [7.2.3/A-0-1] É OBRIGATÓRIO fornecer a função "Início" e PODE fornecer as funções "Voltar" e "Recentes".

  • [7.2.3/A-0-2] É PRECISO enviar o evento de pressionar normal e longo da função "Voltar" (KEYCODE_BACK) para o aplicativo em primeiro plano.

  • [7.3.1/A-SR] É ALTAMENTE RECOMENDADO incluir um acelerômetro de três eixos.

Se as implementações de dispositivos automotivos incluírem um acelerômetro de três eixos, elas:

Se as implementações de dispositivos automotivos incluírem um receptor GPS/GNSS e informarem a capability para apps pela flag de recurso android.hardware.location.gps:

  • [7.3.3/A-1-1] A geração da tecnologia GNSS PRECISA ser o ano "2017" ou mais recente.

Se as implementações de dispositivos automotivos incluírem um giroscópio, elas:

  • [7.3.4/A-1-1] PRECISA ser capaz de informar eventos com frequência de pelo menos 100 Hz.

Implementações de dispositivos automotivos:

  • [7.3.11/A] DEVE fornecer a engrenagem atual como SENSOR_TYPE_GEAR.

Implementações de dispositivos automotivos:

  • [7.3.11.2/A-0-1] É PRECISO oferecer suporte ao modo dia/noite definido como SENSOR_TYPE_NIGHT.
  • [7.3.11.2/A-0-2] O valor da flag SENSOR_TYPE_NIGHT PRECISA ser consistente com o modo dia/noite do painel e DEVE ser baseado na entrada do sensor de luz ambiente.

  • O sensor de luz ambiente pode ser o mesmo que o fotômetro.

  • [7.3.11.3/A-0-1] É PRECISO oferecer suporte ao status de direção definido como SENSOR_TYPE_DRIVING_STATUS, com um valor padrão de DRIVE_STATUS_UNRESTRICTED quando o veículo estiver totalmente parado e estacionado. É responsabilidade dos fabricantes de dispositivos configurar o SENSOR_TYPE_DRIVING_STATUS em conformidade com todas as leis e regulamentações aplicáveis aos mercados em que o produto é enviado.

  • [7.3.11.4/A-0-1] É PRECISO fornecer a velocidade do veículo definida como SENSOR_TYPE_CAR_SPEED.

  • [7.4.3/A-0-1] É PRECISO oferecer suporte a Bluetooth e RECOMENDÁVEL oferecer suporte a Bluetooth LE.

  • [7.4.3/A-0-2] As implementações do Android Automotive precisam oferecer suporte aos seguintes perfis Bluetooth:
    • Ligações telefônicas pelo perfil viva-voz (HFP).
    • Reprodução de mídia pelo perfil de distribuição de áudio (A2DP).
    • Controle de reprodução de mídia pelo perfil de controle remoto (AVRCP).
    • Compartilhamento de contatos usando o perfil de acesso à agenda telefônica (PBAP).

  • [7.4.3/A] DEVE oferecer suporte ao perfil de acesso a mensagens (MAP).

  • [7.4.5/A] DEVE incluir suporte para conectividade de dados baseada em rede celular.

  • [7.6.1/A-0-1] É PRECISO ter pelo menos 4 GB de armazenamento não volátil disponível para dados privados do aplicativo (também conhecidos como partição "/data").

Se as implementações de dispositivos automotivos forem de 32 bits:

  • [7.6.1/A-1-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 512 MB se qualquer uma das seguintes densidades for usada:

    • 280 dpi ou menos em telas pequenas/normais
    • ldpi ou menor em telas extragrandes
    • mdpi ou menor em telas grandes

  • [7.6.1/A-1-2] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 608 MB se qualquer uma das densidades a seguir for usada:

    • xhdpi ou superior em telas pequenas/normais
    • hdpi ou mais em telas grandes
    • mdpi ou superior em telas extragrandes

  • [7.6.1/A-1-3] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 896 MB se qualquer uma das densidades a seguir for usada:

    • 400 dpi ou mais em telas pequenas/normais
    • xhdpi ou superior em telas grandes
    • tvdpi ou superior em telas extragrandes

  • [7.6.1/A-1-4] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 1344 MB se qualquer uma das densidades a seguir for usada:

    • 560 dpi ou mais em telas pequenas/normais
    • 400 dpi ou mais em telas grandes
    • xhdpi ou superior em telas extragrandes

Se as implementações de dispositivos automotivos forem de 64 bits:

  • [7.6.1/A-2-1] A memória disponível para o kernel e o espaço do usuário PRECISA ter pelo menos 816 MB se qualquer uma das seguintes densidades for usada:

    • 280 dpi ou menos em telas pequenas/normais
    • ldpi ou menor em telas extragrandes
    • mdpi ou menor em telas grandes

  • [7.6.1/A-2-2] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 944 MB se qualquer uma das densidades a seguir for usada:

    • xhdpi ou superior em telas pequenas/normais
    • hdpi ou mais em telas grandes
    • mdpi ou superior em telas extragrandes

  • [7.6.1/A-2-3] A memória disponível para o kernel e o espaço do usuário PRECISA ter pelo menos 1280 MB se qualquer uma das seguintes densidades for usada:

    • 400 dpi ou mais em telas pequenas/normais
    • xhdpi ou superior em telas grandes
    • tvdpi ou superior em telas extragrandes

  • [7.6.1/A-2-4] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 1824 MB se qualquer uma das densidades a seguir for usada:

    • 560 dpi ou mais em telas pequenas/normais
    • 400 dpi ou mais em telas grandes
    • xhdpi ou superior em telas extragrandes

A "memória disponível para o kernel e o espaço do usuário" acima se refere ao espaço de memória fornecido, além de qualquer memória já dedicada a componentes de hardware, como rádio, vídeo e assim por diante, que não estão sob o controle do kernel nas implementações do dispositivo.

Implementações de dispositivos automotivos:

  • [7.7.1/A] DEVE incluir uma porta USB com suporte ao modo periférico.

Implementações de dispositivos automotivos:

  • [7.8.1/A-0-1] É OBRIGATÓRIO incluir um microfone.

Implementações de dispositivos automotivos:

  • [7.8.2/A-0-1] É PRECISO ter uma saída de áudio e declarar android.hardware.audio.output.

2.5.2. Multimídia

As implementações de dispositivos automotivos precisam ter suporte à seguinte codificação de áudio:

  • [5.1/A-0-1] Perfil MPEG-4 AAC (AAC LC)
  • [5.1/A-0-2] Perfil MPEG-4 HE AAC (AAC+).
  • [5.1/A-0-3] AAC ELD (AAC aprimorado com atraso baixo)

As implementações de dispositivos automotivos precisam ter suporte à seguinte codificação de vídeo:

  • [5.2/A-0-1] H.264 AVC
  • [5.2/A-0-2] VP8

As implementações de dispositivos automotivos precisam oferecer suporte à seguinte decodificação de vídeo:

  • [5.3/A-0-1] H.264 AVC
  • [5.3/A-0-2] MPEG-4 SP
  • [5.3/A-0-3] VP8
  • [5.3/A-0-4] VP9

É ALTAMENTE RECOMENDÁVEL que as implementações de dispositivos automotivos ofereçam suporte à seguinte decodificação de vídeo:

  • [5.3/A-SR] H.265 HEVC

2.5.3. Software

Implementações de dispositivos automotivos:

  • [3/A-0-1] É OBRIGATÓRIO declarar o recurso android.hardware.type.automotive.
  • [3/A-0-2] É NECESSÁRIO oferecer suporte a uiMode = UI_MODE_TYPE_CAR.

  • [3/A-0-3] As implementações do Android Automotive precisam oferecer suporte a todas as APIs públicas no namespace android.car.*.

  • [3.4.1/A-0-1] É PRECISO fornecer uma implementação completa da API android.webkit.Webview.

  • [3.8.3/A-0-1] É NECESSÁRIO mostrar notificações que usam a API Notification.CarExtender quando solicitadas por aplicativos de terceiros.

  • [3.8.4/A-0-1] É PRECISO implementar um assistente no dispositivo para processar a ação de assistência.

  • [3.14/A-0-1] É OBRIGATÓRIO incluir uma estrutura de interface para oferecer suporte a apps de terceiros que usam as APIs de mídia, conforme descrito na seção 3.14.

2.2.4. Desempenho e energia

Implementações de dispositivos automotivos:

  • [8.3/A-0-1] Todos os apps isentos dos modos de economia de energia "App em espera" e "Soneca" precisam ser mostrados ao usuário final.

  • [8.3/A-0-2] Os algoritmos de acionamento, manutenção e ativação e o uso de configurações globais do sistema dos modos de economia de energia do modo de espera do app e do Doze NÃO PODEM se desviar do Projeto Android Open Source.

  • [8.4/A-0-1] É necessário fornecer um perfil de energia por componente que defina o valor de consumo atual para cada componente de hardware e o consumo aproximado de bateria causado pelos componentes ao longo do tempo, conforme documentado no site do Projeto Android Open Source.

  • [8.4/A-0-2] É OBRIGATÓRIO informar todos os valores de consumo de energia em miliamperes-hora (mAh).
  • [8.4/A-0-3] É OBRIGATÓRIO informar o consumo de energia da CPU por UID de cada processo. O Android Open Source Project atende ao requisito com a implementação do módulo do kernel uid_cputime.
  • [8.4/A] DEVE ser atribuído ao próprio componente de hardware se não for possível atribuir o uso de energia do componente de hardware a um aplicativo.
  • [8.4/A-0-4] É OBRIGATÓRIO disponibilizar esse uso de energia ao desenvolvedor do app pelo comando de shell adb shell dumpsys batterystats.

2.2.5. Modelo de segurança

Se as implementações de dispositivos automotivos incluírem vários usuários, elas:

  • [9.5/A-1-1] É OBRIGATÓRIO incluir uma conta de visitante que permita todas as funções fornecidas pelo sistema do veículo sem exigir que um usuário faça login.

Implementações de dispositivos automotivos:

  • [9.14/A-0-1] É NECESSÁRIO controlar as mensagens de subsistemas de veículos do framework do Android, por exemplo, permitir tipos e origens de mensagens.
  • [9.14/A-0-2] É NECESSÁRIO monitorar ataques de negação de serviço do framework do Android ou de apps de terceiros. Isso protege contra softwares maliciosos que inundam a rede do veículo com tráfego, o que pode levar a um mau funcionamento dos subsistemas do veículo.

2.6. Requisitos para tablets

Um dispositivo Android Tablet se refere a uma implementação de dispositivo Android que normalmente é usado com as duas mãos e não em um formato de concha.

As implementações de dispositivos Android são classificadas como tablet se atenderem a todos os seguintes critérios:

  • Ter uma fonte de energia que ofereça mobilidade, como uma bateria.
  • Ter um tamanho físico diagonal da tela entre 7 e 18 polegadas.

As implementações de dispositivos tablet têm requisitos semelhantes às implementações de dispositivos portáteis. As exceções são indicadas por * nessa seção e mencionadas para referência nesta seção.

2.4.1. Hardware

Tamanho da tela

  • [7.1.1.1/Tab-0-1] PRECISA ter uma tela de 7 a 18 polegadas.

Memória e armazenamento mínimos (seção 7.6.1)

As densidades de tela listadas para telas pequenas/normais nos requisitos de dispositivos portáteis não são aplicáveis a tablets.

Modo de periférico USB (seção 7.7.1)

Se as implementações de dispositivos tablet incluírem uma porta USB com suporte ao modo periférico, elas:

  • [7.7.1/Tab]Pode implementar a API Android Open Accessory (AOA).

Modo de realidade virtual (seção 7.9.1)

Realidade virtual de alto desempenho (seção 7.9.2)

Os requisitos de realidade virtual não se aplicam a tablets.

3. Software

3.1. Compatibilidade com a API gerenciada

O ambiente de execução de bytecode Dalvik gerenciado é o veículo principal para aplicativos Android. A interface de programação do aplicativo (API) do Android é o conjunto de interfaces da plataforma Android expostas a aplicativos executados no ambiente de execução gerenciado.

  • [C-0-1] As implementações de dispositivos precisam fornecer implementações completas, incluindo todos os comportamentos documentados, de qualquer API documentada exposta pelo SDK do Android ou qualquer API decorada com o marcador "@SystemApi" no código-fonte do Android upstream.

  • [C-0-2] As implementações de dispositivos PRECISAM oferecer suporte/preservar todas as classes, métodos e elementos associados marcados pela anotação TestApi (@TestApi).

  • [C-0-3] As implementações de dispositivos NÃO PODEM omitir APIs gerenciadas, alterar interfaces ou assinaturas de API, desviar do comportamento documentado ou incluir no-ops, exceto quando especificamente permitido por esta definição de compatibilidade.

  • [C-0-4] As implementações de dispositivos PRECISAM manter as APIs presentes e se comportar de maneira razoável, mesmo quando alguns recursos de hardware para os quais o Android inclui APIs são omitidos. Consulte a seção 7 para ver os requisitos específicos deste cenário.

3.1.1. Extensões Android

O Android inclui suporte para estender as APIs gerenciadas mantendo a mesma versão do nível da API.

  • [C-0-1] As implementações de dispositivos Android PRECISAM carregar previamente a implementação do AOSP da biblioteca compartilhada ExtShared e dos serviços ExtServices com versões maiores ou iguais às versões mínimas permitidas para cada nível da API. Por exemplo, as implementações de dispositivos do Android 7.0 que executam o nível 24 da API precisam incluir pelo menos a versão 1.

3.2. Compatibilidade de API flexível

Além das APIs gerenciadas da seção 3.1, o Android também inclui uma API "soft" significativa somente para execução, na forma de intents, permissões e aspectos semelhantes de apps Android que não podem ser aplicados no momento da compilação.

3.2.1. Permissões

  • [C-0-1] Os implementadores de dispositivos precisam oferecer suporte e aplicar todas as constantes de permissão, conforme documentado na página de referência de permissões. A seção 9 lista outros requisitos relacionados ao modelo de segurança do Android.

3.2.2. Parâmetros do build

As APIs do Android incluem várias constantes na classe android.os.Build que têm como objetivo descrever o dispositivo atual.

  • [C-0-1] Para fornecer valores consistentes e significativos em todas as implementações de dispositivos, a tabela abaixo inclui outras restrições sobre os formatos desses valores aos quais as implementações de dispositivos PRECISAM se conformar.
Parâmetro Detalhes
VERSION.RELEASE A versão do sistema Android em execução no momento, em formato legível por humanos. Esse campo PRECISA ter um dos valores de string definidos em 8.0.
VERSION.SDK A versão do sistema Android em execução no momento, em um formato acessível ao código de aplicativos de terceiros. Para o Android 8.0, esse campo PRECISA ter o valor inteiro 8.0_INT.
VERSION.SDK_INT A versão do sistema Android em execução no momento, em um formato acessível ao código de aplicativos de terceiros. Para o Android 8.0, esse campo PRECISA ter o valor inteiro 8.0_INT.
VERSION.INCREMENTAL Um valor escolhido pelo implementador do dispositivo que designa o build específico do sistema Android em execução no momento, em um formato legível por humanos. Esse valor NÃO PODE ser reutilizado para builds diferentes disponibilizados aos usuários finais. Um uso típico desse campo é indicar qual número de build ou identificador de mudança de controle de origem foi usado para gerar o build. Não há requisitos sobre o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").
TABULEIRO Um valor escolhido pelo implementador do dispositivo que identifica o hardware interno específico usado pelo dispositivo em um formato legível por humanos. Um possível uso desse campo é indicar a revisão específica da placa que alimenta o dispositivo. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9_-]+$".
MARCA Um valor que reflete o nome da marca associado ao dispositivo, conhecido pelos usuários finais. PRECISA estar em um formato legível por humanos e REPRESENTAR o fabricante do dispositivo ou a marca da empresa sob a qual o dispositivo é comercializado. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9_-]+$".
SUPPORTED_ABIS O nome do conjunto de instruções (tipo de CPU + convenção ABI) do código nativo. Consulte a seção 3.3. Compatibilidade com a API nativa.
SUPPORTED_32_BIT_ABIS O nome do conjunto de instruções (tipo de CPU + convenção ABI) do código nativo. Consulte a seção 3.3. Compatibilidade com a API nativa.
SUPPORTED_64_BIT_ABIS O nome do segundo conjunto de instruções (tipo de CPU + convenção ABI) do código nativo. Consulte a seção 3.3. Compatibilidade com a API nativa.
CPU_ABI O nome do conjunto de instruções (tipo de CPU + convenção ABI) do código nativo. Consulte a seção 3.3. Compatibilidade com a API nativa.
CPU_ABI2 O nome do segundo conjunto de instruções (tipo de CPU + convenção ABI) do código nativo. Consulte a seção 3.3. Compatibilidade com a API nativa.
DISPOSITIVO Um valor escolhido pelo implementador do dispositivo que contém o nome de desenvolvimento ou de código que identifica a configuração dos recursos de hardware e o design industrial do dispositivo. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9_-]+$". O nome do dispositivo NÃO PODE mudar durante a vida útil do produto.
FINGERPRINT Uma string que identifica exclusivamente esse build. Ele DEVE ser razoavelmente legível por humanos. Ele PRECISA seguir este modelo:

$(BRAND)/$(PRODUCT)/
    $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

Exemplo:

acme/myproduct/
    mydevice:8.0/LMYXX/3359:userdebug/test-keys

A impressão digital NÃO pode incluir caracteres de espaço em branco. Se outros campos incluídos no modelo acima tiverem caracteres de espaço em branco, eles PRECISAM ser substituídos no fingerprint do build por outro caractere, como o sublinhado ("_"). O valor desse campo PRECISA ser codificável como ASCII de 7 bits.

HARDWARE O nome do hardware (da linha de comando do kernel ou /proc). Ele DEVE ser razoavelmente legível por humanos. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9_-]+$".
HOST Uma string que identifica de maneira exclusiva o host em que o build foi criado, em um formato legível por humanos. Não há requisitos sobre o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").
ID Um identificador escolhido pelo implementador do dispositivo para se referir a uma versão específica em um formato legível por humanos. Esse campo pode ser o mesmo que android.os.Build.VERSION.INCREMENTAL, mas DEVE ser um valor suficientemente significativo para que os usuários finais distingam entre builds de software. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9._-]+$".
FABRICANTE O nome comercial do fabricante de equipamento original (OEM) do produto. Não há requisitos sobre o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou uma string vazia (""). Esse campo NÃO PODE mudar durante a vida útil do produto.
MODEL Um valor escolhido pelo implementador do dispositivo que contém o nome do dispositivo conhecido pelo usuário final. Ele DEVE ser o mesmo nome usado para comercializar e vender o dispositivo para os usuários finais. Não há requisitos sobre o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou uma string vazia (""). Esse campo NÃO PODE mudar durante a vida útil do produto.
PRODUTO Um valor escolhido pelo implementador do dispositivo que contém o nome de desenvolvimento ou o nome de código do produto específico (SKU) que DEVE ser exclusivo na mesma marca. PRECISA ser legível por humanos, mas não necessariamente para visualização por usuários finais. O valor desse campo PRECISA ser codificado como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9_-]+$". O nome do produto NÃO PODE mudar durante a vida útil do produto.
SERIAL Um número de série de hardware, que PRECISA estar disponível e ser exclusivo em todos os dispositivos com o mesmo MODELO e FABRICANTE. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular “^([a-zA-Z0-9]{6,20})$”.
TAGS Uma lista de tags separadas por vírgulas escolhidas pelo implementador do dispositivo que distinguem ainda mais o build. Esse campo PRECISA ter um dos valores correspondentes às três configurações típicas de assinatura da plataforma Android: chaves de lançamento, chaves de desenvolvimento e chaves de teste.
HORÁRIO Um valor que representa o carimbo de data/hora de quando o build ocorreu.
MÁQUINA Um valor escolhido pelo implementador do dispositivo que especifica a configuração do ambiente de execução do build. Esse campo PRECISA ter um dos valores correspondentes às três configurações típicas de ambiente de execução do Android: user, userdebug ou eng.
USUÁRIO Um nome ou ID do usuário (ou usuário automatizado) que gerou o build. Não há requisitos sobre o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").
SECURITY_PATCH Um valor que indica o nível do patch de segurança de um build. Ele PRECISA indicar que o build não está de forma alguma vulnerável a nenhum dos problemas descritos no boletim de segurança público do Android designado. Ele PRECISA estar no formato [AAAA-MM-DD], correspondendo a uma string definida documentada no Boletim de segurança público do Android ou no Aviso de segurança do Android, por exemplo, "2015-11-01".
BASE_OS Um valor que representa o parâmetro FINGERPRINT do build, que é idêntico a esse build, exceto pelos patches fornecidos no boletim de segurança pública do Android. Ele precisa informar o valor correto e, se esse build não existir, informe uma string vazia ("").
BOOTLOADER (link em inglês) Um valor escolhido pelo implementador do dispositivo que identifica a versão específica do carregador de inicialização interno usada no dispositivo em um formato legível por humanos. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9._-]+$".
getRadioVersion() PRECISA ser ou retornar um valor escolhido pelo implementador do dispositivo que identifica a versão específica do rádio/modem interno usada no dispositivo em um formato legível por humanos. Se um dispositivo não tiver nenhum rádio/modem interno, ele PRECISA retornar NULL. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9._-,]+$".

3.2.3. Compatibilidade de intents

3.2.3.1. Intents principais do aplicativo

As intents do Android permitem que os componentes do aplicativo solicitem funcionalidades de outros componentes do Android. O projeto upstream do Android inclui uma lista de aplicativos considerados principais do Android, que implementam vários padrões de intent para realizar ações comuns.

  • [C-0-1] As implementações de dispositivos PRECISAM incluir esses componentes de aplicativo, serviço ou pelo menos um gerenciador para todos os padrões de filtro de intent público definidos pelos seguintes aplicativos Android principais no AOSP:

    • Relógio de mesa
    • Navegador
    • Agenda
    • Contatos
    • Galeria
    • GlobalSearch
    • Tela de início
    • Música
    • Configurações
3.2.3.2. Resolução de intents
  • [C-0-1] Como o Android é uma plataforma extensível, as implementações de dispositivos PRECISAM permitir que cada padrão de intent referenciado na seção 3.2.3.1 seja substituído por aplicativos de terceiros. A implementação de código aberto upstream do Android permite isso por padrão.

  • [C-0-2] Os implementadores de dispositivos NÃO PODEM anexar privilégios especiais ao uso de padrões de intent por aplicativos do sistema nem impedir que aplicativos de terceiros se associem a esses padrões e assumam o controle deles. Essa proibição inclui especificamente, mas não se limita a, desativar a interface do usuário "Chooser", que permite que o usuário selecione entre vários aplicativos que processam o mesmo padrão de intent.

  • [C-0-3] As implementações de dispositivos precisam fornecer uma interface do usuário para que os usuários modifiquem a atividade padrão para intents.

  • No entanto, as implementações de dispositivos PODEM fornecer atividades padrão para padrões de URI específicos (por exemplo, http://play.google.com) quando a atividade padrão fornece um atributo mais específico para o URI de dados. Por exemplo, um padrão de filtro de intent que especifica o URI de dados "http://www.android.com" é mais específico do que o padrão de intent principal do navegador para "http://".

O Android também inclui um mecanismo para apps de terceiros declararem um comportamento de vinculação de apps padrão com autoridade para determinados tipos de intents de URI da Web. Quando essas declarações oficiais são definidas nos padrões de filtro de intent de um app, as implementações do dispositivo:

  • [C-0-4] É OBRIGATÓRIO tentar validar todos os filtros de intent executando as etapas de validação definidas na especificação do Digital Asset Links conforme implementado pelo Gerenciador de pacotes no projeto upstream do Android Open Source.
  • [C-0-5] É OBRIGATÓRIO tentar a validação dos filtros de intent durante a instalação do aplicativo e definir todos os filtros de intent de URI validados com sucesso como gerenciadores de apps padrão para os URIs.
  • PODE definir filtros de intent de URI específicos como gerenciadores de apps padrão para os URIs, se eles forem verificados, mas outros filtros de URI candidatos falharem na verificação. Se uma implementação de dispositivo fizer isso, ela PRECISA fornecer ao usuário as substituições de padrão por URI apropriado no menu de configurações.
  • DEVE fornecer ao usuário controles de Links do app por app nas Configurações da seguinte maneira:
    • [C-0-6] O usuário PRECISA poder substituir de forma holística o comportamento padrão dos links de um app para que ele seja: sempre aberto, sempre perguntado ou nunca aberto, o que precisa se aplicar a todos os filtros de intent de URI candidatos de forma igual.
    • [C-0-7] O usuário PRECISA ter acesso a uma lista dos filtros de intent de URI candidatos.
    • A implementação do dispositivo PODE permitir que o usuário substitua filtros de intent de URI de candidato específicos que foram verificados com sucesso, por filtro de intent.
    • [C-0-8] A implementação do dispositivo PRECISA permitir que os usuários visualizem e substituam filtros de intent de URI de candidato específicos se a implementação do dispositivo permitir que alguns filtros de intent de URI de candidato sejam verificados com sucesso, enquanto outros podem falhar.
3.2.3.3. Namespaces de intent
  • [C-0-1] As implementações de dispositivos NÃO PODEM incluir nenhum componente do Android que respeite novos padrões de intent ou intent de transmissão usando uma string de ACTION, CATEGORY ou outra chave no namespace android. ou com.android..
  • [C-0-2] Os implementadores de dispositivos NÃO PODEM incluir componentes do Android que respeitem novos padrões de intent ou broadcast usando uma string de chave ACTION, CATEGORY ou outra em um espaço de pacote pertencente a outra organização.
  • [C-0-3] Os implementadores de dispositivos NÃO PODEM alterar ou estender nenhum dos padrões de intent usados pelos apps principais listados na seção 3.2.3.1.
  • As implementações de dispositivos PODEM incluir padrões de intent usando namespaces associados de forma clara e óbvia à própria organização. Essa proibição é análoga à especificada para classes de linguagem Java na seção 3.6.
3.2.3.4. Intents de transmissão

Os apps de terceiros dependem da plataforma para transmitir determinadas intents e receber notificações sobre mudanças no ambiente de hardware ou software.

Implementações de dispositivos:

  • [C-0-1] É OBRIGATÓRIO transmitir as intents de transmissão pública em resposta a eventos do sistema apropriados, conforme descrito na documentação do SDK. Esse requisito não conflita com a seção 3.5, porque a limitação para aplicativos em segundo plano também é descrita na documentação do SDK.
3.2.3.5. Configurações padrão do app

O Android inclui configurações que oferecem aos usuários uma maneira fácil de selecionar os aplicativos padrão, por exemplo, para a tela inicial ou SMS.

Quando for apropriado, as implementações de dispositivos precisam fornecer um menu de configurações semelhante e ser compatível com o padrão de filtro de intent e os métodos de API descritos na documentação do SDK, conforme abaixo.

Se as implementações de dispositivos informarem android.software.home_screen, elas:

Se as implementações de dispositivos informarem android.hardware.telephony, elas:

Se as implementações de dispositivos informarem android.hardware.nfc.hce, elas:

Se as implementações de dispositivos informarem android.hardware.telephony, elas:

Se as implementações do dispositivo oferecem suporte ao VoiceInteractionService, elas:

3.2.4. Atividades em telas secundárias

Se as implementações de dispositivos permitirem o lançamento de atividades do Android normais em telas secundárias, elas:

  • [C-1-1] É OBRIGATÓRIO definir a flag de recurso android.software.activities_on_secondary_displays.
  • [C-1-2] É PRECISO garantir a compatibilidade da API semelhante a uma atividade executada na tela principal.
  • [C-1-3] É PRECISO que a nova atividade seja exibida na mesma tela da atividade que a iniciou, quando a nova atividade for iniciada sem especificar uma tela de destino pela API ActivityOptions.setLaunchDisplayId().
  • [C-1-4] É OBRIGATÓRIO destruir todas as atividades quando uma tela com a flag Display.FLAG_PRIVATE for removida.
  • [C-1-5] É PRECISO redimensionar todas as atividades em um VirtualDisplay se a tela for redimensionada.
  • PODE mostrar um IME (editor de método de entrada, um controle do usuário que permite a entrada de texto) na tela principal quando um campo de entrada de texto for focado em uma tela secundária.
  • DEVE implementar o foco de entrada na tela secundária independentemente da tela principal, quando houver suporte para entradas por toque ou tecla.
  • DEVE ter android.content.res.Configuration que corresponde a essa tela para ser exibido, funcionar corretamente e manter a compatibilidade se uma atividade for iniciada na tela secundária.

Se as implementações de dispositivo permitirem a inicialização de atividades do Android normais em telas secundárias e as telas principal e secundária tiverem android.util.DisplayMetrics diferentes:

  • [C-2-1] Atividades que não podem ser redimensionadas (que têm resizeableActivity=false em AndroidManifest.xml) e apps direcionados ao nível 23 da API ou versões anteriores NÃO PODEM ser permitidos em telas secundárias.

Se as implementações de dispositivos permitirem a inicialização de atividades do Android normais em telas secundárias e uma tela secundária tiver a flag android.view.Display.FLAG_PRIVATE:

  • [C-3-1] Somente o proprietário da tela, do sistema e das atividades que já estão nela PODE iniciar atividades nela. Qualquer pessoa pode iniciar em uma tela com a flag android.view.Display.FLAG_PUBLIC.

3.3. Compatibilidade com a API nativa

A compatibilidade com o código nativo é desafiadora. Por esse motivo, os implementadores de dispositivos são:

  • [SR] É ALTAMENTE RECOMENDADO usar as implementações das bibliotecas listadas abaixo do Projeto de código aberto do Android.

3.3.1. Interfaces binárias do aplicativo

O bytecode Dalvik gerenciado pode chamar o código nativo fornecido no arquivo .apk do aplicativo como um arquivo ELF .so compilado para a arquitetura de hardware do dispositivo. Como o código nativo é altamente dependente da tecnologia de processador, o Android define várias interfaces binárias de aplicativo (ABIs) no Android NDK.

Implementações de dispositivos:

  • [C-0-1] PRECISA ser compatível com uma ou mais ABIs definidas e implementar a compatibilidade com o NDK do Android.
  • [C-0-2] É necessário incluir suporte para que o código executado no ambiente gerenciado chame o código nativo usando a semântica padrão da Java Native Interface (JNI).
  • [C-0-3] PRECISA ser compatível com a origem (ou seja, compatível com o cabeçalho) e com o binário (para a ABI) com cada biblioteca necessária na lista abaixo.
  • [C-0-4] É PRECISO oferecer suporte à ABI equivalente de 32 bits se houver suporte para qualquer ABI de 64 bits.
  • [C-0-5] É OBRIGATÓRIO informar com precisão a interface binária de aplicativo (ABI, na sigla em inglês) nativa aceita pelo dispositivo usando os parâmetros android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS e android.os.Build.SUPPORTED_64_BIT_ABIS, cada um deles uma lista de ABIs separada por vírgulas e ordenada da mais para a menos preferida.
  • [C-0-6] É PRECISO informar, pelos parâmetros acima, apenas as ABIs documentadas e descritas na versão mais recente da documentação de gerenciamento de ABI do Android NDK e incluir suporte à extensão Advanced SIMD (também conhecida como NEON).

  • [C-0-7] É OBRIGATÓRIO disponibilizar todas as bibliotecas a seguir, que fornecem APIs nativas, para apps que incluem código nativo:

    • libaaudio.so (suporte de áudio nativo do AAudio)
    • libandroid.so (suporte nativo à atividade do Android)
    • libc (biblioteca C)
    • libcamera2ndk.so
    • libdl (vinculador dinâmico)
    • libEGL.so (gerenciamento de superfície OpenGL nativa)
    • libGLESv1_CM.so (OpenGL ES 1.x)
    • libGLESv2.so (OpenGL ES 2.0)
    • libGLESv3.so (OpenGL ES 3.x)
    • libicui18n.so
    • libicuuc.so
    • libjnigraphics.so
    • liblog (registro do Android)
    • libmediandk.so (suporte a APIs de mídia nativas)
    • libm (biblioteca matemática)
    • libOpenMAXAL.so (suporte ao OpenMAX AL 1.0.1)
    • libOpenSLES.so (suporte a áudio do OpenSL ES 1.0.1)
    • libRS.so
    • libstdc++ (suporte mínimo para C++)
    • libvulkan.so (Vulkan)
    • libz (compactação Zlib)
    • Interface JNI

  • [C-0-8] NÃO é permitido adicionar ou remover as funções públicas das bibliotecas nativas listadas acima.

  • [C-0-9] É OBRIGATÓRIO listar outras bibliotecas que não são do AOSP expostas diretamente a apps de terceiros em /vendor/etc/public.libraries.txt.
  • [C-0-10] NÃO EXPORÃO nenhu ma outra biblioteca nativa, implementada e fornecida no AOSP como bibliotecas do sistema, a apps de terceiros com o nível 24 da API ou mais recente como destino, porque elas são reservadas.
  • [C-0-11] É OBRIGATÓRIO exportar todos os símbolos de função do OpenGL ES 3.1 e do pacote de extensões para Android, conforme definido no NDK, pela biblioteca libGLESv3.so. Embora todos os símbolos precisem estar presentes, a seção 7.1.4.1 descreve com mais detalhes os requisitos para quando a implementação completa de cada função correspondente é esperada.
  • [C-0-12] É PRECISO exportar símbolos de função para os símbolos de função principais do Vulkan 1.0, bem como as extensões VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 e VK_KHR_get_physical_device_properties2 pela biblioteca libvulkan.so. Embora todos os símbolos precisem estar presentes, a seção 7.1.4.2 descreve com mais detalhes os requisitos para quando a implementação completa de cada função correspondente é esperada.
  • DEVEM ser criados usando o código-fonte e os arquivos de cabeçalho disponíveis no projeto de código aberto upstream do Android

Versões futuras do Android NDK podem oferecer suporte a outras ABIs.

3.3.2. Compatibilidade com código nativo ARM de 32 bits

Se as implementações de dispositivo forem dispositivos ARM de 64 bits, então:

  • [C-1-1] Embora a arquitetura ARMv8 descontinue várias operações da CPU, incluindo algumas usadas no código nativo atual, as seguintes operações descontinuadas PRECISAM permanecer disponíveis para o código ARM nativo de 32 bits, seja por suporte nativo à CPU ou por emulação de software:

    • Instruções SWP e SWPB
    • Instrução SETEND
    • Operações de barreira CP15ISB, CP15DSB e CP15DMB

Se as implementações do dispositivo incluírem uma ABI ARM de 32 bits, elas:

  • [C-2-1] É PRECISO incluir as linhas a seguir em /proc/cpuinfo quando ele for lido por aplicativos ARM de 32 bits para garantir a compatibilidade com aplicativos criados usando versões legadas do Android NDK.

    • Features:, seguido por uma lista de recursos opcionais de CPU ARMv7 compatíveis com o dispositivo.
    • CPU architecture:, seguido por um número inteiro que descreve a arquitetura ARM com suporte mais recente do dispositivo (por exemplo, "8" para dispositivos ARMv8).

  • NÃO deve alterar /proc/cpuinfo quando lido por aplicativos ARM ou não ARM de 64 bits.

3.4. Compatibilidade com a Web

3.4.1. Compatibilidade com a WebView

Se as implementações de dispositivo fornecerem uma implementação completa da API android.webkit.Webview, elas:

  • [C-1-1] É OBRIGATÓRIO informar android.software.webview.
  • [C-1-2] É OBRIGATÓRIO usar o build do projeto Chromium do projeto upstream do Android Open Source no branch do Android 8.0 para a implementação da API android.webkit.WebView.

  • [C-1-3] A string do user agent informada pela WebView PRECISA estar neste formato:

    Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

    • O valor da string $(VERSION) PRECISA ser igual ao valor de android.os.Build.VERSION.RELEASE.
    • O valor da string $(MODEL) PRECISA ser igual ao valor de android.os.Build.MODEL.
    • O valor da string $(BUILD) PRECISA ser igual ao valor de android.os.Build.ID.
    • O valor da string $(CHROMIUM_VER) PRECISA ser a versão do Chromium no projeto de código aberto do Android upstream.
    • As implementações de dispositivos PODEM omitir "Mobile" na string do user agent.

  • O componente WebView PRECISA incluir suporte para o maior número possível de recursos HTML5 e, se for compatível com o recurso, PRECISA estar em conformidade com a especificação HTML5.

3.4.2. Compatibilidade de navegadores

Se as implementações de dispositivos incluírem um aplicativo de navegador independente para navegação geral na Web, elas:

  • [C-1-1] É PRECISO oferecer suporte a cada uma das APIs associadas ao HTML5:
  • [C-1-2] PRECISA oferecer suporte à API webstorage HTML5/W3C e DEVE oferecer suporte à API IndexedDB HTML5/W3C. Como os órgãos de padrões de desenvolvimento da Web estão fazendo a transição para favorecer o IndexedDB em vez do Web Storage, espera-se que o IndexedDB se torne um componente obrigatório em uma versão futura do Android.
  • PODE enviar uma string de user agent personalizada no aplicativo de navegador independente.
  • DEVE implementar suporte para o maior número possível de recursos do HTML5 no aplicativo de navegador independente, seja baseado no aplicativo de navegador WebKit upstream ou em uma substituição de terceiros.

No entanto, se as implementações de dispositivos não incluírem um aplicativo de navegador independente, elas:

  • [C-2-1] PRECISA continuar a oferecer suporte aos padrões de intent pública, conforme descrito na seção 3.2.3.1.

3.5. Compatibilidade comportamental da API

O comportamento de cada um dos tipos de API (gerenciada, soft, nativa e da Web) precisa ser consistente com a implementação preferencial do Android Open Source Project upstream. Algumas áreas específicas de compatibilidade são:

  • [C-0-1] Os dispositivos NÃO PODEM mudar o comportamento ou a semântica de uma intent padrão.
  • [C-0-2] Os dispositivos NÃO PODEM alterar o ciclo de vida ou a semântica do ciclo de vida de um tipo específico de componente do sistema (como serviço, atividade, ContentProvider etc.).
  • [C-0-3] Os dispositivos NÃO PODEM mudar a semântica de uma permissão padrão.
  • Os dispositivos NÃO podem alterar as limitações aplicadas aos aplicativos em segundo plano. Mais especificamente, para apps em segundo plano:
    • [C-0-4] Eles PRECISAM parar de executar callbacks registrados pelo app para receber saídas do GnssMeasurement e do GnssNavigationMessage.
    • [C-0-5] Eles PRECISAM limitar a taxa da frequência de atualizações fornecidas ao app pela classe de API LocationManager ou pelo método WifiManager.startScan().
    • [C-0-6] Se o app for destinado ao nível 25 da API ou mais recente, ele NÃO PODE permitir o registro de broadcast receivers para as transmissões implícitas de intents padrão do Android no manifesto do app, a menos que a intent de transmissão exija uma permissão "signature" ou "signatureOrSystem" protectionLevel ou esteja na lista de isenção.
    • [C-0-7] Se o app for destinado ao nível 25 da API ou mais recente, ele PRECISA interromper os serviços em segundo plano do app, como se ele tivesse chamado o método stopSelf() dos serviços, a menos que o app seja colocado em uma lista de permissões temporária para processar uma tarefa visível para o usuário.
    • [C-0-8] Se o app for direcionado ao nível 25 da API ou mais recente, ele PRECISA liberar os wakelocks que o app mantém.

A lista acima não está completa. O Conjunto de teste de compatibilidade (CTS) testa partes significativas da plataforma para compatibilidade comportamental, mas não todas. É responsabilidade do implementador garantir a compatibilidade comportamental com o Android Open Source Project. Por esse motivo, os implementadores de dispositivos PRECISAM usar o código-fonte disponível no Android Open Source Project sempre que possível, em vez de implementar novamente partes significativas do sistema.

3.6. Namespaces de API

O Android segue as convenções de namespace de pacote e classe definidas pela linguagem de programação Java. Para garantir a compatibilidade com aplicativos de terceiros, os implementadores de dispositivos NÃO PODEM fazer modificações proibidas (confira abaixo) nestes namespaces de pacotes:

  • java.*
  • javax.*
  • sun.*
  • android.*
  • com.android.*

Ou seja, eles:

  • [C-0-1] NÃO é permitido modificar as APIs expostas publicamente na plataforma Android alterando assinaturas de método ou classe ou removendo classes ou campos de classe.
  • [C-0-2] NÃO É PERMITIDO adicionar elementos expostos publicamente (como classes ou interfaces, ou campos ou métodos para classes ou interfaces existentes) ou APIs de teste ou do sistema às APIs nos namespaces acima. Um "elemento exposto publicamente" é qualquer construção que não seja decorada com o marcador "@hide", conforme usado no código-fonte do Android upstream.

Os implementadores de dispositivos PODEM modificar a implementação subjacente das APIs, mas essas modificações:

  • [C-0-3] NÃO PODE afetar o comportamento declarado e a assinatura do idioma Java de nenhuma API exposta publicamente.
  • [C-0-4] NÃO PODE ser anunciado ou exposto aos desenvolvedores.

No entanto, os implementadores de dispositivos PODEM adicionar APIs personalizadas fora do namespace padrão do Android, mas as APIs personalizadas:

  • [C-0-5] NÃO PODE estar em um namespace de propriedade ou que se refira a outra organização. Por exemplo, os implementadores de dispositivos NÃO PODEM adicionar APIs ao namespace com.google.* ou semelhante: apenas o Google pode fazer isso. Da mesma forma, o Google NÃO PODE adicionar APIs aos namespaces de outras empresas.
  • [C-0-6] PRECISA ser empacotado em uma biblioteca compartilhada do Android para que apenas os apps que as usam explicitamente (pelo mecanismo <uses-library>) sejam afetados pelo aumento do uso de memória dessas APIs.

Se um implementador de dispositivo propor a melhoria de um dos namespaces de pacote acima (por exemplo, adicionando uma nova funcionalidade útil a uma API existente ou adicionando uma nova API), ele PRECISA acessar source.android.com e iniciar o processo de contribuição de mudanças e código, de acordo com as informações desse site.

As restrições acima correspondem a convenções padrão para nomear APIs na linguagem de programação Java. O objetivo desta seção é apenas reforçar essas convenções e torná-las obrigatórias com a inclusão nesta definição de compatibilidade.

3.7. Compatibilidade com o ambiente de execução

Implementações de dispositivos:

  • [C-0-1] É PRECISO oferecer suporte ao formato completo do Dalvik Executable (DEX) e à especificação e semântica do bytecode do Dalvik.

  • [C-0-2] É OBRIGATÓRIO configurar os ambientes de execução do Dalvik para alocar memória de acordo com a plataforma Android upstream e conforme especificado na tabela a seguir. Consulte a seção 7.1.1 para ver as definições de tamanho e densidade da tela.

  • DEVE usar o Android RunTime (ART), a implementação upstream de referência do formato executável Dalvik e o sistema de gerenciamento de pacotes da implementação de referência.

  • EXECUTAR testes de fuzz em vários modos de execução e arquiteturas de destino para garantir a estabilidade do ambiente de execução. Consulte JFuzz e DexFuzz no site do Android Open Source Project.

Os valores de memória especificados abaixo são considerados valores mínimos, e as implementações de dispositivos podem alocar mais memória por aplicativo.

Layout da tela Densidade da tela Memória mínima do aplicativo
Relógio Android 120 dpi (ldpi) 32MB
160 dpi (mdpi)
213 dpi (tvdpi)
240 dpi (hdpi) 36MB
280 dpi (280dpi)
320 dpi (xhdpi) 48MB
360 dpi (360dpi)
400 dpi (400dpi) 56MB
420 dpi (420dpi) 64MB
480 dpi (xxhdpi) 88MB
560 dpi (560dpi) 112MB
640 dpi (xxxhdpi) 154MB
pequeno/normal 120 dpi (ldpi) 32MB
160 dpi (mdpi)
213 dpi (tvdpi) 48MB
240 dpi (hdpi)
280 dpi (280dpi)
320 dpi (xhdpi) 80MB
360 dpi (360dpi)
400 dpi (400dpi) 96MB
420 dpi (420dpi) 112MB
480 dpi (xxhdpi) 128MB
560 dpi (560dpi) 192MB
640 dpi (xxxhdpi) 256MB
grande 120 dpi (ldpi) 32MB
160 dpi (mdpi) 48MB
213 dpi (tvdpi) 80MB
240 dpi (hdpi)
280 dpi (280dpi) 96MB
320 dpi (xhdpi) 128MB
360 dpi (360dpi) 160MB
400 dpi (400dpi) 192MB
420 dpi (420dpi) 228MB
480 dpi (xxhdpi) 256MB
560 dpi (560dpi) 384MB
640 dpi (xxxhdpi) 512 MB
extra grande 120 dpi (ldpi) 48MB
160 dpi (mdpi) 80MB
213 dpi (tvdpi) 96MB
240 dpi (hdpi)
280 dpi (280dpi) 144MB
320 dpi (xhdpi) 192MB
360 dpi (360dpi) 240MB
400 dpi (400dpi) 288MB
420 dpi (420dpi) 336MB
480 dpi (xxhdpi) 384MB
560 dpi (560dpi) 576MB
640 dpi (xxxhdpi) 768MB

3.8. Compatibilidade da interface do usuário

3.8.1. Tela inicial (acesso rápido)

O Android inclui um aplicativo de acesso rápido (tela inicial) e suporte a apps de terceiros para substituir o acesso rápido do dispositivo (tela inicial).

Se as implementações de dispositivos permitirem que aplicativos de terceiros substituam a tela inicial do dispositivo, elas:

  • [C-1-1] É PRECISO declarar o recurso da plataforma android.software.home_screen.
  • [C-1-2] DEVE retornar o objeto AdaptiveIconDrawable quando o aplicativo de terceiros usar a tag <adaptive-icon> para fornecer o ícone e os métodos PackageManager para recuperar ícones forem chamados.

Se as implementações de dispositivos incluírem uma tela de início padrão compatível com a fixação de atalhos no app, elas:

Por outro lado, se as implementações do dispositivo não oferecerem suporte à fixação no app, elas:

Se as implementações de dispositivos implementarem uma tela de início padrão que ofereça acesso rápido aos atalhos adicionais fornecidos por apps de terceiros pela API ShortcutManager, elas:

  • [C-4-1] PRECISA oferecer suporte a todos os recursos de atalho documentados (por exemplo, atalhos estáticos e dinâmicos, fixação de atalhos) e implementar totalmente as APIs da classe de API ShortcutManager.

Se as implementações do dispositivo incluírem um app de inicialização padrão que mostre selos para os ícones do app, elas:

  • [C-5-1] É PRECISO respeitar o método da API NotificationChannel.setShowBadge(). Em outras palavras, mostre uma affordance visual associada ao ícone do app se o valor for definido como true e não mostre nenhum esquema de badging de ícone do app quando todos os canais de notificação do app tiverem definido o valor como false.
  • PODE substituir os ícones de selo do app pelo esquema de selo proprietário quando os aplicativos de terceiros indicarem suporte ao esquema de selo proprietário pelo uso de APIs proprietárias, mas PRECISA usar os recursos e valores fornecidos pelas APIs de selo de notificação descritos no SDK , como Notification.Builder.setNumber() e Notification.Builder.setBadgeIconType().

3.8.2. Widgets

O Android oferece suporte a widgets de apps de terceiros ao definir um tipo de componente e a API e o ciclo de vida correspondentes, que permitem que os aplicativos exponham um "AppWidget" ao usuário final.

Se as implementações de dispositivos oferecerem suporte a widgets de apps de terceiros, elas:

  • [C-1-1] É PRECISO declarar suporte ao recurso de plataforma android.software.app_widgets.
  • [C-1-2] É PRECISO incluir suporte integrado a AppWidgets e expor recursos da interface do usuário para adicionar, configurar, visualizar e remover AppWidgets diretamente no inicializador.
  • [C-1-3] PRECISA ser capaz de renderizar widgets de 4 x 4 no tamanho padrão da grade. Consulte as Diretrizes de design para widgets de app na documentação do SDK do Android para saber mais.
  • PODE oferecer suporte a widgets de apps na tela de bloqueio.

Se as implementações de dispositivos oferecerem suporte a widgets de apps de terceiros e fixação de atalhos no app, elas:

3.8.3. Notificações

O Android inclui as APIs Notification e NotificationManager, que permitem que desenvolvedores de apps de terceiros notifiquem os usuários sobre eventos importantes e atraiam a atenção deles usando os componentes de hardware (por exemplo, som, vibração e luz) e os recursos de software (por exemplo, painel de notificações, barra de sistema) do dispositivo.

3.8.3.1. Apresentação de notificações

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

  • [C-1-1] É PRECISO oferecer suporte a notificações que usam recursos de hardware, conforme descrito na documentação do SDK, e na medida do possível com o hardware de implementação do dispositivo. Por exemplo, se uma implementação de dispositivo incluir um vibrador, ela PRECISA implementar corretamente as APIs de vibração. Se uma implementação de dispositivo não tiver hardware, as APIs correspondentes PRECISAM ser implementadas como no-ops. Esse comportamento é detalhado na seção 7.
  • [C-1-2] É PRECISO renderizar corretamente todos os recursos (ícones, arquivos de animação etc.) fornecidos nas APIs ou no guia de estilo de ícones da barra de status/sistema, embora eles POSSAM oferecer uma experiência do usuário alternativa para notificações diferente da fornecida pela implementação de referência do Android Open Source.
  • [C-1-3] É NECESSÁRIO honrar e implementar corretamente os comportamentos descritos para que as APIs atualizem, removam e agrupem notificações.
  • [C-1-4] É PRECISO fornecer o comportamento completo da API NotificationChannel documentada no SDK.
  • [C-1-5] É OBRIGATÓRIO fornecer uma capacidade de uso para o usuário bloquear e modificar a notificação de um determinado app de terceiros por cada canal e nível de pacote de app.
  • [C-1-6] É OBRIGATÓRIO fornecer uma capacidade do usuário para mostrar canais de notificação excluídos.
  • DEVE oferecer suporte a notificações avançadas.
  • DEVE apresentar algumas notificações de prioridade mais alta como notificações de alerta.
  • DEVE ter a capacidade do usuário de adiar notificações.
  • PODE gerenciar apenas a visibilidade e o momento em que os apps de terceiros podem notificar os usuários sobre eventos importantes para reduzir problemas de segurança, como distração do motorista.

Se as implementações de dispositivos oferecerem suporte a notificações avançadas, elas:

  • [C-2-1] É OBRIGATÓRIO usar os recursos exatos conforme fornecidos pela classe da API Notification.Style e suas subclasses para os elementos de recurso apresentados.
  • DEVE apresentar todos os elementos de recurso (por exemplo, ícone, título e texto de resumo) definidos na classe da API Notification.Style e nas subclasses dela.

Se as implementações de dispositivos oferecerem suporte a notificações de alerta:

  • [C-3-1] É OBRIGATÓRIO usar a visualização e os recursos de notificação de alerta conforme descrito na classe da API Notification.Builder quando as notificações de alerta forem apresentadas.
3.8.3.2. Serviço de listener de notificações

O Android inclui as APIs NotificationListenerService, que permitem que os apps (uma vez ativados explicitamente pelo usuário) recebam uma cópia de todas as notificações quando elas são postadas ou atualizadas.

Implementações de dispositivos:

  • [C-0-1] É PRECISO atualizar corretamente e imediatamente as notificações em todos os serviços de listener instalados e ativados pelo usuário, incluindo todos os metadados anexados ao objeto de notificação.
  • [C-0-2] DEVE respeitar a chamada de API snoozeNotification(), dispensar a notificação e fazer um callback após a duração de suspensão definida na chamada de API.

Se as implementações de dispositivos tiverem uma característica de uso do usuário para adiar notificações, elas:

  • [C-1-1] DEVE refletir o status da notificação adiada corretamente usando as APIs padrão, como NotificationListenerService.getSnoozedNotifications().
  • [C-1-2] É PRECISO disponibilizar essa capacidade do usuário para adiar notificações de cada app de terceiros instalado, a menos que sejam de serviços persistentes/em primeiro plano.
3.8.3.3. Não perturbe

Se as implementações de dispositivos oferecerem suporte ao recurso Não perturbe, elas:

  • [C-1-1] É PRECISO implementar uma atividade que responda à intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS, que, para implementações com UI_MODE_TYPE_NORMAL, PRECISA ser uma atividade em que o usuário possa conceder ou negar o acesso do app às configurações da política de DND.
  • [C-1-2] É OBRIGATÓRIO, quando a implementação do dispositivo forneceu uma forma de o usuário conceder ou negar o acesso de apps de terceiros à configuração da política de DND, mostrar as regras automáticas de DND criadas por aplicativos, além das regras predefinidas e criadas pelo usuário.
  • [C-1-3] É PRECISO honrar os valores suppressedVisualEffects transmitidos pelo NotificationManager.Policy. Se um app tiver definido qualquer uma das flags SUPPRESSED_EFFECT_SCREEN_OFF ou SUPPRESSED_EFFECT_SCREEN_ON, ele PRECISA indicar ao usuário que os efeitos visuais foram suprimidos no menu de configurações do DND.

O Android inclui APIs que permitem aos desenvolvedores incorporar a pesquisa aos apps e expor os dados deles na pesquisa global do sistema. Em geral, essa funcionalidade consiste em uma única interface do usuário em todo o sistema que permite a entrada de consultas, mostra sugestões à medida que os usuários digitam e exibe os resultados. As APIs do Android permitem que os desenvolvedores reutilizem essa interface para oferecer a pesquisa nos próprios apps e fornecer resultados à interface do usuário da pesquisa global comum.

  • As implementações de dispositivos Android DEVEM incluir a pesquisa global, uma interface de usuário de pesquisa única, compartilhada e em todo o sistema, capaz de sugerir resultados em tempo real em resposta à entrada do usuário.

Se as implementações de dispositivos implementarem a interface de pesquisa global, elas:

  • [C-1-1] É OBRIGATÓRIO implementar as APIs que permitem que aplicativos de terceiros adicionem sugestões à caixa de pesquisa quando ela é executada no modo de pesquisa global.

Se nenhum aplicativo de terceiros que use a pesquisa global estiver instalado:

  • O comportamento padrão DEVE ser mostrar os resultados e as sugestões do mecanismo de pesquisa da Web.

O Android também inclui as APIs Assist para permitir que os aplicativos escolham quantas informações do contexto atual são compartilhadas com o assistente no dispositivo.

Se as implementações do dispositivo oferecerem suporte à ação de assistência, elas:

  • [C-2-1] É PRECISO indicar claramente ao usuário final quando o contexto é compartilhado, por:
    • Sempre que o app de assistência acessar o contexto, uma luz branca vai aparecer ao redor das bordas da tela, com duração e brilho iguais ou superiores aos da implementação do Projeto Android Open Source.
    • Para o app de assistência pré-instalado, ofereça ao usuário uma capacidade de uso a menos de duas navegações de distância da entrada de voz padrão e do menu de configurações do app de assistente e compartilhe o contexto somente quando o app de assistência for invocado explicitamente pelo usuário usando uma palavra de ativação ou uma entrada de tecla de navegação de assistência.
  • [C-2-2] A interação designada para iniciar o app de assistência, conforme descrito na seção 7.2.3, PRECISA iniciar o app de assistência selecionado pelo usuário, ou seja, o app que implementa VoiceInteractionService ou uma atividade que processa a intent ACTION_ASSIST.
  • [C-SR] É ALTAMENTE RECOMENDADO usar o toque e manter pressionado na tecla HOME como essa interação designada.

3.8.5. Alertas e avisos

Os aplicativos podem usar a API Toast para mostrar strings curtas não modais ao usuário final que desaparecem após um breve período e usar a API de tipo de janela TYPE_APPLICATION_OVERLAY para mostrar janelas de alerta como uma sobreposição em outros apps.

Se as implementações de dispositivos incluem uma saída de tela ou vídeo, elas:

  • [C-1-1] É OBRIGATÓRIO fornecer uma característica de uso para impedir que um app exiba janelas de alerta que usam o TYPE_APPLICATION_OVERLAY . A implementação do AOSP atende a esse requisito com controles na sombra de notificação.

  • [C-1-2] É OBRIGATÓRIO honrar a API Toast e exibir notificações do app para os usuários finais de maneira muito visível.

3.8.6. Temas

O Android oferece "temas" como um mecanismo para que os aplicativos apliquem estilos em uma atividade ou aplicativo inteiro.

O Android inclui uma família de temas "Holo" e "Material" como um conjunto de estilos definidos para que os desenvolvedores de apps possam usar se quiserem combinar o tema e a aparência do Holo, conforme definido pelo SDK do Android.

Se as implementações de dispositivos incluem uma saída de tela ou vídeo, elas:

  • [C-1-1] NENHUM dos atributos do tema Holo expostos aos aplicativos PODE ser alterado.
  • [C-1-2] É PRECISO oferecer suporte à família de temas "Material" e NADA pode alterar os atributos do tema Material ou os recursos expostos aos aplicativos.

O Android também inclui uma família de temas "Padrão do dispositivo" como um conjunto de estilos definidos para que os desenvolvedores de apps possam usar se quiserem combinar a aparência e a sensação do tema do dispositivo, conforme definido pelo implementador do dispositivo.

O Android oferece suporte a um tema variante com barras de sistema translúcidas, o que permite que os desenvolvedores de aplicativos preencham a área atrás da barra de status e de navegação com o conteúdo do app. Para oferecer uma experiência consistente aos desenvolvedores nessa configuração, é importante manter o estilo do ícone da barra de status em diferentes implementações de dispositivos.

Se as implementações do dispositivo incluírem uma barra de status do sistema, elas:

  • [C-2-1] É OBRIGATÓRIO usar a cor branca para ícones de status do sistema (como intensidade do sinal e nível da bateria) e notificações emitidas pelo sistema, a menos que o ícone esteja indicando um status problemático ou um app solicite uma barra de status clara usando a flag SYSTEM_UI_FLAG_LIGHT_STATUS_BAR.
  • [C-2-2] As implementações de dispositivos Android PRECISAM mudar a cor dos ícones de status do sistema para preto (para mais detalhes, consulte R.style) quando um app solicitar uma barra de status clara.

3.8.7. Planos fundo interativos

O Android define um tipo de componente e a API e o ciclo de vida correspondentes que permitem que os aplicativos exponham um ou mais planos de fundo interativos ao usuário final. Os planos de fundo animados são animações, padrões ou imagens semelhantes com recursos de entrada limitados que aparecem como um plano de fundo, atrás de outros aplicativos.

O hardware é considerado capaz de executar papéis de parede animados de forma confiável se ele puder executar todos os papéis de parede animados, sem limitações de funcionalidade, a uma taxa de frames razoável sem efeitos adversos em outros aplicativos. Se as limitações do hardware causarem falhas em planos de fundo e/ou aplicativos, mal funcionamento, consumo excessivo de bateria ou CPU ou execução com taxas de frames inaceitáveis, o hardware será considerado incapaz de executar o plano de fundo em tempo real. Por exemplo, alguns planos de fundo animados podem usar um contexto OpenGL 2.0 ou 3.x para renderizar o conteúdo. O papel de parede animado não será executado de forma confiável em hardware que não oferece suporte a vários contextos OpenGL, porque o uso de um contexto OpenGL pode entrar em conflito com outros aplicativos que também usam um contexto OpenGL.

  • As implementações de dispositivos capazes de executar planos de fundo interativos de forma confiável, conforme descrito acima, DEVEM implementar planos de fundo interativos.

Se as implementações de dispositivos implementarem planos de fundo interativos, elas:

  • [C-1-1] É OBRIGATÓRIO informar a flag de recurso da plataforma android.software.live_wallpaper.

3.8.8. Troca de atividades

O código-fonte upstream do Android inclui a tela de visão geral, uma interface do usuário no nível do sistema para alternar tarefas e mostrar atividades e tarefas acessadas recentemente usando uma imagem em miniatura do estado gráfico do aplicativo no momento em que o usuário saiu dele pela última vez.

As implementações de dispositivos que incluem a tecla de navegação de função recente, conforme detalhado na seção 7.2.3, PODEM alterar a interface.

Se as implementações do dispositivo, incluindo a tecla de navegação de função recente, conforme detalhado na seção 7.2.3, alterarem a interface, elas:

  • [C-1-1] É PRECISO oferecer suporte a pelo menos 20 atividades exibidas.
  • DEVE mostrar pelo menos o título de quatro atividades por vez.
  • [C-1-2] É PRECISO implementar o comportamento de fixação de tela e fornecer ao usuário um menu de configurações para ativar o recurso.
  • DEVE mostrar a cor, o ícone e o título da tela em destaques recentes.
  • DEVE mostrar um recurso de fechamento ("x"), mas PODE atrasar isso até que o usuário interaja com as telas.
  • DEVE implementar um atalho para alternar facilmente para a atividade anterior
  • DEVE acionar a ação de troca rápida entre os dois apps usados mais recentemente quando a tecla de função de apps recentes for tocada duas vezes.
  • DEVE acionar o modo de várias janelas de tela dividida, se houver suporte, quando a tecla de funções recentes for pressionada por muito tempo.

  • PODE exibir afiliadas recentes como um grupo que se move junto.

  • [C-SR] É ALTAMENTE RECOMENDADO que as implementações de dispositivos usem a interface do usuário upstream do Android (ou uma interface semelhante baseada em miniaturas) para a tela de visão geral.

3.8.9. Gerenciamento de entrada

O Android inclui suporte para gerenciamento de entrada e editores de método de entrada de terceiros.

Se as implementações de dispositivo permitirem que os usuários usem métodos de entrada de terceiros no dispositivo, eles:

  • [C-1-1] É PRECISO declarar o recurso da plataforma android.software.input_methods e oferecer suporte a APIs IME, conforme definido na documentação do SDK do Android.
  • [C-1-2] É OBRIGATÓRIO fornecer um mecanismo acessível ao usuário para adicionar e configurar métodos de entrada de terceiros em resposta à intent android.settings.INPUT_METHOD_SETTINGS.

Se as implementações do dispositivo declararem a flag de recurso android.software.autofill, elas:

3.8.10. Controle de mídia na tela de bloqueio

A API de cliente de controle remoto foi descontinuada no Android 5.0 em favor do modelo de notificação de mídia, que permite que os aplicativos de mídia sejam integrados aos controles de reprodução exibidos na tela de bloqueio.

3.8.11. Protetores de tela (antes chamados de Sonhos)

O Android inclui suporte a proteções de tela interativas, anteriormente chamadas de "Sonhos". Os protetores de tela permitem que os usuários interajam com aplicativos quando um dispositivo conectado a uma fonte de energia está ocioso ou acoplado em uma base de mesa. Os dispositivos Android Watch PODEM implementar protetores de tela, mas outros tipos de implementações de dispositivos PRECISAM incluir suporte a protetores de tela e oferecer uma opção de configurações para que os usuários configurem protetores de tela em resposta à intent android.settings.DREAM_SETTINGS.

3.8.12. Local

Se as implementações do dispositivo incluírem um sensor de hardware (por exemplo, GPS) capaz de fornecer as coordenadas de localização:

3.8.13. Unicode e fonte

O Android inclui suporte aos caracteres emoji definidos no Unicode 10.0.

Se as implementações de dispositivos incluem uma saída de tela ou vídeo, elas:

  • [C-1-1] É PRECISO renderizar esses caracteres emoji em glifos coloridos.
  • [C-1-2] É PRECISO incluir suporte para:
    • Fonte Roboto 2 com diferentes pesos: sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light para os idiomas disponíveis no dispositivo.
    • Cobertura completa do Unicode 7.0 para latim, grego e cirílico, incluindo os intervalos latino estendido A, B, C e D e todos os glifos no bloco de símbolos de moeda do Unicode 7.0.
  • DEVEM oferecer suporte a emojis de tom de pele e famílias diversas, conforme especificado no Relatório técnico Unicode 51.

Se as implementações do dispositivo incluírem um IME, elas:

  • DEVE fornecer um método de entrada para esses caracteres de emoji ao usuário.

3.8.14. Várias janelas

Se as implementações de dispositivo tiverem a capacidade de mostrar várias atividades ao mesmo tempo, elas:

  • [C-1-1] É OBRIGATÓRIO implementar esses modos de várias janelas de acordo com os comportamentos do aplicativo e as APIs descritas na documentação de suporte ao modo de várias janelas do SDK do Android e atender aos seguintes requisitos:
  • [C-1-2] Os aplicativos podem indicar se são capazes de operar no modo de várias janelas no arquivo AndroidManifest.xml, explicitamente definindo o atributo android:resizeableActivity como true ou implicitamente com a targetSdkVersion > 24. Os apps que definem explicitamente esse atributo como false no manifesto NÃO PODEM ser iniciados no modo de várias janelas. Apps mais antigos com targetSdkVersion < 24 que não definiram esse atributo android:resizeableActivity PODEM ser iniciados no modo de várias janelas, mas o sistema PRECISA avisar que o app pode não funcionar como esperado nesse modo.
  • [C-1-3] NÃO É PERMITIDO oferecer tela dividida ou modo de forma livre se a altura da tela for menor que 440 dp e a largura da tela for menor que 440 dp.
  • As implementações de dispositivos com tamanho de tela xlarge DEVEM oferecer suporte ao modo de formato livre.

Se as implementações de dispositivos oferecem suporte a modos de várias janelas e de tela dividida, elas:

  • [C-2-1] É PRECISO carregar previamente uma tela de início redimensionável como padrão.
  • [C-2-2] A atividade acoplada de uma janela múltipla de tela dividida PRECISA ser cortada, mas DEVE mostrar algum conteúdo dela, se o app de tela inicial for a janela em foco.
  • [C-2-3] É OBRIGATÓRIO honrar os valores declarados de AndroidManifestLayout_minWidth e AndroidManifestLayout_minHeight do aplicativo de inicialização de terceiros e não substituir esses valores ao mostrar algum conteúdo da atividade acoplada.

Se as implementações de dispositivos oferecem suporte a modos de várias janelas e picture-in-picture, elas:

  • [C-3-1] É PRECISO iniciar atividades no modo picture-in-picture em várias janelas quando o app: * É direcionado ao nível 26 da API ou mais recente e declara android:supportsPictureInPicture * É direcionado ao nível 25 da API ou anterior e declara android:resizeableActivity e android:supportsPictureInPicture.
  • [C-3-2] É OBRIGATÓRIO expor as ações no SystemUI conforme especificado pela atividade PIP atual pela API setActions().
  • [C-3-3] PRECISA oferecer suporte a proporções maiores ou iguais a 1:2,39 e menores ou iguais a 2,39:1, conforme especificado pela atividade PIP pela API setAspectRatio().
  • [C-3-4] É OBRIGATÓRIO usar KeyEvent.KEYCODE_WINDOW para controlar a janela PIP. Se o modo PIP não for implementado, a chave PRECISA estar disponível para a atividade em primeiro plano.
  • [C-3-5] É PRECISO fornecer uma affordance do usuário para impedir que um app seja exibido no modo PIP. A implementação do AOSP atende a esse requisito com controles na sombra de notificação.
  • [C-3-6] É PRECISO alocar largura e altura mínimas de 108 dp para a janela PIP e largura mínima de 240 dp e altura de 135 dp para a janela PIP quando o Configuration.uiMode estiver configurado como UI_MODE_TYPE_TELEVISION.

3.9. Administração do dispositivo

O Android inclui recursos que permitem que aplicativos com segurança executem funções de administração de dispositivos no nível do sistema, como a aplicação de políticas de senha ou a exclusão remota, pela API Android Device Administration.

Se as implementações de dispositivo implementarem a gama completa de políticas de administração de dispositivo definidas na documentação do SDK do Android, elas:

  • [C-1-1] É OBRIGATÓRIO declarar android.software.device_admin.
  • [C-1-2] É PRECISO oferecer suporte ao provisionamento de proprietários de dispositivos, conforme descrito na seção 3.9.1 e na seção 3.9.1.1.
  • [C-1-3] É PRECISO declarar o suporte a perfis gerenciados usando a flag de recurso android.software.managed_users, exceto quando o dispositivo está configurado para se reportar como um dispositivo com pouca RAM ou para alocar armazenamento interno (não removível) como armazenamento compartilhado.

3.9.1 Provisionamento de dispositivo

3.9.1.1 Provisionamento de proprietário do dispositivo

Se as implementações do dispositivo declararem android.software.device_admin, elas:

  • [C-1-1] É PRECISO oferecer suporte ao registro de um cliente de política de dispositivo (DPC, na sigla em inglês) como um app de proprietário do dispositivo, conforme descrito abaixo:
  • [C-1-2] NÃO É PERMITIDO definir um aplicativo (incluindo o app pré-instalado) como o do proprietário do dispositivo sem o consentimento ou a ação explícita do usuário ou do administrador do dispositivo.

Se as implementações do dispositivo declararem android.software.device_admin, mas também incluírem uma solução de gerenciamento de proprietário do dispositivo exclusiva e fornecerem um mecanismo para promover um aplicativo configurado na solução como um "equivalente ao proprietário do dispositivo" ao "proprietário do dispositivo" padrão, conforme reconhecido pelas APIs padrão do DevicePolicyManager do Android, elas:

  • [C-2-1] É PRECISO ter um processo em vigor para verificar se o app específico que está sendo promovido pertence a uma solução legítima de gerenciamento de dispositivos corporativos e se ele já foi configurado na solução proprietária para ter os direitos equivalentes de "proprietário do dispositivo".
  • [C-2-2] É OBRIGATÓRIO mostrar a mesma declaração de consentimento do proprietário do dispositivo do AOSP que o fluxo iniciado por android.app.action.PROVISION_MANAGED_DEVICE antes de registrar o aplicativo DPC como "proprietário do dispositivo".
  • PODE ter dados do usuário no dispositivo antes de registrar o aplicativo DPC como "proprietário do dispositivo".
3.9.1.2 Provisionamento de perfil gerenciado

Se as implementações do dispositivo declararem android.software.managed_users, elas:

  • [C-1-1] É PRECISO implementar as APIs que permitem que um aplicativo de controlador de políticas de dispositivo (DPC) se torne o proprietário de um novo perfil gerenciado.

  • [C-1-2] A experiência dos usuários no processo de provisionamento de perfil gerenciado (o fluxo iniciado por android.app.action.PROVISION_MANAGED_PROFILE) PRECISA estar alinhada com a implementação do AOSP.

  • [C-1-3] É OBRIGATÓRIO fornecer as seguintes características do usuário nas Configurações para indicar ao usuário quando uma determinada função do sistema foi desativada pelo Device Policy Controller (DPC):

    • Um ícone consistente ou outra característica de uso (por exemplo, o ícone de informações do AOSP upstream) para representar quando uma configuração específica é restrita por um administrador de dispositivos.
    • Uma breve mensagem explicativa, fornecida pelo administrador do dispositivo pelo setShortSupportMessage.
    • Ícone do aplicativo DPC.

3.9.2 Suporte a perfil gerenciado

Se as implementações do dispositivo declararem android.software.managed_users, elas:

  • [C-1-1] É PRECISO oferecer suporte a perfis gerenciados pelas APIs android.app.admin.DevicePolicyManager.
  • [C-1-2] É PRECISO permitir que apenas um perfil gerenciado seja criado.
  • [C-1-3] É OBRIGATÓRIO usar um selo de ícone (semelhante ao selo de trabalho upstream do AOSP) para representar os aplicativos e widgets gerenciados e outros elementos de interface com selo, como "Recentes" e "Notificações".
  • [C-1-4] É PRECISO mostrar um ícone de notificação (semelhante ao selo de trabalho upstream do AOSP) para indicar quando o usuário está em um aplicativo de perfil gerenciado.
  • [C-1-5] É PRECISO mostrar uma mensagem curta indicando que o usuário está no perfil gerenciado se e quando o dispositivo for ativado (ACTION_USER_PRESENT) e o app em primeiro plano estiver no perfil gerenciado.
  • [C-1-6] Quando um perfil gerenciado existir, é OBRIGATÓRIO mostrar uma affordance visual no "Chooser" de intent para permitir que o usuário encaminhe a intent do perfil gerenciado para o usuário principal ou vice-versa, se ativado pelo Device Policy Controller.
  • [C-1-7] Quando um perfil gerenciado existir, ele PRECISA expor os seguintes recursos do usuário para o usuário principal e o perfil gerenciado:
    • Contabilização separada para bateria, localização, dados móveis e uso de armazenamento do usuário principal e do perfil gerenciado.
    • Gerenciamento independente de aplicativos de VPN instalados no usuário principal ou no perfil gerenciado.
    • Gerenciamento independente de aplicativos instalados no usuário principal ou perfil gerenciado.
    • Gerenciamento independente de contas no perfil do usuário principal ou gerenciado.
  • [C-1-8] É PRECISO garantir que o discador, os contatos e os aplicativos de mensagens pré-instalados possam pesquisar e consultar as informações do autor da chamada do perfil gerenciado (se houver) e do perfil principal, se o Device Policy Controller permitir.
  • [C-1-9] É PRECISO garantir que ele atenda a todos os requisitos de segurança aplicáveis a um dispositivo com vários usuários ativados (consulte a seção 9.5), mesmo que o perfil gerenciado não seja contado como outro usuário além do principal.
  • [C-1-10] É PRECISO oferecer suporte à capacidade de especificar uma tela de bloqueio separada que atenda aos seguintes requisitos para conceder acesso a apps executados em um perfil gerenciado.
    • As implementações de dispositivos precisam respeitar a intent DevicePolicyManager.ACTION_SET_NEW_PASSWORD e mostrar uma interface para configurar uma credencial de tela de bloqueio separada para o perfil gerenciado.
    • As credenciais da tela de bloqueio do perfil gerenciado PRECISAM usar os mesmos mecanismos de armazenamento e gerenciamento de credenciais do perfil pai, conforme documentado no site do projeto Android Open Source.
    • As políticas de senha do DPC precisam ser aplicadas apenas às credenciais da tela de bloqueio do perfil gerenciado, a menos que sejam chamadas pela instância DevicePolicyManager retornada por getParentProfileInstance.
  • Quando os contatos do perfil gerenciado são mostrados no registro de chamadas pré-instalado, na interface de chamada, nas notificações de chamadas em andamento e perdidas, nos contatos e nos apps de mensagens, eles precisam ter o mesmo selo usado para indicar aplicativos de perfil gerenciado.

3.10. Acessibilidade

O Android oferece uma camada de acessibilidade que ajuda usuários com deficiência a navegar pelos dispositivos com mais facilidade. Além disso, o Android oferece APIs da plataforma que permitem que as implementações de serviços de acessibilidade recebam callbacks para eventos do usuário e do sistema e gerem mecanismos de feedback alternativos, como texto para fala, feedback tátil e navegação por trackball/d-pad.

Se as implementações de dispositivos oferecem suporte a serviços de acessibilidade de terceiros, elas:

  • [C-1-1] É PRECISO fornecer uma implementação do framework de acessibilidade do Android, conforme descrito na documentação do SDK das APIs de acessibilidade.
  • [C-1-2] É OBRIGATÓRIO gerar eventos de acessibilidade e entregar o AccessibilityEvent adequado a todas as implementações registradas de AccessibilityService, conforme documentado no SDK.
  • [C-1-3] É PRECISO honrar a intent android.settings.ACCESSIBILITY_SETTINGS para fornecer um mecanismo acessível ao usuário para ativar e desativar os serviços de acessibilidade de terceiros com os serviços de acessibilidade pré-carregados.
  • [C-1-4] É PRECISO adicionar um botão na barra de navegação do sistema que permita ao usuário controlar o serviço de acessibilidade quando os serviços de acessibilidade ativados declararem o AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON . Para implementações de dispositivo sem barra de navegação do sistema, esse requisito não é aplicável, mas as implementações de dispositivo precisam fornecer uma característica do usuário para controlar esses serviços de acessibilidade.

Se as implementações do dispositivo incluírem serviços de acessibilidade pré-carregados, elas:

  • [C-2-1] É OBRIGATÓRIO implementar esses serviços de acessibilidade pré-carregados como apps compatíveis com a inicialização direta quando o armazenamento de dados for criptografado com criptografia baseada em arquivos (FBE).
  • DEVEM fornecer um mecanismo no fluxo de configuração pronto para uso para que os usuários ativem serviços de acessibilidade relevantes, além de opções para ajustar o tamanho da fonte, o tamanho da tela e os gestos de ampliação.

3.11. Conversão de texto em voz

O Android inclui APIs que permitem que os aplicativos usem serviços de conversão de texto em voz (TTS) e que os provedores de serviços ofereçam implementações desses serviços.

Se as implementações do dispositivo informarem o recurso android.hardware.audio.output, elas:

Se as implementações de dispositivos oferecerem suporte à instalação de mecanismos de TTS de terceiros, elas:

  • [C-2-1] É PRECISO fornecer ao usuário uma affordance para permitir que ele selecione um mecanismo de TTS para uso no nível do sistema.

3.12. TV Input Framework

O Android TV Input Framework (TIF) simplifica o envio de conteúdo ao vivo para dispositivos Android TV. O TIF oferece uma API padrão para criar módulos de entrada que controlam dispositivos Android TV.

Se as implementações de dispositivos oferecem suporte a TIF, elas:

  • [C-1-1] É PRECISO declarar o recurso da plataforma android.software.live_tv.
  • [C-1-2] É OBRIGATÓRIO pré-carregar um aplicativo de TV (app de TV) e atender a todos os requisitos descritos na seção 3.12.1.

3.12.1. App de TV

Se as implementações de dispositivos oferecem suporte a TIF:

  • [C-1-1] O app de TV precisa oferecer recursos para instalar e usar canais de TV e atender aos requisitos a seguir.

O app de TV necessário para implementações de dispositivos Android que declaram a flag de recurso android.software.live_tv PRECISA atender aos seguintes requisitos:

  • As implementações de dispositivos DEVEM permitir que entradas de terceiros baseadas em TIF (entradas de terceiros) sejam instaladas e gerenciadas.
  • As implementações de dispositivos PODEM fornecer uma separação visual entre as entradas baseadas em TIF pré-instaladas (entradas instaladas) e as entradas de terceiros.
  • As implementações de dispositivos NÃO devem mostrar as entradas de terceiros mais de uma única ação de navegação longe do app de TV (ou seja, expandir uma lista de entradas de terceiros do app de TV).

O Android Open Source Project oferece uma implementação do app de TV que atende aos requisitos acima.

3.12.1.1. Guia de programação eletrônica

Se as implementações de dispositivos oferecem suporte a TIF, elas:

  • [C-1-1] PRECISA mostrar uma sobreposição informativa e interativa, que PRECISA incluir um guia de programação eletrônica (EPG) gerado com base nos valores nos campos TvContract.Programs.
  • [C-1-2] Na mudança de canal, as implementações de dispositivos precisam mostrar os dados de EPG do programa que está sendo reproduzido.
  • [SR] É ALTAMENTE RECOMENDADO que o EPG mostre entradas instaladas e de terceiros com a mesma importância. A EPG NÃO DEVE mostrar as entradas de terceiros a mais de uma ação de navegação das entradas instaladas na EPG.
  • A EPG DEVE mostrar informações de todas as entradas instaladas e de terceiros.
  • O EPG PODE fornecer uma separação visual entre as entradas instaladas e as entradas de terceiros.
3.12.1.2. Navegação

Se as implementações de dispositivos oferecem suporte a TIF, elas:

  • [C-1-1] É PRECISO permitir a navegação para as seguintes funções usando o botão direcional, as teclas "Voltar" e "Início" nos dispositivos de entrada do dispositivo Android TV (ou seja, controle remoto, aplicativo de controle remoto ou controle de jogos):

    • Como mudar de canal de TV
    • Abertura da EPG
    • Como configurar e ajustar entradas de terceiros com base em TIF
    • Como abrir o menu "Configurações"

  • DEVE transmitir eventos de tecla para entradas HDMI pelo CEC.

3.12.1.3. Vinculação de apps de entrada de TV

Se as implementações de dispositivos oferecem suporte a TIF:

  • [C-1-1] As implementações de dispositivos Android TV precisam oferecer suporte à vinculação de apps de entrada de TV, que permite que todas as entradas forneçam links de atividades da atividade atual para outra (ou seja, um link da programação ao vivo para conteúdo relacionado).
  • [C-1-2] O app de TV PRECISA mostrar a vinculação do app de entrada de TV quando ela for fornecida.
3.12.1.4. Mudança de horário

Se as implementações de dispositivos oferecem suporte a TIF, elas:

  • [SR] ALTAMENTE RECOMENDADO para oferecer suporte ao time-shifting, que permite que o usuário pause e retome o conteúdo ao vivo.
  • DEVE fornecer ao usuário uma maneira de pausar e retomar o programa que está sendo reproduzido, se o deslocamento no tempo para esse programa estiver disponível.
3.12.1.5. Gravação de TV

Se as implementações de dispositivos oferecem suporte a TIF, elas:

  • [SR] É ALTAMENTE RECOMENDADO oferecer suporte à gravação de TV.
  • DEVE fornecer uma interface do usuário para reproduzir programas gravados.
  • Se a entrada de TV for compatível com a gravação e a gravação de um programa não for proibida, o EPG PODERÁ oferecer uma maneira de gravar um programa.

3.13. Configurações rápidas

O Android oferece um componente de interface de configurações rápidas que permite acesso rápido a ações usadas com frequência ou necessárias com urgência.

Se as implementações do dispositivo incluírem um componente de interface de configurações rápidas, elas:

  • [C-1-1] PRECISA permitir que o usuário adicione ou remova os blocos fornecidos pelas APIs quicksettings de um app de terceiros.
  • [C-1-2] NÃO é permitido adicionar automaticamente um bloco de um app de terceiros diretamente às Configurações rápidas.
  • [C-1-3] É OBRIGATÓRIO mostrar todos os blocos adicionados pelo usuário de apps de terceiros com os blocos de configurações rápidas fornecidos pelo sistema.

3.14. Interface de mídia

Se as implementações de dispositivos incluírem o framework de IU com suporte a apps de terceiros que dependem de MediaBrowser e MediaSession , elas:

  • [C-1-1] É OBRIGATÓRIO mostrar os ícones de MediaItem e de notificação inalterados.
  • [C-1-2] PRECISA mostrar esses itens conforme descrito pela MediaSession, por exemplo, metadados, ícones e imagens.
  • [C-1-3] É OBRIGATÓRIO mostrar o título do app.
  • [C-1-4] É PRECISO ter uma gaveta para apresentar a hierarquia do MediaBrowser.

3.15. Instant Apps

As implementações de dispositivos precisam atender aos seguintes requisitos:

  • [C-0-1] As permissões concedidas aos apps instantâneos PRECISAM ter o android:protectionLevel definido como "ephemeral".
  • [C-0-2] Os apps instantâneos NÃO PODEM interagir com apps instalados por meio de intents implícitas, a menos que uma das seguintes condições seja verdadeira:
    • O filtro de padrão de intent do componente é exposto e tem CATEGORY_BROWSABLE
    • A ação é uma das seguintes: ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE.
    • O destino é exposto explicitamente com android:visibleToInstantApps
  • [C-0-3] Os apps instantâneos NÃO PODEM interagir explicitamente com apps instalados, a menos que o componente seja exposto por android:visibleToInstantApps.
  • [C-0-4] Os apps instalados NÃO podem ver detalhes sobre apps instantâneos no dispositivo, a menos que o app instantâneo se conecte explicitamente ao aplicativo instalado.

3.16. Pareamento de dispositivo complementar

O Android inclui suporte ao pareamento de dispositivos complementares para gerenciar a associação com mais eficiência e oferece a API CompanionDeviceManager para que os apps acessem esse recurso.

Se as implementações de dispositivo oferecem suporte ao recurso de pareamento do dispositivo complementar, elas:

  • [C-1-1] É PRECISO declarar a flag de recurso FEATURE_COMPANION_DEVICE_SETUP .
  • [C-1-2] É OBRIGATÓRIO garantir que as APIs no pacote android.companion sejam totalmente implementadas.
  • [C-1-3] É PRECISO fornecer recursos para o usuário selecionar/confirmar que um dispositivo complementar está presente e operacional.

4. Compatibilidade de empacotamento de apps

Implementações de dispositivos:

  • [C-0-1] É PRECISO ser capaz de instalar e executar arquivos ".apk" do Android gerados pela ferramenta "aapt" incluída no SDK oficial do Android.
  • Como o requisito acima pode ser desafiador, é RECOMENDADO que as implementações de dispositivo usem as implementações de systemDevice de gerenciamento de pacotes da referência do AOSP.
  • [C-0-2] É PRECISO oferecer suporte à verificação de arquivos ".apk" usando o Esquema de assinatura de APK v2 e a assinatura JAR.
  • [C-0-3] NÃO É PERMITIDO estender os formatos .apk, Android Manifest, Dalvik bytecode ou bytecode do RenderScript de modo a impedir a instalação e a execução correta desses arquivos em outros dispositivos compatíveis.

  • [C-0-4] NÃO É PERMITIDO que apps que não sejam o "instalador de registro" atual do pacote desinstalem o app silenciosamente sem nenhuma solicitação, conforme documentado no SDK para a permissão DELETE_PACKAGE. As únicas exceções são o app verificador de pacotes do sistema que processa a intent PACKAGE_NEEDS_VERIFICATION e o app gerenciador de armazenamento que processa a intent ACTION_MANAGE_STORAGE.

  • [C-0-5] PRECISA ter uma atividade que processe a intent android.settings.MANAGE_UNKNOWN_APP_SOURCES.

  • [C-0-6] NÃO É PERMITIDO instalar pacotes de apps de fontes desconhecidas, a menos que o app que solicita a instalação atenda a todos os requisitos abaixo:

    • Ele PRECISA declarar a permissão REQUEST_INSTALL_PACKAGES ou ter o android:targetSdkVersion definido como 24 ou menos.
    • O usuário precisa ter concedido permissão para instalar apps de fontes desconhecidas.

  • DEVE fornecer uma capacidade do usuário para conceder/revogar a permissão de instalação de apps de fontes desconhecidas por aplicativo, mas PODE escolher implementar isso como uma operação nula e retornar RESULT_CANCELED para startActivityForResult(), se a implementação do dispositivo não permitir que os usuários tenham essa escolha. No entanto, mesmo nesses casos, eles DEVEM indicar ao usuário por que essa escolha não foi apresentada.

5. Compatibilidade com multimídia

Implementações de dispositivos:

  • [C-0-1] É PRECISO oferecer suporte aos formatos de mídia, codificadores, decodificadores, tipos de arquivo e formatos de contêiner definidos na seção 5.1 para todos os codecs declarados por MediaCodecList.
  • [C-0-2] É OBRIGATÓRIO declarar e informar o suporte para os codificadores e decodificadores disponíveis para apps de terceiros por meio de MediaCodecList.
  • [C-0-3] PRECISA ser capaz de decodificar e disponibilizar para apps de terceiros todos os formatos que pode codificar. Isso inclui todos os bitstreams gerados pelos codificadores e os perfis informados no CamcorderProfile.

Implementações de dispositivos:

  • DEVE ter como objetivo a latência mínima do codec. Em outras palavras, eles
    • NÃO deve consumir e armazenar buffers de entrada e retornar buffers de entrada apenas uma vez processados.
    • NÃO DEVE manter buffers decodificados por mais tempo do que o especificado pelo padrão (por exemplo, SPS).
    • NÃO segure buffers codificados por mais tempo do que o necessário pela estrutura GOP.

Todos os codecs listados na seção abaixo são fornecidos como implementações de software na implementação preferida do Android do Android Open Source Project.

Nem o Google nem a Open Handset Alliance representam que esses codecs estão livres de patentes de terceiros. Quem pretende usar esse código-fonte em produtos de hardware ou software deve saber que as implementações desse código, incluindo em software de código aberto ou shareware, podem exigir licenças de patente dos detentores relevantes.

5.1. Codecs de mídia

5.1.1. Codificação de áudio

Confira mais detalhes em 5.1.3. Detalhes dos codecs de áudio.

Se as implementações do dispositivo declararem android.hardware.microphone, elas PRECISAM oferecer suporte à seguinte codificação de áudio:

  • [C-1-1] PCM/WAVE

5.1.2. Decodificação de áudio

Confira mais detalhes em 5.1.3. Detalhes dos codecs de áudio.

Se as implementações do dispositivo declararem suporte ao recurso android.hardware.audio.output, elas precisarão oferecer suporte aos seguintes decodificadores de áudio:

  • [C-1-1] Perfil MPEG-4 AAC (AAC LC)
  • [C-1-2] Perfil MPEG-4 HE AAC (AAC+).
  • [C-1-3] Perfil MPEG-4 HE AACv2 (AAC+ aprimorado)
  • [C-1-4] AAC ELD (AAC aprimorado com atraso baixo)
  • [C-1-5] FLAC
  • [C-1-6] MP3
  • [C-1-7] MIDI
  • [C-1-8] Vorbis
  • [C-1-9] PCM/WAVE
  • [C-1-10] Opus

Se as implementações do dispositivo oferecerem suporte à decodificação de buffers de entrada AAC de streams multicanais (ou seja, mais de dois canais) para PCM usando o decodificador de áudio AAC padrão na API android.media.MediaCodec, é OBRIGATÓRIO ter suporte ao seguinte:

  • [C-2-1] A decodificação PRECISA ser realizada sem downmix. Por exemplo, um stream AAC 5.0 precisa ser decodificado para cinco canais de PCM, e um stream AAC 5.1 precisa ser decodificado para seis canais de PCM.
  • [C-2-2] Os metadados de alcance dinâmico precisam ser definidos em "Controle de alcance dinâmico (DRC)" na ISO/IEC 14496-3 e nas chaves DRC android.media.MediaFormat para configurar os comportamentos relacionados ao alcance dinâmico do decodificador de áudio. As chaves AAC DRC foram introduzidas na API 21 e são: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL e KEY_AAC_ENCODED_TARGET_LEVEL.

5.1.3. Detalhes dos codecs de áudio

Formato/Codec Detalhes Tipos de arquivo/formatos de contêiner compatíveis
Perfil MPEG-4 AAC
(AAC LC) 		Suporte a conteúdo mono/estéreo/5.0/5.1 com taxas de amostragem padrão de 8 a 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
  • AAC bruto ADTS (.aac, ADIF não é compatível)
  • MPEG-TS (.ts, não pesquisável)
Perfil MPEG-4 HE AAC (AAC+) Suporte a conteúdo mono/estéreo/5.0/5.1 com taxas de amostragem padrão de 16 a 48 kHz.
Perfil MPEG-4 HE AACv2
(AAC+ aprimorado) 		Suporte a conteúdo mono/estéreo/5.0/5.1 com taxas de amostragem padrão de 16 a 48 kHz.
AAC ELD (AAC aprimorado com atraso baixo) Suporte a conteúdo mono/estéreo com taxas de amostragem padrão de 16 a 48 kHz.
AMR-NB 4,75 a 12,2 kbps com amostragem a 8 kHz. 3GPP (.3gp)
AMR-WB 9 taxas de 6,60 kbit/s a 23,85 kbit/s com amostragem a 16 kHz.
FLAC Mono/estéreo (sem multicanal). Taxas de amostragem de até 48 kHz (mas o valor de até 44,1 kHz é RECOMENDADO em dispositivos com saída de 44,1 kHz, já que o redutor de 48 para 44,1 kHz não inclui um filtro passa baixa). RECOMENDADO 16 bits; sem pontilhamento aplicado para 24 bits. Somente FLAC (.flac)
MP3 Taxa de bits mono/estéreo constante (CBR) ou variável (VBR) de 8-320 kbps. MP3 (.mp3)
MIDI MIDI tipos 0 e 1. DLS versões 1 e 2. XMF e XMF para celular. Compatível com os formatos de toque RTTTL/RTX, OTA e iMelody.
  • Tipo 0 e 1 (.mid, .xmf, .mxmf)
  • RTTTL/RTX (.rtttl, .rtx)
  • OTA (.ota)
  • iMelody (.imy)
Vorbis
  • Ogg (.ogg)
  • Matroska (.mkv, Android 4.0+)
PCM/WAVE PCM linear de 16 bits (taxas até o limite de hardware). Os dispositivos PRECISAM oferecer suporte a taxas de amostragem para gravação PCM bruta em frequências de 8.000, 11.025, 16.000 e 44.100 Hz. WAVE (.wav)
Opus Matroska (.mkv), Ogg(.ogg)

5.1.4. Codificação de imagem

Confira mais detalhes em 5.1.6. Detalhes dos codecs de imagem.

As implementações de dispositivo precisam oferecer suporte à codificação da seguinte imagem:

  • [C-0-1] JPEG
  • [C-0-2] PNG
  • [C-0-3] WebP

5.1.5. Decodificação de imagem

Confira mais detalhes em 5.1.6. Detalhes dos codecs de imagem.

As implementações de dispositivos precisam oferecer suporte à codificação da seguinte decodificação de imagem:

  • [C-0-1] JPEG
  • [C-0-2] GIF
  • [C-0-3] PNG
  • [C-0-4] BMP
  • [C-0-5] WebP
  • [C-0-6] Raw

5.1.6. Detalhes dos codecs de imagem

Formato/Codec Detalhes Tipos de arquivo/formatos de contêiner compatíveis
JPEG Básico+progressivo JPEG (.jpg)
GIF GIF (.gif)
PNG PNG (.png)
BMP BMP (.bmp)
WebP WebP (.webp)
bruto ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)

5.1.7. Codecs de vídeo

  • Para uma qualidade aceitável de streaming de vídeo na Web e serviços de videoconferência, as implementações de dispositivos PRECISAM usar um codec VP8 de hardware que atenda aos requisitos.

Se as implementações do dispositivo incluírem um decodificador ou codificador de vídeo:

  • [C-1-1] Os codecs de vídeo precisam ter suporte a tamanhos de buffer de bytes de saída e entrada que acomodem o maior frame possível compactado e descompactado, conforme determinado pelo padrão e pela configuração, mas sem alocar em excesso.

  • [C-1-2] Os codificadores e decodificadores de vídeo PRECISAM oferecer suporte ao formato de cores flexível YUV420 (COLOR_FormatYUV420Flexible).

Se as implementações de dispositivos anunciarem suporte ao perfil HDR pelo Display.HdrCapabilities, elas:

  • [C-2-1] É PRECISO oferecer suporte à análise e ao processamento de metadados estáticos HDR.

Se as implementações de dispositivo anunciarem suporte à atualização interna usando FEATURE_IntraRefresh na classe MediaCodecInfo.CodecCapabilities, elas:

  • [C-3-1]PRECISA oferecer suporte aos períodos de atualização no intervalo de 10 a 60 frames e operar com precisão em até 20% do período de atualização configurado.

5.1.8. Lista de codecs de vídeo

Formato/Codec Detalhes Tipos de arquivo/
formatos de contêiner compatíveis
H.263
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
H.264 AVC Consulte as seções 5.2 e 5.3 para mais detalhes.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • MPEG-2 TS (.ts, AAC exclusivo de áudio, não pesquisável, Android 3.0+)
H.265 HEVC Consulte a seção 5.3 para mais detalhes. MPEG-4 (.mp4)
MPEG-2 Perfil principal MPEG2-TS
MPEG-4 SP 3GPP (.3gp)
VP8 Consulte as seções 5.2 e 5.3 para mais detalhes.
VP9 Consulte a seção 5.3 para mais detalhes.

5.2. Codificação de vídeo

Se as implementações de dispositivos oferecerem suporte a qualquer codificador de vídeo e o disponibilizarem para apps de terceiros, elas:

  • NÃO deve ser, em duas janelas deslizantes, mais de 15% do que o bitrate entre intervalos intraframe (I-frame).
  • NÃO deve ser mais de 100% do que o bitrate em uma janela deslizante de 1 segundo.

Se as implementações de dispositivos incluírem uma tela integrada com comprimento diagonal de pelo menos 2,5 polegadas ou incluírem uma porta de saída de vídeo ou declararem o suporte a uma câmera usando a flag de recurso android.hardware.camera.any, elas:

  • [C-1-1] É PRECISO incluir o suporte a pelo menos um dos codificadores de vídeo VP8 ou H.264 e disponibilizá-lo para aplicativos de terceiros.
  • DEVE oferecer suporte aos codificadores de vídeo VP8 e H.264 e disponibilizá-los para aplicativos de terceiros.

Se as implementações de dispositivos oferecerem suporte a qualquer um dos codificadores de vídeo H.264, VP8, VP9 ou HEVC e disponibilizarem esse suporte para aplicativos de terceiros, elas:

  • [C-2-1] É PRECISO ter suporte a taxas de bits configuráveis dinamicamente.
  • DEVE oferecer suporte a taxas de frames variáveis, em que o codificador de vídeo PRECISA determinar a duração instantânea do frame com base nos carimbos de data/hora dos buffers de entrada e alocar o bucket de bits com base nessa duração.

Se as implementações de dispositivos oferecerem suporte ao codificador de vídeo MPEG-4 SP e o disponibilizarem para apps de terceiros, elas:

  • DEVE oferecer suporte a taxas de bits configuráveis dinamicamente para o codificador compatível.

5.2.1. H.263

Se as implementações de dispositivos oferecerem suporte a codificadores H.263 e disponibilizarem esse recurso para apps de terceiros, elas:

  • [C-1-1] É PRECISO oferecer suporte ao nível 45 do perfil de referência.
  • DEVE oferecer suporte a taxas de bits configuráveis dinamicamente para o codificador compatível.

5.2.2. H-264

Se as implementações de dispositivos oferecem suporte ao codec H.264, elas:

  • [C-1-1] É PRECISO oferecer suporte ao perfil de referência de nível 3. No entanto, o suporte para ASO (Ordem arbitrária de fatias), FMO (Ordem flexível de macrobloco) e RS (fatias redundantes) é OPCIONAL. Além disso, para manter a compatibilidade com outros dispositivos Android, é RECOMENDÁVEL que os codificadores não usem ASO, FMO e RS para o perfil de referência.
  • [C-1-2] É PRECISO oferecer suporte aos perfis de codificação de vídeo SD (definição padrão) na tabela a seguir.
  • DEVE oferecer suporte ao nível 4 do perfil principal.
  • DEVE oferecer suporte aos perfis de codificação de vídeo em HD (alta definição), conforme indicado na tabela a seguir.

Se as implementações de dispositivos informarem suporte à codificação H.264 para vídeos com resolução de 720p ou 1080p pelas APIs de mídia, elas:

  • [C-2-1] É PRECISO oferecer suporte aos perfis de codificação na tabela a seguir.
SD (baixa qualidade) SD (alta qualidade) HD 720p HD 1080p
Resolução do vídeo 320 x 240 px 720 x 480 px 1.280 x 720 px 1.920 x 1.080 px
Frame rate do vídeo 20 qps 30 fps 30 fps 30 fps
Taxa de bits do vídeo 384 Kbps 2 Mbps 4 Mbps 10 Mbps

5.2.3. VP8

Se as implementações de dispositivos forem compatíveis com o codec VP8, elas:

  • [C-1-1] PRECISA oferecer suporte aos perfis de codificação de vídeo SD.
  • DEVE oferecer suporte aos seguintes perfis de codificação de vídeo em HD (alta definição).
  • DEVE oferecer suporte à gravação de arquivos WebM do Matroska.
  • DEVE usar um codec VP8 de hardware que atenda aos requisitos de codificação de hardware do RTC do projeto WebM para garantir uma qualidade aceitável de streaming de vídeo da Web e serviços de videoconferência.

Se as implementações de dispositivos informarem suporte à codificação VP8 para vídeos com resolução de 720p ou 1080p pelas APIs de mídia, elas:

  • [C-2-1] É PRECISO oferecer suporte aos perfis de codificação na tabela a seguir.
SD (baixa qualidade) SD (alta qualidade) HD 720p HD 1080p
Resolução do vídeo 320 x 180 px 640 x 360 px 1.280 x 720 px 1.920 x 1.080 px
Frame rate do vídeo 30 fps 30 fps 30 fps 30 fps
Taxa de bits do vídeo 800 Kbps 2 Mbps 4 Mbps 10 Mbps

5.2.4. VP9

Se as implementações de dispositivos forem compatíveis com o codec VP9, elas:

  • DEVE oferecer suporte à gravação de arquivos WebM do Matroska.

5.3. Decodificação de vídeo

Se as implementações de dispositivos oferecerem suporte aos codecs VP8, VP9, H.264 ou H.265, elas:

  • [C-1-1] É PRECISO oferecer suporte à resolução dinâmica de vídeo e à alternância de frame rate pelas APIs padrão do Android no mesmo fluxo para todos os codecs VP8, VP9, H.264 e H.265 em tempo real e com a resolução máxima compatível com cada codec no dispositivo.

Se as implementações de dispositivos declararem suporte ao decodificador Dolby Vision usando HDR_TYPE_DOLBY_VISION , elas:

  • [C-2-1] É OBRIGATÓRIO fornecer um extrator com tecnologia Dolby Vision.
  • [C-2-2] PRECISA exibir corretamente o conteúdo do Dolby Vision na tela do dispositivo ou em uma porta de saída de vídeo padrão, como HDMI.
  • [C-2-3] É OBRIGATÓRIO definir o índice de faixa das camadas básicas compatíveis com versões anteriores (se houver) para que ele seja igual ao índice de faixa da camada Dolby Vision combinada.

5.3.1. MPEG-2

Se as implementações de dispositivos oferecerem suporte a decodificadores MPEG-2, elas:

  • [C-1-1] PRECISA oferecer suporte ao nível alto do perfil principal.

5.3.2. H.263

Se as implementações de dispositivos oferecerem suporte a decodificadores H.263, elas:

  • [C-1-1] É PRECISO oferecer suporte ao nível 30 e 45 do perfil de referência.

5.3.3. MPEG-4

Se as implementações do dispositivo tiverem decodificadores MPEG-4, elas:

  • [C-1-1] É PRECISO oferecer suporte ao perfil simples de nível 3.

5.3.4. H.264

Se as implementações de dispositivos oferecerem suporte a decodificadores H.264, elas:

  • [C-1-1] É PRECISO ter suporte ao perfil principal de nível 3.1 e ao perfil de referência. O suporte a ASO (ordenação arbitrária de fatias), FMO (ordenação flexível de macrobloqueio) e RS (fatias redundantes) é OPCIONAL.
  • [C-1-2] É PRECISO decodificar vídeos com os perfis SD (definição padrão) listados na tabela a seguir e codificados com o perfil de referência e o perfil principal de nível 3.1 (incluindo 720p30).
  • DEVE ser capaz de decodificar vídeos com os perfis de alta definição, conforme indicado na tabela a seguir.

Se a altura informada pelo método Display.getSupportedModes() for igual ou maior que a resolução do vídeo, as implementações do dispositivo:

  • [C-2-1] É PRECISO oferecer suporte aos perfis de decodificação de vídeo HD 720p na tabela a seguir.
  • [C-2-2] É PRECISO oferecer suporte aos perfis de decodificação de vídeo HD 1080p na tabela a seguir.
SD (baixa qualidade) SD (alta qualidade) HD 720p HD 1080p
Resolução do vídeo 320 x 240 px 720 x 480 px 1.280 x 720 px 1.920 x 1.080 px
Frame rate do vídeo 30 fps 30 fps 60 qps 30 qps (60 qpsTV)
Taxa de bits do vídeo 800 Kbps 2 Mbps 8 Mbps 20 Mbps

5.3.5. H.265 (HEVC)

Se as implementações de dispositivos oferecerem suporte ao codec H.265, elas:

  • [C-1-1] É PRECISO oferecer suporte ao nível principal do perfil principal de nível 3 e aos perfis de decodificação de vídeo SD, conforme indicado na tabela a seguir.
  • DEVE oferecer suporte aos perfis de decodificação em HD, conforme indicado na tabela a seguir.
  • [C-1-2] É PRECISO oferecer suporte aos perfis de decodificação em HD, conforme indicado na tabela a seguir, se houver um decodificador de hardware.

Se a altura informada pelo método Display.getSupportedModes() for igual ou maior que a resolução do vídeo, faça o seguinte:

  • [C-2-1] As implementações de dispositivos precisam oferecer suporte a pelo menos uma das decodificações H.265 ou VP9 dos perfis 720p, 1080p e UHD.
SD (baixa qualidade) SD (alta qualidade) HD 720p HD 1080p Ultra HD
Resolução do vídeo 352 x 288 px 720 x 480 px 1.280 x 720 px 1.920 x 1.080 px 3840 x 2160 px
Frame rate do vídeo 30 fps 30 fps 30 fps 30/60 fps (60 fpsTV com decodificador de hardware H.265) 60 qps
Taxa de bits do vídeo 600 Kbps 1,6 Mbps 4 Mbps 5 Mbps 20 Mbps

5.3.6. VP8

Se as implementações de dispositivos forem compatíveis com o codec VP8, elas:

  • [C-1-1] É PRECISO oferecer suporte aos perfis de decodificação SD na tabela a seguir.
  • DEVE usar um codec VP8 de hardware que atenda aos requisitos.
  • DEVE oferecer suporte aos perfis de decodificação em HD na tabela a seguir.

Se a altura informada pelo método Display.getSupportedModes() for igual ou maior que a resolução do vídeo, faça o seguinte:

  • [C-2-1] As implementações de dispositivos precisam oferecer suporte aos perfis de 720p na tabela a seguir.
  • [C-2-2] As implementações de dispositivos precisam oferecer suporte a perfis de 1080p na tabela a seguir.
SD (baixa qualidade) SD (alta qualidade) HD 720p HD 1080p
Resolução do vídeo 320 x 180 px 640 x 360 px 1.280 x 720 px 1.920 x 1.080 px
Frame rate do vídeo 30 fps 30 fps 30 qps (60 qpsTV) 30 (60 fpsTelevisão)
Taxa de bits do vídeo 800 Kbps 2 Mbps 8 Mbps 20 Mbps

5.3.7. VP9

Se as implementações de dispositivos forem compatíveis com o codec VP9, elas:

  • [C-1-1] PRECISA oferecer suporte aos perfis de decodificação de vídeo SD, conforme indicado na tabela a seguir.
  • DEVE oferecer suporte aos perfis de decodificação em HD, conforme indicado na tabela a seguir.

Se as implementações do dispositivo forem compatíveis com o codec VP9 e um decodificador de hardware:

  • [C-2-1] É PRECISO oferecer suporte aos perfis de decodificação em HD, conforme indicado na tabela a seguir.

Se a altura informada pelo método Display.getSupportedModes() for igual ou maior que a resolução do vídeo, faça o seguinte:

  • [C-3-1] As implementações de dispositivos precisam oferecer suporte a pelo menos uma das decodificações VP9 ou H.265 dos perfis 720p, 1080p e UHD.
SD (baixa qualidade) SD (alta qualidade) HD 720p HD 1080p Ultra HD
Resolução do vídeo 320 x 180 px 640 x 360 px 1.280 x 720 px 1.920 x 1.080 px 3840 x 2160 px
Frame rate do vídeo 30 fps 30 fps 30 fps 30 fps (60 fpsTV com decodificação de hardware VP9) 60 qps
Taxa de bits do vídeo 600 Kbps 1,6 Mbps 4 Mbps 5 Mbps 20 Mbps

5.4. Gravação em áudio

Embora alguns dos requisitos descritos nesta seção sejam listados como "DEVE" desde o Android 4.3, a definição de compatibilidade para versões futuras está planejada para mudar para "PRECISA". É ALTAMENTE RECOMENDÁVEL que os dispositivos Android atuais e novos atendam a esses requisitos listados como "DEVE", caso contrário, eles não poderão alcançar a compatibilidade com o Android quando forem atualizados para a versão futura.

5.4.1. Captura de áudio bruto

Se as implementações do dispositivo declararem android.hardware.microphone, elas:

  • [C-1-1] É PRECISO permitir a captura de conteúdo de áudio bruto com as seguintes características:

    • Formato: PCM linear, 16 bits
    • Taxas de amostragem: 8.000, 11.025, 16.000, 44.100 Hz
    • Canais: mono

  • [C-1-2] É PRECISO capturar acima das taxas de amostragem sem upsampling.

  • [C-1-3] É necessário incluir um filtro anti-aliasing adequado quando as taxas de amostragem fornecidas acima forem capturadas com redução de amostragem.

  • DEVE permitir a captura de conteúdo de áudio bruto com qualidade de rádio AM e DVD, o que significa as seguintes características:

    • Formato: PCM linear, 16 bits
    • Taxas de amostragem: 22.050, 48.000 Hz
    • Canais: estéreo

Se as implementações de dispositivos permitirem a captura de conteúdo de áudio bruto com qualidade de rádio AM e DVD, elas:

  • [C-2-1] É OBRIGATÓRIO capturar sem upsampling em qualquer proporção maior que 16000:22050 ou 44100:48000.
  • [C-2-2] É OBRIGATÓRIO incluir um filtro anti-aliasing adequado para qualquer amostragem de alta ou baixa.

5.4.2. Captura para reconhecimento de voz

Se as implementações do dispositivo declararem android.hardware.microphone, elas:

  • [C-1-1] É PRECISO capturar a fonte de áudio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION em uma das taxas de amostragem, 44100 e 48000.
  • [C-1-2] É OBRIGATÓRIO desativar, por padrão, qualquer processamento de áudio de redução de ruído ao gravar um stream de áudio da fonte de áudio AudioSource.VOICE_RECOGNITION.
  • [C-1-3] É OBRIGATÓRIO desativar por padrão qualquer controle de ganho automático ao gravar um fluxo de áudio da fonte de áudio AudioSource.VOICE_RECOGNITION.
  • DEVE gravar o fluxo de áudio de reconhecimento de voz com amplitude aproximadamente plana em relação às características de frequência: especificamente, ±3 dB, de 100 Hz a 4.000 Hz.
  • DEVE gravar o stream de áudio de reconhecimento de voz com a sensibilidade de entrada definida de modo que uma fonte de nível de potência de som (SPL) de 90 dB a 1.000 Hz produza um RMS de 2.500 para amostras de 16 bits.
  • DEVE gravar o stream de áudio de reconhecimento de voz para que os níveis de amplitude PCM rastreiem linearmente as mudanças de SPL de entrada em pelo menos um intervalo de 30 dB de -18 dB a +12 dB em relação a 90 dB SPL no microfone.
  • DEVE gravar o fluxo de áudio de reconhecimento de voz com distorção harmônica total (THD, na sigla em inglês) menor que 1% para 1 kHz em 90 dB SPL no nível de entrada do microfone.

Se as implementações do dispositivo declararem tecnologias de android.hardware.microphone e supressão de ruído (redução) ajustadas para reconhecimento de fala, elas:

  • [C-2-1] PRECISA permitir que esse efeito de áudio seja controlável com a API android.media.audiofx.NoiseSuppressor.
  • [C-2-2] É OBRIGATÓRIO identificar de forma exclusiva cada implementação de tecnologia de supressão de ruído pelo campo AudioEffect.Descriptor.uuid.

5.4.3. Captura para redirecionamento da reprodução

A classe android.media.MediaRecorder.AudioSource inclui a fonte de áudio REMOTE_SUBMIX.

Se as implementações do dispositivo declararem android.hardware.audio.output e android.hardware.microphone, elas:

  • [C-1-1] É PRECISO implementar corretamente a fonte de áudio REMOTE_SUBMIX para que, quando um app use a API android.media.AudioRecord para gravar dessa fonte de áudio, ele capture uma mistura de todos os streams de áudio, exceto:

    • AudioManager.STREAM_RING
    • AudioManager.STREAM_ALARM
    • AudioManager.STREAM_NOTIFICATION

5.5. Reprodução de áudio

O Android inclui suporte para permitir que apps reproduzam áudio pelo periférico de saída de áudio, conforme definido na seção 7.8.2.

5.5.1. Reprodução de áudio bruto

Se as implementações do dispositivo declararem android.hardware.audio.output, elas:

  • [C-1-1] É PRECISO permitir a reprodução de conteúdo de áudio bruto com as seguintes características:

    • Formato: PCM linear, 16 bits
    • Taxas de amostragem: 8.000, 11.025, 16.000, 22.050, 32.000, 44.100
    • Canais: mono, estéreo

  • DEVE permitir a reprodução de conteúdo de áudio bruto com as seguintes características:

    • Taxas de amostragem: 24.000, 48.000

5.5.2. Efeitos de áudio

O Android oferece uma API para efeitos de áudio para implementações de dispositivos.

Se as implementações do dispositivo declararem o recurso android.hardware.audio.output, elas:

  • [C-1-1] PRECISA oferecer suporte às implementações EFFECT_TYPE_EQUALIZER e EFFECT_TYPE_LOUDNESS_ENHANCER controláveis pelas subclasses Equalizer e LoudnessEnhancer de AudioEffect.
  • [C-1-2] PRECISA oferecer suporte à implementação da API do visualizador, controlável pela classe Visualizer.
  • DEVE oferecer suporte às implementações EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB e EFFECT_TYPE_VIRTUALIZER controláveis pelas subclasses AudioEffect BassBoost, EnvironmentalReverb, PresetReverb e Virtualizer.

5.5.3. Volume da saída de áudio

Implementações de dispositivos automotivos:

  • DEVE permitir ajustar o volume de áudio separadamente para cada stream de áudio usando o tipo de conteúdo ou o uso conforme definido por AudioAttributes e o uso de áudio no carro conforme definido publicamente em android.car.CarAudioManager.

5.6. Latência de áudio

A latência de áudio é o tempo de atraso enquanto um sinal de áudio passa por um sistema. Muitas classes de aplicativos dependem de latências curtas para conseguir efeitos sonoros em tempo real.

Para os fins desta seção, use as seguintes definições:

  • Latência de saída. O intervalo entre o momento em que um aplicativo grava um frame de dados codificados em PCM e o momento em que o som correspondente é apresentado ao ambiente em um transdutor no dispositivo ou o sinal sai do dispositivo por uma porta e pode ser observado externamente.
  • Latência de saída fria. A latência de saída do primeiro frame, quando o sistema de saída de áudio estava inativo e desligado antes da solicitação.
  • latência de saída contínua. A latência de saída para frames subsequentes, depois que o dispositivo está reproduzindo áudio.
  • latência de entrada. O intervalo entre o momento em que um som é apresentado pelo ambiente ao dispositivo em um transdutor no dispositivo ou o sinal entra no dispositivo por uma porta e o momento em que um aplicativo lê o frame correspondente de dados codificados em PCM.
  • perda de entrada. A parte inicial de um sinal de entrada que está indisponível ou não pode ser usado.
  • Latência de entrada fria. A soma do tempo de entrada perdido e a latência de entrada do primeiro frame, quando o sistema de entrada de áudio estava inativo e desligado antes da solicitação.
  • latente de entrada contínua. A latência de entrada para frames subsequentes, enquanto o dispositivo está capturando áudio.
  • Jitter de saída fria. A variabilidade entre medições separadas de valores de latência de saída fria.
  • Jitter de entrada fria. A variabilidade entre medições separadas de valores de latência de entrada fria.
  • latência de ida e volta contínua. A soma da latência de entrada contínua mais a latência de saída contínua mais um período de buffer. O período de buffer permite que o app processe o sinal e mitigue a diferença de fase entre os streams de entrada e saída.
  • API da fila de buffer de PCM do OpenSL ES. O conjunto de APIs OpenSL ES relacionadas ao PCM no Android NDK.
  • API de áudio nativa AAudio. O conjunto de APIs AAudio no Android NDK.

Se as implementações do dispositivo declararem android.hardware.audio.output, é ALTAMENTE RECOMENDÁVEL que elas atendam ou excedam os seguintes requisitos:

  • [SR] Latência de saída fria de 100 milissegundos ou menos
  • [SR] Latência de saída contínua de 45 milissegundos ou menos
  • [SR] Minimizar o jitter de saída a frio

Se as implementações do dispositivo atenderem aos requisitos acima após qualquer calibração inicial ao usar a API de fila de buffer PCM do OpenSL ES, para latência de saída contínua e latência de saída fria em pelo menos um dispositivo de saída de áudio com suporte, elas são:

  • [SR] É ALTAMENTE RECOMENDADO informar áudio de baixa latência declarando a flag de recurso android.hardware.audio.low_latency.
  • [SR] É FORTEMENTE RECOMENDADO atender aos requisitos de áudio de baixa latência pela API AAudio.

Se as implementações do dispositivo não atenderem aos requisitos de áudio de baixa latência pela API de fila de buffer PCM do OpenSL ES, elas:

  • [C-1-1] NÃO é necessário informar suporte para áudio de baixa latência.

Se as implementações do dispositivo incluírem android.hardware.microphone, é ALTAMENTE RECOMENDÁVEL que elas atendam a estes requisitos de áudio de entrada:

  • [SR] Latência de entrada fria de 100 milissegundos ou menos
  • [SR] Latência de entrada contínua de 30 milissegundos ou menos
  • [SR] Latência de ida e volta contínua de 50 milissegundos ou menos
  • [SR] Minimizar o jitter de entrada a frio

5.7. Protocolos de rede

As implementações de dispositivos precisam oferecer suporte aos protocolos de rede de mídia para reprodução de áudio e vídeo, conforme especificado na documentação do SDK do Android.

Se as implementações de dispositivos incluírem um decodificador de áudio ou vídeo, elas:

  • [C-1-1] É PRECISO oferecer suporte a todos os codecs e formatos de contêiner necessários na seção 5.1 por HTTP(S).

  • [C-1-2] É necessário oferecer suporte aos formatos de segmento de mídia mostrados na tabela "Formatos de segmento de mídia" abaixo no draft protocol HTTP Live Streaming, versão 7.

  • [C-1-3] É PRECISO oferecer suporte ao seguinte perfil de vídeo de áudio RTP e codecs relacionados na tabela RTSP abaixo. Para exceções, consulte as notas de rodapé da tabela na seção 5.1.

Formatos de segmento de mídia

Formatos de segmentos Referência(s) Suporte a codec obrigatório
Stream de transporte MPEG-2 ISO 13818 Codecs de vídeo:
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
Consulte a seção 5.1.3 para saber mais sobre o H.264 AVC, o MPEG2-4 SP,
e o MPEG-2.

Codecs de áudio:

  • AAC
Consulte a seção 5.1.1 para saber mais sobre o AAC e as variantes dele.
AAC com enquadramento ADTS e tags ID3 ISO 13818-7 Consulte a seção 5.1.1 para saber mais sobre o AAC e as variantes
WebVTT WebVTT

RTSP (RTP, SDP)

Nome do perfil Referência(s) Suporte a codec obrigatório
H264 AVC RFC 6184 Consulte a seção 5.1.3 para saber mais sobre o AVC H264.
MP4A-LATM RFC 6416 (em inglês) Consulte a seção 5.1.1 para saber mais sobre o AAC e as variantes
H263-1998 RFC 3551
RFC 4629
RFC 2190 		Consulte a seção 5.1.3 para saber mais sobre o H263.
H263-2000 RFC 4629 Consulte a seção 5.1.3 para saber mais sobre o H263.
AMR RFC 4867 Consulte a seção 5.1.1 para saber mais sobre AMR-NB.
AMR-WB RFC 4867 Consulte a seção 5.1.1 para saber mais sobre AMR-WB.
MP4V-ES RFC 6416 (em inglês) Consulte a seção 5.1.3 para saber mais sobre o MPEG-4 SP.
mpeg4-generic RFC 3640 (em inglês) Consulte a seção 5.1.1 para saber mais sobre o AAC e as variantes
MP2T RFC 2250 Consulte MPEG-2 Transport Stream em HTTP Live Streaming para mais detalhes.

5.8. Secure Media

Se as implementações de dispositivos oferecem suporte à saída de vídeo segura e podem oferecer suporte a superfícies seguras, elas:

  • [C-1-1] É PRECISO declarar suporte para Display.FLAG_SECURE.

Se as implementações de dispositivos declararem suporte a Display.FLAG_SECURE e ao protocolo de exibição sem fio, elas:

  • [C-2-1] É OBRIGATÓRIO proteger a vinculação com um mecanismo criptograficamente seguro, como o HDCP 2.x ou mais recente, para as telas conectadas por protocolos sem fio, como o Miracast.

Se as implementações de dispositivos declararem suporte a Display.FLAG_SECURE e a tela externa com fio, elas:

  • [C-3-1] É PRECISO ter suporte a HDCP 1.2 ou mais recente para todas as telas externas com fio.

5.9. Interface digital para instrumentos musicais (MIDI)

Se uma implementação de dispositivo oferece suporte ao transporte de software MIDI entre apps (dispositivos MIDI virtuais) e oferece suporte a MIDI em todos os seguintes transportes de hardware compatíveis com MIDI para os quais ele oferece conectividade genérica que não é MIDI, ele é:

Os transportes de hardware com capacidade MIDI são:

  • Modo de host USB (seção 7.7 USB)
  • Modo de periférico USB (seção 7.7 USB)
  • MIDI por Bluetooth LE atuando no papel central (seção 7.4.3 Bluetooth)

Se a implementação do dispositivo oferecer conectividade genérica que não seja MIDI em um determinado transporte de hardware compatível com MIDI listado acima, mas não oferecer suporte a MIDI nesse transporte de hardware, ele:

  • [C-1-1] NÃO é permitido informar suporte para o recurso android.software.midi.

5.10. Áudio profissional

Se as implementações de dispositivos informarem suporte ao recurso android.hardware.audio.pro pela classe android.content.pm.PackageManager, elas:

  • [C-1-1] É PRECISO informar o suporte ao recurso android.hardware.audio.low_latency.
  • [C-1-2] A latência de áudio de ida e volta contínua, conforme definido na seção 5.6 Latência de áudio, PRECISA ser de 20 milissegundos ou menos e DEVE ser de 10 milissegundos ou menos em pelo menos um caminho compatível.
  • [C-1-3] É PRECISO incluir portas USB com suporte para o modo de host USB e o modo de periférico USB.
  • [C-1-4] É PRECISO informar o suporte ao recurso android.software.midi.
  • [C-1-5] É NECESSÁRIO atender às latências e aos requisitos de áudio USB usando a API de fila de buffer PCM do OpenSL ES.
  • DEVE fornecer um nível sustentável de desempenho da CPU enquanto o áudio estiver ativo.
  • DEVE minimizar a imprecisão e a deriva do relógio de áudio em relação ao horário padrão.
  • DEVE minimizar a deriva do relógio de áudio em relação à CLOCK_MONOTONIC da CPU quando ambos estão ativos.
  • DEVE minimizar a latência de áudio em transdutores no dispositivo.
  • DEVE minimizar a latência de áudio por áudio digital USB.
  • DEVE documentar as medições de latência de áudio em todos os caminhos.
  • DEVE minimizar o jitter nos tempos de entrada de callback de conclusão do buffer de áudio, já que isso afeta a porcentagem utilizável da largura de banda total da CPU pelo callback.
  • DEVE fornecer zero underruns (saída) ou overruns (entrada) de áudio no uso normal com a latência informada.
  • DEVE fornecer zero diferença de latência entre canais.
  • DEVE minimizar a latência média do MIDI em todos os transportes.
  • DEVE minimizar a variabilidade da latência MIDI sob carga (jitter) em todos os transportes.
  • DEVE fornecer carimbos de data/hora MIDI precisos em todos os transportes.
  • DEVE minimizar o ruído do sinal de áudio em transdutores no dispositivo, incluindo o período imediatamente após a inicialização a frio.
  • DEVE fornecer zero diferença de relógio de áudio entre os lados de entrada e saída dos endpoints correspondentes, quando ambos estão ativos. Exemplos de pontos finais correspondentes incluem o microfone e o alto-falante no dispositivo ou a entrada e a saída do conector de áudio.
  • DEVE processar callbacks de conclusão de buffer de áudio para os lados de entrada e saída dos endpoints correspondentes na mesma linha de execução quando ambos estiverem ativos e entrar no callback de saída imediatamente após o retorno do callback de entrada. Ou, se não for viável processar os callbacks na mesma linha de execução, insira o callback de saída logo após inserir o callback de entrada para permitir que o aplicativo tenha um tempo consistente dos lados de entrada e saída.
  • DEVE minimizar a diferença de fase entre o buffer de áudio HAL para os lados de entrada e saída dos endpoints correspondentes.
  • DEVE minimizar a latência de toque.
  • DEVE minimizar a variabilidade da latência do toque sob carga (jitter).

Se as implementações do dispositivo atenderem a todos os requisitos acima, elas:

Se as implementações do dispositivo atenderem aos requisitos pela API da fila de buffer PCM do OpenSL ES, elas:

  • [SR] É FORTEMENTE RECOMENDADO atender aos mesmos requisitos pela API AAudio.

Se as implementações do dispositivo incluírem um conector de áudio de 3,5 mm com quatro condutores, elas:

Se as implementações de dispositivos omitirem uma entrada de áudio de 3,5 mm com quatro condutores, elas:

  • [C-3-1] É PRECISO ter uma latência de ida e volta contínua de 20 milissegundos ou menos.
  • A latência de ida e volta contínua do áudio DEVE ser de 10 milissegundos ou menos na porta do modo host USB usando a classe de áudio USB.

Se as implementações do dispositivo incluem portas USB com suporte ao modo de host USB, elas:

  • [C-4-1] É PRECISO implementar a classe de áudio USB.

Se as implementações do dispositivo incluem uma porta HDMI, elas:

  • [C-5-1] É PRECISO oferecer suporte à saída em estéreo e oito canais com profundidade de 20 ou 24 bits e 192 kHz sem perda de profundidade de bits ou reamostragem.

5.11. Captura para "Não processado"

O Android inclui suporte para gravação de áudio não processado pela fonte de áudio android.media.MediaRecorder.AudioSource.UNPROCESSED. No OpenSL ES, ele pode ser acessado com a predefinição de gravação SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Se as implementações de dispositivos tiverem a intenção de oferecer suporte à fonte de áudio não processada e disponibilizá-la para apps de terceiros, elas:

  • [C-1-1] É OBRIGATÓRIO informar o suporte usando a propriedade android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

  • [C-1-2] É PRECISO mostrar características aproximadamente planas de amplitude em relação à frequência na faixa de frequência média: especificamente ±10 dB de 100 Hz a 7.000 Hz para cada microfone usado para gravar a fonte de áudio não processada.

  • [C-1-3] PRECISA mostrar níveis de amplitude na faixa de baixa frequência: especificamente de ±20 dB de 5 Hz a 100 Hz em comparação com a faixa de média frequência de cada microfone usado para gravar a fonte de áudio não processada.

  • [C-1-4] PRECISA apresentar níveis de amplitude no intervalo de alta frequência: especificamente de ±30 dB de 7.000 Hz a 22 KHz em comparação com o intervalo de frequência média para cada microfone usado para gravar a fonte de áudio não processada.

  • [C-1-5] É PRECISO definir a sensibilidade de entrada de áudio de modo que uma fonte de tom senoidal de 1.000 Hz reproduzida a 94 dB de nível de pressão sonora (SPL) produza uma resposta com RMS de 520 para amostras de 16 bits (ou -36 dB em escala completa para amostras de ponto flutuante/precisão dupla) para cada microfone usado para gravar a fonte de áudio não processada.

  • [C-1-6] É OBRIGATÓRIO ter uma relação sinal-ruído (SNR) de 60 dB ou mais para cada microfone usado para gravar a fonte de áudio não processada. O SNR é medido como a diferença entre 94 dB SPL e SPL equivalente de ruído próprio, ponderado em A.

  • [C-1-7] É PRECISO ter uma distorção harmônica total (THD) menor que 1% para 1 kHz a 90 dB SPL de nível de entrada em cada microfone usado para gravar a fonte de áudio não processada.

  • NÃO pode ter nenhum outro processamento de sinal (por exemplo, controle automático de ganho, filtro passa-alta ou cancelamento de eco) no caminho, exceto um multiplicador de nível para levar o nível ao intervalo desejado. Resumindo:

  • [C-1-8] Se qualquer processamento de sinal estiver presente na arquitetura por qualquer motivo, ele PRECISA ser desativado e introduzir zero atraso ou latência extra no caminho do sinal.
  • [C-1-9] O multiplicador de nível, embora permitido no caminho, NÃO PODE introduzir atraso ou latência no caminho do sinal.

Todas as medições de SPL são feitas diretamente ao lado do microfone em teste. Para várias configurações de microfone, esses requisitos se aplicam a cada microfone.

Se as implementações do dispositivo declararem android.hardware.microphone, mas não forem compatíveis com a fonte de áudio não processada, elas:

  • [C-2-1] É PRECISO retornar null para o método da API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) para indicar corretamente a falta de suporte.
  • [SR] ainda é FORTEMENTE RECOMENDADO para atender a tantos requisitos quanto possível para o caminho do sinal da fonte de gravação não processada.

6. Compatibilidade de ferramentas e opções para desenvolvedores

6.1. Ferramentas para desenvolvedores

Implementações de dispositivos:

  • [C-0-1] É PRECISO oferecer suporte às ferramentas para desenvolvedores do Android fornecidas no SDK do Android.

  • Android Debug Bridge (adb)

    • [C-0-2] É PRECISO oferecer suporte a todas as funções do adb conforme documentado no SDK do Android, incluindo dumpsys.
    • [C-0-3] NÃO MUDAR o formato ou o conteúdo dos eventos do sistema do dispositivo (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) registrados pelo dumpsys.
    • [C-0-4] O daemon adb do dispositivo PRECISA estar inativo por padrão, e é PRECISO ter um mecanismo acessível ao usuário para ativar a ponte de depuração do Android.
    • [C-0-5] É PRECISO oferecer suporte ao adb seguro. O Android inclui suporte para adb seguro. O adb seguro ativa o adb em hosts autenticados conhecidos.

    • [C-0-6] É PRECISO fornecer um mecanismo que permita que o adb seja conectado de uma máquina host. Exemplo:

      • Implementações de dispositivos sem uma porta USB que ofereça suporte ao modo periférico PRECISAM implementar o adb por uma rede local (como Ethernet ou Wi-Fi).
      • É PRECISO fornecer drivers para Windows 7, 9 e 10, permitindo que os desenvolvedores se conectem ao dispositivo usando o protocolo adb.

  • Serviço de monitoramento de depuração do Dalvik (ddms)

    • [C-0-7] PRECISA oferecer suporte a todos os recursos do ddms, conforme documentado no SDK do Android. Como o ddms usa o adb, o suporte a ele DEVE estar inativo por padrão, mas PRECISA ser compatível sempre que o usuário ativar a ponte de depuração do Android, como acima.
  • Monkey
    • [C-0-8] É OBRIGATÓRIO incluir o framework Monkey e disponibilizá-lo para uso de aplicativos.
  • SysTrace
    • [C-0-9] É PRECISO oferecer suporte à ferramenta systrace, conforme documentado no SDK do Android. O Systrace precisa estar inativo por padrão e PRECISA haver um mecanismo acessível ao usuário para ativar o Systrace.

6.2. Opções do desenvolvedor

O Android inclui suporte para que os desenvolvedores configurem as configurações relacionadas ao desenvolvimento de apps.

As implementações de dispositivos precisam oferecer uma experiência consistente para as Opções do desenvolvedor. Elas:

  • [C-0-1] DEVE honrar a intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS para mostrar configurações relacionadas ao desenvolvimento do app. A implementação upstream do Android oculta o menu "Opções do desenvolvedor" por padrão e permite que os usuários iniciem as opções do desenvolvedor depois de pressionar sete (7) vezes no item de menu Configurações > Sobre o dispositivo > Número da versão.
  • [C-0-2] É OBRIGATÓRIO ocultar as Opções do desenvolvedor por padrão e fornecer um mecanismo para ativar as Opções do desenvolvedor sem a necessidade de uma lista de permissões especial.
  • PODE limitar temporariamente o acesso ao menu de opções para desenvolvedores ocultando ou desativando o menu para evitar distrações em cenários em que a segurança do usuário é uma preocupação.

7. Compatibilidade de hardware

Se um dispositivo incluir um componente de hardware específico com uma API correspondente para desenvolvedores terceirizados:

  • [C-0-1] A implementação do dispositivo PRECISA implementar essa API conforme descrito na documentação do SDK do Android.

Se uma API no SDK interagir com um componente de hardware declarado como opcional e a implementação do dispositivo não tiver esse componente:

  • [C-0-2] As definições de classe completas (como documentado pelo SDK) para as APIs do componente AINDA precisam ser apresentadas.
  • [C-0-3] Os comportamentos da API precisam ser implementados como no-ops de maneira razoável.
  • [C-0-4] Os métodos da API precisam retornar valores nulos quando permitido pela documentação do SDK.
  • [C-0-5] Os métodos da API precisam retornar implementações sem operação de classes em que valores nulos não são permitidos pela documentação do SDK.
  • [C-0-6] Os métodos da API NÃO PODEM gerar exceções não documentadas pela documentação do SDK.
  • [C-0-7] As implementações de dispositivos PRECISAM informar consistentemente informações precisas de configuração de hardware usando os métodos getSystemAvailableFeatures() e hasSystemFeature(String) na classe android.content.pm.PackageManager para o mesmo fingerprint de build.

Um exemplo típico de um cenário em que esses requisitos se aplicam é a API de telefonia: mesmo em dispositivos que não são smartphones, essas APIs precisam ser implementadas como no-ops razoáveis.

7.1. Tela e gráficos

O Android inclui recursos que ajustam automaticamente os recursos do aplicativo e os layouts da interface de forma adequada para o dispositivo, garantindo que os aplicativos de terceiros sejam executados corretamente em várias configurações de hardware. Os dispositivos precisam implementar essas APIs e comportamentos corretamente, conforme detalhado nesta seção.

As unidades referenciadas pelos requisitos nesta seção são definidas da seguinte maneira:

  • tamanho físico diagonal. A distância em polegadas entre dois cantos opostos da parte iluminada da tela.
  • pontos por polegada (dpi). O número de pixels englobados por uma extensão linear horizontal ou vertical de 1". Quando os valores de dpi são listados, tanto o dpi horizontal quanto o vertical precisam estar dentro do intervalo.
  • proporção. A proporção dos pixels da dimensão maior em relação à dimensão menor da tela. Por exemplo, uma tela de 480 x 854 pixels seria 854/480 = 1,779, ou aproximadamente "16:9".
  • pixel de densidade independente (dp). A unidade de pixel virtual normalizada para uma tela de 160 dpi, calculada como: pixels = dps * (density/160).

7.1.1. Configuração da tela

7.1.1.1. Tamanho da tela

O framework da interface do Android oferece suporte a vários tamanhos diferentes de layout de tela lógica e permite que os aplicativos consultem o tamanho do layout de tela da configuração atual usando Configuration.screenLayout com SCREENLAYOUT_SIZE_MASK e Configuration.smallestScreenWidthDp.

  • [C-0-1] As implementações de dispositivos PRECISAM informar o tamanho correto do layout para o Configuration.screenLayout, conforme definido na documentação do SDK do Android. Especificamente, as implementações de dispositivo precisam informar as dimensões corretas da tela de pixel (dp) de densidade independente lógica, conforme abaixo:

    • Dispositivos com Configuration.uiMode definido como qualquer valor diferente de UI_MODE_TYPE_WATCH e que informem um tamanho small para Configuration.screenLayout precisam ter pelo menos 426 dp x 320 dp.
    • Os dispositivos que informam um tamanho normal para o Configuration.screenLayout precisam ter pelo menos 480 dp x 320 dp.
    • Os dispositivos que informam um tamanho large para o Configuration.screenLayout precisam ter pelo menos 640 dp x 480 dp.
    • Os dispositivos que informam um tamanho xlarge para o Configuration.screenLayout precisam ter pelo menos 960 dp x 720 dp.

  • [C-0-2] As implementações de dispositivos precisam respeitar corretamente o suporte declarado pelos aplicativos aos tamanhos de tela pelo atributo <supports-screens> no AndroidManifest.xml, conforme descrito na documentação do SDK do Android.

7.1.1.2. Proporção da tela

Embora não haja restrição ao valor da proporção da tela física, a proporção da tela lógica em que os apps de terceiros são renderizados, que pode ser derivada dos valores de altura e largura informados pelas APIs view.Display e Configuration, PRECISA atender aos seguintes requisitos:

  • [C-0-1] As implementações de dispositivo com Configuration.uiMode definido como UI_MODE_TYPE_NORMAL PRECISAM ter um valor de proporção entre 1,3333 (4:3) e 1,86 (aproximadamente 16:9), a menos que o app possa ser considerado pronto para ser esticado por mais tempo ao atender a uma das seguintes condições:

  • [C-0-2] As implementações de dispositivos com Configuration.uiMode definido como UI_MODE_TYPE_WATCH PRECISAM ter um valor de proporção definido como 1,0 (1:1).

7.1.1.3. Densidade da tela

O framework de IU do Android define um conjunto de densidades lógicas padrão para ajudar os desenvolvedores a segmentar os recursos do aplicativo.

  • [C-0-1] Por padrão, as implementações de dispositivo PRECISAM informar apenas uma das seguintes densidades lógicas do framework Android pela API DENSITY_DEVICE_STABLE, e esse valor PRECISA permanecer o mesmo. No entanto, o dispositivo PODE informar uma densidade arbitrária diferente de acordo com as mudanças de configuração de exibição feitas pelo usuário (por exemplo, tamanho da tela) definidas após a inicialização inicial.

    • 120 dpi (ldpi)
    • 160 dpi (mdpi)
    • 213 dpi (tvdpi)
    • 240 dpi (hdpi)
    • 260 dpi (260dpi)
    • 280 dpi (280dpi)
    • 300 dpi (300dpi)
    • 320 dpi (xhdpi)
    • 340 dpi (340dpi)
    • 360 dpi (360dpi)
    • 400 dpi (400dpi)
    • 420 dpi (420dpi)
    • 480 dpi (xxhdpi)
    • 560 dpi (560dpi)
    • 640 dpi (xxxhdpi)

  • As implementações de dispositivos DEVEM definir a densidade padrão do framework do Android que é numericamente mais próxima da densidade física da tela, a menos que essa densidade lógica reduza o tamanho da tela informado abaixo do mínimo suportado. Se a densidade do framework padrão do Android que é numericamente mais próxima da densidade física resultar em um tamanho de tela menor do que o menor tamanho de tela compatível com suporte (largura de 320 dp), as implementações de dispositivo VÃO PRECISAR informar a próxima densidade padrão mais baixa do framework do Android.

Se houver uma affordance para mudar o tamanho da tela do dispositivo:

  • [C-1-1] O tamanho da tela NÃO PODE ser dimensionado em mais de 1,5 vezes a densidade nativa ou produzir uma dimensão mínima de tela menor que 320 dp (equivalente ao qualificador de recursos sw320dp), o que ocorrer primeiro.
  • [C-1-2] O tamanho da tela NÃO PODE ser dimensionado para menos de 0,85 vezes a densidade nativa.
  • Para garantir uma boa usabilidade e tamanhos de fonte consistentes, é RECOMENDÁVEL que as seguintes opções de escalonamento de tela nativa sejam fornecidas (atendendo aos limites especificados acima):
  • Pequeno: 0,85x
  • Padrão: 1x (escala de exibição nativa)
  • Grande: 1,15x
  • Maior: 1,3x
  • Maior: 1,45x

7.1.2. Métricas de tela

Se as implementações de dispositivos incluem uma saída de tela ou vídeo, elas:

  • [C-1-1] É OBRIGATÓRIO informar os valores corretos para todas as métricas de exibição definidas na API android.util.DisplayMetrics.

Se as implementações de dispositivos não incluírem uma tela ou saída de vídeo incorporada, elas:

  • [C-2-1] É OBRIGATÓRIO informar valores razoáveis para todas as métricas de exibição definidas na API android.util.DisplayMetrics para o view.Display padrão emulado.

7.1.3. Orientação da tela

Implementações de dispositivos:

  • [C-0-1] É OBRIGATÓRIO informar quais orientações de tela são compatíveis (android.hardware.screen.portrait e/ou android.hardware.screen.landscape) e é OBRIGATÓRIO informar pelo menos uma orientação compatível. Por exemplo, um dispositivo com uma tela de paisagem de orientação fixa, como uma televisão ou um laptop, DEVE informar apenas android.hardware.screen.landscape.
  • [C-0-2] É OBRIGATÓRIO informar o valor correto da orientação atual do dispositivo sempre que ele for consultado pela android.content.res.Configuration.orientation, android.view.Display.getOrientation() ou outras APIs.

Se as implementações do dispositivo oferecerem suporte às duas orientações da tela, elas:

  • [C-1-1] É PRECISO oferecer suporte à orientação dinâmica por aplicativos para orientação de tela em modo retrato ou paisagem. Ou seja, o dispositivo precisa respeitar a solicitação do aplicativo para uma orientação de tela específica.
  • [C-1-2] O tamanho ou a densidade da tela NÃO PODEM mudar quando a orientação é alterada.
  • PODE selecionar a orientação retrato ou paisagem como padrão.

7.1.4. Aceleração gráfica 2D e 3D

7.1.4.1 OpenGL ES

Implementações de dispositivos:

  • [C-0-1] É PRECISO identificar corretamente as versões do OpenGL ES com suporte (1.1, 2.0, 3.0, 3.1, 3.2) pelas APIs gerenciadas (como pelo método GLES10.getString()) e pelas APIs nativas.
  • [C-0-2] É PRECISO incluir o suporte a todas as APIs gerenciadas e nativas correspondentes para todas as versões do OpenGL ES identificadas.

Se as implementações de dispositivos incluem uma saída de tela ou vídeo, elas:

  • [C-1-1] PRECISA oferecer suporte ao OpenGL ES 1.0 e 2.0, conforme descrito e detalhado na documentação do SDK do Android.
  • [SR] são ALTAMENTE RECOMENDADOS para oferecer suporte ao OpenGL ES 3.0.
  • DEVE ser compatível com o OpenGL ES 3.1 ou 3.2.

Se as implementações do dispositivo forem compatíveis com qualquer uma das versões do OpenGL ES, elas:

  • [C-2-1] É OBRIGATÓRIO informar, pelas APIs gerenciadas e nativas do OpenGL ES, quaisquer outras extensões do OpenGL ES implementadas. Por outro lado, NÃO é permitido informar strings de extensão que não sejam compatíveis.
  • [C-2-2] É PRECISO oferecer suporte às extensões EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage e EGL_ANDROID_recordable.
  • [SR] é ALTAMENTE RECOMENDADO oferecer suporte a EGL_KHR_partial_update.
  • DEVE informar com precisão, pelo método getString(), qualquer formato de compactação de textura compatível, que geralmente é específico do fornecedor.

Se as implementações do dispositivo declararem suporte ao OpenGL ES 3.0, 3.1 ou 3.2, elas:

  • [C-3-1] É OBRIGATÓRIO exportar os símbolos de função correspondentes para essas versões, além dos símbolos de função OpenGL ES 2.0 na biblioteca libGLESv2.so.

Se as implementações do dispositivo oferecem suporte ao OpenGL ES 3.2, elas:

  • [C-4-1] É PRECISO oferecer suporte ao pacote de extensão OpenGL ES para Android na íntegra.

Se as implementações do dispositivo oferecerem suporte ao pacote de extensões para Android do OpenGL ES, elas:

  • [C-5-1] É PRECISO identificar o suporte usando a flag de recurso android.hardware.opengles.aep.

Se as implementações de dispositivos oferecerem suporte à extensão EGL_KHR_mutable_render_buffer, elas:

  • [C-6-1] É necessário ter suporte à extensão EGL_ANDROID_front_buffer_auto_refresh.
7.1.4.2 Vulkan

O Android inclui suporte para a Vulkan, uma API multiplataforma de baixa sobrecarga para gráficos 3D de alto desempenho.

Se as implementações do dispositivo forem compatíveis com o OpenGL ES 3.0 ou 3.1, elas:

  • [SR] É ALTAMENTE RECOMENDADO incluir suporte ao Vulkan 1.0 .

Se as implementações de dispositivos incluem uma saída de tela ou vídeo, elas:

  • DEVE incluir suporte ao Vulkan 1.0.

Implementações de dispositivos, se incluir suporte ao Vulkan 1.0:

  • [C-1-1] DEVE informar o valor inteiro correto com as flags de recursos android.hardware.vulkan.level e android.hardware.vulkan.version.
  • [C-1-2] É PRECISO enumerar pelo menos um VkPhysicalDevice para a API nativa do Vulkan vkEnumeratePhysicalDevices() .
  • [C-1-3] É PRECISO implementar totalmente as APIs Vulkan 1.0 para cada VkPhysicalDevice enumerado.
  • [C-1-4] É PRECISO enumerar camadas, contidas em bibliotecas nativas nomeadas como libVkLayer*.so no diretório de biblioteca nativa do pacote de aplicativos, pelas APIs nativas do Vulkan vkEnumerateInstanceLayerProperties() e vkEnumerateDeviceLayerProperties() .
  • [C-1-5] NÃO É PERMITIDO enumerar camadas fornecidas por bibliotecas fora do pacote do aplicativo ou fornecer outras maneiras de rastrear ou interceptar a API Vulkan, a menos que o aplicativo tenha o atributo android:debuggable definido como true.
  • [C-1-6] É OBR informar todas as strings de extensão com suporte pelas APIs nativas do Vulkan e, inversamente, NÃO informar strings de extensão sem suporte.

Implementações de dispositivos, se não incluir suporte ao Vulkan 1.0:

  • [C-2-1] NÃO declarar nenhuma das flags de recursos do Vulkan (por exemplo, android.hardware.vulkan.level, android.hardware.vulkan.version).
  • [C-2-2] NÃO É PERMITIDO enumerar nenhum VkPhysicalDevice para a vkEnumeratePhysicalDevices() da API nativa do Vulkan.
7.1.4.3 RenderScript
  • [C-0-1] As implementações de dispositivos PRECISAM oferecer suporte ao Android RenderScript, conforme detalhado na documentação do SDK do Android.
7.1.4.4 Aceleração gráfica 2D

O Android inclui um mecanismo para que os aplicativos declarem que querem ativar a aceleração de hardware para gráficos 2D no nível do aplicativo, da atividade, da janela ou da visualização usando uma tag de manifesto android:hardwareAccelerated ou chamadas diretas de API.

Implementações de dispositivos:

  • [C-0-1] PRECISA ativar a aceleração de hardware por padrão e PRECISA desativar a aceleração de hardware se o desenvolvedor solicitar isso definindo android:hardwareAccelerated="false" ou desativando a aceleração de hardware diretamente pelas APIs View do Android.
  • [C-0-2] PRECISA apresentar um comportamento consistente com a documentação do SDK do Android sobre aceleração de hardware.

O Android inclui um objeto TextureView que permite que os desenvolvedores integrem diretamente texturas OpenGL ES aceleradas por hardware como destinos de renderização em uma hierarquia de interface.

Implementações de dispositivos:

  • [C-0-3] PRECISA oferecer suporte à API TextureView e PRECISA apresentar um comportamento consistente com a implementação upstream do Android.
7.1.4.5 Telas de ampla gama

Se as implementações de dispositivos declararem suporte a telas de ampla gama de cores usando Configuration.isScreenWideColorGamut() , elas:

  • [C-1-1] PRECISA ter uma tela com calibração de cores.
  • [C-1-2] É OBRIGATÓRIO ter uma tela com uma gama que cubra a gama de cores sRGB totalmente no espaço CIE 1931 xyY.
  • [C-1-3] É OBR ter uma tela com uma gama de pelo menos 90% do NTSC 1953 no espaço CIE 1931 xyY.
  • [C-1-4] PRECISA oferecer suporte ao OpenGL ES 3.0, 3.1 ou 3.2 e informar corretamente.
  • [C-1-5] É PRECISO anunciar suporte para as extensões EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_colorspace_scrgb_linear e EGL_GL_colorspace_display_p3.
  • [SR] É ALTAMENTE RECOMENDADO oferecer suporte a GL_EXT_sRGB.

Por outro lado, se as implementações de dispositivos não oferecerem suporte a telas de ampla gama de cores, elas:

  • [C-2-1] DEVE abranger 100% ou mais de sRGB no espaço CIE 1931 xyY, embora a gama de cores da tela seja indefinida.

7.1.5. Modo de compatibilidade de aplicativos legados

O Android especifica um "modo de compatibilidade" em que o framework opera em um modo equivalente ao tamanho de tela "normal" (largura de 320 dp) para beneficiar aplicativos legados que não foram desenvolvidos para versões antigas do Android que antecedem a independência do tamanho da tela.

7.1.6. Tecnologia da tela

A plataforma Android inclui APIs que permitem que os apps renderizem gráficos avançados na tela. Os dispositivos precisam oferecer suporte a todas essas APIs, conforme definido pelo SDK do Android, a menos que seja permitido especificamente neste documento.

Implementações de dispositivos:

  • [C-0-1] É PRECISO oferecer suporte a telas capazes de renderizar gráficos coloridos de 16 bits.
  • DEVE oferecer suporte a telas com gráficos coloridos de 24 bits.
  • [C-0-2] É PRECISO oferecer suporte a telas capazes de renderizar animações.
  • [C-0-3] É OBRIGATÓRIO usar a tecnologia de exibição com uma proporção de pixels (PAR) entre 0,9 e 1,15. Ou seja, a proporção de pixels PRECISA ser próxima de um quadrado (1,0) com uma tolerância de 10 a 15%.

7.1.7. Telas secundárias

O Android inclui suporte para tela secundária para ativar recursos de compartilhamento de mídia e APIs para desenvolvedores acessarem telas externas.

Se as implementações de dispositivos oferecerem suporte a uma tela externa por uma conexão de tela adicional integrada, com ou sem fio, elas:

  • [C-1-1] É PRECISO implementar o serviço de sistema e a API DisplayManager conforme descrito na documentação do SDK do Android.

7.2. Dispositivos de entrada

Implementações de dispositivos:

7.2.1. Teclado

Se as implementações de dispositivos incluírem suporte a aplicativos de Editor de método de entrada (IME) de terceiros, elas:

Implementações de dispositivos: [C-0-1] NÃO é permitido incluir um teclado de hardware que não corresponda a um dos formatos especificados em android.content.res.Configuration.keyboard (QWERTY ou 12 teclas). DEVE incluir outras implementações de teclado virtual. * PODE incluir um teclado de hardware.

7.2.2. Navegação sem toque

O Android inclui suporte para botão direcional, trackball e roda como mecanismos de navegação sem toque.

Implementações de dispositivos:

Se as implementações de dispositivos não tiverem navegações sem toque, elas:

  • [C-1-1] É OBRIGATÓRIO fornecer um mecanismo de interface do usuário alternativo razoável para a seleção e edição de texto, compatível com mecanismos de gerenciamento de entrada. A implementação de código aberto upstream do Android inclui um mecanismo de seleção adequado para uso com dispositivos que não têm entradas de navegação não por toque.

7.2.3. Teclas de navegação

As funções Início, Recentes e Voltar, normalmente fornecidas por uma interação com um botão físico dedicado ou uma parte distinta da tela touchscreen, são essenciais para o paradigma de navegação do Android e, portanto:

  • [C-0-1] É OBRIGATÓRIO fornecer a função "home".
  • DEVE fornecer botões para a função "Recentes" e "Voltar".

Se as funções "Início", "Recentes" ou "Voltar" forem fornecidas, elas:

  • [C-1-1] PRECISA ser acessível com uma única ação (por exemplo, toque, clique duplo ou gesto) quando qualquer uma delas for acessível.
  • [C-1-2] É PRECISO indicar claramente qual ação única aciona cada função. Exemplos de indicações são um ícone visível impresso no botão, um ícone de software mostrado na parte da barra de navegação da tela ou um fluxo de demonstração guiado passo a passo durante a experiência de configuração inicial.

Implementações de dispositivos:

  • [SR] É ALTAMENTE RECOMENDADO não fornecer o mecanismo de entrada para a função de menu, já que ela foi descontinuada em favor da barra de ações desde o Android 4.0.

Se as implementações do dispositivo oferecerem a função Menu, elas:

  • [C-2-1] PRECISA mostrar o botão de menu flutuante de ações sempre que o pop-up do menu flutuante de ações não estiver vazio e a barra de ações estiver visível.
  • [C-2-2] NÃO MODIFIQUE a posição do pop-up de overflow de ação exibido ao selecionar o botão de overflow na barra de ações, mas PODE renderizar o pop-up de overflow de ação em uma posição modificada na tela quando ele é exibido ao selecionar a função de menu.

Se as implementações do dispositivo não fornecerem a função Menu, para compatibilidade com versões anteriores, elas: * [C-3-1] PRECISAM disponibilizar a função Menu para os aplicativos quando targetSdkVersion for menor que 10, seja por um botão físico, uma tecla de software ou gestos. Essa função de menu precisa ser acessível, a menos que esteja oculta com outras funções de navegação.

Se as implementações do dispositivo oferecerem a função Assist, elas: [C-4-1] TERÃO QUE tornar a função Assist acessível com uma única ação (por exemplo, toque, clique duplo ou gesto) quando outras teclas de navegação estiverem acessíveis. [SR] É ALTAMENTE RECOMENDADO usar o toque e a manutenção pressionado na função HOME como esta interação designada.

Se as implementações do dispositivo usarem uma parte distinta da tela para mostrar as teclas de navegação, elas:

  • [C-5-1] As teclas de navegação PRECISAM usar uma parte distinta da tela, que não está disponível para aplicativos, e NÃO PODEM obscurecer ou interferir de outra forma na parte da tela disponível para aplicativos.
  • [C-5-2] PRECISA disponibilizar uma parte da tela para aplicativos que atendam aos requisitos definidos na seção 7.1.1.
  • [C-5-3] É OBRIGATÓRIO respeitar as flags definidas pelo app pelo método da API View.setSystemUiVisibility(), para que essa parte distinta da tela (também conhecida como barra de navegação) seja oculta corretamente, conforme documentado no SDK.

7.2.4. Entrada por touchscreen

O Android oferece suporte a vários sistemas de entrada de ponteiro, como telas e trackpads touch, além de dispositivos de entrada touch falsos. As implementações de dispositivos com tela touchscreen são associadas a uma tela de modo que o usuário tem a impressão de manipular itens diretamente na tela. Como o usuário toca diretamente na tela, o sistema não exige recursos adicionais para indicar os objetos que estão sendo manipulados.

Implementações de dispositivos:

  • DEVE ter um sistema de entrada de ponteiro de algum tipo (semelhante a um mouse ou por toque).
  • DEVE oferecer suporte a ponteiros rastreados de forma totalmente independente.

Se as implementações do dispositivo incluem uma tela touchscreen (single-touch ou melhor), elas:

  • [C-1-1] É OBRIGATÓRIO informar TOUCHSCREEN_FINGER para o campo da API Configuration.touchscreen.
  • [C-1-2] É OBRIGATÓRIO informar os flags de recursos android.hardware.touchscreen e android.hardware.faketouch.

Se as implementações de dispositivo incluem uma tela touchscreen que pode rastrear mais de um toque, elas:

  • [C-2-1] É OBRIGATÓRIO informar as flags de recursos adequadas android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand correspondentes ao tipo de tela touchscreen específica no dispositivo.

Se as implementações do dispositivo não incluírem uma tela touchscreen (e dependerem apenas de um dispositivo de ponteiro) e atenderem aos requisitos de toque simulado na seção 7.2.5, elas:

  • [C-3-1] NÃO DEVE informar nenhuma flag de recurso que comece com android.hardware.touchscreen e DEVE informar apenas android.hardware.faketouch.

7.2.5. Entrada por toque falsa

A interface de toque simulada fornece um sistema de entrada do usuário que aproxima um subconjunto de recursos de tela touchscreen. Por exemplo, um mouse ou controle remoto que aciona um cursor na tela se aproxima do toque, mas exige que o usuário primeiro aponte ou foque e depois clique. Vários dispositivos de entrada, como mouse, trackpad, mouse aéreo com giroscópio, ponteiro com giroscópio, joystick e trackpad multitoque, podem oferecer suporte a interações de toque falsas. O Android inclui a constante de recurso android.hardware.faketouch, que corresponde a um dispositivo de entrada não por toque (baseado em ponteiro) de alta fidelidade, como um mouse ou trackpad que pode emular adequadamente a entrada por toque (incluindo suporte a gestos básicos) e indica que o dispositivo oferece suporte a um subconjunto emulado de recursos da tela touchscreen.

Se as implementações de dispositivos não incluem uma tela touchscreen, mas incluem outro sistema de entrada de ponteiro que querem disponibilizar, elas:

  • DEVE declarar suporte à flag de recurso android.hardware.faketouch.

Se as implementações de dispositivos declararem suporte a android.hardware.faketouch, elas:

  • [C-1-1] É OBRIGATÓRIO informar as posições absolutas X e Y da tela do local do ponteiro e exibir um ponteiro visual na tela.
  • [C-1-2] É OBRIGATÓRIO informar o evento de toque com o código de ação que especifica a mudança de estado que ocorre no ponteiro descendo ou subindo na tela.
  • [C-1-3] É PRECISO oferecer suporte ao ponteiro para baixo e para cima em um objeto na tela, o que permite que os usuários simulem o toque em um objeto na tela.
  • [C-1-4] É PRECISO oferecer suporte ao ponteiro para baixo, ponteiro para cima, ponteiro para baixo e ponteiro para cima no mesmo local em um objeto na tela dentro de um limite de tempo, o que permite que os usuários emulem o toque duplo em um objeto na tela.
  • [C-1-5] É PRECISO oferecer suporte ao ponteiro para baixo em um ponto arbitrário na tela, movimento do ponteiro para qualquer outro ponto arbitrário na tela, seguido por um ponteiro para cima, o que permite que os usuários emulem um toque de arrasto.
  • [C-1-6] É PRECISO oferecer suporte ao ponteiro para baixo e permitir que os usuários movam rapidamente o objeto para uma posição diferente na tela e, em seguida, o ponteiro para cima na tela, o que permite que os usuários joguem um objeto na tela.
  • [C-1-7] É OBRIGATÓRIO informar TOUCHSCREEN_NOTOUCH para o campo da API Configuration.touchscreen.

Se as implementações de dispositivos declararem suporte a android.hardware.faketouch.multitouch.distinct, elas:

  • [C-2-1] É PRECISO declarar suporte para android.hardware.faketouch.
  • [C-2-2] É PRECISO oferecer suporte a rastreamento distinto de duas ou mais entradas de ponteiro independentes.

Se as implementações de dispositivos declararem suporte a android.hardware.faketouch.multitouch.jazzhand, elas:

  • [C-3-1] É PRECISO declarar suporte para android.hardware.faketouch.
  • [C-3-2] É NECESSÁRIO oferecer suporte a rastreamento distinto de 5 (rastreamento de uma mão de dedos) ou mais entradas de ponteiro de forma totalmente independente.

7.2.6. Suporte a controles de jogos

7.2.6.1. Mapeamentos de botões

Se as implementações do dispositivo declararem a flag de recurso android.hardware.gamepad, elas: [C-1-1] TERÃO que incorporar um controlador ou enviar com um controlador separado na caixa, que forneceria meios para inserir todos os eventos listados nas tabelas abaixo. [C-1-2] PRECISA ser capaz de mapear eventos HID para as constantes view.InputEvent do Android associadas, conforme listado nas tabelas abaixo. A implementação upstream do Android inclui a implementação para controles de jogos que atende a esse requisito.

Botão Uso do HID2 Botão do Android
A1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 0x09 0x0004 KEYCODE_BUTTON_X (99)
Y1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
Botão direcional para cima1
Botão direcional para baixo1 		0x01 0x00393 AXIS_HAT_Y4
D-pad para a esquerda1
D-pad para a direita1 		0x01 0x00393 AXIS_HAT_X4
Botão de ombro esquerdo1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
Botão de ombro direito1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
Clique no botão esquerdo1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
Clique no botão direito1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
Início1 0x0c 0x0223 KEYCODE_HOME (3)
Voltar1 0x0c 0x0224 KEYCODE_BACK (4)

1 KeyEvent

2 Os usos de HID acima precisam ser declarados em uma CA de gamepad (0x01 0x0005).

3 Esse uso precisa ter um mínimo lógico de 0, um máximo lógico de 7, um mínimo físico de 0, um máximo físico de 315, unidades em graus e um tamanho de relatório de 4. O valor lógico é definido como a rotação no sentido horário para longe do eixo vertical. Por exemplo, um valor lógico de 0 representa nenhuma rotação e o botão para cima pressionado, enquanto um valor lógico de 1 representa uma rotação de 45 graus e as teclas para cima e esquerda pressionadas.

4 MotionEvent

Controles analógicos1 Uso de HID Botão do Android
Gatilho esquerdo 0x02 0x00C5 AXIS_LTRIGGER
Gatilhos direito 0x02 0x00C4 AXIS_RTRIGGER
Joystick esquerdo 0x01 0x0030
0x01 0x0031 		AXIS_X
AXIS_Y
Joystick direito 0x01 0x0032
0x01 0x0035 		AXIS_Z
AXIS_RZ

1 MotionEvent

7.2.7. Controle remoto

Consulte a Seção 2.3.1 para ver os requisitos específicos do dispositivo.

7.3. Sensores

Se as implementações de dispositivo incluem um tipo de sensor específico que tem uma API correspondente para desenvolvedores terceirizados, a implementação do dispositivo PRECISA implementar essa API conforme descrito na documentação do SDK do Android e na documentação do Android Open Source sobre sensores.

Implementações de dispositivos:

  • [C-0-1] É PRECISO informar com precisão a presença ou ausência de sensores por classe android.content.pm.PackageManager.
  • [C-0-2] PRECISA retornar uma lista precisa dos sensores compatíveis usando SensorManager.getSensorList() e métodos semelhantes.
  • [C-0-3] PRECISA se comportar de maneira razoável para todas as outras APIs de sensor (por exemplo, retornando true ou false conforme apropriado quando os aplicativos tentam registrar listeners, não chamando listeners de sensor quando os sensores correspondentes não estão presentes etc.).

Se as implementações de dispositivo incluírem um tipo de sensor específico que tenha uma API correspondente para desenvolvedores terceirizados, elas:

  • [C-1-1] É OBRIGATÓRIO informar todas as medições do sensor usando os valores relevantes do Sistema Internacional de Unidades (métrico) para cada tipo de sensor, conforme definido na documentação do SDK do Android.
  • [C-1-2] É OBRIGATÓRIO informar os dados do sensor com uma latência máxima de 100 milissegundos
  • 2 * sample_time para o caso de um sensor transmitido com uma latência mínima necessária de 5 ms + 2 * sample_time quando o processador do aplicativo está ativo. Esse atraso não inclui atrasos de filtragem.
  • [C-1-3] É OBRIGATÓRIO informar a primeira amostra do sensor em 400 milissegundos + 2 * sample_time do sensor sendo ativado. É aceitável que essa amostra tenha uma precisão de 0.

  • [SR] DEVE informar o horário do evento em nanossegundos, conforme definido na documentação do SDK do Android, representando o horário em que o evento ocorreu e sincronizado com o relógio SystemClock.elapsedRealtimeNano(). É FORTEMENTE RECOMENDADO que os dispositivos Android atuais e novos atendam a esses requisitos para que possam ser atualizados para as versões futuras da plataforma, em que esse componente pode se tornar OBRIGATÓRIO. O erro de sincronização DEVE ser inferior a 100 milissegundos.

  • [C-1-4] Para que qualquer API indicada pela documentação do SDK do Android seja um sensor contínuo, as implementações de dispositivos precisam fornecer continuamente amostras de dados periódicos que precisam ter um jitter abaixo de 3%, em que o jitter é definido como a variação padrão da diferença dos valores de carimbo de data/hora informados entre eventos consecutivos.

  • [C-1-5] É PRECISO garantir que o stream de eventos do sensor NÃO impeça a CPU do dispositivo de entrar em um estado de suspensão ou de sair dele.

  • Quando vários sensores são ativados, o consumo de energia NÃO DEVE exceder a soma do consumo de energia informado pelo sensor individual.

A lista acima não é abrangente. O comportamento documentado do SDK do Android e da documentação de código aberto do Android sobre sensores é considerado oficial.

Alguns tipos de sensores são compostos, ou seja, podem ser derivados de dados fornecidos por um ou mais outros sensores. Por exemplo, o sensor de orientação e o sensor de aceleração linear.

Implementações de dispositivos:

  • IMPLEMENTAR esses tipos de sensores, quando eles incluem os sensores físicos necessários, conforme descrito em tipos de sensores.

Se as implementações do dispositivo incluírem um sensor composto, elas:

  • [C-2-1] É PRECISO implementar o sensor conforme descrito na documentação do Android Open Source sobre sensores compostos.

7.3.1. Acelerômetro

  • As implementações de dispositivos devem incluir um acelerômetro de três eixos.

Se as implementações do dispositivo incluírem um acelerômetro de três eixos, elas:

  • [C-1-1] É PRECISO que o sistema consiga informar eventos com frequência de pelo menos 50 Hz.
  • [C-1-2] É PRECISO implementar e informar o sensor TYPE_ACCELEROMETER.
  • [C-1-3] É OBRIGATÓRIO obedecer ao sistema de coordenadas do sensor Android, conforme detalhado nas APIs do Android.
  • [C-1-4] É PRECISO medir a queda livre até quatro vezes a gravidade(4g) ou mais em qualquer eixo.
  • [C-1-5] PRECISA ter uma resolução de pelo menos 12 bits.
  • [C-1-6] É OBRIGATÓRIO ter uma variação padrão não superior a 0,05 m/s^, em que a variação padrão precisa ser calculada por eixo em amostras coletadas durante um período de pelo menos 3 segundos na taxa de amostragem mais rápida.
  • [SR] É ALTAMENTE RECOMENDADO implementar o sensor composto TYPE_SIGNIFICANT_MOTION.
  • [SR] É ALTAMENTE RECOMENDADO implementar o sensor TYPE_ACCELEROMETER_UNCALIBRATED se a calibração do acelerômetro on-line estiver disponível.
  • DEVE implementar os sensores compostos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR e TYPE_STEP_COUNTER conforme descrito no documento do SDK do Android.
  • DEVE informar eventos de até 200 Hz.
  • DEVE ter uma resolução de pelo menos 16 bits.
  • DEVEM ser calibrados durante o uso se as características mudarem ao longo do ciclo de vida e forem compensadas, e preservar os parâmetros de compensação entre as reinicializações do dispositivo.
  • DEVE ser compensada pela temperatura.
  • DEVE implementar o sensor TYPE_ACCELEROMETER_UNCALIBRATED.

Se as implementações do dispositivo incluírem um acelerômetro de três eixos e qualquer um dos sensores compostos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR e TYPE_STEP_COUNTER forem implementados:

  • [C-2-1] A soma do consumo de energia PRECISA ser sempre menor que 4 mW.
  • Cada um deve estar abaixo de 2 mW e 0,5 mW quando o dispositivo estiver em uma condição dinâmica ou estática.

Se as implementações do dispositivo incluem um acelerômetro de três eixos e um sensor de giroscópio, elas:

  • [C-3-1] É PRECISO implementar os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
  • DEVE implementar o sensor composto TYPE_GAME_ROTATION_VECTOR.
  • [SR] É ALTAMENTE RECOMENDADO que os dispositivos Android novos e atuais implementem o sensor TYPE_GAME_ROTATION_VECTOR.

Se as implementações do dispositivo incluem um acelerômetro de três eixos, um sensor de giroscópio e um sensor de magnetômetro, elas:

  • [C-4-1] É PRECISO implementar um sensor composto TYPE_ROTATION_VECTOR.

7.3.2. Magnetômetro

  • As implementações de dispositivos devem incluir um magnetômetro de três eixos (bússola).

Se as implementações do dispositivo incluírem um magnetômetro de três eixos, elas:

  • [C-1-1] É PRECISO implementar o sensor TYPE_MAGNETIC_FIELD.
  • [C-1-2] PRECISA ser capaz de informar eventos com frequência de pelo menos 10 Hz e DEVE informar eventos com frequência de pelo menos 50 Hz.
  • [C-1-3] É OBRIGATÓRIO obedecer ao sistema de coordenadas do sensor Android, conforme detalhado nas APIs do Android.
  • [C-1-4] É PRECISO medir entre -900 µT e +900 µT em cada eixo antes da saturação.
  • [C-1-5] É PRECISO ter um valor de deslocamento de ferro rígido menor que 700 µT e DEVE ter um valor abaixo de 200 µT, colocando o magnetômetro longe de campos magnéticos dinâmicos (induzidos por corrente) e estáticos (induzidos por ímã).
  • [C-1-6] PRECISA ter uma resolução igual ou mais densa que 0,6 µT.
  • [C-1-7] É PRECISO oferecer suporte à calibração on-line e compensação do viés de hardware e preservar os parâmetros de compensação entre reinicializações do dispositivo.
  • [C-1-8] A compensação de ferro macio PRECISA ser aplicada. A calibração pode ser feita durante o uso ou durante a produção do dispositivo.
  • [C-1-9] DEVE ter um desvio padrão, calculado por eixo em amostras coletadas durante um período de pelo menos 3 segundos na taxa de amostragem mais rápida, não superior a 1,5 µT. DEVE ter um desvio padrão não superior a 0,5 µT.
  • DEVE implementar o sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.
  • [SR] É ALTAMENTE RECOMENDADO que os dispositivos Android novos e atuais implementem o sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Se as implementações do dispositivo incluem um magnetômetro de três eixos, um sensor de acelerômetro e um sensor de giroscópio, elas:

  • [C-2-1] É PRECISO implementar um sensor composto TYPE_ROTATION_VECTOR.

Se as implementações do dispositivo incluírem um magnetômetro de três eixos, um acelerômetro, elas:

  • PODE implementar o sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Se as implementações do dispositivo incluem um magnetômetro de três eixos, um acelerômetro e um sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR, elas:

  • [C-3-1] PRECISA consumir menos de 10 mW.
  • DEVE consumir menos de 3 mW quando o sensor estiver registrado para o modo de lote a 10 Hz.

7.3.3. GPS

Implementações de dispositivos:

  • DEVE incluir um receptor de GPS/GNSS.

Se as implementações do dispositivo incluírem um receptor GPS/GNSS e informarem a capability para os aplicativos usando a flag de recurso android.hardware.location.gps, elas:

  • [C-1-1] É PRECISO oferecer suporte a saídas de localização com uma taxa de pelo menos 1 Hz quando solicitado por LocationManager#requestLocationUpdate.
  • [C-1-2] É PRECISO determinar o local em condições de céu aberto (sinais fortes, multicaminho desprezível, HDOP < 2) em até 10 segundos (tempo rápido para a primeira correção), quando conectado a uma conexão de Internet de dados de 0,5 Mbps ou mais rápida. Esse requisito geralmente é atendido pelo uso de alguma forma de técnica de GPS/GNSS assistida ou prevista para minimizar o tempo de bloqueio do GPS/GNSS. Os dados de assistência incluem horário de referência, localização de referência e efemérides/relógio do satélite.
    • [SR] Depois de fazer esse cálculo de localização, é ALTAMENTE RECOMENDADO que o dispositivo possa determinar a própria localização, em céu aberto, em até 10 segundos, quando as solicitações de localização forem reiniciadas, até uma hora após o cálculo inicial de localização, mesmo quando a solicitação subsequente for feita sem uma conexão de dados e/ou após um ciclo de energia.

  • Em condições de céu aberto, depois de determinar o local, enquanto estiver parado ou se movendo com menos de 1 metro por segundo ao quadrado de aceleração:

    • [C-1-3] É PRECISO determinar a localização em até 20 metros e a velocidade em até 0, 5 metro por segundo, pelo menos 95% do tempo.
    • [C-1-4] É necessário rastrear e informar simultaneamente pelo menos 8 satélites de uma constelação por meio de GnssStatus.Callback.
    • DEVE ser capaz de rastrear simultaneamente pelo menos 24 satélites de várias constelações (por exemplo, GPS + pelo menos um de Glonass, Beidou, Galileo).
    • [C-1-5] É OBRIGATÓRIO informar a geração da tecnologia GNSS pela API de teste "getGnssYearOfHardware".
    • [SR] Continuar a exibir saídas de localização de GPS/GNSS normais durante uma ligação de emergência.
    • [SR] Informar medições GNSS de todas as constelações rastreadas (conforme informado nas mensagens GnssStatus), exceto SBAS.
    • [SR] Relatório AGC e frequência da medição do GNSS.
    • [SR] Informar todas as estimativas de precisão (incluindo direção, velocidade e vertical) como parte de cada local do GPS.
    • [SR] É FORTEMENTE RECOMENDADO atender ao máximo possível dos requisitos obrigatórios adicionais para dispositivos que informam o ano "2016" ou "2017" pela API de teste LocationManager.getGnssYearOfHardware().

Se as implementações do dispositivo incluírem um receptor GPS/GNSS e informarem a capability para os aplicativos usando a flag de recurso android.hardware.location.gps, e a API de teste LocationManager.getGnssYearOfHardware() informar o ano "2016" ou mais recente, elas:

  • [C-2-1] É OBRIGATÓRIO informar as medições do GPS assim que elas forem encontradas, mesmo que um local calculado pelo GPS/GNSS ainda não tenha sido informado.
  • [C-2-2] É OBRIGATÓRIO informar as pseudodistâncias e as taxas de pseudodistância do GPS que, em condições de céu aberto após a determinação do local, enquanto estão parados ou se movem com menos de 0, 2 metro por segundo ao quadrado de aceleração, são suficientes para calcular a posição em até 20 metros e a velocidade em até 0, 2 metro por segundo, pelo menos 95% do tempo.

Se as implementações do dispositivo incluírem um receptor GPS/GNSS e informarem a capacidade para os aplicativos pela flag de recurso android.hardware.location.gps e a API de teste LocationManager.getGnssYearOfHardware() informar o ano "2017" ou mais recente, elas:

  • [C-3-1] É PRECISO continuar a fornecer saídas de localização de GPS/GNSS normais durante uma ligação de emergência.
  • [C-3-2] É OBRIGATÓRIO informar as medições do GNSS de todas as constelações rastreadas (conforme informado nas mensagens GnssStatus), exceto o SBAS.
  • [C-3-3] É OBRIGATÓRIO informar o AGC e a frequência da medição do GNSS.
  • [C-3-4] É OBRIGATÓRIO informar todas as estimativas de precisão (incluindo rumo, velocidade e vertical) como parte de cada local do GPS.

7.3.4. Giroscópio

Implementações de dispositivos:

  • DEVE incluir um giroscópio (sensor de mudança angular).
  • NÃO deve incluir um sensor de giroscópio, a menos que um acelerômetro de três eixos também seja incluído.

Se as implementações do dispositivo incluírem um giroscópio, elas:

  • [C-1-1] É PRECISO que o sistema consiga informar eventos com frequência de pelo menos 50 Hz.
  • [C-1-2] É OBRIGATÓRIO implementar o sensor TYPE_GYROSCOPE e também o sensor TYPE_GYROSCOPE_UNCALIBRATED.
  • [C-1-3] É PRECISO medir mudanças de orientação de até 1.000 graus por segundo.
  • [C-1-4] PRECISA ter uma resolução de 12 bits ou mais e DEVE ter uma resolução de 16 bits ou mais.
  • [C-1-5] É PRECISO compensar a temperatura.
  • [C-1-6] DEVE ser calibrado e compensado durante o uso e preservar os parâmetros de compensação entre as reinicializações do dispositivo.
  • [C-1-7] PRECISA ter uma variação não maior que 1e-7 rad^2 / s^2 por Hz (variância por Hz ou rad^2 / s). A variação pode variar com a taxa de amostragem, mas PRECISA ser limitada por esse valor. Em outras palavras, se você medir a variação do giroscópio com uma taxa de amostragem de 1 Hz, ela NÃO PODE ser maior que 1e-7 rad^2/s^2.
  • [SR] É ALTAMENTE RECOMENDADO que os dispositivos Android novos e atuais implementem o sensor SENSOR_TYPE_GYROSCOPE_UNCALIBRATED.
  • [SR] É ALTAMENTE RECOMENDÁVEL que o erro de calibração seja menor que 0,01 rad/s quando o dispositivo estiver parado à temperatura ambiente.
  • DEVE informar eventos de até 200 Hz.

Se as implementações do dispositivo incluem um giroscópio, um sensor de acelerômetro e um sensor de magnetômetro, elas:

  • [C-2-1] É PRECISO implementar um sensor composto TYPE_ROTATION_VECTOR.

Se as implementações do dispositivo incluem um giroscópio e um sensor de acelerômetro, elas:

  • [C-3-1] É PRECISO implementar os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
  • [SR] É ALTAMENTE RECOMENDADO que os dispositivos Android novos e atuais implementem o sensor TYPE_GAME_ROTATION_VECTOR.
  • DEVE implementar o sensor composto TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barômetro

  • As implementações de dispositivos devem incluir um barômetro (sensor de pressão do ar ambiente).

Se as implementações do dispositivo incluírem um barômetro, elas:

  • [C-1-1] É PRECISO implementar e informar o sensor TYPE_PRESSURE.
  • [C-1-2] É PRECISO enviar eventos a 5 Hz ou mais.
  • [C-1-3] É PRECISO compensar a temperatura.
  • [SR] É ALTAMENTE RECOMENDADO que você possa informar medições de pressão no intervalo de 300 a 1.100 hPa.
  • Deve ter uma precisão absoluta de 1hPa.
  • DEVE ter uma precisão relativa de 0,12 hPa em um intervalo de 20 hPa (o que equivale a uma precisão de cerca de 1 m em uma mudança de cerca de 200 m no nível do mar).

7.3.6. Termômetro

Implementações de dispositivos: podem incluir um termômetro ambiente (sensor de temperatura). PODE, mas NÃO DEVE incluir um sensor de temperatura da CPU.

Se as implementações do dispositivo incluem um termômetro ambiente (sensor de temperatura), elas:

  • [C-1-1] PRECISA ser definido como SENSOR_TYPE_AMBIENT_TEMPERATURE e PRECISA medir a temperatura ambiente (sala/cabine do veículo) de onde o usuário está interagindo com o dispositivo em graus Celsius.
  • [C-1-2] PRECISA ser definido como SENSOR_TYPE_TEMPERATURE.
  • [C-1-3] É OBRIGATÓRIO medir a temperatura da CPU do dispositivo.
  • [C-1-4] NÃO DEVE medir nenhuma outra temperatura.

O tipo de sensor SENSOR_TYPE_TEMPERATURE teve o uso suspenso no Android 4.0.

7.3.7. Fotômetro

  • As implementações de dispositivos PODEM incluir um fotômetro (sensor de luz ambiente).

7.3.8. Sensor de proximidade

  • As implementações de dispositivos PODEM incluir um sensor de proximidade.

Se as implementações do dispositivo incluírem um sensor de proximidade, elas:

  • [C-1-1] É OBRIGATÓRIO medir a proximidade de um objeto na mesma direção da tela. Ou seja, o sensor de proximidade PRECISA ser orientado para detectar objetos próximos à tela, já que a intenção principal desse tipo de sensor é detectar um telefone em uso pelo usuário. Se as implementações do dispositivo incluírem um sensor de proximidade com qualquer outra orientação, ele NÃO PODE ser acessível por essa API.
  • [C-1-2] PRECISA ter precisão de 1 bit ou mais.

7.3.9. Sensores de alta fidelidade

Se as implementações de dispositivos incluírem um conjunto de sensores de maior qualidade, conforme definido nesta seção, e os disponibilizarem para apps de terceiros, elas:

  • [C-1-1] É OBRIGATÓRIO identificar o capability usando a flag de recurso android.hardware.sensor.hifi_sensors.

Se as implementações do dispositivo declararem android.hardware.sensor.hifi_sensors, elas:

  • [C-2-1] É PRECISO ter um sensor TYPE_ACCELEROMETER que:

    • É PRECISO ter um intervalo de medição entre pelo menos -8 g e +8 g.
    • PRECISA ter uma resolução de medição de pelo menos 1024 LSB/G.
    • PRECISA ter uma frequência de medição mínima de 12,5 Hz ou inferior.
    • PRECISA ter uma frequência máxima de medição de 400 Hz ou mais.
    • Deve ter um ruído de medição não superior a 400 uG/√Hz.
    • É PRECISO implementar um formulário de desativação desse sensor com um recurso de buffer de pelo menos 3.000 eventos do sensor.
    • O consumo de energia em lote precisa ser de no máximo 3 mW.
    • DEVE ter uma estabilidade de viés de ruído estacionário de \<15 μg √Hz do conjunto de dados estático de 24 horas.
    • DEVE ter uma mudança de viés em relação à temperatura de ≤ +/- 1 mg / °C.
    • DEVE ter uma não linearidade de linha de melhor ajuste de ≤ 0,5% e uma mudança de sensibilidade em relação à temperatura de ≤ 0,03%/C°.
    • DEVE ter um espectro de ruído branco para garantir a qualificação adequada da integridade do ruído do sensor.

  • [C-2-2] É PRECISO ter um TYPE_ACCELEROMETER_UNCALIBRATED com os mesmos requisitos de qualidade do TYPE_ACCELEROMETER.

  • [C-2-3] É PRECISO ter um sensor TYPE_GYROSCOPE que:

    • PRECISA ter um intervalo de medição entre pelo menos -1000 e +1000 dps.
    • PRECISA ter uma resolução de medição de pelo menos 16 LSB/dps.
    • PRECISA ter uma frequência de medição mínima de 12,5 Hz ou inferior.
    • PRECISA ter uma frequência máxima de medição de 400 Hz ou mais.
    • Deve ter um ruído de medição não superior a 0,014°/s/√Hz.
    • DEVE ter uma estabilidade de viés estático de < 0,0002 °/s √Hz do conjunto de dados estático de 24 horas.
    • DEVE ter uma mudança de viés em relação à temperatura de ≤ +/- 0,05 °/ s / °C.
    • DEVE ter uma mudança de sensibilidade em relação à temperatura de ≤ 0,02% / °C.
    • DEVE ter uma não linearidade de linha de ajuste ideal de ≤ 0,2%.
    • DEVE ter uma densidade de ruído de ≤ 0,007 °/s/√Hz.
    • DEVE ter um espectro de ruído branco para garantir a qualificação adequada da integridade do ruído do sensor.
    • DEVE ter um erro de calibração menor que 0,002 rad/s na faixa de temperatura de 10 a 40 ℃ quando o dispositivo estiver parado.

  • [C-2-4] É PRECISO ter um TYPE_GYROSCOPE_UNCALIBRATED com os mesmos requisitos de qualidade do TYPE_GYROSCOPE.

  • [C-2-5] É PRECISO ter um sensor TYPE_GEOMAGNETIC_FIELD que:
    • PRECISA ter um intervalo de medição entre pelo menos -900 e +900 uT.
    • É PRECISO ter uma resolução de medição de pelo menos 5 LSB/uT.
    • PRECISA ter uma frequência de medição mínima de 5 Hz ou menor.
    • PRECISA ter uma frequência máxima de medição de 50 Hz ou mais.
    • Deve ter um ruído de medição não superior a 0,5 uT.
  • [C-2-6] É PRECISO ter um TYPE_MAGNETIC_FIELD_UNCALIBRATED com os mesmos requisitos de qualidade do TYPE_GEOMAGNETIC_FIELD e, além disso:
    • É PRECISO implementar um formulário sem ativação desse sensor com capacidade de buffer de pelo menos 600 eventos do sensor.
    • DEVE ter um espectro de ruído branco para garantir a qualificação adequada da integridade do ruído do sensor.
  • [C-2-7] É PRECISO ter um sensor TYPE_PRESSURE que:
    • PRECISA ter um intervalo de medição entre pelo menos 300 e 1.100 hPa.
    • PRECISA ter uma resolução de medição de pelo menos 80 LSB/hPa.
    • Deve ter uma frequência de medição mínima de 1 Hz ou inferior.
    • PRECISA ter uma frequência de medição máxima de 10 Hz ou mais.
    • O ruído de medição não pode exceder 2 Pa/√Hz.
    • É PRECISO implementar um formulário sem ativação desse sensor com um recurso de buffer de pelo menos 300 eventos do sensor.
    • O consumo de energia em lote precisa ser de no máximo 2 mW.
  • [C-2-8] É PRECISO ter um sensor TYPE_GAME_ROTATION_VECTOR que:
    • É PRECISO implementar um formulário sem ativação desse sensor com um recurso de buffer de pelo menos 300 eventos do sensor.
    • O consumo de energia em lote precisa ser de no máximo 4 mW.
  • [C-2-9] É PRECISO ter um sensor TYPE_SIGNIFICANT_MOTION que:
    • O consumo de energia DEVE ser de no máximo 0,5 mW quando o dispositivo estiver estático e de 1,5 mW quando estiver em movimento.
  • [C-2-10] É PRECISO ter um sensor TYPE_STEP_DETECTOR que:
    • É PRECISO implementar um formulário sem ativação desse sensor com capacidade de buffer de pelo menos 100 eventos do sensor.
    • O consumo de energia DEVE ser de no máximo 0,5 mW quando o dispositivo estiver estático e de 1,5 mW quando estiver em movimento.
    • O consumo de energia em lote precisa ser de no máximo 4 mW.
  • [C-2-11] É PRECISO ter um sensor TYPE_STEP_COUNTER que:
    • O consumo de energia DEVE ser de no máximo 0,5 mW quando o dispositivo estiver estático e de 1,5 mW quando estiver em movimento.
  • [C-2-12] É PRECISO ter um sensor TILT_DETECTOR que:
    • O consumo de energia DEVE ser de no máximo 0,5 mW quando o dispositivo estiver estático e de 1,5 mW quando estiver em movimento.
  • [C-2-13] O carimbo de data/hora do mesmo evento físico informado pelo acelerômetro, pelo sensor de giroscópio e pelo magnetômetro PRECISA estar a 2,5 milissegundos um do outro.
  • [C-2-14] É OBRIGATÓRIO ter carimbos de data/hora de eventos do sensor de giroscópio na mesma base de tempo que o subsistema da câmera e com um erro de até 1 milissegundo.
  • [C-2-15] É NECESSÁRIO enviar amostras para os aplicativos em até 5 milissegundos a partir do momento em que os dados estão disponíveis em qualquer um dos sensores físicos acima para o aplicativo.
  • [C-2-16] O consumo de energia não pode ser maior que 0,5 mW quando o dispositivo está estático e 2,0 mW quando o dispositivo está em movimento quando qualquer combinação dos seguintes sensores está ativada:
    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS
  • [C-2-17] PODE ter um sensor TYPE_PROXIMITY, mas, se estiver presente, PRECISA ter um recurso de buffer mínimo de 100 eventos do sensor.

Todos os requisitos de consumo de energia nesta seção não incluem o consumo de energia do processador do aplicativo. Ele inclui a energia consumida por toda a cadeia de sensores, incluindo o sensor, qualquer circuito de suporte, qualquer sistema de processamento de sensores dedicado etc.

Se as implementações de dispositivos incluem suporte a sensores diretos, elas:

  • [C-3-1] É OBRIGATÓRIO declarar corretamente o suporte a tipos de canal direto e nível de taxas de relatório direto usando as APIs isDirectChannelTypeSupported e getHighestDirectReportRateLevel.
  • [C-3-2] É PRECISO oferecer suporte a pelo menos um dos dois tipos de canal direto do sensor para todos os sensores que declaram suporte ao canal direto do sensor
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
  • DEVE oferecer suporte à geração de relatórios de eventos pelo canal direto do sensor para o sensor principal (variante sem ativação) dos seguintes tipos:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Sensor de impressão digital

Se as implementações do dispositivo incluem uma tela de bloqueio segura, elas:

  • DEVE incluir um sensor de impressão digital.

Se as implementações do dispositivo incluírem um sensor de impressão digital e disponibilizarem o sensor para apps de terceiros, elas:

  • [C-1-1] É PRECISO declarar suporte para o recurso android.hardware.fingerprint.
  • [C-1-2] É necessário implementar totalmente a API correspondente, conforme descrito na documentação do SDK do Android.
  • [C-1-3] A taxa de aceitação falsa PRECISA ser menor que 0,002%.
  • [C-1-4] É OBRIGATÓRIO limitar a taxa de tentativas por pelo menos 30 segundos após cinco tentativas falsas de verificação de impressão digital.
  • [C-1-5] É OBRIGATÓRIO ter uma implementação de keystore com suporte de hardware e realizar a correspondência de impressão digital em um ambiente de execução confiável (TEE) ou em um chip com um canal seguro para o TEE.
  • [C-1-6] É OBRIGATÓRIO que todos os dados de impressão digital identificáveis sejam criptografados e autenticados criptograficamente para que não possam ser adquiridos, lidos ou alterados fora do ambiente de execução confiável (TEE), conforme documentado nas diretrizes de implementação no site do Projeto Android Open Source.
  • [C-1-7] É PRECISO impedir a adição de uma impressão digital sem primeiro estabelecer uma cadeia de confiança, fazendo com que o usuário confirme a credencial de dispositivo (PIN/padrão/senha) atual ou adicione uma nova (PIN/padrão/senha) protegida pelo TEE. A implementação do Projeto Android Open Source fornece o mecanismo no framework para fazer isso.
  • [C-1-8] NÃO É PERMITIDO permitir que aplicativos de terceiros distingam impressões digitais individuais.
  • [C-1-9] É PRECISO honrar a flag DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
  • [C-1-10] Ao fazer upgrade de uma versão anterior ao Android 6.0, os dados de impressão digital PRECISAM ser migrados com segurança para atender aos requisitos acima ou removidos.
  • [SR] É ALTAMENTE RECOMENDADO ter uma taxa de rejeição falsa de menos de 10%, conforme medido no dispositivo.
  • [SR] É ALTAMENTE RECOMENDADO ter uma latência abaixo de 1 segundo, medida desde o momento em que o sensor de impressão digital é tocado até a tela ser desbloqueada, para um dedo registrado.
  • DEVE usar o ícone de impressão digital do Android fornecido no Android Open Source Project.

7.3.11. Sensores exclusivos do Android Automotive

Os sensores específicos para automóveis são definidos no android.car.CarSensorManager API.

7.3.11.1. Engrenagem atual

Consulte a Seção 2.5.1 para ver os requisitos específicos do dispositivo.

7.3.11.2. Modo dia/noite

Consulte a Seção 2.5.1 para ver os requisitos específicos do dispositivo.

7.3.11.3. Status de condução

Consulte a Seção 2.5.1 para ver os requisitos específicos do dispositivo.

7.3.11.4. Velocidade da roda

Consulte a Seção 2.5.1 para ver os requisitos específicos do dispositivo.

7.3.12. Sensor de pose

Implementações de dispositivos:

  • PODE oferecer suporte ao sensor de pose com seis graus de liberdade.

Se as implementações de dispositivos oferecerem suporte ao sensor de pose com seis graus de liberdade, elas:

  • [C-1-1] É PRECISO implementar e informar o sensor TYPE_POSE_6DOF.
  • [C-1-2] PRECISA ser mais preciso do que o vetor de rotação sozinho.

7.4. Conectividade de dados

7.4.1. Telefonia

"Telefonia", conforme usado pelas APIs do Android e neste documento, se refere especificamente ao hardware relacionado a fazer chamadas de voz e enviar mensagens SMS por uma rede GSM ou CDMA. Embora essas chamadas de voz possam ou não ser comutadas por pacotes, elas são consideradas independentes de qualquer conectividade de dados que possa ser implementada usando a mesma rede. Em outras palavras, a funcionalidade e as APIs de "telefonia" do Android se referem especificamente a chamadas de voz e SMS. Por exemplo, implementações de dispositivos que não podem fazer chamadas ou enviar/receber mensagens SMS não são consideradas dispositivos de telefonia, mesmo que usem uma rede celular para conectividade de dados.

  • O Android PODE ser usado em dispositivos que não incluem hardware de telefonia. Ou seja, o Android é compatível com dispositivos que não são smartphones.

Se as implementações de dispositivos incluem telefonia GSM ou CDMA, elas:

  • [C-1-1] É OBRIGATÓRIO declarar a flag de recurso android.hardware.telephony e outras flags de subrecurso de acordo com a tecnologia.
  • [C-1-2] É PRECISO implementar suporte total à API para essa tecnologia.

Se as implementações de dispositivos não incluírem hardware de telefonia, elas:

  • [C-2-1] É OBRIGATÓRIO implementar as APIs completas como no-ops.
7.4.1.1. Compatibilidade com o bloqueio de números

Se as implementações de dispositivos informarem o android.hardware.telephony feature, elas:

  • [C-1-1] É PRECISO incluir suporte ao bloqueio de números
  • [C-1-2] É PRECISO implementar totalmente BlockedNumberContract e a API correspondente, conforme descrito na documentação do SDK.
  • [C-1-3] É OBRIGATÓRIO bloquear todas as ligações e mensagens de um número de telefone em "BlockedNumberProvider" sem nenhuma interação com apps. A única exceção é quando o bloqueio de número é temporariamente suspenso, conforme descrito na documentação do SDK.
  • [C-1-4] NÃO É PERMITIDO gravar no provedor de registro de chamadas da plataforma para uma chamada bloqueada.
  • [C-1-5] NÃO DEVE gravar no provedor de telefonia para uma mensagem bloqueada.
  • [C-1-6] É PRECISO implementar uma interface de gerenciamento de números bloqueados, que é aberta com a intent retornada pelo método TelecomManager.createManageBlockedNumbersIntent().
  • [C-1-7] NÃO DEVE permitir que usuários secundários visualizem ou editem os números bloqueados no dispositivo, já que a plataforma Android assume que o usuário principal tem controle total dos serviços de telefonia, uma única instância, no dispositivo. Toda a interface relacionada ao bloqueio PRECISA ser oculta para usuários secundários, e a lista de bloqueios PRECISA ser respeitada.
  • DEVE migrar os números bloqueados para o provedor quando um dispositivo for atualizado para o Android 7.0.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementações de dispositivos:

  • DEVE incluir suporte a uma ou mais formas de 802.11.

Se as implementações de dispositivos incluírem suporte a 802.11 e exporem a funcionalidade a um aplicativo de terceiros, elas:

  • [C-1-1] É PRECISO implementar a API Android correspondente.
  • [C-1-2] É OBRIGATÓRIO informar a flag de recurso de hardware android.hardware.wifi.
  • [C-1-3] É OBRIGATÓRIO implementar a API multicast conforme descrito na documentação do SDK.
  • [C-1-4] É PRECISO oferecer suporte a DNS multicast (mDNS) e NÃO filtrar pacotes mDNS (224.0.0.251) em nenhum momento da operação, incluindo:
    • Mesmo quando a tela não está em um estado ativo.
    • Para implementações de dispositivos Android TV, mesmo em estados de energia em espera.
  • DEVE randomizar o endereço MAC de origem e o número de sequência dos frames de solicitação de sondagem, uma vez no início de cada verificação, enquanto a STA estiver desconectada.
    • Cada grupo de frames de solicitação de sondagem que compõem uma verificação deve usar um endereço MAC consistente (NÃO DEVE ser aleatório no meio de uma verificação).
    • O número de sequência da solicitação de sondagem precisa ser iterado normalmente (sequencialmente) entre as solicitações de sondagem em uma verificação
    • O número de sequência da solicitação de sondagem precisa ser aleatório entre a última solicitação de sondagem de uma varredura e a primeira solicitação de sondagem da próxima varredura.
  • DEVE permitir apenas os seguintes elementos de informação em frames de solicitação de sondagem, enquanto a STA estiver desconectada:
    • Conjunto de parâmetros SSID (0)
    • Conjunto de parâmetros do DS (3)
7.4.2.1. Wi-Fi Direct

Implementações de dispositivos:

  • DEVE incluir suporte para Wi-Fi Direct (Wi-Fi ponto a ponto).

Se as implementações de dispositivos incluem suporte para Wi-Fi Direct, elas:

  • [C-1-1] É PRECISO implementar a API correspondente do Android, conforme descrito na documentação do SDK.
  • [C-1-2] É OBRIGATÓRIO informar o recurso de hardware android.hardware.wifi.direct.
  • [C-1-3] PRECISA ter suporte à operação regular de Wi-Fi.
  • DEVE oferecer suporte a operações de Wi-Fi e Wi-Fi Direct simultaneamente.

Implementações de dispositivos:

Se as implementações do dispositivo incluem suporte para TDLS e o TDLS é ativado pela API WiFiManager, elas:

  • [C-1-1] É PRECISO declarar suporte a TDLS por meio de WifiManager.isTdlsSupported.
  • Use TDLS apenas quando possível E benéfico.
  • DEVE ter alguma heurística e NÃO usar TDLS quando o desempenho for pior do que passar pelo ponto de acesso Wi-Fi.
7.4.2.3. Wi-Fi Aware

Implementações de dispositivos:

Se as implementações de dispositivos incluírem suporte ao Wi-Fi Aware e exporem a funcionalidade a apps de terceiros, elas:

  • [C-1-1] É OBRIGATÓRIO implementar as APIs WifiAwareManager conforme descrito na documentação do SDK.
  • [C-1-2] É OBRIGATÓRIO declarar a flag de recurso android.hardware.wifi.aware.
  • [C-1-3] É PRECISO oferecer suporte a operações do Wi-Fi e do Wi-Fi Aware simultaneamente.
  • [C-1-4] É PRECISO randomizar o endereço da interface de gerenciamento do Wi-Fi Aware em intervalos de até 30 minutos e sempre que o Wi-Fi Aware estiver ativado.
7.4.2.4. Passpoint do Wi-Fi

Implementações de dispositivos:

Se as implementações de dispositivos incluem suporte para Wi-Fi Passpoint, elas:

  • [C-1-1] É NECESSÁRIO implementar as APIs WifiManager relacionadas ao Passpoint conforme descrito na documentação do SDK.
  • [C-1-2] É PRECISO oferecer suporte ao padrão IEEE 802.11u, especificamente relacionado à descoberta e seleção de rede, como o serviço de publicidade genérica (GAS, na sigla em inglês) e o protocolo de consulta de rede de acesso (ANQP, na sigla em inglês).

Por outro lado, se as implementações de dispositivos não incluem suporte ao Wi-Fi Passpoint:

  • [C-2-1] A implementação das APIs WifiManager relacionadas ao Passpoint PRECISA gerar uma UnsupportedOperationException.

7.4.3. Bluetooth

Se as implementações do dispositivo oferecem suporte ao perfil de áudio Bluetooth, elas:

  • DEVE oferecer suporte a codecs de áudio avançados e Bluetooth (por exemplo, LDAC).

Se as implementações do dispositivo declararem o recurso android.hardware.vr.high_performance, elas:

  • [C-1-1] É PRECISO ter suporte a Bluetooth 4.2 e à extensão de comprimento de dados do Bluetooth LE.

O Android inclui suporte para Bluetooth e Bluetooth de baixa energia.

Se as implementações de dispositivos incluem suporte para Bluetooth e Bluetooth de baixa energia, elas:

  • [C-2-1] É OBRIGATÓRIO declarar os recursos relevantes da plataforma (android.hardware.bluetooth e android.hardware.bluetooth_le, respectivamente) e implementar as APIs da plataforma.
  • DEVE implementar perfis relevantes de Bluetooth, como A2DP, AVCP, OBEX etc., conforme apropriado para o dispositivo.

Se as implementações de dispositivos incluem suporte para Bluetooth de baixa energia, elas:

  • [C-3-1] É OBRIGATÓRIO declarar o recurso de hardware android.hardware.bluetooth_le.
  • [C-3-2] É OBRIGATÓRIO ativar as APIs Bluetooth baseadas em GATT (perfil de atributo genérico), conforme descrito na documentação do SDK e em android.bluetooth.
  • [C-3-3] É PRECISO informar o valor correto de BluetoothAdapter.isOffloadedFilteringSupported() para indicar se a lógica de filtragem para as classes da API ScanFilter está implementada.
  • [C-3-4] É OBRIGATÓRIO informar o valor correto de BluetoothAdapter.isMultipleAdvertisementSupported() para indicar se a publicidade de baixa energia é compatível.
  • DEVE oferecer suporte ao descarregamento da lógica de filtragem para o chipset Bluetooth ao implementar a API ScanFilter.
  • DEVE oferecer suporte ao descarregamento da verificação em lote para o chipset Bluetooth.

  • DEVE oferecer suporte a vários anúncios com pelo menos quatro slots.

  • [SR] É ALTAMENTE RECOMENDADO implementar um tempo limite de endereço particular solucionável (RPA) de no máximo 15 minutos e girar o endereço no tempo limite para proteger a privacidade do usuário.

7.4.4. Comunicação a curta distância (NFC)

Implementações de dispositivos:

  • DEVE incluir um transceptor e hardware relacionado para comunicação a curta distância (NFC).
  • [C-0-1] É OBRIGATÓRIO implementar as APIs android.nfc.NdefMessage e android.nfc.NdefRecord, mesmo que elas não incluam suporte a NFC ou declarem o recurso android.hardware.nfc, porque as classes representam um formato de representação de dados independente de protocolo.

Se as implementações de dispositivos incluírem hardware NFC e planejam disponibilizá-lo para apps de terceiros, elas:

  • [C-1-1] É OBRIGATÓRIO informar o recurso android.hardware.nfc do método android.content.pm.PackageManager.hasSystemFeature().
  • DEVE ser capaz de ler e gravar mensagens NDEF usando os seguintes padrões NFC:
  • [C-1-2] PRECISA ser capaz de atuar como leitor/gravador do NFC Forum (conforme definido pela especificação técnica do NFC Forum NFCForum-TS-DigitalProtocol-1.0) pelos seguintes padrões de NFC:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS X 6319-4)
    • IsoDep (ISO 14443-4)
    • Tipos de tag do NFC Forum 1, 2, 3, 4 e 5 (definidos pelo NFC Forum)

  • [SR] ALTAMENTE RECOMENDADO para ler e gravar mensagens NDEF, bem como dados brutos, usando os seguintes padrões de NFC. Embora os padrões de NFC sejam indicados como ALTAMENTE RECOMENDADOS, a definição de compatibilidade para uma versão futura está planejada para mudar para OBRIGATÓRIO. Esses padrões são opcionais nesta versão, mas serão obrigatórios em versões futuras. É altamente recomendável que os dispositivos atuais e novos que executam essa versão do Android atendam a esses requisitos agora para que possam fazer upgrade para as versões futuras da plataforma.

  • [C-1-3] É PRECISO transmitir e receber dados pelos seguintes padrões e protocolos ponto a ponto:

    • ISO 18092
    • LLCP 1.2 (definido pelo NFC Forum)
    • SDP 1.0 (definido pelo Fórum de NFC)
    • Protocolo NDEF Push
    • SNEP 1.0 (definido pelo NFC Forum)
  • [C-1-4] É PRECISO incluir suporte ao Android Beam e ATIVAR o Android Beam por padrão.
  • [C-1-5] É PRECISO enviar e receber usando o Android Beam quando ele estiver ativado ou outro modo P2P de NFC proprietário estiver ativado.
  • [C-1-6] É PRECISO implementar o servidor padrão do SNEP. Mensagens NDEF válidas recebidas pelo servidor SNEP padrão precisam ser enviadas aos apps usando a intent android.nfc.ACTION_NDEF_DISCOVERED. A desativação do Android Beam nas configurações NÃO deve desativar o envio de mensagens NDEF recebidas.
  • [C-1-7] É PRECISO honrar a intent android.settings.NFCSHARING_SETTINGS para mostrar as configurações de compartilhamento de NFC.
  • [C-1-8] É PRECISO implementar o servidor NPP. As mensagens recebidas pelo servidor NPP precisam ser processadas da mesma forma que o servidor padrão do SNEP.
  • [C-1-9] É PRECISO implementar um cliente SNEP e tentar enviar P2P NDEF de saída para o servidor SNEP padrão quando o Android Beam estiver ativado. Se nenhum servidor SNEP padrão for encontrado, o cliente PRECISA tentar enviar para um servidor NPP.
  • [C-1-10] É PRECISO permitir que as atividades em primeiro plano definam a mensagem NDEF P2P de saída usando android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback e android.nfc.NfcAdapter.enableForegroundNdefPush.
  • DEVE usar um gesto ou uma confirmação na tela, como "Tocar para transmitir", antes de enviar mensagens NDEF P2P de saída.
  • [C-1-11] É PRECISO oferecer suporte à transferência de conexão NFC para Bluetooth quando o dispositivo oferece suporte ao perfil de envio de objeto Bluetooth.
  • [C-1-12] É PRECISO oferecer suporte à transferência de conexão para Bluetooth ao usar android.nfc.NfcAdapter.setBeamPushUris, implementando as especificações Transferência de conexão versão 1.2 e Pareamento simples e seguro do Bluetooth usando a NFC versão 1.0 do NFC Forum. Essa implementação PRECISA implementar o serviço de transferência LLCP com o nome de serviço "urn:nfc:sn:handover" para trocar os registros de solicitação/seleção de transferência por NFC e PRECISA usar o perfil de envio de objeto Bluetooth para a transferência real de dados Bluetooth. Por motivos de compatibilidade com versões anteriores (para permanecer compatível com dispositivos Android 4.1), a implementação PRECISA aceitar solicitações SNEP GET para trocar os registros de solicitação de transferência/seleção por NFC. No entanto, uma implementação não deve enviar solicitações GET do SNEP para realizar a transferência de conexão.
  • [C-1-13] É PRECISO pesquisar todas as tecnologias com suporte no modo de descoberta de NFC.
  • DEVE estar no modo de descoberta de NFC enquanto o dispositivo está ativo com a tela ativa e a tela de bloqueio desbloqueada.
  • DEVE ser capaz de ler o código de barras e o URL (se codificado) dos produtos de código de barras NFC Thinfilm.

Os links disponíveis publicamente não estão disponíveis para as especificações do JIS, ISO e NFC Forum citadas acima.

O Android inclui suporte para o modo de emulação de cartão host (HCE) do NFC.

Se as implementações do dispositivo incluírem um chipset de controlador NFC compatível com HCE (para NfcA e/ou NfcB) e oferecerem suporte ao roteamento de ID do aplicativo (AID, na sigla em inglês), elas:

  • [C-2-1] É OBRIGATÓRIO informar a constante de recurso android.hardware.nfc.hce.
  • [C-2-2] É NECESSÁRIO oferecer suporte a APIs NFC HCE, conforme definido no SDK do Android.

Se as implementações de dispositivos incluírem um chipset de controlador NFC compatível com HCE para NfcF e implementarem o recurso para apps de terceiros, elas:

  • [C-3-1] É OBRIGATÓRIO informar a constante de recurso android.hardware.nfc.hcef.
  • [C-3-2] É OBRIGATÓRIO implementar as APIs de emulação de cartão NfcF conforme definido no SDK do Android.

Se as implementações do dispositivo incluírem suporte geral a NFC, conforme descrito nesta seção, e oferecerem suporte a tecnologias MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF no MIFARE Classic) na função de leitor/gravador, elas:

  • [C-4-1] É OBRIGATÓRIO implementar as APIs do Android correspondentes, conforme documentado pelo SDK do Android.
  • [C-4-2] É OBRIGATÓRIO informar o recurso com.nxp.mifare do método android.content.pm.PackageManager.hasSystemFeature(). Esse não é um recurso padrão do Android e, como tal, não aparece como uma constante na classe android.content.pm.PackageManager.

7.4.5. Capacidade mínima de rede

Implementações de dispositivos:

  • [C-0-1] É PRECISO incluir suporte a uma ou mais formas de rede de dados. Especificamente, as implementações de dispositivos precisam incluir suporte a pelo menos um padrão de dados com capacidade de 200 Kbit/s ou mais. Exemplos de tecnologias que atendem a esse requisito incluem EDGE, HSPA, EV-DO, 802.11g, Ethernet, Bluetooth PAN etc.
  • [C-0-2] É PRECISO incluir uma pilha de rede IPv6 e oferecer suporte à comunicação IPv6 usando as APIs gerenciadas, como java.net.Socket e java.net.URLConnection, bem como as APIs nativas, como soquetes AF_INET6.
  • [C-0-3] É OBRIGATÓRIO ativar o IPv6 por padrão.
  • Deve garantir que a comunicação IPv6 seja tão confiável quanto o IPv4, por exemplo.
  • [C-0-4] É PRECISO manter a conectividade IPv6 no modo de suspensão.
  • [C-0-5] A limitação de taxa NÃO PODE fazer com que o dispositivo perca a conectividade IPv6 em qualquer rede compatível com IPv6 que use tempos de vida de RA de pelo menos 180 segundos.
  • DEVE incluir suporte a pelo menos um padrão de dados sem fio comum, como 802.11 (Wi-Fi), quando um padrão de rede física (como Ethernet) é a conexão de dados principal
  • PODE implementar mais de uma forma de conectividade de dados.

O nível necessário de suporte ao IPv6 depende do tipo de rede, conforme descrito abaixo:

Se as implementações de dispositivos oferecem suporte a redes Wi-Fi, elas:

  • [C-1-1] É PRECISO oferecer suporte à operação de pilha dupla e somente IPv6 no Wi-Fi.

Se as implementações de dispositivos oferecerem suporte a redes Ethernet, elas:

  • [C-2-1] É PRECISO oferecer suporte à operação de pilha dupla em Ethernet.

Se as implementações de dispositivos oferecerem suporte a dados móveis, elas:

  • [C-3-1] É OBRIGATÓRIO atender simultaneamente a esses requisitos em cada rede à qual um dispositivo está conectado quando ele está conectado a mais de uma rede simultaneamente (por exemplo, Wi-Fi e dados móveis).
  • DEVE oferecer suporte à operação IPv6 (somente IPv6 e possivelmente pilha dupla) em dados móveis.

7.4.6. Configurações de sincronização

Implementações de dispositivos:

  • [C-0-1] A configuração mestre de sincronização automática PRECISA estar ativada por padrão para que o método getMasterSyncAutomatically() retorne "true".

7.4.7. Economia de dados

Se as implementações de dispositivos incluírem uma conexão limitada, elas serão:

  • [SR] É ALTAMENTE RECOMENDADO fornecer o modo de economia de dados.

Se as implementações do dispositivo oferecerem o modo de Economia de dados, elas:

Se as implementações do dispositivo não oferecerem o modo de Economia de dados, elas:

  • [C-2-1] PRECISA retornar o valor RESTRICT_BACKGROUND_STATUS_DISABLED para ConnectivityManager.getRestrictBackgroundStatus()
  • [C-2-2] NÃO DEVE transmitir ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.
  • [C-2-3] É PRECISO ter uma atividade que processe a intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, mas ela PODE ser implementada como uma operação nula.

7,5. Cameras

Se as implementações do dispositivo incluírem pelo menos uma câmera, elas:

  • [C-1-1] É OBRIGATÓRIO declarar a flag de recurso android.hardware.camera.any.
  • [C-1-2] É PRECISO que um aplicativo possa alocar simultaneamente três bitmaps RGBA_8888 iguais ao tamanho das imagens produzidas pelo sensor de câmera de maior resolução no dispositivo, enquanto a câmera está aberta para fins de visualização básica e captura de fotos.

7.5.1. Câmera traseira

Uma câmera traseira é uma câmera localizada na lateral do dispositivo oposta à tela. Ou seja, ela captura imagens do lado oposto do dispositivo, como uma câmera tradicional.

Implementações de dispositivos:

  • DEVE incluir uma câmera traseira.

Se as implementações do dispositivo incluírem pelo menos uma câmera traseira, elas:

  • [C-1-1] É OBRIGATÓRIO informar a flag de recurso android.hardware.camera e android.hardware.camera.any.
  • [C-1-2] PRECISA ter uma resolução de pelo menos 2 megapixels.
  • DEVE ter o foco automático de hardware ou de software implementado no driver da câmera (transparente para o software do aplicativo).
  • PODE ter hardware de foco fixo ou EDOF (profundidade de campo estendida).
  • PODE incluir um flash.

Se a câmera tiver um flash:

  • [C-2-1] A lâmpada do flash NÃO PODE estar acesa enquanto uma instância de android.hardware.Camera.PreviewCallback estiver registrada em uma superfície de visualização da câmera, a menos que o aplicativo tenha ativado explicitamente o flash ativando os atributos FLASH_MODE_AUTO ou FLASH_MODE_ON de um objeto Camera.Parameters. Essa restrição não se aplica ao aplicativo de câmera do sistema integrado do dispositivo, mas apenas a aplicativos de terceiros que usam Camera.PreviewCallback.

7.5.2. Câmera frontal

Uma câmera frontal é uma câmera localizada no mesmo lado do dispositivo que a tela, ou seja, uma câmera normalmente usada para capturar imagens do usuário, como em videoconferências e aplicativos semelhantes.

Implementações de dispositivos:

  • PODE incluir uma câmera frontal.

Se as implementações do dispositivo incluírem pelo menos uma câmera frontal, elas:

  • [C-1-1] É OBRIGATÓRIO informar a flag de recurso android.hardware.camera.any e android.hardware.camera.front.
  • [C-1-2] PRECISA ter uma resolução de pelo menos VGA (640 x 480 pixels).
  • [C-1-3] NÃO use uma câmera frontal como padrão para a API Camera e NÃO configure a API para tratar uma câmera frontal como a câmera traseira padrão, mesmo que seja a única câmera do dispositivo.
  • [C-1-4] A visualização da câmera PRECISA ser espelhada horizontalmente em relação à orientação especificada pelo aplicativo quando o aplicativo atual solicitou explicitamente que a tela da câmera fosse girada por uma chamada ao método android.hardware.Camera.setDisplayOrientation(). Por outro lado, a visualização PRECISA ser espelhada ao longo do eixo horizontal padrão do dispositivo quando o aplicativo atual não solicita explicitamente que a tela da câmera seja girada por uma chamada ao método android.hardware.Camera.setDisplayOrientation().
  • [C-1-5] NÃO É PERMITIDO espelhar os streams de imagem estática ou vídeo capturados finais retornados aos callbacks do aplicativo ou comprometidos com o armazenamento de mídia.
  • [C-1-6] A imagem mostrada pelo pós-visualização precisa ser espelhada da mesma forma que o fluxo de imagens da visualização da câmera.
  • PODE incluir recursos (como foco automático, flash etc.) disponíveis para câmeras traseiras, conforme descrito na seção 7.5.1.

Se as implementações de dispositivo puderem ser giradas pelo usuário (como automaticamente por um acelerômetro ou manualmente pela entrada do usuário):

  • [C-2-1] A visualização da câmera PRECISA ser espelhada horizontalmente em relação à orientação atual do dispositivo.

7.5.3. Câmera externa

Implementações de dispositivos:

  • PODE incluir suporte para uma câmera externa que não está necessariamente sempre conectada.

Se as implementações do dispositivo incluem suporte para uma câmera externa, elas:

  • [C-1-1] É OBRIGATÓRIO declarar a flag de recurso da plataforma android.hardware.camera.external e android.hardware camera.any.
  • [C-1-2] É PRECISO oferecer suporte à classe de vídeo USB (UVC 1.0 ou mais recente) se a câmera externa se conectar pela porta USB.
  • DEVE oferecer suporte a compactações de vídeo, como MJPEG, para permitir a transferência de streams não codificados de alta qualidade (ou seja, streams de imagem brutos ou compactados de forma independente).
  • PODE oferecer suporte a várias câmeras.
  • PODE oferecer suporte à codificação de vídeo baseada na câmera.

Se a codificação de vídeo baseada na câmera for compatível:

  • [C-2-1] Um fluxo simultâneo não codificado / MJPEG (resolução QVGA ou superior) PRECISA estar acessível à implementação do dispositivo.

7.5.4. Comportamento da API Camera

O Android inclui dois pacotes de API para acessar a câmera. A API android.hardware.camera2 mais recente expõe o controle de câmera de nível inferior ao app, incluindo fluxos de streaming/fotos em sequência eficientes sem cópia e controles por frame de exposição, ganho, ganhos de balanço de branco, conversão de cores, redução de ruído, nitidez e muito mais.

O pacote de API mais antigo, android.hardware.Camera, está marcado como descontinuado no Android 5.0, mas ainda está disponível para uso em apps. As implementações de dispositivos Android precisam garantir o suporte contínuo da API, conforme descrito nesta seção e no SDK do Android.

As implementações de dispositivos precisam implementar os seguintes comportamentos para as APIs relacionadas à câmera, para todas as câmeras disponíveis. Implementações de dispositivos:

  • [C-0-1] É OBRIGATÓRIO usar android.hardware.PixelFormat.YCbCr_420_SP para dados de visualização fornecidos a callbacks de aplicativos quando um aplicativo nunca chamou android.hardware.Camera.Parameters.setPreviewFormat(int).
  • [C-0-2] PRECISA estar no formato de codificação NV21 quando um aplicativo registra uma instância android.hardware.Camera.PreviewCallback e o sistema chama o método onPreviewFrame() e o formato de visualização é YCbCr_420_SP, os dados no byte[] são transmitidos para onPreviewFrame(). Ou seja, o NV21 PRECISA ser o padrão.
  • [C-0-3] É OBRIGATÓRIO ter suporte ao formato YV12 (conforme indicado pela constante android.graphics.ImageFormat.YV12) para visualizações de câmera frontal e traseira para android.hardware.Camera. O codificador de vídeo e a câmera de hardware podem usar qualquer formato de pixel nativo, mas a implementação do dispositivo PRECISA oferecer suporte à conversão para YV12.
  • [C-0-4] DEVE oferecer suporte aos formatos android.hardware.ImageFormat.YUV_420_888 e android.hardware.ImageFormat.JPEG como saídas pela API android.media.ImageReader para android.hardware.camera2.
  • [C-0-5] A API Camera completa incluída na documentação do SDK do Android ainda precisa ser implementada, mesmo que o dispositivo inclua foco automático de hardware ou outros recursos. Por exemplo, câmeras sem foco automático PRECISAM chamar qualquer instância registrada de android.hardware.Camera.AutoFocusCallback, mesmo que isso não tenha relevância para uma câmera sem foco automático. Isso se aplica a câmeras frontais. Por exemplo, embora a maioria das câmeras frontais não ofereça suporte ao foco automático, os callbacks da API ainda precisam ser "falsos", conforme descrito.
  • [C-0-6] PRECISA reconhecer e honrar cada nome de parâmetro definido como uma constante na classe android.hardware.Camera.Parameters. Por outro lado, as implementações de dispositivos NÃO PODEM reconhecer ou aceitar constantes de string transmitidas ao método android.hardware.Camera.setParameters(), exceto aquelas documentadas como constantes no android.hardware.Camera.Parameters. Ou seja, as implementações de dispositivos precisam oferecer suporte a todos os parâmetros padrão da câmera, se o hardware permitir, e NÃO podem oferecer suporte a tipos personalizados de parâmetros da câmera. Por exemplo, implementações de dispositivos que oferecem suporte à captura de imagens usando técnicas de High Dynamic Range (HDR) PRECISAM oferecer suporte ao parâmetro de câmera Camera.SCENE_MODE_HDR.
  • [C-0-7] É OBRIGATÓRIO informar o nível adequado de suporte com a propriedade android.info.supportedHardwareLevel, conforme descrito no SDK do Android, e informar as flags de recursos do framework adequadas.
  • [C-0-8] PRECISA declarar os recursos de câmera individuais de android.hardware.camera2 pela propriedade android.request.availableCapabilities e declarar as flags de recursos adequadas. PRECISA definir a flag de recurso se algum dos dispositivos de câmera conectados oferecer suporte a ela.
  • [C-0-9] PRECISA transmitir a intent Camera.ACTION_NEW_PICTURE sempre que uma nova foto for tirada pela câmera e a entrada da foto for adicionada à loja de mídia.
  • [C-0-10] É OBRIGATÓRIO transmitir a intent Camera.ACTION_NEW_VIDEO sempre que um novo vídeo for gravado pela câmera e a entrada da imagem for adicionada à loja de mídia.

7.5.5. Orientação da câmera

Se as implementações do dispositivo tiverem uma câmera frontal ou traseira, elas:

  • [C-1-1] PRECISA estar orientado de forma que a dimensão longa da câmera se alinhe à dimensão longa da tela. Ou seja, quando o dispositivo é segurado na orientação paisagem, as câmeras precisam capturar imagens na orientação paisagem. Isso se aplica independentemente da orientação natural do dispositivo, ou seja, se aplica a dispositivos com orientação principal de paisagem e retrato.

7.6. Memória e armazenamento

7.6.1. Memória e armazenamento mínimos

Implementações de dispositivos:

  • [C-0-1] PRECISA incluir um gerenciador de download que os aplicativos PODEM usar para fazer o download de arquivos de dados e PRECISA ser capaz de fazer o download de arquivos individuais de pelo menos 100 MB para o local de "cache" padrão.

7.6.2. Armazenamento compartilhado do aplicativo

Implementações de dispositivos:

  • [C-0-1] É PRECISO oferecer armazenamento para ser compartilhado por aplicativos, também conhecido como "armazenamento externo compartilhado", "armazenamento compartilhado do aplicativo" ou pelo caminho do Linux "/sdcard" em que ele é montado.
  • [C-0-2] PRECISA ser configurado com o armazenamento compartilhado montado por padrão, ou seja, "pronto para uso", independentemente de o armazenamento ser implementado em um componente de armazenamento interno ou em um meio de armazenamento removível (por exemplo, slot para cartão Secure Digital).
  • [C-0-3] É OBRIGATÓRIO montar o armazenamento compartilhado do aplicativo diretamente no caminho sdcard do Linux ou incluir um link simbólico do Linux de sdcard para o ponto de montagem real.
  • [C-0-4] É PRECISO aplicar a permissão android.permission.WRITE_EXTERNAL_STORAGE neste armazenamento compartilhado, conforme documentado no SDK. Caso contrário, o armazenamento compartilhado PRECISA ser gravável por qualquer aplicativo que receba essa permissão.

As implementações de dispositivos PODEM atender aos requisitos acima usando uma das seguintes opções:

  • Armazenamento removível acessível ao usuário, como um slot para cartão Secure Digital (SD).
  • Uma parte do armazenamento interno (não removível) conforme implementado no Android Open Source Project (AOSP).

Se as implementações de dispositivos usarem armazenamento removível para atender aos requisitos acima, elas:

  • [C-1-1] É OBRIGATÓRIO implementar uma interface do usuário pop-up ou aviso ao usuário quando não houver um meio de armazenamento inserido no slot.
  • [C-1-2] É OBRIGATÓRIO incluir um meio de armazenamento formatado em FAT (por exemplo, um cartão SD) ou mostrar na caixa e em outros materiais disponíveis no momento da compra que o meio de armazenamento precisa ser comprado separadamente.

Se as implementações do dispositivo usarem uma parte do armazenamento não removível para atender aos requisitos acima, elas:

  • DEVE usar a implementação do AOSP do armazenamento compartilhado do aplicativo interno.
  • PODE compartilhar o espaço de armazenamento com os dados privados do aplicativo.

Se as implementações de dispositivos incluírem vários caminhos de armazenamento compartilhados (como um slot para cartão SD e armazenamento interno compartilhado), elas:

  • [C-2-1] SOMENTE aplicativos Android pré-instalados e privilegiados com a permissão WRITE_EXTERNAL_STORAGE PODEM gravar no armazenamento externo secundário, exceto ao gravar em diretórios específicos do pacote ou no URI retornado ao acionar a intent ACTION_OPEN_DOCUMENT_TREE.

Se as implementações de dispositivos tiverem uma porta USB com suporte ao modo periférico USB, elas:

  • [C-3-1] É PRECISO fornecer um mecanismo para acessar os dados no armazenamento compartilhado do aplicativo em um computador host.
  • EXPORÃO o conteúdo das duas rotas de armazenamento de forma transparente pelo serviço de verificação de mídia do Android e pelo android.provider.MediaStore.
  • PODE usar o armazenamento em massa USB, mas DEVE usar o protocolo de transferência de mídia para atender a esse requisito.

Se as implementações do dispositivo tiverem uma porta USB com o modo periférico USB e oferecerem suporte ao protocolo de transferência de mídia, elas:

  • PRECISA ser compatível com o host de MTP do Android de referência, a Transferência de arquivos do Android.
  • DEVE informar uma classe de dispositivo USB de 0x00.
  • DEVE informar um nome de interface USB de "MTP".

7.6.3. Armazenamento adotável

Se o dispositivo for móvel, ao contrário da televisão, as implementações do dispositivo serão:

  • [SR] É ALTAMENTE RECOMENDADO implementar o armazenamento adaptável em um local estável de longo prazo, já que desconectá-lo acidentalmente pode causar perda/corrupção de dados.

Se a porta do dispositivo de armazenamento removível estiver em um local estável de longo prazo, como no compartimento da bateria ou em outra capa protetora, as implementações do dispositivo serão:

7.7. USB

Se as implementações do dispositivo tiverem uma porta USB, elas:

  • DEVE oferecer suporte ao modo de periférico USB e ao modo de host USB.

7.7.1. Modo de periférico USB

Se as implementações de dispositivos incluírem uma porta USB com suporte ao modo periférico:

  • [C-1-1] A porta PRECISA ser compatível com um host USB que tenha uma porta USB tipo A ou tipo C padrão.
  • [C-1-2] É OBRIGATÓRIO informar o valor correto de iSerialNumber no descritor de dispositivo padrão do USB por meio de android.os.Build.SERIAL.
  • [C-1-3] É NECESSÁRIO detectar carregadores de 1,5 A e 3,0 A de acordo com o padrão do resistor do tipo C e DETECTAR MUDANÇAS NO ANÚNCIO se eles tiverem suporte para USB tipo C.
  • [SR] A porta DEVE usar o formato USB micro-B, micro-AB ou tipo C. É FORTEMENTE RECOMENDADO que os dispositivos Android atuais e novos atendam a esses requisitos para que possam fazer upgrade para as versões futuras da plataforma.
  • [SR] A porta DEVE estar localizada na parte de baixo do dispositivo (de acordo com a orientação natural) ou ativar a rotação de tela do software para todos os apps (incluindo a tela inicial), para que a tela seja renderizada corretamente quando o dispositivo estiver orientado com a porta na parte de baixo. É FORTEMENTE RECOMENDADO que os dispositivos Android atuais e novos atendam a esses requisitos para que possam fazer upgrade para versões futuras da plataforma.
  • [SR] DEVE implementar suporte para consumir uma corrente de 1,5 A durante o chirp e o tráfego de HS, conforme especificado na especificação de carregamento de bateria USB, revisão 1.2. É FORTEMENTE RECOMENDADO que os dispositivos Android atuais e novos atendam a esses requisitos para que possam fazer upgrade para as versões futuras da plataforma.
  • [SR] É ALTAMENTE RECOMENDADO não oferecer suporte a métodos de carregamento proprietários que modifiquem a tensão do Vbus além dos níveis padrão ou alterem os papéis de destino/fonte, já que isso pode resultar em problemas de interoperabilidade com os carregadores ou dispositivos que oferecem suporte aos métodos padrão de fornecimento de energia USB. Embora isso seja "FORTEMENTE RECOMENDADO", em versões futuras do Android, podemos exigir que todos os dispositivos tipo C ofereçam suporte à interoperabilidade total com carregadores tipo C padrão.
  • [SR] É ALTAMENTE RECOMENDADO oferecer suporte à entrega de energia para dados e troca de função de energia quando houver suporte para USB Type-C e modo host USB.
  • DEVE oferecer suporte ao fornecimento de energia para carregamento de alta tensão e suporte a modos alternativos, como saída de tela.
  • DEVE implementar a API e a especificação do acessório aberto Android (AOA, na sigla em inglês) conforme documentado na documentação do SDK do Android.

Se as implementações de dispositivos incluem uma porta USB, implementam a especificação AOA, elas:

  • [C-2-1] É PRECISO declarar suporte ao recurso de hardware android.hardware.usb.accessory.
  • [C-2-2] A classe de armazenamento em massa USB PRECISA incluir a string "android" no final da string iInterface da descrição da interface do armazenamento em massa USB.

7.7.2. Modo de host USB

Se as implementações de dispositivos incluírem uma porta USB com suporte ao modo de host, elas:

  • [C-1-1] É OBRIGATÓRIO implementar a API host USB do Android conforme documentado no SDK do Android e DECLARAR suporte ao recurso de hardware android.hardware.usb.host.
  • [C-1-2] É PRECISO implementar suporte para conectar periféricos USB padrão. Em outras palavras, é PRECISO:
    • Ter uma porta do tipo C no dispositivo ou ser enviado com cabos que adaptam uma porta proprietária do dispositivo a uma porta USB-C padrão (dispositivo USB-C).
    • Ter uma porta tipo A no dispositivo ou ser enviado com cabos que adaptam uma porta proprietária no dispositivo a uma porta USB tipo A padrão.
    • Ter uma porta micro-AB no dispositivo, que DEVE ser enviada com um cabo que se adapta a uma porta tipo A padrão.
  • [C-1-3] NÃO PODE ser enviado com um adaptador que converte portas USB tipo A ou micro-AB em uma porta tipo C (soquete).
  • [SR] É ALTAMENTE RECOMENDADO implementar a classe de áudio USB conforme documentado na documentação do SDK do Android.
  • DEVE oferecer suporte ao carregamento do dispositivo periférico USB conectado no modo host; anunciando uma corrente de fonte de pelo menos 1,5 A, conforme especificado na seção "Terminais" da Especificação do cabo e conector USB Type-C, revisão 1.2 para conectores USB Type-C ou usando a faixa de corrente de saída da porta de carregamento downstream(CDP), conforme especificado nas Especificações de carregamento de bateria USB, revisão 1.2 para conectores Micro-AB.
  • DEVEM implementar e oferecer suporte aos padrões USB Type-C.

Se as implementações do dispositivo incluem uma porta USB com suporte ao modo de host e à classe de áudio USB, elas:

  • [C-2-1] É PRECISO oferecer suporte à classe HID do USB.
  • [C-2-2] É PRECISO oferecer suporte à detecção e ao mapeamento dos seguintes campos de dados HID especificados nas tabelas de uso do USB HID e na solicitação de uso do comando de voz para as constantes KeyEvent conforme abaixo:
    • Página de uso (0xC) ID de uso (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
    • Página de uso (0xC) ID de uso (0x0E9): KEYCODE_VOLUME_UP
    • Página de uso (0xC) ID de uso (0x0EA): KEYCODE_VOLUME_DOWN
    • Página de uso (0xC) ID de uso (0x0CF): KEYCODE_VOICE_ASSIST

Se as implementações do dispositivo incluírem uma porta USB com suporte ao modo host e ao Framework de acesso ao armazenamento (SAF, na sigla em inglês), elas:

  • [C-3-1] DEVE reconhecer todos os dispositivos MTP (protocolo de transferência de mídia) conectados remotamente e tornar o conteúdo deles acessível pelas intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT e ACTION_CREATE_DOCUMENT. .

Se as implementações do dispositivo incluem uma porta USB com suporte ao modo host e ao USB Type-C, elas:

  • [C-4-1] É PRECISO implementar a funcionalidade da porta de dupla função, conforme definido pela especificação USB Type-C (seção 4.5.1.3.3).
  • [SR] É ALTAMENTE RECOMENDADO que ofereça suporte a DisplayPort, DEVE oferecer suporte a taxas de dados USB SuperSpeed e ALTAMENTE RECOMENDADO que ofereça suporte ao fornecimento de energia para troca de dados e de função.
  • [SR] É ALTAMENTE RECOMENDADO que o modo de acessório do adaptador de áudio não seja compatível, conforme descrito no Apêndice A da Revisão 1.2 da especificação de cabo e conector USB Type-C.
  • PRECISA implementar o modelo Try.* mais adequado para o formato do dispositivo. Por exemplo, um dispositivo portátil PRECISA implementar o modelo Try.SNK.

7.8. Áudio

7.8.1. Microfone

Se as implementações do dispositivo incluírem um microfone, elas:

  • [C-1-1] É OBRIGATÓRIO informar a constante de recurso android.hardware.microphone.
  • [C-1-2] PRECISA atender aos requisitos de gravação de áudio na seção 5.4.
  • [C-1-3] É PRECISO atender aos requisitos de latência de áudio na seção 5.6.
  • [SR] É ALTAMENTE RECOMENDADO oferecer suporte à gravação de ultrassom, conforme descrito na seção 7.8.3.

Se as implementações do dispositivo omitirem um microfone, elas:

  • [C-2-1] NÃO DEVE informar a constante de recurso android.hardware.microphone.
  • [C-2-2] É PRECISO implementar a API de gravação de áudio pelo menos como no-ops, de acordo com a seção 7.

7.8.2. Saída de áudio

Se as implementações do dispositivo incluírem um alto-falante ou uma porta de saída de áudio/multimídia para um periférico de saída de áudio, como uma entrada de áudio de 3,5 mm com quatro condutores ou uma porta no modo host USB usando a classe de áudio USB, elas:

  • [C-1-1] É OBRIGATÓRIO informar a constante de recurso android.hardware.audio.output.
  • [C-1-2] PRECISA atender aos requisitos de reprodução de áudio na seção 5.5.
  • [C-1-3] É PRECISO atender aos requisitos de latência de áudio na seção 5.6.
  • [SR] É ALTAMENTE RECOMENDADO oferecer suporte à reprodução próxima à ultrassônica, conforme descrito na seção 7.8.3.

Se as implementações de dispositivos não incluírem um alto-falante ou uma porta de saída de áudio, elas:

  • [C-2-1] NÃO DEVE informar o recurso android.hardware.audio output.
  • [C-2-2] É PRECISO implementar as APIs relacionadas à saída de áudio como no-ops, no mínimo.

Para os fins desta seção, uma "porta de saída" é uma interface física, como uma entrada de áudio de 3,5 mm, HDMI ou porta de modo host USB com classe de áudio USB. O suporte à saída de áudio por protocolos baseados em rádio, como Bluetooth, Wi-Fi ou rede celular, não se qualifica como inclusão de uma "porta de saída".

7.8.2.1. Portas de áudio analógico

Para ser compatível com os fones de ouvido e outros acessórios de áudio que usam o plugue de áudio de 3,5 mm no ecossistema do Android, se uma implementação de dispositivo incluir uma ou mais portas de áudio analógico, pelo menos uma delas DEVE ser uma entrada de áudio de 3,5 mm com quatro condutores.

Se as implementações do dispositivo tiverem um conector de áudio de 3,5 mm com quatro condutores, elas:

  • [C-1-1] É PRECISO oferecer suporte à reprodução de áudio em fones de ouvido estéreo e fones de ouvido estéreo com microfone.
  • [C-1-2] É PRECISO oferecer suporte a conectores de áudio TRRS com a ordem de pinagem CTIA.
  • [C-1-3] PRECISA oferecer suporte à detecção e ao mapeamento para os códigos de tecla dos três intervalos de impedância equivalente entre o microfone e os condutores de aterramento no plugue de áudio:
    • 70 ohms ou menos: KEYCODE_HEADSETHOOK
    • 210-290 ohms: KEYCODE_VOLUME_UP
    • 360-680 ohms: KEYCODE_VOLUME_DOWN
  • [C-1-4] PRECISA acionar ACTION_HEADSET_PLUG ao inserir um plugue, mas somente depois que todos os contatos do plugue estiverem tocando os segmentos relevantes na tomada.
  • [C-1-5] É PRECISO que ele seja capaz de gerar pelo menos 150 mV ± 10% da tensão de saída em uma impedância de alto-falante de 32 ohms.
  • [C-1-6] É PRECISO ter uma tensão de polarização do microfone entre 1,8 V e 2,9 V.
  • [SR] ALTAMENTE RECOMENDADO para detectar e mapear para o código de tecla do seguinte intervalo de impedância equivalente entre o microfone e os condutores de aterramento no plugue de áudio:
    • 110-180 ohms:KEYCODE_VOICE_ASSIST
  • DEVE oferecer suporte a plugues de áudio com a ordem de pinagem OMTP.
  • DEVE oferecer suporte à gravação de áudio de fones de ouvido estéreo com microfone.

Se as implementações do dispositivo tiverem uma entrada de áudio de 3,5 mm com quatro condutores e oferecerem suporte a um microfone, e transmitirem o android.intent.action.HEADSET_PLUG com o valor extra do microfone definido como 1, elas:

  • [C-2-1] É PRECISO oferecer suporte à detecção de microfone no acessório de áudio conectado.

7.8.3. Near-Ultrasound

O áudio próximo ao ultrassom é a faixa de 18,5 kHz a 20 kHz.

Implementações de dispositivos:

  • É necessário informar corretamente o suporte ao recurso de áudio de quase ultrassom pela API AudioManager.getProperty da seguinte maneira:

Se PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND for "true", os requisitos a seguir PRECISAM ser atendidos pelas fontes de áudio VOICE_RECOGNITION e UNPROCESSED:

  • [C-1-1] A resposta de potência média do microfone na faixa de 18,5 kHz a 20 kHz PRECISA ser de no máximo 15 dB abaixo da resposta em 2 kHz.
  • [C-1-2] A relação sinal-ruído não ponderada do microfone de 18,5 kHz a 20 kHz para um tom de 19 kHz em -26 dBFS PRECISA ser maior que 50 dB.

Se PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND for "true":

  • [C-2-1] A resposta média do alto-falante em 18,5 kHz a 20 kHz PRECISA ser pelo menos 40 dB abaixo da resposta em 2 kHz.

7.9. Realidade virtual

O Android inclui APIs e recursos para criar apps de "realidade virtual" (RV), incluindo experiências de RV de alta qualidade para dispositivos móveis. As implementações de dispositivos precisam implementar essas APIs e comportamentos corretamente, conforme detalhado nesta seção.

7.9.1. Modo de realidade virtual

O Android inclui suporte ao modo de RV, um recurso que processa a renderização estereoscópica de notificações e desativa componentes monoculares da interface do sistema enquanto um aplicativo de RV tem o foco do usuário.

7.9.2. Realidade virtual de alto desempenho

Se as implementações de dispositivos identificarem o suporte à RV de alto desempenho para períodos mais longos de uso com a flag de recurso android.hardware.vr.high_performance, elas:

  • [C-1-1] É PRECISO ter pelo menos dois núcleos físicos.
  • [C-1-2] É OBRIGATÓRIO declarar android.software.vr.mode feature.
  • [C-1-3] É PRECISO oferecer suporte ao modo performance sustentada.
  • [C-1-4] PRECISA ter suporte ao OpenGL ES 3.2.
  • [C-1-5] PRECISA ter suporte ao nível 0 e PODE ter suporte ao nível 1 do hardware do Vulkan.
  • [C-1-6] É OBRIGATÓRIO implementar EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content e expor as extensões na lista de extensões EGL disponíveis.
  • [C-1-7] A GPU e a tela precisam ser capazes de sincronizar o acesso ao buffer frontal compartilhado para que a renderização alternada do olho do conteúdo de RV a 60 fps com dois contextos de renderização seja exibida sem artefatos de rasgo visíveis.
  • [C-1-8] É PRECISO implementar GL_EXT_multisampled_render_to_texture, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture, GL_EXT_protected_textures e expor as extensões na lista de extensões GL disponíveis.
  • [C-1-9] É PRECISO implementar suporte para as flags AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER e AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA, conforme descrito no NDK.
  • [C-1-10] É PRECISO implementar suporte para AHardwareBuffers com mais de uma camada.
  • [C-1-11] É PRECISO oferecer suporte à decodificação H.264 de pelo menos 3840x2160 a 30 fps e 40 Mbps (equivalente a 4 instâncias de 1920x1080 a 30 fps e 10 Mbps ou 2 instâncias de 1920x1080 a 60 fps e 20 Mbps).
  • [C-1-12] É PRECISO ter suporte a HEVC e VP9, ser capaz de decodificar pelo menos 1920x1080 a 30 fps e 10 Mbps e ser capaz de decodificar 3840x2160 a 30 fps e 20 Mbps (equivalente a 4 instâncias de 1920x1080 a 30 fps e 5 Mbps).
  • [C-1-13] É NECESSÁRIO oferecer suporte à API HardwarePropertiesManager.getDeviceTemperatures e retornar valores precisos para a temperatura da pele.
  • [C-1-14] É OBRIGATÓRIO ter uma tela integrada, e a resolução PRECISA ser de pelo menos FullHD(1080p) e é ALTAMENTE RECOMENDADO que seja QuadHD (1440p) ou superior.
  • [C-1-15] A tela PRECISA ser atualizada a pelo menos 60 Hz no modo de RV.
  • [C-1-16] A latência de exibição no tempo de comutação de cinza para cinza, branco para preto e preto para branco PRECISA ser ≤ 3 ms.
  • [C-1-17] A tela PRECISA oferecer suporte a um modo de baixa persistência com persistência de ≤5 ms, sendo que a persistência é definida como o tempo em que um pixel emite luz.
  • [C-1-18] É PRECISO ter suporte para Bluetooth 4.2 e extensão de comprimento de dados do Bluetooth LE seção 7.4.3.
  • [SR] É FORTEMENTE RECOMENDADO oferecer suporte ao recurso android.hardware.sensor.hifi_sensors e É NECESSÁRIO atender aos requisitos relacionados ao giroscópio, ao acelerômetro e ao magnetômetro para android.hardware.hifi_sensors.
  • PODE fornecer um núcleo exclusivo para o aplicativo em primeiro plano e PODE oferecer suporte à API Process.getExclusiveCores para retornar os números dos núcleos da CPU exclusivos do aplicativo em primeiro plano.

Se o núcleo exclusivo tiver suporte, ele:

  • [C-2-1] PRECISA não permitir que nenhum outro processo do espaço do usuário seja executado nele (exceto drivers de dispositivo usados pelo aplicativo), mas PODE permitir que alguns processos do kernel sejam executados conforme necessário.

8. Desempenho e energia

Alguns critérios mínimos de desempenho e potência são essenciais para a experiência do usuário e afetam as suposições de referência que os desenvolvedores teriam ao desenvolver um app.

8.1. Consistência na experiência do usuário

Uma interface do usuário suave pode ser fornecida ao usuário final se houver determinados requisitos mínimos para garantir uma taxa de frames e tempos de resposta consistentes para aplicativos e jogos. As implementações de dispositivos, dependendo do tipo, PODEM ter requisitos mensuráveis para a latência da interface do usuário e a alternância de tarefas, conforme descrito na seção 2.

8.2. Desempenho de acesso a E/S de arquivos

Fornecer uma base de referência comum para um desempenho consistente de acesso a arquivos no armazenamento de dados particular do aplicativo (partição /data) permite que os desenvolvedores de apps estabeleçam uma expectativa adequada que ajudaria o design do software. As implementações de dispositivos, dependendo do tipo, PODEM ter determinados requisitos descritos na seção 2 para as seguintes operações de leitura e gravação:

  • Desempenho de gravação sequencial. Medido gravando um arquivo de 256 MB usando um buffer de gravação de 10 MB.
  • Performance de gravação aleatória. Medido gravando um arquivo de 256 MB usando um buffer de gravação de 4 KB.
  • Desempenho de leitura sequencial. Medido lendo um arquivo de 256 MB usando um buffer de gravação de 10 MB.
  • Desempenho de leitura aleatória. Medido lendo um arquivo de 256 MB usando um buffer de gravação de 4 KB.

8.3. Modos de economia de energia

O Android inclui os modos de economia de energia "App em espera" e "Soneca" para otimizar o uso da bateria. [SR] É ALTAMENTE RECOMENDADO que todos os apps isentos desses modos sejam visíveis para o usuário final. [SR] A ativação, a manutenção, os algoritmos de ativação e o uso de configurações globais do sistema desses modos de economia de energia são FORTEMENTE RECOMENDADOS para que não se desviem do Projeto Android Open Source.

Além dos modos de economia de energia, as implementações de dispositivos Android PODEM implementar qualquer um ou todos os quatro estados de energia em suspensão, conforme definido pela Interface Avançada de Energia e Configuração (ACPI).

Se as implementações de dispositivos implementarem os estados de energia S3 e S4, conforme definido pelo ACPI, elas:

  • [C-1-1] SOMENTE entre nestes estados ao fechar uma tampa que faça parte fisicamente do dispositivo.

8.4. Contabilidade de consumo de energia

Uma contabilidade e relatórios mais precisos do consumo de energia fornecem ao desenvolvedor do app os incentivos e as ferramentas para otimizar o padrão de uso de energia do aplicativo.

Implementações de dispositivos:

  • [SR] É ALTAMENTE RECOMENDADO fornecer um perfil de energia por componente que defina o valor de consumo atual para cada componente de hardware e o consumo aproximado de bateria causado pelos componentes ao longo do tempo, conforme documentado no site do Projeto Android Open Source.
  • [SR] É ALTAMENTE RECOMENDADO informar todos os valores de consumo de energia em miliamperes-hora (mAh).
  • [SR] É ALTAMENTE RECOMENDADO informar o consumo de energia da CPU por UID de cada processo. O Android Open Source Project atende ao requisito com a implementação do módulo do kernel uid_cputime.
  • [SR] É ALTAMENTE RECOMENDADO disponibilizar esse uso de energia ao desenvolvedor do app pelo comando de shell adb shell dumpsys batterystats.
  • DEVE ser atribuído ao próprio componente de hardware se não for possível atribuir o uso de energia do componente de hardware a um aplicativo.

8.5. Desempenho consistente

A performance pode variar drasticamente em apps de longa duração de alto desempenho, seja por causa de outros apps em execução em segundo plano ou do estrangulamento da CPU devido a limites de temperatura. O Android inclui interfaces programáticas para que, quando o dispositivo for compatível, o aplicativo em primeiro plano possa solicitar que o sistema otimize a alocação dos recursos para lidar com essas flutuações.

Implementações de dispositivos:

Se as implementações de dispositivos informarem suporte ao modo performance sustentado, elas:

  • [C-1-1] É OBRIGATÓRIO fornecer ao aplicativo em primeiro plano um nível consistente de desempenho por pelo menos 30 minutos, quando o app solicitar.
  • [C-1-2] É PRECISO honrar a API Window.setSustainedPerformanceMode() e outras APIs relacionadas.

Se as implementações de dispositivos incluírem dois ou mais núcleos de CPU, elas:

  • DEVE fornecer pelo menos um núcleo exclusivo que possa ser reservado pelo aplicativo em primeiro plano.

Se as implementações de dispositivo oferecerem suporte à reserva de um núcleo exclusivo para o aplicativo em primeiro plano, elas:

  • [C-2-1] É OBRIGATÓRIO informar os números de ID das cores exclusivas que podem ser reservadas pelo aplicativo em primeiro plano pelo método da API Process.getExclusiveCores().
  • [C-2-2] NÃO DEVE permitir que nenhum processo do espaço do usuário, exceto os drivers de dispositivo usados pelo aplicativo, seja executado nas CPUs exclusivas, mas PODE permitir que alguns processos do kernel sejam executados conforme necessário.

Se as implementações do dispositivo não oferecerem suporte a um núcleo exclusivo, elas:

9. Compatibilidade do modelo de segurança

Implementações de dispositivos:

  • [C-0-1] É PRECISO implementar um modelo de segurança consistente com o modelo de segurança da plataforma Android, conforme definido no documento de referência sobre segurança e permissões nas APIs da documentação para desenvolvedores do Android.

  • [C-0-2] É PRECISO oferecer suporte à instalação de aplicativos autoassinados sem exigir permissões/certificados adicionais de terceiros/autoridades. Especificamente, os dispositivos compatíveis precisam oferecer suporte aos mecanismos de segurança descritos nas subseções a seguir.

9.1. Permissões

Implementações de dispositivos:

  • [C-0-1] É PRECISO oferecer suporte ao modelo de permissões do Android, conforme definido na documentação para desenvolvedores do Android. Especificamente, eles precisam aplicar cada permissão definida conforme descrito na documentação do SDK. Nenhuma permissão pode ser omitida, alterada ou ignorada.

  • PODE adicionar outras permissões, desde que as novas strings de ID de permissão não estejam no namespace android.\*.

  • [C-0-2] As permissões com um protectionLevel de PROTECTION_FLAG_PRIVILEGED SOMENTE podem ser concedidas a apps pré-carregados nos caminhos privilegiados da imagem do sistema e no subconjunto das permissões explicitamente permitidas para cada app. A implementação do AOSP atende a esse requisito lendo e aceitando as permissões permitidas de cada app nos arquivos no caminho etc/permissions/ e usando o caminho system/priv-app como o caminho privilegiado.

As permissões com nível de proteção perigoso são de execução. Os aplicativos com targetSdkVersion > 22 solicitam isso no momento da execução.

Implementações de dispositivos:

  • [C-0-3] É OBRIGATÓRIO mostrar uma interface dedicada para que o usuário decida se concede as permissões de execução solicitadas e também fornecer uma interface para que o usuário gerencie as permissões de execução.
  • [C-0-4] É PRECISO ter uma e apenas uma implementação das duas interfaces do usuário.
  • [C-0-5] NÃO é permitido conceder nenhuma permissão de execução a apps pré-instalados, a menos que:
  • o consentimento do usuário pode ser obtido antes que o aplicativo o use
  • as permissões de execução são associadas a um padrão de intent em que o aplicativo pré-instalado é definido como o gerenciador padrão;

Se as implementações de dispositivos incluírem um app pré-instalado ou permitirem que apps de terceiros acessem as estatísticas de uso, elas:

  • [SR] É ALTAMENTE RECOMENDADO fornecer um mecanismo acessível ao usuário para conceder ou revogar o acesso às estatísticas de uso em resposta à intent android.settings.ACTION_USAGE_ACCESS_SETTINGS para apps que declaram a permissão android.permission.PACKAGE_USAGE_STATS.

Se as implementações de dispositivos quiserem impedir que apps, incluindo os pré-instalados, acessem as estatísticas de uso, elas:

  • [C-1-1] A atividade que processa o padrão de intent android.settings.ACTION_USAGE_ACCESS_SETTINGS AINDA PRECISA ser implementada como uma operação nula, ou seja, precisa ter um comportamento equivalente ao que ocorre quando o acesso do usuário é negado.

9.2. Isolamento de UID e processo

Implementações de dispositivos:

  • [C-0-1] PRECISA oferecer suporte ao modelo de sandbox de aplicativos Android, em que cada aplicativo é executado como um UID no estilo Unix exclusivo e em um processo separado.
  • [C-0-2] É PRECISO oferecer suporte à execução de vários aplicativos como o mesmo ID de usuário do Linux, desde que os aplicativos sejam assinados e criados corretamente, conforme definido na Referência de segurança e permissões.

9.3. Permissões do sistema de arquivos

Implementações de dispositivos:

9.4. Ambientes de execução alternativos

As implementações de dispositivos precisam manter a consistência do modelo de segurança e de permissões do Android, mesmo que incluam ambientes de execução que executam aplicativos usando algum outro software ou tecnologia que não seja o formato executável Dalvik ou o código nativo. Resumindo:

  • [C-0-1] Os ambientes de execução alternativos PRECISAM ser aplicativos Android e obedecer ao modelo de segurança padrão do Android, conforme descrito em outro lugar na seção 9.

  • [C-0-2] Não é permitido conceder acesso a recursos protegidos por permissões não solicitadas no arquivo AndroidManifest.xml do ambiente de execução por meio do mecanismo <uses-permission>.

  • [C-0-3] Os ambientes de execução alternativos NÃO PODEM permitir que os aplicativos usem recursos protegidos por permissões do Android restritos a aplicativos do sistema.

  • [C-0-4] Os ambientes de execução alternativos PRECISAM obedecer ao modelo de sandbox do Android, e os aplicativos instalados que usam um ambiente de execução alternativo NÃO PODEM reutilizar o sandbox de nenhum outro app instalado no dispositivo, exceto pelos mecanismos padrão do Android de ID de usuário compartilhado e certificado de assinatura.

  • [C-0-5] Os ambientes de execução alternativos NÃO PODEM ser iniciados com, conceder ou receber acesso aos sandboxes correspondentes a outros aplicativos Android.

  • [C-0-6] As runtimes alternativas NÃO PODEM ser iniciadas, concedidas ou conceder a outros aplicativos privilégios do superusuário (raiz) ou de qualquer outro ID de usuário.

  • [C-0-7] Quando os arquivos .apk de ambientes de execução alternativos são incluídos na imagem do sistema de implementações de dispositivos, eles PRECISAM ser assinados com uma chave diferente da usada para assinar outros aplicativos incluídos nas implementações de dispositivos.

  • [C-0-8] Ao instalar aplicativos, os ambientes de execução alternativos PRECISAM receber o consentimento do usuário para as permissões do Android usadas pelo aplicativo.

  • [C-0-9] Quando um aplicativo precisa usar um recurso do dispositivo que tem uma permissão correspondente do Android (como câmera, GPS etc.), o ambiente de execução alternativo PRECISA informar ao usuário que o aplicativo poderá acessar esse recurso.

  • [C-0-10] Quando o ambiente de execução não registra os recursos do aplicativo dessa maneira, ele PRECISA listar todas as permissões mantidas pelo próprio ambiente de execução ao instalar qualquer aplicativo que use esse ambiente.

  • Os ambientes de execução alternativos PRECISAM instalar apps pelo PackageManager em sandboxes do Android separados (IDs de usuário do Linux etc.).

  • Os ambientes de execução alternativos podem fornecer um único sandbox do Android compartilhado por todos os aplicativos que usam o ambiente de execução alternativo.

9.5. Suporte a vários usuários

O Android inclui suporte para vários usuários e oferece suporte para isolamento total do usuário.

  • As implementações de dispositivos PODEM, mas NÃO devem, ativar o modo multiusuário se usarem mídia removível para o armazenamento externo principal.

Se as implementações de dispositivos incluírem vários usuários, eles:

  • [C-1-1] É PRECISO atender aos seguintes requisitos relacionados ao suporte multiusuário.
  • [C-1-2] PRECISA implementar, para cada usuário, um modelo de segurança consistente com o modelo de segurança da plataforma Android, conforme definido no documento de referência sobre segurança e permissões nas APIs.
  • [C-1-3] É PRECISO ter diretórios de armazenamento de aplicativos compartilhados (também conhecidos como /sdcard) separados e isolados para cada instância de usuário.
  • [C-1-4] É PRECISO garantir que os aplicativos de propriedade de um determinado usuário e executados em nome dele não possam listar, ler ou gravar nos arquivos de propriedade de qualquer outro usuário, mesmo que os dados de ambos estejam armazenados no mesmo volume ou sistema de arquivos.
  • [C-1-5] É NECESSÁRIO criptografar o conteúdo do cartão SD quando o modo multiusuário estiver ativado usando uma chave armazenada apenas em mídia não removível acessível apenas ao sistema, se as implementações do dispositivo usarem mídia removível para as APIs de armazenamento externo. Como isso torna a mídia ilegível para um PC host, as implementações de dispositivo precisam mudar para MTP ou um sistema semelhante para fornecer aos PCs host acesso aos dados do usuário atual.

Se as implementações do dispositivo incluírem vários usuários e não declararem a flag de recurso android.hardware.telephony, elas:

  • [C-2-1] É PRECISO oferecer suporte a perfis restritos, um recurso que permite aos proprietários de dispositivos gerenciar outros usuários e os recursos deles no dispositivo. Com os perfis restritos, os proprietários de dispositivos podem configurar rapidamente ambientes separados para que outros usuários trabalhem, com a capacidade de gerenciar restrições mais refinadas nos apps disponíveis nesses ambientes.

Se as implementações do dispositivo incluírem vários usuários e declararem a flag de recurso android.hardware.telephony, elas:

  • [C-3-1] NÃO é necessário oferecer suporte a perfis restritos, mas é necessário se alinhar à implementação de controles do AOSP para permitir /desabilitar o acesso de outros usuários a chamadas de voz e SMS.

9.6. Aviso de SMS premium

O Android inclui suporte para avisar os usuários sobre qualquer mensagem SMS premium enviada. SMS premium são mensagens de texto enviadas para um serviço registrado com uma operadora que pode gerar cobranças para o usuário.

Se as implementações de dispositivos declararem suporte a android.hardware.telephony, elas:

  • [C-1-1] É OBRIGATÓRIO avisar os usuários antes de enviar uma mensagem SMS para números identificados por expressões regulares definidas no arquivo /data/misc/sms/codes.xml do dispositivo. O Android Open Source Project upstream oferece uma implementação que atende a esse requisito.

9.7. Recursos de segurança do kernel

O Sandbox do Android inclui recursos que usam o sistema de controle de acesso obrigatório (MAC) do Security-Enhanced Linux (SELinux), o sandbox do seccomp e outros recursos de segurança no kernel do Linux. Implementações de dispositivos:

  • [C-0-1] É PRECISO manter a compatibilidade com aplicativos existentes, mesmo quando o SELinux ou outros recursos de segurança são implementados abaixo do framework do Android.
  • [C-0-2] NÃO PODE ter uma interface do usuário visível quando uma violação de segurança é detectada e bloqueada pelo recurso de segurança implementado abaixo do framework do Android, mas PODE ter uma interface do usuário visível quando ocorre uma violação de segurança não bloqueada que resulta em uma exploração bem-sucedida.
  • [C-0-3] O SELinux ou qualquer outro recurso de segurança implementado abaixo do framework do Android NÃO PODE ser configurado pelo usuário ou desenvolvedor do app.
  • [C-0-4] NÃO É PERMITIDO que um aplicativo que possa afetar outro por meio de uma API (como a API Device Administration) configure uma política que quebre a compatibilidade.
  • [C-0-5] É PRECISO dividir o framework de mídia em vários processos para que seja possível conceder acesso mais restrito a cada processo, conforme descrito no site do Projeto Android Open Source.
  • [C-0-6] É OBRIGATÓRIO implementar um mecanismo de sandbox de aplicativo de kernel que permita a filtragem de chamadas do sistema usando uma política configurável de programas multithread. O Android Open Source Project upstream atende a esse requisito ativando o seccomp-BPF com sincronização de threadgroup (TSYNC), conforme descrito na seção "Configuração do kernel" do source.android.com.

A integridade do kernel e os recursos de autoproteção são essenciais para a segurança do Android. Implementações de dispositivos:

  • [C-0-7] É PRECISO implementar mecanismos de proteção contra buffer excedente de pilha do kernel. Exemplos desses mecanismos são CC_STACKPROTECTOR_REGULAR e CONFIG_CC_STACKPROTECTOR_STRONG.
  • [C-0-8] É PRECISO implementar proteções rígidas de memória do kernel em que o código executável é somente leitura, os dados somente leitura não são executáveis nem graváveis e os dados graváveis não são executáveis (por exemplo, CONFIG_DEBUG_RODATA ou CONFIG_STRICT_KERNEL_RWX).
  • [SR] É ALTAMENTE RECOMENDADO manter os dados do kernel, que são gravados apenas durante a inicialização, marcados como somente leitura após a inicialização (por exemplo, __ro_after_init).
  • [SR} É ALTAMENTE RECOMENDADO implementar a verificação de limites de tamanho de objeto estático e dinâmico de cópias entre o espaço do usuário e o espaço do kernel (por exemplo, CONFIG_HARDENED_USERCOPY).
  • [SR] É ALTAMENTE RECOMENDADO nunca executar a memória do espaço do usuário ao executar no kernel (por exemplo, PXN de hardware ou emulado por CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN).
  • [SR] É ALTAMENTE RECOMENDADO nunca ler ou gravar a memória do espaço do usuário no kernel fora das APIs de acesso de cópia de usuário normais (por exemplo, PAN de hardware ou emulado por CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN).
  • [SR] É ALTAMENTE RECOMENDADO randomizar o layout do código do kernel e da memória e evitar exposições que comprometam a randomização (por exemplo, CONFIG_RANDOMIZE_BASE com entropia do carregador de inicialização pelo /chosen/kaslr-seed Device Tree node ou EFI_RNG_PROTOCOL).

Se as implementações do dispositivo usarem um kernel do Linux, elas:

  • [C-1-1] É PRECISO implementar o SELinux.
  • [C-1-2] É PRECISO definir o SELinux como o modo de restrição global.
  • [C-1-3] É PRECISO configurar todos os domínios no modo de aplicação. Nenhum domínio no modo permissivo é permitido, incluindo domínios específicos de um dispositivo/fabricante.
  • [C-1-4] NÃO é permitido modificar, omitir ou substituir as regras neverallow presentes na pasta system/sepolicy fornecida no upstream do Android Open Source Project (AOSP). A política DEVE ser compilada com todas as regras neverallow presentes, tanto para domínios AOSP SELinux quanto para domínios específicos de dispositivos/fornecedores.
  • DEVE manter a política SELinux padrão fornecida na pasta system/sepolicy do Projeto Android Open Source upstream e adicionar apenas a essa política para a própria configuração específica do dispositivo.

Se as implementações do dispositivo usarem um kernel diferente do Linux, elas:

  • [C-2-1] É PRECISO usar um sistema de controle de acesso obrigatório equivalente ao SELinux.

9,8. Privacidade

9.8.1. Histórico de uso

O Android armazena o histórico das escolhas do usuário e o gerencia pelo UsageStatsManager.

Implementações de dispositivos:

  • [C-0-1] É OBRIGATÓRIO manter um período de retenção razoável desse histórico de usuário.
  • [SR] É ALTAMENTE RECOMENDADO manter o período de retenção de 14 dias conforme configurado por padrão na implementação do AOSP.

9.8.2. Gravando

Se as implementações de dispositivo incluírem uma funcionalidade no sistema que capture o conteúdo exibido na tela e/ou grave o stream de áudio reproduzido no dispositivo, elas:

  • [C-1-1] É OBRIGATÓRIO ter uma notificação em andamento para o usuário sempre que esse recurso estiver ativado e capturar/gravar ativamente.

Se as implementações de dispositivos incluírem um componente ativado de fábrica, capaz de gravar áudio ambiente para inferir informações úteis sobre o contexto do usuário, elas:

  • [C-2-1] NÃO É PERMITIDO armazenar de forma permanente no armazenamento do dispositivo ou transmitir fora dele o áudio bruto gravado ou qualquer formato que possa ser convertido de volta para o áudio original ou um fac-símile semelhante, exceto com consentimento explícito do usuário.

9.8.3. Conectividade

Se as implementações de dispositivos tiverem uma porta USB com suporte ao modo periférico USB, elas:

  • [C-1-1] É OBRIGATÓRIO apresentar uma interface que peça o consentimento do usuário antes de permitir o acesso ao conteúdo do armazenamento compartilhado pela porta USB.

9.8.4. Tráfego de rede

Implementações de dispositivos:

  • [C-0-1] É PRECISO pré-instalar os mesmos certificados raiz para a loja de autoridade certificadora (AC) confiável do sistema como fornecidos no projeto upstream do Android Open Source.
  • [C-0-2] É OBRIGATÓRIO enviar com uma loja de AC raiz do usuário vazia.
  • [C-0-3] É OBRIGATÓRIO mostrar um aviso ao usuário indicando que o tráfego de rede pode ser monitorado quando uma AC raiz do usuário é adicionada.

Se o tráfego do dispositivo for roteado por uma VPN, as implementações do dispositivo:

  • [C-1-1] É PRECISO mostrar um aviso ao usuário indicando:
    • Esse tráfego de rede pode ser monitorado.
    • Esse tráfego de rede está sendo roteado pelo aplicativo VPN específico que fornece a VPN.

Se as implementações de dispositivos tiverem um mecanismo ativado por padrão que roteia o tráfego de dados de rede por um servidor proxy ou gateway VPN (por exemplo, pré-carregando um serviço de VPN com android.permission.CONTROL_VPN concedido), elas:

  • [C-2-1] É OBRIGATÓRIO pedir o consentimento do usuário antes de ativar esse mecanismo, a menos que a VPN seja ativada pelo Device Policy Controller usando o DevicePolicyManager.setAlwaysOnVpnPackage(). Nesse caso , o usuário não precisa fornecer um consentimento separado, mas APENAS ser notificado.

9,9. Criptografia de armazenamento de dados

Se as implementações do dispositivo oferecerem suporte a uma tela de bloqueio segura, conforme descrito na seção 9.11.1, elas:

  • [C-1-1] É PRECISO oferecer suporte à criptografia de armazenamento de dados dos dados privados do aplicativo (/data partition), bem como da partição de armazenamento compartilhada do aplicativo (/sdcard partition) se ela for uma parte permanente e não removível do dispositivo.

Se as implementações do dispositivo oferecerem suporte a uma tela de bloqueio segura, conforme descrito na seção 9.11.1, e oferecerem suporte à criptografia de armazenamento de dados com desempenho criptográfico do padrão de criptografia avançada (AES) acima de 50 MiB/s, elas:

  • [C-2-1] É OBRIGATÓRIO ativar a criptografia de armazenamento de dados por padrão quando o usuário concluir a experiência de configuração inicial. Se as implementações do dispositivo já forem lançadas em uma versão anterior do Android com a criptografia desativada por padrão, esse dispositivo não poderá atender ao requisito com uma atualização de software do sistema e PODE ser isento.

  • DEVE atender ao requisito de criptografia de armazenamento de dados acima implementando a Criptografia baseada em arquivos (FBE).

9.9.1. Inicialização direta

Implementações de dispositivos:

  • [C-0-1] É PRECISO implementar as APIs do modo de inicialização direta, mesmo que elas não ofereçam suporte à criptografia de armazenamento.

  • [C-0-2] As intents ACTION_LOCKED_BOOT_COMPLETED e ACTION_USER_UNLOCKED ainda precisam ser transmitidas para sinalizar aos aplicativos compatíveis com a inicialização direta que os locais de armazenamento criptografados pelo dispositivo (DE, na sigla em inglês) e criptografados por credenciais (CE, na sigla em inglês) estão disponíveis para o usuário.

9.9.2. Criptografia baseada em arquivos

Se as implementações do dispositivo oferecerem suporte ao FBE, elas:

  • [C-1-1] É OBRIGATÓRIO inicializar sem pedir credenciais ao usuário e permitir que apps compatíveis com a inicialização direta acessem o armazenamento criptografado pelo dispositivo (DE, na sigla em inglês) depois que a mensagem ACTION_LOCKED_BOOT_COMPLETED for transmitida.
  • [C-1-2] SOMENTE PERMITIR O ACESSO AO ARMAZENAMENTO CRIPTOGRÁFICO DE CREDENCIAIS (CE) DEPOIS QUE O USUÁRIO DESBLOQUEAR O DISPOSITIVO FORNECENDO AS CREDENCIAIS (POR EXEMPLO, SENHA, PIN, PADRÃO OU IMPRESSÃO DIGITAL) E A MENSAGEM ACTION_USER_UNLOCKED FOR ENVIADA.
  • [C-1-3] NÃO é permitido oferecer nenhum método para desbloquear o armazenamento protegido por CE sem as credenciais fornecidas pelo usuário.
  • [C-1-4] É PRECISO oferecer suporte à inicialização verificada e garantir que as chaves de DE sejam vinculadas criptograficamente à raiz de confiança de hardware do dispositivo.
  • [C-1-5] É PRECISO oferecer suporte à criptografia do conteúdo do arquivo usando AES com um comprimento de chave de 256 bits no modo XTS.

  • [C-1-6] É NECESSÁRIO oferecer suporte à criptografia do nome do arquivo usando AES com um comprimento de chave de 256 bits no modo CBC-CTS.

  • As chaves que protegem as áreas de armazenamento de CE e DE:

  • [C-1-7] PRECISA ser vinculado criptograficamente a um keystore protegido por hardware.

  • [C-1-8] As chaves CE precisam estar vinculadas às credenciais da tela de bloqueio de um usuário.
  • [C-1-9] As chaves de CE precisam estar vinculadas a uma senha padrão quando o usuário não especificou credenciais da tela de bloqueio.

  • [C-1-10] PRECISA ser único e distinto. Em outras palavras, nenhuma chave CE ou DE de um usuário corresponde a qualquer outra chave CE ou DE.

  • [C-1-11] É OBRIGATÓRIO usar as cifras, os comprimentos de chave e os modos com suporte obrigatório por padrão.

  • É NECESSÁRIO que os apps essenciais pré-carregados (por exemplo, Alarm, Phone, Messenger) sejam compatíveis com a inicialização direta.

  • PODE oferecer suporte a cifras alternativas, comprimentos de chave e modos para criptografia de conteúdo e nome de arquivo.

O projeto upstream do Android Open Source oferece uma implementação preferencial desse recurso com base no recurso de criptografia ext4 do kernel do Linux.

9.9.3. Criptografia de disco completo

Se as implementações do dispositivo oferecerem suporte à criptografia de disco completo (FDE), elas:

  • [C-1-1] É OBRIGATÓRIO usar o AES com uma chave de 128 bits (ou mais) e um modo projetado para armazenamento (por exemplo, AES-XTS, AES-CBC-ESSIV).
  • [C-1-2] É OBRIGATÓRIO usar uma senha padrão para encapsular a chave de criptografia e NÃO PRECISA gravar a chave de criptografia no armazenamento a qualquer momento sem que ela seja criptografada.
  • [C-1-3] É OBRIGATÓRIO oferecer ao usuário a possibilidade de criptografar com AES a chave de criptografia, exceto quando ela estiver em uso ativo, com as credenciais da tela de bloqueio esticadas usando um algoritmo de alongamento lento (por exemplo, PBKDF2 ou scrypt).
  • [C-1-4] O algoritmo de alongamento de senha padrão acima PRECISA ser vinculado criptograficamente a esse keystore quando o usuário não especificou credenciais de tela de bloqueio ou desativou o uso da senha para criptografia e o dispositivo fornece um keystore protegido por hardware.
  • [C-1-5] A chave de criptografia NÃO PODE ser enviada do dispositivo (mesmo quando envolvida com a senha do usuário e/ou chave vinculada ao hardware).

O projeto upstream do Android Open Source oferece uma implementação preferencial desse recurso, com base no recurso dm-crypt do kernel do Linux.

9.10. Integridade do dispositivo

Os requisitos a seguir garantem a transparência do status da integridade do dispositivo. Implementações de dispositivos:

  • [C-0-1] É OBRIGATÓRIO informar corretamente pelo método PersistentDataBlockManager.getFlashLockState() da API do sistema se o estado do carregador de inicialização permite a instalação da imagem do sistema. O estado FLASH_LOCK_UNKNOWN é reservado para implementações de dispositivos que estão sendo atualizadas de uma versão anterior do Android, em que esse novo método da API do sistema não existia.

A inicialização verificada é um recurso que garante a integridade do software do dispositivo. Se uma implementação de dispositivo oferecer suporte ao recurso, ele:

  • [C-1-1] É PRECISO declarar a flag de recurso da plataforma android.software.verified_boot.
  • [C-1-2] É PRECISO realizar a verificação em cada sequência de inicialização.
  • [C-1-3] É PRECISO iniciar a verificação em uma chave de hardware imutável que seja a raiz de confiança e ir até a partição do sistema.
  • [C-1-4] É PRECISO implementar cada etapa de verificação para verificar a integridade e a autenticidade de todos os bytes na próxima etapa antes de executar o código na próxima etapa.
  • [C-1-5] É OBRIGATÓRIO usar algoritmos de verificação tão fortes quanto as recomendações atuais do NIST para algoritmos de hash (SHA-256) e tamanhos de chave pública (RSA-2048).
  • [C-1-6] NÃO DEVE permitir que a inicialização seja concluída quando a verificação do sistema falhar, a menos que o usuário consinta tentar a inicialização. Nesse caso, os dados de qualquer bloco de armazenamento não verificado NÃO PODEM ser usados.
  • [C-1-7] NÃO É PERMITIDO que as partições verificadas no dispositivo sejam modificadas, a menos que o usuário tenha desbloqueado explicitamente o carregador de inicialização.
  • [SR] Se houver vários chips discretos no dispositivo (por exemplo, rádio, processador de imagem especializado), é ALTAMENTE RECOMENDADO verificar cada etapa da inicialização do processo de inicialização de cada um desses chips.
  • [SR] É ALTAMENTE RECOMENDADO usar armazenamento inviolável para quando o carregador de inicialização estiver desbloqueado. O armazenamento com evidências de adulteração significa que o carregador de inicialização pode detectar se o armazenamento foi adulterado dentro do HLOS (sistema operacional de alto nível).
  • [SR] É ALTAMENTE RECOMENDADO solicitar ao usuário, enquanto ele usa o dispositivo, e exigir a confirmação física antes de permitir a transição do modo de carregador de inicialização bloqueado para o modo de carregador de inicialização desbloqueado.
  • [SR] É ALTAMENTE RECOMENDADO implementar a proteção de reversão para o HLOS (por exemplo, inicialização, partições do sistema) e usar armazenamento inviolável para armazenar os metadados usados para determinar a versão mínima do SO permitida.
  • DEVE implementar a proteção de reversão para qualquer componente com firmware persistente (por exemplo, modem, câmera) e DEVE usar armazenamento inviolável para armazenar os metadados usados para determinar a versão mínima permitida.

O Android Open Source Project upstream oferece uma implementação preferencial desse recurso no repositório external/avb/, que pode ser integrado ao carregador de inicialização usado para carregar o Android.

Implementações de dispositivos com desempenho de criptografia do padrão de criptografia avançada (AES) acima de 50 MiB/segundos:

  • [C-2-1] É PRECISO oferecer suporte à inicialização verificada para a integridade do dispositivo.

Se uma implementação de dispositivo já foi lançada sem oferecer suporte à inicialização verificada em uma versão anterior do Android, esse dispositivo não pode adicionar suporte a esse recurso com uma atualização do software do sistema e, portanto, está isento do requisito.

9.11. Chaves e credenciais

O sistema Android Keystore permite que os desenvolvedores de apps armazenem chaves criptográficas em um contêiner e as usem em operações criptográficas pela API KeyChain ou pela API Keystore. Implementações de dispositivos:

  • [C-0-1] É PRECISO permitir pelo menos 8.192 chaves para importação.
  • [C-0-2] A autenticação da tela de bloqueio PRECISA limitar a taxa de tentativas e PRECISA ter um algoritmo de espera exponencial. Após 150 tentativas, o atraso DEVE ser de pelo menos 24 horas por tentativa.
  • NÃO deve limitar o número de chaves que podem ser geradas

Quando a implementação do dispositivo oferece suporte a uma tela de bloqueio segura, ela:

  • [C-1-1] É OBRIGATÓRIO fazer backup da implementação do keystore com hardware seguro.
  • [C-1-2] É PRECISO ter implementações de algoritmos criptográficos RSA, AES, ECDSA e HMAC e funções de hash da família MD5, SHA1 e SHA-2 para oferecer suporte adequado aos algoritmos aceitos pelo sistema do Keystore do Android em uma área isolada com segurança do código executado no kernel e acima. O isolamento seguro PRECISA bloquear todos os possíveis mecanismos pelos quais o código do kernel ou do espaço do usuário possa acessar o estado interno do ambiente isolado, incluindo o DMA. O upstream do Android Open Source Project (AOSP) atende a esse requisito usando a implementação do Trusty, mas outra solução baseada no ARM TrustZone ou uma implementação segura revisada por terceiros de um isolamento adequado baseado em hipervisor são opções alternativas.
  • [C-1-3] É PRECISO realizar a autenticação da tela de bloqueio no ambiente de execução isolado e, somente se for bem-sucedido, permitir que as chaves vinculadas à autenticação sejam usadas. O upstream do Android Open Source Project fornece a camada de abstração de hardware (HAL, na sigla em inglês) do Gatekeeper e o Trusty, que podem ser usados para atender a esse requisito.
  • [C-1-4] É PRECISO oferecer suporte ao atestado de chaves em que a chave de assinatura de atestado é protegida por hardware seguro e a assinatura é realizada em hardware seguro. As chaves de assinatura de atestado precisam ser compartilhadas em um número suficiente de dispositivos para evitar que sejam usadas como identificadores. Uma maneira de atender a esse requisito é compartilhar a mesma chave de atestado,a menos que pelo menos 100.000 unidades de um determinado SKU sejam produzidas. Se mais de 100.000 unidades de um SKU forem produzidas, uma chave diferente PODE ser usada para cada 100.000 unidades.

Se uma implementação de dispositivo já tiver sido lançada em uma versão anterior do Android, esse dispositivo estará isento do requisito de ter um keystore protegido por hardware e oferecer suporte ao atestado de chave, a menos que ele declare o recurso android.hardware.fingerprint, que exige um keystore protegido por hardware.

9.11.1. Tela de bloqueio segura

Se as implementações do dispositivo tiverem uma tela de bloqueio segura e incluirem um ou mais agentes de confiança, que implementam a API do sistema TrustAgentService, elas:

  • [C-1-1] É OBRIGATÓRIO indicar ao usuário na interface do usuário "Configurações" e "Tela de bloqueio" situações em que o bloqueio automático da tela é adiado ou pode ser desbloqueado pelo agente de confiança. O AOSP atende ao requisito mostrando uma descrição de texto para os menus "Configuração de bloqueio automático" e "O botão liga/desliga bloqueia instantaneamente a configuração" e um ícone distinto na tela de bloqueio.
  • [C-1-2] É NECESSÁRIO respeitar e implementar totalmente todas as APIs do agente de confiança na classe DevicePolicyManager, como a constante KEYGUARD_DISABLE_TRUST_AGENTS.
  • [C-1-3] NÃO É PERMITIDO implementar totalmente a função TrustAgentService.addEscrowToken() em um dispositivo usado como dispositivo pessoal principal (por exemplo, dispositivo portátil), mas É PERMITIDO implementar totalmente a função em implementações de dispositivo normalmente compartilhadas.
  • [C-1-4] É PRECISO criptografar os tokens adicionados por TrustAgentService.addEscrowToken() antes de armazená-los no dispositivo.
  • [C-1-5] NÃO DEVE armazenar a chave de criptografia no dispositivo.
  • [C-1-6] É OBRIGATÓRIO informar o usuário sobre as implicações de segurança antes de ativar o token de depósito para descriptografar o armazenamento de dados.

Se as implementações de dispositivos adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio, para que esse método de autenticação seja tratado como uma maneira segura de bloquear a tela, ele precisa:

Se as implementações de dispositivos adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio se forem baseados em um segredo conhecido, para que esse método de autenticação seja tratado como uma maneira segura de bloquear a tela, eles:

  • [C-3-1] A entropia do menor comprimento permitido de entradas PRECISA ser maior que 10 bits.
  • [C-3-2] A entropia máxima de todas as entradas possíveis PRECISA ser maior que 18 bits.
  • [C-3-3] NÃO é permitido substituir nenhum dos métodos de autenticação (PIN,padrão, senha) implementados e fornecidos no AOSP.
  • [C-3-4] PRECISA ser desativado quando o aplicativo do controlador de política de dispositivo (DPC) tiver definido a política de qualidade da senha pelo método DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva do que PASSWORD_QUALITY_SOMETHING.

Se as implementações de dispositivos adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio com base em um token físico ou no local, para que esse método de autenticação seja tratado como uma maneira segura de bloquear a tela, ele precisa:

  • [C-4-1] É OBRIGATÓRIO ter um mecanismo de fallback para usar um dos métodos de autenticação principais, que é baseado em um segredo conhecido e atende aos requisitos para ser tratado como uma tela de bloqueio segura.
  • [C-4-2] PRECISA ser desativado e permitir que apenas a autenticação primária desbloqueie a tela quando o aplicativo do controlador de políticas do dispositivo (DPC) tiver definido a política com o método DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) ou DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva do que PASSWORD_QUALITY_UNSPECIFIED.
  • [C-4-3] O usuário PRECISA ser desafiado para a autenticação principal (por exemplo, PIN, padrão, senha) pelo menos uma vez a cada 72 horas ou menos.

Se as implementações de dispositivos adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio com base em biometria, para que esse método de autenticação seja tratado como uma maneira segura de bloquear a tela, eles:

  • [C-5-1] É PRECISO ter um mecanismo de fallback para usar um dos métodos de autenticação principais, que é baseado em um secret conhecido e atende aos requisitos para ser tratado como uma tela de bloqueio segura.
  • [C-5-2] PRECISA ser desativado e permitir que apenas a autenticação primária desbloqueie a tela quando o aplicativo do controlador de políticas do dispositivo (DPC) tiver definido a política de recurso de proteção de chaves chamando o método DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT).
  • [C-5-3] PRECISA ter uma taxa de aceitação falsa igual ou mais forte do que o necessário para um sensor de impressão digital, conforme descrito na seção 7.3.10, ou PRECISA ser desativado e permitir apenas que a autenticação primária desbloqueie a tela quando o aplicativo Device Policy Controller (DPC) tiver definido a política de qualidade da senha pelo método DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva do que PASSWORD_QUALITY_BIOMETRIC_WEAK.
  • [C-5-4] O usuário PRECISA ser desafiado para a autenticação principal (por exemplo, PIN, padrão, senha) pelo menos uma vez a cada 72 horas ou menos.

Se as implementações de dispositivos adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio e se esse método de autenticação for usado para desbloquear o protetor de tela, mas não for tratado como uma tela de bloqueio segura, então:

9.12. Exclusão de dados

Todas as implementações de dispositivos:

  • [C-0-1] É PRECISO oferecer aos usuários um mecanismo para realizar uma "Redefinição para a configuração original".
  • [C-0-2] É PRECISO excluir todos os dados gerados pelo usuário. Ou seja, todos os dados, exceto:
    • A imagem do sistema
    • Todos os arquivos do sistema operacional necessários para a imagem do sistema
  • [C-0-3] É OBRIGATÓRIO excluir os dados de modo a atender aos padrões relevantes do setor, como o NIST SP800-88.
  • [C-0-4] É PRECISO acionar o processo "Redefinição de dados de fábrica" acima quando a API DevicePolicyManager.wipeData() for chamada pelo app de controle de política do dispositivo do usuário principal.
  • PODE fornecer uma opção de eliminação rápida de dados que realiza apenas uma exclusão lógica de dados.

9.13. Modo de inicialização segura

O Android oferece o modo de inicialização segura, que permite que os usuários inicializem em um modo em que apenas os apps do sistema pré-instalados podem ser executados e todos os apps de terceiros são desativados. Esse modo, conhecido como "Modo de inicialização segura", permite que o usuário desinstale apps de terceiros potencialmente nocivos.

As implementações de dispositivos são:

  • [SR] É ALTAMENTE RECOMENDADO implementar o modo de inicialização segura.

Se as implementações de dispositivos implementarem o modo de inicialização segura, elas:

  • [C-1-1] É PRECISO oferecer ao usuário uma opção para entrar no modo de inicialização segura de forma ininterruptível de apps de terceiros instalados no dispositivo, exceto quando o app de terceiros é um controlador de política de dispositivo e definiu a flag UserManager.DISALLOW_SAFE_BOOT como verdadeira.

  • [C-1-2] É OBRIGATÓRIO oferecer ao usuário a capacidade de desinstalar apps de terceiros no modo de segurança.

  • DEVEM fornecer ao usuário a opção de entrar no modo de inicialização segura pelo menu de inicialização usando um fluxo de trabalho diferente do de uma inicialização normal.

9.14. Isolamento do sistema de veículos automotivos

Espera-se que os dispositivos Android Automotive troquem dados com subsistemas críticos do veículo usando o HAL do veículo para enviar e receber mensagens em redes de veículos, como o barramento CAN.

A troca de dados pode ser protegida com a implementação de recursos de segurança abaixo das camadas do framework do Android para evitar interações maliciosas ou não intencionais com esses subsistemas.

10. Teste de compatibilidade de software

As implementações de dispositivos precisam passar em todos os testes descritos nesta seção. No entanto, nenhum pacote de teste de software é totalmente abrangente. Por esse motivo, É ALTAMENTE RECOMENDADO que os implementadores de dispositivos façam o menor número possível de mudanças na implementação de referência e preferida do Android disponível no Projeto Android Open Source. Isso vai minimizar o risco de introduzir bugs que criam incompatibilidades que exigem retrabalho e possíveis atualizações do dispositivo.

10.1. Conjunto de teste de compatibilidade

Implementações de dispositivos:

  • [C-0-1] É PRECISO passar no Conjunto de teste de compatibilidade do Android (CTS) disponível no Projeto Android Open Source, usando o software de envio final no dispositivo.

  • [C-0-2] É PRECISO garantir a compatibilidade em casos de ambiguidade no CTS e para qualquer nova implementação de partes do código-fonte de referência.

O CTS foi projetado para ser executado em um dispositivo real. Como qualquer software, o CTS pode conter bugs. A versão do CTS será independente desta definição de compatibilidade, e várias revisões do CTS poderão ser lançadas para o Android 8.0.

Implementações de dispositivos:

  • [C-0-3] É NECESSÁRIO passar na versão mais recente do CTS disponível no momento em que o software do dispositivo for concluído.

  • DEVE usar a implementação de referência na árvore do Android Open Source o máximo possível.

10.2. Verificador do CTS

O Verificador do CTS está incluído no Compatibility Test Suite e é destinado a ser executado por um operador humano para testar funcionalidades que não podem ser testadas por um sistema automatizado, como o funcionamento correto de uma câmera e sensores.

Implementações de dispositivos:

  • [C-0-1] É PRECISO executar corretamente todos os casos aplicáveis no verificador do CTS.

O Verificador do CTS tem testes para muitos tipos de hardware, incluindo alguns opcionais.

Implementações de dispositivos:

  • [C-0-2] É PRECISO passar em todos os testes de hardware que eles têm. Por exemplo, se um dispositivo tiver um acelerômetro, ele PRECISA executar corretamente o caso de teste do acelerômetro no Verificador do CTS.

Os casos de teste para recursos indicados como opcionais neste documento de definição de compatibilidade PODEM ser pulados ou omitidos.

  • [C-0-2] Todos os dispositivos e builds precisam executar corretamente o Verificador CTS, conforme observado acima. No entanto, como muitos builds são muito semelhantes, não é esperado que os implementadores de dispositivos executem explicitamente o Verificador do CTS em builds que diferem apenas de maneiras triviais. Especificamente, implementações de dispositivos que diferem de uma implementação que passou pelo Verificador do CTS apenas pelo conjunto de localidades, branding etc. incluídos PODEM omitir o teste do Verificador do CTS.

11. Software atualizável

  • [C-0-1] As implementações de dispositivos precisam incluir um mecanismo para substituir todo o software do sistema. O mecanismo não precisa realizar upgrades "ao vivo", ou seja, pode ser necessário reiniciar o dispositivo.

Qualquer método pode ser usado, desde que ele substitua todo o software pré-instalado no dispositivo. Por exemplo, qualquer uma das seguintes abordagens atende a esse requisito:

  • Downloads "over-the-air (OTA)" com atualização off-line por reinicialização.
  • Atualizações "conectadas" por USB de um PC host.

  • Atualizações "off-line" com uma reinicialização e atualização de um arquivo no armazenamento removível.

  • [C-0-2] O mecanismo de atualização usado PRECISA oferecer suporte a atualizações sem apagar os dados do usuário. Ou seja, o mecanismo de atualização PRECISA preservar os dados privados e compartilhados do app. O software upstream do Android inclui um mecanismo de atualização que atende a esse requisito.

Se as implementações do dispositivo incluem suporte a uma conexão de dados não tarifadas, como o perfil 802.11 ou Bluetooth PAN (rede de área pessoal), elas:

  • [C-1-1] É PRECISO oferecer suporte a downloads OTA com atualização off-line por reinicialização.

Para implementações de dispositivos lançadas com o Android 6.0 e versões mais recentes, o mecanismo de atualização PRECISA oferecer suporte à verificação de que a imagem do sistema é binária idêntica ao resultado esperado após uma atualização OTA. A implementação OTA baseada em blocos no upstream do Android Open Source Project, adicionada desde o Android 5.1, atende a esse requisito.

Além disso, as implementações de dispositivos precisam oferecer suporte a atualizações A/B do sistema. O AOSP implementa esse recurso usando o HAL de controle de inicialização.

Se um erro for encontrado em uma implementação de dispositivo após o lançamento, mas dentro de um período razoável de vida útil do produto determinado em consulta com a equipe de compatibilidade do Android para afetar a compatibilidade de apps de terceiros, faça o seguinte:

  • [C-2-1] O implementador do dispositivo PRECISA corrigir o erro com uma atualização de software disponível que possa ser aplicada de acordo com o mecanismo descrito.

O Android inclui recursos que permitem ao app proprietário do dispositivo (se presente) controlar a instalação de atualizações do sistema. Se o subsistema de atualização do sistema para dispositivos informar android.software.device_admin, ele:

12. Registro de alterações do documento

Para um resumo das mudanças na definição de compatibilidade nesta versão:

Confira um resumo das mudanças nas seções de pessoas:

  1. Introdução
  2. Tipos de dispositivo
  3. Software
  4. Embalagem do aplicativo
  5. Multimídia
  6. Ferramentas e opções para desenvolvedores
  7. Compatibilidade de hardware
  8. Desempenho e potência
  9. Modelo de segurança
  10. Teste de compatibilidade de software
  11. Software atualizável
  12. Registro de alterações do documento
  13. Entre em contato

12.1. Dicas para visualizar o registro de alterações

As mudanças são marcadas da seguinte maneira:

  • CDD
    Mudanças substanciais nos requisitos de compatibilidade.

  • Documentos
    Mudanças cosméticas ou relacionadas ao build.

Para uma melhor visualização, anexe os parâmetros de URL pretty=full e no-merges aos URLs do registro de alterações.

13. Entre em contato

Você pode participar do fórum de compatibilidade com o Android e pedir esclarecimentos ou mencionar problemas que você acha que o documento não aborda.