Definição de compatibilidade do Android 15

1. Introdução

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

O uso de "PRECISA", "NÃO PODE", "OBRIGATÓRIO", "DEVERÁ", "NÃO DEVE", "DEVERIA", "NÃO DEVE", "RECOMENDADO", "PODE" e "OPCIONAL" é de acordo com 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 executando Android 15. Uma "implementação de dispositivo" ou "implementação" é solução de hardware/software tão desenvolvida.

Para ser considerado compatível com o Android 15, o dispositivo implementações PRECISAM atender aos requisitos apresentados nesta seção Definição, incluindo quaisquer documentos incorporados por referência.

Onde essa definição ou os testes de software descritos em a seção 10 for silenciosa, ambígua ou incompletas, é responsabilidade do implementador do dispositivo garantir compatibilidade com as implementações atuais.

Por esse motivo, o Android Open Source Project é a referência e a implementação preferida do Android. Dispositivo implementadores são FORTEMENTE RECOMENDADOS a basear as implementações na o máximo possível no fluxo de origem o código-fonte disponível Android Open Source Project. Embora alguns componentes possam ser substituído por implementações alternativas, é FORTEMENTE RECOMENDADO não seguir essa prática, pois passar nos testes de software se tornará significativamente fica mais difícil. É responsabilidade do implementador garantir compatibilidade comportamental com a implementação padrão do Android, incluindo e além do Teste de Compatibilidade do Android. Por fim, observe que determinados componentes substituições e modificações são expressamente proibidas por este documento.

Muitos dos recursos vinculados a este documento são derivados diretamente ou indiretamente do SDK do Android e será funcionalmente idêntica à na documentação do SDK. Nos casos em que essa Compatibilidade A definição ou o conjunto de teste de compatibilidade discorda do SDK a documentação do SDK é considerada oficial. Qualquer modelo os detalhes fornecidos nos recursos vinculados ao longo deste documento são considerados por inclusão como parte da 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 uma tipo de dispositivo específico. Cada subseção da Seção 2 é é dedicada a um tipo específico de dispositivo.

Todos os outros requisitos que se aplicam universalmente a qualquer dispositivo Android implementações, estão listadas nas seções após a Seção 2. Esses requisitos são chamados de "Requisitos principais" neste documento.

1.1.2. ID do requisito

O ID do requisito é atribuído para os requisitos OBRIGATÓRIOS.

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

Cada ID é definido conforme abaixo:

  • ID do tipo de dispositivo (mais informações em 2. Tipos de dispositivos)
    • C: Principais requisitos aplicados a todas as implementações de dispositivos Android.
    • H: Dispositivo portátil Android
    • T: Dispositivo Android Television
    • R: Implementação no Android Automotive
    • W: implementação do Android Watch
    • Guia: implementação nos tablets Android
  • ID da condição
    • Quando o requisito é incondicional, esse ID é definido como 0.
    • Quando o requisito é condicional, 1 é atribuído ao primeiro e o número aumenta em 1 na mesma seção, e do mesmo tipo de dispositivo.
  • ID do requisito
    • Esse ID começa em 1 e incrementa em 1 dentro da mesma seção, e a mesma condição.

1.1.3 ID do requisito na seção 2

Os IDs de requisitos na Seção 2 têm duas partes. A primeira corresponde a um ID de seção, conforme descrito acima. A segunda parte identifica formato e o requisito específico dele.

ID da seção, 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 dispositivos

O Android Open Source Project fornece uma pilha de software que pode ser usada para uma variedade de tipos de dispositivos e formatos. Para reforçar a segurança dos dispositivos, da pilha de software, incluindo SOs substitutos ou kernels alternativos deve ser executada em um ambiente seguro, conforme descrito na seção 9 e em outras seções deste CDD. Existem alguns tipos de dispositivos com 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 tipo de dispositivo.

Todas as implementações de dispositivos Android que não se encaixam em nenhuma das os tipos de dispositivos PRECISAM atender a todos os requisitos das demais seções deste documento. Definição de compatibilidade.

2.1 Configurações do dispositivo

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

2.2. Requisitos para dispositivos portáteis

Um dispositivo portátil Android é uma implementação de dispositivo Android que é normalmente usado segurando-o na mão, como um player de mp3, telefone ou tablet.

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

  • usar uma fonte de energia que ofereça mobilidade, como uma bateria;
  • Ter um tamanho de tela diagonal físico dentro do intervalo de 4 a 8 polegadas.
  • Ter uma interface de entrada touchscreen.

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

Observação:os requisitos que não se aplicam a Tablets Android são marcados com um *.

2.2.1. Hardware

Implementações de dispositivos portáteis:

  • [7.1.1.1/H-0-1] PRECISA ter pelo menos um Tela compatível com Android de pelo menos 2,2" na borda curta e 3,4" na borda longa.
  • [7.1.1.3/H-SR-1] É FORTEMENTE RECOMENDADO para fornecem aos usuários uma affordance para alterar o tamanho de exibição (densidade da tela).

  • [7.1.1.1/H-0-2] PRECISA oferecer suporte à composição de GPU de Os buffers gráficos têm no mínimo a maior resolução de qualquer exibição.

  • [7.1.1.1/H-0-3]* PRECISA mapear cada UI_MODE_NORMAL tela disponibilizada para aplicativos de terceiros em um local área de exibição física de pelo menos 2,2" polegadas na borda curta e 3,4" centímetros na borda longa.

  • [7.1.1.3/H-0-1]* PRECISA definir o valor de DENSITY_DEVICE_STABLE seja 92% ou maior do que a densidade física real da exibição correspondente.

Se as implementações de dispositivos portáteis tiverem suporte ao Vulkan, elas:

Se as implementações de dispositivos portáteis forem compatíveis com High Dynamic Range exibições por meio de Configuration.isScreenHdr() , eles:

  • [7.1.4.5/H-1-1] PRECISA anunciar o suporte para o EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace e VK_EXT_hdr_metadata extensões.

Implementações de dispositivos portáteis:

  • [7.1.4.6/H-0-1] PRECISA informar se o dispositivo oferece suporte à criação de perfil da GPU por uma propriedade do sistema graphics.gpu.profiler.support

Se as implementações de dispositivos portáteis declararem suporte por meio de uma propriedade do sistema graphics.gpu.profiler.support, eles:

Implementações de dispositivos portáteis:

  • [7.1.5/H-0-1] PRECISA incluir suporte para modelos legados. o modo de compatibilidade do aplicativo conforme implementado pelo Android upstream o código-fonte. Ou seja, as implementações de dispositivos NÃO PODEM alterar os acionadores ou limites em que o modo de compatibilidade é ativado e NÃO PODE alterar o do próprio modo de compatibilidade.
  • [7.2.1/H-0-1] PRECISA incluir suporte para terceiros. Aplicativos do Editor de método de entrada (IME, na sigla em inglês).
  • [7.2.3/H-0-2] PRECISA enviar os comandos normal e longo Evento da função Voltar (KEYCODE_BACK) para o aplicativo em primeiro plano. Esses eventos NÃO PODEM ser consumidos pelo sistema e PODE ser acionado fora do dispositivo Android (por exemplo, hardware externo teclado conectado ao dispositivo Android).
  • [7.2.3/H-0-3] PRECISA fornecer a função Home no todas as telas compatíveis com Android que fornecem a tela inicial.
  • [7.2.3/H-0-4] PRECISA fornecer a função "Voltar" em todas telas compatíveis com Android e a função Recentes em pelo menos um telas compatíveis com Android.
  • [7.2.4/H-0-1] PRECISA oferecer suporte à entrada touchscreen.
  • [7.2.4/H-SR-1] É FORTEMENTE RECOMENDADO para lançar a app assistivo selecionado pelo usuário, ou seja, o app que implementa VoiceInteractionService ou uma atividade que processa a ACTION_ASSIST (link em inglês). ao tocar e manter o botão KEYCODE_MEDIA_PLAY_PAUSE pressionado ou KEYCODE_HEADSETHOOK se a atividade em primeiro plano não processar esses eventos de tocar e manter pressionado.
  • [7.3.1/H-SR-1] É MUITO RECOMENDADO a inclusão de um eixo acelerômetro.

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

  • [7.3.1/H-1-1] PRECISA relatar eventos até uma frequência. de pelo menos 100 Hz.

Se as implementações de dispositivos portáteis incluírem um receptor GPS/GNSS e informarem o aos aplicativos pelo recurso android.hardware.location.gps ele:

  • [7.3.3/H-2-1] PRECISA informar as medições de GNSS assim que elas forem encontrados, mesmo que uma localização calculada a partir de GPS/GNSS ainda não tenha sido relatada.
  • [7.3.3/H-2-2] PRECISA informar as pseudodistâncias e pseudodistâncias do GNSS. em condições de céu aberto após a determinação do local, enquanto parado ou em movimento com menos de 0,2 metro por segundo ao quadrado de são suficientes para calcular uma posição dentro de 20 metros, e a velocidade em 0,2 metro por segundo, pelo menos 95% do tempo.

Se as implementações de dispositivos portáteis incluírem um giroscópio de três eixos, elas:

  • [7.3.4/H-3-1] PRECISA relatar eventos até uma frequência. de pelo menos 100 Hz.
  • [7.3.4/H-3-2] PRECISA ser capaz de medir mudanças de orientação. até 1.000 graus por segundo.

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

  • [7.3,8/H] DEVEM incluir um sensor de proximidade.

Implementações de dispositivos portáteis:

  • [7.3.11/H-SR-1] É FORTEMENTE RECOMENDADO para oferecer suporte ao sensor de pose com 6 graus de liberdade.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [7.4.3/H] DEVE incluir suporte para Bluetooth e Bluetooth LE.

Implementações de dispositivos portáteis que incluem suporte para Bluetooth LE:

  • [7.4.3/H-SR-1] É FORTEMENTE RECOMENDADO para o suporte Extensão de comprimento do pacote de dados Bluetooth LE.

Encerrar novos requisitos

Se os dispositivos forem compatíveis com o protocolo Wi-Fi Neighbor Awareness Networking (NAN) declarar PackageManager.FEATURE_WIFI_AWARE e a localização de Wi-Fi (Wi-Fi Round Tempo de viagem (RTT)) ao declarar PackageManager.FEATURE_WIFI_RTT. Depois, eles:

  • [7.4.2.5/H-1-1] PRECISA informar o intervalo com precisão para dentro de +/-1 metro a uma largura de banda de 160 MHz no 68o percentil (conforme calculado com a função de distribuição cumulativa), +/-2 metros a 80 MHz de largura de banda a no 68o percentil, +/-4 metros a 40 MHz de largura de banda no 68o percentil, e +/-8 metros a uma largura de banda de 20 MHz no 68o percentil a distâncias de 10 cm, 1 m, 3 m e 5 m, conforme observado pelo API WifiRttManager#startRanging do Android.

  • [7.4.2.5/H-SR-1] É FORTEMENTE RECOMENDADO para informar o intervalo com precisão de +/-1 metro a uma largura de banda de 160 MHz no 90o percentil (conforme calculado com a função de distribuição cumulativa), +/-2 metros a 80 MHz de largura de banda no 90o percentil, +/- 4 metros a 40 MHz largura de banda no 90o percentil e +/-8 metros a 20 MHz de largura de banda no 90o percentil a distâncias de 10 cm, conforme observado pelo API WifiRttManager#startRanging do Android.

É RECOMENDADO seguir as etapas de configuração de medição especificadas no Calibragem de presença.

Se as implementações de dispositivos portáteis declararem FEATURE_BLUETOOTH_LE, elas:

  • [7.4.3/H-1-3] PRECISA medir e compensar Rx para garantir que o RSSI médio do BLE seja -50 dBm +/-15 dB a 1 m de distância de um dispositivo de referência transmitindo em ADVERTISE_TX_POWER_HIGH.
  • [7.4.3/H-1-4] PRECISA medir e compensar Tx para garantir que o RSSI médio do BLE seja -50 dBm +/-15 dB ao ler a partir de dispositivo de referência posicionado a 1 m de distância e transmitindo a ADVERTISE_TX_POWER_HIGH

Se as implementações de dispositivos portáteis incluírem um dispositivo de câmera lógico que liste recursos usando CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, eles:

  • [7.5.4/H-1-1] PRECISA ter o campo de visão (FOV) normal por padrão e PRECISA estar entre 50 e 50 graus.

Implementações de dispositivos portáteis:

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

Se as implementações de dispositivos portáteis declararem compatibilidade somente com ABI 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 416 MB se a exibição padrão usar framebuffer resoluções até qHD (por exemplo, FWVGA).

  • [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 592 MB se a exibição padrão usar framebuffer resoluções até HD+ (por exemplo, HD, WSVGA).

  • [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 a exibição padrão usar framebuffer resoluções até FHD (ex.: WSXGA+).

  • [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 1.344 MB se a tela padrão usar resoluções de framebuffer até QHD (por exemplo, QWXGA).

Se as implementações de dispositivos portáteis declararem compatibilidade com qualquer ABI de 64 bits (com ou sem ABI de 32 bits):

  • [7.6.1/H-5-1] A memória disponível para o kernel e o espaço do usuário PRECISAM ter pelo menos 816 MB se a tela padrão usar resoluções de framebuffer acima para qHD (por exemplo, FWVGA).

  • [7.6.1/H-6-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser pelo menos 944 MB se a tela padrão usar resoluções de framebuffer até HD+ (por exemplo, HD, WSVGA).

  • [7.6.1/H-7-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser pelo menos 1.280 MB se a tela padrão usar resoluções de framebuffer até FHD (por exemplo, WSXGA+).

  • [7.6.1/H-8-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser pelo menos 1.824 MB se a tela padrão usar resoluções de framebuffer até QHD (por exemplo, QWXGA).

Observe que a "memória disponível para o kernel e o espaço do usuário" acima refere-se à além de qualquer memória já dedicada ao hardware como rádio, vídeo, entre outros, que não estão no kernel nas implementações de dispositivos.

Se as implementações de dispositivos portáteis incluírem menos ou iguais a 1 GB de memória disponíveis para o kernel e o espaço do usuário, eles:

  • [7.6.1/H-9-1] PRECISA declarar a flag de recurso. android.hardware.ram.low.
  • [7.6.1/H-9-2] PRECISA ter pelo menos 1,1 GB de armazenamento não volátil para aplicativos dados privados (também conhecida como partição "/data").

Se as implementações de dispositivos portáteis incluírem mais de 1 GB de memória disponível ao kernel e ao espaço do usuário, eles:

  • [7.6.1/H-10-1] PRECISA ter pelo menos 4 GB de não volátil disponível para dados privados do aplicativo (também conhecida como partição "/data").
  • DEVE declarar a flag de recurso android.hardware.ram.normal.

Se as implementações de dispositivos portáteis incluírem maior ou igual a 2 GB e menos de 4 GB de memória disponíveis para o kernel e o espaço do usuário, eles:

  • [7.6.1/H-SR-1] É FORTEMENTE RECOMENDADO para oferecer suporte apenas ao espaço do usuário de 32 bits (apps e código do sistema)

Se as implementações de dispositivos portáteis incluírem menos de 2 GB de memória disponível para o kernel e o espaço do usuário, eles:

  • [7.6.1/H-1-1] PRECISA oferecer suporte a apenas uma ABI (somente 64 ou 32 bits). apenas).

Implementações de dispositivos portáteis:

  • [7.6.2/H-0-1] NÃO PODE fornecer uma inscrição armazenamento compartilhado menor que 1 GiB.
  • [7.7.1/H] DEVE incluir uma porta USB compatível com o modo de periféricos.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Se as implementações de dispositivos portáteis incluírem uma porta USB apoio com um controlador operando no modo periférico, eles:

  • [7.7.1/H-1-1] PRECISA implementar o Android Open Accessory (AOA). API.

Encerrar novos requisitos

Se as implementações de dispositivos portáteis incluírem uma porta USB compatível com o modo host, eles:

  • [7.7.2/H-1-1] PRECISA implementar a classe de áudio USB. conforme documentado na documentação do SDK do Android.

Implementações de dispositivos portáteis:

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

Se as implementações de dispositivos portáteis forem capazes de atender a todos os requisitos de desempenho requisitos para oferecer suporte ao modo RV e incluir suporte para ele, eles:

  • [7.9.1/H-1-1] PRECISA declarar a android.hardware.vr.high_performance.
  • [7.9.1/H-1-2] PRECISA incluir um aplicativo implementar android.service.vr.VrListenerService que podem ser ativados pela RV pelo android.app.Activity#setVrModeEnabled.

Se as implementações de dispositivos portáteis incluírem uma ou mais portas USB-C no host e implementar (classe de áudio USB), além dos requisitos de seção 7.7.2, eles:

  • [7.8.2.2/H-1-1] PRECISA fornecer o seguinte mapeamento de software de códigos HID:
Função Mapeamentos Contexto Comportamento
A Página de uso do HID: 0x0C
Uso de HID: 0x0CD
Chave do kernel: KEY_PLAYPAUSE
Chave do Android: KEYCODE_MEDIA_PLAY_PAUSE
Controles de mídia Entrada: pressione rapidamente
Saída: reproduzir ou pausar
Entrada: toque e mantenha pressionado
. Saída: iniciar o comando de voz
Envios: android.speech.action.VOICE_SEARCH_HANDS_FREE se o dispositivo está bloqueado ou a tela está desligada. Envios Caso contrário android.speech.RecognizerIntent.ACTION_WEB_SEARCH
Chamada recebida Entrada: pressione rapidamente
Saída: aceitar chamada
Entrada: toque e mantenha pressionado
. Saída: rejeitar chamada
Chamada em andamento Entrada: pressione rapidamente
Saída: fim da chamada
Entrada: toque e mantenha pressionado
. Saída: ativar ou desativar o som do microfone
B Página de uso do HID: 0x0C
Uso de HID: 0x0E9
Chave do kernel: KEY_VOLUMEUP
Chave do Android: VOLUME_UP
Reprodução de mídia, ligação em andamento Entrada: toque curto ou longo
Saída: aumenta o volume do sistema ou do fone de ouvido
C Página de uso do HID: 0x0C
Uso de HID: 0x0EA
Chave do kernel: KEY_VOLUMEDOWN
Chave do Android: VOLUME_DOWN
Reprodução de mídia, ligação em andamento Entrada: toque curto ou longo
Saída: diminui o volume do sistema ou do fone de ouvido.
D Página de uso do HID: 0x0C
Uso de HID: 0x0CF
Chave do kernel: KEY_VOICECOMMAND
Chave do Android: KEYCODE_VOICE_ASSIST
Todas. Pode ser acionado em qualquer instância. Entrada: toque curto ou longo
Saída: iniciar o comando de voz
  • [7.8.2.2/H-1-2] PRECISA acionar ACTION_HEADSET_PLUG na inserção de um plugue, mas somente depois que as interfaces de áudio USB e os endpoints foram enumerados corretamente para identificar o tipo de terminal conectado.

Quando o terminal de áudio USB do tipo 0x0302 é detectado, ele:

  • [7.8.2.2/H-2-1] PRECISA transmitir a intent ACTION_HEADSET_PLUG com "microfone" o extra é definido como zero.

Quando o terminal de áudio USB do tipo 0x0402 é detectado, ele:

  • [7.8.2.2/H-3-1] PRECISA transmitir a intent ACTION_HEADSET_PLUG com "microfone" o extra foi definido como 1.

Quando a API AudioManager.getDevices() é chamada enquanto o periférico USB está conectaram:

  • [7.8.2.2/H-4-1] PRECISA listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_HEADSET e função isSink() se o campo de tipo de terminal de áudio USB for 0x0302.

  • [7.8.2.2/H-4-2] PRECISA listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_HEADSET e função isSink() se o terminal de áudio USB é 0x0402.

  • [7.8.2.2/H-4-3] PRECISA listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_HEADSET e função isSource() se o terminal de áudio USB é 0x0402.

  • [7.8.2.2/H-4-4] PRECISA listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_DEVICE. e função isSink() se o campo de tipo de terminal de áudio USB for 0x603.

  • [7.8.2.2/H-4-5] PRECISA listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_DEVICE e função isSource() se o terminal de áudio USB é 0x604.

  • [7.8.2.2/H-4-6] PRECISA listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_DEVICE e função isSink() se o tipo de terminal de áudio USB é 0x400.

  • [7.8.2.2/H-4-7] PRECISA listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_DEVICE e função isSource() se o terminal de áudio USB campo de tipo é 0x400.

  • [7.8.2.2/H-SR-1] São RECOMENDADOS FORTEMENTE na conexão de um Periférico de áudio USB-C, para realizar a enumeração de descritores USB, identificar e transmitir a intent ACTION_HEADSET_PLUG em menos de 1.000 milissegundos.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Se Para Implementações de dispositivos portáteis que declarem android.hardware.audio.output e android.hardware.microphone, eles: consulte os requisitos de RTL e TTL na seção 5.6.

  • [5.6/H-1-1] PRECISA ter uma viagem de ida e volta contínua média de 300 milissegundos ou menos de 5 medições, com um Desvio médio absoluto menor que 30 ms, acima estes caminhos de dados: "alto-falante para o microfone", Adaptador de loopback de 3,5 mm (se compatível), loopback USB (se compatível).

  • [5.6/H-1-2] PRECISA ter uma latência média entre toques. de 300 milissegundos ou menos em pelo menos cinco medições pelo alto-falante para o caminho de dados do microfone.

Encerrar novos requisitos

Um atuador ressonante linear (LRA, na sigla em inglês) é um sistema de mola de massa simples com frequência ressonante dominante, em que a massa se traduz na direção movimento desejado.

Se as implementações de dispositivos portáteis incluírem pelo menos um 7.10 de uso geral atuador ressonante linear, eles:

  • [7,10/H] DEVE posicionar o posicionamento do atuador próximo o local em que o dispositivo normalmente é segurado ou tocado pelas mãos.

  • [7,10/H] DEVE mover o atuador tátil no eixo X (esquerda-direita) da orientação natural do dispositivo.

Se as implementações de dispositivos portáteis tiverem uma finalidade geral atuador tátil, que é um atuador ressonante linear do eixo X (LRA, na sigla em inglês), eles:

  • [7,10/H] A frequência ressonante do LRA do eixo X DEVE ser menor que 200 Hz.

Se as implementações de dispositivos portáteis seguirem o mapeamento de constantes táteis, elas:

2.2.2. Multimídia

As implementações de dispositivos portáteis PRECISAM ser compatíveis com as seguintes codificações de áudio e formatos de decodificação e disponibilizá-los para aplicativos de terceiros:

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

As implementações de dispositivos portáteis PRECISAM ser compatíveis com a seguinte codificação de vídeo formatos e disponibilizá-los para aplicativos de terceiros:

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

As implementações de dispositivos portáteis PRECISAM ser compatíveis com a seguinte decodificação de vídeo formatos e disponibilizá-los para aplicativos de terceiros:

  • [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
  • [5.3/H-0-6] AV1

2.2.3. Software

Implementações de dispositivos portáteis:

  • [3.2.3.1/H-0-1] PRECISA ter uma aplicativo que lida com o ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, e ACTION_CREATE_DOCUMENT intents conforme descrito nos documentos do SDK e fornecem a affordance do usuário para acessar os dados do provedor de documentos usando a API DocumentsProvider.
  • [3.2.3.1/H-0-2]* PRECISA pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents, para todos os padrões de filtro de intent pública definidos pelo seguinte aplicativo intents listadas aqui.
  • [3.2.3.1/H-SR-1] São FORTES RECOMENDADO de pré-carregar um aplicativo de e-mail que pode lidar com ACTION_SENDTO ou ACTION_SEND ou ACTION_SEND_MULTIPLE para enviar um e-mail.
  • [3.4.1/H-0-1] PRECISA fornecer um implementação da API android.webkit.Webview.
  • [3.4.2/H-0-1] PRECISA incluir um navegador autônomo. para a navegação na Web de usuários gerais.
  • [3.8.1/H-SR-1] São FORTEMENTE RECOMENDADOS para implementar uma tela de início padrão com suporte à fixação de atalhos no app. widgets e widgetFeatures.
  • [3.8.1/H-SR-2] São FORTEMENTE RECOMENDADOS implementar um inicializador padrão que fornece acesso rápido aos recursos atalhos fornecidos por apps de terceiros usando o ShortcutsManager API.
  • [3.8.1/H-SR-3] São FORTEMENTE RECOMENDADOS para incluir um app de tela de início padrão que mostra selos para os ícones de apps.
  • [3.8.2/H-SR-1] São FORTEMENTE RECOMENDADOS para oferecer suporte a widgets de apps de terceiros.
  • [3.8.3/H-0-1] PRECISA permitir serviços de terceiros para notificar os usuários sobre eventos importantes usando o Notification e o NotificationManager Classes de API.
  • [3.8.3/H-0-2] PRECISA ser compatível com rich notificações.
  • [3.8.3/H-0-3] PRECISA ser compatível com os avisos notificações.
  • [3.8.3/H-0-4] PRECISA incluir um aba de notificações, fornecendo ao usuário a capacidade de controlar diretamente (por exemplo, responder, adiar, dispensar, bloquear) as notificações por meio de affordance do usuário, como ou o painel de controle conforme implementado no AOSP.
  • [3.8.3/H-0-5] PRECISA mostrar as opções fornecido pelo parceiro RemoteInput.Builder setChoices() na aba de notificações.
  • [3.8.3/H-SR-1] São FORTEMENTE RECOMENDADOS para mostrar a primeira opção fornecida por RemoteInput.Builder setChoices() na aba de notificações sem precisar de interação adicional do usuário.
  • [3.8.3/H-SR-2] São FORTEMENTE RECOMENDADOS para mostrar todas as opções fornecidas em RemoteInput.Builder setChoices() na aba de notificações quando o usuário expandir todas as notificações da aba de notificações.
  • [3.8.3.1/H-SR-1] São FORTEMENTE RECOMENDADOS para mostrar ações para quais Notification.Action.Builder.setContextual está definido como true alinhado com as respostas exibidas por Notification.Remoteinput.Builder.setChoices.
  • [3.8.4/H-SR-1] São FORTEMENTE RECOMENDADOS para implementar um assistente no dispositivo e processar a ação de assistência.

Se as implementações de dispositivos portáteis forem compatíveis com notificações do MediaStyle eles:

  • [3.8.3.1/H-SR-2] São FORTEMENTE RECOMENDADOS para fornecer uma funcionalidade de usuário (por exemplo, seletor de saída) acessada interface do sistema que permite aos usuários alternar entre as mídias adequadas disponíveis rotas (por exemplo, dispositivos Bluetooth e rotas fornecidas para MediaRouter2Manager). quando um app posta uma notificação MediaStyle com um token MediaSession.

Se as implementações do dispositivo, incluindo a tecla de navegação da função Recentes, como detalhadas na seção 7.2.3 alteram a interface, eles:

  • [3.8.3/H-1-1] PRECISA implementar a tela. comportamento de fixação e fornecer ao usuário um menu de configurações para alternar o .

Se as implementações de dispositivos portáteis forem compatíveis com a ação de assistência, elas:

  • [3.8.4/H-SR-2] São FORTEMENTE RECOMENDADOS para usar a tecla HOME como a interação designada para iniciar o como descrito na seção 7.2.3. PRECISA ser lançado o app assistivo selecionado pelo usuário, ou seja, o app que implementa VoiceInteractionService, ou uma atividade que processa a intent ACTION_ASSIST.

Se as implementações de dispositivos portáteis forem compatíveis com conversation notifications e agrupe-as em uma seção separada dos alertas e das conversas silenciosas notificações, eles:

  • [3.8.4/H-1-1]* PRECISA exibir notificações de conversa antes das notificações que não são de conversa com com exceção das notificações de serviços em primeiro plano importance:alta notificações.

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

  • [3.8.10/H-1-1] PRECISA exibir o ícone de cadeado. Notificações da tela, incluindo o Modelo de notificação de mídia.

Se as implementações de dispositivos portáteis forem compatíveis com uma tela de bloqueio segura, elas:

Se as implementações de dispositivos portáteis incluírem suporte para ControlsProviderService e Control e permitem que aplicativos de terceiros publiquem controles de dispositivos. Em seguida, eles:

  • [3.8.16/H-1-1] PRECISA declarar o recurso sinalizar android.software.controls e a defina como true.
  • [3.8.16/H-1-2] PRECISA fornecer um usuário com a capacidade de adicionar, editar, selecionar e operar o ambiente controles de dispositivo favoritos dos controles registrados pelo terceiro aplicativos por meio do ControlsProviderService e o Control APIs de terceiros.
  • [3.8.16/H-1-3] PRECISA fornecer acesso a essa funcionalidade do usuário dentro de três interações de uma tela de início padrão.
  • [3.8.16/H-1-4] PRECISA renderizar com precisão nesta funcionalidade de usuário, o nome e o ícone de cada aplicativo de terceiros que oferece controles pelo ControlsProviderService a API, bem como quaisquer campos especificados fornecidos pela Control APIs de terceiros.

  • [3.8.16/H-1-5] PRECISA fornecer um usuário affordance para desativar os controles de dispositivo de autenticação triviais designados pelo aplicativo controles registrados pelos aplicativos de terceiros por meio do ControlsProviderService e o Control API Control.isAuthRequired.

  • [3.8.16/H-1-6] Implementações de dispositivos PRECISA renderizar com precisão a affordance do usuário da seguinte forma:

    • Se o dispositivo tiver definido config_supportsMultiWindow=true e o app declarar os metadados META_DATA_PANEL_ACTIVITY no ControlsProviderService declaração, incluindo o ComponentName de um uma atividade válida (conforme definido pela API), o app PRECISA incorporar essa atividade nesta funcionalidade do usuário.
    • Se o app não declarar os metadados META_DATA_PANEL_ACTIVITY, ele PRECISA renderizar os campos especificados conforme fornecido pelo ControlsProviderService a API, bem como quaisquer campos especificados fornecidos pela Control APIs.
  • [3.8.16/H-1-7] Se o app declarar os metadados META_DATA_PANEL_ACTIVITY, ele PRECISA passar o valor da configuração definida em [3.8.16/H-1-5] usando EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS ao iniciar a atividade incorporada.

Por outro lado, se as implementações de dispositivos portáteis não implementarem esses controles, eles:

Se as implementações de dispositivos portáteis não estiverem em execução no modo de bloqueio de tarefas, quando o conteúdo for copiado para a área de transferência, elas:

  • [3.8.17/H-1-1] PRECISA apresentar uma confirmação ao usuário de que os dados foram copiado para a área de transferência (por exemplo, uma miniatura ou alerta de "Conteúdo copiado"). Além disso, inclua uma indicação se os dados da área de transferência serão sincronizados. entre dispositivos.

Implementações de dispositivos portáteis:

  • [3.10/H-0-1] PRECISA ser compatível com acessibilidade de terceiros. serviços.
  • [3.10/H-SR-1] É FORTEMENTE RECOMENDADO o pré-carregamento serviços de acessibilidade no dispositivo comparáveis com funcionalidades superiores ou iguais a elas do acesso com interruptor e do TalkBack (para os idiomas compatíveis com os recursos mecanismo de conversão de texto em voz) conforme fornecido no talkback aberto no projeto de origem.
  • [3.11/H-0-1] PRECISA ser compatível com a instalação do mecanismos TTS de terceiros.
  • [3.11/H-SR-1] É FORTEMENTE RECOMENDADO a inclusão de um Mecanismo de TTS com suporte para os idiomas disponíveis no dispositivo.
  • [3.13/H-SR-1] É FORTEMENTE RECOMENDADO a inclusão de um Componente de interface das Configurações rápidas.

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

  • [3.16/H-1-1] PRECISA oferecer suporte ao pareamento do dispositivo complementar .

Se a função de navegação for fornecida como uma ação na tela baseada em gestos:

  • [7.2.3/H] A zona de reconhecimento de gestos da casa DEVE ter no máximo 32 dp de altura a partir da parte inferior tela.

Se as implementações de dispositivos portáteis fornecerem uma função de navegação como um gesto de qualquer lugar nas extremidades esquerda e direita da tela:

  • [7.2.3/H-0-1] A área de gestos da função de navegação PRECISA ter menos de 40 dp de largura em cada lado. A área de gestos DEVE ser 24 dp de largura por padrão.

Se as implementações de dispositivos portáteis forem compatíveis com uma tela de bloqueio segura e tiverem mais ou igual a 2 GB de memória disponível para o kernel e o espaço do usuário, eles:

  • [3.9/H-1-2] PRECISA declarar o suporte de perfis gerenciados pela Sinalização de recurso android.software.managed_users.

Se as implementações de dispositivos portáteis Android declararem suporte à câmera por meio de android.hardware.camera.any eles:

Se o aplicativo de configurações da implementação do dispositivo implementar uma funcionalidade dividida, usando a incorporação de atividades, eles:

Se as implementações de dispositivos permitirem que os usuários façam qualquer tipo de ligação, eles

2.2.4 Desempenho e potência

  • [8.1/H-0-1] Latência de frame consistente. Latência de frame inconsistente ou um atraso na renderização de frames NÃO PODEM acontecer com mais frequência geralmente que 5 quadros por segundo e DEVE estar abaixo de 1 quadros por segundo.
  • [8.1/H-0-2] Latência da interface do usuário. As implementações de dispositivos DEVEM garantir uma experiência do usuário de baixa latência rolando uma lista de 10 mil entradas de lista, conforme definido pelo Teste de compatibilidade do Android. (CTS) em menos de 36 segundos.
  • [8.1/H-0-3] Troca de tarefas. Quando vários aplicativos foram lançados, retomando um após o lançamento PRECISA levar menos de um segundo.

Implementações de dispositivos portáteis:

  • [8.2/H-0-1] PRECISA garantir uma sequência de gravação de pelo menos 5 MB/s.
  • [8.2/H-0-2] PRECISA garantir que uma gravação aleatória e desempenho de pelo menos 0,5 MB/s.
  • [8.2/H-0-3] PRECISA garantir uma leitura sequencial. e desempenho de pelo menos 15 MB/s.
  • [8.2/H-0-4] PRECISA garantir uma leitura aleatória. e desempenho de pelo menos 3,5 MB/s.

Se as implementações de dispositivos portáteis incluírem recursos para melhorar a potência do dispositivo de código aberto incluídos no AOSP ou que ampliem os recursos incluídos no AOSP:

  • [8.3/H-1-1] PRECISA fornecer recursos do usuário para ativar e desative o recurso de economia de bateria.
  • [8.3/H-1-2] PRECISA fornecer recursos do usuário para exibir todos os apps isentos dos modos de economia de energia "App em espera" e "Soneca".

Implementações de dispositivos portáteis:

  • [8.4/H-0-1] PRECISA fornecer uma perfil de energia por componente que define o valor de consumo atual para cada componente de hardware e o consumo aproximado da bateria causado pelo ao longo do tempo, conforme documentado no site do Android Open Source Project.
  • [8.4/H-0-2] PRECISA informar toda a energia valores de consumo em milissegundos/hora (mAh).
  • [8.4/H-0-3] PRECISA informar a energia da CPU e consumo de acordo com o UID de cada processo. O Android Open Source Project atende à requisito pela implementação do módulo do kernel uid_cputime.
  • [8.4/H-0-4] PRECISA fazer esse uso de energia disponível no adb shell dumpsys batterystats shell para o desenvolvedor do app.
  • [8,4/H] DEVE ser atribuída ao componente de hardware em si, 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 saída de tela ou vídeo, elas:

Implementações de dispositivos portáteis:

  • [8.5/H-0-1] PRECISA fornecer uma funcionalidade de usuário para ver todos os aplicativos com serviços em primeiro plano ativos ou iniciados pelo usuário, incluindo a duração de cada um desses serviços desde que foi iniciado, conforme descrito no documento do SDK.

  • [8.5/H-0-2]DEVE fornecer uma funcionalidade de usuário para interromper um app que está executando um serviço em primeiro plano ou um job iniciado pelo usuário.

2.2.5 Modelo de segurança

Implementações de dispositivos portáteis:

  • [9/H-0-1] PRECISA declarar a android.hardware.security.model.compatible .
  • [9.1/H-0-1] PRECISA permitir que apps de terceiros acessem a estatísticas de uso com a permissão android.permission.PACKAGE_USAGE_STATS e fornecer um mecanismo acessível ao usuário para conceder ou revogar o acesso a esses aplicativos em resposta aos android.settings.ACTION_USAGE_ACCESS_SETTINGS intenção.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

As implementações de dispositivos PRECISAM declarar compatibilidade com android.software.credentials e:

  • [9/H-0-2] PRECISA respeitar a intent android.settings.CREDENTIAL_PROVIDER. para permitir a seleção de um provedor preferido para o Gerenciador de credenciais. O Preenchimento automático e o também será o local padrão para salvar novas credenciais inseridos pelo Gerenciador de credenciais.

  • [9/H-0-3] PRECISA oferecer suporte a pelo menos dois provedores de credenciais simultâneos e fornecem uma funcionalidade de usuário no app Configurações para ativar ou desativar provedores.

Encerrar novos requisitos

Se as implementações de dispositivos declararem suporte a android.hardware.telephony: eles:

  • [9.5/H-1-1] NÃO PODE definir UserManager.isHeadlessSystemUserMode para true.

Implementações de dispositivos portáteis:

  • [9.11/H-0-2] PRECISA fazer backup da implementação de keystore. com um ambiente de execução isolado.
  • [9.11/H-0-3] PRECISA ter implementações de RSA, AES, Algoritmos criptográficos ECDSA e HMAC e família MD5, SHA-1 e SHA-2 para oferecer suporte adequado ao suporte do sistema Android Keystore algoritmos em uma área segura e isolada do código em execução kernel e acima. O isolamento seguro PRECISA bloquear todos os possíveis mecanismos. pelo qual o código do kernel ou do espaço do usuário pode acessar o estado interno da ambiente isolado, incluindo DMA. O Android Open Source upstream O Project (AOSP) atende a esse requisito usando a implementação Trusty, mas outra Uma solução baseada em ARM TrustZone ou uma solução verificada por terceiros como segura a implementação adequada de um isolamento baseado em hipervisor são alternativas .
  • [9.11/H-0-4] PRECISA executar a tela de bloqueio. no ambiente de execução isolado e somente ao bem-sucedido, permite o uso das chaves vinculadas à autenticação. Bloquear tela as credenciais PRECISAM ser armazenadas de uma forma que permita somente a execução isolada para executar a autenticação da tela de bloqueio. O sistema upstream do Android O Open Source Project oferece Camada de abstração de hardware (HAL) Gatekeeper e o Trusty, que podem ser usados para atender a esse requisito.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [9.11/H-0-5] PRECISA oferecer suporte ao atestado de chaves em que o a chave de assinatura de atestado é protegida por um hardware seguro e a assinatura é executadas em hardware seguro. As chaves de assinatura de atestado PRECISAM ser compartilhadas entre um número grande de dispositivos para impedir as chaves evitados deixem de ser usados como permanentes identificadores de dispositivo. Uma maneira de atender a esse requisito é compartilhar os mesma chave de atestado,a menos que pelo menos 100.000 unidades de uma determinada SKU sejam produzidos. Se mais de 100.000 unidades de uma SKU forem produzidas, outro pode ser usada para cada 100.000 unidades.

Encerrar novos requisitos

Se uma implementação de dispositivo já tiver sido iniciada em uma versão anterior versão, tal dispositivo está isento da exigência de ter um keystore em um ambiente de execução isolado e oferecem suporte ao atestado de chaves, a menos que declare o recurso android.hardware.fingerprint, que requer uma um keystore apoiado por um ambiente de execução isolado.

Quando as implementações de dispositivos portáteis são compatíveis com uma tela de bloqueio segura, elas:

  • [9.11/H-1-1] PRECISA permitir que o usuário escolha a menor tempo limite de suspensão, isto é, o tempo de transição entre o status desbloqueado como 15 segundos ou menos.
  • [9.11/H-1-2] PRECISA fornecer funcionalidade ao usuário para ocultar notificações e desativar todas as formas de autenticação, exceto as autenticação principal descrita em 9.11.1 Tela de bloqueio segura. O AOSP atende como o modo de bloqueio total.

Se as implementações do dispositivo tiverem uma tela de bloqueio segura e incluírem um ou mais agentes de confiança, que implementam a API do sistema TrustAgentService, elas:

  • [9.11.1/H-1-1] PRECISA desafiar o usuário quanto a um dos métodos principais de autenticação recomendados (por exemplo, PIN, padrão ou senha) com mais frequência do que uma vez a cada 72 horas.

Se as implementações de dispositivos portáteis incluírem vários usuários e não declararem a flag de recurso android.hardware.telephony, eles:

  • [9.5/H-2-1] PRECISA oferecer suporte a perfis restritos, um recurso que permite que os proprietários de dispositivos gerenciem outros usuários e do dispositivo. Com 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 de dispositivos portáteis incluírem vários usuários e declararem a flag de recurso android.hardware.telephony, eles:

  • [9.5/H-3-1] NÃO PODE oferecer suporte a restrições perfis, mas PRECISA estar alinhada com a implementação de controles do AOSP para ativar ou desativar o acesso de outros usuários a chamadas de voz e SMS.

Se as implementações de dispositivos portáteis definirem UserManager.isHeadlessSystemUserMode para true, ele

  • [9.5/H-4-1] NÃO PODE incluir suporte para eUICCs, nem para eSIMs com recurso de chamada.
  • [9.5/H-4-2] NÃO PODE declarar suporte para android.hardware.telephony

O Android, pela API do sistema, VoiceInteractionService oferece suporte a um mecanismo para detecção de hotword sempre ativada sem indicação de acesso ao microfone e a detecção de consultas sempre ativada, sem microfone ou câmera indicação de acesso.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Configurações restritas

As configurações restritas fornecem avisos visíveis ao usuário e solicita a confirmação do usuário para conceder permissões para cada aplicativo que:

  • Ser instalado após ser baixado por meio de um aplicativo (por exemplo, um aplicativo de mensagens ou um navegador) que não seja uma "loja de apps" aplicativo identificado por PackageManager como PACKAGE_DOWNLOADED_FILE.
  • Sendo instalado a partir de um arquivo local (por exemplo, o aplicativo foi transferido por sideload) identificado por PackageManager como PACKAGE_SOURCE_LOCAL_FILE.

Para as permissões aplicadas os identificadores associados listados abaixo:

  • Alarmes e lembretes: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
  • Acesso total aos arquivos: AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
  • Sobrepor a outros apps: AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
  • Instalar apps desconhecidos: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
  • Gerenciar mídia: AppOpsManager.OPSTR_MANAGE_MEDIA
  • Modificar configurações do sistema: AppOpsManager.OPSTR_WRITE_SETTINGS
  • Picture-in-picture: AppOpsManager.OPSTR_PICTURE_IN_PICTURE
  • Ativar a tela: AppOpsManager.OPSTR_TURN_SCREEN_ON
  • Notificações em tela cheia: AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
  • Controle de Wi-Fi: AppOpsManager.OPSTR_CHANGE_WIFI_STATE
  • Acessibilidade: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
  • Listener de notificações: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
  • Acesso ao uso: AppOpsManager.OPSTR_GET_USAGE_STATS
  • Administrador do dispositivo: Manifest.permission.BIND_DEVICE_ADMIN
  • Não perturbe: Manifest.permission.MANAGE_NOTIFICATIONS

Esses aplicativos são identificados como "aplicativos cobertos" para os requisitos listados nesta seção.

Implementações de dispositivos:

  • [9.8/H-0-1] PRECISA implementar as configurações restritas, conforme descrito acima para o seguinte:

    • Permissões especiais
      • Acessibilidade (AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE)
      • Listener de notificações (AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS)
      • Apps do administrador do dispositivo (Manifest.permission.BIND_DEVICE_ADMIN)
      • Sobrepor a outros apps (AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW)
      • Acesso ao uso (AppOpsManager.OPSTR_GET_USAGE_STATS)
    • Papéis (apps padrão)
      • Discador (RoleManager.ROLE_DIALER)
      • SMS (RoleManager.ROLE_SMS)
    • Permissões de tempo de execução
      • Tempo de execução de SMS (Manifest.permission_group.SMS)
  • [9.8/H-0-2] PRECISA ativar "Configurações restritas" como padrão e precisa É RECOMENDADO não ter recursos de usuário que permitam para desativar as Configurações restritas em todos os apps.

  • [9,8/H-0-3] PRECISA garantir que a confirmação do usuário seja recebida para cada Aplicativo Coberto antes que qualquer uma das Permissões Aplicadas possa ser concedida.

  • [9.8/H-0-4] É NECESSÁRIO permitir apenas a confirmação do usuário para ativar as configurações restritas seja obtido na página AppInfo do Aplicativo Coberto, usando a API EnhancedConfirmationManager.

  • [9.8/H-0-5] É FORTEMENTE RECOMENDADO para integração e chamada EnhancedConfirmationManager para todas as permissões especiais, para determinar dinamicamente se a configuração é restrita.

    • Alarmes e lembretes: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
    • Acesso total aos arquivos: AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
    • Sobrepor a outros apps: AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
    • Instalar apps desconhecidos: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
    • Gerenciar mídia: AppOpsManager.OPSTR_MANAGE_MEDIA
    • Modificar configurações do sistema: AppOpsManager.OPSTR_WRITE_SETTINGS
    • Picture-in-picture: AppOpsManager.OPSTR_PICTURE_IN_PICTURE
    • Ativar a tela: AppOpsManager.OPSTR_TURN_SCREEN_ON
    • Notificações em tela cheia: AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
    • Controle de Wi-Fi: AppOpsManager.OPSTR_CHANGE_WIFI_STATE
    • Acessibilidade: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
    • Listener de notificações: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
    • Acesso ao uso: AppOpsManager.OPSTR_GET_USAGE_STATS
    • Administrador do dispositivo: Manifest.permission.BIND_DEVICE_ADMIN
    • Não perturbe: Manifest.permission.MANAGE_NOTIFICATIONS
.

Encerrar novos requisitos

Se as implementações de dispositivos portáteis forem compatíveis com a API do sistema HotwordDetectionService ou outro mecanismo para detecção de hotwords sem indicação de acesso ao microfone, eles:

  • [9.8/H-1-1] PRECISA garantir que o serviço de detecção de hotword só possa transmitir dados para o sistema, ContentCaptureService, ou reconhecimento de fala no dispositivo criado pela SpeechRecognizer#createOnDeviceSpeechRecognizer().
  • [9.8/H-1-2] PRECISA garantir que o serviço de detecção de hotword só possa transmitir dados de áudio do microfone ou derivados para o servidor do sistema por meio do API HotwordDetectionService ou para ContentCaptureService por API ContentCaptureManager.
  • [9.8/H-1-3] NÃO PODE fornecer áudio de microfone com mais de 30 segundos para uma solicitação individual acionada por hardware para o serviço de detecção de hotwords.
  • [9.8/H-1-4] NÃO PODE fornecer áudio de microfone em buffer com mais de 8 segundos para um solicitação individual para o serviço de detecção de hotwords.
  • [9.8/H-1-5] NÃO PODE fornecer áudio de microfone em buffer com mais de 30 segundos ao um serviço de interação por voz ou entidade semelhante.
  • [9.8/H-1-6] NÃO PODE permitir mais de 100 bytes de dados (exceto streams de áudio) sejam transmitidos do serviço de detecção de hotword em cada resultado da hotword.
  • [9.8/H-1-7] NÃO PODE permitir a transmissão de mais de 5 bits de dados do serviço de detecção de hotword em cada resultado de hotword negativa.
  • [9.8/H-1-8] PRECISA permitir apenas a transmissão de dados fora da hotword. de detecção em uma solicitação de validação de hotword do servidor do sistema.
  • [9.8/H-1-9] NÃO PODE permitir que um aplicativo instalável pelo usuário forneça a serviço de detecção de hotword do Google.
  • [9.8/H-1-10] NÃO PODE SER na interface do usuário dados quantitativos sobre o uso do microfone por o serviço de detecção de hotwords.
  • [9.8/H-1-11] PRECISA registrar o número de bytes incluídos em cada transmissão do serviço de detecção de hotword para permitir a inspeção de segurança os pesquisadores.
  • [9.8/H-1-12] PRECISA oferecer suporte a um modo de depuração que registre o conteúdo bruto de cada transmissão do serviço de detecção de hotword para permitir inspeção e pesquisadores de segurança.
  • [9.8/H-1-14] PRECISA exibir o indicador de microfone, conforme descrito na seção. 9.8.2, quando um resultado de hotword bem-sucedido é transmitido para a rede serviço de interação ou entidade semelhante.

  • [9.8/H-1-15] PRECISA garantir que os streams de áudio fornecidos com hotword bem-sucedida os resultados são transmitidos unidirecionalmente do serviço de detecção de hotword para o serviço de interação por voz.

  • [9.8/H-SR-1] É FORTEMENTE RECOMENDADO que você notifique os usuários antes de definir uma aplicativo como o provedor do serviço de detecção de hotword.

  • [9.8/H-SR-2] É FORTEMENTE RECOMENDADO para proibir a transmissão de e não estruturados do serviço de detecção de hotwords.

  • [9.8/H-SR-3] É FORTEMENTE RECOMENDADO para reiniciar o processo que hospeda o serviço de detecção de hotwords pelo menos uma vez a cada hora ou a cada 30 horas; eventos acionadores de hardware, o que ocorrer primeiro.

Se as implementações de dispositivos incluem um aplicativo que usa a API do sistema HotwordDetectionService ou um mecanismo semelhante para detecção de hotwords sem indicação de uso do microfone, o aplicativo:

  • [9.8/H-2-1] PRECISA fornecer aviso explícito ao usuário para cada frase de hotword. suporte.
  • [9.8/H-2-2] NÃO PODE preservar dados brutos de áudio ou dados derivados deles, por meio do serviço de detecção de hotwords.
  • [9.8/H-2-3] NÃO PODE transmitir do serviço de detecção de hotword, áudio dados que podem ser usados para reconstruir (total ou parcialmente) o áudio, ou conteúdos de áudio não relacionados à hotword em si, exceto à ContentCaptureService ou fala no dispositivo serviço de reconhecimento de marca.

Se as implementações de dispositivos portáteis forem compatíveis com a API do sistema VisualQueryDetectionService ou outro mecanismo para detecção de consultas sem indicação de acesso ao microfone e/ou à câmera, eles:

  • [9.8/H-3-1] PRECISA garantir que o serviço de detecção de consultas só transmita para o sistema, ou ContentCaptureService, ou fala no dispositivo de reconhecimento de marca (criado pela SpeechRecognizer#createOnDeviceSpeechRecognizer()).
  • [9.8/H-3-2] NÃO PODE permitir a transmissão de informações de áudio ou vídeo. de VisualQueryDetectionService, exceto para ContentCaptureService ou de reconhecimento de fala no dispositivo.
  • [9.8/H-3-3] PRECISA exibir um aviso na interface do sistema quando o dispositivo detecta o usuário intenção de interagir com o aplicativo de assistente digital (por exemplo, detectando presença do usuário pela câmera).
  • [9.8/H-3-4] PRECISA exibir um indicador de microfone e exibir o consulta do usuário na interface logo após a consulta do usuário ser detectada.
  • [9.8/H-3-5] NÃO PODE permitir que um aplicativo instalável pelo usuário forneça a com o serviço de detecção de consultas visuais.

Se as implementações de dispositivos portáteis declararem android.hardware.microphone, elas:

  • [9.8.2/H-4-1] PRECISA exibir o indicador de microfone quando: um aplicativo está acessando dados de áudio do microfone, mas não quando o o microfone só é acessado por HotwordDetectionService, SOURCE_HOTWORD,ContentCaptureService ou apps com as funções chamadas na seção 9.1 com o identificador CDD [C-4-X].
  • [9.8.2/H-4-2] PRECISA exibir a lista de itens recentes e ativos. Apps que usam o microfone como retornado PermissionManager.getIndicatorAppOpUsageData(), com qualquer atribuição mensagens associadas a elas.
  • [9.8.2/H-4-3] NÃO PODE ocultar o indicador de microfone para apps do sistema com interfaces do usuário visíveis ou interação direta com o usuário.
  • [9.8.2/H-4-4] PRECISA exibir a lista de Recentes e Ativos. apps que usam o microfone como retornado de PermissionManager.getIndicatorAppOpUsageData(). além de mensagens de atribuição associadas.

Se as implementações de dispositivos portáteis declararem android.hardware.camera.any, elas:

  • [9.8.2/H-5-1] PRECISA exibir o indicador da câmera quando um está acessando dados da câmera em tempo real, mas não quando ela está sendo acessado por aplicativos com os papéis destacados seção 9.1 com o identificador CDD [C-4-X].
  • [9.8.2/H-5-2] PRECISA exibir apps recentes e ativos usando o câmera retornada de PermissionManager.getIndicatorAppOpUsageData(), além de mensagens de atribuição associadas.
  • [9.8.2/H-5-3] NÃO PODE ocultar o indicador da câmera para apps do sistema com interfaces do usuário visíveis ou interação direta com o usuário.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

A Inicialização verificada é um recurso que garante a integridade do software do dispositivo. Se as implementações de dispositivos forem compatíveis com o recurso, elas:

  • [9.10/H-1-1] PRECISA verificar todas as partições somente leitura. montado durante a sequência de inicialização do Android, e o resumo do VBMeta precisa incluir todas essas partições verificadas no cálculo.
.

Encerrar novos requisitos

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

Implementações de dispositivos portáteis (* não aplicável a tablets):

  • [6.1/H-0-1]* PRECISA oferecer suporte ao comando shell. cmd testharness

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Implementações de dispositivos portáteis (* não aplicável a tablets):

  • Perfetto (link em inglês)
    • [6.1/H-0-2]* PRECISA expor um /system/bin/perfetto. binário para o usuário do shell com o qual o cmdline obedece a documentação do perfetto.
    • [6.1/H-0-3]* O binário do perfetto PRECISA aceitar como: insira uma configuração protobuf que esteja em conformidade com o esquema definido em a documentação do perfetto.
    • [6.1/H-0-4]* O binário do perfetto PRECISA escrever como gera um trace protobuf que cumpre o esquema definido em a documentação do perfetto.
    • [6.1/H-0-5]* DEVE fornecer, por meio do perfetto binário, pelo menos as fontes descritas nos a documentação do perfetto.
    • [6.1/H-0-6]* O daemon rastreado do perfetto PRECISA ser ativada por padrão (propriedade do sistema persist.traced.enable).

Encerrar novos requisitos

2.2.7. Classe de desempenho de mídia portátil

Consulte a Seção 7.11 para ver a definição de classe de desempenho de mídia.

2.2.7.1 Mídia

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.U para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, eles:

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.V para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, a empresa:

Encerrar novos requisitos

  • [5.1/H-1-1] PRECISA anunciar o número máximo de hardwares decodificadores de vídeo sessões que podem ser executadas simultaneamente em qualquer combinação de codecs por meio do CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [5.1/H-1-2] PRECISA oferecer suporte a seis instâncias de decodificador de vídeo por hardware de 8 bits (SDR). sessões (AVC, HEVC, VP9, AV1 ou posteriores) em qualquer combinação de codec em execução concomitantemente com 3 sessões com resolução de 1080p a 30 fps e 3 sessões em 4K resolução a 30 fps, a menos que AV1 Em todas as sessões, NÃO PODE haver mais de um frame caiu por segundo. Os codecs AV1 só são necessários para oferecer suporte à resolução de 1080p, mas ainda precisam oferecer suporte a seis instâncias a 1080p30 fps.

Encerrar novos requisitos

  • [5.1/H-1-3] PRECISA anunciar o número máximo de hardwares de codificador sessões que podem ser executadas simultaneamente em qualquer combinação de codecs por meio do CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [5.1/H-1-4] PRECISA oferecer suporte a seis instâncias de codificador de vídeo de hardware de 8 bits (SDR). sessões (AVC, HEVC, VP9, AV1 ou posteriores) em qualquer combinação de codec em execução ao mesmo tempo com 4 sessões em 1080p com resolução a 30 fps e 2 sessões em 4K resolução a 30 fps, a menos que AV1 Em todas as sessões, NÃO PODE haver mais de um frame caiu por segundo. Os codecs AV1 só são necessários para oferecer suporte à resolução de 1080p, necessário para dar suporte a seis instâncias a 1080p30fps.

Encerrar novos requisitos

  • [5.1/H-1-5] PRECISA anunciar o número máximo de hardwares de codificador sessões do decodificador que podem ser executadas simultaneamente em qualquer combinação de codecs por meio do CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [5.1/H-1-6] PRECISA oferecer suporte a seis instâncias de decodificador de vídeo por hardware de 8 bits (SDR). e sessões de codificador de vídeo em hardware (AVC, HEVC, VP9, AV1 ou superior) em qualquer combinação de codecs executada simultaneamente com três sessões a 4K a 30 fps (exceto AV1), sendo que no máximo 2 são sessões do codificador e 3 com resolução de 1080p. Em todas as sessões, NÃO PODE haver mais de um frame caiu por segundo. Os codecs AV1 só são necessários para oferecer suporte à resolução de 1080p, necessário para dar suporte a seis instâncias a 1080p30fps.

Encerrar novos requisitos

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [5.1/H-1-19] PRECISA oferecer suporte a três instâncias de decodificador de vídeo por hardware de 10 bits (HDR) e sessões de codificador de vídeo em hardware (AVC, HEVC, VP9, AV1 ou superior) em qualquer combinação de codecs executada simultaneamente a uma resolução de 4K a 30 fps (exceto AV1) e no máximo 1 é uma sessão de codificador, que pode ser configurada RGBA_1010102 usando uma superfície GL. Para todas as sessões, NÃO PODE haver mais de um frame descartado por segundo. Geração de metadados HDR pelo codificador não é necessário ao codificar a partir da superfície GL. As sessões do codec AV1 são precisa oferecer suporte à resolução de 1080p, mesmo quando esse requisito chama para 4K.

Encerrar novos requisitos

  • [5.1/H-1-7] PRECISA ter uma latência de inicialização de codec de 40 ms ou menos para um Sessão de codificação de vídeo de 1080p ou menor para todos os codificadores de vídeo de hardware sob carga. O carregamento aqui é definido como um vídeo simultâneo de 1080p a 720p sessão de transcodificação usando codecs de vídeo de hardware junto com a e inicialização de gravação de áudio e vídeo. Para o codec Dolby Vision, a latência de inicialização PRECISA ser de 50 ms ou menos.
  • [5.1/H-1-8] PRECISA ter uma latência de inicialização de codec de 30 ms ou menos para um Sessão de codificação de áudio com taxa de bits de 128 kbps ou menor para todos os codificadores de áudio quando sob carga. O carregamento aqui é definido como um vídeo simultâneo de 1080p a 720p sessão de transcodificação usando codecs de vídeo de hardware junto com a inicialização de gravação de áudio e vídeo.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [5.1/H-1-9] PRECISA oferecer suporte a duas instâncias de decodificador de vídeo por hardware seguro sessões (AVC, HEVC, VP9, AV1 ou posteriores) em qualquer combinação de codec em execução simultaneamente com resolução de 4k a 30 fps (exceto AV1) para 8 bits (SDR) e Conteúdo HDR de 10 bits. Em todas as sessões, NÃO PODE haver mais de um frame caiu por segundo. As sessões do codec AV1 só precisam oferecer suporte à resolução de 1080p, mesmo quando esse requisito exige 4K.

Encerrar novos requisitos

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [5.1/H-1-10] PRECISA oferecer suporte a três instâncias de decodificador de vídeo por hardware não seguro sessões com 1 instância de sessão de decodificador de vídeo por hardware seguro (4 instâncias no total) (AVC, HEVC, VP9, AV1 ou posterior) em qualquer combinação de codecs em execução simultaneamente a três sessões com resolução 4K a 30 fps (exceto AV1) que inclui uma sessão de decodificador segura e uma sessão não segura em 1080p resolução a 30 fps, sendo que no máximo 2 sessões podem estar em HDR de 10 bits. Em todas as sessões, NÃO PODE haver mais de um frame caiu por segundo. As sessões do codec AV1 só precisam oferecer suporte à resolução de 1080p, mesmo quando esse requisito exige 4K.

Encerrar novos requisitos

  • [5.1/H-1-11] PRECISA oferecer suporte a um decodificador seguro para cada hardware AVC, HEVC, VP9 ou decodificador AV1 no dispositivo.
  • [5.1/H-1-12] PRECISA ter uma latência de inicialização de codec de 40 ms ou menos para um Sessão de decodificação de vídeo de 1080p ou menor para todos os decodificadores de vídeo de hardware sob carga. O carregamento é definido como um volume de 1080p a 720p simultâneo sessão de transcodificação somente de vídeo usando codecs de vídeo de hardware com o Inicialização da reprodução de áudio e vídeo em 1080p. Para o codec Dolby Vision, a latência de inicialização PRECISA ser de 50 ms ou menos.
  • [5.1/H-1-13] PRECISA ter uma latência de inicialização de codec de 30 ms ou menos para um Sessão de decodificação de áudio com taxa de bits de 128 kbps ou menor para todos os decodificadores de áudio quando sob carga. O carregamento aqui é definido como um vídeo simultâneo de 1080p a 720p sessão de transcodificação usando codecs de vídeo de hardware junto com a e a inicialização da reprodução de áudio e vídeo.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [5.1/H-1-14] PRECISA ser compatível com o decodificador de hardware AV1 Main 10, Level 4.1 e granulação com efeito de granulação sobre a composição da GPU.

Encerrar novos requisitos

  • [5.1/H-1-15] PRECISA ter pelo menos um decodificador de vídeo por hardware compatível com 4K60.
  • [5.1/H-1-16] PRECISA ter pelo menos um codificador de vídeo de hardware compatível com 4K60.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [5.1/H-1-21] PRECISA oferecer suporte a FEATURE_DynamicColorAspect para todos os tipos de vídeo de hardware. (AVC, HEVC, VP9, AV1 ou superiores). Observação: isso significa que os aplicativos podem atualizar os aspectos de cor do conteúdo de vídeo durante a sessão de decodificação. Decodificadores com suporte a conteúdo de 10 e 8 bits PRECISAM oferecer suporte dinâmico alternar entre conteúdo de 8 e 10 bits no modo de superfície. Decodificadores compatíveis com A função de transferência HDR PRECISA ser compatível com a alternância dinâmica entre SDR e HDR conteúdo.

Encerrar novos requisitos

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [5.1/H-1-22] PRECISA oferecer suporte a codificação, decodificação, edição de GPU e exibição de vídeo. do conteúdo na proporção retrato, independentemente dos metadados de rotação do maior resolução compatível com a câmera, ou 4K, o que for menor. Observação: inclui perfis HDR se o codec for compatível com HDR. Os codecs AV1 só são necessários são compatíveis com a resolução de 1080p. Esse requisito serve apenas para codecs de hardware, GPUs e a DPU.

Encerrar novos requisitos

  • [5.3/H-1-1] NÃO PODE eliminar mais de 1 frame em 10 segundos (ou seja, menos de 0,167% de queda do quadro) para uma sessão de vídeo 4K de 60 fps sob carregamento.
  • [5.3/H-1-2] NÃO PODE cair mais de 1 frame em 10 segundos durante um vídeo. mudança da resolução em uma sessão de vídeo de 60 QPS sob carga para uma sessão de 4K.
  • [5.6/H-1-1] PRECISA ter uma latência de toque para tom de 80 milissegundos ou menos usando o o teste por toque do CTS Verifier.
  • [5.6/H-1-2] PRECISA ter uma latência de ida e volta de áudio de 80 milissegundos ou em pelo menos um caminho de dados com suporte.
  • [5.6/H-1-3] PRECISA oferecer suporte a áudio de 24 bits ou mais para saída estéreo de áudio com mais de 3,5 mm. Entradas, se presente, e via áudio USB, se compatível com todos os dados para configurações de baixa latência e de streaming. Para a baixa latência a AAudio deve ser usada pelo app em um callback de baixa latência modo Para a configuração de streaming, um AudioTrack Java deve ser usado pelo o app. Nas configurações de baixa latência e de streaming, a HAL o coletor de saída deve aceitar AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT ou AUDIO_FORMAT_PCM_FLOAT para o formato de saída de destino.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [5.6/H-1-4] PRECISA oferecer suporte a dispositivos de áudio USB com pelo menos quatro canais. Essa opção é usada pelos controladores de DJ para a prévia das músicas.

Encerrar novos requisitos

  • [5.6/H-1-5] PRECISA oferecer suporte a dispositivos MIDI compatíveis com a classe e declarar os Sinalização de recurso MIDI.
  • [5.6/H-1-9] PRECISA oferecer suporte a pelo menos 12 mixes de canais. Isso implica que abrir uma faixa de áudio com máscara de canal 7.1.4 e abrir corretamente espacializar ou fazer downmix de todos os canais para estéreo.
  • [5.6/H-SR] É FORTEMENTE RECOMENDADO para oferecer suporte a 24 canais de mix com oferecer suporte mínimo às máscaras de canal 9.1.6 e 22.2.
  • [5.7/H-1-2] PRECISA oferecer suporte a MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL com o abaixo dos recursos de descriptografia de conteúdo.
Tamanho mínimo da amostra 4 MiB
Número mínimo de subamostras: H264 ou HEVC 32
Número mínimo de subamostras: VP9 9
Número mínimo de subamostras: AV1 288
Tamanho mínimo do buffer de subamostra 1 MiB
Tamanho mínimo do buffer de criptografia genérico 500 KiB
Número mínimo de sessões simultâneas 30
Número mínimo de chaves por sessão 20
Número total mínimo de chaves (todas as sessões) 80
Número total mínimo de chaves DRM (todas ) 6
Tamanho da mensagem 16 KiB
Frames descriptografados por segundo 60 QPS
  • [5.1/H-1-17] PRECISA ter pelo menos um decodificador de imagem de hardware compatível com AVIF Perfil de referência.
  • [5.1/H-1-18] PRECISA oferecer suporte ao codificador AV1, que pode codificar até 480p a 30 fps e 1 Mbps.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [5.1/H-1-20] PRECISA ser compatível com Feature_HdrEditing. recurso para todos os codificadores AV1 e HEVC de hardware presentes no dispositivo em 4K ou a maior resolução suportada pela câmera, o que for menor.

Encerrar novos requisitos

  • [5.12/H-SR] São altamente recomendadas para oferecer suporte ao Feature_HdrEditing para todos os codificadores AV1 e HEVC de hardware presentes no dispositivo.
  • [5.12/H-1-2] PRECISA oferecer suporte ao formato de cores RGBA_1010102 para todos os hardwares AV1 e Codificadores HEVC presentes no dispositivo.
  • [5.12/H-1-3] PRECISA anunciar o suporte para a extensão EXT_YUV_target em amostra de texturas YUV em 8 e 10 bits.
  • [7.1.4/H-1-1] PRECISA ter pelo menos seis sobreposições de hardware no processamento da tela. (DPU), com pelo menos dois deles capazes de exibir conteúdo de vídeo de 10 bits.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.V para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS e incluem suporte a um codificador AVC ou HEVC de hardware, eles:

Encerrar novos requisitos

2.2.7.2 Câmera

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.U para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, eles:

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.V para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, a empresa:

Encerrar novos requisitos

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [7.5/H-1-1] PRECISA ter uma câmera traseira principal com um resolução de pelo menos 12 megapixels compatível com captura de vídeo em 4k a 30 fps, 1080p a 60 fps e 720p a 60 fps. A câmera traseira principal é a câmera traseira com o menor ID de câmera.

Encerrar novos requisitos

  • [7.5/H-1-2] PRECISA ter uma câmera frontal principal com resolução de no mínimo no mínimo 6 megapixels e suporte a captura de vídeo a 1080p a 30 fps. O principal A câmera frontal é a frontal com o menor ID de câmera.
  • [7.5/H-1-3] PRECISA oferecer suporte à propriedade android.info.supportedHardwareLevel como FULL ou melhor para a instância principal secundária e LIMITED ou melhor para a principal principal câmera.
  • [7.5/H-1-4] PRECISA ser compatível. CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME para as contas principais câmeras.
  • [7.5/H-1-5] PRECISA ter a latência de captura JPEG da Camera2 < 1.000 ms para resolução de 1080p, conforme medido pelo PerformanceTest da câmera CTS em Condições de iluminação ITS (3.000K) para ambas as câmeras principais.
  • [7.5/H-1-6] PRECISA ter a latência de inicialização da câmera2 (abrir a câmera para a primeira visualização) frame) < 500 ms, medido pelo PerformanceTest da câmera CTS de acordo com o ITS. condições de iluminação (3.000K) para as duas câmeras principais.
  • [7.5/H-1-8] PRECISA oferecer suporte a CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW. e android.graphics.ImageFormat.RAW_SENSOR para a câmera traseira principal.
  • [7.5/H-1-9] PRECISA ter uma câmera principal traseira compatível com 720p ou 1080p a 240 fps.
  • [7.5/H-1-10] PRECISA ter ZOOM_RATIO mínimo < 1.0 para as câmeras principais, se houver é uma câmera RGB ultra grande angular voltada para a mesma direção.
  • [7.5/H-1-11] PRECISA implementar o streaming front-back simultâneo na rede principal. câmeras.
  • [7.5/H-1-12] PRECISA ser compatível. CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION para as contas principais câmera frontal e traseira principal.
  • [7.5/H-1-13] PRECISA oferecer suporte ao recurso LOGICAL_MULTI_CAMERA. para a câmera traseira principal se houver mais de uma câmera traseira RGB câmeras.
  • [7.5/H-1-14] PRECISA oferecer suporte ao recurso STREAM_USE_CASE para as contas primárias câmera frontal e traseira principal.
  • [7.5/H-1-15] PRECISA ser compatível. Extensões do Modo noturno pelas extensões CameraX e Camera2 para principais câmeras.
  • [7.5/H-1-16] PRECISA oferecer suporte ao recurso DYNAMIC_RANGE_TEN_BIT para a instância principal. câmeras.
  • [7.5/H-1-17] PRECISA ser compatível com CONTROL_SCENE_MODE_FACE_PRIORITY. e detecção facial (STATISTICS_FACE_DETECT_MODE_SIMPLE ou STATISTICS_FACE_DETECT_MODE_FULL) para as câmeras principais.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [7.5/H-1-18] PRECISA oferecer suporte a JPEG_R na parte traseira principal e as câmeras frontais principais.
  • [7.5/H-1-19] PRECISA ser compatível. CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION para HLG10 de 1080p Prévia com proporção máxima de 16:9 JPEG e para visualização HLG10 de 720p com combinações de stream JPEG com proporção máxima de 16:9 para a página principal câmera traseira.
  • [7.5/H-1-20] PRECISA, por padrão, gerar JPEG_R para a instância principal. as câmeras traseira e principal no app de câmera nativo.

Encerrar novos requisitos

2.2.7.3 Hardware

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.U para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, eles:

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.V para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, a empresa:

Encerrar novos requisitos

  • [7.1.1.1/H-2-1] PRECISA ter uma resolução de tela de pelo menos 1080p.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [7.1.1.3/H-2-1] PRECISA ter uma densidade de tela de pelo menos 400 dpi. se a largura da tela do dispositivo for < 600 dp.

Encerrar novos requisitos

  • [7.1.1.3/H-3-1] PRECISA ter uma tela HDR com suporte de pelo menos 1.000 nits. média.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Encerrar novos requisitos

2.2.7.4 Desempenho

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.U para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, eles:

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.V para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, a empresa:

Encerrar novos requisitos

  • [8.2/H-1-1] PRECISA garantir um desempenho de gravação sequencial de pelo menos 150 MB/s.
  • [8.2/H-1-2] PRECISA garantir um desempenho de gravação aleatória de pelo menos 10 MB/s.
  • [8.2/H-1-3] PRECISA garantir um desempenho de leitura sequencial de pelo menos 250 MB/s.
  • [8.2/H-1-4] PRECISA garantir um desempenho de leitura aleatória de pelo menos 100 MB/s.
  • [8.2/H-1-5] PRECISA garantir um desempenho de leitura e gravação sequencial paralelo. com desempenho de leitura e gravação de pelo menos 50 MB/s.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

2.2.7.5 Gráficos

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.V para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, eles:

Encerrar novos requisitos

2.3. Requisitos para televisão

Um dispositivo Android Television é uma implementação de dispositivo Android que é uma interface de entretenimento para consumo de mídia digital, filmes, jogos, aplicativos, e/ou TV ao vivo para usuários sentados a cerca de três metros de distância interface do usuário").

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

  • Forneceu um mecanismo para controlar remotamente a interface do usuário renderizada no a tela que pode ficar a três metros de distância do usuário.
  • Ter uma tela incorporada com comprimento diagonal maior que 24 OU incluir uma porta de saída de vídeo, como VGA, HDMI, DisplayPort ou porta sem fio para display.

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

2.3.1 Hardware

Implementações de dispositivos de televisão:

  • [7.2.2/T-0-1] PRECISA oferecer suporte ao D-pad.
  • [7.2.3/T-0-1] PRECISA fornecer o Home e o Back .
  • [7.2.3/T-0-2] PRECISA enviar os comandos normal e longo Evento da função Voltar (KEYCODE_BACK) para o aplicativo em primeiro plano.
  • [7.2.6.1/T-0-1] PRECISA incluir suporte a jogos e declarar a flag de recurso android.hardware.gamepad.
  • [7.2.7/T] DEVE fornecer um controle remoto que os usuários podem acessar a navegação sem toque e teclas de navegação principais.

Se as implementações de dispositivos de televisão incluírem um giroscópio de três eixos, elas:

  • [7.3.4/T-1-1] PRECISA relatar eventos de até uma de pelo menos 100 Hz.
  • [7.3.4/T-1-2] PRECISA ser capaz de medir mudanças de orientação. até 1.000 graus por segundo.

Implementações de dispositivos de televisão:

  • [7.4.3/T-0-1] PRECISA ser compatível com Bluetooth e Bluetooth LE
  • [7.6.1/T-0-1] PRECISA ter pelo menos 4 GB de armazenamento não volátil disponível para dados privados de aplicativos (também conhecida como partição "/data").

Se as implementações de dispositivos de televisão incluírem uma porta USB compatível com o modo host, eles:

  • [7.5.3/T-1-1] PRECISA incluir suporte a uma câmera externa. que se conecta por essa porta USB, mas que não está necessariamente sempre conectada.

Se as implementações de dispositivos 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 maior em telas grandes
    • tvdpi ou maior em telas muito grandes

Se as implementações de dispositivos 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 alguma das densidades a seguir for usado:

    • 400 dpi ou mais em telas pequenas/normais
    • xhdpi ou maior em telas grandes
    • tvdpi ou maior em telas muito grandes

Observe que a "memória disponível para o kernel e o espaço do usuário" acima refere-se à o espaço na memória é fornecido além das memórias dedicados a componentes de hardware, como rádio, vídeo etc., que não são sob o controle do kernel sobre implementações de dispositivos.

Implementações de dispositivos de televisão:

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

2.3.2 Multimídia

As implementações de dispositivos de televisão PRECISAM ser compatíveis com a seguinte codificação de áudio: e decodificação e disponibilizá-los para aplicativos de terceiros:

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

As implementações de dispositivos de televisão PRECISAM ser compatíveis com a seguinte codificação de vídeo formatos e disponibilizá-los para aplicativos de terceiros:

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

Implementações de dispositivos de televisão:

  • [5.2.2/T-SR-1] É FORTEMENTE RECOMENDADO para o suporte Codificação H.264 de vídeos com resolução de 720p e 1080p a 30 quadros por segundo.

As implementações de dispositivos de televisão PRECISAM ser compatíveis com a seguinte decodificação de vídeo formatos e disponibilizá-los para aplicativos de terceiros:

Implementações de dispositivos de televisão PRECISAM ser compatíveis com a decodificação MPEG-2, conforme detalhado em Seção 5.3.1, com frame rates e resoluções padrão de vídeo incluindo:

  • [5.3.1/T-1-1] HD 1080p a 29,97 quadros por segundo com o alto nível do perfil principal.
  • [5.3.1/T-1-2] HD 1080i a 59,94 quadros por segundo com o alto nível do perfil principal. É NECESSÁRIO remover o entrelaçamento dos vídeos MPEG-2 e disponibilizá-los para aplicativos de terceiros.

Implementações de dispositivos de televisão PRECISAM oferecer suporte à decodificação H.264, conforme detalhado em Seção 5.3.4, com frame rates e resoluções padrão de vídeo de até incluindo:

  • [5.3.4/T-1-1] HD 1080p a 60 quadros por segundo com Perfil de referência
  • [5.3.4/T-1-2] HD 1080p a 60 quadros por segundo com Perfil principal
  • [5.3.4/T-1-3] HD 1080p a 60 quadros por segundo com Alto nível 4.2

Implementações de dispositivos de televisão com decodificadores de hardware H.265 PRECISAM ser compatíveis com Decodificação H.265, conforme detalhado na Seção 5.3.5, com frame rates padrão de vídeo e resoluções até, inclusive:

  • [5.3.5/T-1-1] HD 1080p a 60 quadros por segundo com Nível 4.1 do perfil principal

Se as implementações de dispositivos de televisão com decodificadores de hardware H.265 forem compatíveis decodificação H.265 e o perfil de decodificação UHD, eles:

  • [5.3.5/T-2-1] PRECISA ser compatível com o perfil de decodificação UHD. a 60 quadros por segundo com o perfil de nível 5 Main10 de nível 5

As implementações de dispositivos de televisão PRECISAM ser compatíveis com a decodificação VP8, conforme detalhado em Seção 5.3.6, com frame rates e resoluções padrão de vídeo de até incluindo:

  • [5.3.6/T-1-1] HD de 1080p com perfil de decodificação de 60 quadros por segundo

Implementações de dispositivos de televisão com decodificadores de hardware VP9 PRECISAM ser compatíveis com esse padrão. decodificação, conforme detalhado na Seção 5.3.7, com frame rates e resoluções, incluindo:

  • [5.3.7/T-1-1] HD 1080p a 60 quadros por segundo com perfil 0 (profundidade de cor de 8 bits)

Se as implementações de dispositivos de televisão com decodificadores de hardware VP9 oferecerem suporte a VP9 decodificação e o perfil de decodificação UHD, eles:

  • [5.3.7/T-2-1] PRECISA ser compatível com o perfil de decodificação UHD. a 60 quadros por segundo com perfil 0 (profundidade de cor de 8 bits).
  • [5.3.7/T-SR1] É FORTEMENTE RECOMENDADO para oferecer suporte à Perfil de decodificação UHD a 60 quadros por segundo com perfil 2 (profundidade de cor de 10 bits).

Implementações de dispositivos de televisão:

  • [5.5/T-0-1] PRECISA incluir suporte ao mestre do sistema. Atenuação do volume e da saída de áudio digital em saídas compatíveis exceto para saída de passagem de áudio compactada, em que nenhuma decodificação de áudio é feita no dispositivo).

Se as implementações de dispositivos de televisão não tiverem um monitor integrado, mas compatíveis com um monitor externo conectado por HDMI, eles:

  • [5.8/T-0-1] PRECISA definir o modo de saída HDMI como resolução mais alta para o formato de pixel escolhido que funciona com 50 Hz ou 60 Hz para a tela externa, dependendo da taxa de atualização de vídeo para a região em que o dispositivo é vendido.
  • [5.8/T-SR-1] É FORTEMENTE RECOMENDADO para fornecer a um usuário seletor configurável de taxa de atualização HDMI.
  • [5.8] DEVE definir a taxa de atualização do modo de saída HDMI para 50 Hz ou 60 Hz, dependendo da taxa de atualização de vídeo da região da dispositivo é vendido.

Se as implementações de dispositivos de televisão não tiverem um monitor integrado, mas compatíveis com um monitor externo conectado por HDMI, eles:

  • [5.8/T-1-1] PRECISA oferecer suporte a HDCP 2.2.

Se as implementações de dispositivos de televisão não suportarem a decodificação UHD, mas oferecem suporte a uma tela externa conectada por HDMI, eles:

  • [5.8/T-2-1] PRECISA oferecer suporte a HDCP 1.4.

2.3.3 Software

Implementações de dispositivos de televisão:

  • [3/T-0-1] PRECISA declarar os recursos android.software.leanback e android.hardware.type.television.
  • [3.2.3.1/T-0-1] PRECISA pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents para todos padrões de filtro de intent pública definidos pelas seguintes intents de aplicativo listados aqui.
  • [3.4.1/T-0-1] PRECISA fornecer um implementação da API android.webkit.Webview.

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

  • [3.8.10/T-1-1] PRECISA exibir a fechadura Notificações da tela, incluindo o Modelo de notificação de mídia.

Implementações de dispositivos de televisão:

  • [3.8.14/T-SR-1] São FORTEMENTE RECOMENDADOS para oferecer suporte ao modo picture-in-picture (PIP) de várias janelas.
  • [3.10/T-0-1] PRECISA ser compatível com acessibilidade de terceiros. serviços.
  • [3.10/T-SR-1] É FORTEMENTE RECOMENDADO para pré-carregar serviços de acessibilidade no dispositivo comparáveis ou superiores do acesso com interruptor e do TalkBack (para os idiomas compatíveis com os serviços de acessibilidade do mecanismo de conversão de texto em voz pré-instalados) conforme fornecido o projeto de código aberto TalkBack.

Se as implementações de dispositivos de televisão informarem o recurso android.hardware.audio.output, eles:

  • [3.11/T-SR-1] É FORTEMENTE RECOMENDADO a inclusão de um Mecanismo de TTS com suporte para os idiomas disponíveis no dispositivo.
  • [3.11/T-1-1] PRECISA ser compatível com a instalação do mecanismos TTS de terceiros.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Implementações de dispositivos de televisão:

  • [3.12/T-0-1] PRECISA oferecer suporte ao TV Input Framework.

Encerrar novos requisitos

Iniciar novos requisitos para a versão 15 (AOSP experimental)

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

Implementações de dispositivos de televisão:

  • [3/T-0-2] PRECISA declarar o recurso da plataforma android.software.live_tv
  • [3/T-0-3] PRECISA oferecer suporte a todas as APIs TIF, de forma que um aplicativo que usa essas APIs e as entradas de terceiros baseadas em TIF serviço pode ser instalado e usado no dispositivo.

O framework do Android Television Tuner (TF) unifica o gerenciamento de conteúdo ao vivo do Tuner com o conteúdo de streaming do IP em dispositivos Android Television. O framework Turner fornece uma API padrão para criar serviços de entrada que usam o Android Television Tuner.

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

  • [3/T-1-1] PRECISA oferecer suporte a todas as APIs Tuner Framework, de forma que uma o aplicativo que usa essas APIs pode ser instalado e usado no dispositivo.

Encerrar novos requisitos

2.3.4 Desempenho e potência

  • [8.1/T-0-1] Latência de frame consistente. Latência de frame inconsistente ou um atraso na renderização de frames NÃO PODEM acontecer com mais frequência geralmente que 5 quadros por segundo e DEVE estar abaixo de 1 quadros por segundo.
  • [8.2/T-0-1] PRECISA garantir uma sequência e um desempenho de gravação de pelo menos 5 MB/s.
  • [8.2/T-0-2] PRECISA garantir que uma gravação aleatória desempenho de pelo menos 0,5 MB/s.
  • [8.2/T-0-3] PRECISA garantir uma sequência desempenho de leitura mínimo de 15 MB/s.
  • [8.2/T-0-4] PRECISA garantir uma leitura aleatória. e desempenho de pelo menos 3,5 MB/s.

Se as implementações de dispositivos de televisão incluírem recursos para melhorar a potência do dispositivo de código aberto incluídos no AOSP ou que ampliem os recursos incluídos no AOSP:

  • [8.3/T-1-1] PRECISA fornecer recursos do usuário para ativar e desative o recurso de economia de bateria.

Se as implementações de dispositivos de televisão não tiverem uma bateria, elas:

Se as implementações de dispositivos de televisão tiverem uma bateria, elas:

  • [8.3/T-1-3] PRECISA fornecer funcionalidade do usuário para exibir todos os apps isentos dos modos de economia de energia "App em espera" e "Soneca".

Implementações de dispositivos de televisão:

  • [8.4/T-0-1] PRECISA fornecer uma perfil de energia por componente que define o valor de consumo atual para cada componente de hardware e o consumo aproximado da bateria causado pelo ao longo do tempo, conforme documentado no site do Android Open Source Project.
  • [8.4/T-0-2] PRECISA informar toda a energia valores de consumo em milissegundos/hora (mAh).
  • [8.4/T-0-3] PRECISA informar a energia da CPU. e consumo de acordo com o UID de cada processo. O Android Open Source Project atende à requisito pela implementação do módulo do kernel uid_cputime.
  • [8.4/T] DEVE ser atribuída ao componente de hardware em si, se não for possível atribuir o uso de energia do componente de hardware a um aplicativo.
  • [8.4/T-0-4] PRECISA fazer esse uso de energia disponível no adb shell dumpsys batterystats shell para o desenvolvedor do app.

2.3.5 Modelo de segurança

Implementações de dispositivos de televisão:

  • [9/T-0-1] PRECISA declarar o android.hardware.security.model.compatible .
  • [9.11/T-0-1] PRECISA fazer backup da implementação de keystore. com um ambiente de execução isolado.
  • [9.11/T-0-2] PRECISA ter implementações de RSA, AES, Algoritmos criptográficos ECDSA e HMAC e família MD5, SHA-1 e SHA-2 para oferecer suporte adequado ao suporte do sistema Android Keystore algoritmos em uma área segura e isolada do código em execução kernel e acima. O isolamento seguro PRECISA bloquear todos os possíveis mecanismos. pelo qual o código do kernel ou do espaço do usuário pode acessar o estado interno da ambiente isolado, incluindo DMA. O Android Open Source upstream O Project (AOSP) atende a esse requisito usando a implementação Trusty, mas outra Uma solução baseada em ARM TrustZone ou uma solução verificada por terceiros como segura a implementação adequada de um isolamento baseado em hipervisor são alternativas .
  • [9.11/T-0-3] PRECISA executar a tela de bloqueio. no ambiente de execução isolado e somente ao bem-sucedido, permite o uso das chaves vinculadas à autenticação. Bloquear tela as credenciais PRECISAM ser armazenadas de uma forma que permita somente a execução isolada para executar a autenticação da tela de bloqueio. O sistema upstream do Android O Open Source Project oferece Camada de abstração de hardware (HAL) Gatekeeper e o Trusty, que podem ser usados para atender a esse requisito.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [9.11/T-0-4] PRECISA oferecer suporte ao atestado de chaves em que o a chave de assinatura de atestado é protegida por um hardware seguro e a assinatura é executadas em hardware seguro. As chaves de assinatura de atestado PRECISAM ser compartilhadas entre um número grande de dispositivos para impedir as chaves evitados deixem de ser usados como permanentes identificadores de dispositivo. Uma maneira de atender a esse requisito é compartilhar os mesma chave de atestado,a menos que pelo menos 100.000 unidades de uma determinada SKU sejam produzidos. Se mais de 100.000 unidades de uma SKU forem produzidas, outro pode ser usada para cada 100.000 unidades.

Encerrar novos requisitos

Se uma implementação de dispositivo já tiver sido iniciada em uma versão anterior versão, tal dispositivo está isento da exigência de ter um keystore em um ambiente de execução isolado e oferecem suporte ao atestado de chaves, a menos que declare o recurso android.hardware.fingerprint, que requer uma um keystore apoiado por um ambiente de execução isolado.

Se as implementações de dispositivos de televisão forem compatíveis com uma tela de bloqueio segura, elas:

  • [9.11/T-1-1] PRECISA permitir que o usuário escolha a opção Sono tempo limite para a transição do estado desbloqueado para o bloqueado, com um o tempo limite mínimo permitido é de até 15 segundos.

Se as implementações de dispositivos de televisão incluírem vários usuários e não declararem a flag de recurso android.hardware.telephony, eles:

  • [9.5/T-2-1] PRECISA oferecer suporte a perfis restritos, um recurso que permite que os proprietários de dispositivos gerenciem outros usuários e do dispositivo. Com 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 de dispositivos de televisão incluírem vários usuários e declararem a flag de recurso android.hardware.telephony, eles:

  • [9.5/T-3-1] NÃO PODE oferecer suporte a restrições perfis, mas PRECISA estar alinhada com a implementação de controles do AOSP para ativar ou desativar o acesso de outros usuários a chamadas de voz e SMS.

Se as implementações de dispositivos de televisão declararem android.hardware.microphone, elas:

  • [9.8.2/T-4-1] PRECISA exibir o indicador de microfone quando: um aplicativo está acessando dados de áudio do microfone, mas não quando o microfone só é acessado pelo HotwordDetectionService, SOURCE_HOTword, ContentCaptureService ou os apps que detêm as funções mencionadas na Seção 9.1 Permissões com identificador CDD C-3-X.
  • [9.8.2/T-4-2] NÃO PODE ocultar o indicador de microfone para apps do sistema com interfaces do usuário visíveis ou interação direta com o usuário.

Se as implementações de dispositivos de televisão declararem android.hardware.camera.any, elas:

  • [9.8.2/T-5-1] PRECISA exibir o indicador da câmera quando um está acessando os dados da câmera em tempo real, mas não quando ela está sendo acessados por aplicativos que detêm os papéis mencionados na Seção 9.1 Permissões com identificador CDD [C-3-X].
  • [9.8.2/T-5-2] NÃO PODE ocultar o indicador da câmera para apps do sistema com interfaces do usuário visíveis ou interação direta com o usuário.

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

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Implementações de dispositivos de televisão:

  • Perfetto (link em inglês)
    • [6.1/T-0-1] PRECISA expor um /system/bin/perfetto. binário para o usuário do shell com o qual o cmdline obedece a documentação do perfetto.
    • [6.1/T-0-2] O binário do perfetto PRECISA ser aceito como insira uma configuração protobuf que esteja em conformidade com o esquema definido em a documentação do perfetto.
    • [6.1/T-0-3] O binário do perfetto PRECISA ser escrito como gera um trace protobuf que cumpre o esquema definido em a documentação do perfetto.
    • [6.1/T-0-4] PRECISA fornecer, pelo perfetto. binário, pelo menos as fontes descritas nos a documentação do perfetto.
    • [6.1/T-0-5] O daemon rastreado do perfetto PRECISA estar ativado por padrão (propriedade do sistema persist.traced.enable).

Encerrar novos requisitos

2.4. Requisitos do relógio

Um dispositivo Android Watch é uma implementação de dispositivo Android destinada a: ser usado no corpo, talvez no pulso.

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

  • Ter uma tela com o comprimento diagonal físico 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 o Android Relógios de implementações de dispositivos.

2.4.1. Hardware

Implementações de dispositivos de smartwatches:

  • [7.1.1.1/W-0-1] PRECISA ter uma tela com o tamanho diagonal físico no intervalo de 1,1 a 2,5 polegadas.

  • [7.2.3/W-0-1] PRECISA ter a função Home disponível ao usuário e a função Voltar, exceto quando estiver em UI_MODE_TYPE_WATCH.

  • [7.2.4/W-0-1] PRECISA oferecer suporte à entrada touchscreen.

  • [7.3.1/W-SR-1] É MUITO RECOMENDADO a inclusão de um eixo acelerômetro.

Se as implementações de dispositivos Watch incluírem suporte ao Vulkan, elas vão:

Se as implementações do dispositivo Watch incluírem um receptor GPS/GNSS e informarem o aos aplicativos pelo recurso android.hardware.location.gps ele:

  • [7.3.3/W-1-1] PRECISA informar as medições do GNSS assim que elas forem encontrados, mesmo que uma localização calculada a partir de GPS/GNSS ainda não tenha sido relatada.
  • [7.3.3/W-1-2] PRECISA informar as pseudodistâncias e pseudodistâncias do GNSS. em condições de céu aberto após a determinação do local, enquanto parado ou em movimento com menos de 0,2 metro por segundo ao quadrado de são suficientes para calcular uma posição dentro de 20 metros, e a velocidade em 0,2 metro por segundo, pelo menos 95% do tempo.

Se as implementações de dispositivos Watch incluírem um giroscópio de três eixos, elas:

  • [7.3.4/W-2-1] PRECISA ser capaz de medir mudanças de orientação. até 1.000 graus por segundo.

Implementações de dispositivos de smartwatches:

  • O [7.4.3/W-0-1] PRECISA ser compatível com Bluetooth.

  • [7.6.1/W-0-1] PRECISA ter pelo menos 1 GB de espaço 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] PRECISA ter pelo menos 416 MB de memória disponíveis para o kernel e o espaço do usuário.

  • [7.8.1/W-0-1] PRECISA incluir um microfone.

  • [7.8.2/W] PODE ter saída de áudio.

2.4.2. Multimídia

Nenhum requisito extra.

2.4.3. Software

Implementações de dispositivos de smartwatches:

  • [3/W-0-1] PRECISA declarar o recurso android.hardware.type.watch
  • [3/W-0-2] PRECISA oferecer suporte a uiMode = UI_MODE_TYPE_ASSIST.
  • [3.2.3.1/W-0-1] PRECISA pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents, para todos os padrões de filtro de intent pública definidos pelo seguinte aplicativo intents listadas aqui.

Implementações de dispositivos de smartwatches:

  • [3.8.4/W-SR-1] São FORTEMENTE RECOMENDADOS para implementar um assistente no dispositivo e processar a ação de assistência.

Assistir implementações de dispositivos que declaram o android.hardware.audio.output flag de recurso:

  • [3.10/W-1-1] PRECISA ser compatível com acessibilidade de terceiros. serviços.
  • [3.10/W-SR-1] É FORTEMENTE RECOMENDADO o pré-carregamento serviços de acessibilidade no dispositivo comparáveis com funcionalidades superiores ou iguais a elas do acesso com interruptor e do TalkBack (para os idiomas compatíveis com os recursos mecanismo de conversão de texto em voz) fornecidos pelo projeto de código aberto TalkBack.

Se as implementações de dispositivos Watch relatarem o recurso android.hardware.audio.output, eles:

  • [3.11/W-SR-1] É FORTEMENTE RECOMENDADO a inclusão de um Mecanismo de TTS com suporte para os idiomas disponíveis no dispositivo.

  • [3.11/W-0-1] PRECISA ser compatível com a instalação do mecanismos TTS de terceiros.

2.4.4 Desempenho e potência

Se as implementações de dispositivos Watch incluem recursos para melhorar a energia do dispositivo de código aberto incluídos no AOSP ou que ampliem os recursos incluídos no AOSP:

  • [8.3/W-SR-1] É FORTEMENTE RECOMENDADO fornecer funcionalidade do usuário para exibir todos os apps isentos do App em espera e Modos de economia de energia do Soneca.
  • [8.3/W-SR-2] É FORTEMENTE RECOMENDADO fornecer funcionalidade do usuário para ativar e desativar o recurso de economia de bateria.

Implementações de dispositivos de smartwatches:

  • [8.4/W-0-1] PRECISA fornecer uma perfil de energia por componente que define o valor de consumo atual para cada componente de hardware e o consumo aproximado da bateria causado pelo ao longo do tempo, conforme documentado no site do Android Open Source Project.
  • [8.4/W-0-2] PRECISA informar toda a energia valores de consumo em milissegundos/hora (mAh).
  • [8.4/W-0-3] PRECISA informar a potência da CPU e consumo de acordo com o UID de cada processo. O Android Open Source Project atende à requisito pela implementação do módulo do kernel uid_cputime.
  • [8.4/W-0-4] PRECISA fazer esse uso de energia disponível no adb shell dumpsys batterystats shell para o desenvolvedor do app.
  • [8.4/W] DEVE ser atribuída ao componente de hardware em si, se não for possível atribuir o uso de energia do componente de hardware a um aplicativo.

2.4.5. Modelo de segurança

Implementações de dispositivos de smartwatches:

  • [9/W-0-1] PRECISA declarar a android.hardware.security.model.compatible .

Se as implementações de dispositivos Watch incluem vários usuários e não declararem a flag de recurso android.hardware.telephony, eles:

  • [9.5/W-1-1] PRECISA oferecer suporte a perfis restritos, um recurso que permite que os proprietários de dispositivos gerenciem outros usuários e do dispositivo. Com 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 de dispositivos Watch incluem vários usuários e declararem a flag de recurso android.hardware.telephony, eles:

  • [9.5/W-2-1] NÃO PODE oferecer suporte a restrições perfis, mas PRECISA estar alinhada com a implementação de controles do AOSP para ativar ou desativar o acesso de outros usuários a chamadas de voz e SMS.

Se as implementações do dispositivo tiverem uma tela de bloqueio segura e incluírem um ou mais agentes de confiança, que implementam a API do sistema TrustAgentService, elas:

  • [9.11.1/W-1-1] PRECISA desafiar o usuário quanto a um dos métodos principais de autenticação recomendados (por exemplo, PIN, padrão ou senha) com mais frequência do que uma vez a cada 72 horas.

2,5 Requisitos automotivos

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

As implementações de dispositivos Android serão classificadas como Automotive se declararem o recurso android.hardware.type.automotive ou atender a todas as critérios.

  • estejam incorporados como parte de um veículo automotivo ou conectá-lo a ele;
  • estão usando uma tela na fila do assento do motorista como tela principal;

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

2.5.1. Hardware

Implementações de dispositivos automotivos:

  • [7.1.1.1/A-0-1] PRECISA ter uma tela de pelo menos seis polegadas de tamanho diagonal.
  • [7.1.1.1/A-0-2] PRECISA ter um layout de tamanho de tela. de pelo menos 750 dp x 480 dp.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Se as implementações de dispositivos automotivos oferecerem suporte a multiusuário simultâneo (em que vários usuários de Android podem interagir com o dispositivo ao mesmo tempo, cada uma usando sua própria tela ao config_multiuserVisibleBackgroundUsers estiver ativado), eles:

  • [7.1.1.1/A-1-1] PRECISA ter uma tela separada de deve ter pelo menos 15 centímetros de tamanho diagonal para cada zona de ocupantes do tela principal. Ele deve ser marcado como CarOccupantZoneManager.DISPLAY_TYPE_MAIN para cada zona de ocupantes.
  • [7.1.1.1/A-1-2] PRECISA ter um layout de tamanho de tela. de pelo menos 750 dp x 480 dp para cada tela principal.

Encerrar novos requisitos

Se as implementações de dispositivos automotivos oferecerem suporte ao OpenGL ES 3.1, elas:

  • [7.1.4.1/A-0-1] PRECISA declarar OpenGL ES 3.1 ou mais recente.
  • [7.1.4.1/A-0-2] PRECISA oferecer suporte ao Vulkan 1.1.
  • [7.1.4.1/A-0-3] PRECISA incluir o carregador do Vulkan. e exportar todos os símbolos.

Se as implementações de dispositivos automotivos incluírem suporte ao Vulkan, elas:

Implementações de dispositivos automotivos:

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Encerrar novos requisitos

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [7.2.3/A-0-1] PRECISA fornecer a Página inicial e funções de retorno e PODEM fornecer Voltar e o Funções recentes.

Encerrar novos requisitos

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Se as implementações de dispositivos automotivos oferecerem suporte a multiusuário simultâneo (em que vários usuários de Android podem interagir com o dispositivo ao mesmo tempo, cada uma usando sua própria tela ao config_multiuserVisibleBackgroundUsers estiver ativado), eles:

  • [7.3/A-1-1] PRECISA definir o NIGHT_MODE Sinalize o valor de forma consistente com o modo dia/noite do painel todas as telas, incluindo as do assento traseiro.

Encerrar novos requisitos

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

  • [7.3.1/A-1-1] PRECISA relatar eventos até uma frequência. de pelo menos 100 Hz.

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

  • [7.3.1/A-SR-1] É FORTEMENTE RECOMENDADO para implementar a sensor composto para acelerômetro de eixos limitados.

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

  • [7.3.1/A-1-3] PRECISA implementar e informar Sensor TYPE_ACCELEROMETER_LIMITED_AXES.
  • [7.3.1/A-1-4] PRECISA implementar e informar Sensor TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

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

  • [7.3.4/A-2-1] PRECISA relatar eventos até uma frequência. de pelo menos 100 Hz.
  • [7.3.4/A-2-3] PRECISA ser capaz de medir mudanças de orientação. até 250 graus por segundo.
  • [7.3.4/A-SR-1] É FORTEMENTE RECOMENDADO para configurar o intervalo de medida do giroscópio para +/-250 dps, a fim de maximizar a resolução sempre que possível.

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

  • [7.3.4/A-SR-2] É FORTEMENTE RECOMENDADO para implementar a sensor composto para giroscópio de eixos limitados.

Se as implementações de dispositivos automotivos incluírem um giroscópio com menos de três eixos, elas:

  • [7.3.4/A-4-1] PRECISA implementar e informar Sensor TYPE_GYROSCOPE_LIMITED_AXES.
  • [7.3.4/A-4-2] PRECISA implementar e informar Sensor TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

Se as implementações de dispositivos automotivos incluírem um receptor GPS/GNSS, mas não incluem conectividade de dados com base em rede celular, eles:

  • [7.3.3/A-3-1] PRECISA determinar o local na primeira vez. Se o receptor GPS/GNSS estiver ligado ou após 4 ou mais dias dentro de 60 segundos.
  • [7.3.3/A-3-2] PRECISA atender aos critérios de tempo até a primeira correção, descritos em 7.3.3/C-1-2 e 7.3.3/C-1-6 para todas as outras solicitações de local (ou seja, solicitações que não são a primeira vez nunca ou depois de mais de quatro dias). O requisito 7.3.3/C-1-2 é normalmente atendidas em veículos sem conectividade de dados baseada em rede celular, usando previsões de órbita de GNSS calculadas no receptor ou última localização conhecida do veículo e a capacidade de detectar mortos pelo menos 60 segundos com uma precisão de posição satisfatória 7.3.3/C-1-3 ou uma combinação de ambos.

Se as implementações de dispositivos automotivos incluírem um sensor TYPE_HEADING, elas:

  • [7.3.4/A-4-3] PRECISA relatar eventos até uma frequência. de pelo menos 1 Hz.
  • [7.3.4/A-SR-3] STRONGLY_RECOMMENDED para relatar eventos de até um de pelo menos 10 Hz.
  • DEVE se referir ao norte verdadeiro.
  • DEVE estar disponível mesmo quando o veículo estiver parado.
  • DEVE ter uma resolução de pelo menos 1 grau.

Implementações de dispositivos automotivos:

  • [7.4.3/A-0-1] PRECISA ser compatível com Bluetooth e DEVE oferecer suporte a Bluetooth LE.
  • [7.4.3/A-0-2] Implementações do Android Automotive PRECISA oferecer suporte aos seguintes perfis Bluetooth:
    • Chamadas telefônicas pelo perfil viva-voz (HFP, na sigla em inglês).
    • Reprodução de mídia no perfil de distribuição de áudio (A2DP, na sigla em inglês).
    • Controle de reprodução de mídia sobre o perfil de controle remoto (AVRCP, na sigla em inglês).
    • Compartilhamento de contatos usando o perfil de acesso à agenda telefônica (PBAP, na sigla em inglês).

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [7.4.3/A-SR-1] É FORTEMENTE RECOMENDADO para o suporte Perfil de acesso a mensagens (MAP, na sigla em inglês) se o dispositivo tiver a zona de ocupante do motorista.

Encerrar novos requisitos

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Se as implementações de dispositivos automotivos oferecerem suporte a multiusuário simultâneo (em que vários usuários de Android podem interagir com o dispositivo ao mesmo tempo, cada uma usando sua própria tela ao config_multiuserVisibleBackgroundUsers estiver ativado), eles:

  • [7.4.3/A-1-1] PRECISA ser independente e NÃO interferir. com os de outros usuários experiência de BT.

Encerrar novos requisitos

Implementações de dispositivos automotivos:

  • [7.4.5/A] DEVE incluir suporte para celular conectividade de dados baseada em rede.
  • [7.4.5/A] PODE usar a API System Constante NetworkCapabilities#NET_CAPABILITY_OEM_PAID para redes que devem estar disponíveis para apps do sistema.

Se as implementações do dispositivo incluem suporte a rádio de transmissão AM/FM e exposição a funcionalidade de qualquer aplicativo, elas:

  • [7.4/A-1-1] PRECISA declarar suporte para FEATURE_BROADCAST_RADIO.

Uma câmera traseira significa uma câmera voltada para o mundo que pode ser localizada em qualquer colocado no veículo e voltado para o lado de fora da cabine do veículo; ou seja, imagens na lateral do corpo do veículo, como na câmera traseira.

Uma câmera frontal refere-se a uma câmera voltada ao usuário que pode ser localizada em qualquer colocado no veículo e voltado para dentro da cabine dele; isso imagens que o usuário pode usar, por exemplo, para videoconferências e aplicativos semelhantes.

Implementações de dispositivos automotivos:

  • [7.5/A-SR-1] É FORTEMENTE RECOMENDADO a inclusão de uma ou mais visualizações câmeras.
  • PODE incluir uma ou mais câmeras voltadas para o usuário.
  • [7.5/A-SR-2] É FORTEMENTE RECOMENDADO para oferecer suporte ao streaming simultâneo de várias câmeras.

Se as implementações de dispositivos automotivos incluírem pelo menos uma câmera voltadas para o mundo, para uma câmera, eles:

  • [7.5/A-1-1] PRECISA estar orientada de modo que a dimensão longa da câmera se alinhe. com o plano X-Y dos eixos dos sensores automotivos do Android.
  • [7.5/A-SR-3] É FORTEMENTE RECOMENDADO ter foco fixo ou EDOF (profundidade de campo estendida).
  • [7.5/A-1-2] PRECISA ter a câmera frontal como a principal câmera com o menor ID de câmera.

Se as implementações de dispositivos automotivos incluírem pelo menos uma câmera voltado para o usuário, para uma câmera desse tipo:

  • [7.5/A-2-1] A principal câmera voltada ao usuário PRECISA ser a câmera voltada ao usuário. com o menor ID de câmera.
  • PODE ser orientado de modo que a dimensão longa da câmera se alinhe com o eixo X-Y plano dos eixos dos sensores automotivos do Android.

Se as implementações de dispositivos automotivos incluírem uma câmera acessível via API android.hardware.Camera ou android.hardware.camera2, eles:

  • [7.5/A-3-1] PRECISA obedecer aos principais requisitos de câmera da seção 7.5.

Se as implementações de dispositivos automotivos incluírem uma câmera inacessível usando a API android.hardware.Camera ou android.hardware.camera2, eles:

  • [7.5/A-4-1] PRECISA estar acessível pelo serviço do sistema de visualização estendida.

Se as implementações de dispositivos automotivos incluírem uma ou mais câmeras acessíveis por meio de Serviço de sistema de visualização estendido, para essa câmera, eles:

  • [7.5/A-5-1] NÃO PODE girar nem espelhar a visualização da câmera horizontalmente.
  • [7.5/A-SR-4] É FORTEMENTE RECOMENDADO que tenha uma resolução de pelo menos 1,3 megapixels.

Se as implementações de dispositivos automotivos incluem uma ou mais câmeras acessível pelo Serviço do sistema de visualização estendida e pelo android.hardware.Camera ou a API android.hardware.Camera2, para essa câmera, eles:

  • [7.5/A-6-1] PRECISA informar o mesmo ID da câmera.

Se as implementações de dispositivos automotivos fornecerem uma API de câmera reservada, elas:

Implementações de dispositivos automotivos:

  • [7.6.1/A-0-1] PRECISA ter pelo menos 4 GB de armazenamento não volátil disponível para dados privados de aplicativos (partição /data).

  • [7.6.1/A] DEVE formatar a partição de dados para oferecer melhor desempenho e longevidade no armazenamento flash (por exemplo, usando o sistema de arquivos f2fs).

Se as implementações de dispositivos automotivos fornecerem armazenamento externo compartilhado por meio de um do armazenamento interno não removível, elas:

  • [7.6.1/A-SR-1] É FORTEMENTE RECOMENDADO para reduzir Overhead de E/S em operações realizadas no armazenamento externo, por exemplo, usando SDCardFS.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Se as implementações de dispositivos automotivos oferecerem suporte a multiusuário simultâneo (em que vários usuários de Android podem interagir com o dispositivo ao mesmo tempo, cada uma usando sua própria tela ao config_multiuserVisibleBackgroundUsers estiver ativado), eles:

  • [7.6.1/A-1-1] PRECISA ter, em uma única instância do AAOS, pelo menos 4 GB para cada usuário Android simultâneo de armazenamento não volátil disponível para dados privados do aplicativo (partição /data).

Encerrar novos requisitos

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

Iniciar novos requisitos para a versão 15 (AOSP experimental)

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

    • 280 dpi ou menos em telas pequenas/normais
    • Ldpi ou menor em telas muito grandes
    • 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. por tela principal se alguma das densidades a seguir for usada:

    • xhdpi ou maior em telas pequenas/normais
    • hdpi ou maior em telas grandes
    • mdpi ou maior em telas muito grandes
  • [7.6.1/A-2-3] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 1.280 MB por tela principal se alguma das densidades a seguir for usada:

    • 400 dpi ou mais em telas pequenas/normais
    • xhdpi ou maior em telas grandes
    • tvdpi ou maior em telas muito grandes
  • [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 1.824 MB por tela principal se alguma das densidades a seguir for usada:

    • 560 dpi ou mais em telas pequenas/normais
    • 400 dpi ou mais em telas grandes
    • xhdpi ou maior em telas muito grandes

Observe que a "memória disponível para o kernel e o espaço do usuário" acima refere-se à além de qualquer memória já dedicada ao hardware como rádio, vídeo, entre outros, que não estão no kernel nas implementações de dispositivos.

Encerrar novos requisitos

Implementações de dispositivos automotivos:

  • [7.7.1/A] DEVE incluir uma porta USB compatível com o modo de periféricos.

Implementações de dispositivos automotivos:

  • [7.8.1/A-0-1] PRECISA incluir um microfone.

Implementações de dispositivos automotivos:

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

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Se as implementações de dispositivos automotivos oferecerem suporte a multiusuário simultâneo (em que vários usuários de Android podem interagir com o dispositivo ao mesmo tempo, cada uma usando sua própria tela ao config_multiuserVisibleBackgroundUsers estiver ativado), eles:

  • [7.8.2/A-1-1] PRECISA ter um dispositivo de saída de áudio para cada principal para vários sistemas de usuários simultâneos.
  • [7.8.2/A-1-2] PRECISA ter uma zona de áudio do driver que cubra a alto-falante global da cabine. A zona do passageiro da frente pode compartilhar o áudio do motorista ou ter a própria saída de áudio.

Encerrar novos requisitos

2.5.2 Multimídia

As implementações de dispositivos automotivos PRECISAM oferecer suporte à codificação de áudio a seguir. e decodificação e disponibilizá-los para aplicativos de terceiros:

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

As implementações de dispositivos automotivos PRECISAM oferecer suporte à seguinte codificação de vídeo: formatos e disponibilizá-los para aplicativos de terceiros:

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

As implementações de dispositivos automotivos PRECISAM oferecer suporte à decodificação de vídeo a seguir. formatos e disponibilizá-los para aplicativos de terceiros:

  • [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

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

  • [5,3/A-SR-1] H.265 HEVC

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Se as implementações de dispositivos automotivos oferecerem suporte a multiusuário simultâneo (em que vários usuários de Android podem interagir com o dispositivo ao mesmo tempo, cada uma usando sua própria tela ao config_multiuserVisibleBackgroundUsers estiver ativado), eles:

  • [5.5.3/A-1-1] PRECISA definir curvas de volume idênticas para todos os streams de saída de áudio mapeados para o mesmo grupo de volumes, conforme definido no arquivo de configuração de áudio do carro.

Encerrar novos requisitos

2.5.3 Software

Implementações de dispositivos automotivos:

  • [3/A-0-1] PRECISA declarar o recurso android.hardware.type.automotive

  • [3/A-0-2] PRECISA oferecer suporte a uiMode = UI_MODE_TYPE_CAR.

  • [3/A-0-3] PRECISA oferecer suporte a todas as APIs públicas nos android.car.* .

Se as implementações de dispositivos automotivos fornecerem uma API reservada usando android.car.CarPropertyManager com android.car.VehiclePropertyIds, eles:

  • [3/A-1-1] NÃO PODE anexar privilégios especiais ao sistema o uso dessas propriedades por parte de um aplicativo ou impedem que aplicativos de terceiros do uso dessas propriedades.
  • [3/A-1-2] NÃO PODE replicar uma propriedade do veículo que já existe no SDK.

Implementações de dispositivos automotivos:

  • [3.2.1/A-0-1] PRECISA oferecer suporte e aplicar todas constantes de permissão, conforme documentado pela página de referência de permissões automotivas.

  • [3.2.3.1/A-0-1] PRECISA pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents para todos padrões de filtro de intent pública definidos pelas seguintes intents de aplicativo listados aqui.

  • [3.4.1/A-0-1] PRECISA fornecer um implementação da API android.webkit.Webview.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [3.8/A-0-1] NÃO PODE permitir que usuários secundários completos que não sejam o usuário atual em primeiro plano iniciem atividades e tenham acesso à interface em nenhuma tela.

Se as implementações de dispositivos automotivos oferecerem suporte a multiusuário simultâneo (em que vários usuários de Android podem interagir com o dispositivo ao mesmo tempo, cada uma usando sua própria tela ao config_multiuserVisibleBackgroundUsers está ativada), para usuários secundários completos que não são o usuário em primeiro plano atual mas tiverem acesso de interface à tela, eles:

Encerrar novos requisitos

Implementações de dispositivos automotivos:

  • [3.8.3/A-0-1] PRECISA exibir notificações que usam o Notification.CarExtender API quando solicitado por aplicativos de terceiros.

  • [3.8.4/A-SR-1] São altamente recomendados para implementar um assistente no dispositivo e processar a ação de assistência.

Se as implementações de dispositivos automotivos incluírem um botão "push-to-talk", elas:

  • [3.8.4/A-1-1] PRECISA usar um pressionamento curto de o botão de pressionar para falar como a interação designada para iniciar o app assistivo selecionado pelo usuário, ou seja, o app que implementa VoiceInteractionService.

Implementações de dispositivos automotivos:

  • [3.8.3.1/A-0-1] PRECISA corretamente renderize recursos conforme descrito em Notifications on Automotive OS na documentação do SDK.
  • [3.8.3.1/A-0-2] PRECISA exibir PLAY e MUTE para ações de notificação no lugar daquelas fornecidas por Notification.Builder.addAction()
  • [3.8.3.1/A] DEVE restringir as o uso de tarefas de gerenciamento avançado, como controles por canal de notificação. PODE usar recursos de interface por aplicativo para reduzir os controles.

Se as implementações de dispositivos automotivos oferecerem suporte às propriedades da HAL de usuário, elas:

Implementações de dispositivos automotivos:

Se as implementações de dispositivos automotivos incluírem um app de tela de início padrão, elas:

Implementações de dispositivos automotivos:

  • [3.8/A] PODE restringir o aplicativo solicitações para entrar no modo de tela cheia, conforme descrito em immersive documentation.
  • [3.8/A] PODE manter a barra de status e a barra de navegação sempre visível.
  • [3.8/A] PODE restringir o aplicativo solicitações para alterar as cores atrás dos elementos da interface do sistema, a fim de garantir esses elementos estejam claramente visíveis em todos os momentos.

2.5.4 Desempenho e potência

Implementações de dispositivos automotivos:

  • [8.2/A-0-1] PRECISA informar o número de bytes lidos e gravados no armazenamento não volátil por UID de cada processo para que os as estatísticas são disponibilizadas aos desenvolvedores pela API do sistema. android.car.storagemonitoring.CarStorageMonitoringManager O Android Open O projeto de origem atende ao requisito pelo módulo do kernel uid_sys_stats.
  • [8.3/A-1-3] PRECISA oferecer suporte ao modo garagem.
  • [8.3/A] DEVE ficar no modo garagem por pelo menos 15 minutos após cada percurso, a menos que:
    • A bateria está descarregada.
    • Nenhum job ocioso está programado.
    • O motorista sai do modo garagem.
  • [8.4/A-0-1] PRECISA fornecer uma perfil de energia por componente que define o valor de consumo atual para cada componente de hardware e o consumo aproximado da bateria causado pelo ao longo do tempo, conforme documentado no site do Android Open Source Project.
  • [8.4/A-0-2] PRECISA informar toda a energia valores de consumo em milissegundos/hora (mAh).
  • [8.4/A-0-3] PRECISA informar a energia da CPU. e consumo de acordo com o UID de cada processo. O Android Open Source Project atende à requisito pela implementação do módulo do kernel uid_cputime.
  • [8.4/A] DEVE ser atribuída ao componente de hardware em si, se não for possível atribuir o uso de energia do componente de hardware a um aplicativo.
  • [8.4/A-0-4] PRECISA fazer esse uso de energia disponível no adb shell dumpsys batterystats shell para o desenvolvedor do app.

2.5.5 Modelo de segurança

Se as implementações de dispositivos automotivos oferecerem suporte a vários usuários, elas:

Se as implementações de dispositivos automotivos declararem android.hardware.microphone, eles:

  • [9.8.2/A-1-1] PRECISA exibir o indicador de microfone quando: um aplicativo está acessando dados de áudio do microfone, mas não quando o o microfone só é acessado por HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService ou apps com os papéis destacados seção 9.1 com o identificador CDD [C-4-X].
  • [9.8.2/A-1-2] NÃO PODE ocultar o indicador de microfone para apps do sistema com interfaces do usuário visíveis ou interação direta com o usuário.
  • [9.8.2/A-1-3] PRECISA fornecer uma funcionalidade de usuário para alternar o microfone no app Configurações.

Se as implementações de dispositivos automotivos declararem android.hardware.camera.any, eles:

  • [9.8.2/A-2-1] PRECISA exibir o indicador da câmera quando um está acessando dados da câmera em tempo real, mas não quando ela está sendo acessado por aplicativos que desempenham as funções definidas no Seção 9.1 Permissões com o identificador CDD [C-4-X].
  • [9.8.2/A-2-2] NÃO PODE ocultar o indicador da câmera para apps do sistema com interfaces do usuário visíveis ou interação direta com o usuário.
  • [9.8.2/A-2-3] PRECISA fornecer uma funcionalidade de usuário para ativar ou desativar a câmera no app Configurações.
  • [9.8.2/A-2-4] PRECISA exibir apps recentes e ativos usando a câmera como retornado de PermissionManager.getIndicatorAppOpUsageData(), junto com mensagens de atribuição associadas a elas.

Implementações de dispositivos automotivos:

  • [9/A-0-1] PRECISA declarar a android.hardware.security.model.compatible .
  • [9.11/A-0-1] PRECISA fazer backup da implementação de keystore. com um ambiente de execução isolado.
  • [9.11/A-0-2] PRECISA ter implementações de RSA, AES, Algoritmos criptográficos ECDSA e HMAC e família MD5, SHA-1 e SHA-2 para oferecer suporte adequado ao suporte do sistema Android Keystore algoritmos em uma área segura e isolada do código em execução kernel e acima. O isolamento seguro PRECISA bloquear todos os possíveis mecanismos. pelo qual o código do kernel ou do espaço do usuário pode acessar o estado interno da ambiente isolado, incluindo DMA. O Android Open Source upstream O Project (AOSP) atende a esse requisito usando a implementação Trusty, mas outra Uma solução baseada em ARM TrustZone ou uma solução verificada por terceiros como segura a implementação adequada de um isolamento baseado em hipervisor são alternativas .
  • [9.11/A-0-3] PRECISA executar a tela de bloqueio. no ambiente de execução isolado e somente ao bem-sucedido, permite o uso das chaves vinculadas à autenticação. Bloquear tela as credenciais PRECISAM ser armazenadas de uma forma que permita somente a execução isolada para executar a autenticação da tela de bloqueio. O sistema upstream do Android O Open Source Project oferece Camada de abstração de hardware (HAL) Gatekeeper e o Trusty, que podem ser usados para atender a esse requisito.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [9.11/A-0-4] PRECISA oferecer suporte ao atestado de chaves em que o a chave de assinatura de atestado é protegida por um hardware seguro e a assinatura é executadas em hardware seguro. As chaves de assinatura de atestado PRECISAM ser compartilhadas entre um número grande de dispositivos para impedir as chaves evitados deixem de ser usados como permanentes identificadores de dispositivo. Uma maneira de atender a esse requisito é compartilhar os mesma chave de atestado,a menos que pelo menos 100.000 unidades de uma determinada SKU sejam produzidos. Se mais de 100.000 unidades de uma SKU forem produzidas, outro pode ser usada para cada 100.000 unidades.

Encerrar novos requisitos

Se uma implementação de dispositivo já tiver sido iniciada em uma versão anterior versão, tal dispositivo está isento da exigência de ter um keystore em um ambiente de execução isolado e oferecem suporte ao atestado de chaves, a menos que declare o recurso android.hardware.fingerprint, que requer uma um keystore apoiado por um ambiente de execução isolado.

Implementações de dispositivos automotivos:

  • [9.14/A-0-1] Mensagens de gatekeep PRECISA dos subsistemas do veículo do framework do Android (por exemplo, colocar uma mensagem permitida na lista de permissões) tipos e origens de mensagens.
  • [9,14/A-0-2] PRECISA praticar o monitoramento contra ataques de negação de serviço do framework do Android ou de apps de terceiros. Isso protege contra software malicioso que inunda a rede do veículo com tráfego, o que pode causar o defeito de subsistemas do veículo.

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

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Implementações de dispositivos automotivos:

  • Perfetto (link em inglês)
    • [6.1/A-0-1] PRECISA expor um /system/bin/perfetto. binário para o usuário do shell com o qual o cmdline obedece a documentação do perfetto.
    • [6.1/A-0-2] O binário do perfetto PRECISA ser aceito como insira uma configuração protobuf que esteja em conformidade com o esquema definido em a documentação do perfetto.
    • [6.1/A-0-3] O binário do perfetto PRECISA ser escrito como gera um trace protobuf que cumpre o esquema definido em a documentação do perfetto.
    • [6.1/A-0-4] PRECISA fornecer, pelo perfetto. binário, pelo menos as fontes descritas nos a documentação do perfetto.
    • [6.1/A-0-5] O daemon rastreado do perfetto PRECISA estar ativado por padrão (propriedade do sistema persist.traced.enable).

Encerrar novos requisitos

2,6 Requisitos para tablets

Um tablet Android se refere a uma implementação de dispositivo Android que geralmente atende a todos os critérios a seguir:

  • Usado por segurar as duas mãos.
  • Não tem configuração flip ou conversível.
  • As implementações de teclado físico usadas com o dispositivo são conectadas por usando uma conexão padrão (por exemplo, USB ou Bluetooth).
  • tem uma fonte de energia que oferece mobilidade, como uma bateria;

  • Tem uma tela com tamanho maior que 7” e menor que 18”, medidas diagonalmente.

Implementações de tablets têm requisitos semelhantes aos de dispositivos portáteis e implementações. As exceções são indicadas por um * na seção e indicados para referência nesta seção.

2.6.1. Hardware

Giroscópio

Se as implementações de tablets incluírem um giroscópio de três eixos, elas:

  • [7.3.4/Tab-1-1] PRECISA ser capaz de medir a orientação. muda até 1.000 graus por segundo.

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

As densidades de tela listadas para telas pequenas/normais no dispositivo portátil não se aplicam a tablets.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

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

Se as implementações de tablets incluírem uma porta USB compatível com periféricos , eles:

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

Encerrar novos requisitos

Modo de realidade virtual (Seção 7.9.1)

Alto desempenho da realidade virtual (Seção 7.9.2)

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

2.6.2. Modelo de segurança

Chaves e credenciais (Seção 9.11)

Consulte a Seção [9.11].

Se as implementações de tablets incluem vários usuários e não declararem a flag de recurso android.hardware.telephony, eles:

  • [9.5/T-1-1] PRECISA oferecer suporte a perfis restritos, um recurso que permite que os proprietários de dispositivos gerenciem outros usuários e do dispositivo. Com 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 de tablets incluem vários usuários e declararem a flag de recurso android.hardware.telephony, eles:

  • [9.5/T-2-1] NÃO PODE oferecer suporte a restrições perfis, mas PRECISA estar alinhada com a implementação de controles do AOSP para ativar ou desativar o acesso de outros usuários a chamadas de voz e SMS.

2.6.2. Software

  • [3.2.3.1/Tab-0-1] PRECISA pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents para todos os padrões de filtro de intent pública definidos pelas seguintes intents de aplicativo listados aqui.

3. Software

3.1. Compatibilidade com APIs gerenciadas

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

Implementações de dispositivos:

  • [C-0-1] PRECISA fornecer implementações completas, incluindo todas as documentações do que qualquer API documentada exposta pelo SDK do Android ou qualquer API decorada com a tag "@SystemApi", no diretório upstream do Android o código-fonte.

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

  • [C-0-3] NÃO PODE omitir nenhuma API gerenciada, alterar interfaces ou assinaturas de API, desviam do comportamento documentado ou incluem ambiente autônomo, exceto quando permitido especificamente por esta definição de compatibilidade.

  • [C-0-4] Ainda PRECISA manter as APIs presentes e se comportar. de forma razoável, mesmo quando alguns recursos de hardware para os quais o inclui APIs são omitidas. Consulte a seção 7 para requisitos específicos desse cenário.

  • [C-0-5] NÃO PODE permitir que apps de terceiros usem interfaces externas ao SDK, o que são definidos como métodos e campos nos pacotes de linguagem Java que são no caminho de classe de inicialização no AOSP e que não façam parte da SDK do Vertex AI Pipelines. Isso inclui APIs decoradas com a anotação @hide, mas não com um @SystemAPI, conforme descrito nos documentos do SDK. e membros particulares e privados do pacote.

  • [C-0-6] PRECISA ser enviado com todas as interfaces externas ao SDK no mesmo listas fornecidas pelas sinalizações provisórias e de lista de bloqueio em prebuilts/runtime/appcompat/hiddenapi-flags.csv caminho para a ramificação de nível de API adequada no AOSP.

  • [C-0-7] PRECISA ser compatível com a configuração assinada. mecanismo de atualização dinâmica para remover interfaces externas ao SDK de uma lista restrita incorporando a configuração assinada em qualquer APK, usando as chaves públicas existentes presentes no AOSP.

    No entanto, elas:

    • MAIS, se uma API oculta estiver ausente ou tiver sido implementada de maneira diferente no dispositivo de implementação, mova a API oculta para a lista de bloqueio ou omita a API todas as listas restritas.
    • MAIS, se ainda não existir uma API oculta no AOSP, adicione a API oculta a qualquer uma das listas restritas.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [C-0-8] NÃO PODE oferecer suporte à instalação de aplicativos direcionados a um nível de API menor que 23 24.

Encerrar novos requisitos

3.1.1. Extensões Android

O Android oferece suporte à extensão da superfície de API gerenciada de um nível de API específico ao atualizando a versão da extensão desse nível de API. A A API android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) retorna o versão da extensão do apiLevel fornecido, se houver extensões para ele Nível da API.

Implementações de dispositivos Android:

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

  • [C-0-2] PRECISA retornar somente números válidos de versão de extensão que tenham sido definido pelo AOSP.

  • [C-0-3] PRECISA oferecer suporte a todas as APIs definidas pelas versões da extensão. devolvido por android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) da mesma maneira que outras APIs gerenciadas têm suporte, seguindo os requisitos na seção 3.1.

3.1.2. Biblioteca do Android

Devido à descontinuação do cliente Apache HTTP, implementações de dispositivos:

  • [C-0-1] NÃO PODE colocar a biblioteca org.apache.http.legacy no bootclasspath.
  • [C-0-2] É NECESSÁRIO adicionar a biblioteca org.apache.http.legacy ao aplicativo o caminho de classe somente quando o app atender a uma destas condições:
    • Segmenta a API de nível 28 ou anterior.
    • Declara no manifesto que precisa da biblioteca definindo a propriedade Atributo android:name de <uses-library> a org.apache.http.legacy.

A implementação do AOSP atende a esses requisitos.

3.2. Compatibilidade leve com APIs

Além das APIs gerenciadas da seção 3.1, O Android também inclui uma implementação significativa somente API, na forma de tais itens como intents, permissões e aspectos semelhantes de aplicativos Android que não podem ser aplicadas no tempo de compilação do aplicativo.

3.2.1. Permissões

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

3.2.2. Parâmetros de build

As APIs do Android incluem várias constantes no Classe android.os.Build que descrevem o dispositivo atual.

  • [C-0-1] Para oferecer valores consistentes e significativos em todos os dispositivos implementações, a tabela abaixo inclui restrições adicionais sobre os formatos desses valores com os quais as implementações de dispositivos PRECISAM estar em conformidade.
Parâmetro Detalhes
VERSÃO.LANÇAMENTO A versão do sistema Android em execução no momento, em formato legível . Este campo PRECISA ter um dos valores de string definidos em Strings de versão permitidas para o Android 15.
VERSION.SDK A versão do sistema Android em execução no momento, em um formato pode ser acessado por códigos de aplicativos de terceiros. No Android 15, este campo PRECISA ter o valor inteiro: 15_INT.
VERSION.SDK&lowbar;INT A versão do sistema Android em execução no momento, em um formato pode ser acessado por códigos de aplicativos de terceiros. No Android 15, este campo PRECISA ter o valor inteiro 15&lowbar;INT.
VERSÃO.INCREMENTAL Um valor escolhido pelo implementador do dispositivo, designando o build específico do sistema Android em execução no momento e em formato legível por humanos. Isso O valor NÃO PODE ser reutilizado para builds diferentes disponibilizados aos usuários finais. Um uso típico deste campo é para indicar qual número da versão ou o identificador de mudanças de controle de origem foi usado para gerar o build. O valor desse campo PRECISA ser codificado como ASCII de 7 bits para impressão e corresponder à expressão regular ^[^ :\/~]+$.
TABULEIRO Um valor escolhido pelo implementador do dispositivo para identificar o hardware interno usado pelo dispositivo, em formato legível por humanos. Uma possível o uso deste campo é para indicar a revisão específica da placa que fornece energia o dispositivo. O valor deste 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 associada ao dispositivo, como conhecido pelo os usuários finais. PRECISA estar em um formato legível por humanos e DEVE representar os fabricante do dispositivo ou a marca da empresa sob a qual o dispositivo está comercializados. O valor deste campo PRECISA ser codificável como ASCII de 7 bits e corresponder. a expressão regular ^[a-zA-Z0-9_-]+$.
ABIS&lowbar;COMPATÍVEIS O nome do conjunto de instruções (tipo de CPU + convenção ABI) de código nativo o código-fonte. Consulte a seção 3.3. API nativa Compatibilidade.
ABIS&lowbar;32&lowbar;BIT&lowbar;suportadas O nome do conjunto de instruções (tipo de CPU + convenção ABI) de código nativo o código-fonte. Consulte a seção 3.3. API nativa Compatibilidade.
ABIS&lowbar;64&lowbar;BIT&lowbar;suportadas O nome do segundo conjunto de instruções (tipo de CPU + convenção ABI) de o código nativo. Consulte a seção 3.3. Nativo Compatibilidade da API.
ABI de CPU O nome do conjunto de instruções (tipo de CPU + convenção ABI) de código nativo o código-fonte. Consulte a seção 3.3. API nativa Compatibilidade.
CPU&lowbar;ABI2 O nome do segundo conjunto de instruções (tipo de CPU + convenção ABI) de o código nativo. Consulte a seção 3.3. Nativo Compatibilidade da API.
DISPOSITIVO Um valor escolhido pelo implementador do dispositivo contendo o nome de desenvolvimento ou codinome que identifica a configuração dos recursos de hardware e o design industrial do dispositivo. O valor deste campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular ^[a-zA-Z0-9_-]+$: O nome deste dispositivo NÃO PODE ser alterado durante o de vida útil do produto.
IMPRESSORA Uma string que identifica exclusivamente este build. DEVE ser razoavelmente legível por humanos. Ele PRECISA seguir este modelo:

$(MARCA)/$(PRODUTO)/
$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

Exemplo:

acme/meuproduto/
mydevice:15/LMYXX/3359:userdebug/test-keys

A impressão digital NÃO PODE incluir caracteres de espaço em branco. O valor de este campo PRECISA ser codificável como ASCII de 7 bits.

HARDWARE O nome do hardware (da linha de comando do kernel ou /proc). Ela DEVE ser legíveis por humanos. O valor deste campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular ^[a-zA-Z0-9_-]+$:
APRESENTADOR String que identifica exclusivamente o host em que o build foi criado. legível por humanos. Não há requisitos sobre o formato específico dos neste campo, exceto que NÃO PODE ser nulo ou a string vazia ("").
ID Um identificador escolhido pelo implementador do dispositivo para se referir a um determinado em um formato legível por humanos. Esse campo pode ser igual a android.os.Build.VERSION.INCREMENTAL, mas DEVE ser um valor suficiente. importante para os usuários finais distinguirem builds de software. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder ao padrão expressão ^[a-zA-Z0-9._-]+$.
FABRICANTE O nome comercial do fabricante de equipamento original (OEM) do produto. Não há requisitos para o formato específico desse campo, exceto que NÃO PODE ser nulo ou uma string vazia (""). Este campo NÃO PODE ser alterado durante a vida útil do produto.
FABRICANTE&DURANTE O nome comercial do fabricante do sistema principal em (SOC) usado no produto. Dispositivos com o mesmo fabricante de SOC devem usar o mesmo valor constante. Solicite ao fabricante do SOC a constante correta a ser usada. O valor deste campo PRECISA ser codificável como ASCII de 7 bits, PRECISA corresponder à expressão regular. ^([0-9A-Za-z ]+), NÃO PODE começar ou terminar com espaço em branco. e NÃO PODE ser igual a "unknown". Este campo NÃO PODE ser alterado durante o de vida útil do produto.
MODELO&lowbar;SOC O nome do modelo do sistema principal em um chip (SOC) usado na o produto. Dispositivos com o mesmo modelo de SOC precisam usar a mesma constante . Peça ao fabricante do SOC a constante correta a ser usada. O valor deste campo PRECISA ser codificável como ASCII de 7 bits e corresponder ao expressão regular ^([0-9A-Za-z ._/+-]+)$, NÃO PODE iniciar ou terminar com um espaço em branco e NÃO PODE ser igual a "unknown". Este campo NÃO PODE ser alterado durante a vida útil do produto.
MODEL Um valor escolhido pelo implementador do dispositivo contendo o nome do dispositivo conhecido pelo usuário final. Este DEVE ser o mesmo nome usado o dispositivo é comercializado e vendido aos usuários finais. Não há requisitos para o formato específico deste campo, exceto que ele NÃO PODE ser nulo nem string vazia (""). Este campo NÃO PODE ser alterado durante o de vida útil do produto.
PRODUTO Um valor escolhido pelo implementador do dispositivo contendo o nome de desenvolvimento ou codinome do produto específico (SKU) que PRECISAM ser exclusivos dentro da pela mesma marca. PRECISA ser legível, mas não se destina necessariamente à visualização. pelos usuários finais. O valor deste campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular ^[a-zA-Z0-9_-]+$. Este produto O nome NÃO PODE ser alterado durante a vida útil do produto.
SKU do ODM Um valor opcional escolhido pelo implementador do dispositivo que contém SKU (unidade de manutenção de estoque) usada para rastrear configurações específicas do dispositivo, por exemplo, qualquer periférico incluído no dispositivo, quando vendido. O valor deste campo PRECISA ser codificável como ASCII de 7 bits e corresponder ao expressão regular ^([0-9A-Za-z.,_-]+)$.
SÉRIE PRECISA retornar "UNKNOWN".
TAGS Uma lista separada por vírgulas de tags escolhidas pelo implementador do dispositivo que diferencia ainda mais o build. As tags PRECISAM ser codificadas como ASCII de 7 bits. e corresponder às expressões regulares ^[a-zA-Z0-9._-]+ e PRECISA têm um dos valores que correspondem aos três tipos de plataforma típicas de assinatura: chaves de lançamento, dev-keys e chaves de teste.
HORÁRIO Um valor que representa o carimbo de data/hora de quando o build ocorreu.
MÁQUINA Valor escolhido pelo implementador do dispositivo, especificando o ambiente de execução e a configuração do build. Este campo PRECISA ter um dos valores correspondentes às três configurações típicas do ambiente de execução do Android: usuário, userdebug ou eng.
USUÁRIO Um nome ou ID do usuário (ou usuário automatizado) que gerou o ser construído. Não há requisitos para o formato específico desse campo, exceto que NÃO PODE ser nulo ou uma string vazia ("").
SEGURANÇA&lowbar;PATCH Um valor que indica o nível do patch de segurança de uma versão. Ela PRECISA significar que o build não é de forma alguma vulnerável a nenhum dos problemas descritos com o boletim de segurança pública do Android. Ela PRECISA estar no formato [AAAA-MM-DD], correspondendo a uma string definida documentada no Segurança pública do Android Boletim ou no Consultoria de segurança do Android, por exemplo, "2015-11-01".
SO BÁSICO Um valor que representa o parâmetro FINGERPRINT da compilação que é idêntico a este build, exceto pelos patches fornecidos no Boletim de segurança pública do Android. Ela PRECISA informar o valor correto e, se um build desse tipo não existir, informe uma string vazia ("").
BOOTLOADER Um valor escolhido pelo implementador do dispositivo para identificar o A versão do carregador de inicialização interno usado no dispositivo, em formato legível por humanos. O valor deste campo PRECISA ser codificável como ASCII de 7 bits e corresponder ao expressão regular ^[a-zA-Z0-9._-]+$.
getRadioVersion() (link em inglês) PRECISA (ser ou retornar) um valor escolhido pelo implementador do dispositivo. identificando a versão interna específica do rádio/modem usada no dispositivo, em um formato legível por humanos. Se um dispositivo não tiver rádio/modem, ele PRECISA retornar NULL. O valor deste campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular ^[a-zA-Z0-9._-,]+$:
getSerial() (em inglês) PRECISA (ser ou devolver) um número de série do hardware, que PRECISA estar disponível. e exclusivos entre dispositivos com o mesmo MODEL e MANUFACTURER. O valor de este 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 comuns de aplicativos

As intents do Android permitem que os componentes do aplicativo solicitem a funcionalidade outros componentes do Android. O projeto upstream do Android inclui uma lista de aplicativos que implementam diversos padrões de intent para realizar ações comuns.

Implementações de dispositivos:

  • [C-SR-1] É FORTEMENTE RECOMENDADO para pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents, para todos os filtros de intents públicos padrões definidos pelas seguintes intents de aplicativo listadas aqui e fornecer o cumprimento, ou seja, atender às expectativas dos desenvolvedores em relação a esses intents de aplicativos, conforme descrito no SDK.

Consulte a Seção 2 para intents de aplicativos obrigatórias para cada tipo de dispositivo.

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 cada padrão de intent referenciado na seção 3.2.3.1, exceto para Configurações, para serem substituídas por aplicativos de terceiros. A 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 sistema aplicativos uso desses padrões de intent ou impedem que aplicativos de terceiros da vinculação e assumindo o controle desses padrões. Essa proibição inclui especificamente, mas não se limita a, desativar o "Seletor" usuário que permite que o usuário selecione entre vários aplicativos que todos para processar o mesmo padrão de intent.

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

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

O Android também inclui um mecanismo para que aplicativos de terceiros declarem uma comportamento de vinculação de apps padrão autoritativo para determinados tipos de intents de URI da Web. Quando essas declarações oficiais são definido nos padrões de filtro de intent de um app, as implementações de dispositivos:

  • [C-0-4] PRECISA tentar validar qualquer filtro de intent executando a etapas de validação definidas na especificação Digital Asset Links conforme implementado pelo Package Manager no Android Open Source upstream Projeto.
  • [C-0-5] PRECISA tentar a validação dos filtros de intents durante a instalação do o aplicativo e definir todos os filtros de intent de URI validados como gerenciadores de apps padrão para os URIs.
  • PODE definir filtros de intent de URI específicos como gerenciadores de aplicativo padrão para seus URIs, se eles forem verificados, mas outros filtros de URI candidatos falharem verificação. Se uma implementação de dispositivo fizer isso, ela PRECISA fornecer o as substituições apropriadas por padrão de URI no menu de configurações.
  • PRECISA fornecer ao usuário controles de links do app por app nas "Configurações" como da seguinte forma:
    • [C-0-6] O usuário PRECISA conseguir fazer a substituição completa do app padrão comportamento de links para um app ser: sempre abrir, sempre perguntar ou nunca abrir, que precisa se aplicar a todos os filtros de intent de URI candidatos igualmente.
    • [C-0-7] O usuário PRECISA ver uma lista de intents de URI candidatas. filtros.
    • A implementação do dispositivo PODE fornecer ao usuário a capacidade de substituir filtros de intent de URI candidatos específicos que foram verificados por filtro de intent.
    • [C-0-8] A implementação do dispositivo PRECISA oferecer aos usuários a capacidade de ver e substituir filtros de intent de URI candidatos específicos se o dispositivo permite que alguns filtros de intent de URI candidatos funcionem verificação, enquanto outras podem falhar.
3.2.3.3. Namespaces de intents
  • [C-0-1] As implementações de dispositivos NÃO PODEM incluir componentes Android que respeita qualquer novo intent ou padrão de intent de transmissão usando um objeto ACTION, CATEGORY ou outra string de chave no namespace android.* ou com.android.*.
  • [C-0-2] Implementadores de dispositivos NÃO PODEM incluir componentes Android que respeitar novos padrões de intent de transmissão ou de intent usando uma expressão ACTION, CATEGORY ou ou outra string de chave em um espaço de pacote pertencente a outra organização.
  • [C-0-3] Os implementadores de dispositivos NÃO PODEM alterar nem estender nenhuma intent listados na seção 3.2.3.1.
  • As implementações de dispositivos PODEM incluir padrões de intent usando namespaces claramente e, obviamente, associadas às próprias organizações. Essa proibição é análoga à especificada para classes da linguagem Java na seção 3.6.
3.2.3.4. Intents de transmissão

Aplicativos de terceiros dependem da plataforma para transmitir certas intents a notificá-los sobre alterações no ambiente de hardware ou software.

Implementações de dispositivos:

  • [C-0-1] PRECISA transmitir as intents de transmissão públicas listadas aqui. em resposta aos eventos apropriados do sistema, conforme descrito na documentação do SDK. Observe que esse requisito não está em conflito com a seção 3.5, porque limitações para aplicativos de segundo plano também estão descritas no SDK na documentação do Google Cloud. Além disso, certas intents de transmissão são condicionais ao hardware se o dispositivo for compatível com o hardware necessário, eles DEVEM transmitir a e fornecem o comportamento inline com a documentação do SDK.
3.2.3.5. Intents de aplicativos condicionais

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

Quando fizer sentido, as implementações de dispositivos PRECISAM fornecer configurações semelhantes. e ser compatível com o padrão de filtro de intent e os métodos da API descritos na documentação do SDK, conforme mostrado abaixo.

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

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

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

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

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

Se as implementações de dispositivos forem compatíveis com o recurso "Não perturbe", elas:

  • [C-6-1] PRECISA 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 pode conceder ou negar o acesso do app às configurações da política de Não perturbe.

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

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

  • [C-8-1] PRECISA respeitar o android.settings.ACCESSIBILITY_SETTINGS. de fornecer um mecanismo acessível ao usuário para ativar e desativar a serviços de acessibilidade de terceiros junto com os serviços serviços.

Caso as implementações do dispositivo incluam suporte ao Wi-Fi Easy Connect e exponham a a aplicativos de terceiros, elas:

Se as implementações de dispositivos oferecerem o modo de economia de dados, elas:

Se as implementações de dispositivos não oferecerem o modo de economia de dados, elas:

Se as implementações de dispositivos declararem suporte à câmera usando o android.hardware.camera.any, eles:

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

Se as implementações de dispositivos declararem o android.software.autofill sinalização de recurso, elas:

Se as implementações de dispositivos incluem um app pré-instalado ou querem permitir a apps de terceiros para acessar as estatísticas de uso, eles:

  • [C-SR-2] são FORTEMENTE RECOMENDADOS fornecer um mecanismo acessível ao usuário para conceder ou revogar o acesso às estatísticas de uso em resposta aos android.settings.ACTION_USAGE_ACCESS_CONFIG para apps que declaram a android.permission.PACKAGE_USAGE_STATS permissão.

Se as implementações de dispositivos tiverem a intenção de proibir qualquer app, incluindo apps acessando as estatísticas de uso, eles:

  • [C-15-1] PRECISA ter uma atividade que gerencie android.settings.ACTION_USAGE_ACCESS_CONFIG de intenção padrão, mas PRECISA implementá-lo como ambiente autônomo, ou seja, ter um padrão do usuário, como quando o acesso dele é recusado.

Se as implementações do dispositivo mostrarem links para as atividades especificadas pelo AutofillService_passwordsActivity (link em inglês) em "Configurações" ou links para senhas de usuário por um mecanismo semelhante:

  • [C-16-1] PRECISA exibir esses links em todos os serviços de preenchimento automático instalados.

Se as implementações de dispositivos oferecem suporte à VoiceInteractionService e têm mais de um aplicativo que usa essa API instalada de cada vez, eles:

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

  • [C-SR-3] É FORTEMENTE RECOMENDADO para respeitar android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA e As intents android.speech.tts.engine.GET_SAMPLE_TEXT têm uma atividade para fornecer o fulfillment para essas intents, conforme descrito no SDK.

O Android inclui suporte para protetores de tela interativos, anteriormente chamados como 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 ancorado em uma base de mesa; Implementações dos dispositivos:

  • DEVE incluir suporte para protetores de tela e fornecer uma opção de configuração para que os usuários configurem protetores de tela em resposta à android.settings.DREAM_SETTINGS.

Se as implementações de dispositivos informarem android.hardware.nfc.uicc ou android.hardware.nfc.ese, eles:

3.2.4. Atividades em telas secundárias/múltiplas

Se as implementações de dispositivos permitem iniciar atividades normais do Android em mais de uma tela, eles:

  • [C-1-1] PRECISA definir o android.software.activities_on_secondary_displays. flag de recurso.
  • [C-1-2] PRECISA garantir a compatibilidade das APIs, semelhante a uma atividade em execução no na tela principal.
  • [C-1-3] PRECISA colocar a nova atividade na mesma tela que a atividade que iniciou-o, quando a nova atividade é iniciada sem especificar um exibir usando ActivityOptions.setLaunchDisplayId() API.
  • [C-1-4] PRECISA destruir todas as atividades quando uma tela com o Display.FLAG_PRIVATE é removida.
  • [C-1-5] PRECISA ocultar o conteúdo com segurança em todas as telas quando o dispositivo estiver bloqueado com uma tela de bloqueio segura, a menos que o app permita aparecer sobre a tela de bloqueio tela usando Activity#setShowWhenLocked() API.
  • DEVE ter android.content.res.Configuration que corresponde a essa tela para ser exibida, operar corretamente e manter a compatibilidade se uma atividade for iniciada tela secundária.

Se as implementações de dispositivos permitem iniciar atividades normais do Android em dispositivos secundários. e uma tela secundária tem a propriedade android.view.Display.FLAG_PRIVATE. sinalização:

  • [C-3-1] Somente o proprietário da tela, do sistema e das atividades nessa tela PRECISA ser capaz de iniciar. Todos podem lançar uma tela com android.view.Display.FLAG_PUBLIC; .

3.3. Compatibilidade com API nativa

A compatibilidade do código nativo é desafiadora. Por isso, implementadores de dispositivos são:

  • [C-SR-1] É MUITO RECOMENDADO usar as implementações das bibliotecas listado abaixo do projeto upstream do Android Open Source Project.

3.3.1. Interfaces binárias do aplicativo

O bytecode gerenciado do Dalvik pode chamar o código nativo fornecido no aplicativo Arquivo .apk como um arquivo .so ELF compilado para o hardware do dispositivo apropriado. do Terraform. Como o código nativo é muito dependente do processador, tecnologia, o Android define diversas interfaces binárias de aplicativo (ABIs) em o Android NDK.

Implementações de dispositivos:

  • [C-0-1] PRECISA ser compatível com uma ou mais ABIs do Android NDK definidas.
  • [C-0-2] PRECISA incluir suporte para código em execução no ambiente gerenciado para para código nativo, usando a Java Native Interface (JNI) semântica.
  • [C-0-3] PRECISA ser compatível com a fonte (ou seja, com o cabeçalho) e compatível com binário (para ABI) com cada biblioteca necessária na lista a seguir.
  • [C-0-5] PRECISA informar com precisão a interface binária do aplicativo nativa (ABI) compatível com o dispositivo, pela android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS e Parâmetros android.os.Build.SUPPORTED_64_BIT_ABIS, separados por vírgula lista de ABIs ordenadas da mais para a menos preferida.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [C-0-6] PRECISA informar, usando os parâmetros acima, um subconjunto dos seguintes lista de ABIs e NÃO PODEM informar nenhuma ABI que não esteja na lista.

Encerrar novos requisitos

  • [C-0-7] PRECISA criar todas as bibliotecas a seguir, fornecendo APIs nativas, disponíveis para apps que incluem código nativo:

    • libaaudio.so (suporte a áudio nativo AAudio)
    • libamidi.so (suporte a MIDI nativo, se o recurso android.software.midi é reivindicado conforme descrito na Seção 5.9)
    • libandroid.so (suporte a atividades nativas do Android)
    • libc (biblioteca C)
    • libcamera2ndk.so
    • libdl (vinculador dinâmico)
    • libEGL.so (gerenciamento de superfície nativo do OpenGL)
    • libGLESv1_CM.so (OpenGL ES 1.x)
    • libGLESv2.so (OpenGL ES 2.0)
    • libGLESv3.so (OpenGL ES 3.x)
    • libicui18n.so (link em inglês)
    • libicuuc.so
    • libjnigraphics.so (libjnigraphics.so)
    • liblog (geração de registros do Android)
    • libmediandk.so (suporte a APIs de mídia nativa)
    • libm (biblioteca matemática)
    • libneuralnetworks.so (API Neural Networks)
    • libOpenMAXAL.so (suporte a OpenMAX AL 1.0.1)
    • libOpenSLES.so (suporte a áudio do OpenSL ES 1.0.1)
    • libRS.so (em inglês)
    • libstdc++ (suporte mínimo para C++)
    • libvulkan.so (Vulkan)
    • libz (compactação Zlib)
    • Interface JNI
  • [C-0-8] NÃO PODE adicionar ou remover as funções públicas para as bibliotecas nativas listados acima.

  • [C-0-9] É NECESSÁRIO listar outras bibliotecas não AOSP expostas diretamente a apps de terceiros no /vendor/etc/public.libraries.txt.

  • [C-0-10] NÃO PODE expor outras bibliotecas nativas, implementadas e fornecidos no AOSP como bibliotecas do sistema para apps de terceiros que segmentam a API nível 24 ou superior, conforme forem reservados.

  • [C-0-11] PRECISA exportar todo o OpenGL ES 3.1 e o Pacote de extensões do Android (link em inglês) símbolos de função, conforme definido no NDK, usando a biblioteca libGLESv3.so. Embora todos os símbolos PRECISAM estar presentes, a seção 7.1.4.1 descreve em mais detalhes os requisitos de quando a implementação completa de cada as funções correspondentes são esperadas.

  • [C-0-12] É NECESSÁRIO exportar os símbolos de função do núcleo Função Vulkan 1.1 bem como os símbolos VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 e VK_KHR_get_physical_device_properties2 extensões por meio do biblioteca libvulkan.so. Embora todos os símbolos PRECISAM estar presentes, seção 7.1.4.2 descreve com mais detalhes os requisitos de quando implementação de cada função correspondente são esperadas.

  • DEVE ser construído usando o código-fonte e arquivos de cabeçalho disponíveis no o Android Open Source Project upstream.

Versões futuras do Android podem apresentar suporte a mais ABIs do Google Cloud.

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

Se as implementações de dispositivos informarem compatibilidade com a ABI armeabi, elas:

  • [C-3-1] também PRECISA oferecer suporte a armeabi-v7a e informar esse suporte, conforme O armeabi serve apenas para compatibilidade com versões anteriores de apps mais antigos.

Se as implementações de dispositivos informarem compatibilidade com a ABI armeabi-v7a, para apps usando essa ABI, eles:

  • [C-2-1] PRECISA incluir as seguintes linhas em /proc/cpuinfo e NÃO DEVE alteram os valores no mesmo dispositivo, mesmo quando são lidos por outras ABIs.

    • Features:, seguido por uma lista de todos os recursos opcionais da CPU ARMv7. suportado pelo dispositivo.
    • CPU architecture:, seguido por um número inteiro que descreve o dispositivo arquitetura ARM com suporte mais alto (por exemplo, "8" para dispositivos ARMv8).
  • [C-2-2] PRECISA sempre manter as seguintes operações disponíveis, mesmo caso em que a ABI é implementada em uma arquitetura ARMv8, seja por meio de suporte nativo de CPU ou emulação de software:

    • Instruções do SWP e do SWPB.
    • CP15ISB, CP15DSB e CP15DMB
  • [C-2-3] PRECISA incluir suporte para o SIMD avançado. (conhecido como NEON).

3,4 Compatibilidade com a Web

3.4.1. Compatibilidade com WebView

Se as implementações de dispositivos fornecerem uma implementação completa do API android.webkit.Webview, eles:

  • [C-1-1] PRECISA informar android.software.webview.
  • [C-1-2] PRECISA usar o build do projeto Chromium. do Android Open Source Project upstream no Android 15 ramificação para a implementação da android.webkit.WebView API.
  • [C-1-3] A string do user agent informada pelo WebView PRECISA estar neste formato:

    Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, como Gecko) Versão/4.0 $(CHROMIUM_VER) Celular Safari/537.36

    • O valor da string $(VERSION) PRECISA ser igual ao valor de android.os.Build.VERSION.RELEASE para
    • A string $(MODEL) PODE estar vazia, mas se não estiver vazia, PRECISA ter o mesmo valor que android.os.Build.MODEL.
    • "Versão/$(BUILD)" PODE ser omitido, mas se estiver presente, $(BUILD) string PRECISA ser igual ao valor de android.os.Build.ID.
    • O valor da string $(CHROMIUM_VER) PRECISA ser a versão do Chromium. no Android Open Source Project.
    • As implementações de dispositivos podem omitir dispositivos móveis na string do user agent.
  • O componente WebView DEVE incluir suporte para o máximo possível de recursos HTML5 possível e, se for compatível com o recurso, DEVE estar em conformidade com especificação HTML5.

  • [C-1-4] PRECISA renderizar o conteúdo fornecido ou o conteúdo do URL remoto em um processo. diferente do aplicativo que instancia a WebView. Especificamente o processo separado do renderizador PRECISA conter privilégios menores, executar como um ID de usuário separado, não têm acesso ao diretório de dados do aplicativo, não têm acesso direto à rede e só têm acesso ao mínimo serviços do sistema pelo Binder. A implementação do WebView do AOSP atende esse requisito.

Se as implementações do dispositivo forem de 32 bits ou declararem a flag de recurso android.hardware.ram.low, eles estão isentos de C-1-3.

3.4.2. Compatibilidade de navegadores

Se as implementações de dispositivos incluem um aplicativo de navegador autônomo para fins gerais a navegação na Web, eles:

  • [C-1-1] PRECISA oferecer suporte a cada uma dessas APIs associadas HTML5:
  • [C-1-2] PRECISA ser compatível com HTML5/W3C. webstorage API e DEVE oferecer suporte às APIs HTML5/W3C API IndexedDB. Observe que, como o servidor órgãos de padronização de desenvolvimento estão em transição para favorecer o IndexedDB webstorage, o IndexedDB deve se tornar um componente obrigatório em versão futura do Android.
  • PODE enviar uma string do user agent personalizado no aplicativo Navegador autônomo.
  • DEVE implementar suporte para o máximo o HTML5 possível no Aplicativo de navegador (seja baseado no navegador WebKit upstream ou um substituto de terceiros).

No entanto, se as implementações de dispositivos não incluírem um navegador autônomo, do aplicativo, eles:

  • [C-2-1] ainda PRECISA oferecer suporte aos padrões de intenção pública, conforme descrito em seção 3.2.3.1.

3,5 Compatibilidade comportamental de API

Implementações de dispositivos:

  • [C-0-9] PRECISA garantir que a compatibilidade comportamental da API seja aplicada a todos apps instalados, a menos que eles sejam restritos conforme descrito em Seção 3.5.1.
  • [C-0-10] NÃO PODE implementar a abordagem de lista de permissões que garante que a API compatibilidade comportamental somente para apps selecionados pelo dispositivo de implementação.

O comportamento de cada tipo de API (gerenciada, flexível, nativa e na Web) precisa ser consistente com a implementação preferencial do modelo Android Open Source Project. Algumas áreas específicas de compatibilidade são:

  • [C-0-1] Os dispositivos NÃO PODEM mudar o comportamento ou a semântica de um intent padrão.
  • [C-0-2] Os dispositivos NÃO PODEM mudar 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 a aplicativos em segundo plano. Mais especificamente, para aplicativos em segundo plano:
    • [C-0-4] eles PRECISAM parar de executar callbacks registrados pelo receba saídas do GnssMeasurement e GnssNavigationMessage.
    • [C-0-5] Ele PRECISA limitar a frequência das atualizações fornecidas ao app por meio do LocationManager a classe da API ou a WifiManager.startScan() .
    • [C-0-6] Se o app for direcionado ao nível 25 da API ou mais recente, ele NÃO PODERÁ SER permitem registrar receptores de transmissão para as transmissões implícitas de intents padrão do Android no manifesto do app, a menos que a transmissão requer uma "signature" ou "signatureOrSystem" protectionLevel permissão ou estão na lista de isenções.
    • [C-0-7] Se o app for direcionado ao nível 25 da API ou mais recente, ele PRECISA ser interrompido. os serviços em segundo plano do app, como se ele tivesse chamado o serviços stopSelf() a menos que o app seja colocado em uma lista de permissões temporária para processar um que fica 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 libera os wakelocks que o app retém.
  • [C-0-11] Os dispositivos PRECISAM retornar os seguintes provedores de segurança como os primeiros sete valores de matriz do Security.getProviders() , na ordem indicada e com os nomes informados (conforme retornado pelo Provider.getName()). e classes, a menos que o app tenha modificado a lista por insertProviderAt() ou removeProvider(). Dispositivos PODE retornar provedores adicionais depois da lista especificada de provedores a seguir.
    1. AndroidNSSP: android.security.net.config.NetworkSecurityConfigProvider
    2. AndroidOpenSSL: com.android.org.conscrypt.OpenSSLProvider
    3. CertPathProvider: sun.security.provider.CertPathProvider
    4. Alternativa AndroidKeyStoreBC: android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
    5. BCcom.android.org.bouncycastle.jce.provider.BouncyCastleProvider
    6. HarmonyJSSE: com.android.org.conscrypt.JSSEProvider
    7. AndroidKeyStore: android.security.keystore.AndroidKeyStoreProvider

A lista acima não está completa. Os testes do conjunto de teste de compatibilidade (CTS) 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 isso, os implementadores de dispositivos DEVE usar o código-fonte disponível pelo Android Open Source Project, quando possível, em vez de reimplementar partes significativas do sistema.

3.5.1. Restrição de aplicativo

Se as implementações de dispositivos implementam um mecanismo reservado para restringir apps (por exemplo, mudar ou restringir comportamentos de APIs descritos no SDK) e se esse mecanismo for mais restritivo que o bucket restrito do App em espera, eles:

  • [C-1-1] PRECISA permitir que o usuário confira a lista de apps restritos.
  • [C-1-2] PRECISA oferecer recursos ao usuário para ativar / desativar todos esses recursos. restrições de propriedade a cada app.
  • [C-1-3] PRECISA não aplicar automaticamente essas restrições proprietárias sem evidências de mau comportamento de saúde do sistema, mas PODEM aplicar restrições nos apps após a detecção de mau comportamento de saúde do sistema, como wakelocks travados, serviços e outros critérios. Os critérios podem ser determinados pelo dispositivo. implementadores, mas PRECISA estar relacionado ao impacto do app na integridade do sistema. Outra opção que não são puramente relacionados à integridade do sistema, como falta de popularidade no mercado, NÃO PODE ser usada como critério.

  • [C-1-4] Não PRECISA aplicar automaticamente essas restrições de propriedade a apps. quando um usuário tiver desativado as restrições de apps manualmente e PODE sugerir que o usuário para aplicar essas restrições de propriedade.

  • [C-1-5] PRECISA informar os usuários se essas restrições proprietárias forem aplicadas a um app automaticamente. Essas informações DEVEM ser fornecidas no período de 24 horas anteriores à aplicação dessas restrições de propriedade.

  • [C-1-6] PRECISA retornar "true" para ActivityManager.isBackgroundRestricted(). para qualquer chamada de API de um app.

  • [C-1-7] NÃO PODE restringir o app em primeiro plano que é explicitamente usado por o usuário.

  • [C-1-8] PRECISA suspender essas restrições reservadas nos apps sempre que um o usuário começa a usar o app explicitamente, tornando-o o primeiro plano para o aplicativo.

  • [C-1-10] PRECISA fornecer um documento ou site público e claro que descreva como as restrições de propriedade são aplicadas. Este documento ou site PRECISA ser pode ser vinculado aos documentos do SDK do Android e PRECISA incluir:

    • Condições de acionamento de restrições reservadas.
    • O que e como um app pode ser restrito.
    • Como um app pode ser isento dessas restrições.
    • Como um app pode solicitar isenção de restrições reservadas, se oferecer suporte a essa isenção para apps que o usuário pode instalar.

Se um app estiver pré-instalado no dispositivo e nunca tiver sido usado explicitamente por um usuário por mais de 30 dias, [C-1-3] [C-1-5] são isentos.

Se as implementações do dispositivo estenderem as restrições do app implementadas no AOSP:

  • [C-2-1]PRECISA seguir a implementação descrita neste documento.

3.5.2. Hibernação do aplicativo

Se as implementações do dispositivo incluem a hibernação do app incluída no AOSP ou estender o recurso incluído no AOSP, eles:

  • [C-1-1] PRECISA atender a todos os requisitos da seção 3.5.1, exceto: [C-1-6] e [C-1-3].
  • [C-1-2] Só é preciso aplicar a restrição no app para um usuário quando há evidências de que o usuário não usa o app há algum tempo. Isso é FORTEMENTE RECOMENDADO que seja de um mês ou mais. O uso PRECISA ser definida pela interação explícita do usuário pelo UsageStats#getLastTimeVisible() API ou qualquer item que faça com que um app saia do estado de fechamento forçado, incluindo vinculações de serviço, de provedor de conteúdo, transmissões explícitas etc., que será acompanhado por uma nova API UsageStats#getLastTimeAnyComponentUsed().
  • [C-1-3] É PRECISO aplicar restrições que afetam todos os usuários de dispositivos quando há é uma evidência de que o pacote não foi usado por QUALQUER usuário por algum período de tempo de resposta. É RECOMENDADO que a duração seja de um mês ou mais.
  • [C-1-4] NÃO PODE deixar o app incapaz de responder a intents de atividade, vinculações de serviço, solicitações de provedor de conteúdo ou transmissões explícitas.

A hibernação do app no AOSP atende aos requisitos acima.

3,6 Namespaces da API

O Android segue as convenções de namespace de pacote e classe definidas pela de programação centrada no usuário. Para garantir a compatibilidade com aplicativos de terceiros, os implementadores de dispositivos NÃO PODEM fazer nenhuma modificação proibida (veja abaixo) em esses namespaces de pacote:

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

Ou seja, eles:

  • [C-0-1] NÃO PODE modificar as APIs expostas publicamente na plataforma Android mudando qualquer método ou assinatura de classe, ou removendo classes ou campos.
  • [C-0-2] NÃO PODE adicionar elementos expostos publicamente (como classes ou interfaces, campos ou métodos para classes ou interfaces existentes) ou testar ou APIs do sistema às APIs nos namespaces acima. Um anúncio "publicamente exposto elemento" é qualquer construção que não esteja decorada com a palavra-chave "@hide". marcador como usada no código-fonte upstream do Android.

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 na linguagem Java do as APIs expostas publicamente.
  • [C-0-4] NÃO PODE ser anunciado nem exposto a desenvolvedores.

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

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

Os implementadores de dispositivos podem adicionar APIs personalizadas em idiomas nativos, fora do NDK Mas as APIs personalizadas:

  • [C-1-1] NÃO PODE estar em uma biblioteca do NDK ou de propriedade de outra pessoa da sua organização, conforme descrito aqui.

Se um implementador de dispositivos propuser a melhoria de um dos namespaces de pacote acima Por exemplo, adicionando uma nova funcionalidade útil a uma API existente API), o implementador DEVIA acessar source.android.com. e iniciar o processo de contribuição de mudanças e de acordo com as informações do site.

Observe que as restrições acima correspondem às convenções padrão de nomenclatura APIs na linguagem de programação Java; seção tem como objetivo reforçar e torná-las vinculativas por meio da inclusão nesta Compatibilidade Definição.

3,7 Compatibilidade de ambiente de execução

Implementações de dispositivos:

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

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

  • DEVE usar o Android RunTime (ART), a referência upstream implementação do Dalvik Executable Format e a referência no sistema de gerenciamento de pacotes da implementação.

  • Realize testes de fuzz em vários modos de execução e as arquiteturas de destino para garantir a estabilidade do ambiente de execução. Consulte JFuzz (link em inglês) 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
140 dpi (140dpi)
160 dpi (mdpi)
180 dpi (180dpi)
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi) 36MB
240 dpi (hdpi)
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
140 dpi (140dpi)
160 dpi (mdpi)
180 dpi (180dpi) 48MB
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi)
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
140 dpi (140dpi) 48MB
160 dpi (mdpi)
180 dpi (180dpi) 80MB
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi)
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
140 dpi (140dpi) 80MB
160 dpi (mdpi)
180 dpi (180dpi) 96MB
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi)
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 de início (tela inicial)

O Android inclui um aplicativo de inicialização (tela inicial) e suporte para aplicativos de terceiros para substituir o inicializador do dispositivo (tela inicial).

Se as implementações de dispositivos permitirem que aplicativos de terceiros substituam o dispositivo tela inicial, eles:

  • [C-1-1] PRECISA declarar o recurso da plataforma android.software.home_screen.
  • [C-1-2] PRECISA retornar AdaptiveIconDrawable. quando o aplicativo de terceiros usa a tag <adaptive-icon> para fornecer o ícone e o PackageManager para recuperar ícones são chamados.

Se as implementações do dispositivo incluem uma tela de início padrão compatível com aplicativos fixação de atalhos, eles:

Por outro lado, se as implementações de dispositivos não oferecerem suporte à fixação no aplicativo de atalhos, eles:

Se as implementações de dispositivos implementam uma tela de início padrão que fornece acesso a atalhos adicionais fornecidos por aplicativos de terceiros através do Atalhos do Gerenciador API, eles:

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

Se as implementações do dispositivo incluem um app de tela de início padrão que mostra selos para os ícones do app, eles:

  • [C-5-1] PRECISA respeitar os NotificationChannel.setShowBadge(). Método de API. Em outras palavras, mostre uma affordance visual associada ao ícone do app se o valor definido como true e não mostra nenhum esquema de selos de ícones do app quando todos dos canais de notificação do app definiram o valor como false.
  • PODE substituir os selos de ícones do app pelo esquema de selos reservado quando os aplicativos de terceiros são compatíveis com o esquema de selos reservado com o uso de APIs proprietárias, mas DEVE usar os recursos e valores fornecidos pelas APIs de selos de notificação descritas no SDK, como o Notification.Builder.setNumber() e o Notification.Builder.setBadgeIconType() API.

Se as implementações de dispositivos forem compatíveis monocromático , estes ícones:

  • [C-6-1] PRECISA ser usada apenas quando o usuário ativar esse recurso explicitamente (por exemplo, via menu do seletor de configurações ou plano de fundo).

3.8.2. Widgets

O Android oferece suporte a widgets de apps de terceiros definindo um tipo de componente e API e ciclo de vida correspondentes que permite que os aplicativos exponham uma "AppWidget" para o usuário final.

Se as implementações de dispositivos forem compatíveis com widgets de apps de terceiros, elas:

  • [C-1-1] PRECISA declarar suporte ao recurso da plataforma android.software.app_widgets:
  • [C-1-2] PRECISA incluir suporte integrado para AppWidgets e expor funcionalidades da interface do usuário para adicionar, configurar, exibir e remover AppWidgets
  • [C-1-3] PRECISA renderizar widgets de tamanho 4 x 4. no tamanho padrão da grade. Veja as Diretrizes de design para widgets de apps na documentação do SDK do Android para mais detalhes.
  • PODE oferecer suporte a widgets de aplicativos na tela de bloqueio.

Se as implementações de dispositivos forem compatíveis com widgets de apps de terceiros e itens no app fixação de atalhos, eles:

3.8.3. Notificações

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

3.8.3.1. Apresentação de notificações

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

  • [C-1-1] PRECISA ser compatível com notificações que usam recursos de hardware, conforme descrito em na documentação do SDK e, na medida do possível, com a implementação do dispositivo ao hardware. Por exemplo, se uma implementação de dispositivo inclui uma vibração, ela PRECISA implementar corretamente as APIs de vibração. Se a implementação de um dispositivo não tiver as APIs correspondentes PRECISAM ser implementadas como ambiente autônomo. Esse comportamento é detalhado na seção 7.
  • [C-1-2] PRECISA renderizar corretamente todos os recursos. (ícones, arquivos de animação etc.) fornecidos nas APIs ou na Guia de estilo de ícone da barra de status/sistema, embora possam oferecer uma experiência alternativa ao usuário para notificações do que o fornecido pela implementação de referência do Android Open Source.
  • [C-1-3] PRECISA respeitar e implementar corretamente os comportamentos descritos as APIs para atualizar, remover e agrupar notificações.
  • [C-1-4] PRECISA fornecer o comportamento completo do NotificationChannel. A API é documentada no SDK.
  • [C-1-5] PRECISA fornecer uma funcionalidade do usuário para bloquear e modificar uma determinada notificações de apps de terceiros por canal e pacote de app.
  • [C-1-6] Também PRECISA fornecer uma funcionalidade de usuário para exibir notificações excluídas. canais.
  • [C-1-7] PRECISA renderizar corretamente todos os recursos (imagens, adesivos, ícones etc.) fornecido por Notification.MessagingStyle. ao lado do texto da notificação sem precisar de interação adicional do usuário. Para exemplo, PRECISA mostrar todos os recursos, incluindo os ícones fornecidos por android.app.Person (link em inglês) em uma conversa em grupo definida pelo setGroupConversation.

  • [C-SR-1] É FORTEMENTE RECOMENDADO fornecer uma affordance para o usuário controlar as notificações que são expostas a apps que receberam a permissão Permissão do listener de notificações. A granularidade PRECISA ser de modo que o usuário possa controlar quais tipos de notificação são selecionados para cada listener interligados a esse ouvinte. Os tipos PRECISAM incluir "conversas", "alertas", "silencioso" e "importante em andamento" notificações.

  • [C-SR-2] São FORTEMENTE RECOMENDADOS fornecem uma affordance para os usuários especificarem a serem excluídos da notificação de um listener de notificações específico.

  • [C-SR-3] É FORTEMENTE RECOMENDADO para mostrar automaticamente uma funcionalidade do usuário para bloquear notificações de apps de terceiros em cada canal e app no nível do pacote depois que o usuário dispensa essa notificação várias vezes.

  • DEVE ser compatível com notificações avançadas.

  • DEVE apresentar algumas notificações de prioridade mais alta como notificações de alerta.

  • DEVE ter um recurso do usuário para adiar notificações.

  • PODE gerenciar apenas a visibilidade e o momento em que os apps de terceiros podem notificar usuários de eventos importantes para reduzir problemas de segurança, como distração do motorista.

O Android 11 introduz o suporte a notificações de conversa, que são notificações que usam MessagingStyle e fornece um ID de atalho para Pessoas publicado.

Implementações de dispositivos:

  • [C-SR-4] É FORTEMENTE RECOMENDADO para agrupar e mostrar conversation notifications antes de notificações não relacionadas a conversas, com exceção de notificações de serviços em primeiro plano em andamento e importance:high notificações.

Se as implementações de dispositivos oferecem suporte a conversation notifications e o app fornece os dados necessários para bubbles, eles:

  • [C-SR-5] É MUITO RECOMENDADO mostrar esta conversa como um balão. A implementação do AOSP atende a esses requisitos com a interface padrão do sistema. Configurações e acesso rápido.

Se as implementações de dispositivos forem compatíveis com notificações avançadas, elas:

  • [C-2-1] PRECISA usar os recursos exatos que fornecido pelo Notification.Style Classe de API e subclasses para os elementos de recurso apresentados.
  • DEVE apresentar todos os elementos do recurso (por exemplo, ícone, título e texto do resumo) definidos no Notification.Style A classe da API e as subclasses dela.

As notificações de alerta são apresentadas ao usuário à medida que chegam, independentemente da superfície em que Se as implementações de dispositivos forem compatíveis com avisos notificações, eles podem fazer o seguinte:

  • [C-3-1] PRECISA usar a visualização e os recursos das notificações de informações básicas conforme descrito nos Notification.Builder Classe da API quando as notificações de alerta são apresentadas.
  • [C-3-2] PRECISA exibir as ações fornecidas pelo Notification.Builder.addAction() com o conteúdo da notificação sem interação adicional do usuário conforme descrito no SDK.
3.8.3.2. Serviço de listener de notificações

O Android inclui NotificationListenerService. APIs que permitem que os aplicativos (uma vez ativados explicitamente pelo usuário) recebam uma cópia dos todas as notificações à medida que são postadas ou atualizadas.

Implementações de dispositivos:

  • [C-0-1] PRECISA atualizar todas as notificações de forma correta e imediata a todos os serviços de listener instalados e ativados pelo usuário, incluindo todos os serviços todos os metadados anexados ao objeto de notificação.
  • [C-0-2] PRECISA respeitar os snoozeNotification(). chamada de API, dispensar a notificação e fazer um callback após o adiamento que é definida na chamada de API.

Se as implementações de dispositivos tiverem uma funcionalidade de usuário para adiar notificações, elas:

  • [C-1-1] PRECISA refletir o status de notificações adiadas corretamente por meio das APIs padrão, como NotificationListenerService.getSnoozedNotifications()
  • [C-1-2] PRECISA disponibilizar essa funcionalidade do usuário para adiar notificações. de cada app de terceiros instalado, a menos que sejam de persistentes/em primeiro plano.
3.8.3.3. Não perturbe (Não perturbe) / Modo de prioridade

Se as implementações de dispositivos forem compatíveis com o recurso Não perturbe (também chamado de modo de prioridade), eles:

  • [C-1-1] PRECISA, para quando a implementação do dispositivo fornece um meio para o usuário para dar ou negar o acesso de apps de terceiros à configuração da política de Não perturbe exibir Regras automáticas de NP criados pelos aplicativos junto com as regras predefinidas e criadas pelo usuário.
  • [C-1-3] PRECISA respeitar o suppressedVisualEffects. transmitidos pela classe NotificationManager.Policy e se um app tiver configurado uma das opções BIGPRESSED_EF_SCREEN_ON, ele DEVE indicar ao usuário que o os efeitos visuais são suprimidos no menu de configurações do modo Não perturbe.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

3.8.3.4. Proteção a Notificação Sensível

Essas informações incluem conteúdo como senhas únicas, de confirmação única e códigos semelhantes de autenticação ou redefinição que podem aparecer notificações aos usuários.

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

  • [C-1-1] PRECISA encobrir informações sensíveis de notificações para que não sejam transmitidas listeners de notificação, a menos que o serviço de listener seja um dos seguintes:

    • Apps assinados pelo sistema com uma uid < 10 mil
    • IU do sistema
    • Concha
    • App de dispositivo complementar designado (definido por CompanionDeviceManager)
    • Papel SYSTEM_AUTOMOTIVE_PROJECTION
    • Papel SYSTEM_NOTIFICATION_INTELLIGENCE
    • Função HOME

A implementação AOSP do NotificationAssistantServices que exemplifique e atenda a esses requisitos. Consulte android.ext.services.notification como exemplo.

Encerrar novos requisitos

3.8.4. APIs Assist

O Android inclui as APIs Assist para permitir que os aplicativos escolham a quantidade de informações do contexto atual compartilhado com o assistente no dispositivo.

Se as implementações de dispositivos forem compatíveis com a ação de assistência, elas:

  • [C-2-1] PRECISA indicar claramente para o usuário final quando o contexto é compartilhado. de uma destas formas:
    • Sempre que o app assistivo acessa o contexto, uma tela branca luz nas bordas da tela que atingem ou excedem a duração e Brilho da implementação do Android Open Source Project.
    • Para o app assistivo pré-instalado, fornecer uma funcionalidade do usuário menos de duas navegações para fora o menu de configurações padrão da entrada de texto por voz e do app Google Assistente, e só compartilha o contexto quando o app assistivo é invocado explicitamente pelo ao usuário por meio de uma hotword ou entrada de tecla de navegação de assistência.
  • [C-2-2] A interação designada para iniciar o app assistivo, conforme descrito. na seção 7.2.3 PRECISA iniciar o cluster ou seja, o app que implementa VoiceInteractionService, ou uma atividade que processa a intent ACTION_ASSIST.

3.8.5. Alertas e avisos

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

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

  • [C-1-1] PRECISA fornecer recursos do usuário para impedir que um app mostre alertas. Janelas que usam o TYPE_APPLICATION_OVERLAY. A implementação do AOSP atende a esse requisito porque tem controles na aba de notificações.

  • [C-1-2] PRECISA respeitar a API Toast e exibir avisos de aplicativos para usuários finais em algumas visível.

3.8.6. Temas

O Android fornece "temas" como um mecanismo para os aplicativos aplicarem estilos em toda uma atividade ou aplicativo.

O Android inclui um "Holo" e "Material" família de temas como um conjunto de estilos definidos que os desenvolvedores de aplicativos usem se quiserem corresponder Aparência do tema Holo conforme definido pelo SDK do Android.

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

  • [C-1-1] NÃO PODE alterar nenhum dos atributos do tema Holo expostos a aplicativos conteinerizados.
  • [C-1-2] PRECISA ser compatível com o "Material" família de temas e NÃO PODEM alterar nenhum dos Atributos de tema do Material Design ou os ativos delas expostos a aplicativos.
  • [C-1-3] PRECISA definir "sans-serif" família de fontes para Roboto versão 2.x para os idiomas que a Roboto suporta ou fornecer uma affordance de usuário para alterar a fonte usada para o "sans-serif" família de fontes para Roboto versão 2.x para as linguagens com suporte da Roboto.

  • [C-1-4] PRECISA gerar paletas de tons de cores dinâmicas conforme especificado no AOSP documentação de Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (consulte android.theme.customization.system_palette e android.theme.customization.theme_style).

  • [C-1-5] PRECISA gerar paletas de tons de cores dinâmicas usando estilos de tema de cores. numerada na Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES documentação (consulte android.theme.customization.theme_styles), ou seja, TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD e MONOCHROMATIC.

    "Cor da origem" usada para gerar paletas de tons de cores dinâmicas quando enviada com android.theme.customization.system_palette (conforme documentado em Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES).

  • [C-1-6] PRECISA ter um valor de chroma CAM16 de 5 ou maior.

    • DEVE ser derivado do plano de fundo via com.android.systemui.monet.ColorScheme#getSeedColors, que fornece múltiplas cores de origem válidas para escolher uma.

    • DEVE usar o valor 0xFF1B6EF3, se nenhuma das cores fornecidas atender o requisito de cor de origem acima.

O Android também inclui um "Padrão do dispositivo" família de temas como um conjunto de estilos definidos que os desenvolvedores de aplicativos podem usar se quiserem combinar com a aparência do device, conforme definido pelo implementador do dispositivo.

O Android oferece suporte a um tema variante com barras de sistema translúcidas, o que permite desenvolvedores de aplicativos para preencher a área atrás da barra de status e navegação com o conteúdo do app. Para que o desenvolvedor tenha uma experiência consistente do navegador, é importante que o estilo do ícone da barra de status seja diferentes implementações de dispositivos.

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

  • [C-2-1] PRECISA usar branco para ícones de status do sistema (como intensidade do sinal e nível de bateria) e as notificações emitidas pelo sistema, a menos que o ícone seja que indicam um status problemático ou um aplicativo solicita uma barra de status clara usando o valor WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS .
  • [C-2-2] Implementações de dispositivos Android PRECISAM mudar a cor do sistema ícones de status para preto (para mais detalhes, consulte R.style) quando um app solicita 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 aplicativos para expor um ou mais "Planos de fundo interativos" para o usuário final. Planos de fundo interativos são animações, padrões ou imagens semelhantes com recursos de entrada limitados que são exibidos como um plano de fundo, atrás de outros aplicativos conteinerizados.

O hardware é considerado capaz de executar planos de fundo interativos de forma confiável se puder ser executado todos os planos de fundo interativos, sem limitações de funcionalidade, com um frame razoável sem efeitos adversos nas outras aplicações. Se as limitações no fazer com que planos de fundo e/ou aplicativos travem, mau funcionamento, consumam excesso de energia da CPU ou da bateria ou execução em frame rates inaceitavelmente baixos, o hardware é considerado incapaz de executar o plano de fundo interativo. Por exemplo, algumas planos de fundo interativos podem usar um contexto OpenGL 2.0 ou 3.x para renderizar seu conteúdo. O plano de fundo interativo não será executado de maneira confiável em hardware não compatível com várias Contextos do OpenGL porque o uso do plano de fundo interativo de um contexto do OpenGL pode entrar em conflito com outros aplicativos que também usam um contexto OpenGL.

  • 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 implementam planos de fundo interativos, elas:

  • [C-1-1] PRECISA 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 as tela de visão geral, interface do usuário de nível de sistema para alternar tarefas e exibir os acessos recentes atividades e tarefas usando uma imagem em miniatura da interface gráfica do aplicativo no momento em que o usuário saiu do aplicativo pela última vez.

Implementações de dispositivos incluindo a tecla de navegação da função Recentes, conforme detalhado em A seção 7.2.3 PODE alterar a interface.

Se as implementações do dispositivo, incluindo a tecla de navegação da função Recentes, conforme detalhado em seção 7.2.3 alterar a interface, eles:

  • [C-1-1] PRECISA oferecer suporte a pelo menos até sete atividades exibidas.
  • DEVE exibir pelo menos o título de quatro atividades por vez.
  • DEVE exibir a cor de destaque, o ícone e o título da tela em "Recentes".
  • DEVE exibir uma affordance de fechamento ("x"), mas PODE postergar 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 alternância rápida entre as duas usadas mais recentemente quando a tecla de função Recentes é tocada duas vezes.
  • DEVE acionar o modo de várias janelas de tela dividida, se compatível, quando o Manter a tecla de funções recentes pressionada.
  • PODE exibir recentes afiliadas como um grupo que é movido em conjunto.
  • [C-SR-1] É FORTEMENTE RECOMENDADO usar o usuário Android upstream (ou uma interface semelhante baseada em miniatura) para a tela de visão geral.

3.8.9. Gerenciamento de entradas

O Android inclui suporte a Gerenciamento de entradas e suporte a editores de método de entrada de terceiros.

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

  • [C-1-1] PRECISA declarar o recurso de plataforma android.software.input_methods e oferecem suporte a APIs do IME, conforme definido na documentação do SDK do Android.

3.8.10. Controle de mídia da tela de bloqueio

A API Remote Control Client foi descontinuada do Android 5.0 e substituída pela Modelo de notificação de mídia que permite que aplicativos de mídia se integrem a controles de mídia que são exibidos na tela de bloqueio.

3.8.11. Protetores de tela (antigo Dreams)

Consulte as configurações na seção 3.2.3.5. de configurar protetores de tela.

3.8.12. Local

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

3.8.13. Unicode e fonte

O Android inclui suporte para os caracteres de emoji definidos em Unicode 10.0 (link em inglês).

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

  • [C-1-1] PRECISA renderizar esses caracteres de emoji em um glifo de cor.
  • [C-1-2] PRECISA incluir suporte para:
    • Fonte Roboto 2 com pesos diferentes — Sans Serif-thin, sans-serif-light, Sans Serif-medium, sans-serif-preto, sans-serif condensado, Sans Serif-condensed light nos idiomas disponíveis no dispositivo.
    • Cobertura completa em Unicode 7.0 para idiomas latinos, gregos e cirílicos, incluindo os Intervalos latinos estendidos A, B, C e D, e todos os glifos na moeda bloco de símbolos do Unicode 7.0.
  • [C-1-3] NÃO PODE remover nem modificar NotoColorEmoji.tff na imagem do sistema. (É aceitável adicionar uma nova fonte de emoji para substituir o emoji em NotoColorEmoji.tff).
  • DEVE oferecer suporte ao tom de pele e aos emojis de família diversos, conforme especificado nos Relatório técnico do Unicode no 51.

Se as implementações de dispositivos incluírem um IME, elas:

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

O Android inclui suporte para renderizar fontes de Mianmar. Mianmar tem várias fontes não compatíveis com Unicode, conhecidas como "Zawgyi", para renderizar Mianmar idiomas.

Se as implementações de dispositivos forem compatíveis com o birmanês, elas:

  • [C-2-1] PRECISA renderizar texto com fonte compatível com Unicode como padrão. uma fonte não compatível com Unicode NÃO PODE ser definida como padrão, a menos que o usuário escolhe no seletor de idioma.
  • [C-2-2] PRECISA ser compatível com uma fonte Unicode e uma fonte não compatível com Unicode se um fonte não compatível com Unicode é compatível com o dispositivo. Não Unicode fonte compatível NÃO PODE remover ou substituir a fonte Unicode.
  • [C-2-3] PRECISA renderizar texto com fonte não compatível com Unicode SOMENTE SE uma código de idioma com código de script Qaag (link em inglês) é especificado (por exemplo, my-Qaag). Nenhum outro código ISO de idioma ou região (seja atribuído, não atribuído ou reservado) pode ser usado para se referir a códigos não Unicode fonte compatível com Mianmar. Os desenvolvedores de apps e os autores de páginas da Web podem especificar my-Qaag como o código de idioma designado, como faria para qualquer outro idioma.

3.8.14. Várias janelas

Se as implementações de dispositivos puderem exibir várias atividades em ao mesmo tempo, eles:

  • [C-1-1] PRECISA implementar esses modos de várias janelas de acordo com a comportamentos de aplicativos e APIs descritos no SDK do Android documentação de suporte do modo de várias janelas e conheça os seguintes requisitos:
  • [C-1-2] PRECISA respeitar android:resizeableActivity. definido por um app no arquivo AndroidManifest.xml, conforme descrito em deste SDK.
  • [C-1-3] NÃO PODE oferecer o modo de tela dividida ou formato livre se a altura da tela é inferior a 440 dp e a largura da tela é inferior a 440 dp.
  • [C-1-4] Uma atividade NÃO PODE ser redimensionada para um tamanho menor que 220 dp em modos de várias janelas diferentes de picture-in-picture.
  • As implementações de dispositivos com tamanho de tela xlarge DEVEM ser compatíveis com formato livre modo

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

  • [C-2-2] PRECISA cortar a atividade na base de uma tela dividida em várias janelas, mas DEVE mostrar algum conteúdo dela se o app de acesso rápido for a janela em foco.
  • [C-2-3] PRECISA respeitar o AndroidManifestLayout_minWidth declarado. e AndroidManifestLayout_minHeight valores do aplicativo de inicialização de terceiros e não substituem esses valores ao mostrar conteúdo da atividade ancorada.

Se as implementações de dispositivos oferecem suporte ao(s) modo(s) de várias janelas e ao picture-in-picture no modo de várias janelas, eles:

  • [C-3-1] PRECISA iniciar atividades no modo picture-in-picture de várias janelas. quando o app é: * Segmentar o nível 26 da API ou mais recente e declarar android:supportsPictureInPicture * Segmenta a API de nível 25 ou anterior e declara ambos android:resizeableActivity e android:supportsPictureInPicture.
  • [C-3-2] PRECISA expor as ações na SystemUI como especificado pela atividade do PIP atual com o setActions() API.
  • [C-3-3] PRECISA oferecer suporte a proporções maiores ou iguais a 1:2,39 e menor ou igual a 2,39:1, conforme especificado pela atividade PIP por setAspectRatio() API.
  • [C-3-4] PRECISA usar KeyEvent.KEYCODE_WINDOW. para controlar a janela PIP; se o modo PIP não estiver implementado, a chave DEVE ser disponível para a atividade em primeiro plano.
  • [C-3-5] PRECISA fornecer recursos do usuário para bloquear a exibição de um app Modo PIP; a implementação do AOSP atende a esse requisito controles na aba de notificações.
  • [C-3-6] PRECISA alocar a largura e a altura mínimas a seguir para o PIP quando um aplicativo não declarar nenhum valor para AndroidManifestLayout_minWidth e AndroidManifestLayout_minHeight:

    • Dispositivos com o Configuration.uiMode definido diferente de UI_MODE_TYPE_TELEVISION PRECISA alocar 108 dp de largura e altura.
    • Dispositivos com o Configuration.uiMode definido como UI_MODE_TYPE_TELEVISION PRECISA alocar uma largura mínima de 240 dp e uma altura mínima de 135 dp.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Se as implementações de dispositivos incluem mais de uma opção exibir áreas e disponibilizá-las para os aplicativos, eles:

  • [C-4-1] PRECISA ser compatível com o modo de várias janelas.

Se as implementações de dispositivos forem compatíveis com o modo de várias janelas, elas:

  • [C-5-1] PRECISA implementar a versão correta das extensões do gerenciador do Windows. nível da API, conforme descrito nas Extensões do WindowManager.

Encerrar novos requisitos

3.8.15. Recorte da tela

O Android oferece suporte a um recorte da tela, conforme descrito no documento do SDK. A API DisplayCutout define uma área na borda da tela que pode não funcionar para um aplicativo devido a um corte da tela ou uma tela curva nas bordas.

Se as implementações de dispositivos incluírem cortes de tela, elas:

  • [C-1-5] NÃO PODE ter cortes se a proporção do dispositivo for de 1,0 (1:1).
  • [C-1-2] NÃO PODE ter mais de um corte por borda.
  • [C-1-3] PRECISA respeitar as flags de corte da tela definidas pelo app com o WindowManager.LayoutParams conforme descrito no SDK.
  • [C-1-4] PRECISA informar os valores corretos para todas as métricas de corte definidas no API DisplayCutout.

3.8.16. Controles do dispositivo

O Android inclui ControlsProviderService e Control APIs que permitem que aplicativos de terceiros publiquem controles do dispositivo para status e ação dos usuários.

Consulte a Seção 2_2_3 para ver os requisitos específicos dos dispositivos.

3.8.17. Área de transferência

Implementações de dispositivos:

  • [C-0-1] NÃO É POSSÍVEL enviar dados da área de transferência para nenhum componente, atividade, serviço ou em qualquer conexão de rede, sem ação explícita do usuário (por exemplo, pressionar um na sobreposição), exceto para os serviços mencionados no 9.8.6 Captura de Conteúdo e Pesquisa no App.

Se as implementações do dispositivo gerarem uma visualização visível para o usuário quando o conteúdo for copiado para a área de transferência de qualquer item ClipData em que ClipData.getDescription().getExtras() contém android.content.extra.IS_SENSITIVE, ele:

  • [C-1-1] PRECISA encobrir a visualização visível para o usuário.

A implementação de referência do AOSP atende a esses requisitos da área de transferência.

3,9. Administração do dispositivo

Iniciar novos requisitos para a versão 15 (AOSP experimental)

O Android inclui recursos que permitem apps com reconhecimento aplicativos ativam aplicativos controladores de política de dispositivo para realizar funções de administração de dispositivos no nível do sistema, como aplicação de senha políticas ou realizar a limpeza remota, por meio do API Android Device Administration APIs do Gerenciador do Device Policy.

Se as implementações de dispositivos implementam toda a gama de administração de dispositivos definidas na documentação do SDK do Android, elas:

  • [C-1-1] PRECISA declarar android.software.device_admin.
  • [C-1-2] PRECISA oferecer suporte ao provisionamento do proprietário do dispositivo, conforme descrito em seção 3.9.1 e seção 3.9.1.1.

Encerrar novos requisitos

3.9.1. Provisionamento de dispositivos

3.9.1.1 Provisionamento do proprietário do dispositivo

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

  • [C-1-1] PRECISA ser compatível com o registro de um cliente do Device Policy (DPC) como um App proprietário do dispositivo conforme descrito abaixo:
    • Quando a implementação do dispositivo tiver nem os usuários nem dados do usuário configurados, ele:
      • [C-1-5] PRECISA registrar o aplicativo DPC como o app Proprietário do dispositivo ou ativar o app DPC para escolher se tornar Proprietário do Dispositivo ou do Perfil, se o dispositivo declarar suporte para comunicação a curta distância (NFC, na sigla em inglês) por meio de a flag de recurso android.hardware.nfc e recebe uma mensagem NFC que contêm um registro com tipo MIME MIME_TYPE_PROVISIONING_NFC.
      • [C-1-8] É NECESSÁRIO enviar o ACTION_GET_PROVISIONING_MODE. após o provisionamento do proprietário do dispositivo ser acionado para que o O app de DPC pode escolher se quer se tornar um Proprietário do Dispositivo ou um Perfil proprietário, dependendo dos valores android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES, a menos que possa ser determinado a partir contexto de que há apenas uma opção válida.
      • [C-1-9] PRECISA enviar o ACTION_ADMIN_POLICY_COMPLIANCE (link em inglês) para o aplicativo Proprietário do dispositivo se um Proprietário do dispositivo for estabelecido durante o provisionamento, independentemente do método usado. A o usuário não poderá continuar no assistente de configuração até que Proprietário do dispositivo concluído.
    • Quando a implementação do dispositivo tiver usuários ou os dados do usuário, ela:
      • [C-1-7] Não é NECESSÁRIO registrar nenhum aplicativo de DPC como o app proprietário do dispositivo mais.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [C-1-2] PRECISA mostrar um aviso de divulgação adequado (conforme mencionado no AOSP) e receba o consentimento afirmativo do usuário final antes de abrir o app. definido como proprietário do dispositivo, a menos que o dispositivo seja configurado de forma programática para Modo de demonstração na loja antes da interação do usuário final na tela. Se as implementações de dispositivos declararem android.software.device_admin, mas também incluem um modelo de gerenciamento de dispositivos móveis e fornecer um mecanismo promover um aplicativo configurado na solução como "Proprietário do dispositivo" equivalente" para "Proprietário do dispositivo" padrão, reconhecida pela norma Android DevicePolicyManager (link em inglês) APIs, eles:

  • [C-2-1] PRECISA ter um processo para verificar se um determinado app promovida pertence a um sistema legítimo de gerenciamento e tenha sido configurado na solução proprietária ter os direitos equivalentes como "Proprietário do dispositivo".

  • [C-2-2] PRECISA mostrar a mesma declaração de consentimento do proprietário do dispositivo AOSP que a fluxo iniciado por android.app.action.PROVISION_MANAGED_DEVICE antes de registrar o aplicativo DPC como "Proprietário do dispositivo".

  • [C-2-3] NÃO PODE codificar o consentimento nem impedir o uso de outros apps do proprietário do dispositivo.

Encerrar novos requisitos

3.9.1.2 Provisionamento de perfil gerenciado

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

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [C-1-2] O processo de provisionamento de perfil gerenciado (o fluxo iniciado pelo DPC usando o método android.app.action.PROVISION_MANAGED_PROFILE) ou pela plataforma), a tela de consentimento e a experiência do usuário DEVEM estar alinhadas com a implementação do AOSP.

Encerrar novos requisitos

  • [C-1-3] PRECISA fornecer as seguintes affordances do usuário nas configurações para indicar ao usuário quando uma função específica do sistema foi desativada pelo o controlador de política de dispositivo (DPC):

    • Um ícone consistente ou outra funcionalidade do usuário (por exemplo, o upstream ícone de informações do AOSP) para representar quando uma configuração específica é restrita por um administrador de dispositivo.
    • Uma breve mensagem de explicação, fornecida pelo administrador do dispositivo por meio do setShortSupportMessage
    • O ícone do aplicativo DPC.
  • [C-1-4] PRECISA iniciar o gerenciador de ACTION_PROVISIONING_SUCCESSFUL. no perfil de trabalho se um Proprietário do perfil for estabelecido ao o provisionamento é iniciado por android.app.action.PROVISION_MANAGED_PROFILE. e o DPC implementou o gerenciador.

  • [C-1-5] PRECISA enviar ACTION_PROFILE_PROVISIONING_COMPLETE são transmitidos para o DPC do perfil de trabalho quando o provisionamento é iniciado pelo android.app.action.PROVISION_MANAGED_PROFILE intenção.

  • [C-1-6] É NECESSÁRIO enviar o ACTION_GET_PROVISIONING_MODE. após o provisionamento do proprietário do perfil ser acionado para que o app DPC pode optar por se tornar Proprietário do dispositivo ou Proprietário do perfil, exceto quando o provisionamento é acionado pela intent android.app.action.PROVISION_MANAGED_PROFILE.

  • [C-1-7] PRECISA enviar ACTION_ADMIN_POLICY_COMPLIANCE intenção para o perfil de trabalho quando um Proprietário do perfil é estabelecido durante independentemente do método usado, exceto quando o provisionamento é acionado pela intent android.app.action.PROVISION_MANAGED_PROFILE. O usuário não poderá continuar no assistente de configuração até que o perfil Conclusão do app do proprietário.

  • [C-1-8] PRECISA enviar ACTION_MANAGED_PROFILE_PROVISIONED transmitidos ao DPC do perfil pessoal quando um Proprietário do perfil é estabelecido, seja qual for o método de provisionamento usado.

3.9.2. Suporte a perfis gerenciados

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

  • [C-1-1] PRECISA oferecer suporte aos perfis gerenciados pelo android.app.admin.DevicePolicyManager. APIs de terceiros.
  • [C-1-2] PRECISA permitir a criação de apenas um perfil gerenciado.
  • [C-1-3] PRECISA usar um selo de ícone (semelhante ao de trabalho upstream do AOSP) para representar os aplicativos e widgets gerenciados e outros elementos de interface com selo como Recentes & Notificações.
  • [C-1-4] PRECISA exibir um ícone de notificação (semelhante ao trabalho upstream do AOSP) ) para indicar quando o usuário está em um aplicativo de perfil gerenciado.
  • [C-1-5] PRECISA exibir um aviso indicando que o usuário está no grupo se e quando o dispositivo for ativado (ACTION_USER_PRESENT), e o aplicativo em primeiro plano está dentro do perfil gerenciado.
  • [C-1-6] Onde existe um perfil gerenciado, PRECISA mostrar uma affordance visual na Intent "Seletor" para permitir que o usuário encaminhe a intent para o usuário principal ou vice-versa, se ativado pelo Device Policy Controlador.
  • [C-1-7] Onde houver um perfil gerenciado, será NECESSÁRIO expor o seguinte usuário affordances para o usuário principal e o perfil gerenciado:
    • Contabilização separada para uso de bateria, localização, dados móveis e armazenamento para o usuário principal e o perfil gerenciado.
    • Gerenciamento independente de apps de VPN instalados na rede principal usuário ou perfil gerenciado.
    • Gerenciamento independente de aplicativos instalados no usuário principal ou perfil gerenciado.
    • Gerenciamento independente de contas do usuário principal ou gerenciadas perfil.
  • [C-1-8] PRECISA garantir que o discador, os contatos e as mensagens estejam pré-instalados os aplicativos podem pesquisar e procurar informações do autor da chamada no (se houver) ao lado dos do perfil principal, se o É permitido pelo Device Policy Controller.
  • [C-1-9] PRECISA garantir que ela atenda a todos os requisitos de segurança. aplicável a um dispositivo com vários usuários ativados (consulte a seção 9.5), embora o perfil gerenciado não é contado como outro usuário além do usuário principal.
  • [C-1-10] PRECISA garantir que os dados da captura de tela estejam salvos no perfil de trabalho. quando uma captura de tela é feita com um topActivity janela com foco (aquele com o qual o usuário interagiu por último entre todas as atividades) e ao qual pertence um app do perfil de trabalho.
  • [C-1-11] NÃO PODE capturar nenhum outro conteúdo da tela (barra do sistema, notificações ou qualquer conteúdo de perfil pessoal), exceto para o perfil de trabalho janelas/janelas do aplicativo ao salvar uma captura de tela no perfil de trabalho (para garantir que os dados os dados do perfil não são salvos no perfil de trabalho).

Se as implementações de dispositivo declararem android.software.managed_users e android.software.secure_lock_screen, eles:

  • [C-2-1] PRECISA ser compatível com a capacidade de especificar uma reunião separada da tela de bloqueio os seguintes requisitos para conceder acesso a apps em execução em um somente por perfil.
    • As implementações de dispositivos DEVEM respeitar as DevicePolicyManager.ACTION_SET_NEW_PASSWORD e mostrar uma interface para configurar uma tela de bloqueio separada para o perfil gerenciado.
    • As credenciais da tela de bloqueio do perfil gerenciado PRECISAM usar as mesmas informações armazenamento de credenciais e mecanismos de gerenciamento como o perfil pai, conforme documentado no Site do projeto de código aberto do Android.
    • As políticas de senha do DPC PRECISA ser aplicada apenas às credenciais da tela de bloqueio do perfil gerenciado, a menos que será chamado para a instância DevicePolicyManager retornada pelo getParentProfileInstance
  • Quando os contatos do perfil gerenciado são exibidos No registro de chamadas pré-instalado, interface na chamada, em andamento e na chamada perdida de notificações, contatos e mensagens, eles DEVEM receber o selo o mesmo selo usado para indicar aplicativos de perfil gerenciado.

3.9.3. Suporte gerenciado ao usuário

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

  • [C-1-1] PRECISA fornecer recursos para que o usuário faça logout e volte para o usuário principal em uma sessão multiusuário quando isLogoutEnabled retorna true. A funcionalidade do usuário PRECISA estar acessível na tela de bloqueio. sem desbloquear o dispositivo.

Se as implementações de dispositivos declararem android.software.device_admin e fornecerem uma funcionalidade de usuário no dispositivo para adicionar mais usuários secundários, ele:

  • [C-SR-1] É FORTEMENTE RECOMENDADO mostrar o mesmo consentimento do proprietário do dispositivo AOSP de divulgação que foram mostradas no fluxo iniciado por android.app.action.PROVISION_MANAGED_DEVICE, antes de permitir a adição de contas no novo usuário secundário, para que os usuários entendam que o dispositivo é gerenciado.

3.9.4. Requisitos do papel de Gerenciamento da política do dispositivo

Se as implementações de dispositivos informarem android.software.device_admin ou android.software.managed_users, ele poderá fazer o seguinte:

  • [C-1-1] PRECISA ser compatível com o papel de gerenciamento de políticas do dispositivo, conforme definido em seção 9.1. O aplicativo que detém o papel de gerenciamento de políticas do dispositivo PODE ser definido definindo config_devicePolicyManagement como o nome do pacote. O nome do pacote PRECISA ser seguido por : e pelo certificado de assinatura, a menos que o aplicativo seja pré-carregado.

Se um nome de pacote não for definido para config_devicePolicyManagement como descritas acima:

Se um nome de pacote for definido para config_devicePolicyManagement, conforme descrito acima:

  • [C-3-1] O aplicativo PRECISA estar instalado em todos perfis para um usuário.
  • [C-3-2] Implementações de dispositivos PODEM definir um aplicativo que atualiza o proprietário do papel de gerenciamento de políticas do dispositivo antes do provisionamento config_devicePolicyManagementUpdater:

Se um nome de pacote for definido para config_devicePolicyManagementUpdater como descritas acima:

  • [C-4-1] O aplicativo PRECISA estar pré-instalado no dispositivo.
  • [C-4-2] O aplicativo PRECISA implementar um filtro de intent que resolva android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER:

3.9.5. Framework de resolução de políticas do dispositivo

Se as implementações de dispositivos informarem android.software.device_admin ou android.software.managed_users, ele poderá fazer o seguinte:

3,10 Acessibilidade

O Android oferece uma camada de acessibilidade que ajuda usuários com deficiências a a navegar pelos dispositivos com mais facilidade. Além disso, o Android fornece APIs de plataforma que permitem que as implementações de serviços de acessibilidade recebam callbacks para o usuário e eventos do sistema e gerar mecanismos de feedback alternativos, como conversão de texto em voz, retorno tátil e navegação com trackball/botão direcional.

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

  • [C-1-1] PRECISA fornecer uma implementação da acessibilidade do Android. conforme descrito nas APIs de acessibilidade na documentação do SDK.
  • [C-1-2] PRECISA gerar eventos de acessibilidade e entregar os eventos AccessibilityEvent para todos os registrados AccessibilityService implementações conforme documentado no SDK.
  • [C-1-4] PRECISA fornecer recursos para o usuário controlar a acessibilidade. serviços que declaram AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_Button. Para implementações de dispositivos com uma barra de navegação do sistema, elas DEVE permitir que o usuário tenha a opção de usar um botão no sistema barra de navegação para controlar esses serviços.

Se as implementações de dispositivos incluírem serviços de acessibilidade pré-instalados, elas:

  • [C-2-1] PRECISA implementar esses serviços de acessibilidade pré-instalados Reconhecimento de inicialização direta quando o armazenamento de dados é criptografado com a criptografia baseada em arquivos (FBE, na sigla em inglês).
  • DEVE fornecer um mecanismo no fluxo de configuração pronto para que os usuários ativem serviços de acessibilidade relevantes, bem como opções para ajustar o tamanho da fonte, tamanho de exibição e gestos de ampliação.

3,11. Conversão de texto em voz

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

Se implementações de dispositivo relatam o recurso android.hardware.audio.output, eles:

Se as implementações de dispositivos forem compatíveis com a instalação de mecanismos TTS de terceiros, elas:

  • [C-2-1] PRECISA fornecer recursos para que o usuário possa selecionar uma TTS Engine para uso no sistema.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

3,12. TV Input Framework

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

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

  • [C-1-1] PRECISA declarar o recurso da plataforma android.software.live_tv.
  • [C-1-2] PRECISA oferecer suporte a todas as APIs TIF, como um aplicativo que usa essas APIs e as entradas de terceiros baseadas em TIF serviço pode ser instalado e usado no dispositivo.

Encerrar novos requisitos

3,13 Configurações rápidas

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

Se as implementações de dispositivos incluírem um componente de interface para Configurações rápidas e oferecer suporte a terceiros Em "Configurações rápidas", eles:

  • [C-1-1] PRECISA permitir que o usuário adicione ou remova os blocos fornecidos pelo quicksettings APIs de um app de terceiros.
  • [C-1-2] NÃO PODE adicionar automaticamente um bloco de um app de terceiros de forma automática para acessar as "Configurações rápidas".
  • [C-1-3] PRECISA mostrar todos os blocos adicionados pelo usuário de apps de terceiros. junto com os blocos de configuração rápida fornecidos pelo sistema.

3,14 Interface de mídia

Se as implementações de dispositivos incluírem aplicativos não ativados por voz (os Aplicativos) que interagem com aplicativos de terceiros no MediaBrowser ou MediaSession, os aplicativos:

  • [C-1-2] PRECISA mostrar claramente os ícones acessados por getIconBitmap() ou getIconUri(), além dos títulos. recebido via getTitle(), conforme descrito em MediaDescription. Pode encurtar títulos para cumprir regulamentações de segurança (por exemplo, distração do motorista).

  • [C-1-3] PRECISA mostrar o ícone do aplicativo de terceiros sempre que o conteúdo fornecido por esse aplicativo de terceiros.

  • [C-1-4] PRECISA permitir que o usuário interaja com todo o MediaBrowser hierarquia. PODE restringir o acesso a parte da hierarquia para cumprir as regulamentações de segurança (por exemplo, distração do motorista), mas NÃO PODEM dar tratamento preferencial com base no conteúdo ou provedor de conteúdo.

  • [C-1-5] PRECISA considerar o toque duplo de KEYCODE_HEADSETHOOK ou KEYCODE_MEDIA_PLAY_PAUSE como KEYCODE_MEDIA_NEXT para MediaSession.Callback#onMediaButtonEvent.

3,15 Instant Apps

Se as implementações de dispositivos forem compatíveis com Instant Apps, elas PRECISAM atender aos seguintes requisitos: requisitos:

  • [C-1-1] Os apps instantâneos só PRECISAM receber permissões com o android:protectionLevel Defina como "instant".
  • [C-1-2] Os apps instantâneos NÃO PODEM interagir com apps instalados por intents implícitas a menos que uma das seguintes condições seja verdadeira:
    • O filtro de padrão de intent do componente está exposto e tem CATEGORY_BROWSABLE
    • A ação é ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
    • O destino é explicitamente exposto com android:visibleToInstantApps
  • [C-1-3] Os Instant Apps NÃO PODEM interagir explicitamente com apps instalados, a menos que a o componente é exposto por android:visibleToInstantApps.
  • [C-1-4] Os apps instalados NÃO PODEM ver detalhes sobre os Instant Apps no dispositivo, a menos que o app instantâneo se conecte explicitamente aplicativo instalado.
  • As implementações de dispositivos PRECISAM fornecer as seguintes affordances do usuário para ao interagir com os Instant Apps. O AOSP atende aos requisitos das interface padrão do sistema, Configurações e Tela de início. Implementações de dispositivos:

    • [C-1-5] PRECISA fornecer recursos de usuário para visualizar e excluir Instant Apps armazenada localmente em cache para cada pacote de app.
    • [C-1-6] PRECISA fornecer uma notificação persistente ao usuário, que pode ser recolhido enquanto um Instant App está em execução em primeiro plano. Este usuário a notificação PRECISA incluir que os Instant Apps não exigem instalação. e fornecem uma affordance de usuário que o direcione ao aplicativo tela de informações em Configurações. Para Apps instantâneos iniciados por intents da Web, como definida usando uma intent com a ação definida como Intent.ACTION_VIEW e com um esquema de "http" ou "https", uma funcionalidade de usuário adicional, DEVE permitir que o usuário não inicie o app instantâneo e iniciar o link associado com o navegador da Web configurado, se um navegador está disponível no dispositivo.
    • [C-1-7] PRECISA permitir que os Instant Apps em execução sejam acessados em "Recentes" se a função Recentes estiver disponível no dispositivo.
  • [C-1-8] É NECESSÁRIO pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents para as intents listadas no SDK aqui. e tornar as intents visíveis para os Apps instantâneos.

3,16 Pareamento de dispositivo complementar

O Android inclui suporte para pareamento de dispositivos complementares para um gerenciamento mais eficaz associação com dispositivos complementares e fornece o CompanionDeviceManager API para que os apps acessem este recurso.

Se as implementações de dispositivos forem compatíveis com o recurso de pareamento de dispositivo complementar, elas:

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [C-1-3] PRECISA fornecer affordances para o usuário selecionar/confirmar uma dispositivo complementar estiver presente e operacional, que PRECISA usar a mesma mensagem implementada no AOSP sem adição ou modificação.

Encerrar novos requisitos

3.17. Apps pesados

Se as implementações de dispositivos declararem o recurso FEATURE_CANT_SAVE_STATE, então eles:

  • [C-1-1] PRECISA ter apenas um app instalado que especifique cantSaveState em execução no sistema por vez. Se o usuário sai de um aplicativo desse tipo sem sair dele explicitamente (por exemplo, pressionando em casa e deixa uma atividade ativa no sistema, em vez de pressionar "Voltar" sem atividades ativas restantes no sistema), as implementações de dispositivos PRECISAM priorizar esse aplicativo na RAM da mesma forma que fazem com outros aplicativos. que devem permanecer em execução, como serviços em primeiro plano. Enquanto esse app está em segundo plano, o sistema ainda pode usar energia recursos de gerenciamento, como limitar o acesso à CPU e à rede.
  • [C-1-2] PRECISA fornecer uma funcionalidade de interface para escolher o app que não vai: participam do mecanismo normal de salvar/restaurar o estado quando o usuário inicia um segundo app declarado com cantSaveState. .
  • [C-1-3] NÃO É POSSÍVEL aplicar outras mudanças na política a apps que especifiquem cantSaveState, como alterações no desempenho da CPU ou na priorização da programação.

Se as implementações do dispositivo não declararem o recurso FEATURE_CANT_SAVE_STATE, então eles:

  • [C-1-1] PRECISA ignorar cantSaveState. definido por apps e NÃO PODE mudar o comportamento do app com base nisso .

3,18. Contatos

O Android inclui Contacts Provider APIs para permitir que os aplicativos gerenciem informações de contato armazenadas no dispositivo. Os dados de contato inseridos diretamente no dispositivo geralmente são sincronizados. com um serviço da Web, mas os dados PODEM residir apenas localmente no dispositivo. Os contatos armazenados apenas no dispositivo são chamados de locais contatos.

RawContacts estão "associados a" ou "armazenado em" um Conta quando ACCOUNT_NAME, e ACCOUNT_TYPE, as colunas dos contatos brutos correspondem às Account.name e Account.type da conta.

Conta local padrão: uma conta para contatos brutos armazenados apenas em dispositivo e não associados a uma conta no Gerente de contas, que são criados com valores null para o ACCOUNT_NAME, e ACCOUNT_TYPE, colunas.

Conta local personalizada: uma conta para contatos brutos que são armazenados apenas no dispositivo do usuário e não associados a uma conta no AccountManager, que são criado com pelo menos um valor não nulo para o ACCOUNT_NAME, e ACCOUNT_TYPE, colunas.

Implementações de dispositivos:

  • [C-SR-1] É MUITO RECOMENDADO não criar contas locais personalizadas.

Se as implementações de dispositivos usarem uma conta local personalizada, faça o seguinte:

  • [C-1-1] A ACCOUNT_NAME, da conta local personalizada PRECISA ser retornada pelo ContactsContract.RawContacts.getLocalAccountName
  • [C-1-2] A ACCOUNT_TYPE, da conta local personalizada PRECISA ser retornada pelo ContactsContract.RawContacts.getLocalAccountType
  • [C-1-3] Contatos brutos inseridos por aplicativos de terceiros com a conta local padrão (ou seja, definindo valores nulos para ACCOUNT_NAME e ACCOUNT_TYPE) PRECISAM ser inseridos no local personalizado padrão.
  • [C-1-4] Os contatos brutos inseridos na conta local personalizada não PODEM ser removidas quando contas são adicionadas ou removidas.
  • [C-1-5] Operações de exclusão realizadas na conta local personalizada DEVE resultar na limpeza imediata dos contatos brutos (como se os CALLER_IS_SYNCADAPTER parâmetro foi definido como verdadeiro), mesmo que o parâmetro CALLER\_IS\_SYNCADAPTER fosse definido como falso ou não especificado.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

3,19. Configurações de idioma

Implementações de dispositivos:

  • [C-0-1] NÃO PODE fornecer nenhuma funcionalidade do usuário para selecionar opções específicas de gênero tratamento de linguagem para idiomas que não aceitam a faixa etária específica traduções. Consulte recursos gramaticais para mais informações.

Encerrar novos requisitos

4. Compatibilidade do empacotamento de aplicativos

Implementações de dispositivos:

  • [C-0-1] PRECISA ser capaz de instalar e executar o arquivo ".apk" do Android como gerado pelo "aapt" inclusa no SDK oficial do Android.

    • Como o requisito acima pode ser desafiador, as implementações de dispositivos são RECOMENDADO usar o gerenciamento de pacotes da implementação de referência do AOSP sistema.
  • [C-0-2] PRECISA ser compatível com a verificação de ".apk" usando o Esquema de assinatura de APK v3.1 Esquema de assinatura de APK v3 Esquema de assinatura de APK v2 e assinatura JAR.

  • [C-0-3] NÃO PODE estender o .apk Manifesto do Android, Bytecode Dalvik ou Formatos de bytecode do RenderScript de modo a impedir que esses arquivos sejam sendo instalado e executado corretamente em outros dispositivos compatíveis.

  • [C-0-4] NÃO É POSSÍVEL permitir outros apps além do atual "instalador do registro" para que o pacote desinstale o app silenciosamente sem confirmação do usuário, conforme documentado no SDK para o DELETE_PACKAGE permissão. As únicas exceções são o processamento do app do verificador de pacotes do sistema PACKAGE_NEEDS_VERIFICATION (em inglês) e o processamento de apps do gerenciador de armazenamento ACTION_MANAGE_STORAGE (em inglês) intenção.

  • [C-0-5] PRECISA ter uma atividade que gerencie android.settings.MANAGE_UNKNOWN_APP_SOURCES intenção.

  • [C-0-6] NÃO É POSSÍVEL instalar pacotes de aplicativos desconhecidos fontes, a menos que o app que solicite a instalação atenda a todos os requisitos a seguir:

    • Ela PRECISA declarar a REQUEST_INSTALL_PACKAGES. permissão ou definir android:targetSdkVersion como 24 ou inferior.
    • Ele PRECISA ter recebido permissão do usuário para instalar apps fontes desconhecidas.
  • DEVE fornecer uma funcionalidade ao usuário para conceder/revogar a permissão para instalar aplicativos de fontes desconhecidas por aplicativo, mas PODEM optar por implementar como um ambiente autônomo e retorna RESULT_CANCELED para startActivityForResult(), se a implementação do dispositivo não permitir que os usuários tenham essa opção. No entanto, mesmo nesses casos, eles DEVEM indicar ao usuário por que não há essa escolha apresentada.

  • [C-0-7] PRECISA exibir uma caixa de diálogo de aviso com a string de aviso que é fornecido pela API do sistema PackageManager.setHarmfulAppWarning para o usuário antes de iniciar uma atividade em um aplicativo que foi marcado pela mesma API do sistema PackageManager.setHarmfulAppWarning que possivelmente prejudiciais.

  • DEVE fornecer funcionalidade ao usuário para optar por desinstalar ou iniciar um aplicativo na caixa de diálogo de aviso.

  • [C-0-8] PRECISA implementar o suporte para o sistema de arquivos incremental, conforme documentado aqui.

  • [C-0-9] PRECISA oferecer suporte à verificação de arquivos .apk usando o Esquema de assinatura de APK v4 e Esquema de assinatura de APK v4.1.

.

5. Compatibilidade multimídia

Implementações de dispositivos:

  • [C-0-1] PRECISA 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] PRECISA declarar e informar o suporte dos codificadores e decodificadores disponíveis para aplicativos de terceiros MediaCodecList
  • [C-0-3] PRECISA ser capaz de decodificar e disponibilizar para terceiros apps em todos os formatos que ele pode codificar. Isso inclui todos os bitstreams que seu de rede e os perfis informados nos CamcorderProfile

Implementações de dispositivos:

  • DEVE visar a latência mínima do codec, ou seja,
    • NÃO DEVE consumir e armazenar buffers de entrada e retornar apenas buffers de entrada depois do processamento.
    • NÃO DEVE manter os buffers decodificados por mais tempo do que o especificado pelo padrão (por exemplo, SPS).
    • NÃO DEVE manter buffers codificados por mais tempo do que o exigido pelo GOP na estrutura dos preços.

Todos os codecs listados na seção abaixo são fornecidos como softwares. na implementação preferencial do Android do projeto de origem.

O Google e a Open Handset Alliance não fazem representação de que esses codecs não têm patentes de terceiros. Aqueles a intenção de usar esse código-fonte em produtos de hardware ou software é aconselhável que as implementações desse código, incluindo em softwares de código aberto ou o shareware, pode exigir licenças de patentes dos respectivos titulares das patentes.

5.1. Codecs de mídia

5.1.1. Codificação de áudio

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

Se as implementações de dispositivos declararem android.hardware.microphone, eles DEVEM ser compatíveis com a codificação dos formatos de áudio a seguir e disponibilizá-los para apps de terceiros:

  • [C-1-1] PCM/WAVE
  • [C-1-2] FLAC
  • [C-1-3] Opus

Todos os codificadores de áudio PRECISAM ser compatíveis com:

5.1.2. Decodificação de áudio

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

Se as implementações de dispositivo declararem suporte ao android.hardware.audio.output, eles precisam oferecer suporte à decodificação do seguintes formatos de áudio:

  • [C-1-1] Perfil AAC MPEG-4 (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-11] xHE-AAC (perfil ISO/IEC 23003-3 estendido HE AAC, que inclui o perfil de referência USAC e o intervalo dinâmico ISO/IEC 23003-4 perfil de controle)
  • [C-1-5] FLAC
  • [C-1-6] MP3
  • [C-1-7] MIDI
  • [C-1-8] Vórbis
  • [C-1-9] PCM/WAVE, incluindo áudio de alta resolução formatos de até 24 bits, taxa de amostragem de 192 kHz e 8 canais. Esse requisito serve apenas para decodificação, e um dispositivo tem permissão para downsample e downmix durante a fase de reprodução.
  • [C-1-10] Opus

Se as implementações do dispositivo forem compatíveis com a decodificação de buffers de entrada AAC de streams multicanais (ou seja, mais de dois canais) para PCM por meio do padrão Decodificador de áudio AAC na API android.media.MediaCodec, o seguinte PRECISA ser suportado:

  • [C-2-1] A decodificação PRECISA ser feita sem downmixing (por exemplo, um AAC de 5.0 o stream precisa ser decodificado para cinco canais de PCM, um stream AAC 5.1 precisa ser decodificado a seis canais de PCM).
  • [C-2-2] Os metadados de intervalo dinâmico PRECISAM ser conforme definidos em "Controle de intervalo dinâmico (RDC)" na norma ISO/IEC 14496-3 e as chaves android.media.MediaFormat DRC para configurar os comportamentos relacionados ao intervalo dinâmico do decodificador de áudio. A 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.
  • [C-SR-1] É FORTEMENTE RECOMENDADO que os requisitos C-2-1 e C-2-2 acima sejam por todos os decodificadores de áudio AAC.

Ao decodificar o áudio USAC, MPEG-D (ISO/IEC 23003-4):

  • [C-3-1] O volume e os metadados da DRC PRECISAM ser interpretados e aplicados de acordo com o nível 1 do perfil de controle de intervalo dinâmico da MPEG-D DRC.
  • [C-3-2] O decodificador PRECISA se comportar de acordo com a configuração definido com as seguintes chaves android.media.MediaFormat: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL e KEY_AAC_DRC_EFFECT_TYPE.

Decodificadores de perfil MPEG-4 AAC, HE AAC e HE AACv2:

  • Pode ser compatível com o controle de volume e de intervalo dinâmico usando ISO/IEC 23003-4 Perfil de controle de intervalo dinâmico.

Se a norma ISO/IEC 23003-4 e as normas ISO/IEC 23003-4 e Os metadados ISO/IEC 14496-3 estão presentes em um bitstream decodificado, então:

  • Os metadados ISO/IEC 23003-4 DEVEM ter precedência.

Todos os decodificadores de áudio PRECISAM oferecer suporte à saída de:

Se as implementações do dispositivo forem compatíveis com a decodificação de buffers de entrada AAC de streams multicanais (ou seja, mais de dois canais) para PCM por meio do padrão Decodificador de áudio AAC na API android.media.MediaCodec, o seguinte PRECISA ter suporte:

  • [C-7-1] PRECISA ser configurado pelo aplicativo usando a função de decodificação. com a chave KEY_MAX_OUTPUT_CHANNEL_COUNT para controlar se o conteúdo é reduzido para estéreo (ao usar o valor 2) ou se a saída for pelo número nativo de canais (ao usar um valor igual ou maior que esse número). Por exemplo, um valor de 6 ou mais configuraria um decodificador para produzir 6 canais quando alimentado com conteúdo 5.1.
  • [C-7-2] Ao decodificar, o decodificador PRECISA anunciar a máscara de canal que está sendo usada no formato de saída com o KEY_CHANNEL_MASK usando as constantes android.media.AudioFormat (exemplo: CHANNEL_OUT_5POINT1).

Se as implementações de dispositivos oferecem suporte a decodificadores de áudio diferentes do AAC padrão e são capazes de produzir áudio multicanal (ou seja, mais de 2 canais) quando alimentado com conteúdo multicanal compactado, então:

  • [C-SR-2] O decodificador é FORTEMENTE RECOMENDADO para ser configurado pelo aplicativo usando a função de decodificação com a chave KEY_MAX_OUTPUT_CHANNEL_COUNT para controlar se o conteúdo é reduzido para estéreo (ao usar o valor 2) ou se a saída for pelo número nativo de canais (ao usar um valor igual ou maior que esse número). Por exemplo, um valor de 6 ou mais configuraria um decodificador para produzir 6 canais quando alimentado com conteúdo 5.1.
  • [C-SR-3] Ao decodificar, o decodificador é FORTEMENTE RECOMENDADO para anunciar o máscara de canal usada no formato de saída com o KEY_CHANNEL_MASK usando as constantes android.media.AudioFormat (exemplo: CHANNEL_OUT_5POINT1).

5.1.3. Detalhes dos codecs de áudio

Formato/Codec Detalhes Tipos de arquivos/formatos de contêiner aceitos
Perfil AAC MPEG-4
(AAC LC)
Suporte a conteúdo mono/estéreo/5.0/5.1 com de 8 a 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
  • ADTS AAC bruto (.aac, ADIF não compatíveis)
  • MPEG-TS (.ts, não pesquisável, somente decodificação)
  • Matroska (.mkv, somente decodificação)
Perfil MPEG-4 HE AAC (AAC+) Suporte a conteúdo mono/estéreo/5.0/5.1 com de 16 a 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2
Perfil (AAC+ otimizado)
Suporte a conteúdo mono/estéreo/5.0/5.1 com de 16 a 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
AAC ELD (AAC aprimorado com atraso baixo) Compatibilidade com conteúdo mono/estéreo com taxas de amostragem padrão de 16 a 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
USAC Compatibilidade com conteúdo mono/estéreo com taxas de amostragem padrão de 7,35 para 48 kHz. MPEG-4 (.mp4, .m4a)
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, conforme definido em AMR-WB, multitaxa adaptável – Codec de fala de banda larga 3GPP (.3gp)
FLAC Para codificador e decodificador: pelo menos os modos mono e estéreo PRECISAM ser suporte. Taxas de amostragem de até 192 kHz PRECISAM ser compatíveis. 16 e 24 bits a resolução PRECISA ser suportada. O processamento de dados de áudio FLAC de 24 bits PRECISA ser disponível com a configuração de áudio de ponto flutuante.
  • FLAC (.flac)
  • MPEG-4 (.mp4, .m4a, somente decodificação)
  • Matroska (.mkv, somente decodificação)
MP3 Taxa de bits mono/estéreo constante (CBR) ou variável (VBR) de 8 a 320 Kbps
  • MP3 (.mp3)
  • MPEG-4 (.mp4, .m4a, somente decodificação)
  • Matroska (.mkv, somente decodificação)
MIDI MIDI tipos 0 e 1. DLS versões 1 e 2. XMF e XMF para celular. Suporte para formatos de toque RTTTL/RTX, OTA e iMelody
  • Tipo 0 e 1 (.mid, .xmf, .mxmf)
  • RTTTL/RTX (.rtttl, .rtx)
  • iMelody (.imy)
Vorbis Decodificação: suporte a conteúdo mono, estéreo, 5.0 e 5.1 com amostragem. de 8.000, 12.000, 16.000, 24.000 e 48.000 Hz.
Codificação: suporte a conteúdo mono e estéreo com taxas de amostragem de 8.000, 12.000, 16.000, 24.000 e 48.000 Hz.
  • Ogg (.ogg)
  • MPEG-4 (.mp4, .m4a, somente decodificação)
  • Matroska (.mkv)
  • Webm (.webm)
PCM/WAVE O codec PCM PRECISA ser compatível com PCM linear de 16 bits e flutuante de 16 bits. ONDA o extrator precisa oferecer suporte a PCM linear de 16, 24 e 32 bits e a flutuação de 32 bits (taxas até o limite de hardware). As taxas de amostragem PRECISAM ser compatíveis com 8 kHz a 192 kHz. WAVE (.wav)
Opus Decodificação: compatibilidade com conteúdo mono, estéreo, 5.0 e 5.1 com taxas de amostragem de 8.000, 12.000, 16.000, 24.000 e 48.000 Hz.
Codificação: suporte a conteúdo mono e estéreo com taxas de amostragem de 8.000, 12.000, 16.000, 24.000 e 48.000 Hz.
  • Ogg (.ogg)
  • MPEG-4 (.mp4, .m4a, somente decodificação)
  • Matroska (.mkv)
  • Webm (.webm)

5.1.4. Codificação de imagem

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

As implementações de dispositivos PRECISAM ser compatíveis com a seguinte codificação de imagem:

  • [C-0-1] JPEG
  • [C-0-2] PNG
  • [C-0-3] WebP
  • [C-0-4] AVIF
    • Os dispositivos precisam oferecer suporte a BITRATE_MODE_CQ e ao perfil de referência.

Se as implementações de dispositivos forem compatíveis com a codificação HEIC via android.media.MediaCodec para o tipo de mídia MIMETYPE_IMAGE_ANDROID_HEIC, eles:

  • [C-1-1] PRECISA fornecer um codec de codificador HEVC acelerado por hardware que oferece suporte para BITRATE_MODE_CQ modo de controle de taxa de bits, HEVCProfileMainStill perfil e frame de 512 x 512 px.

5.1.5 Decodificação de imagem

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

As implementações de dispositivos PRECISAM oferecer suporte à decodificação da seguinte codificaçã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] Bruto
  • [C-0-7] AVIF (perfil de referência)

Se as implementações de dispositivos forem compatíveis com a decodificação de vídeo HEVC, elas:

  • [C-1-1] PRECISA oferecer suporte à decodificação de imagem HEIF (HEIC).

Decodificadores de imagem compatíveis com um formato de alta profundidade de bits (mais de 9 bits por canal):

  • [C-2-1] PRECISA oferecer suporte à saída de um formato equivalente de 8 bits, se solicitado pelo aplicativo, por exemplo, pela classe ARGB_8888 de android.graphics.Bitmap.

5.1.6. Detalhes dos codecs de imagem

Formato/Codec Detalhes Tipos de arquivos/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)
HEIF Imagem, Coleção de imagens, Sequência de imagens HEIF (.heif), HEIC (.heic)
AVIF (perfil de referência) Imagem, coleta de imagens, perfil de referência de sequência de imagens Contêiner HEIF (.avif)

Codificadores e decodificadores de imagens expostos na API MediaCodec

  • [C-1-1] É NECESSÁRIO oferecer suporte para a cor flexível YUV420 8:8:8 formato (COLOR_FormatYUV420Flexible) até CodecCapabilities.

  • [C-SR-1] É MUITO RECOMENDADO para oferecer suporte ao formato de cores RGB888 para a superfície de entrada modo

  • [C-1-3] PRECISA suportar pelo menos um plano ou semiplanar Formato de cor YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) ou COLOR_FormatYUV420PackedSemiPlanar (equivalente) para COLOR_FormatYUV420SemiPlanar). Eles são FORTEMENTE RECOMENDADOS para oferecer suporte os dois.

5.1.7. Codecs de vídeo

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

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

  • [C-1-1] Os codecs de vídeo PRECISAM oferecer suporte a tamanhos de buffer de bytes de entrada e saída que acomodar o maior frame compactado viável e descompactado conforme ditado de acordo com o padrão e a configuração, mas sem superalocar.

  • [C-1-2] Codificadores e decodificadores de vídeo PRECISAM oferecer suporte à cor flexível YUV420 de 8:8:8. formatos (COLOR_FormatYUV420Flexible) até CodecCapabilities.

  • [C-1-3] Codificadores e decodificadores de vídeo PRECISAM oferecer suporte a pelo menos um Formato de cor semiplanar YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) ou COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar). Eles são FORTEMENTE RECOMENDADOS para oferecer suporte a ambos.

  • [C-SR-1] Codificadores e decodificadores de vídeo são FORTEMENTE RECOMENDADOS para oferecer suporte pelo menos uma cor plana ou semiplanar YUV420 8:8:8 otimizada por hardware formato (YV12, NV12, NV21 ou formato otimizado de fornecedor equivalente).

  • [C-1-5] Decodificadores de vídeo com suporte a um formato com alta profundidade de bits (mais de 9 bits por canal) PRECISA oferecer suporte à saída de um formato equivalente a 8 bits se solicitado pelo aplicativo. Isso DEVE ser refletido no suporte a uma YUV420 8:8:8 no formato de cor via android.media.MediaCodecInfo.

Se as implementações de dispositivos anunciarem suporte ao perfil HDR por meio do Display.HdrCapabilities, eles:

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

Se as implementações de dispositivos anunciarem suporte a atualizações intra FEATURE_IntraRefresh no MediaCodecInfo.CodecCapabilities , ela:

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

A menos que o aplicativo especifique o contrário usando o KEY_COLOR_FORMAT chave de formato, implementações do decodificador de vídeo:

  • [C-4-1] O padrão é o formato de cor otimizado para exibição de hardware se configurado usando a saída Surface.
  • [C-4-2] O padrão é um formato de cores YUV420 8:8:8 otimizado para CPU leitura se configurado para não usar a saída Surface.

5.1.8. Lista de codecs de vídeo

Formato/Codec Detalhes Tipos de arquivos/formatos de contêiner aceitos
H.263
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • Matroska (.mkv, somente decodificação)
H.264 AVC Consulte a seção 5.2 e 5.3 para mais detalhes
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • MPEG-2 TS (.ts, não pesquisável)
  • Matroska (.mkv, somente decodificação)
H.265 HEVC Consulte detalhes na seção 5.3
  • MPEG-4 (.mp4)
  • Matroska (.mkv, somente decodificação)
MPEG-2 Perfil principal
  • MPEG2-TS (.ts, não pesquisável)
  • MPEG-4 (.mp4, somente decodificação)
  • Matroska (.mkv, somente decodificação)
MPEG-4 SP
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • Matroska (.mkv, somente decodificação)
VP8 Consulte a seção 5.2 e 5.3 para mais detalhes
VP9 Consulte detalhes na seção 5.3
AV1 Consulte as seções 5.2 e 5.3 para mais detalhes
  • MPEG-4 (.mp4)
  • Matroska (.mkv, somente decodificação)

5.1.9. Segurança do codec de mídia

As implementações de dispositivos PRECISAM garantir compliance com os recursos de segurança do codec de mídia conforme descrito abaixo.

O Android inclui suporte para OMX, uma API de aceleração multimídia multiplataforma, bem como o Codec 2.0, uma API de aceleração de multimídia com baixa sobrecarga.

Se as implementações de dispositivos oferecerem suporte a multimídia, elas:

  • [C-1-1] PRECISA oferecer suporte a codecs de mídia via OMX ou Codec 2.0 APIs (ou ambas), como no Android Open Source Project, e não desativar ou burlar as proteções de segurança. Especificamente, isso não significa codec PRECISA usar a API OMX ou o Codec 2.0, somente esse suporte por pelo menos uma dessas APIs PRECISA estar disponível, e o suporte para as APIs disponíveis PRECISA estar disponível. incluem as proteções de segurança presentes.
  • [C-SR-1] É FORTEMENTE RECOMENDADO a inclusão de suporte para a API Codec 2.0.

Se as implementações de dispositivos não oferecerem suporte à API Codec 2.0, elas:

  • [C-2-1] PRECISA incluir o codec de software OMX correspondente do Android Projeto de código aberto (se disponível) para cada formato e tipo de mídia (codificador ou decodificador) suportado pelo dispositivo.
  • [C-2-2] Codecs que têm nomes que começam com "OMX.google". PRECISA se basear no código-fonte do Android Open Source Project.
  • [C-SR-2] É FORTEMENTE RECOMENDADO que os codecs do software OMX sejam executados em um codec processo que não tem acesso a drivers de hardware além de mapeadores de memória.

Se as implementações de dispositivos oferecerem suporte à API Codec 2.0, elas:

  • [C-3-1] PRECISA incluir o codec de software do Codec 2.0 correspondente Android Open Source Project (se disponível) para cada formato e tipo de mídia (codificador ou decodificador) suportado pelo dispositivo.
  • [C-3-2] PRECISA hospedar os codecs de software Codec 2.0 no codec de software. conforme fornecido no Android Open Source Project para possibilitar para conceder acesso mais restrito aos codecs de software.
  • [C-3-3] Codecs que têm nomes que começam com "c2.android". PRECISA se basear no código-fonte do Android Open Source Project.

5.1.10 Caracterização do codec de mídia

Se as implementações de dispositivos forem compatíveis com codecs de mídia, elas:

  • [C-1-1] PRECISA retornar valores corretos de caracterização do codec de mídia por meio do MediaCodecInfo API.

Especificamente, as seguintes:

  • [C-1-2] Codecs com nomes que começam com "OMX". É NECESSÁRIO usar as APIs OMX e que tenham nomes que estejam em conformidade com as diretrizes de nomenclatura OMX IL.
  • [C-1-3] Codecs com nomes que começam com "c2". PRECISA usar a API Codec 2.0 e têm nomes que estejam em conformidade com as diretrizes de nomenclatura Codec 2.0 para Android.
  • [C-1-4] Codecs com nomes que começam com "OMX.google". ou "c2.android". OBRIGATÓRIO NÃO ser caracterizada como fornecedora ou acelerada por hardware.
  • [C-1-5] Codecs que são executados em um processo de codec (fornecedor ou sistema) que tenham acesso a drivers de hardware que não sejam alocadores de memória e mapeadores NÃO PODEM ser caracterizada como somente software.
  • [C-1-6] Codecs ausentes ou não baseados no Android Open Source Project no código-fonte desse projeto PRECISA ser caracterizado como fornecedor.
  • [C-1-7] Codecs que utilizam aceleração de hardware PRECISAM ser caracterizados como acelerado por hardware.
  • [C-1-8] Os nomes de codecs NÃO PODEM ser enganosos. Por exemplo, codecs chamados "decodificadores" PRECISA oferecer suporte à decodificação, e os chamados "codificadores" DEVE oferecer suporte e codificação. Codecs com nomes que contêm formatos de mídia PRECISAM ser compatíveis com esses formatos.

Se as implementações de dispositivos forem compatíveis com codecs de vídeo:

  • [C-2-1] Todos os codecs de vídeo PRECISAM publicar dados de frame rate possíveis para o tamanhos a seguir se compatíveis com o codec:
SD (baixa qualidade) SD (alta qualidade) HD 720p HD 1080p Ultra HD
Resolução do vídeo
  • 176 x 144 px (H263, MPEG2, MPEG4)
  • 352 x 288 px (codificador MPEG4, H263, MPEG2)
  • 320 x 180 px (VP8, VP8)
  • 320 x 240 px (outros)
  • 704 x 576 px (H263)
  • 640 x 360 px (VP8, VP9)
  • 640 x 480 px (codificador MPEG4)
  • 720 x 480 px (outro, AV1)
  • 1.408 x 1.152 px (H263)
  • 1280 x 720 px (outro, AV1)
1920 x 1080 px (exceto MPEG4, AV1) 3.840 x 2.160 px (HEVC, VP9, AV1)
  • [C-2-2] Codecs de vídeo caracterizados como acelerados por hardware PRECISAM publicar as informações dos pontos de desempenho. Eles PRECISAM listar todos os compatíveis pontos de desempenho padrão (listados em PerformancePoint) API), a menos que tenham cobertura de outro ponto de desempenho padrão compatível.
  • Além disso, DEVEM publicar pontos de desempenho estendidos se oferecer suporte a desempenho contínuo de vídeo, diferente dos padrão listados.

5,2. Codificação de vídeo

Se as implementações de dispositivos forem compatíveis com qualquer codificador de vídeo e o disponibilizar apps de terceiros, e defina a
MediaFormat.KEY_BITRATE_MODE para BITRATE_MODE_VBR para que o codificador opere no modo de taxa de bits variável. desde que isso não afete o valor mínimo de qualidade, a taxa de bits codificada :

  • Mais de um janela deslizante, mais de 15% acima da taxa de bits entre os intraframes (I-frame) em intervalos de IP.
  • NÃO DEVE ser maior que 100% acima da taxa de bits em uma janela deslizante de um segundo.

Se as implementações de dispositivos forem compatíveis com qualquer codificador de vídeo e o disponibilizar apps de terceiros e definir MediaFormat.KEY_BITRATE_MODE para BITRATE_MODE_CBR Assim, o codificador opera em modo de taxa de bits constante e, em seguida, a taxa de bits codificada:

  • [C-SR-2] é FORTEMENTE RECOMENDADO para NÃO pode ser superior a 15% acima da taxa de bits desejada em uma janela deslizante de 1 segundo.

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

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

Se as implementações de dispositivos forem compatíveis com vídeos H.264, VP8, VP9 ou HEVC codificadores e disponibilizá-los para aplicativos de terceiros, ela:

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

Se as implementações de dispositivos forem compatíveis com o codificador de vídeo MPEG-4 SP, para apps de terceiros, eles:

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

Se as implementações de dispositivos fornecerem codificadores de vídeo ou imagem com aceleração de hardware, e oferecer suporte a uma ou mais câmeras de hardware conectadas ou conectáveis expostas por as APIs android.camera:

  • [C-4-1] Todos os codificadores de vídeo e imagem com aceleração de hardware PRECISAM ser compatíveis com codificando frames da(s) câmera(s) de hardware.
  • DEVE oferecer suporte à codificação de frames da(s) câmera(s) de hardware em todos os vídeos ou codificadores de imagem.

Se as implementações de dispositivos fornecerem codificação HDR, elas:

  • [C-SR-1] é FORTEMENTE RECOMENDADO que forneça um plug-in para a API de transcodificação contínua para converter de HDR para SDR.

5.2.1. H.263

Se as implementações de dispositivos oferecerem suporte a codificadores H.263 a apps de terceiros, ela:

  • [C-1-1] PRECISA oferecer suporte à resolução QCIF (176 x 144) usando o perfil de referência de nível 45. A resolução SQCIF é opcional.

5.2.2. H.264

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

  • [C-1-1] PRECISA oferecer suporte ao perfil de referência de nível 3. No entanto, o suporte para ASO (Ordem Arbitrária de Frações), FMO (Flexível) Ordenação de Macroblocks) e RS (Slices Redundantes) são OPCIONAL. Além disso, para mantêm a compatibilidade com outros dispositivos Android, é RECOMENDADO que ASO, FMO e RS não são usados para o perfil de referência por codificadores.
  • [C-1-2] PRECISA 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 HD (alta definição) como indicados na tabela a seguir.

Se as implementações de dispositivos informarem suporte à codificação H.264 para 720p ou 1080p e resolução de vídeos através das APIs de mídia, eles:

  • [C-2-1] PRECISA 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).
  • [C-1-2] PRECISA oferecer suporte à gravação de arquivos Matroska WebM.
  • DEVE fornecer um codec VP8 de hardware que atenda às Requisitos de codificação de hardware RTC do projeto WebM, para garantir qualidade aceitável dos serviços de streaming e videoconferência na Web.

Se as implementações do dispositivo relatarem compatibilidade com a codificação VP8 para 720p ou 1080p e resolução de vídeos através das APIs de mídia, eles:

  • [C-2-1] PRECISA 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:

  • [C-1-2] PRECISA oferecer suporte ao Perfil 0 de Nível 3.
  • [C-1-1] PRECISA oferecer suporte à gravação de arquivos Matroska WebM.
  • [C-1-3] PRECISA gerar dados do CodecPrivate.
  • DEVE oferecer suporte aos perfis de decodificação de HD conforme indicado na tabela a seguir.
  • [C-SR-1] é FORTEMENTE RECOMENDADO para oferecer suporte aos perfis de decodificação de HD como indicado na tabela a seguir se houver um codificador de hardware.
SD HD 720p HD 1080p Ultra HD
Resolução do vídeo 720 x 480 px 1.280 x 720 px 1.920 x 1.080 px 3.840 x 2.160 px
Frame rate do vídeo 30 fps 30 fps 30 fps 30 fps
Taxa de bits do vídeo 1,6 Mbps 4 Mbps 5 Mbps 20 Mbps

Se as implementações de dispositivos alegarem ser compatíveis com os perfis 2 ou 3 nas APIs Media:

  • O suporte para o formato de 12 bits é OPCIONAL.

5.2.5. H.265

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

  • [C-1-1] PRECISA oferecer suporte ao perfil principal de nível 3 até Resolução de 512 x 512.
  • [C-SR-1] é FORTEMENTE RECOMENDADO para dar suporte à um perfil SD de 720 x 480 e o de codificação em HD conforme indicado na tabela a seguir, se houver um codificador de hardware.
SD HD 720p HD 1080p Ultra HD
Resolução do vídeo 720 x 480 px 1.280 x 720 px 1.920 x 1.080 px 3.840 x 2.160 px
Frame rate do vídeo 30 fps 30 fps 30 fps 30 fps
Taxa de bits do vídeo 1,6 Mbps 4 Mbps 5 Mbps 20 Mbps

5.2.6. AV1

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

  • [C-1-1] PRECISA oferecer suporte ao Perfil principal, incluindo conteúdo de 8 e 10 bits.
  • [C-1-2] PRECISA publicar os dados de performance, ou seja, informar os dados de performance pelo getSupportedFrameRatesFor() ou getSupportedPerformancePoints() APIs para resoluções com suporte na tabela abaixo.

  • [C-1-3] PRECISA aceitar metadados HDR e enviá-los para o bitstream.

Se o codificador AV1 tiver aceleração de hardware, ele:

  • [C-2-1] PRECISA suportar, e até mesmo, o perfil de codificação HD1080p da na tabela abaixo:
SD HD 720p HD 1080p Ultra HD
Resolução do vídeo 720 x 480 px 1.280 x 720 px 1.920 x 1.080 px 3.840 x 2.160 px
Frame rate do vídeo 30 fps 30 fps 30 fps 30 fps
Taxa de bits do vídeo 5 Mbps 8 Mbps 16 Mbps 50 Mbps

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] PRECISA ser compatível com a resolução dinâmica de vídeo e a troca de frame rate. usando as APIs padrão do Android no mesmo fluxo para todos os pacotes VP8, VP9, Codecs H.264 e H.265 em tempo real e até a resolução máxima suportada de cada codec do dispositivo.

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] PRECISA oferecer suporte ao perfil de referência de nível 30. (Resoluções CIF, QCIF e SQCIF a 30 fps a 384 kbps) e Nível 45 (QCIF e resoluções SQCIF a 30 fps a 128 kbps).

5.3.3. MPEG-4

Se implementações de dispositivos com decodificadores MPEG-4, elas:

  • [C-1-1] PRECISA 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] PRECISA oferecer suporte ao perfil principal de nível 3.1 e ao perfil de referência. Suporte para ASO (Ordem Arbitrária de Frações), FMO (Ordem Flexível de Macrobloco) e RS (Slices redundantes) é OPCIONAL.
  • [C-1-2] PRECISA ser capaz de decodificar vídeos com SD (definição padrão) perfis listados na tabela a seguir e codificados com o perfil de referência e o nível 3.1 do perfil principal (incluindo 720p30).
  • DEVE SER capaz de decodificar vídeos com os perfis HD (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, implementações de dispositivo:

  • [C-2-1] PRECISA oferecer suporte aos perfis de decodificação de vídeo HD de 720p nos seguintes tabela.
  • [C-2-2] PRECISA oferecer suporte aos perfis de decodificação de vídeo HD 1080p nos seguintes tabela.
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 fps (60 fpsTelevisão)
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] PRECISA ser compatível com o nível 3 do perfil principal e com o vídeo SD e decodificando perfis conforme indicado na tabela a seguir.
  • DEVE oferecer suporte aos perfis de decodificação de HD conforme indicado na tabela a seguir.
  • [C-1-2] PRECISA oferecer suporte aos perfis de decodificação de HD, conforme indicado no 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, então:

  • [C-2-1] As implementações de dispositivos PRECISAM ser compatíveis com pelo menos H.265 ou VP9 decodificação de 720, 1080 perfis e Ultra HD.
SD (baixa qualidade) SD (alta qualidade) HD 720p HD 1080p Ultra HD
Resolução do vídeo 352 x 288 pixels 720 x 480 px 1.280 x 720 px 1.920 x 1.080 px 3.840 x 2.160 px
Frame rate do vídeo 30 fps 30 fps 30 fps 30/60 fps (60 fpsTelevisão com decodificação de hardware H.265) 60 qps
Taxa de bits do vídeo 600 Kbps 1,6 Mbps 4 Mbps 5 Mbps 20 Mbps

Se as implementações de dispositivos alegarem compatibilidade com um perfil HDR pela mídia APIs:

  • [C-3-1] As implementações de dispositivos PRECISAM aceitar os metadados HDR obrigatórios de do aplicativo, além de oferecer suporte à extração e saída do HDR necessário metadados do bitstream e/ou contêiner.
  • [C-3-2] As implementações de dispositivos PRECISAM exibir corretamente o conteúdo HDR na na tela do dispositivo ou em uma porta de saída de vídeo padrão (por exemplo, HDMI.

5.3.6. VP8

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

  • [C-1-1] PRECISA oferecer suporte aos perfis de decodificação de SD na tabela a seguir.
  • DEVE usar um codec VP8 de hardware que atenda às requisitos.
  • DEVE oferecer suporte aos perfis de decodificação de 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, então:

  • [C-2-1] As implementações de dispositivos PRECISAM oferecer suporte a perfis de 720p no tabela a seguir.
  • [C-2-2] As implementações de dispositivos PRECISAM oferecer suporte a perfis de 1080p no 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 (60 fpsTelevisão) 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 no tabela a seguir.
  • DEVE oferecer suporte aos perfis de decodificação de HD conforme indicado na tabela a seguir.

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

  • [C-2-1] PRECISA oferecer suporte aos perfis de decodificação de HD, conforme indicado no tabela.

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

  • [C-3-1] As implementações de dispositivos PRECISAM oferecer suporte a pelo menos um VP9 ou H.265. e decodificação dos perfis 720, 1080 e Ultra HD.
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 3.840 x 2.160 px
Frame rate do vídeo 30 fps 30 fps 30 fps 30 fps (60 fpsTelevisão 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

Se as implementações de dispositivos alegam oferecer suporte a VP9Profile2 ou VP9Profile3 por meio do elemento 'CodecProfileLevel' APIs de mídia:

  • O suporte para o formato de 12 bits é OPCIONAL.

Se as implementações de dispositivos alegarem compatibilidade com um perfil HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) pelo APIs de mídia:

  • [C-4-1] As implementações de dispositivos PRECISAM aceitar os metadados HDR obrigatórios (KEY_HDR_STATIC_INFO) para todos os perfis HDR e "KEY_HDR10_PLUS_INFO" para perfis HDR10Plus) do aplicativo. Eles também PRECISAM oferecer suporte à extração e saída do metadados HDR exigidos do bitstream e/ou contêiner.
  • [C-4-2] As implementações de dispositivos PRECISAM exibir corretamente o conteúdo HDR na tela na tela do dispositivo ou em uma porta de saída de vídeo padrão (por exemplo, HDMI.

5.3.8. Dolby Vision

Se as implementações de dispositivos declararem suporte para o decodificador Dolby Vision usando HDR_TYPE_DOLBY_VISION, eles:

  • [C-1-1] PRECISA fornecer um extrator compatível com Dolby Vision.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [C-1-2] PRECISA mostrar corretamente o conteúdo do Dolby Vision qualquer um no dispositivo ou em um monitor externo conectado por uma porta de saída de vídeo padrão (por exemplo, HDMI.

Encerrar novos requisitos

  • [C-1-3] É NECESSÁRIO definir o ID da faixa de camadas de base compatíveis com versões anteriores (se houver) sejam iguais combinou o ID de faixa da camada Dolby Vision.

5.3.9. AV1

Se as implementações de dispositivos forem compatíveis com o codec AV1 e o disponibilizarem para aplicativos de terceiros, elas:

  • [C-1-1] PRECISA oferecer suporte ao Perfil principal, incluindo conteúdo de 8 e 10 bits.

Se as implementações de dispositivos oferecerem suporte ao codec AV1 com um hardware decodificador acelerado:

  • [C-2-1] PRECISA ser capaz de decodificar pelo menos os perfis de decodificação de vídeo HD de 720p na tabela abaixo quando a altura relatada por Display.getSupportedModes() é igual ou maior que 720p.
  • [C-2-2] É NECESSÁRIO decodificar pelo menos os perfis de decodificação de vídeo HD de 1080p na tabela abaixo quando a altura informada por Display.getSupportedModes() é igual ou maior que 1080p.
SD HD 720p HD 1080p Ultra HD
Resolução do vídeo 720 x 480 px 1.280 x 720 px 1.920 x 1.080 px 3.840 x 2.160 px
Frame rate do vídeo 30 fps 30 fps 30 fps 30 fps
Taxa de bits do vídeo 5 Mbps 8 Mbps 16 Mbps 50 Mbps

Se as implementações de dispositivos oferecerem suporte ao perfil HDR por meio das APIs de mídia, então: eles:

  • [C-3-1] PRECISA oferecer suporte à extração e saída de metadados HDR do bitstream e/ou contêiner.
  • [C-3-2] PRECISA exibir corretamente o conteúdo HDR na tela do dispositivo ou em um porta de saída de vídeo padrão (por exemplo, HDMI).

5,4. Gravação em áudio

Embora alguns dos requisitos descritos nesta seção estejam listados como DEVE desde o Android 4.3, a definição de compatibilidade para versões futuras está planejada para mudar para OBRIGATÓRIO. Dispositivos Android novos e já existentes são MAIS IMPORTANTES RECOMENDADO para atender aos requisitos listados como DEVE ou não serão compatíveis com Android quando o upgrade for feito no futuro. para a versão anterior.

5.4.1. Captura de áudio bruta e informações do microfone

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

  • [C-1-1] PRECISA permitir a captura de conteúdo de áudio bruto para qualquer stream INPUT AudioRecord ou AAudio que esteja aberto com sucesso. No mínimo, as seguintes características PRECISAM ser compatíveis:

  • DEVE permitir a captura de conteúdo de áudio bruto com as seguintes características:

    • Formato: PCM linear de 16 e 24 bits
    • Taxas de amostragem: 8000, 11025, 16000, 22050, 24000, 32000, 44100 48.000 Hz
    • Canais: o número de canais que o número de microfones no dispositivo
  • [C-1-2] PRECISA capturar taxas de amostragem acima da média sem aumento de amostragem.

  • [C-1-3] PRECISA incluir um filtro anti-aliasing adequado quando o as taxas de amostragem fornecidas acima são capturadas com a redução de amostragem.

  • DEVE permitir 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
  • [C-1-4] PRECISA respeitar a API MicrophoneInfo. e preencher adequadamente as informações dos microfones disponíveis no dispositivo pode ser acessado pelos aplicativos de terceiros AudioManager.getMicrophones() para AudioRecord ativo usando MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED ou VOICE_PERFORMANCE. Se as implementações de dispositivos permitirem captura de áudio bruto com qualidade de rádio AM e DVD eles:

  • [C-2-1] PRECISA capturar sem aumento de amostragem a qualquer proporção maior que 16000:22050 ou 44100:48000.

  • [C-2-2] PRECISA incluir um filtro anti-aliasing adequado para todos os aumentos na amostragem ou down-amostragem.

5.4.2. Captura para reconhecimento de voz

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

  • [C-1-1] PRECISA capturar Fonte de áudio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION em uma das taxas de amostragem, 44100 e 48000.
  • [C-1-2] PRECISA, por padrão, desativar o processamento de áudio com redução de ruído ao gravando um stream de áudio do AudioSource.VOICE_RECOGNITION fonte.
  • [C-1-3] PRECISA, por padrão, desativar qualquer controle automático de ganho ao gravar um stream de áudio da fonte de áudio AudioSource.VOICE_RECOGNITION.

  • DEVE exibir características de amplitude em relação à frequência aproximadas planas no intervalo de frequência média: especificamente ±3 dB de 100 Hz a 4.000 Hz para cada e cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.

  • [C-SR-1] é MUITO RECOMENDADO a exibir níveis de amplitude em baixos da faixa de frequência específica: de ±20 dB de 30 Hz a 100 Hz, em comparação intervalo de frequência média para cada microfone usado para gravar a voz fonte de áudio de reconhecimento de marca.

  • [C-SR-2] é MUITO RECOMENDADO a exibir níveis de amplitude nos valores da faixa de frequência específica: de ±30 dB de 4.000 Hz a 22 KHz, em comparação com o intervalo de média da frequência de cada microfone usado para gravar a voz fonte de áudio de reconhecimento de marca.

  • DEVE configurar a sensibilidade da entrada de áudio de forma que uma fonte de tom senoidal de 1.000 Hz tocado em 90 dB de nível de pressão do som (SPL) (medido ao lado do microfone) produz uma resposta ideal de RMS 2500 dentro de um intervalo de 1770 e 3530 para 16 bit-samples (ou -22,35 db ±3dB escala total para ponto flutuante/precisão dupla) amostras) para cada microfone usado para gravar o reconhecimento de voz fonte de áudio.

  • DEVE gravar o stream de áudio de reconhecimento de voz para que a amplitude de PCM os níveis rastreiam linearmente as mudanças de SPL de entrada em um intervalo de pelo menos 30 dB, de -18 De dB a +12 dB re 90 dB SPL no microfone.

  • DEVE gravar o stream de áudio de reconhecimento de voz com harmônico total distorção (THD) menor que 1% para 1 kHz em um nível de entrada de SPL de 90 dB em ao microfone do meu dispositivo.

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

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

5.4.3. Capturar para traçar novo trajeto de reprodução

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

Se as implementações de dispositivos declararem android.hardware.audio.output e android.hardware.microphone, eles:

  • [C-1-1] PRECISA implementar corretamente a fonte de áudio REMOTE_SUBMIX para que quando um aplicativo usa a API android.media.AudioRecord para gravar usando fonte de áudio, ela captura uma combinação de todos os streams de áudio, exceto:

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

5.4.4. Cancelador de eco acústico

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

  • DEVE implementar um cancelador de eco acústico (AEC, na sigla em inglês) ajustada para comunicação por voz e aplicada ao caminho de captura ao capturar usando AudioSource.VOICE_COMMUNICATION.

Se as implementações do dispositivo fornecerem um cancelador de eco acústico, que é inserido no caminho de áudio de captura quando AudioSource.VOICE_COMMUNICATION for selecionada, eles:

5.4.5. Captura simultânea

Se as implementações de dispositivos declararem android.hardware.microphone,elas PRECISAM implementar a captura simultânea, conforme descrito neste documento. Especificamente:

  • [C-1-1] PRECISA permitir o acesso simultâneo ao microfone por um dispositivo de acessibilidade captura de serviço com AudioSource.VOICE_RECOGNITION e pelo menos um captura de aplicativos com qualquer AudioSource.
  • [C-1-2] PRECISA permitir o acesso simultâneo ao microfone por um dispositivo aplicativo com uma função de assistente e pelo menos um aplicativo capturando com qualquer AudioSource, exceto AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER.
  • [C-1-3] PRECISA silenciar a captura de áudio de qualquer outro aplicativo, exceto um serviço de acessibilidade, enquanto um aplicativo está capturando com AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER. No entanto, quando Um app está capturando via AudioSource.VOICE_COMMUNICATION e depois outro app pode capturar a ligação se for um aplicativo privilegiado (pré-instalado) com permissão CAPTURE_AUDIO_OUTPUT.
  • [C-1-4] Se dois ou mais aplicativos estiverem capturando simultaneamente nenhum dos aplicativos tem uma interface na parte superior, aquela que iniciou a captura mais recentemente recebe áudio.

5,5. Reprodução de áudio

O Android inclui suporte para permitir que apps reproduzam áudio pela própria como um periférico, conforme definido na seção 7.8.2.

5.5.1. Reprodução de áudio bruto

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

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

    • Formatos de origem: PCM linear, 16 bits, 8 bits, flutuante
    • Canais: mono, estéreo, configurações multicanal válidas com até 8 canais
    • Taxas de amostragem (em Hz):
      • 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 no canal configurações listadas acima
      • 96.000 em mono e estéreo

5.5.2. Efeitos de áudio

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

Se as implementações de dispositivos declararem o recurso android.hardware.audio.output, eles:

  • [C-1-1] PRECISA oferecer suporte às APIs EFFECT_TYPE_EQUALIZER e Implementações EFFECT_TYPE_LOUDNESS_ENHANCER controláveis pelo Subclasses de AudioEffect Equalizer e LoudnessEnhancer.
  • [C-1-2] PRECISA oferecer suporte à implementação da API do visualizador, controlável pelo a classe Visualizer.
  • [C-1-3] PRECISA oferecer suporte à implementação de EFFECT_TYPE_DYNAMICS_PROCESSING. controlável pela subclasse AudioEffect DynamicsProcessing.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [C-1-4] PRECISA oferecer suporte a efeitos de áudio com entrada e saída de ponto flutuante, quando o efeito são retornados ao pipeline de áudio do framework. Isso se refere a inserir ou usar efeitos AUX, como o equalizador. O comportamento equivalente é muito recomendado quando os resultados do efeito não são visíveis pelo áudio do framework pipeline (como pós-processamento ou efeitos descarregados).

Encerrar novos requisitos

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [C-1-5] PRECISA garantir que os efeitos de áudio ofereçam suporte a vários canais, até a contagem de canais do mixer, também conhecida como FCC_LIMIT, quando os resultados do efeito são retornados ao pipeline de áudio do framework. Isso refere-se aos efeitos comuns de inserção ou auxiliar, mas exclui efeitos especiais, como como downmix, upmix e efeitos de espacialização que mudam a contagem de canais. Um comportamento equivalente é recomendado quando os efeitos não são visíveis pelo pipeline de áudio do framework (como pós-processamento ou efeitos).

Encerrar novos requisitos

  • DEVE oferecer suporte a EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, implementações de EFFECT_TYPE_PRESET_REVERB e EFFECT_TYPE_VIRTUALIZER controlável pelas subclasses AudioEffect BassBoost, EnvironmentalReverb, PresetReverb e Virtualizer.
  • [C-SR-1] É FORTEMENTE RECOMENDADO para oferecer suporte a efeitos em pontos flutuantes e multicanal.

5.5.3. Volume de saída de áudio

Implementações de dispositivos automotivos:

  • DEVE permitir o ajuste do volume do áudio separadamente por stream de áudio com base no tipo ou uso de conteúdo, conforme definido por AudioAttributes e uso de áudio do carro, conforme definido publicamente em android.car.CarAudioManager.

5.5.4. Descarregamento de áudio

Se as implementações de dispositivos forem compatíveis com a reprodução de descarregamento de áudio, elas:

  • [C-SR-1] É FORTEMENTE RECOMENDADO para cortar o conteúdo de áudio reproduzido sem lacunas entre dois clipes com o mesmo formato quando especificado pelo API AudioTrack sem lacunas e o contêiner de mídia do MediaPlayer.

5,6. Latência de áudio

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

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 quando o som correspondente é apresentado ao em um transdutor no dispositivo ou o sinal sai do dispositivo por uma e podem ser observados externamente.
  • latência de saída a frio. O tempo entre o início de um stream de saída e o a hora de apresentação do primeiro frame com base em carimbos de data/hora, quando a saída de áudio sistema esteve 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 estiver reproduzindo áudio.
  • latência de entrada. É o intervalo entre o momento em que um som é apresentado entre o dispositivo e um transdutor ou a entrada de sinal no dispositivo via uma porta e quando um aplicativo lê o frame correspondente de dados codificados em PCM.
  • entrada perdida. A parte inicial de um sinal de entrada que é inutilizável ou indisponível.
  • latência de entrada a frio. O tempo entre o início da transmissão e quando o primeiro frame válido, quando o sistema de entrada de áudio está ocioso, e desligados antes da solicitação.
  • latência de entrada contínua. a latência de entrada para frames subsequentes; enquanto o dispositivo está capturando áudio.
  • latência de ida e volta contínua. A soma da latência de entrada contínua mais latência de saída contínua mais um período de buffer. O período de buffer permite tempo para o app processar o sinal e tempo para a mitigação do app a diferença entre os fluxos de entrada e saída.
  • API OpenSL ES PCM da fila de buffer. O conjunto de dados de PCM OpenSL ES (link em inglês) APIs no Android NDK.
  • API Native Audio da AAudio. O conjunto de APIs AAudio no Android NDK.
  • Carimbo de data/hora. Um par que consiste em uma posição relativa do frame em um e o tempo estimado quando esse frame entra ou sai do de processamento de áudio no endpoint associado. Consulte também AudioTimestamp.
  • glitch. Uma interrupção temporária ou um valor de amostra incorreto no sinal de áudio normalmente é causado por buffer underrun para saída, estouro de buffer para entrada ou qualquer outra fonte de ruído digital ou analógico.
  • desvio médio absoluto (MAD, na sigla em inglês). A média do valor absoluto do desvios da média de um conjunto de valores.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • A latência de toque para tom (TTL), conforme medido pelo CTS Verifier, é o tempo entre o momento em que é tocado na tela e quando um tom é gerado como resultado disso. é ouvido no alto-falante. A média é calculada com base em cinco medições usando o API de áudio nativa da AAudio para saída.

  • A latência de ida e volta (RTL, na sigla em inglês), conforme medida pelo CTS Verifier, é a média Latência contínua em cinco medições, medida em um caminho de loopback que alimenta a saída de volta para a entrada, usando a API de áudio nativo da AAudio. Os caminhos de loopback são:

    • Alto-falante/microfone: alto-falante integrado para microfone integrado.
    • Analógico: entrada analógica de 3,5 mm e adaptador de loopback.
    • USB: adaptador de USB para 3,5 mm e um adaptador de loopback ou de áudio USB e cabos de loopback.
  • FEATURE_AUDIO_PRO. O recurso android.hardware.audio.pro é declarado.

  • MPC: Classe de desempenho de mídia

Encerrar novos requisitos

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • latência de rastreamento da cabeça. A hora em que usa o movimento da cabeça capturado pela unidade de medida de inércia (IMU, na sigla em inglês) nos transdutores dos fones de ouvido detecção da alteração no som causada esse movimento.

Encerrar novos requisitos

Se as implementações de dispositivos declararem android.hardware.audio.output, elas PRECISA atender ou exceder os seguintes requisitos:

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [C-1-1] O carimbo de data/hora da saída retornado por AudioTrack.getTimestamp (link em inglês) e AAudioStream_getTimestamp tem precisão de +/- 2 ms.

Encerrar novos requisitos

  • [C-1-2] Latência de saída frio de 500 milissegundos ou menos.

  • [C-1-3] É NECESSÁRIO abrir um stream de saída usando AAudioStreamBuilder_openStream() levar menos de 1.000 milissegundos.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [C-1-4] As latências de ida e volta calculadas com base na entrada e na saída os carimbos de data/hora retornados por AAudioStream_getTimestamp PRECISAM estar dentro de 200 ms de a latência de ida e volta medida para AAUDIO_PERFORMANCE_MODE_NONE e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY para alto-falantes com e sem fio fones de ouvido.

Encerrar novos requisitos

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Se as implementações de dispositivos declararem android.hardware.audio.output, elas serão É RECOMENDADO atender ou superar os seguintes requisitos:

  • [C-SR-1] Latência de saída fria de 100 milissegundos ou menos pelo alto-falante caminho dos dados.

  • [C-SR-2] Latência de toque para tom de 80 milissegundos ou menos.

  • [C-SR-4] As latências de ida e volta calculadas com base na entrada e na saída os carimbos de data/hora retornados por AAudioStream_getTimestamp são FORTEMENTE RECOMENDADOS esteja dentro de 30 ms da latência de ida e volta medida para AAUDIO_PERFORMANCE_MODE_NONE e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY para alto-falantes, fones de ouvido com e sem fio.

Encerrar novos requisitos

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Se as implementações de dispositivos atenderem aos requisitos acima, após qualquer calibração, ao usar a API de áudio nativo da AAudio, para saída contínua e a latência de saída fria em pelo menos um áudio com suporte dispositivo de saída, eles são:

Encerrar novos requisitos

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Se as implementações do dispositivo não atenderem aos requisitos de áudio de baixa latência via API de áudio nativa da AAudio, eles:

  • [C-2-1] NÃO É POSSÍVEL informar suporte para áudio de baixa latência.

Encerrar novos requisitos

Se as implementações de dispositivos incluírem android.hardware.microphone, elas PRECISA atender a estes requisitos de áudio de entrada:

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [C-3-1] Limite o erro nos carimbos de data/hora de entrada, conforme retornado por AudioRecord.getTimestamp (link em inglês) ou AAudioStream_getTimestamp, para +/- 2 ms. "Erro" aqui significa o desvio do valor correto.

Encerrar novos requisitos

  • [C-3-2] Latência de entrada a frio de 500 milissegundos ou menos.
  • [C-3-3] É NECESSÁRIO abrir um stream de entrada usando AAudioStreamBuilder_openStream() levar menos de 1.000 milissegundos.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Se as implementações de dispositivos incluírem android.hardware.microphone, elas serão É RECOMENDADO atender a estes requisitos de entrada de áudio:

  • [C-SR-8] Latência de entrada a frio de 100 milissegundos ou menos pelo microfone caminho dos dados.
  • [C-SR-11] Limite o erro nos carimbos de data/hora de entrada, conforme retornado por AudioRecord.getTimestamp (link em inglês) ou AAudioStream_getTimestamp, para +/- 1 ms.

Encerrar novos requisitos

Iniciar novos requisitos para a versão 15 (AOSP experimental)

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

  • [C-SR-12] É FORTEMENTE RECOMENDADO ter uma latência média contínua de ida e volta de 50 milissegundos ou menos em 5 medições, com um Desvio médio absoluto menos de 10 ms em pelo menos um caminho compatível.

Encerrar novos requisitos

Iniciar novos requisitos para a versão 15 (AOSP experimental)

A tabela a seguir define os requisitos de RTL para dispositivos portáteis implementações, conforme definido em 2.2.1, que declaram android.hardware.audio.output e android.hardware.microphone.

Dispositivo e declarações RTL (ms) MAD (ms) Caminhos de loopback
Filmagem manual 250 30 alto-falante/microfone, analógico de 3,5 mm (se compatível), USB (se compatível)
>= MPC_T (14) 80 15 pelo menos um caminho
RECURSO_ÁUDIO_BAIXO_LATÊNCIA 50 10 pelo menos um caminho
RECURSO_ÁUDIO_PRO 25 5 pelo menos um caminho
RECURSO_ÁUDIO_PRO 20 5 analógico (se compatível)
RECURSO_ÁUDIO_PRO 25 5 USB (se analógico não for compatível)

Encerrar novos requisitos

Iniciar novos requisitos para a versão 15 (AOSP experimental)

A tabela a seguir define os requisitos de TTL para dispositivos portáteis implementações, conforme definido em 2.2.1, que declaram android.hardware.audio.output e android.hardware.microphone.

Dispositivo e declarações TTL (ms)
Filmagem manual 250
>= MPC_T (14) 80
MPC_S (13) 100
RECURSO_ÁUDIO_PRO 80

Encerrar novos requisitos

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Se as implementações de dispositivos incluírem suporte para spatial audio com rastreamento da cabeça e declarar PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY ele:

  • [C-4-1] PRECISA exibir um rastreamento máximo da cabeça para a latência de atualização de áudio de 300 ms.

Encerrar novos requisitos

5,7. Protocolos de rede

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

Para cada codec e formato de contêiner que é necessária uma implementação de dispositivo suporte, a implementação do dispositivo:

  • [C-1-1] PRECISA oferecer suporte a esse codec ou contêiner por HTTP e HTTPS.

  • [C-1-2] PRECISA oferecer suporte aos formatos de segmento de mídia correspondentes, conforme mostrado em a tabela de formatos de segmento de mídia abaixo Protocolo de rascunho HTTP Live Streaming, versão 7.

  • [C-1-3] PRECISA oferecer suporte aos formatos de payload do RTSP correspondentes, como mostrado no tabela RTSP abaixo. Para exceções, consulte as notas de rodapé da tabela em seção 5.1.

Formatos de segmento de mídia

Formatos de segmentos Referências Compatibilidade necessária com o codec
Stream de transporte MPEG-2 ISO 13818 (link em inglês) Codecs de vídeo:
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
. Consulte a seção 5.1.8 para obter detalhes sobre H264 AVC, MPEG2-4 SP,
e MPEG-2.

Codecs de áudio:

  • AAC
. Consulte a seção 5.1.3 para saber detalhes sobre o AAC e as variantes dele.
AAC com enquadramento ADTS e tags ID3 ISO 13818-7 (link em inglês) Consulte a seção 5.1.1 para mais detalhes sobre o AAC e as variantes dele.
WebVTT WebVTT

RTSP (RTP, SDP)

Nome do perfil Referências Compatibilidade necessária com o codec
H264 AVC RFC 6184 (link em inglês) Consulte a seção 5.1.8 para detalhes sobre o H264 AVC
MP4A-LATM RFC 6416 (em inglês) Consulte a seção 5.1.3 para mais detalhes sobre o AAC e as variantes dele.
H263-1998 RFC 3551
(link em inglês) RFC 4629
(link em inglês) RFC 2190
Consulte a seção 5.1.8 para saber mais sobre o H263
T263-2000 RFC 4629 (link em inglês) Consulte a seção 5.1.8 para saber mais sobre o H263
AMR RFC 4867 (link em inglês) Consulte a seção 5.1.3 para detalhes sobre o AMR-NB
AMR-WB RFC 4867 (link em inglês) Consulte a seção 5.1.3 para mais detalhes sobre o AMR-WB.
MP4V-ES RFC 6416 (em inglês) Consulte a seção 5.1.8 para mais detalhes sobre o MPEG-4 SP,
mpeg4-genérico RFC 3640 (em inglês) Consulte a seção 5.1.3 para mais detalhes sobre o AAC e as variantes dele.
MP2T RFC 2250 (link em inglês) Consulte a seção Fluxo de transporte MPEG-2 abaixo da HTTP Live Streaming para mais detalhes.

5,8. Mídia segura

Se as implementações de dispositivos oferecerem suporte a saída de vídeo segura e forem capazes de oferecendo suporte a superfícies seguras, elas:

  • [C-1-1] PRECISA declarar compatibilidade com Display.FLAG_SECURE.

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

  • [C-2-1] PRECISA proteger o link com um mecanismo com criptografia forte, como como HDCP 2.x ou superior para telas conectadas por meio de protocolos sem fio. como o Miracast.

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

  • [C-3-1] PRECISA oferecer suporte a HDCP 1.2 ou mais recente para todas as telas externas conectadas. por uma porta com fio acessível ao usuário.

5,9. Interface digital para instrumentos musicais (MIDI)

Se as implementações de dispositivos relatarem compatibilidade com o recurso android.software.midi por meio do android.content.pm.PackageManager , ela:

  • [C-1-1] PRECISA oferecer suporte a MIDI em todos os transportes de hardware compatíveis com MIDI para que fornecem conectividade genérica não MIDI, em que esses transportes são:

  • [C-1-2] PRECISA oferecer suporte ao transporte de software MIDI entre apps. (dispositivos MIDI virtuais)

  • [C-1-3] PRECISA incluir libamidi.so (suporte a MIDI nativo)

  • DEVE oferecer suporte a MIDI sobre o modo de periférico USB, seção 7.7

5,10 Áudio profissional

Se as implementações de dispositivos relatarem compatibilidade com o recurso android.hardware.audio.pro pelo android.content.pm.PackageManager , ela:

  • [C-1-1] PRECISA relatar a compatibilidade com o recurso. android.hardware.audio.low_latency:

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [C-1-2] PRECISA ter o áudio de ida e volta contínuo latência, atender à latência requisitos para FEATURE_AUDIO_PRO, conforme definido na seção 5.6 Latência de áudio de 25 milissegundos ou menos em pelo menos um caminho.

Encerrar novos requisitos

  • [C-1-3] PRECISA incluir portas USB compatíveis com o modo host USB e USB modo periférico.
  • [C-1-4] PRECISA relatar a compatibilidade com o recurso android.software.midi.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [C-1-5] PRECISA cumprir os requisitos latências e áudio USB requisitos de latência usando o Áudio nativo AAudio e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.

Encerrar novos requisitos

  • [C-1-6] PRECISA ter latência de saída de frio de 200 milissegundos ou menos.
  • [C-1-7] PRECISA ter latência de entrada a frio de 200 milissegundos ou menos.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [C-1-8] PRECISA ter uma latência média entre toques e tons de 80 milissegundos ou menos. em pelo menos cinco medições do alto-falante para o caminho de dados do microfone.
  • [C-SR-1] É FORTEMENTE RECOMENDADO para atender às latências definidas na seção 5,6 Latência de áudio, de 20 milissegundos ou menor que 5 medições com desvio absoluto médio menor que 5 milésimos de segundo entre o alto-falante e o microfone.
  • [C-SR-2] É FORTEMENTE RECOMENDADO a atender aos requisitos de áudio profissional para: latência de áudio de ida e volta contínua, latência de entrada a frio e saída de frio latência e requisitos de áudio USB usando a API de áudio nativo da AAudio no caminho do MMAP.
  • [C-SR-3] É FORTEMENTE RECOMENDADO para fornecer um nível consistente de CPU desempenho enquanto o áudio está ativo e a carga da CPU varia. Isso deve ser testado usando o app Android SynthMark. O SynthMark usa um sintetizador de software executado em um framework de áudio simulado que mede o desempenho do sistema. Consulte a Documentação do SynthMark para conferir uma explicação sobre os comparativos de mercado. SynthMark precisa ser executado usando o "Teste automatizado" e obter os seguintes resultados:

    • Voicemark.90 >= 32 vozes
    • latênciamark.Fixed.little <= 15 ms
    • latênciamark.dynamic.little <= 50 ms
  • DEVE minimizar a imprecisão e o desvio do relógio de áudio em relação ao horário padrão.

  • DEVE minimizar a variação do relógio de áudio em relação à CPU CLOCK_MONOTONIC quando ambos estão ativos.

  • DEVE minimizar a latência de áudio em transdutores no dispositivo.

  • DEVE minimizar a latência de áudio no áudio digital USB.

  • DEVE documentar as medições de latência de áudio em todos os caminhos.

  • DEVE minimizar a instabilidade nos tempos de entrada de callback para conclusão do buffer de áudio, já que esse afeta a porcentagem utilizável da largura de banda total da CPU pelo callback.

  • DEVE fornecer zero falhas de áudio em condições normais de uso na latência relatada.

  • DEVE fornecer zero diferença de latência entre os canais.

  • DEVE minimizar a latência média de MIDI em todos os transportes.

  • DEVE minimizar a variabilidade de latência MIDI sob carga (instabilidade) 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 do dispositivo, incluindo os 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 do endpoints correspondentes, quando ambos estão ativos. Exemplos de respostas os endpoints incluem o microfone e o alto-falante do dispositivo ou a entrada de entrada de áudio e saída.

  • DEVE lidar com callbacks de conclusão do buffer de áudio para os lados de entrada e saída de endpoints correspondentes no mesmo encadeamento quando ambos estiverem ativos, e inserir o callback de saída imediatamente após o retorno do callback de entrada. Ou se não for viável lidar com os retornos de chamada no mesmo thread, insira o de saída logo após inserir o retorno de chamada para permitir que o tenha um tempo consistente entre os lados de entrada e saída.

  • DEVE minimizar a diferença de fase entre o buffer de áudio HAL para a entrada e lados de saída dos endpoints correspondentes.

  • DEVE minimizar a latência de toque.

  • DEVE minimizar a variabilidade da latência de toque sob carga (instabilidade).

Encerrar novos requisitos

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Se as implementações de dispositivos atenderem a todos os requisitos acima, elas:

Encerrar novos requisitos

Se as implementações do dispositivo incluírem uma entrada para fone de ouvido de 3,5 mm com quatro condutores, elas:

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [C-2-1] PRECISA ter uma latência média contínua de áudio de ida e volta, conforme definido em seção 5.6 Latência de áudio, de 20 milissegundos ou menos, mais de 5 medições com desvio absoluto médio inferior a 5 milissegundos o caminho da entrada de áudio usando uma Dongle de loopback de áudio.

Encerrar novos requisitos

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Encerrar novos requisitos

Se as implementações do dispositivo omitirem uma entrada de áudio de 3,5 mm com 4 condutores e incluem portas USB compatíveis com o modo host USB, elas:

  • [C-3-1] PRECISA implementar a classe de áudio USB.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [C-3-2] PRECISA ter uma latência média contínua de áudio de ida e volta de 25 milissegundos ou menos, mais de 5 medições com desvio absoluto médio menos de 5 milissegundos pela porta do modo host USB usando a classe de áudio USB. (Isso pode ser medido com o uso de um adaptador USB-3,5 mm e um loopback de áudio ou uma interface de áudio USB com cabos patch para conectar entradas para saídas).
  • [C-SR-6] É FORTEMENTE RECOMENDADO para oferecer suporte a E/S simultâneas com até oito canais em cada direção, taxa de amostragem de 96 kHz e profundidade de 24 ou 32 bits, quando usadas com periféricos de áudio USB que também atendem a esses requisitos.
  • [C-SR-7] É FORTEMENTE RECOMENDADO para atender a esse grupo de requisitos usando a API de áudio nativa da AAudio no caminho do MMAP.

Encerrar novos requisitos

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Se as implementações de dispositivos incluírem uma porta HDMI, elas:

  • DEVE oferecer suporte à saída em estéreo e oito canais em 20 bits ou 24 bits de profundidade e 192 kHz sem perda ou reamostragem de profundidade de bits em pelo menos uma configuração.

Encerrar novos requisitos

5,11. Capturar para não processados

O Android inclui suporte à gravação de áudio não processado pelo Fonte de áudio android.media.MediaRecorder.AudioSource.UNPROCESSED. Em OpenSL ES, pode ser acessado com a predefinição de gravação SL_ANDROID_RECORDING_PRESET_UNPROCESSED:

Se o dispositivo tiver a intenção de oferecer suporte a fontes de áudio não processadas e tornar para que ele seja disponibilizado para apps de terceiros, eles:

  • [C-1-1] PRECISA informar o suporte pelo android.media.AudioManager. propriedade PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

  • [C-1-2] PRECISA exibir aproximadamente amplitude em relação à frequência plana características na faixa média de frequência: especificamente ±10 dB do 100 Hz a 7.000 Hz para cada microfone usado para gravar os áudios não processados fonte de áudio.

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

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

  • [C-1-5] PRECISA definir a sensibilidade da entrada de áudio de forma que uma frequência sinusoidal de 1.000 Hz fonte de tons reproduzida a um nível de pressão sonora (SPL, na sigla em inglês) de 94 dB gera uma resposta com RMS de 520 para amostras de 16 bits (ou escala total de -36 dB para ponto flutuante/duplo amostras de precisão) para cada microfone usado para gravar os fonte de áudio.

  • [C-1-6] PRECISA ter uma relação sinal-ruído (SNR, na sigla em inglês) em 60 dB ou maior por de cada microfone usado para gravar a fonte de áudio não processada. (enquanto o SNR é medido como a diferença entre SPL de 94 dB e equivalente SPL do ruído próprio, ponderado por A).

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

  • [C-1-8] NÃO PODE ter nenhum outro processamento de sinal (por exemplo, ganho automático) Controle, filtro de passagem alta ou cancelamento de eco) no caminho que não seja um multiplicador de nível para alcançar o intervalo desejado. Resumindo:

    • [C-1-9] Se houver algum processamento de sinal na arquitetura motivo, ele PRECISA ser desativado e introduzir efetivamente nenhum atraso ou latência extra para o caminho do indicador.
    • [C-1-10] O multiplicador de nível, embora esteja no caminho, NÃO PODE SER 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. No caso de várias configurações de microfone, estes requisitos se aplicam a: cada microfone.

Se as implementações de dispositivo declararem android.hardware.microphone, mas não dão suporte a fontes de áudio não processadas, elas:

  • [C-2-1] PRECISA retornar null para AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED). método da API, para indicar corretamente a falta de suporte.
  • [C-SR-1] ainda é FORTEMENTE RECOMENDADO para atender ao maior número possível dos requisitos para o caminho do sinal da origem de gravação não processada.

5,12. Vídeo HDR

O Android 13 é compatível com as tecnologias HDR, conforme descrito em um documento a seguir.

Formato pixel

Se um decodificador de vídeo anunciar compatibilidade com COLOR_FormatYUVP010:

  • [C-1-1] PRECISA oferecer suporte ao formato P010 para leitura de CPU (ImageReader, MediaImage, ByteBuffer). No Android 13, o P010 é relaxado para permitir uma passada arbitrária para o Y. e UVs.

  • [C-1-2] O buffer de saída P010 PRECISA poder ser amostrado pela GPU (quando alocada com uso de GPU_SAMPLING). Isso permite a composição de GPUs e a personalização e o mapeamento de tons por apps.

Se um decodificador de vídeo anunciar compatibilidade com COLOR_Format32bitABGR2101010, ele:

  • [C-2-1] PRECISA oferecer suporte ao formato RGBA_1010102 para a superfície de saída e Legível pela CPU (saída do ByteBuffer).

Se um codificador de vídeo anunciar compatibilidade com COLOR_FormatYUVP010, ele:

  • [C-3-1] PRECISA oferecer suporte ao formato P010 para superfície de entrada e gravação de CPU. (ImageWriter, MediaImage, ByteBuffer).
.

Se um codificador de vídeo anunciar compatibilidade com COLOR_Format32bitABGR2101010, ele:

  • [C-4-1] PRECISA oferecer suporte ao formato RGBA_1010102 para a superfície de entrada e a capacidade de gravação da CPU. (ImageWriter, ByteBuffer). Observação: a conversão entre várias curvas NÃO são necessárias para codificadores.

Requisitos de captura HDR

Para todos os codificadores de vídeo compatíveis com perfis HDR, as implementações de dispositivos:

  • [C-5-1] NÃO PODE presumir que os metadados HDR são precisos. Por exemplo, o um frame codificado pode ter pixels além do nível máximo de luminância, ou histograma pode não ser representativo do frame.

  • DEVE agregar metadados dinâmicos em HDR para gerar estática HDR apropriada metadados para streams codificados, que devem ser gerados no final de cada de codificador-decodificador.

Se as implementações de dispositivos oferecerem suporte à captura HDR usando as APIs CamcorderProfile então eles:

  • [C-6-1] também PRECISA oferecer suporte à captura HDR com as APIs Camera2.

  • [C-6-2] PRECISA oferecer suporte a pelo menos um codificador de vídeo acelerado por hardware no todas as tecnologias HDR com suporte.

  • [C-6-3] PRECISA oferecer suporte, no mínimo, à captura de HLG.

  • [C-6-4] PRECISA oferecer suporte à gravação de metadados HDR (se aplicável para HDR no arquivo de vídeo capturado. Para AV1, HEVC e DolbyVision isso significa incluir os metadados no bitstream codificado.

  • [C-6-5] PRECISA oferecer suporte a P010 e COLOR_FormatYUVP010.

  • [C-6-6] PRECISA oferecer suporte ao mapeamento de tons HDR para SDR por padrão com aceleração de hardware para o perfil capturado. Em outras palavras, Se um dispositivo puder capturar HDR10+ HEVC, o decodificador HEVC padrão DEVE ser capaz de para decodificar o stream capturado em SDR.

Requisitos de edição de HDR

Se as implementações de dispositivos incluírem codificadores de vídeo compatíveis com a edição HDR, eles:

  • DEVE usar latência mínima para gerar os metadados HDR quando ausentes, e DEVEM lidar com situações em que os metadados estão presentes para alguns e não para outros. Esses metadados DEVEM ser precisos (por exemplo, representam o pico de luminância real e o histograma do quadro).

Se a implementação do dispositivo incluir codecs compatíveis com FEATURE_HdrEditing, codecs:

  • [C-7-1] PRECISA oferecer suporte a pelo menos um perfil HDR.

  • [C-7-2] PRECISA oferecer suporte a FEATURE_HdrEditing em todos os perfis HDR anunciados por esse codec. Em outras palavras, eles PRECISAM oferecer suporte à geração de metadados HDR quando não está presente em todos os perfis HDR com suporte e que usam metadados HDR.

  • [C-7-3] PRECISA oferecer suporte aos seguintes formatos de entrada do codificador de vídeo que completam preservar o sinal decodificado em HDR:

    • RGBA_1010102 (já está na curva de transferência de destino) para as duas entradas e o ByteBuffer e PRECISA anunciar o suporte para COLOR_Format32bitABGR2101010.

Se a implementação do dispositivo incluir codecs compatíveis com FEATURE_HdrEditing, dispositivo:

  • [C-7-4] É NECESSÁRIO anunciar o suporte à extensão OpenGL EXT_YUV_target.

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

6.1. Ferramentas para desenvolvedores

Implementações de dispositivos:

  • [C-0-1] PRECISA ser compatível com as Ferramentas para Desenvolvedores do Android fornecidas na SDK do Vertex AI Pipelines.
  • Android Debug Bridge (adb)

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [C-0-2] PRECISA oferecer suporte ao adb, conforme documentado no SDK do Android e no shell fornecidos no AOSP, que podem ser usados por desenvolvedores de apps, incluindo dumpsys, cmd statse Simpleperf.

Encerrar novos requisitos

  • [C-0-11] PRECISA oferecer suporte ao comando shell cmd testharness. Fazendo upgrade implementações de dispositivos de uma versão anterior do Android sem uma um bloco de dados persistente pode ser isento de C-0-11.
  • [C-0-3] NÃO PODE alterar o formato ou o conteúdo do sistema do dispositivo eventos (bateriastats, discostats, impressão digital, Graphstats, netstats, notificação, procstats) registrados pelo comando dumpsys.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [C-0-10] PRECISA gravar, sem omissão, e fazer os seguintes eventos acessível e disponível para o comando shell do cmd stats e o StatsManager Classe da API do sistema.
    • ActivityForegroundStateChanged
    • Anomalia detectada
    • AppBreadcrumbReported
    • Ocorreram AppCrash
    • O AppStart ocorreu
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • CobrançaStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • InputDeviceUsageReported
    • JobStateChanged
    • KeyConfigured (em inglês)
    • TecladoSystemsEventReported
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • Uso do touchpad
    • UidProcessStateChanged
    • WakelockStateChanged
    • Alarme de ativação ocorreu
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged

Encerrar novos requisitos

  • [C-0-4] PRECISA fazer com que o daemon do adb do lado do dispositivo fique inativo por padrão e É NECESSÁRIO haver um mecanismo acessível ao usuário para ativar o Android Debug Ponte
  • [C-0-5] PRECISA oferecer suporte ao adb seguro. O Android inclui suporte a chamadas adb: O adb seguro permite o uso do adb em hosts autenticados conhecidos.
  • [C-0-6] PRECISA fornecer um mecanismo que permita a conexão do adb de uma máquina host. Especificamente:

Se as implementações de dispositivos sem porta USB forem compatíveis com o modo periférico, elas:

  • [C-3-1] PRECISA implementar o adb via rede de área local (como ou Wi-Fi).
  • [C-3-2] PRECISA fornecer drivers para Windows 7, 8 e 10, permitindo que os desenvolvedores se conectem ao dispositivo usando o protocolo adb.

Se as implementações de dispositivos oferecerem suporte a conexões adb com uma máquina host via Wi-Fi ou Ethernet, eles:

  • [C-4-1] PRECISA ter o método AdbManager#isAdbWifiSupported(). retornar true.

Se as implementações de dispositivos oferecerem suporte a conexões adb com uma máquina host via Wi-Fi ou Ethernet inclui pelo menos uma câmera, eles:

  • [C-5-1] PRECISA ter o método AdbManager#isAdbWifiQrSupported(). retornar true.

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

    • [C-0-7] PRECISA oferecer suporte a todos os recursos de ddms, conforme documentado no SDK do Android. Como o ddms usa adb, o suporte para ddms DEVE estar inativo por padrão, mas DEVE ser suportado sempre que o usuário ativar o Android Debug Bridge. acima.
  • SysTrace (em inglês)

    • [C-0-9] PRECISA oferecer suporte à ferramenta Systrace, conforme documentado no SDK do Android. O Systrace precisa estar inativo por padrão e PRECISA haver uma instância acessível ao usuário para ativar o Systrace.
  • Perfetto (link em inglês)

    • [C-SR-1] É FORTEMENTE RECOMENDADO expor um /system/bin/perfetto binário para o usuário do shell com o qual o cmdline obedece a documentação do perfetto (link em inglês).
    • [C-SR-2] O binário do perfetto é FORTEMENTE RECOMENDADO para aceitar como entrada uma protobuf que está em conformidade com o esquema definido em a documentação do perfetto (link em inglês).
    • [C-SR-3] O binário do perfetto é MUITO RECOMENDADO para escrever como saída uma rastro protobuf que esteja em conformidade com o esquema definido em a documentação do perfetto (link em inglês).
    • [C-SR-4] É MUITO RECOMENDADO fornecer, pelo binário perfetto, Pelo menos as fontes de dados descritas na documentação do Perfeito.
  • Baixa memória assassina

    • [C-0-12] É NECESSÁRIO gravar um Atom LMK_KILL_OCCURRED_FIELD_NUMBER no Status do registro quando um app é encerrado pelo Low Memory Killer.
  • Modo arcabouço de testes Se as implementações de dispositivos oferecerem suporte ao comando shell cmd testharness e executar cmd testharness enable, eles:

  • Informações de trabalho da GPU

    Implementações de dispositivos:

    • [C-0-13] É NECESSÁRIO implementar o comando shell dumpsys gpu --gpuwork para exibir os dados de trabalho agregados da GPU retornados pelo kernel power/gpu_work_period tracepoint ou não exibirá dados se o tracepoint não for compatível. O AOSP implementação é frameworks/native/services/gpuservice/gpuwork/.

Se as implementações do dispositivo informarem o suporte ao Vulkan 1.0 ou mais recente pelo android.hardware.vulkan.version:

  • [C-1-1] PRECISA fornecer uma affordance para o desenvolvedor do app ativar/desativar. Camadas de depuração da GPU.
  • [C-1-2] PRECISA, quando as camadas de depuração de GPU estiverem ativadas, enumerar as camadas bibliotecas fornecidas por ferramentas externas (ou seja, não fazem parte da plataforma ou pacote de aplicativos) encontrados nos aplicativos depuráveis diretório base para Suporte a vkEnumerateInstanceLayerProperties() e vkCreateInstance() métodos da API.

6.2. Opções do desenvolvedor

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

As implementações de dispositivos PRECISAM fornecer uma experiência consistente para As opções do desenvolvedor:

  • [C-0-1] PRECISA respeitar android.settings.APPLICATION_DEVELOPMENT_CONFIG para mostrar as configurações relacionadas ao desenvolvimento de aplicativos. O sistema upstream do Android oculta o menu "Opções do desenvolvedor" por padrão e permite que os usuários Abra as "Opções do desenvolvedor" depois de pressionar sete (7) vezes em Configurações > Sobre o dispositivo > Número da versão.
  • [C-0-2] É NECESSÁRIO ocultar as Opções do desenvolvedor por padrão.
  • [C-0-3] PRECISA fornecer um mecanismo claro que não dê prioridade tratamento a um app de terceiros em vez de outro para permitir que o desenvolvedor Opções. PRECISA fornecer um documento ou site público visível que descreva como ativar as Opções do desenvolvedor. Este documento ou site PRECISA estar disponível para um link documentos do SDK do Android.
  • DEVE manter uma notificação visual contínua para o usuário quando o Desenvolvedor As opções estão ativadas, e a segurança do usuário é uma preocupação.
  • PODE limitar temporariamente o acesso ao menu Developer Options, visualmente ocultar ou desativar o menu, para evitar distrações em cenários em que o a segurança do usuário é uma preocupação.

7. Compatibilidade de hardware

Se um dispositivo incluir um componente de hardware específico que tenha um API para desenvolvedores terceirizados:

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

Se uma API no SDK interage com um componente de hardware declarado como opcional e o A implementação de dispositivo não tem esse componente:

  • [C-0-2] Definições de classe completas (conforme documentado pelo SDK) para o componente As APIs PRECISAM ser apresentadas.
  • [C-0-3] Os comportamentos da API PRECISAM ser implementados como ambiente autônomo em alguns casos de maneira
  • [C-0-4] Os métodos da API PRECISAM retornar valores nulos quando permitido pelo SDK na documentação do Google Cloud.
  • [C-0-5] Os métodos da API PRECISAM retornar implementações de ambiente autônomo 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 pelo SDK na documentação do Google Cloud.
  • [C-0-7] As implementações de dispositivos PRECISAM informar de forma consistente o hardware preciso de configuração do Terraform com as APIs getSystemAvailableFeatures() e métodos hasSystemFeature(String) no android.content.pm.PackageManager (link em inglês) para a mesma impressão digital do build.

Um exemplo típico de cenário em que esses requisitos se aplicam é a API: mesmo em aparelhos que não sejam telefones, essas APIs devem ser implementadas o quanto antes ambiente autônomo.

7.1. Tela e gráficos

O Android inclui instalações que ajustam automaticamente os recursos do aplicativo e da interface layouts adequados para o dispositivo, a fim de garantir que os aplicativos de terceiros funcionam bem em diversas telas e configurações de hardware. Um Uma tela compatível com Android é uma tela que implementa todos os comportamentos e APIs descritos em Desenvolvedores Android - Compatibilidade de tela geral, este (7.1) e suas subseções, assim como qualquer tipo de dispositivo adicional comportamentos específicos documentados na seção 2 deste CDD.

Implementações de dispositivos:

  • [C-0-1] PRECISA, por padrão, renderizar aplicativos de terceiros apenas em Telas compatíveis com Android.

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

  • tamanho diagonal físico. A distância em polegadas entre dois opostos. cantos da parte iluminada da tela.
  • densidade. O número de pixels abrangidos por uma linha extensão horizontal ou vertical de 1", expresso em pixels por polegada (ppi ou dpi). Com os valores ppi e dpi listados, os dpi horizontal e vertical precisam estar dentro do intervalo listado.
  • proporção. A proporção entre os pixels da dimensão maior e a menor dimensão da tela. Por exemplo, uma tela de 480 x 854 pixels ser 854/480 = 1,779, ou aproximadamente "16:9".
  • pixel de densidade independente (dp, na sigla em inglês). Uma unidade de pixel virtual normalizada para uma densidade de tela de 160. Para alguns d de densidade, e um número de pixels p, o número de pixels de densidade independente dp, é calculado como: dp = (160 / d) * p.

7.1.1. Configuração da tela

7.1.1.1 Tamanho e forma da tela

O framework de interface do Android é compatível com diversos layouts de tela lógicos diferentes. e permite que os aplicativos consultem a tela da configuração atual tamanho do layout usando Configuration.screenLayout com o SCREENLAYOUT_SIZE_MASK e Configuration.smallestScreenWidthDp.

Implementações de dispositivos:

  • [C-0-1] PRECISA informar o tamanho correto do layout do Configuration.screenLayout, conforme definido na documentação do SDK do Android. Especificamente, as implementações de dispositivos PRECISAM informar a lógica correta dimensões da tela em pixels de densidade independente (dp, na sigla em inglês), conforme abaixo:

    • Dispositivos com o Configuration.uiMode definido como qualquer valor diferente UI_MODE_TYPE_WATCH, e informar um tamanho de small para o Configuration.screenLayout PRECISA ter pelo menos 426 dp x 320 dp.
    • Dispositivos informando um tamanho de normal para o dispositivo Configuration.screenLayout, PRECISA ter pelo menos 480 dp x 320 dp.
    • Dispositivos informando um tamanho de large para o dispositivo Configuration.screenLayout, PRECISA ter pelo menos 640 dp x 480 dp.
    • Dispositivos informando um tamanho de xlarge para o dispositivo Configuration.screenLayout, PRECISA ter pelo menos 960 dp x 720 dp.
  • [C-0-2] PRECISA respeitar as inscrições corretamente. afirmaram suporte a tamanhos de tela por meio do <supports-screens> no AndroidManifest.xml, conforme descrito na documentação do SDK do Android.

  • PODE ter telas compatíveis com Android com cantos arredondados.

Se as implementações de dispositivos suportarem telas capazes de Configuração de tamanho UI_MODE_TYPE_NORMAL e usar telas físicas com cantos arredondados para renderizar essas telas, eles:

  • [C-1-1] PRECISA garantir que pelo menos um dos requisitos a seguir é atendida para cada uma dessas telas:

    • O raio dos cantos arredondados será menor ou igual a 38 dp.
    • Quando uma caixa de 18 dp por 18 dp está ancorada em cada canto da linha pelo menos um pixel de cada caixa ficará visível na tela.
  • DEVE incluir affordance do usuário para alternar para o modo de exibição com o cantos retangulares.

Se as implementações de dispositivos só puderem usar a configuração de teclado NO_KEYS, e pretende relatar a compatibilidade com o modo de interface UI_MODE_TYPE_NORMAL da configuração, eles:

  • [C-4-1] PRECISA ter um tamanho de layout de pelo menos os cortes da tela, excluindo os cortes da tela 596 dp x 384 dp ou superior.

Para detalhes sobre como implementar corretamente o arquivo secundário ou as APIs de extensão, consulte à documentação pública do Gerenciador de janelas do Jetpack.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Se as implementações de dispositivos incluem uma ou mais áreas de exibição compatíveis com o Android que sejam dobráveis ou que incluam uma articulação dobrável entre várias áreas de painel de exibição compatíveis com Android e disponibilize essas áreas para aplicativos, elas:

  • [C-4-1] PRECISA implementar a versão correta das extensões do Windows Manager. Nível da API, conforme descrito em Extensões do WindowManager.

Encerrar novos requisitos

7.1.1.2 Proporção da tela

Esta seção foi excluída no Android 14.

7.1.1.3 Densidade da tela

O framework da interface do Android define um conjunto de densidades lógicas padrão para ajudar desenvolvedores de aplicativos visam recursos de aplicativos.

Implementações dos dispositivos:

  • [C-0-1] PRECISA informar uma das densidades de framework do Android listadas em DisplayMetrics usando a API DENSITY_DEVICE_STABLE e esse valor precisa ser estático para cada tela física. No entanto, o dispositivo PODE informar um DisplayMetrics.density diferente de acordo com as alterações de configuração da tela feitas pelo usuário (por exemplo, tamanho de exibição) definido após a primeira inicialização.

  • DEVE definir a densidade padrão da estrutura Android que é numericamente mais próximo da densidade física da tela, ou um valor que seria mapeado para mesmas medidas equivalentes de campo de visão angular de um dispositivo portátil.

Se as implementações de dispositivos oferecem uma affordance para mudar o tamanho de exibição do dispositivo, elas:

  • [C-1-1] NÃO PODE dimensionar a tela mais do que 1,5 vez DENSITY_DEVICE_STABLE ou produzir uma dimensão mínima efetiva da tela menor que 320 dp (equivalente para o qualificador de recurso sw320dp), o que ocorrer primeiro.
  • [C-1-2] NÃO PODE dimensionar a tela menor que 0,85 vezes o valor de DENSITY_DEVICE_STABLE.
  • Para garantir uma boa usabilidade e tamanhos de fonte consistentes, é RECOMENDADO que o seguinte escala de opções de exibição nativa (em conformidade com os limites especificado acima)
    • Pequeno: 0,85x
    • Padrão: 1x (escala de display nativa)
    • Grande: 1,15x
    • Maior: 1,3x
    • Maior 1,45x

7.1.2. Métricas de display

Se as implementações do dispositivo incluem telas compatíveis com Android ou de vídeo para as telas compatíveis com o Android, eles:

  • [C-1-1] É NECESSÁRIO informar os valores corretos para todas as telas compatíveis com o Android métricas definidas no API android.util.DisplayMetrics.

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

  • [C-2-1] PRECISA informar os valores corretos de tela compatível com Android conforme definido 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] PRECISA informar quais orientações de tela são compatíveis (android.hardware.screen.portrait e/ou android.hardware.screen.landscape) e PRECISA informar pelo menos um orientação. Por exemplo, um dispositivo com orientação de paisagem fixa telas, como uma televisão ou um laptop, só DEVE denunciar android.hardware.screen.landscape.
  • [C-0-2] PRECISA informar o valor correto da configuração atual do dispositivo orientação sempre que consultado pelo android.content.res.Configuration.orientation, android.view.Display.getOrientation() ou outras APIs.

Se as implementações de dispositivos forem compatíveis com as duas orientações de tela, elas:

  • [C-1-1] PRECISA oferecer suporte à orientação dinâmica dos aplicativos nas telas retrato ou paisagem. orientação. Ou seja, o dispositivo precisa respeitar a solicitação do aplicativo para uma tela específica. orientação.
  • [C-1-2] NÃO PODE mudar o tamanho ou a densidade da tela informada ao mudar a orientação.
  • 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] PRECISA identificar corretamente as versões compatíveis do OpenGL ES (1.1, 2.0, 3.0, 3.1, 3.2) por meio das APIs gerenciadas (como pela GLES10.getString()) e as APIs nativas.
  • [C-0-2] PRECISA incluir suporte para todas as APIs gerenciadas correspondentes. APIs nativas para cada versão do OpenGL ES que ela identificou ter suporte.

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

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Encerrar novos requisitos

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [C-SR-1] É FORTEMENTE RECOMENDADO para oferecer suporte ao OpenGL ES 3.1.

Encerrar novos requisitos

  • DEVE oferecer suporte a OpenGL ES 3.2.

Os testes dEQP do OpenGL ES são particionados em várias listas de teste, cada uma com um número de data/versão associado. Eles estão na árvore de origem do Android em external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt: Um dispositivo que oferece suporte ao OpenGL ES em um nível autoinformado indica que pode passar o dEQP testes em todas as listas de teste deste nível e anteriores.

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

  • [C-2-1] PRECISA gerar relatórios pelas APIs gerenciadas do OpenGL ES e APIs nativas outras extensões do OpenGL ES que tenham implementado e, por outro lado, PRECISAM NOT as strings de extensão de relatório incompatíveis.
  • [C-2-2] PRECISA oferecer suporte a 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, EGL_ANDROID_recordable e EGL_ANDROID_GLES_layers.
  • [C-2-3] PRECISA informar a versão máxima dos testes de dEQP do OpenGL ES com suporte pela flag de recurso android.software.opengles.deqp.level.
  • [C-2-4] PRECISA ser compatível pelo menos com a versão 132383489 (a partir de 1o de março de 2020), como informados na flag de recurso android.software.opengles.deqp.level.
  • [C-2-5] PRECISA passar em todos os testes dEQP do OpenGL ES nas listas de teste entre as versões 132383489 e a versão especificada no Sinalização de recurso android.software.opengles.deqp.level, para cada com suporte Versão do OpenGL ES.
  • [C-SR-2] É FORTEMENTE RECOMENDADO para oferecer suporte a EGL_KHR_partial_update e OES_EGL_image_external extensão.
  • DEVE informar com precisão usando o método getString(), qualquer textura formato de compactação compatível, que costuma ser específico do fornecedor.

  • DEVE oferecer suporte aos EGL_IMG_context_priority e EGL_EXT_protected_content extensão.

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

  • [C-3-1] PRECISA exportar os símbolos de função correspondentes para essa versão além dos símbolos de função do OpenGL ES 2.0 na biblioteca libGLESv2.so.
  • [C-SR-3] É FORTEMENTE RECOMENDADO para oferecer suporte a OES_EGL_image_external_essl3 .

Se as implementações de dispositivos forem compatíveis com o OpenGL ES 3.2, elas:

  • [C-4-1] PRECISA ser compatível com o pacote de extensão OpenGL ES para Android na íntegra.

Se as implementações de dispositivos oferecerem suporte ao Pacote de extensões para Android (link em inglês) do OpenGL ES na própria integralmente, eles:

  • [C-5-1] PRECISA identificar o suporte pelo android.hardware.opengles.aep. flag de recurso.

Se as implementações do dispositivo exporem suporte para EGL_KHR_mutable_render_buffer , eles:

  • [C-6-1] também PRECISA oferecer suporte a EGL_ANDROID_front_buffer_auto_refresh. .
7.1.4.2. Vulkan

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

Se as implementações de dispositivos forem compatíveis com o OpenGL ES 3.1, elas:

  • [C-SR-1] É FORTEMENTE RECOMENDADO a inclusão de suporte para Vulkan 1.3
  • [C-4-1] NÃO PODE oferecer suporte a uma versão de variante do Vulkan (ou seja, a variante parte da versão principal do Vulkan PRECISA ser zero).

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

  • [C-SR-2] É FORTEMENTE RECOMENDADO a inclusão de suporte para Vulkan 1.3

Os testes dEQP do Vulkan são particionados em várias listas de teste, cada uma com um a data/versão associada. Eles estão na árvore de origem do Android em external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt: Um dispositivo que oferece suporte ao Vulkan em um nível autoinformado indica que ele pode passar o dEQP testes em todas as listas de teste deste nível e anteriores.

Se as implementações de dispositivos incluírem suporte ao Vulkan, elas:

  • [C-1-1] PRECISA informar o valor inteiro correto com a android.hardware.vulkan.level e android.hardware.vulkan.version flags de recursos.
  • [C-1-2] PRECISA enumerar pelo menos um VkPhysicalDevice para o Vulkan. API nativa vkEnumeratePhysicalDevices().
  • [C-1-3] PRECISA implementar totalmente as APIs do Vulkan 1.1 para cada VkPhysicalDevice:
  • [C-1-4] PRECISA enumerar as camadas, contidas em bibliotecas nativas chamadas como libVkLayer*.so no diretório da biblioteca nativa do pacote do app. usando as APIs nativas do Vulkan vkEnumerateInstanceLayerProperties() e vkEnumerateDeviceLayerProperties().
  • [C-1-5] NÃO PODE enumerar as camadas fornecidas por bibliotecas fora do pacote de aplicativos da Web ou fornecer outras formas de rastrear ou interceptar os API do Vulkan, a menos que o aplicativo tenha o atributo android:debuggable definido como true ou os metadados com.android.graphics.injectLayers.enable Defina como true.
  • [C-1-6] PRECISA informar todas as strings de extensão com suporte pelo método APIs nativas do Vulkan e, por outro lado, NÃO PODEM informar strings de extensão que não são compatíveis.
  • [C-1-7] PRECISA oferecer suporte a VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, e VK_KHR_incremental_present.
  • [C-1-8] PRECISA informar a versão máxima dos testes de dEQP do Vulkan com suporte pela flag de recurso android.software.vulkan.deqp.level.
  • [C-1-9] PRECISA ser compatível com a versão 132317953 (a partir de 1o de março de 2019) como relatados na flag de recurso android.software.vulkan.deqp.level.
  • [C-1-10] PRECISA passar em todos os testes de dEQP do Vulkan nas listas de teste entre versão 132317953 e a versão especificada no android.software.vulkan.deqp.level.
  • [C-1-11] NÃO PODE enumerar o suporte para VK_KHR_video_queue, VK_KHR_video_decode_queue ou VK_KHR_video_encode_queue.
  • [C-SR-3] É FORTEMENTE RECOMENDADO para oferecer suporte a VK_KHR_driver_properties e extensões VK_GOOGLE_display_timing.
  • [C-1-12] NÃO PODE enumerar o suporte para a extensão VK_KHR_performance_query.
  • [C-SR-4] É FORTEMENTE RECOMENDADO para atender aos requisitos especificados por o perfil de referência do Android 2022;
  • [C-SR-5] É FORTEMENTE RECOMENDADO para oferecer suporte a VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory e VK_EXT_global_priority.
  • [C-SR-6] É FORTEMENTE RECOMENDADO usar o SkiaVk com HWUI.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

Se as implementações de dispositivos incluírem suporte ao Vulkan, elas:

  • [C-SR-8] É FORTEMENTE RECOMENDADO não modificar o carregador do Vulkan.
  • [C-1-14] NÃO PODE enumerar extensões de dispositivo Vulkan do tipo "KHR", "GOOGLE" ou "ANDROID" a menos que essas extensões estejam incluídas Sinalização de recurso android.software.vulkan.deqp.level.

Encerrar novos requisitos

Se as implementações de dispositivos não incluírem suporte para o Vulkan 1.0, elas:

  • [C-2-1] NÃO PODE declarar nenhuma das flags de recurso do Vulkan (por exemplo, android.hardware.vulkan.level, android.hardware.vulkan.version).
  • [C-2-2] NÃO PODE enumerar nenhum VkPhysicalDevice para a API nativa do Vulkan vkEnumeratePhysicalDevices().

Se as implementações de dispositivos incluírem suporte ao Vulkan 1.1 e declararem qualquer um dos Sinalizações de recursos do Vulkan descritas aqui eles:

  • [C-3-1] PRECISA expor o suporte ao semáforo e ao identificador externos do SYNC_FD e a extensão VK_ANDROID_external_memory_android_hardware_buffer.

  • [C-SR-7] É MUITO RECOMENDADO para fazer a VK_KHR_external_fence_fd extensão disponível para aplicativos de terceiros e ativar o aplicativo para exportar o payload de limite e importar o payload de cerca do arquivo POSIX descritores conforme descrito aqui.

7.1.4.3 RenderScript

Implementações de dispositivos:

  • [C-0-1] PRECISA ser compatível com o 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 os aplicativos declararem que querem ativar a aceleração de hardware para gráficos 2D nos níveis de aplicativo, atividade Janela ou visualização com o uso de uma tag de manifesto android:hardwareAccelerated (em inglês) ou chamadas de API diretas.

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, definindo android:hardwareAccelerated="false" ou desativar a aceleração de hardware diretamente pelas APIs View do Android.
  • [C-0-2] PRECISA exibir um comportamento consistente com a Documentação do SDK do Android sobre aceleração de hardware.

O Android inclui um objeto TextureView que permite aos desenvolvedores integrar diretamente texturas do OpenGL ES com aceleração de hardware como destinos de renderização em uma hierarquia de interface.

Implementações de dispositivos:

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

Se as implementações de dispositivos alegarem suporte a telas de ampla gama por meio de Configuration.isScreenWideColorGamut(), eles:

  • [C-1-1] PRECISA ter uma tela calibrada por cores.
  • [C-1-2] PRECISA ter uma tela cuja gama cubra a gama de cores sRGB inteiramente no espaço xyY da CIE 1931.
  • [C-1-3] PRECISA ter uma tela com uma área de gama de pelo menos 90% do DCI-P3 no espaço xyY CIE 1931.
  • [C-1-4] PRECISA oferecer suporte ao OpenGL ES 3.1 ou 3.2 e informá-lo corretamente.
  • [C-1-5] PRECISA anunciar o suporte para EGL_KHR_no_config_context. EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear. EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear, e EGL_EXT_gl_colorspace_display_p3_passthrough extensões.
  • [C-SR-1] É FORTEMENTE RECOMENDADO para oferecer suporte a GL_EXT_sRGB.

Por outro lado, se as implementações de dispositivos não forem compatíveis com telas de ampla gama, elas:

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

7.1.5. Modo de compatibilidade de aplicativo legado

O Android especifica um "modo de compatibilidade" em que o framework opera em uma "normal" Modo de tamanho de tela equivalente (320 dp de largura) para usar o modelo aplicativos não desenvolvidos para versões antigas do Android independência do tamanho da tela.

7.1.6. Tecnologia da tela

A plataforma Android inclui APIs que permitem que aplicativos renderizem gráficos para uma tela compatível com Android. Os dispositivos PRECISAM ser compatíveis com todas as opções a seguir. APIs definidas pelo SDK do Android, a menos que especificamente permitido neste documento.

Todas as telas compatíveis com a implementação do dispositivo:

  • [C-0-1] PRECISA renderizar gráficos coloridos de 16 bits.
  • DEVE oferecer suporte a telas com gráficos coloridos de 24 bits.
  • [C-0-2] PRECISA ser capaz de renderizar animações.
  • [C-0-3] PRECISA ter uma proporção de pixels (PAR) entre 0,9 e 1,15. Ou seja, a proporção de pixels PRECISA estar próxima ao quadrado. (1,0) com tolerância de 10% a 15%.

7.1.7. Telas secundárias

O Android inclui suporte a telas secundárias compatíveis com o Android para ativar recursos de compartilhamento de mídia e APIs de desenvolvedor para acessar telas externas.

Se as implementações de dispositivos forem compatíveis com uma tela externa, seja por um cabo sem fio ou uma conexão de tela adicional incorporada, eles:

  • [C-1-1] PRECISA implementar o DisplayManager serviço do sistema e API, conforme descrito na documentação do SDK do Android.

7.2. Dispositivos de entrada

Implementações de dispositivos:

7.2.1. Teclado

Caso as implementações de dispositivos incluam suporte a aplicativos os aplicativos Editor de método de entrada (IME), eles:

Implementações de dispositivos:

  • [C-0-1] NÃO PODE incluir um teclado físico que não corresponda a um dos formatos especificados em android.content.res.Configuration.tela (em inglês) (QWERTY ou 12 teclas).
  • DEVEM incluir implementações adicionais de teclado de software.
  • PODE incluir um teclado físico.

7.2.2. Navegação sem toque

O Android inclui suporte para botão direcional, trackball e wheel como mecanismos para 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] PRECISA fornecer um mecanismo de interface do usuário alternativo razoável para o seleção e edição de texto, compatível com os Mecanismos de Gerenciamento de Entradas. A a implementação de código aberto upstream do Android inclui um mecanismo de seleção adequado para uso com dispositivos que não tenham entradas de navegação sem toque.

7.2.3. Teclas de navegação

As guias Home, Recentes, e Voltar funções normalmente fornecidas por meio de uma interação com um botão físico dedicado ou uma parte distinta da tela sensível ao toque, são essenciais para o funcionamento paradigma de navegação e, portanto, implementações de dispositivos:

  • [C-0-1] PRECISA fornecer recursos de usuário para iniciar aplicativos instalados. que têm uma atividade com o <intent-filter> definido com ACTION=MAIN e CATEGORY=LAUNCHER ou CATEGORY=LEANBACK_LAUNCHER para dispositivo de televisão e implementações. A função Home DEVE ser o mecanismo para essa affordance do usuário.
  • DEVE fornecer botões para as funções Recentes e Voltar.

Se as funções Home, Recents ou Back forem fornecidas, elas:

  • [C-1-1] PRECISA ser acessível com uma única ação (por exemplo, tocar, clicar duas vezes ou gesto) quando qualquer um deles estiver acessível.
  • [C-1-2] PRECISA fornecer uma indicação clara de qual ação seria acionada cada função. Ter um ícone visível impresso no botão, mostrando um software ícone na parte da barra de navegação da tela, ou orientar o usuário através de um o fluxo de demonstração passo a passo guiado durante a experiência de configuração pronta para uso são exemplos de tal indicação.

Implementações de dispositivos:

  • [C-SR-1] é FORTEMENTE RECOMENDADO para não fornecer o mecanismo de entrada para o Função do menu já que foi descontinuada e substituída pela barra de ações a partir do Android 4.0.

  • [C-SR-2] É FORTEMENTE RECOMENDADO que forneça todas as funções de navegação cancelável. "Cancelável" é definida como a capacidade do usuário de impedir a função de navegação seja executada (por exemplo, indo para casa, voltando etc.) se o o deslizamento não é solto além de um determinado limite.

Se as implementações de dispositivos fornecerem a função de menu, elas:

  • [C-2-1] PRECISA exibir o botão flutuante de ação sempre que a ação O pop-up do menu flutuante não está vazio e a barra de ações está visível.
  • [C-2-2] NÃO É POSSÍVEL modificar a posição do pop-up flutuante de ação exibido selecionando o botão flutuante na barra de ações, mas PODE SER renderizado o pop-up flutuante de ação em uma posição modificada na tela quando estiver exibido selecionando a função Menu.

Se as implementações de dispositivos não fornecerem a função Menu, para inverso compatibilidade, elas:

  • [C-3-1] PRECISA disponibilizar a função Menu aos aplicativos quando targetSdkVersion for menor que 10, seja por um botão físico ou uma chave de software, ou gestos. Essa função de menu deve ser acessível, a menos que esteja oculta junto com outras funções de navegação.

Se as implementações de dispositivos fornecerem a função de assistência, eles:

  • [C-4-1] PRECISA tornar a função Assistente acessível com uma única ação (por exemplo, tocar, clicar duas vezes ou fazer um gesto) quando outras teclas de navegação estiverem acessíveis.
  • [C-SR-3] É MUITO RECOMENDADO usar a função HOME, manter pressionada uma interação designada.

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

  • [C-5-1] As teclas de navegação PRECISAM usar uma parte distinta da tela, não disponíveis para os aplicativos e NÃO PODEM obscurecer ou interferir de outra forma na a parte da tela disponível para os aplicativos.
  • [C-5-2] PRECISA disponibilizar uma parte da tela para aplicativos que atenda aos requisitos definidos na seção 7.1.1.
  • [C-5-3] PRECISA respeitar as flags definidas pelo app usando o View.setSystemUiVisibility(). método da API, de modo que essa parte distinta da tela (ou seja, a barra de navegação) está adequadamente escondida, conforme documentado em pelo SDK.

Se a função de navegação for fornecida como uma ação na tela baseada em gestos:

Se uma função de navegação é fornecida a partir de qualquer lugar das bordas esquerda e direita da orientação atual da tela:

  • [C-7-1] A função de navegação PRECISA ser Voltar e ser fornecida como um deslize das extremidades esquerda e direita da orientação atual do tela.
  • [C-7-2] Se painéis de sistema deslizantes personalizados forem fornecidos à esquerda ou cantos direito, eles DEVEM ser colocados dentro do 1/3 de cima da tela com uma indicação visual clara e persistente de que arrastar invocaria e não "Voltar". Um painel de sistema PODE ser configurado por um usuário de modo que ele fique abaixo do 1/3 da parte superior da tela borda(s), mas o painel do sistema NÃO PODE usar mais do que 1/3 da(s) borda(ões).
  • [C-7-3] Quando o app em primeiro plano tem View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT ou os sinalizadores WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE definidos, O deslizamento das bordas PRECISA se comportar como implementado no AOSP, que é documentados no SDK.
  • [C-7-4] Quando o app em primeiro plano tem View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT ou os sinalizadores WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE definidos, Os painéis de sistema deslizantes personalizados PRECISAM ficar ocultos até que o usuário insira ou Ativa o brilho das barras do sistema (também chamadas de barra de navegação e status) conforme implementadas no AOSP.

Se a função de navegação de retorno for fornecida e o usuário cancelar a ação de voltar um gesto e:

  • [C-8-1] OnBackInvokedCallback.onBackCancelled() PRECISA ser chamado.
  • [C-8-2] O OnBackInvokedCallback.onBackInvoked() NÃO PODE ser chamado.
  • [C-8-3] O evento KEYCODE_BACK NÃO PODE ser enviado.

Se a função de navegação de retorno for fornecida, mas o aplicativo em primeiro plano oferecer NÃO ter um OnBackInvokedCallback registrado, então:

  • O sistema DEVE fornecer uma animação para o aplicativo em primeiro plano que sugere que o usuário está voltando, conforme fornecido no AOSP.

Se as implementações de dispositivos oferecerem suporte à API setNavBarMode do sistema para permita que qualquer app do sistema com a permissão android.permission.STATUS_BAR defina o modo da barra de navegação, eles:

  • [C-9-1] PRECISA oferecer suporte a ícones adequados para crianças ou baseados em botões a navegação fornecida pelo código do AOSP.

7.2.4. Entrada por tela touch

O Android inclui suporte para uma variedade de sistemas de entrada de ponteiro, como touchscreens, touchpads e dispositivos de entrada por toque falsos. Implementações de dispositivos touchscreen sejam associados a uma tela de forma que o usuário tenha a impressão de diretamente manipular itens na tela. Como o usuário está tocando diretamente na tela, o sistema não requer affordances adicionais para indicar os objetos sendo manipuladas.

Implementações de dispositivos:

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

Se as implementações do dispositivo incluem uma tela sensível ao toque (de toque único ou melhor) em um tela principal compatível com Android, eles:

  • [C-1-1] PRECISA informar TOUCHSCREEN_FINGER para Configuration.touchscreen API.
  • [C-1-2] PRECISA informar android.hardware.touchscreen e android.hardware.faketouch.

Se as implementações de dispositivos incluem uma tela tátil que pode rastrear mais de um único toque em uma tela principal compatível com Android, elas:

  • [C-2-1] PRECISA informar as flags de recursos apropriadas android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct e android.hardware.touchscreen.multitouch.jazzhand correspondente ao tipo de touchscreen específica do dispositivo.

Se as implementações de dispositivos dependerem de um dispositivo de entrada externa, como mouse ou trackball (ou seja, sem tocar diretamente na tela) para entrada em um tela compatível com Android e atender aos requisitos de toque simulado em seção 7.2.5, eles:

  • [C-3-1] NÃO É POSSÍVEL reportar uma flag de recurso que comece com android.hardware.touchscreen:
  • [C-3-2] PRECISA informar apenas android.hardware.faketouch.
  • [C-3-3] PRECISA informar TOUCHSCREEN_NOTOUCH para o Configuration.touchscreen API.

7.2.5. Entrada de toque falsa

A interface de toque simulada fornece um sistema de entrada do usuário que se aproxima de um subconjunto recursos de tela touchscreen. Por exemplo, um mouse ou controle remoto que direcione um cursor na tela aproxima o toque, mas exige que o usuário primeiro aponte ou focar e clicar. vários dispositivos de entrada, como mouse, trackpad e giroscópio; Air mouse, ponteiro com giroscópio, joystick e trackpad multitoque podem oferecer suporte a para interações de toque. O Android inclui a constante de recurso android.hardware.faketouch, que corresponde a um dispositivo sem toque de alta fidelidade (baseado em ponteiro), como um mouse ou trackpad que possa emular entradas baseadas em toque (incluindo suporte básico a gestos) e indica que o dispositivo suporta um subconjunto emulado de funcionalidade de tela sensível ao toque.

Se as implementações de dispositivos não incluírem uma tela tátil, mas incluir outra sistema de entrada por ponteiro que querem disponibilizar, ele:

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

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

  • [C-1-1] PRECISA informar as posições absolutas de X e Y da tela da localização do ponteiro e mostra um ponteiro visual na tela.
  • [C-1-2] PRECISA informar o evento de toque com o código de ação que especifica a mudança de estado que ocorre no ponteiro descer ou subir na tela.
  • [C-1-3] PRECISA oferecer suporte ao ponteiro para cima e para baixo em um objeto na tela, o que permite que os usuários emulem o toque em um objeto na tela.
  • [C-1-4] PRECISA oferecer suporte ao ponteiro para baixo, para cima, para baixo e para cima. no mesmo lugar em um objeto na tela dentro de um limite de tempo, que Permite que os usuários emulem o toque duplo em um objeto na tela.
  • [C-1-5] PRECISA oferecer suporte ao ponteiro para baixo em um ponto arbitrário na tela. o ponteiro se move para qualquer outro ponto arbitrário na tela, seguido por um ponteiro para cima, o que permite aos usuários emular uma ação de arrastar por toque.
  • [C-1-6] PRECISA 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, aponta para cima na tela, que permite aos usuários arremessar um objeto na tela.

Se as implementações de dispositivo declararem suporte para android.hardware.faketouch.multitouch.distinct, eles:

  • [C-2-1] PRECISA declarar suporte para android.hardware.faketouch.
  • [C-2-2] PRECISA oferecer suporte ao rastreamento distinto de dois ou mais ponteiros independentes de entrada.

Se as implementações de dispositivo declararem suporte para android.hardware.faketouch.multitouch.jazzhand, eles:

  • [C-3-1] PRECISA declarar compatibilidade com android.hardware.faketouch.
  • [C-3-2] PRECISA oferecer suporte ao rastreamento distinto de cinco dedos (rastreamento de uma mão) ou mais entradas de ponteiro de maneira totalmente independente.

7.2.6. Suporte a controles de jogos

7.2.6.1. Mapeamentos de botões

Implementações de dispositivos:

  • [C-1-1] PRECISA ser capaz de mapear eventos HID para as constantes InputEvent correspondentes, conforme listado nas tabelas abaixo. A implementação upstream do Android atende a esse requisito.

Se as implementações de dispositivo incorporarem um controlador ou enviarem com um controlador separado na caixa, que forneça meios de inserir todos os eventos listados nas tabelas abaixo, elas:

  • [C-2-1] PRECISA declarar a flag de recurso android.hardware.gamepad.
Botão Uso de HID2 Botão do Android
R1 0x09 0x0001 KEYCODE_BOT_A (96)
B1 0x09 0x0002 KEYCODE_BOT_B (97)
X1 0x09 0x0004 KEYCODE_BOT_X (99)
A1 0x09 0x0005 KEYCODE_BOT_Y (100)
Botão direcional para cima1
Botão direcional para baixo1
0x01 0x00393 Eixo_HAT_Y4
Botão direcional esquerdo1
Botão direcional para a direita1
0x01 0x00393 Eixo_HAT_X4
Botão do ombro esquerdo1 0x09 0x0007 KEYCODE_Button_L1 (102)
Botão do ombro direito1 0x09 0x0008 KEYCODE_Botão_R1 (103)
Clique com o botão esquerdo do mouse1 0x09 0x000E KEYCODE_Button_THUMBL (106)
Clique com o botão direito do mouse1 0x09 0x000F KEYCODE_Button_THUMBR (107)
Voltar1 0x0c 0x0224 KEYCODE_BACK (4)

1 KeyEvent

2 Os usos de HID acima precisam ser declarados em um jogo pad CA (0x01 0x0005).

3 Esse uso deve ter um mínimo lógico de 0, um Máximo lógico de 7, Mínimo físico de 0, Máximo físico de 315, Unidades em graus e um Tamanho de relatório de 4. O valor lógico é definido como o rotação no sentido horário na direção oposta do eixo vertical por exemplo, um valor lógico de 0 representa nenhuma rotação e o botão para cima está sendo pressionado, enquanto um valor lógico de 1 representa uma rotação de 45 graus e as teclas para cima e para a esquerda sendo pressionado.

4 MotionEvent

Controles analógicos1 Uso de HID Botão do Android
Gatilho esquerdo 0x02 0x00C5 AXIS_LTRIGGER
Gatilho correto 0x02 0x00C4 EIXO_RTRIGGER
Joystick esquerdo 0x01 0x0030
0x01 0x0031
Eixo X
EIXO_Y
Joystick direito 0x01 0x0032
0x01 0x0035
Eixo Z
AXIS_RZ

1 MotionEvent

7.2.7. Controle remoto

Consulte a Seção 2.3.1 para ver os requisitos específicos dos dispositivos.

7,3 Sensores

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

Implementações de dispositivos:

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

Se as implementações do dispositivo incluem um tipo específico de sensor que tem um API correspondente para desenvolvedores terceirizados, eles:

  • [C-1-1] PRECISA informar todas as medições do sensor. usando os valores relevantes do Sistema Internacional de Unidades (métrica) para cada tipo de sensor definido na documentação do SDK do Android.
  • [C-1-2] PRECISA informar os dados do sensor com latência máxima de 100 milissegundos + 2 * sample_time para o caso de um fluxo do sensor com um latência máxima solicitada de 0 ms quando o processador do aplicativo está ativo. Esse atraso não inclui atrasos de filtragem.
  • [C-1-3] PRECISA informar a primeira amostra do sensor em até 400 milissegundos + 2 * sample_time do sensor que está sendo ativado. É aceitável que esta amostra têm uma precisão de 0.
  • [C-1-4] Para qualquer API indicada pela documentação do SDK do Android como um sensor contínuo as implementações de dispositivos PRECISAM fornecer continuamente amostras periódicas de dados que DEVEM ter uma instabilidade abaixo de 3%, em que a instabilidade é definida como o desvio padrão da diferença do valores de carimbo de data/hora informados entre eventos consecutivos.
  • [C-1-5] PRECISA garantir que o fluxo de eventos do sensor NÃO PODE impedir que a CPU do dispositivo entre em um estado de suspensão ou seja ativada. de um estado de suspensão.
  • [C-1-6] PRECISA informar o horário do evento. em nanossegundos, conforme definido na documentação do SDK do Android, representando hora em que o evento aconteceu e sincronizado com o SystemClock.elapsedRealtimeNano().
  • [C-SR-1] É FORTEMENTE RECOMENDADO que tenham erros de sincronização de carimbo de data/hora abaixo de 100 milissegundos, e DEVE ter erro de sincronização de carimbo de data/hora inferior a 1 milissegundos.
  • Quando vários sensores estiverem ativados, o consumo de energia NÃO DEVE exceder é a soma do consumo de energia informado por um sensor individual.

A lista acima não é abrangente. o comportamento documentado do SDK do Android e as documentações de código aberto do Android sensores serão considerados autoritativo.

Se as implementações do dispositivo incluem um tipo específico de sensor que tem um API correspondente para desenvolvedores terceirizados, eles:

  • [C-1-6] PRECISA definir uma resolução diferente de zero para todos os sensores e informar o valor. pelo Sensor.getResolution() Método de API.

Alguns tipos de sensores são compostos, o que significa que podem ser derivados de dados fornecidos por um ou mais sensores. (Os exemplos incluem o sensor de orientação e o ou sensor de aceleração linear.

Implementações de dispositivos:

  • DEVEM implementar esses tipos de sensor, quando eles incluir os pré-requisitos de sensores físicos, conforme descrito em tipos de sensor.

Se as implementações de dispositivos incluírem um sensor composto, elas:

  • [C-2-1] PRECISA implementar o sensor conforme descrito no Código aberto do Android documentação sobre sensores compostos.

Se as implementações do dispositivo incluem um tipo específico de sensor que tem um API correspondente para desenvolvedores de terceiros, e o sensor informa apenas um e as implementações de dispositivos:

  • [C-3-1] PRECISA definir a resolução como 1 para o sensor e informar o valor pelo Sensor.getResolution() Método de API.

Se as implementações do dispositivo incluem um tipo específico de sensor que oferece suporte SensorAdditionalInfo#TYPE_VEC3_CALIBRATION (link em inglês) e o sensor for exposto a desenvolvedores terceirizados, eles:

  • [C-4-1] NÃO PODE incluir nenhuma calibragem fixa e determinada pela fábrica de parâmetros nos dados fornecidos.

Se as implementações de dispositivos incluírem uma combinação de acelerômetro de três eixos, um Um sensor de giroscópio de três eixos ou um sensor magnetômetro são:

  • [C-SR-2] É MUITO RECOMENDADO para garantir que o acelerômetro, o giroscópio e têm uma posição relativa fixa, de modo que, se o dispositivo transformáveis (por exemplo, dobráveis), os eixos do sensor permanecem alinhados e consistentes com o sistema de coordenadas do sensor em todos os dispositivos possíveis estados de transformação.

7.3.1. Acelerômetro

Implementações de dispositivos:

  • [C-SR-1] É MUITO RECOMENDADO incluir um acelerômetro de três eixos.

Se as implementações de dispositivos incluírem um acelerômetro, elas:

  • [C-1-1] PRECISA relatar eventos com uma frequência de pelo menos 50 Hz.
  • [C-1-3] PRECISA estar em conformidade com Sistema de coordenadas do sensor do Android conforme detalhado nas APIs do Android.
  • [C-1-4] PRECISA ser capaz de medir a queda livre até quatro vezes a gravity(4g) ou mais em qualquer eixo.
  • [C-1-5] PRECISA ter uma resolução de pelo menos 12 bits.
  • [C-1-6] PRECISA ter um desvio padrão não superior a 0,05 m/s^, em que o desvio padrão deve ser calculado por eixo em amostras coletadas durante um período de pelo menos 3 segundos com a taxa de amostragem mais rápida.
  • DEVE relatar eventos de até pelo menos 200 Hz.
  • DEVE ter uma resolução de pelo menos 16 bits.
  • DEVE ser calibrado durante o uso se as características mudarem em do ciclo de vida e compensados, e preservam os parâmetros de compensação entre as reinicializações do dispositivo.
  • DEVE ser compensado por temperatura.

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

  • [C-2-1] PRECISA implementar e informar o sensor TYPE_ACCELEROMETER.
  • [C-SR-4] É FORTEMENTE RECOMENDADO para implementar a TYPE_SIGNIFICANT_MOTION sensor composto.
  • [C-SR-5] É FORTEMENTE RECOMENDADO para implementar e informar Sensor TYPE_ACCELEROMETER_UNCALIBRATED. Os dispositivos Android são É RECOMENDADO atender a esse requisito para que possam fazer upgrade para a em uma próxima versão, em que pode se tornar OBRIGATÓRIO.
  • Implemente as APIs TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR TYPE_STEP_DETECTOR de TYPE_STEP_COUNTER sensores compostos, conforme descrito no documento do SDK do Android.

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

  • [C-3-1] PRECISA implementar e informar o sensor TYPE_ACCELEROMETER_LIMITED_AXES.
  • [C-SR-6] São STRONGLY_RECOMMENDED para implementar e informar Sensor TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

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

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

Se as implementações de dispositivos incluírem um acelerômetro de três eixos e um sensor de giroscópio de três eixos, eles:

  • [C-5-1] PRECISA implementar TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION. com sensores compostos.
  • [C-SR-7] É FORTEMENTE RECOMENDADO para implementar a Sensor composto TYPE_GAME_ROTATION_VECTOR.

Se as implementações de dispositivos incluírem um acelerômetro de três eixos e um sensor de giroscópio de três eixos, e um sensor de magnetômetro, eles:

  • [C-6-1] PRECISA implementar um sensor composto TYPE_ROTATION_VECTOR.

7.3.2. Magnetômetro

Implementações de dispositivos:

  • [C-SR-1] É RECOMENDADO incluir um magnetômetro de três eixos (bússola).

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

  • [C-1-1] PRECISA implementar o sensor TYPE_MAGNETIC_FIELD.
  • [C-1-2] PRECISA relatar eventos com uma frequência de pelo menos 10 Hz e DEVEM relatar eventos de até 50 Hz.
  • [C-1-3] PRECISA estar em conformidade com o Sistema de coordenadas do sensor do Android conforme detalhado nos APIs do Android.
  • [C-1-4] PRECISA ser capaz de medir entre -900 μT e +900 μT em cada do módulo antes da saturação.
  • [C-1-5] PRECISA ter um valor de compensação de hardware inferior a 700 μT e DEVE ter abaixo de 200 μT, afastando o magnetômetro do campos magnéticos dinâmicos (induzidos por corrente) e estáticos (induzidos por ímãs).
  • [C-1-6] PRECISA ter uma resolução igual ou mais densa que 0,6 μT.
  • [C-1-7] PRECISA oferecer suporte à calibragem on-line e à compensação do hardware e preservar os parâmetros de compensação entre as reinicializações do dispositivo.
  • [C-1-8] PRECISA ter a compensação de ferro suave aplicada. A calibragem pode ser feitas durante o uso ou durante a produção do dispositivo.
  • [C-1-9] PRECISA ter um desvio padrão, calculado por eixo com base amostras coletadas durante um período de pelo menos 3 segundos com a amostragem mais rápida não superior a 1, 5 μT; DEVE ter um desvio padrão não superior a 0,5 μT.
  • [C-1-10] PRECISA implementar o TYPE_MAGNETIC_FIELD_UNCALIBRATED sensor

Se as implementações do dispositivo incluírem um magnetômetro de três eixos, um acelerômetro e um giroscópio de três eixos, eles:

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

Se as implementações de dispositivos incluírem um magnetômetro de três eixos e 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 TYPE_GEOMAGNETIC_ROTATION_VECTOR, eles:

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

7.3.3. GPS

Implementações de dispositivos:

  • [C-SR-1] É FORTEMENTE RECOMENDADO a inclusão de um receptor GPS/GNSS.

Se as implementações do dispositivo incluírem um receptor GPS/GNSS e informarem a capacidade aos aplicativos pela flag de recurso android.hardware.location.gps, eles:

  • [C-1-1] PRECISA oferecer suporte a saídas de localização a uma taxa de pelo menos 1 Hz quando solicitada via LocationManager#requestLocationUpdate.
  • [C-1-2] PRECISA determinar o local em condições de céu aberto. (Sinais fortes, multicaminho insignificante, HDOP < 2) dentro de 10 segundos (rápido) tempo até a primeira correção), quando conectado a uma velocidade de dados de 0,5 Mbps ou superior conexão com a Internet. Esse requisito normalmente é atendido pelo uso de alguns forma de técnica de GPS/GNSS assistido ou previsto para minimizar o tempo de bloqueio por GPS/GNSS (os dados de assistência incluem o Tempo de referência, local de referência e efêmeras/relógio do satélite).
    • [C-1-6] Depois de fazer esse cálculo de local, o dispositivo implementações PRECISAM determinar sua localização, em céu aberto, dentro de Cinco segundos, até uma hora após as solicitações de localização serem reiniciadas do cálculo de localização inicial, mesmo quando a solicitação subsequente é feitas sem uma conexão de dados e/ou após uma reinicialização.
  • Em condições de céu aberto após determinar o local, enquanto estiver parado ou movimento com menos de 1 metro por segundo ao quadrado de aceleração:

    • [C-1-3] PRECISA determinar o local a até 20 metros e a velocidade em 0,5 metro por segundo, pelo menos 95% do tempo.
    • [C-1-4] PRECISA acompanhar e relatar simultaneamente por meio de GnssStatus.Callback a pelo menos oito satélites de uma constelação.
    • DEVE ser capaz de rastrear simultaneamente 24 satélites, de múltiplas constelações (ex.: GPS + pelo menos uma entre Glonass, Beidou, Galileu).
  • [C-SR-2] É FORTEMENTE RECOMENDADO para continuar a fornecer GPS/GNSS normal saídas de localização por APIs de provedor de localização GNSS durante uma chamada de emergência a chamada.

  • [C-SR-3] É FORTEMENTE RECOMENDADO para informar medições GNSS de todos constelações rastreadas (conforme relatado em mensagens GnssStatus), com exceção da SBAS.

  • [C-SR-4] É FORTEMENTE RECOMENDADO a informar o AGC e a frequência do GNSS de medida.

  • [C-SR-5] É FORTEMENTE RECOMENDADO para informar todas as estimativas de precisão (incluindo rolamento, velocidade e vertical) como parte de cada localização GPS/GNSS.

  • [C-SR-6] É FORTEMENTE RECOMENDADO para informar medições GNSS assim que eles serão encontrados, mesmo que uma localização calculada com base em GPS/GNSS ainda não tenha sido relatadas.

  • [C-SR-7] É FORTEMENTE RECOMENDADO para informar pseudodistâncias do GNSS e taxas de pseudodistâncias, que, em condições de céu aberto, após determinar a localização, enquanto está parado ou em movimento com menos de 0,2 metro por segundo ao quadrado de são suficientes para calcular uma posição dentro de 20 metros, e a velocidade em 0,2 metro por segundo, pelo menos 95% do tempo.

7.3.4. Giroscópio

Implementações de dispositivos:

  • [C-SR-1] É MUITO RECOMENDADO incluir um sensor de giroscópio.

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

  • [C-1-1] PRECISA relatar eventos com uma frequência de pelo menos 50 Hz.
  • [C-1-4] PRECISA ter uma resolução de 12 bits ou mais.
  • [C-1-5] PRECISA ser compensado pela temperatura.
  • [C-1-6] PRECISA ser calibrado e compensado durante o uso e preservar o 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 variância pode variar com o taxa de amostragem, mas PRECISA ser limitado por esse valor. Em outras palavras, se você medir a variância do giroscópio a uma taxa de amostragem de 1 Hz, ele NÃO DEVE ser maior de 1e a 7 rad^2/s^2.
  • [C-SR-2] O erro de calibração é FORTEMENTE RECOMENDADO ser menor que 0,01 rad/s quando o dispositivo está parado em temperatura ambiente.
  • [C-SR-3] É FORTEMENTE RECOMENDADO ter uma resolução de 16 bits ou mais.
  • DEVE relatar eventos de até pelo menos 200 Hz.

Se as implementações de dispositivos incluírem um giroscópio de três eixos, elas:

  • [C-2-1] PRECISA implementar o sensor TYPE_GYROSCOPE.
  • [C-SR-4] É altamente recomendável implementar TYPE_GYROSCOPE_UNCALIBRATED sensor

Se as implementações de dispositivos incluírem um giroscópio com menos de três eixos, elas:

  • [C-3-1] PRECISA implementar e informar o sensor TYPE_GYROSCOPE_LIMITED_AXES.
  • [C-SR-5] São STRONGLY_RECOMMENDED para implementar e informar Sensor TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

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

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

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

  • [C-5-1] PRECISA implementar TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION. com sensores compostos.
  • [C-SR-6] É FORTEMENTE RECOMENDADO para implementar a TYPE_GAME_ROTATION_VECTOR sensor composto.

7.3.5. Barômetro

Implementações de dispositivos:

  • [C-SR-1] É FORTEMENTE RECOMENDADO incluir um barômetro (pressão do ar ambiente sensor).

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

  • [C-1-1] PRECISA implementar e informar o sensor TYPE_PRESSURE.
  • [C-1-2] PRECISA entregar eventos com frequência de 5 Hz ou mais.
  • [C-1-3] PRECISA ser compensado pela temperatura.
  • [C-SR-2] É MUITO RECOMENDADO para informar as medições de pressão na varia de 300 hPa 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 (equivalente a uma precisão de ~1 m em uma mudança de aproximadamente 200 m no nível do mar).

7.3.6. Termômetro

Se as implementações do dispositivo incluírem um termômetro ambiente (sensor de temperatura), eles:

  • [C-1-1] PRECISA definir SENSOR_TYPE_AMBIENT_TEMPERATURE. do sensor de temperatura ambiente e o sensor PRECISA medir a temperatura ambiente temperatura (sala/cabine do veículo) em que o usuário está interagindo com o o dispositivo em graus Celsius.

Se as implementações do dispositivo incluírem um sensor de termômetro que mede uma diferente da temperatura ambiente, como a temperatura da CPU, eles:

Se as implementações de dispositivos incluírem um sensor para monitorar a temperatura da pele, então eles:

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 incluem um sensor de proximidade e informam apenas um binário "próximo" ou "longe" lendo, eles:

  • [C-1-1] PRECISA medir a proximidade de um objeto na mesma direção que o tela. Ou seja, o sensor de proximidade PRECISA estar orientado para detectar objetos. próximo à tela, já que a intenção principal desse tipo de sensor é detectar um smartphone em uso pelo usuário. Se as implementações de dispositivos incluírem uma sensor de proximidade com qualquer outra orientação, ele NÃO PODE ser acessível por meio dessa API.
  • [C-1-2] PRECISA ter 1 bit de precisão ou mais.
  • [C-1-3] PRECISA usar 0 centímetros como a leitura próxima e 5 centímetros como que você está lendo.
  • [C-1-4] PRECISA informar um alcance e uma resolução máximos de 5.

7.3.9. Sensores de alta fidelidade

Se as implementações do dispositivo incluírem um conjunto de sensores de qualidade mais alta, conforme definido nesta seção e disponibilizá-los para apps de terceiros, eles:

  • [C-1-1] PRECISA identificar a capacidade pela Sinalização de recurso android.hardware.sensor.hifi_sensors.

Se as implementações de dispositivos declararem android.hardware.sensor.hifi_sensors, eles:

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

    • PRECISA ter um intervalo de medição entre pelo menos -8 g e +8 g e é É RECOMENDADO manter um intervalo de medição entre pelo menos -16 g e +16 g.
    • PRECISA ter uma resolução de medição de pelo menos 2.048 LSB/g.
    • PRECISA ter uma frequência de medição mínima de 12,5 Hz ou menos.
    • PRECISA ter uma frequência de medição máxima de 400 Hz ou mais. DEVE oferecem suporte ao SensorDirectChannel RATE_VERY_FAST.
    • PRECISA ter um ruído de medição menor ou igual a 400 μg/✓Hz.
    • PRECISA implementar uma forma sem ativação desse sensor com um buffer de pelo menos 3.000 eventos de sensor.
    • PRECISA ter um consumo de energia em lote não inferior a 3 mW.
    • [C-SR-1] É FORTEMENTE RECOMENDADO que tenha uma largura de banda de medição de 3 dB de no pelo menos 80% da frequência de Nyquist e do espectro de ruído branco largura de banda larga.
    • DEVE ter uma aceleração aleatória de caminhada com menos de 30 μg ≧Hz testada em temperatura ambiente.
    • DEVE ter uma mudança de viés x temperatura de ≤ +/- 1 mg/°C.
    • DEVE ter uma não linearidade de linha de melhor ajuste ≤ 0,5%, e a mudança de sensibilidade x temperatura ≤ 0,5% 0,03%/C°
    • DEVE ter sensibilidade entre eixos de < 2,5 % e variação de sensibilidade entre eixos < Faixa de temperatura de funcionamento do dispositivo de 0,2%.
  • [C-2-2] PRECISA ter um TYPE_ACCELEROMETER_UNCALIBRATED com o mesmo requisitos de qualidade como TYPE_ACCELEROMETER.

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

    • PRECISA ter um intervalo de medição entre -1.000 e +1.000 dps.
    • PRECISA ter uma resolução de medida de pelo menos 16 LSB/dps.
    • PRECISA ter uma frequência de medição mínima de 12,5 Hz ou menos.
    • PRECISA ter uma frequência de medição máxima de 400 Hz ou mais. DEVE oferecem suporte ao SensorDirectChannel RATE_VERY_FAST.
    • PRECISA ter um ruído de medição não superior a 0,014°/s/concordate.
    • [C-SR-2] É FORTEMENTE RECOMENDADO que tenha uma largura de banda de medição de 3 dB de no pelo menos 80% da frequência de Nyquist e do espectro de ruído branco largura de banda larga.
    • DEVE ter uma taxa de caminhada aleatória inferior a 0,001 °/s cione Hz testada na sala temperatura
    • DEVE ter uma mudança de viés x temperatura ≤ +/- 0,05 °/ s / °C.
    • DEVE ter uma mudança de sensibilidade x temperatura de ≤ 0,02% / °C.
    • DEVE ter uma não linearidade de linha de melhor ajuste de ≤ 0,2%.
    • DEVE ter uma densidade de ruído menor ou igual a 0,007 °/s/shaped Hz.
    • DEVE ter erros de calibração inferiores a 0,002 rad/s em faixa de temperatura entre 10 e 40 °C quando o dispositivo está parado.
    • DEVE ter sensibilidade à g menor que 0,1°/s/g.
    • DEVE ter sensibilidade entre eixos de < 4 % e sensibilidade entre eixos variação < Faixa de temperatura de funcionamento do dispositivo de 0,3%.
  • [C-2-4] PRECISA ter um TYPE_GYROSCOPE_UNCALIBRATED com a mesma qualidade requisitos como TYPE_GYROSCOPE.

  • [C-2-5] PRECISA ter um sensor TYPE_GEOMAGNETIC_FIELD que:

    • PRECISA ter um intervalo de medição entre -900 e +900 μT.
    • PRECISA ter uma resolução de medida de pelo menos 5 LSB/uT.
    • PRECISA ter uma frequência de medição mínima de 5 Hz ou menos.
    • PRECISA ter uma frequência de medição máxima de 50 Hz ou mais.
    • PRECISA ter um ruído de medição menor que 0,5 uT.
  • [C-2-6] PRECISA ter um TYPE_MAGNETIC_FIELD_UNCALIBRATED com a mesma qualidade como TYPE_GEOMAGNETIC_FIELD e além disso:

    • PRECISA implementar uma forma sem ativação desse sensor com um buffer de pelo menos 600 eventos de sensor.
    • [C-SR-3] É FORTEMENTE RECOMENDADO ter o espectro de ruído branco de 1 Hz a pelo menos 10 Hz quando a taxa do relatório for 50 Hz ou superior.
  • [C-2-7] PRECISA ter um sensor TYPE_PRESSURE que:

    • PRECISA ter um intervalo de medição entre 300 e 1.100 hPa.
    • PRECISA ter uma resolução de medida de pelo menos 80 LSB/hPa.
    • PRECISA ter uma frequência de medição mínima de 1 Hz ou menos.
    • PRECISA ter uma frequência de medição máxima de 10 Hz ou mais.
    • PRECISA ter um ruído de medição não superior a 2 Pa/cioneHz.
    • PRECISA implementar uma forma sem ativação desse sensor com um buffer de pelo menos 300 eventos de sensor.
    • PRECISA ter um consumo de energia em lote não inferior a 2 mW.
  • [C-2-8] PRECISA ter um sensor TYPE_GAME_ROTATION_VECTOR.

  • [C-2-9] PRECISA ter um sensor TYPE_SIGNIFICANT_MOTION que:

    • PRECISA ter um consumo de energia não inferior a 0,5 mW quando o dispositivo estiver estática e 1,5 mW quando o dispositivo está em movimento.
  • [C-2-10] PRECISA ter um sensor TYPE_STEP_DETECTOR que:

    • PRECISA implementar uma forma sem ativação desse sensor com um buffer de pelo menos 100 eventos de sensor.
    • PRECISA ter um consumo de energia não inferior a 0,5 mW quando o dispositivo estiver estática e 1,5 mW quando o dispositivo está em movimento.
    • PRECISA ter um consumo de energia em lote não inferior a 4 mW.
  • [C-2-11] PRECISA ter um sensor TYPE_STEP_COUNTER que:

    • PRECISA ter um consumo de energia não inferior a 0,5 mW quando o dispositivo estiver estática e 1,5 mW quando o dispositivo está em movimento.
  • [C-2-12] PRECISA ter um sensor TILT_DETECTOR que:

    • PRECISA ter um consumo de energia não inferior a 0,5 mW quando o dispositivo estiver estática e 1,5 mW quando o dispositivo está em movimento.
  • [C-2-13] O carimbo de data/hora do mesmo evento físico relatado pelo O acelerômetro, o giroscópio e o magnetômetro PRECISAM estar dentro de 2, 5 milissegundos e se relacionam entre si. O carimbo de data/hora do mesmo evento físico informado por o acelerômetro e o giroscópio DEVEM estar a até 0,25 milissegundo de cada entre si.

  • [C-2-14] PRECISA ter carimbos de data/hora do evento do sensor do giroscópio ao mesmo tempo como subsistema da câmera e em 1 milissegundo de erro.

  • [C-2-15] PRECISA entregar amostras aos aplicativos em até 5 milissegundos a partir a hora em que os dados estão disponíveis em qualquer um dos sensores físicos acima ao aplicativo.

  • [C-2-16] NÃO PODE ter um consumo de energia superior a 0,5 mW quando o dispositivo está estático e 2 mW quando ele está em movimento quando qualquer combinação dos seguintes sensores estiver 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 presente, PRECISA ter com capacidade mínima de buffer de 100 eventos de sensor.

Observe que os requisitos de consumo de energia nesta seção não incluem os consumo de energia do processador do aplicativo. Ela inclui o poder por toda a cadeia: o sensor, os circuitos de suporte, sistema de processamento de sensores dedicado etc.

Se as implementações do dispositivo incluírem suporte direto a sensores, elas:

  • [C-3-1] PRECISA declarar corretamente o suporte aos tipos de canal direto e direto. informar o nível das taxas usando o isDirectChannelTypeSupported e getHighestDirectReportRateLevel API.
  • [C-3-2] PRECISA 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.
  • DEVE oferecer suporte aos relatórios de eventos pelo canal direto do sensor para campanhas primárias sensor (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. Sensores biométricos

Para mais informações sobre a medição da segurança do desbloqueio biométrico, consulte Como medir a segurança biométrica (em inglês).

Se as implementações de dispositivos incluírem uma tela de bloqueio segura, elas:

  • DEVE incluir um sensor biométrico

Os sensores biométricos podem ser classificados como Classe 3 (anteriormente Forte), Classe 2 (anteriormente fraca) ou Classe 1 (anteriormente Conveniência) com base em suas taxas de aceitação de spoofing e impostores e na segurança da pipeline biométrico. Essa classificação determina as capacidades o sensor biométrico precisa interagir com a plataforma e com dispositivos aplicativos conteinerizados. Os sensores precisam atender a requisitos adicionais, conforme detalhado abaixo, se eles querem ser classificados como Classe 1, Classe 2 ou Classe 3. As biometrias de Classe 2 e Classe 3 recebem recursos adicionais como detalhadas abaixo.

Se as implementações do dispositivo disponibilizarem um sensor biométrico a terceiros aplicativos por android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt, e android.provider.Settings.ACTION_BIOMETRIC_ENROLL, eles:

  • [C-4-1] PRECISA atender aos requisitos de biometria de Classe 3 ou Classe 2 conforme definido neste documento.
  • [C-4-2] PRECISA reconhecer e respeitar cada nome de parâmetro definido como uma constante da seção Authenticators e as combinações delas. Por outro lado, NÃO PODE honrar ou reconhecer constantes inteiras passadas para a classe canAuthenticate(int) e setAllowedAuthenticators(int) métodos diferentes daqueles documentados como constantes públicas Autenticadores e as combinações deles.
  • [C-4-3] PRECISA implementar a instrução ACTION_BIOMETRIC_ENROLL. ações em dispositivos que têm biometria de Classe 3 ou de Classe 2. Esta ação PRECISA apresentar apenas os pontos de entrada de registro para a Classe 3. ou Classe 2.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [C-4-4] É NECESSÁRIO permitir que os aplicativos adicionem conteúdo personalizado ao BiometricPrompt usando os formatos de exibição de conteúdo PromptContentView. A exibição do conteúdo formatos NÃO PODEM ser estendidos para permitir imagens, links, conteúdo interativo, ou outras formas de mídia que ainda não fazem parte do BiometricPrompt API. Ajustes estilísticos que não alteram, ocultam ou truncam esse conteúdo pode ser criado (como mudança de posição, preenchimento, margens e tipografia).

Encerrar novos requisitos

Se as implementações de dispositivos forem compatíveis com biometria passiva, elas:

  • [C-5-1] PRECISA, por padrão, exigir uma etapa de confirmação adicional (por exemplo, o pressionamento de um botão).
  • [C-SR-1] É FORTEMENTE RECOMENDADO ter uma configuração para permitir que os usuários substituem a preferência do aplicativo e sempre exigem acompanhamento etapa de confirmação.
  • [C-SR-2] É FORTEMENTE RECOMENDADO que a ação de confirmação seja garantida. de modo que o comprometimento de um sistema operacional ou kernel não consiga fazer spoofing. Por exemplo, isso significa que a ação de confirmação com base em um botão físico é roteado por um pino de entrada/saída de uso geral (GPIO, na sigla em inglês) somente de entrada de um elemento de segurança (SE) que não pode ser conduzido por nenhum outro meio que não um pressionar um botão físico.
  • [C-5-2] PRECISA implementar também um fluxo de autenticação implícito (sem etapa de confirmação) correspondente a setConfirmationRequired(boolean), que os aplicativos podem configurar para utilizar nos fluxos de login.

Se as implementações de dispositivos tiverem vários sensores biométricos, elas:

  • [C-7-1] PRECISA, quando a biometria está bloqueada (ou seja, ela está desativada) até que o usuário desbloqueie com a autenticação primária) ou bloqueio com limite de tempo Ou seja, a biometria é desativada temporariamente até que o usuário aguarde um pouco em um intervalo de tempo) devido a muitas tentativas com falha, também bloqueie todos os outros biometria de uma classe mais baixa. No caso de bloqueio por tempo limitado, o tempo de espera para a verificação biométrica PRECISA ser o tempo máximo de espera. de todas as biometrias em bloqueios com limite de tempo.

  • [C-SR-12] São RECOMENDADOS FORTEMENTE quando uma biometria está bloqueada (por exemplo, o a biometria ficará desativada até que o usuário faça o desbloqueio com a autenticação principal) ou bloqueio com limite de tempo (ou seja, a biometria é desativada temporariamente até que o usuário espera por um intervalo de tempo) devido a muitas tentativas com falha, para também bloquear todas as outras biometrias da mesma classe biométrica. No caso de bloqueio com limite de tempo, o tempo de espera para a verificação biométrica é FORTEMENTE RECOMENDADO para ser o tempo máximo de espera de todas as biometrias com limite de tempo bloqueio.

  • [C-7-2] PRECISA desafiar o usuário quanto à autenticação principal recomendada. (por exemplo, PIN, padrão, senha) para redefinir o contador de bloqueio para uma biometria que estão sendo bloqueados. A biometria de classe 3 PODE ser permitida para redefinir o bloqueio para uma biometria bloqueada da mesma classe ou de classe inferior. Classe 2 ou A biometria de classe 1 NÃO PODE ser permitida para concluir um bloqueio de redefinição para qualquer biometria.

  • [C-SR-3] É FORTEMENTE RECOMENDADO exigir que apenas uma biometria seja confirmada por autenticação (por exemplo, se a impressão digital e os sensores faciais estiverem disponíveis no dispositivo, onAuthenticationSucceeded. deve ser enviada depois que qualquer um deles for confirmado).

Para que as implementações de dispositivos permitam o acesso a chaves de armazenamento de chaves para aplicativos de terceiros, ela:

  • [C-6-1] PRECISA atender aos requisitos da Classe 3, conforme definido neste seção abaixo.
  • [C-6-2] PRECISA apresentar somente biometrias de Classe 3 quando a autenticação requer BIOMETRIC_STRONG, ou a autenticação for invocada com um CryptoObject.

Se as implementações de dispositivos quiserem tratar um sensor biométrico como Classe 1 (anteriormente Conveniência), eles:

  • [C-1-1] PRECISA ter uma taxa de aceitação falsa menor que 0,002%.
  • [C-1-2] PRECISA divulgar que esse modo pode ser menos seguro que um PIN forte. padrão ou senha e enumerar claramente os riscos de ativá-lo, se o as taxas de aceitação de spoofing e impostores são maiores que 7%, conforme medido pelo Protocolos de teste de biometria do Android.
  • [C-1-9] PRECISA contestar o usuário quanto à autenticação principal recomendada. (por exemplo, PIN, padrão, senha) depois de no máximo 20 tentativas falsas e não tempo de espera inferior a 90 segundos para a verificação biométrica, teste falso é aquele com uma qualidade de captura adequada (BIOMETRIC_ACQUIRED_GOOD) que não corresponde a uma biometria registrada.
  • [C-SR-4] É FORTEMENTE RECOMENDADO para reduzir o número total de falsos testes para a verificação biométrica especificada em [C-1-9] se o spoofing e o impostor as taxas de aceitação são superiores a 7%, conforme medido pela Android Biometrics. Protocolos de teste.
  • [C-1-3] Tentativas de limite de taxa PRECISA para a verificação biométrica, em que um teste falso é aquele com uma qualidade de captura adequada (BIOMETRIC_ACQUIRED_GOOD) que não corresponda a uma biometria registrada.
  • [C-SR-5] É FORTEMENTE RECOMENDADO para tentativas de limite de taxa por pelo menos 30 segundos após cinco tentativas falsas para a verificação biométrica do número máximo de testes falsos por [C-1-9] - onde um teste falso é aquele com uma qualidade de captura adequada (BIOMETRIC_ACQUIRED_GOOD) que não corresponde a biometria registrada.
  • [C-SR-6] É FORTEMENTE RECOMENDADO ter toda a lógica de limitação de taxa no TEE.
  • [C-1-10] PRECISA desativar a biometria quando a espera para autenticação primária for acionado pela primeira vez, conforme descrito em [C-0-2] da seção 9.11.
  • [C-1-11] PRECISA ter uma taxa de aceitação de impostor e de spoofing não superior a 30%. com (1) uma taxa de aceitação de impostor e spoofing para a apresentação de Nível A espécies com instrumento de ataque (PAI) não superior a 30%, e (2) um spoof e taxa de aceitação de impostores de espécies PAI de nível B não superior a 40%, como medidas pelos protocolos de teste de biometria do Android.
  • [C-1-4] PRECISA evitar a adição de novas biometrias sem antes estabelecer uma cadeia de confiança pedindo que o usuário confirme a existência ou adicione um novo dispositivo credencial (PIN/padrão/senha) protegida pelo TEE; o Android Open A implementação do projeto de origem fornece o mecanismo no framework para fazer assim.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [C-1-5] PRECISA remover completamente todos os dados biométricos identificáveis de um usuário. Quando a conta do usuário é removida (inclusive por meio de uma redefinição para a configuração original) ou quando a autenticação principal recomendada (por exemplo, PIN, padrão e senha) será removido.

Encerrar novos requisitos

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [C-1-7] PRECISA desafiar o usuário quanto à autenticação principal recomendada. (como PIN, padrão, senha) uma vez a cada 24 horas ou menos. Observação: o upgrade de dispositivos lançados com o Android 9 ou versões anteriores PRECISA contestar o usuário quanto à autenticação principal recomendada (como PIN, padrão, senha) uma vez a cada 72 horas ou menos.

Encerrar novos requisitos

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [C-1-8] PRECISA desafiar o usuário na pergunta principal recomendada. autenticação (como PIN, padrão, senha) ou biometria de Classe 3 (STRONG); depois de uma das seguintes opções:
    • um tempo limite de inatividade de 4 horas OU
    • 3 tentativas de autenticação biométrica falharam.
    • O tempo limite de inatividade e a contagem de autenticação com falha são redefinidos após qualquer confirmação das credenciais do dispositivo. Observação: upgrade de dispositivos lançados no Android 9 ou anteriores podem estar isentos do C-1-8.

Encerrar novos requisitos

  • [C-SR-7] É FORTEMENTE RECOMENDADO usar a lógica na estrutura fornecida pelo Android Open Source Project para aplicar as restrições especificadas em [C-1-7] e [C-1-8] para novos dispositivos.
  • [C-SR-8] É FORTEMENTE RECOMENDADO ter uma falsa taxa de rejeição menor que 10%, conforme medido no dispositivo.
  • [C-SR-9] É FORTEMENTE RECOMENDADO que tenham uma latência inferior a 1 segundo, medida desde a detecção da biometria até o desbloqueio da tela, para cada biometria registrada.
  • [C-1-12] PRECISA ter uma taxa de aceitação de spoofing e impostor não superior a 40% por apresentação de instrumento de ataque (PAI, na sigla em inglês), conforme medido pelo Protocolos de teste de biometria do Android.
  • [C-SR-13] É FORTEMENTE RECOMENDADO que tenha uma paródia e a taxa de aceitação de impostores não pode ser maior que 30% por apresentação de instrumento de ataque (PAI, na sigla em inglês), conforme medido pelo Protocolos de teste de biometria do Android.
  • [C-SR-8] É FORTEMENTE RECOMENDADO ter uma falsa taxa de rejeição menor que 10%, conforme medido no dispositivo.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [C-1-15] PRECISA permitir que os usuários removam uma ou várias biometrias inscrições.

Encerrar novos requisitos

  • [C-SR-14] É FORTEMENTE RECOMENDADO a divulgar a classe biométrica do sensor biométrico e os riscos correspondentes de ativá-lo.

  • [C-SR-17] É FORTEMENTE RECOMENDADO para implementar as novas interfaces AIDL (como IFace.aidl e IFingerprint.aidl).

Se as implementações de dispositivos quiserem tratar um sensor biométrico como Classe 2 (link em inglês) (anteriormente fraco), eles:

  • [C-2-1] PRECISA atender a todos os requisitos da Classe 1 acima.
  • [C-2-2] PRECISA ter uma taxa de aceitação de impostor e de spoofing não superior a 20%. com (1) uma taxa de aceitação de spoof e impostor para Espécies de instrumento de ataque de apresentação (PAI) de nível A não superior a 20%, e (2) uma taxa de aceitação de spoof e impostor de espécies PAI de nível B não maior que 30%, conforme medido pelo Protocolos de teste de biometria do Android.
  • [C-SR-15] É MUITO RECOMENDADO a ter um spoofing ou um impostor taxa de aceitação não superior a 20% por apresentação de instrumento de ataque (PAI, na sigla em inglês), conforme medido pelo Protocolos de teste de biometria do Android.
  • [C-2-3] PRECISA realizar a correspondência biométrica em um ambiente de execução isolado fora do Android do usuário ou do kernel, como o ambiente de execução confiável (TEE), em um chip com um canal seguro para o ambiente de execução isolado ou em uma Máquina Virtual Protegida que atenda aos requisitos da Seção 9.17.
  • [C-2-4] PRECISA ter todos os dados identificáveis criptografados e criptograficamente autenticados para que não possam ser adquiridos, lidos ou alterados fora o ambiente de execução isolado ou um chip com um canal seguro para o ambiente de execução isolado, conforme documentado na implementação diretrizes no site do Android Open Source Project ou em uma máquina virtual protegida controlado por um hipervisor que atenda aos requisitos da Seção 9.17.
  • [C-2-5] Para biometria baseada em câmera, mas com autenticação biométrica ou a inscrição está acontecendo:
    • PRECISA operar a câmera de uma forma que impeça que os frames sejam lidos ou alterados fora do ambiente de execução isolado ou de um chip com um canal seguro para o ambiente de execução isolado ou um Máquina virtual controlada por hipervisor que atende aos requisitos da seção 9,17
    • Para soluções RGB de uma câmera, os frames podem ser legível fora do ambiente de execução isolado para dar suporte a operações como a visualização da inscrição, mas NÃO PODERÁ ser alterável.
  • [C-2-6] NÃO PODE permitir que aplicativos de terceiros façam a distinção entre registros biométricos individuais.
  • [C-2-7] NÃO PODE permitir acesso não criptografado a dados biométricos identificáveis nem quaisquer dados derivados dele (como embeddings) para o Processador de aplicativos fora do contexto do TEE ou da Máquina Virtual Protegida, por hipervisor que atenda aos requisitos da Seção 9.17. O upgrade de dispositivos lançados com o Android 9 ou versões anteriores não está isento de C-2-7.
  • [C-2-8] PRECISA ter um pipeline de processamento seguro, de modo que um sistema o comprometimento do sistema ou kernel não pode permitir a injeção direta de dados se autenticar falsamente como usuário. Observação: se as implementações de dispositivos já tiverem sido lançadas no Android 9. ou anterior e não possa atender ao requisito C-2-8 por meio de um software de sistema eles poderão ser isentos dessa exigência.

  • [C-SR-10] É FORTEMENTE RECOMENDADO a inclusão da detecção de atividade para todos modalidades biométricas e detecção de atenção para a biometria facial.

  • [C-2-9] PRECISA disponibilizar o sensor biométrico para terceiros aplicativos conteinerizados.

Se as implementações de dispositivos quiserem tratar um sensor biométrico como Classe 3 (link em inglês) (anteriormente Forte), eles:

  • [C-3-1] PRECISA atender a todos os requisitos da Classe 2 acima, exceto [C-1-7] e [C-1-8].
  • [C-3-2] PRECISA ter uma implementação de keystore suportada por hardware.
  • [C-3-3] PRECISA ter uma taxa de aceitação de impostor e de spoofing não superior a 7%. com (1) uma taxa de aceitação de spoof e impostor para Espécies de instrumento de ataque de apresentação (PAI) de nível A não superior a 7% e (2) uma taxa de aceitação de impostor e de spoofing de espécies PAI de nível B não for maior que 20%, conforme medido pelo Protocolos de teste de biometria do Android.
  • [C-3-4] PRECISA desafiar o usuário na pergunta principal recomendada. autenticação (como PIN, padrão, senha) uma vez a cada 72 horas ou menos.
  • [C-3-5] PRECISA gerar novamente o ID do autenticador. para todas as biometrias de Classe 3 com suporte no dispositivo, se alguma delas for reinscreveu-se.
  • [C-3-6] É necessário ativar chaves de keystore com biometria para terceiros aplicativos conteinerizados.
  • [C-SR-16] É FORTEMENTE RECOMENDADO a ter uma paródia e um impostor taxa de aceitação não superior a 7% por espécie de instrumento de ataque de apresentação (PAI, na sigla em inglês), conforme medido pelo Protocolos de teste de biometria do Android. Se as implementações de dispositivos contiverem um sensor de impressão digital sob a tela (UDFPS, na sigla em inglês), eles:

  • [C-SR-11] É FORTEMENTE RECOMENDADO para evitar a área de toque do UDFPS interfira na navegação com três botões( que alguns usuários podem exigir para para fins de acessibilidade).

7.3.11. Sensor de posição

Implementações de dispositivos:

  • PODE suportar o sensor de pose com 6 graus de liberdade.

Se as implementações de dispositivos oferecerem suporte ao sensor de pose com 6 graus de liberdade, elas:

  • [C-1-1] PRECISA implementar e informar TYPE_POSE_6DOF sensor
  • [C-1-2] PRECISA ser mais preciso do que apenas o vetor de rotação.

7.3.12. Sensor de ângulo de dobradiça

Se as implementações de dispositivos oferecerem suporte a um sensor de ângulo de dobradiça, elas:

7.3.13. IEEE 802.1.15.4 (UWB)

Se as implementações de dispositivos incluírem suporte para 802.1.15.4 e exporem a a um aplicativo de terceiros, elas:

  • [C-1-2] PRECISA informar a flag de recurso de hardware android.hardware.uwb.
  • [C-1-3] PRECISA oferecer suporte a todos os conjuntos de configurações a seguir (predefinidos) combinações de parâmetros de FIRA UCI) definido na implementação do AOSP.
    • CONFIG_ID_1: alcance de STATIC STS DS-TWR unicast definido pela FiRa. modo adiado, com intervalo de 240 ms.
    • CONFIG_ID_2: intervalo de STATIC STS DS-TWR de um para muitos definido pela FiRa. modo adiado, intervalo de 200 ms. Caso de uso típico: smartphone interage com muitos dispositivos inteligentes.
    • CONFIG_ID_3: igual a CONFIG_ID_1, exceto ângulo de chegada (AoA) os dados não são informados.
    • CONFIG_ID_4: igual a CONFIG_ID_1, exceto pelo modo de segurança do P-STS. ativado.
    • CONFIG_ID_5: igual a CONFIG_ID_2, exceto pelo modo de segurança do P-STS. ativado.
    • CONFIG_ID_6: igual a CONFIG_ID_3, exceto pelo modo de segurança do P-STS. ativado.
    • CONFIG_ID_7: igual a CONFIG_ID_2, exceto pelo controle individual do P-STS. está ativado.
  • [C-1-4] PRECISA fornecer uma funcionalidade de usuário para permitir que ele alterne a UWB. ativado/desativado do rádio.
  • [C-1-5] PRECISA impor que os apps que usam a rádio UWB mantenham a UWB_RANGING. (no grupo de permissões NEARBY_DEVICES).

Ser aprovado nos testes de conformidade e certificação relevantes definidos pelo organizações, incluindo a FIRA, CCC e O CSA ajuda a garantir que o 802.1.15.4 funcione corretamente.

7,4. Conectividade de dados

7.4.1. Telefonia

"Telefonia" usado pelas APIs do Android. Este documento se refere especificamente a hardwares relacionados à realização de chamadas de voz e ao envio de mensagens SMS, ou estabelecer dados móveis por meio de uma rede móvel (por exemplo, GSM, CDMA, LTE, NR) GSM ou CDMA em uma rede VPC. Um dispositivo compatível com "Telefonia" pode optar por oferecer alguns ou todos de chamadas, mensagens e serviços de dados conforme se adequa ao produto.

  • O Android PODE ser usado em dispositivos que não incluem hardware de telefonia. Isso é que o Android é compatível com dispositivos que não são smartphones.

Se as implementações de dispositivos incluírem telefonia GSM ou CDMA, elas:

  • [C-1-1] PRECISA declarar a flag de recurso android.hardware.telephony e outras sinalizações de sub-recursos de acordo com a tecnologia.
  • [C-1-2] PRECISA implementar o suporte completo da API para essa tecnologia.
  • DEVE permitir todos os tipos de serviço de celular disponíveis (2G, 3G, 4G, 5G etc.) durante chamadas de emergência (independentemente dos tipos de rede definidos pelo SetAllowedNetworkTypeBitmap()).

Se as implementações de dispositivos não incluírem hardware de telefonia, elas:

  • [C-2-1] PRECISA implementar as APIs completas como ambiente autônomo.

Se as implementações de dispositivos oferecerem suporte a eUICCs ou eSIMs/chips incorporados e incluírem um mecanismo reservado para disponibilizar a funcionalidade de eSIM a terceiros desenvolvedores, ela:

Se as implementações de dispositivo não definirem a propriedade do sistema ro.telephony.iwlan\_operation\_mode como "legacy", elas:

Se as implementações de dispositivos oferecerem suporte a um único Subsistema multimídia IP (IMS, na sigla em inglês) nos serviços de telefonia multimídia (MMTEL) e recursos de Serviços de Comunicação Avançada (RCS) e precisam estar em conformidade com requisitos das operadoras de celular quanto ao uso de uma única registro IMS para todo o tráfego de sinalização IMS, eles:

Se as implementações de dispositivos informarem o recurso android.hardware.telephony:

Se as implementações do dispositivo informarem o recurso android.hardware.telephony e fornecer uma barra de status do sistema. Em seguida:

  • [C-7-1] É NECESSÁRIO selecionar uma assinatura ativa representativa para um determinado UUID de grupo para exibir ao usuário em recursos que forneçam status de chip informações imprecisas ou inadequadas. Exemplos de tais affordances incluem a barra de status celular, no ícone de indicador ou no bloco "Configurações rápidas".
  • [C-SR-1] É FORTEMENTE RECOMENDADO que a assinatura de representante seja escolhido para ser o assinatura de dados ativa a menos que o dispositivo tenha uma voz , durante o qual é FORTEMENTE RECOMENDADO que o representante é a assinatura do Voice ativo.

Se as implementações de dispositivos informarem o recurso android.hardware.telephony:

  • [C-6-7] PRECISA ser capaz de abrir e utilizar simultaneamente o máximo número de canais lógicos (20 no total) para cada UICC de acordo com o ETSI TS 102 221.
  • [C-6-8] NÃO É POSSÍVEL aplicar nenhum dos seguintes comportamentos a apps de operadoras ativos (conforme designado por TelephonyManager#getCarrierServicePackageName) automática ou sem confirmação explícita do usuário:
    • Revogar ou limitar o acesso à rede
    • Revogar permissões
    • Restringir a execução de apps em segundo ou primeiro plano além dos recursos de gerenciamento de energia atuais incluídos no AOSP
    • Desativar ou desinstalar o app

Se as implementações de dispositivos informarem o recurso android.hardware.telephony e todas ativas, inscrições não oportunistas que compartilham um UUID de grupo são desativados, removido fisicamente do dispositivo ou marcado como oportunista, faça o seguinte:

  • [C-8-1] É NECESSÁRIO desativar automaticamente todos os recursos ativos restantes oportunista no mesmo grupo.

Se as implementações de dispositivos incluírem a telefonia GSM, mas não a telefonia CDMA, elas:

Se as implementações do dispositivo oferecerem suporte a eUICCs com várias portas e perfis:

7.4.1.1 Compatibilidade com bloqueio de número

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

  • [C-1-1] PRECISA incluir suporte para bloqueio de número
  • [C-1-2] PRECISA implementar totalmente o BlockedNumberContract. e a API correspondente, conforme descrito na documentação do SDK.
  • [C-1-3] PRECISA bloquear todas as ligações e mensagens de um número de telefone "BlockedNumberProvider" sem interação com apps. A única exceção ocorre quando o bloqueio de número é temporariamente suspenso, conforme descrito no SDK na documentação do Google Cloud.

  • [C-1-4] PRECISA gravar no provedor de registro de chamadas da plataforma. para uma chamada bloqueada e PRECISA filtrar chamadas com BLOCKED_TYPE de visualização padrão do registro de chamadas no app discador pré-instalado.

  • [C-1-5] NÃO PODE fazer gravações no provedor de telefonia de uma mensagem bloqueada.

  • [C-1-6] PRECISA implementar uma interface de gerenciamento de números bloqueados, que é aberta com a intent retornada por TelecomManager.createManageBlockedNumbersIntent(). .

  • [C-1-7] NÃO PODE permitir que usuários secundários vejam ou editem os números bloqueados no dispositivo, já que a plataforma Android pressupõe que o usuário principal dos serviços de telefonia, em uma única instância, no dispositivo. Todos o bloqueio de interface relacionada PRECISA estar oculta para usuários secundários e a lista bloqueada PRECISA estar oculta para usuários secundários. sejam respeitadas.

  • DEVE migrar os números bloqueados para o provedor quando um dispositivo for atualizado para o Android 7.0.

  • DEVE fornecer uma funcionalidade de usuário para mostrar chamadas bloqueadas no de telefone.

7.4.1.2 API Telecom

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

  • [C-1-1] PRECISA oferecer suporte às APIs ConnectionService descritas no SDK.
  • [C-1-2] PRECISA exibir uma nova chamada recebida e fornecer funcionalidade ao usuário para Aceitar ou rejeitar a ligação recebida quando o usuário estiver em uma ligação por um app de terceiros sem suporte ao recurso de retenção especificado por CAPABILITY_SUPPORT_HOLD
  • [C-1-3] PRECISA ter um aplicativo que implemente InCallService (ambos em inglês).
  • [C-SR-1] É FORTEMENTE RECOMENDADO notificar o usuário de que responder a uma a ligação recebida vai encerrar a chamada em andamento.

    A implementação do AOSP atende a esses requisitos por uma notificação de alerta. que indica ao usuário que atender a uma chamada fará com que o outra chamada seja eliminada.

  • [C-SR-2] É FORTEMENTE RECOMENDADO pré-carregar o app discador padrão que mostra uma entrada do registro de chamadas e o nome de um app de terceiros no registro de chamadas quando o app de terceiros define EXTRA_LOG_SELF_MANAGED_CALLS tecla extras no PhoneAccount para true.

  • [C-SR-3] É FORTEMENTE RECOMENDADO para lidar com os Eventos KEYCODE_MEDIA_PLAY_PAUSE e KEYCODE_HEADSETHOOK para o android.telecom APIs, conforme abaixo:

    • Chamar Connection.onDisconnect() quando um pressionamento breve do evento de tecla é detectado durante uma chamada em andamento.
    • Chamar Connection.onAnswer() quando um pressionamento breve do evento de tecla é detectado durante uma ligação recebida.
    • Chamar Connection.onReject() quando um evento de tecla é pressionado durante uma ligação recebida.
    • Alterne o status de silenciamento da CallAudioState.
7.4.1.3 Descarregamento de sinal de atividade NAT-T da rede celular

Implementações de dispositivos:

  • DEVE incluir suporte para descarga de sinal de atividade de celular.

Se as implementações de dispositivos incluírem suporte para descarga de sinal de atividade celular e expõe a funcionalidade a apps de terceiros, elas:

  • [C-1-1] PRECISA oferecer suporte à API SocketKeepAlive.
  • [C-1-2] PRECISA oferecer suporte a pelo menos um slot de sinal de atividade simultâneo na rede celular.
  • [C-1-3] PRECISA oferecer suporte ao maior número possível de slots de sinal de atividade móveis simultâneos. compatíveis com a HAL de rádio celular.
  • [C-SR-1] É FORTEMENTE RECOMENDADO para oferecer suporte a pelo menos três sinais de atividade de celular por instância de rádio.

Se as implementações de dispositivos não incluírem suporte para descarga de sinal de atividade celular, eles:

  • [C-2-1] PRECISA retornar ERROR_UNSUPPORTED.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementações de dispositivos:

  • DEVE incluir suporte para uma ou mais formas de 802.11.

Se as implementações de dispositivos incluírem suporte para 802.11 e expõem a a um aplicativo de terceiros, elas:

  • [C-1-1] PRECISA implementar a API do Android correspondente.
  • [C-1-2] PRECISA informar a flag de recurso de hardware android.hardware.wifi.
  • [C-1-3] PRECISA implementar a API multicast. conforme descrito na documentação do SDK.

Iniciar novos requisitos para a versão 15 (AOSP experimental)

  • [C-1-4] PRECISA oferecer suporte a multicast DNS (mDNS) e NÃO PODE filtrar pacotes mDNS (224.0.0.251 ou ff02::fb) a qualquer momento de operação, incluindo quando a tela não está em um estado ativo, a menos que você descarte ou filtre esses pacotes necessário para se manter dentro das faixas de consumo de energia exigidas pelas aplicáveis ao mercado-alvo.

  • [C-1-4] PRECISA oferecer suporte a mDNS e NÃO PODE filtrar pacotes de mDNS (224.0.0.251 ou ff02::fb) a qualquer momento de operação, incluindo quando o não ficará ativo, a menos que o bloqueio multicast não seja mantido e os pacotes serão filtrados pelo APF. Os pacotes não precisam atender a nenhum Operações de mDNS solicitadas atualmente por aplicativos pelo NsdManager APIs de terceiros. No entanto, o dispositivo PODE filtrar pacotes mDNS se isso for necessário devem estar dentro das faixas de consumo de energia exigidas pelos requisitos regulamentares aplicáveis ao mercado-alvo.

Encerrar novos requisitos

  • [C-1-5] NÃO PODE tratar WifiManager.enableNetwork() chamada de método da API como indicação suficiente para alternar a atividade Network, que é usado por padrão para o tráfego do aplicativo e é retornado. por ConnectivityManager Métodos de API, como getActiveNetwork e registerDefaultNetworkCallback. Em outras palavras, eles só PODEM desativar o acesso à Internet fornecido por qualquer outro provedor de rede (por exemplo, dados móveis) se for validado se a rede Wi-Fi está fornecendo acesso à Internet.
  • [C-1-6] São FORTEMENTE RECOMENDADOS quando ConnectivityManager.reportNetworkConnectivity() o método da API for chamado, reavaliar o acesso à Internet no Network e quando a avaliação determina que o Network atual não fornece mais Acesso à Internet, mude para qualquer outra rede disponível (por exemplo, rede móvel) dados) que oferece acesso à Internet.
  • [C-1-7] PRECISA randomizar o endereço MAC de origem e o número da sequência da sondagem frames de solicitação, uma vez no início de cada verificação, enquanto o STA está desconectado.
  • [C-1-8] PRECISA usar um endereço MAC consistente (NÃO DEVE randomizar o MAC) na metade de uma verificação).
  • [C-1-9] PRECISA iterar o número da sequência da solicitação de sondagem normalmente (sequencialmente) entre as solicitações de sondagem em uma verificação.
  • [C-1-10] PRECISA randomizar o número da sequência da solicitação da sondagem entre a última sondagem solicitação de uma verificação e a primeira solicitação de sondagem da próxima verificação.
  • [C-SR-1] É FORTEMENTE RECOMENDADO para randomizar o endereço MAC de origem usado para toda a comunicação do STA a um ponto de acesso (AP) enquanto associa e associadas.
    • O dispositivo PRECISA usar um endereço MAC aleatório diferente para cada SSID. (FQDN para Passpoint) com que ele se comunica.
    • O dispositivo PRECISA oferecer ao usuário a opção de controlar o randomização por SSID (FQDN para Passpoint) com modelos aleatórias e PRECISA definir o modo padrão para as novas redes Wi-Fi. configurações sejam aleatórias.
  • [C-SR-2] É FORTEMENTE RECOMENDADO usar um BSSID aleatório para qualquer AP que criar.
    • O endereço MAC PRECISA ser aleatório e mantido de acordo com o SSID usado pelo AP.
    • O DISPOSITIVO PODE fornecer ao usuário a opção de desativar esse recurso. Se essa opção for fornecida, a ordem aleatória PRECISA estar ativada por padrão.

Se as implementações do dispositivo permitirem o modo de economia de energia Wi-Fi, conforme definido no padrão IEEE 802.11, eles:

  • DEVE desativar o modo de economia de energia Wi-Fi sempre que um app tiver Fechadura WIFI_MODE_FULL_HIGH_PERF ou WIFI_MODE_FULL_LOW_LATENCY fechadura por WifiManager.createWifiLock() eWifiManager.WifiLock.acquire() APIs e o bloqueio está ativo.
  • [C-3-2] A latência média de ida e volta entre o dispositivo e um ponto de acesso enquanto o dispositivo está em um bloqueio de baixa latência do Wi-Fi (WIFI_MODE_FULL_LOW_LATENCY) PRECISA ser menor que latência durante o modo Wi-Fi High Perf Lock (WIFI_MODE_FULL_HIGH_PERF).
  • [C-SR-3] É FORTEMENTE RECOMENDADO para minimizar a latência de ida e volta do Wi-Fi sempre que um bloqueio de baixa latência (WIFI_MODE_FULL_LOW_LATENCY) for adquirido e entra em vigor.

Se as implementações de dispositivos forem compatíveis com Wi-Fi e usarem Wi-Fi para buscar a localização, eles:

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 forem compatíveis com Wi-Fi Direct, elas:

  • [C-1-1] PRECISA implementar a API Android correspondente. conforme descrito na documentação do SDK.
  • [C-1-2] PRECISA informar o recurso de hardware android.hardware.wifi.direct.
  • [C-1-3] PRECISA permitir o funcionamento normal do Wi-Fi.
  • [C-1-4] PRECISA oferecer suporte a operações com Wi-Fi e Wi-Fi Direct simultaneamente.
  • [C-SR-1] É FORTEMENTE RECOMENDADO para randomizar o endereço MAC de origem para todos conexões Wi-Fi Direct recém-criadas.

Implementações de dispositivos:

Se as implementações de dispositivos incluírem suporte para TDLS e TDLS for ativado pelo API WiFiManager, eles:

  • [C-1-1] PRECISA declarar suporte a TDLS por meio de WifiManager.isTdlsSupported.
  • DEVE usar TDLS apenas quando for possível E benéfico.
  • DEVE ter alguma heurística e NÃO usar TDLS quando seu desempenho puder ser pior do que passar pelo ponto de acesso Wi-Fi.
7.4.2.3. Wi-Fi Aware

Implementações de dispositivos:

Caso as implementações do dispositivo incluam suporte ao Wi-Fi Aware e exponha a aplicativos de terceiros, elas:

  • [C-1-1] PRECISA implementar as APIs WifiAwareManager, conforme descrito nos Documentação do SDK.
  • [C-1-2] PRECISA declarar a flag de recurso android.hardware.wifi.aware.
  • [C-1-3] PRECISA oferecer suporte às operações Wi-Fi e Wi-Fi Aware simultaneamente.
  • [C-1-4] PRECISA randomizar o endereço da interface de gerenciamento do Wi-Fi Aware em intervalos de no máximo 30 minutos e sempre que o Wi-Fi Aware estiver ativado, a menos que o a operação de alcance está em andamento ou um caminho de dados do Aware está ativo (a ordem aleatória não está esperado, enquanto o caminho de dados estiver ativo).

Caso as implementações de dispositivos incluam suporte a Wi-Fi Aware e local do Wi-Fi, conforme descrito na Seção 7.4.2.5 e exponha essas funcionalidades a apps de terceiros, então elas:

7.4.2.4. Passpoint do Wi-Fi

Se as implementações de dispositivos forem compatíveis com 802.11 (Wi-Fi), elas:

  • [C-1-1] PRECISA incluir suporte ao Passpoint de Wi-Fi.
  • [C-1-2] PRECISA implementar as APIs WifiManager relacionadas ao Passpoint como descritos na documentação do SDK.
  • [C-1-3] PRECISA oferecer suporte ao padrão IEEE 802.11u, especificamente relacionados para descoberta e seleção de rede, como o anúncio genérico. (GAS) e Access Network Query Protocol (ANQP).
  • [C-1-4] PRECISA declarar a flag de recurso android.hardware.wifi.passpoint.
  • [C-1-5] PRECISA seguir a implementação do AOSP para descobrir, associar e associar a redes Passpoint.
  • [C-1-6] PRECISA oferecer suporte pelo menos ao seguinte subconjunto de provisionamento de dispositivos protocolos definidos no Passpoint R2 da Wi-Fi Alliance: EAP-TTLS. e SOAP-XML.
  • [C-1-7] PRECISA processar o certificado do servidor AAA conforme descrito em Especificação Hotspot 2.0 R3.
  • [C-1-8] PRECISA permitir o controle do usuário do provisionamento pelo seletor de Wi-Fi.
  • [C-1-9] PRECISA manter as configurações do Passpoint persistentes nas reinicializações.
  • [C-SR-1] É FORTEMENTE RECOMENDADO para aceitar os Termos e Condições recurso de aceitação.
  • [C-SR-2] É RECOMENDADO para oferecer suporte ao recurso de informações de locais.

Se um controle de desativação do usuário global do Passpoint for fornecido, as implementações:

  • [C-3-1] PRECISA ativar o Passpoint por padrão.
7.4.2.5 Local do Wi-Fi (tempo de retorno do Wi-Fi - RTT)

Implementações de dispositivos:

Se as implementações do dispositivo incluem suporte à localização por Wi-Fi e expõem a a aplicativos de terceiros, elas:

  • [C-1-1] PRECISA implementar as APIs WifiRttManager, conforme descrito nos Documentação do SDK.
  • [C-1-2] PRECISA declarar a flag de recurso android.hardware.wifi.rtt.
  • [C-1-3] PRECISA randomizar o endereço MAC de origem para cada burst de RTT que é executado enquanto a interface Wi-Fi na qual o RTT é sendo executado não está associado a um ponto de acesso.
  • [C-1-4] PRECISA ter precisão de até 2 metros na largura de banda de 80 MHz no 68o percentil (conforme calculado com a função de distribuição cumulativa).
  • [C-SR-1] É FORTEMENTE RECOMENDADO que você informe com precisão a uma distância de até 1,5 metro com largura de banda de 80 MHz no 68o percentil (conforme calculado com a função de distribuição cumulativa).
7.4.2.6. Descarregamento de sinal de atividade Wi-Fi

Implementações de dispositivos:

  • DEVE incluir suporte para descarga de sinal de atividade Wi-Fi.

Se as implementações de dispositivos incluírem suporte para descarga de sinal de atividade Wi-Fi e expõe a funcionalidade a apps de terceiros, eles:

  • [C-1-1] PRECISA oferecer suporte à API SocketKeepAlive.
  • [C-1-2] PRECISA aceitar pelo menos três slots de sinal de atividade simultâneos por Wi-Fi

Se as implementações de dispositivos não incluírem suporte para descarga de sinal de atividade Wi-Fi, eles:

7.4.2.7. Wi-Fi Easy Connect (protocolo de provisionamento de dispositivo)

Implementações de dispositivos:

Caso as implementações do dispositivo incluam suporte ao Wi-Fi Easy Connect e exponham a a aplicativos de terceiros, elas:

7.4.2.8. Validação do certificado do servidor Wi-Fi empresarial

Se o certificado do servidor Wi-Fi não for validado ou o servidor Wi-Fi nome de domínio não está definido, implementações de dispositivos:

  • [C-SR-1] É FORTEMENTE RECOMENDADO não fornecer ao usuário a opção de adicione manualmente a rede Wi-Fi empresarial no app Configurações.
7.4.2.9. Confiança no primeiro uso (TOFU)

Se as implementações de dispositivos forem compatíveis com a Confiança no primeiro uso (TOFU) e permitem que o usuário defina configurações WPA/WPA2/WPA3-Enterprise, então eles:

  • [C-4-1] PRECISA oferecer ao usuário a opção de usar o TOFU.

7.4.3. Bluetooth

Se as implementações de dispositivos oferecerem suporte ao perfil de áudio Bluetooth, elas:

  • DEVE oferecer suporte a codecs de áudio avançados e codecs de áudio Bluetooth (por exemplo, LDAC)

Se as implementações de dispositivos forem compatíveis com HFP, A2DP e AVRCP, elas:

  • DEVE oferecer suporte a pelo menos cinco dispositivos conectados no total.

Se as implementações do dispositivo declararem android.hardware.vr.high_performance eles:

  • [C-1-1] PRECISA oferecer suporte a Bluetooth 4.2 e à extensão de comprimento de dados Bluetooth LE.

O Android inclui suporte para Bluetooth e Bluetooth de baixa energia.

Se as implementações de dispositivos incluem suporte a Bluetooth e Bluetooth de baixa energia, eles:

  • [C-2-1] PRECISA declarar os recursos relevantes da plataforma (android.hardware.bluetooth e android.hardware.bluetooth_le respectivamente) e implementar as APIs da plataforma.
  • DEVE implementar perfis Bluetooth relevantes como A2DP, AVRCP, OBEX, HFP etc., conforme apropriado para o dispositivo.

Se as implementações de dispositivos incluírem suporte ao Bluetooth de baixa energia (BLE), elas:

  • [C-3-1] PRECISA declarar o recurso de hardware android.hardware.bluetooth_le.
  • [C-3-2] PRECISA ativar o Bluetooth baseado em GATT (perfil de atributo genérico). conforme descrito na documentação do SDK e android.bluetooth.
  • [C-3-3] PRECISA informar o valor correto para BluetoothAdapter.isOffloadedFilteringSupported() para indicar se o lógica de filtragem do ScanFilter, As classes de API são implementadas.
  • [C-3-4] PRECISA informar o valor correto para BluetoothAdapter.isMultipleAdvertisementSupported() para indicar se a publicidade de baixa energia é compatível.
  • [C-3-5] PRECISA implementar um tempo limite de endereço particular solucionável (RPA, na sigla em inglês) de 15 minutos e alternar o endereço no tempo limite para proteger a privacidade do usuário quando o dispositivo está usando BLE ativamente para verificação ou publicidade. Para evitar ataques de temporização, os intervalos de tempo limite também PRECISAM ser aleatórios. entre 5 e 15 minutos.

  • 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 leitura em lote para o chipset Bluetooth.

  • DEVE ser compatível com vários anúncios com pelo menos quatro espaços.

Se as implementações de dispositivos forem compatíveis com Bluetooth LE e usarem Bluetooth LE para verificação de local, eles:

  • [C-4-1] PRECISA fornecer uma funcionalidade do usuário para ativar/desativar a leitura de valor. pela API do sistema BluetoothAdapter.isBleScanAlwaysAvailable().

Se as implementações de dispositivos incluem suporte a Bluetooth LE e aparelhos auditivos do seu perfil, conforme descrito em Suporte para áudio de aparelho auditivo usando Bluetooth LE, eles:

Se as implementações de dispositivos incluírem suporte a Bluetooth ou Bluetooth de baixa energia (BLE), eles:

  • [C-6-1] PRECISA restringir o acesso a metadados Bluetooth (como leitura resultados) que podem ser usados para obter a localização do dispositivo, a menos que O app solicitante transmite um android.permission.ACCESS_FINE_LOCATION verificação de permissão com base no estado atual em primeiro/segundo plano.

Se as implementações do dispositivo incluem suporte a Bluetooth ou Bluetooth de baixa energia (BLE) e o manifesto do app não incluir uma declaração do desenvolvedor informando se não estão derivando a localização por Bluetooth, então, eles:

Se as implementações de dispositivos retornarem true para o API BluetoothAdapter.isLeAudioSupported(), eles:

  • [C-7-1] PRECISA oferecer suporte ao cliente unicast.
  • [C-7-2] PRECISA oferecer suporte a 2 milhões de PHY.
  • [C-7-3] PRECISA oferecer suporte à publicidade estendida de LE.
  • [C-7-4] PRECISA oferecer suporte a pelo menos duas conexões CIS em um CIG.
  • [C-7-5] É NECESSÁRIO habilitar o cliente BAP unicast, o coordenador de conjunto CSIP, o servidor MCP Controlador VCP e servidor CCP simultaneamente.
  • [C-SR-1] É FORTEMENTE RECOMENDADO para ativar o cliente unicast HAP.

Se as implementações de dispositivos retornarem true para o API BluetoothAdapter.isLeAudioBroadcastSourceSupported(), eles:

  • [C-8-1] PRECISA oferecer suporte a pelo menos dois links BIS em uma GRANDE.
  • [C-8-2] É NECESSÁRIO ativar a fonte de transmissão BAP e o assistente de transmissão BAP ao mesmo tempo.
  • [C-8-3] PRECISA oferecer suporte à publicidade LE Periodic.

Se as implementações de dispositivos retornarem true para o API BluetoothAdapter.isLeAudioBroadcastAssistantSupported(), eles:

  • [C-9-1] PRECISA oferecer suporte a PAST (Transferência periódica de sincronização de publicidade).
  • [C-9-2] PRECISA oferecer suporte à publicidade LE Periodic.

Se as implementações de dispositivo declararem FEATURE_BLUETOOTH_LE, elas:

  • [C-10-1] PRECISA ter medições de RSSI dentro de +/-9 dB para 95% dos medidas a 1 m de distância de um dispositivo de referência que transmite a ADVERTISE_TX_POWER_HIGH no ambiente de linha de visão.
  • [C-10-2] PRECISA incluir correções de Rx/Tx para reduzir os desvios por canal. para que as medidas em cada um dos três canais, em cada uma das antenas (se forem usados vários), estão dentro de +/-3 dB um do outro por 95% do medições.
  • [C-SR-2] É FORTEMENTE RECOMENDADO para medir e compensar o deslocamento de Rx para garantir que o RSSI médio do BLE seja -60 dBm +/-10 dB a 1 m de distância de um transmissão de dispositivo de referência em ADVERTISE_TX_POWER_HIGH, onde os dispositivos são são orientados de forma que estejam em "planos paralelos" com telas voltadas para o mesmo direção
  • [C-SR-3] É FORTEMENTE RECOMENDADO para medir e compensar o deslocamento de transação para garantir que o RSSI do BLE médio seja de -60 dBm +/-10 dB ao verificar uma referência dispositivo posicionado a 1 m de distância e transmitindo a ADVERTISE_TX_POWER_HIGH, em que os dispositivos são orientados de modo que estejam "planos paralelos" com telas voltadas para a mesma direção.

É RECOMENDADO seguir as etapas de configuração de medição especificadas no Requisitos para a calibragem de presença.

7.4.4. Comunicação a curta distância (NFC, na sigla em inglês)

Implementações de dispositivos:

  • DEVE incluir um transceptor e hardware relacionado para o recurso Near-Field Comunicações (NFC, na sigla em inglês).
  • [C-0-1] PRECISA implementar android.nfc.NdefMessage e APIs do android.nfc.NdefRecord mesmo que não incluam suporte para NFC ou declarar o recurso android.hardware.nfc, já que as classes representam formato de representação de dados independente de protocolo.

Se as implementações de dispositivos incluem hardware NFC e planeja disponibilizá-lo para apps de terceiros, ela:

  • [C-1-1] PRECISA informar o recurso android.hardware.nfc da método android.content.pm.PackageManager.hasSystemFeature().
  • PRECISA ser capaz de ler e gravar mensagens NDEF usando as seguintes tecnologias NFC padrão, conforme abaixo:
  • [C-1-2] PRECISA atuar como leitor/gravador do Fórum NFC (conforme definido pelas especificações técnicas do NFC Forum NFCForum-TS-Digital Protocol-1.0) por meio dos seguintes padrões NFC:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS X 6.319-4)
    • IsoDep (ISO 14443-4)
    • Tipos de tags do fórum NFC 1, 2, 3, 4, 5 (definidos pelo fórum NFC)
  • [C-SR-1] É FORTEMENTE RECOMENDADO que precisa ler e gravar NDEF mensagens, bem como dados brutos por meio dos seguintes padrões NFC. Observe que enquanto os padrões NFC forem indicados como FORTEMENTE RECOMENDADOS, os A definição de compatibilidade para uma versão futura está planejada para alterar estas como PRECISA. Esses padrões são opcionais nesta versão, mas serão obrigatórios em versões futuras. Dispositivos novos e existentes que executam esta versão do Recomendamos que o Android atenda a esses requisitos. poderão fazer upgrade para as próximas versões da plataforma.

  • [C-1-13] PRECISA pesquisar todas as tecnologias compatíveis durante a descoberta NFC modo

  • DEVE estar no modo de descoberta NFC enquanto o dispositivo estiver ativado com o tela ativa e a tela de bloqueio desbloqueada.

  • DEVE ser capaz de ler o código de barras e o URL (se codificado) de Código de barras NFC Thinfilm produtos.

Observe que links disponíveis publicamente não estão disponíveis para as especificações JIS, ISO e NFC Especificações do fórum citadas acima.

O Android inclui suporte ao modo de emulação de cartão host de NFC (HCE, na sigla em inglês).

Se as implementações de dispositivos incluírem um chipset controlador NFC capaz de HCE (por NfcA e/ou NfcB) e que aceitam roteamento de ID do aplicativo (AID), elas:

  • [C-2-1] PRECISA informar a constante de recurso android.hardware.nfc.hce.
  • [C-2-2] PRECISA oferecer suporte a APIs NFC HCE como definido no SDK do Android.

Se as implementações de dispositivos incluírem um chipset controlador NFC compatível com HCE para NfcF e implementar o recurso para aplicativos de terceiros, eles:

  • [C-3-1] PRECISA informar a constante de recurso android.hardware.nfc.hcef.
  • [C-3-2] PRECISA implementar as APIs de emulação de cartão NFC conforme definido no SDK do Android.

Caso as implementações de dispositivos incluam suporte geral a NFC, conforme descrito neste e oferecer suporte a tecnologias MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF no MIFARE Classic) na função de leitor/gravador, eles:

  • [C-4-1] PRECISA implementar as APIs do Android correspondentes, conforme documentado por SDK do Android.
  • [C-4-2] PRECISA informar o recurso com.nxp.mifare da android.content.pm.PackageManager.hasSystemFeature() . Esse não é um recurso padrão do Android e, portanto, não aparecem como uma constante na classe android.content.pm.PackageManager.

7.4.5. APIs e protocolos de rede

7.4.5.1. Capacidade mínima de rede

Implementações de dispositivos:

  • [C-0-1] PRECISA incluir suporte para uma ou mais formas de nas redes de dados. Especificamente, as implementações de dispositivos PRECISAM incluir suporte para 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 e PAN com Bluetooth.
  • Também DEVE incluir suporte para pelo menos um sistema de dados sem fio como o 802.11 (Wi-Fi), quando um padrão de rede física Ethernet) é a principal conexão de dados.
  • PODE implementar mais de uma forma de conectividade de dados.
7.4.5.2. IPv6

Implementações de dispositivos:

  • [C-0-2] PRECISA incluir uma pilha de rede IPv6 e oferecer suporte a IPv6 comunicação usando as APIs gerenciadas, como java.net.Socket e java.net.URLConnection, além das APIs nativas, como AF_INET6 soquetes.
  • [C-0-3] PRECISA ativar o IPv6 por padrão.
    • PRECISA garantir que a comunicação do IPv6 seja tão confiável quanto do IPv4, por exemplo:
      • [C-0-4] PRECISA manter a conectividade IPv6 no modo Soneca.
      • [C-0-5] A limitação de taxa NÃO PODE fazer com que o dispositivo perca o IPv6 conectividade em qualquer rede compatível com IPv6 que use ciclos de vida de RA de de pelo menos 180 segundos.
  • [C-0-6] PRECISA fornecer aplicativos de terceiros com conectividade IPv6 direta à rede quando conectado a uma rede IPv6, sem qualquer forma de endereço ou a conversão de portas ocorre localmente no dispositivo. As duas APIs gerenciadas, como Socket#getLocalAddress ou Socket#getLocalPort) e as APIs do NDK, como getsockname() ou IPV6_PKTINFO, PRECISAM retornar o IP e porta que é realmente usado para enviar e receber pacotes na e visível como o IP de origem e a porta para servidores de Internet (Web).

O nível necessário de suporte a IPv6 depende do tipo de rede, como mostrado no os requisitos a seguir.

Se as implementações de dispositivos forem compatíveis com Wi-Fi, elas:

  • [C-1-1] PRECISA oferecer suporte à operação de pilha dupla e somente IPv6 no Wi-Fi.

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

  • [C-2-1] PRECISA oferecer suporte à operação de pilha dupla e somente IPv6 Ethernet.

Se as implementações de dispositivos forem compatíveis com dados móveis, elas:

  • [C-3-1] PRECISA oferecer suporte à operação IPv6 (somente IPv6 e possivelmente de pilha dupla) ativada rede celular.

Se as implementações de dispositivos oferecem suporte a mais de um tipo de rede (por exemplo, Wi-Fi e dados móveis), eles:

  • [C-4-1] PRECISA cumprir simultaneamente os requisitos acima em cada rede quando o dispositivo está conectado simultaneamente a mais de um tipo de rede.
7.4.5.3. Portais cativos

Um portal cativo se refere a uma rede que exige login para ter acesso à Internet.

Se as implementações de dispositivos fornecerem uma implementação completa do android.webkit.Webview API, eles:

  • [C-1-1] PRECISA fornecer um aplicativo de portal cativo para lidar com a intent ACTION_CAPTIVE_PORTAL_SIGN_IN e exibir a página de login do portal cativo enviando essa intent chamada para a API do sistema ConnectivityManager#startCaptivePortalApp(Network, Bundle).
  • [C-1-2] É NECESSÁRIO detectar os portais cativos e fazer login de suporte pelo aplicativo de portal cativo quando o dispositivo estiver conectado a qualquer tipo de rede, incluindo celular/móvel, Wi-Fi, Ethernet ou Bluetooth.
  • [C-1-3] PRECISA oferecer suporte ao login em portais cativos usando DNS de texto não criptografado quando o dispositivo está configurado para usar o modo restrito de DNS particular.
  • [C-1-4] PRECISA usar DNS criptografado, de acordo com a documentação do SDK, android.net.LinkProperties.getPrivateDnsServerName e android.net.LinkProperties.isPrivateDnsActive todo o tráfego de rede que não está se comunicando explicitamente com o portal cativo.
  • [C-1-5] PRECISA garantir que, enquanto o usuário fizer login em um do portal, a rede padrão usada por aplicativos (conforme retornado pelo ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback, e usada por padrão por APIs de rede Java, como java.net.Socket, e APIs nativas, como connect()) é qualquer outra rede disponível que fornece acesso à Internet, se disponível.

7.4.6. Configurações de sincronização

Implementações de dispositivos:

  • [C-0-1] PRECISA manter a configuração de sincronização automática principal ativada por padrão para que o método getMasterSyncAutomatically() retorna "true".

7.4.7. Economia de dados

Se as implementações de dispositivos incluírem uma conexão limitada, elas serão:

  • [C-SR-1] É MUITO RECOMENDADO fornecer o modo de economia de dados.

Se as implementações de dispositivos oferecerem o modo de economia de dados, elas:

  • [C-1-1] PRECISA oferecer suporte a todas as APIs do ConnectivityManager. conforme descrito na documentação do SDK

Se as implementações de dispositivos não oferecerem o modo de economia de dados, elas:

7.4.8. Elementos de segurança

Se as implementações de dispositivos forem compatíveis com a API Open Mobile elementos de segurança e disponibilizá-los para aplicativos de terceiros, eles:

7.4.9. UWB

Se as implementações de dispositivos tiverem suporte para 802.1.15.4 e expor a funcionalidade a um aplicativo de terceiros, então eles:

  • [C-1-1] PRECISA implementar a API do Android correspondente no android.uwb.
  • [C-1-2] PRECISA informar a flag de recurso de hardware android.hardware.uwb.
  • [C-1-3] PRECISA oferecer suporte a todos os perfis de UWB relevantes definidos no Android. implementação.
  • [C-1-4] PRECISA fornecer uma funcionalidade de usuário para permitir que ele alterne a UWB. ativado/desativado do rádio.
  • [C-1-5] PRECISA exigir que os apps que usam o recurso UWB mantenham a permissão UWB_RANGING (no grupo de permissões NEARBY_DEVICE).
  • [C-SR-1] É FORTEMENTE RECOMENDADO para passar na conformidade e de certificação definidos por organizações padrão, incluindo FIRA e CCC e CSA.
  • [C-1-6] PRECISA garantir que as medidas de distância estejam dentro de +/-15 cm para 95% das medidas no ambiente da linha de visão a 1 m de distância em um câmara não reflexiva.
  • [C-1-7] PRECISA garantir que a mediana das medidas de distância a 1 m do dispositivo de referência está dentro de [0,75 m, 1,25 m], onde as informações empíricas é medida a partir da borda superior do DUT.
  • [C-SR-2] É FORTEMENTE RECOMENDADO seguir as etapas de configuração da medição especificado em Requisitos para a calibragem de presença.

7,5. Cameras

Se as implementações de dispositivos incluírem pelo menos uma câmera, elas:

  • [C-1-1] PRECISA declarar a flag de recurso android.hardware.camera.any.
  • [C-1-2] PRECISA ser possível para um aplicativo alocar simultaneamente 3 bitmaps RGBA_8888 iguais ao tamanho das imagens produzidas pelo com a maior resolução do dispositivo, enquanto a câmera está aberta para o para fins de visualização básica e ainda captura.
  • [C-1-3] PRECISA garantir que o aplicativo padrão de câmera pré-instalado processamento de intents MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE, ou MediaStore.ACTION_VIDEO_CAPTURE, é responsável por remover a localização do usuário nos metadados da imagem antes enviá-lo para o aplicativo receptor quando o aplicativo receptor têm ACCESS_FINE_LOCATION.

Se as implementações de dispositivos forem compatíveis com a capacidade de saída HDR de 10 bits, elas:

  • [C-2-1] PRECISA oferecer suporte pelo menos ao perfil HLG HDR em todos os dispositivos de câmera. com suporte a saída de 10 bits.
  • [C-2-2] PRECISA oferecer suporte à saída de 10 bits para a interface traseira principal ou câmera frontal principal.
  • [C-SR-1] É FORTEMENTE RECOMENDADO oferecer suporte à saída de 10 bits para o primário câmeras.
  • [C-2-3] PRECISA oferecer suporte aos mesmos perfis HDR para todos BACKWARD_COMPATIBLE subcâmeras físicas de uma câmera lógica e a própria câmera lógica.

Para dispositivos de câmera lógica com suporte a HDR de 10 bits que implementam API android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO, eles:

  • [C-3-1] PRECISA oferecer suporte à alternância entre todas as redes físicas compatíveis com versões anteriores câmeras pelo controle CONTROL_ZOOM_RATIO na câmera lógica.

7.5.1. Câmera traseira

Uma câmera traseira é uma câmera voltada para o mundo que captura cenas do outro lado do dispositivo, como uma câmera tradicional; em dispositivos portáteis, localizado na lateral do dispositivo em frente à tela.

Implementações de dispositivos:

  • DEVE incluir uma câmera traseira.

Se as implementações de dispositivos incluírem pelo menos uma câmera traseira, elas:

  • [C-1-1] PRECISA 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 em hardware ou em software implementado no driver da câmera (transparente ao software do aplicativo).
  • PODE ter hardware de foco fixo ou EDOF (profundidade de campo estendida).
  • PODE incluir um flash.

Se a câmera tiver flash:

  • [C-2-1] a lâmpada do flash NÃO PODE estar acesa enquanto um android.hardware.Camera.PreviewCallback instância foi registrada em uma superfície de visualização da Câmera, a menos que o aplicativo tenha ativado 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 integrado de câmera do sistema do dispositivo, mas somente aplicativos usando Camera.PreviewCallback.

7.5.2. Câmera frontal

Uma câmera frontal é uma câmera voltada ao usuário que normalmente é usada para imagens o usuário, como para videoconferências e aplicativos semelhantes; no portátil dispositivos, que é uma câmera localizada no mesmo lado do dispositivo que a tela.

Implementações de dispositivos:

  • PODE incluir uma câmera frontal.

Se as implementações de dispositivos incluírem pelo menos uma câmera frontal, elas:

  • [C-1-1] PRECISA 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 PODE usar uma câmera frontal como padrão para o Camera e NÃO PODE configurar a API para tratar uma câmera frontal como a câmera traseira padrão, mesmo que ela seja a única 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 tem solicitou explicitamente que a câmera ser girada por meio de uma chamada para o android.hardware.Camera.setDisplayOrientation() . Por outro lado, a visualização PRECISA ser espelhada na imagem padrão do dispositivo. eixo horizontal quando o aplicativo atual não solicita explicitamente que o visor da câmera seja girado por meio de uma chamada ao android.hardware.Camera.setDisplayOrientation() .
  • [C-1-5] NÃO É POSSÍVEL espelhar a imagem estática final ou os streams de vídeo capturados retornados aos callbacks de aplicativos ou confirmados com o armazenamento de mídia.
  • [C-1-6] PRECISA espelhar a imagem exibida pelo pós-visualização da mesma maneira como o stream de imagem de visualização da câmera.
  • PODE incluir recursos (como autofoco, flash etc.) disponíveis para câmeras traseiras, conforme descrito na seção 7.5.1.

Se as implementações do dispositivo puderem ser rotacionadas pelo usuário (como automaticamente por meio de um acelerômetro ou manualmente por 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

Uma câmera externa pode ser conectada ou desconectada fisicamente a implementação do dispositivo a qualquer momento e pode estar voltada para qualquer direção; como USB câmeras.

Implementações de dispositivos:

  • PODE incluir suporte para uma câmera externa que não seja necessariamente sempre conectados.

Se as implementações de dispositivos forem compatíveis com uma câmera externa, elas:

  • [C-1-1] PRECISA declarar a flag de recurso da plataforma android.hardware.camera.external e android.hardware camera.any.
  • [C-1-2] DEVE oferecer suporte à classe de vídeo USB (UVC 1.0 ou superior) se o a câmera se conecta pela porta do host USB.
  • [C-1-3] PRECISA passar nos testes de CTS da câmera com um dispositivo físico externo de câmera conectados. Detalhes dos testes CTS da câmera estão disponíveis em source.android.com.
  • DEVE oferecer suporte a compactação de vídeo, como MJPEG, para permitir a transferência de transmissões não codificadas de alta qualidade (por exemplo, imagens brutas ou com compactação independente córregos).
  • PODE oferecer suporte a várias câmeras.
  • PODE oferecer suporte à codificação de vídeo baseada em câmera.

Se a codificação de vídeo baseada na câmera for compatível:

  • [C-2-1] Uma simultaneidade uma transmissão não codificada / MJPEG (QVGA ou resolução superior) PRECISA estar acessível a a implementação do dispositivo.

7.5.4. Comportamento da API Camera

O Android inclui dois pacotes de API para acessar a câmera, a mais recente A API android.hardware.camera2 expõe o controle da câmera de nível inferior ao app, incluindo fluxos de burst/streaming de cópia zero eficientes e controles por frame do exposição, ganho, ganhos de balanço de branco, conversão de cor, remoção de ruído, nitidez, e muito mais.

O pacote de API mais antigo,android.hardware.Camera, está marcado como descontinuado em Android 5.0, mas ainda deve estar disponível para uso dos apps. Dispositivo Android implementações PRECISAM garantir o suporte contínuo da API, conforme descrito em nesta seção e no SDK do Android.

Todos os recursos comuns entre a classe descontinuada android.hardware.Camera e o pacote android.hardware.camera2 mais recente PRECISA ter desempenho equivalente e qualidade nas duas APIs. Por exemplo, com configurações equivalentes, a velocidade e a precisão do autofoco devem ser idênticas, e a qualidade das imagens capturadas devem ser iguais. Recursos que dependem da semântica diferente das duas APIs não precisam ter velocidade ou qualidade correspondentes, mas DEVEM ser o mais possível.

As implementações de dispositivos PRECISAM implementar os seguintes comportamentos para os APIs relacionadas à câmera para todas as câmeras disponíveis. Implementações de dispositivos:

  • [C-0-1] É NECESSÁRIO usar android.hardware.PixelFormat.YCbCr_420_SP para visualização dados fornecidos aos callbacks de aplicativo 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 um android.hardware.Camera.PreviewCallback instância e o sistema chama o método onPreviewFrame(), e o comando formato for YCbCr_420_SP, os dados no byte[] transmitidos para onPreviewFrame(). Ou seja, NV21 PRECISA ser o padrão.
  • [C-0-3] PRECISA oferecer suporte ao formato YV12 (conforme indicado pelo android.graphics.ImageFormat.YV12) para visualizações de câmera para ambos. câmeras frontal e traseira para android.hardware.Camera. (O hardware o codificador de vídeo e a câmera podem usar qualquer formato de pixel nativo, mas o dispositivo implementação PRECISA ser compatível com a conversão para YV12.)
  • [C-0-4] PRECISA oferecer suporte às APIs android.hardware.ImageFormat.YUV_420_888 e android.hardware.ImageFormat.JPEG formata como saídas usando o API android.media.ImageReader para dispositivos android.hardware.camera2 que anunciar REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE em android.request.availableCapabilities.
  • [C-0-5] Ainda PRECISA implementar a API Camera completa. estão incluídos na documentação do SDK do Android, mesmo que o dispositivo inclui autofoco em hardware ou outros recursos. Por exemplo, câmeras que sem o autofoco PRECISA chamar as campanhas android.hardware.Camera.AutoFocusCallback instâncias (mesmo que não tenham relevância para uma câmera sem foco automático. Isso se aplica a casos de uso câmeras; por exemplo, embora a maioria das câmeras frontal não suportem autofoco, os callbacks de API ainda precisam ser "falsos" conforme descrito.
  • [C-0-6] PRECISA reconhecer e respeitar os nomes de cada parâmetro. definida como uma constante android.hardware.Camera.Parameters e a classe android.hardware.camera2.CaptureRequest. Por outro lado, as implementações de dispositivos NÃO PODEM respeitar ou reconhecer constantes de string transmitidos para o método android.hardware.Camera.setParameters() diferentes dos 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 de câmera se o o hardware permite e NÃO PODE oferecer suporte a tipos personalizados de parâmetros de câmera. Por exemplo, implementações de dispositivos compatíveis com a captura de imagem que usam técnicas de geração de imagens de High Dynamic Range (HDR) PRECISAM oferecer suporte ao parâmetro de câmera. Camera.SCENE_MODE_HDR:
  • [C-0-7] PRECISA informar o nível adequado de suporte com o android.info.supportedHardwareLevel , conforme descrito no SDK do Android e informe a propriedade sinalizações de recursos do framework.
  • [C-0-8] PRECISA declarar também as capacidades individuais da câmera de android.hardware.camera2 pelo android.request.availableCapabilities propriedade e declarar as flags de recurso adequadas. PRECISA definir a flag de recurso se alguma câmera estiver conectada oferece suporte ao recurso.
  • [C-0-9] PRECISA transmitir o Camera.ACTION_NEW_PICTURE. intenção sempre que uma nova foto é tirada pela câmera e a entrada do imagem foi adicionada ao armazenamento de mídia.
  • [C-0-10] PRECISA transmitir o Camera.ACTION_NEW_VIDEO. intenção sempre que um novo vídeo for gravado pela câmera e a entrada do imagem foi adicionada ao armazenamento de mídia.
  • [C-0-11] PRECISA ter todas as câmeras acessíveis com a versão descontinuada android.hardware.Camera API também acessível via android.hardware.camera2 API.
  • [C-0-12] PRECISA garantir que a aparência facial NÃO seja alterada, incluindo a alteração da geometria facial, do tom de pele facial suavização de pele para qualquer android.hardware.camera2 ou android.hardware.Camera API.
  • [C-SR-1] Para dispositivos com várias câmeras RGB perto e virados na mesma direção, é FORTEMENTE RECOMENDADO oferecer suporte a um dispositivo de câmera lógico que liste capacidade CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, e consiste em todas as câmeras RGB voltadas para essa direção como subdispositivos físicos.

Se as implementações do dispositivo fornecerem uma API de câmera reservada para apps de terceiros, eles:

7.5.5. Orientação da câmera

Se as implementações do dispositivo tiverem uma câmera frontal ou traseira, tais câmeras:

  • [C-1-1] PRECISA estar orientada de modo que a dimensão longa da câmera se alinhe com a dimensão longa da tela. Ou seja, quando o dispositivo é mantido no modo paisagem as câmeras PRECISAM capturar imagens na orientação paisagem. Isso se aplica independentemente da orientação natural do dispositivo; ou seja, ela se aplica dispositivos principais no modo paisagem e dispositivos principais no modo retrato.

Os dispositivos que atenderem a todos os critérios a seguir estão isentos do requisito acima:

  • O dispositivo implementa telas de geometria variável, como dobráveis ou articuladas. é exibido.
  • Quando o estado da dobra ou articulação do dispositivo muda, ele alterna entre orientação retrato principal para paisagem principal (ou vice-versa).
  • Implementações de dispositivo que não podem ser rotacionadas pelo usuário, como como dispositivos automotivos.

7,6. Memória e armazenamento

7.6.1. Mínimo de memória e armazenamento

Implementações de dispositivos:

  • [C-0-1] PRECISA incluir um Gerenciador de downloads que os aplicativos PODEM usar para baixar arquivos de dados e DEVEM ser capazes de o download de arquivos individuais de pelo menos 100 MB para o padrão "cache" o local.

7.6.2. Armazenamento compartilhado do aplicativo

Implementações de dispositivos:

  • [C-0-1] PRECISA oferecer armazenamento para ser compartilhado por aplicativos, também conhecidos como como "armazenamento externo compartilhado", "armazenamento compartilhado do app" ou pelo serviço Linux Caminho "/sdcard" em que ele é montado.
  • [C-0-2] PRECISA ser configurado com armazenamento compartilhado montado por padrão, em outros "pronto para uso", independentemente de o armazenamento ter sido implementado um componente de armazenamento interno ou uma mídia de armazenamento removível (por exemplo, Secure slot para cartão digital).
  • [C-0-3] É NECESSÁRIO montar o armazenamento compartilhado do aplicativo diretamente no caminho do Linux sdcard ou inclua um link simbólico do Linux de sdcard para a montagem real. ponto
  • [C-0-4] É NECESSÁRIO ativar armazenamento com escopo por padrão para todas Aplicativos direcionados ao nível de API 29 ou superior, exceto nas seguintes situações:
    • Quando o app solicitar android:requestLegacyExternalStorage="true" no manifesto.
  • [C-0-5] PRECISA encobrir os metadados de local, como as tags GPS Exif, armazenados em arquivos de mídia quando esses arquivos forem acessados pelo MediaStore, exceto quando o app de chamada tem a permissão ACCESS_MEDIA_LOCATION.

As implementações de dispositivos PODEM atender aos requisitos acima usando um dos seguinte:

  • Armazenamento removível acessível pelo usuário, como um slot para cartão SD.
  • Uma parte do armazenamento interno (não removível) conforme implementado no Android Open Source Project (AOSP).

Se as implementações do dispositivo usarem armazenamento removível para atender aos requisitos acima requisitos, eles:

  • [C-1-1] PRECISA implementar um aviso ou uma interface pop-up que avisa o usuário quando não há mídia de armazenamento inserida no slot.
  • [C-1-2] PRECISA incluir um programa ou mídia de armazenamento com formato FAT (por exemplo, cartão SD) na caixa e em outros materiais disponíveis no momento da compra que o armazenamento mídia deve ser adquirida separadamente.

Se as implementações de dispositivos usarem uma parte do armazenamento não removível para atender os requisitos acima, eles:

  • DEVE usar a implementação do AOSP do app interno compartilhado armazenamento.
  • PODE compartilhar o espaço de armazenamento com os dados privados do aplicativo.

Se as implementações de dispositivos tiverem uma porta USB com suporte ao modo de periférico USB, eles:

  • [C-3-1] PRECISA fornecer um mecanismo para acessar os dados no aplicativo o armazenamento compartilhado em um computador host.
  • DEVE expor o conteúdo de ambos os caminhos de armazenamento de forma transparente por meio de Serviço de verificação de mídia do Android e android.provider.MediaStore.
  • PODE usar armazenamento USB em massa, mas DEVE usar Media Transfer Protocol para satisfazer esse requisito.

Se as implementações de dispositivos tiverem uma porta USB com suporte e modo de periférico USB Media Transfer Protocol, eles:

  • DEVE ser compatível com o host do Android MTP de referência, 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 se espera que o dispositivo seja móvel por natureza, diferentemente da televisão, implementações de dispositivos são:

  • [C-SR-1] É MUITO RECOMENDADO implementar o armazenamento adotável na um local estável de longo prazo, já que desconectá-los 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 tampa de proteção, implementações de dispositivos são:

7,7. USB

Se as implementações de dispositivos tiverem uma porta USB, elas:

  • DEVE oferecer suporte ao modo de periférico USB e DEVE oferecer suporte ao modo host USB.
  • DEVE ser compatível com a desativação da sinalização de dados por USB.

7.7.1. Modo USB periférico

Se as implementações de dispositivos incluírem uma porta USB compatível com o modo de periféricos:

  • [C-1-1] A porta PRECISA estar conectada a um host USB com padrão uma porta USB tipo A ou C.
  • [C-1-2] PRECISA informar o valor correto de iSerialNumber no padrão USB. descritor do dispositivo usando android.os.Build.SERIAL.
  • [C-1-3] PRECISA detectar carregadores de 1,5 A e 3,0 A pelo resistor tipo C. padrão e PRECISA detectar as alterações no anúncio, caso sejam compatíveis USB-C.
  • [C-SR-1] A porta DEVE usar o formato USB micro-B, micro-AB ou tipo C. É altamente RECOMENDADO dispositivos Android novos e já existentes para atender a esses requisitos requisitos para que possam fazer upgrade para as versões futuras da plataforma.
  • [C-SR-2] A porta DEVE estar localizada na parte de baixo do dispositivo (de acordo com a orientação natural) ou ativar a rotação da tela do software para todos os apps (incluindo a tela inicial), para que a tela desenhe corretamente quando o dispositivo está orientado com a porta na parte inferior. Android atual e novo dispositivos são AVALIMENTE RECOMENDADOS para atender a esses requisitos para que atualizar para futuras versões da plataforma.
  • [C-SR-3] DEVE implementar suporte para puxar corrente de 1,5 A durante o sinal de HS e o tráfego, conforme especificado na Especificação de carregamento de bateria USB, revisão 1.2. É altamente RECOMENDADO dispositivos Android novos e já existentes para atender a esses requisitos requisitos para que possam fazer upgrade para as versões futuras da plataforma.
  • [C-SR-4] É FORTEMENTE RECOMENDADO não oferecer suporte a proprietários que modificam a tensão Vbus além dos níveis padrão ou alteram de coletor/origem, dessa forma, podem causar problemas de interoperabilidade com o carregadores ou dispositivos que oferecem suporte aos métodos padrão de fornecimento de energia USB. isso é chamado de " FORTEMENTE RECOMENDADO". Em versões futuras do Android, pode EXIGIR todos os dispositivos tipo C para oferecer suporte à interoperabilidade total com carregadores tipo C.
  • [C-SR-5] É MUITO RECOMENDADO oferecer suporte ao Power Delivery para dados e troca de função de energia quando eles forem compatíveis com os modos de host USB e USB Type-C.
  • DEVE oferecer suporte ao Power Delivery para carregamento de alta tensão e suporte para Modos alternativos, como exibição externa.
  • DEVE implementar a API e a especificação do Android Open Accessory (AOA) na documentação do SDK do Android.

Se as implementações de dispositivos incluem uma porta USB e implementam a AOA especificação, eles:

  • [C-2-1] PRECISA 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" em fim da string de descrição da interface iInterface do armazenamento USB em massa

7.7.2. Modo host USB

Se as implementações de dispositivos incluírem uma porta USB compatível com o modo host, elas:

  • [C-1-1] PRECISA implementar a API de host USB do Android, conforme documentado nas SDK do Android e PRECISA declarar suporte para o recurso de hardware android.hardware.usb.host
  • [C-1-2] É NECESSÁRIO implementar suporte para conectar periféricos USB padrão Em outras palavras, eles PRECISAM:
    • Ter uma porta tipo C no dispositivo ou enviar com cabos que se adaptam a um dispositivo para uma porta USB-C padrão (dispositivo USB-C).
    • Ter um dispositivo tipo A ou enviar com cabos adaptados a um dispositivo para uma porta USB-A padrão.
    • Ter uma porta micro-AB no dispositivo, que DEVE ser enviada com um cabo adaptativo para uma porta padrão tipo A.
  • [C-1-3] NÃO PODE enviar com um adaptador que converta de USB tipo A ou Portas micro-AB para uma porta tipo C (receptáculo).
  • [C-SR-1] É FORTEMENTE RECOMENDADO para 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 enquanto estiver no host modo anunciando uma fonte atual de pelo menos 1,5 A, conforme especificado Parâmetros de rescisão do Revisão 1.2 das especificações do cabo e do conector USB-C para USB-C de saída ou usar a porta de encaminhamento de carregamento (CDP, na sigla em inglês) de saída da faixa atual conforme especificado no Especificações de carregamento de bateria USB, revisão 1.2 para conectores Micro-AB.
  • DEVE implementar e oferecer suporte aos padrões USB-C.

Se as implementações de dispositivos incluírem uma porta USB compatível com o modo host e o USB classe de áudio, eles:

  • [C-2-1] PRECISA oferecer suporte à classe HID USB.
  • [C-2-2] PRECISA oferecer suporte à detecção e ao mapeamento dos seguintes dados HID. campos especificados nas Tabelas de uso de HID USB e a Solicitação de uso do Voice Command para o KeyEvent da seguinte forma:
    • ID de uso da página de uso (0xC) (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
    • ID de uso da página de uso (0xC) (0x0E9): KEYCODE_VOLUME_UP
    • ID de uso da página de uso (0xC) (0x0EA): KEYCODE_VOLUME_DOWN
    • ID de uso da página de uso (0xC) (0x0CF): KEYCODE_VOICE_ASSIST

Se as implementações de dispositivos incluem uma porta USB compatível com o modo host e Framework de acesso ao armazenamento (SAF, na sigla em inglês), eles:

  • [C-3-1] PRECISA reconhecer qualquer MTP (protocolo de transferência de mídia) conectado remotamente dispositivos e tornar o conteúdo deles acessível pela ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT e ACTION_CREATE_DOCUMENT. .

Se as implementações de dispositivos incluírem uma porta USB compatível com o modo host e USB Digite C, eles:

  • [C-4-1] PRECISA implementar a funcionalidade de porta de função dupla, conforme definido pelo USB. Especificação Tipo C (seção 4.5.1.3.3). Para duplo Portas de função, em dispositivos que incluem entrada para fone de ouvido de 3,5 mm, o coletor USB (modo host) PODE estar desativada por padrão, mas DEVE ser possível para o para ativá-lo.
  • [C-SR-2] É RECOMENDADO O EXEMPLO DE Compatibilidade com DisplayPort (deve ser compatível com USB) Taxas de dados SuperSpeed e é MUITO RECOMENDADO para oferecer suporte ao Power Delivery para a troca de papéis de dados e poder.
  • [C-SR-3] É RECOMENDADO NÃO oferecer suporte ao modo de acessório do adaptador de áudio como descritos no Apêndice A Revisão 1.2 das especificações do cabo e do conector USB-C.
  • DEVE implementar o modelo Try.* mais apropriado para o formato do dispositivo. Por exemplo, um dispositivo portátil DEVE implementar a Modelo Try.SNK.

7,8. Áudio

7.8.1. Microfone

Se as implementações de dispositivos incluírem um microfone, elas:

  • [C-1-1] PRECISA informar a constante de recurso android.hardware.microphone.
  • [C-1-2] PRECISA atender aos requisitos de gravação de áudio em seção 5.4.
  • [C-1-3] PRECISA atender aos requisitos de latência de áudio seção 5.6.
  • [C-SR-1] É FORTEMENTE RECOMENDADO para oferecer suporte à gravação quase ultrassônica, conforme descrito na seção 7.8.3.

Se as implementações de dispositivos omitirem um microfone, elas:

  • [C-2-1] NÃO PODE informar a constante de recurso android.hardware.microphone.
  • [C-2-2] PRECISA implementar a API de gravação de áudio pelo menos como ambiente autônomo, seção 7.

7.8.2. Saída de áudio

Se as implementações do dispositivo incluírem um alto-falante ou uma saída de áudio/multimídia para um periférico de saída de áudio, como uma entrada para fone de ouvido de 4 condutores de 3,5 mm ou Porta do modo host USB usando a classe de áudio USB, eles:

  • [C-1-1] PRECISA informar a constante de recurso android.hardware.audio.output.
  • [C-1-2] PRECISA atender aos requisitos de reprodução de áudio em seção 5.5.
  • [C-1-3] PRECISA atender aos requisitos de latência de áudio seção 5.6.
  • [C-SR-1] É MUITO RECOMENDADO para oferecer suporte à reprodução quase ultrassônica, conforme descrito na seção 7.8.3.

Se as implementações de dispositivos não incluírem uma porta de saída de áudio ou alto-falante, elas:

  • [C-2-1] NÃO É POSSÍVEL informar o recurso android.hardware.audio.output.
  • [C-2-2] PRECISA implementar as APIs relacionadas à saída de áudio como um ambiente autônomo.

Para os fins desta seção, uma "porta de saída" é um interface física como entrada de áudio de 3, 5 mm, HDMI ou porta de modo host USB com classe de áudio USB. Suporte para saída de áudio por protocolos baseados em rádio, como Bluetooth, Uma rede Wi-Fi ou celular não inclui uma "porta de saída".

7.8.2.1. Portas de áudio analógico

Para ser compatível com o fones de ouvido e outros acessórios de áudio usando o plugue de áudio de 3,5 mm em todo o ecossistema Android, se o dispositivo incluem uma ou mais portas de áudio analógico. São elas:

  • [C-SR-1] É FORTEMENTE RECOMENDADO a inclusão de pelo menos um dos uma ou mais portas de áudio precisam ser uma entrada para fone de ouvido de 3,5 mm com 4 condutores.

Se as implementações do dispositivo tiverem uma entrada para fone de ouvido de 3,5 mm com quatro condutores, elas:

  • [C-1-1] É NECESSÁRIO oferecer suporte à reprodução de áudio para fones de ouvido estéreo ou estéreo. com um microfone.
  • [C-1-2] PRECISA oferecer suporte a plugues de áudio TRRS com a ordem de pinagem CTIA.
  • [C-1-3] PRECISA oferecer suporte à detecção e ao mapeamento dos códigos de tecla da seguindo três intervalos de impedância equivalentes entre o microfone e o solo condutores no plugue de áudio:
    • 70 ohm ou menos: KEYCODE_HEADSETHOOK
    • 210–290 ohm: KEYCODE_VOLUME_UP
    • 360-680 ohm: KEYCODE_VOLUME_DOWN
  • [C-1-4] PRECISA acionar ACTION_HEADSET_PLUG na inserção de um plugue, mas somente depois que todos os contatos no plugue estiverem tocando nos segmentos relevantes na entrada.
  • [C-1-5] PRECISA ser capaz de operar com pelo menos 150 mV ± 10% da tensão de saída uma impedância de alto-falante de 32 ohm.
  • [C-1-6] PRECISA ter uma tensão de polarização de microfone entre 1,8 V e 2,9 V.
  • [C-1-7] PRECISA detectar e mapear para o código de tecla das seguintes intervalo de impedância equivalente entre o microfone e os condutores de terra no plugue de áudio:
    • 110-180 ohm: KEYCODE_VOICE_ASSIST
  • [C-SR-2] É FORTEMENTE RECOMENDADO a compatibilidade com plugues de áudio com o OMTP de descarte.
  • [C-SR-3] É FORTEMENTE RECOMENDADO para oferecer suporte à gravação de áudio estéreo fones de ouvido com microfone.

Se as implementações do dispositivo tiverem uma entrada para fone de ouvido de 3,5 mm com quatro condutores e forem compatíveis com uma microfone e transmitir android.intent.action.HEADSET_PLUG com o de valor extra definido como 1, ele:

  • [C-2-1] PRECISA oferecer suporte à detecção de microfone no áudio conectado. acessório.
7.8.2.2. Portas digitais de áudio

Consulte a Seção 2.2.1 para ver os requisitos específicos dos dispositivos.

7.8.3. Quase ultrassom

O áudio quase ultrassom é a banda de 18,5 kHz a 20 kHz.

Implementações de dispositivos:

  • PRECISA relatar corretamente o suporte dos de áudio quase ultrassom AudioManager.getProperty (link em inglês) API da seguinte maneira:

Se PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND for "true", os seguintes requisitos PRECISAM ser atendidos pelo 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 estar no máximo 15 dB abaixo da resposta a 2 kHz.
  • [C-1-2] O sinal não ponderado do microfone para a proporção de ruído acima de 18,5 kHz a 20 kHz para um tom de 19 kHz a -26 dBFS PRECISA ser no máximo 50 dB.

Se PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND é "true":

  • [C-2-1] A resposta média do alto-falante em 18,5 kHz a 20 kHz PRECISA ser inferior a 40 dB abaixo da resposta a 2 kHz.

7.8.4. Integridade do sinal

Implementações de dispositivos:

  • DEVE fornecer um caminho de sinal de áudio sem falhas para as entradas e streams de saída em dispositivos portáteis, conforme definido por zero falhas medido durante um teste de um minuto por caminho. Testar usando o OboeTester "Teste de falhas automatizado".

O teste requer um dongle de loopback de áudio. usado diretamente em uma entrada de 3,5 mm e/ou em combinação com um adaptador de USB-C para 3,5 mm. Todas as portas de saída de áudio DEVEM ser testadas.

O OboeTester atualmente oferece suporte a caminhos AAudio, portanto, as seguintes combinações DEVEM ser testadas em busca de falhas usando a AAudio:

Modo de desempenho Compartilhamento Taxa de amostragem de saída Em Poss Out Poss
BAIXO_LATÊNCIA EXCLUSIVO NÃO ESPECIFICADO 1 2
BAIXO_LATÊNCIA EXCLUSIVO NÃO ESPECIFICADO 2 1
BAIXO_LATÊNCIA COMPARTILHADO NÃO ESPECIFICADO 1 2
BAIXO_LATÊNCIA COMPARTILHADO NÃO ESPECIFICADO 2 1
NENHUMA COMPARTILHADO 48000 1 2
NENHUMA COMPARTILHADO 48000 2 1
NENHUMA COMPARTILHADO 44100 1 2
NENHUMA COMPARTILHADO 44100 2 1
NENHUMA COMPARTILHADO 16000 1 2
NENHUMA COMPARTILHADO 16000 2 1

Um stream confiável DEVE atender aos seguintes critérios de sinal para ruído Proporção (SNR, na sigla em inglês) e Distorção harmônica total (THD) para 2.000 Hz seno.

Transdutor THD SNR
Alto-falante integrado principal, medido com um microfone de referência externo < 3,0% >= 50 dB
microfone integrado principal, medido com um alto-falante de referência externo < 3,0% >= 50 dB
Entradas de 3,5 mm analógicas integradas, testadas com o adaptador de loopback Menos de 1% >= 60 dB
Adaptadores USB fornecidos com o telefone, testados com o adaptador de loopback < 1,0% >= 60 dB

7,9. Realidade virtual

O Android inclui APIs e instalações para criar a "Realidade virtual" (RV) aplicativos, incluindo experiências de RV com alta qualidade para dispositivos móveis. Dispositivo implementações DEVEM implementar corretamente essas APIs e esses comportamentos, conforme detalhado nesta seção.

7.9.1. Modo de realidade virtual

O Android inclui suporte a Modo RV, um recurso que lida com a renderização estereoscópica de notificações e desativa componentes da interface do sistema monocular enquanto um aplicativo de RV tem o foco do usuário.

7.9.2. Modo de realidade virtual: alto desempenho

Se as implementações de dispositivos oferecerem suporte ao modo RV, elas:

  • [C-1-1] PRECISA ter pelo menos dois núcleos físicos.
  • [C-1-2] PRECISA declarar o recurso android.hardware.vr.high_performance.
  • [C-1-3] PRECISA oferecer suporte ao modo de desempenho sustentado.
  • [C-1-4] PRECISA oferecer suporte ao OpenGL ES 3.2.
  • [C-1-5] PRECISA oferecer suporte a android.hardware.vulkan.level 0.
  • DEVE oferecer suporte a android.hardware.vulkan.level 1 ou mais recente.
  • [C-1-6] PRECISA 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, EGL_EXT_image_gl_colorspace, e expor as extensões na lista de extensões EGL disponíveis.
  • [C-1-8] PRECISA implementar GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures, e expor as extensões na lista de extensões GL disponíveis.
  • [C-SR-1] É FORTEMENTE RECOMENDADO a implementação GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture, e expor as extensões na lista de extensões GL disponíveis.
  • [C-SR-2] É FORTEMENTE RECOMENDADO para oferecer suporte ao Vulkan 1.1.
  • [C-SR-3] É FORTEMENTE RECOMENDADO a implementação VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image, e a exponha na lista de extensões do Vulkan disponíveis.
  • [C-SR-4] É FORTEMENTE RECOMENDADO expor pelo menos uma família de filas do Vulkan em que flags contêm VK_QUEUE_GRAPHICS_BIT e VK_QUEUE_COMPUTE_BIT, e queueCount é pelo menos 2.
  • [C-1-7] A GPU e a tela PRECISAM sincronizar o acesso ao buffer frontal, de modo que a renderização de olhos alternados do conteúdo de RV a 60 fps com dois contextos de renderização serão exibidos sem artefatos de ruptura visíveis.
  • [C-1-9] PRECISA implementar o suporte para AHardwareBuffer. sinalizações AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA e AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT conforme descrito no NDK.
  • [C-1-10] PRECISA implementar suporte para AHardwareBuffers com qualquer combinação das flags de uso AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT para pelo menos os seguintes formatos: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
  • [C-SR-5] É FORTEMENTE RECOMENDADO para oferecer suporte à alocação de AHardwareBuffers com mais de uma camada e flags e formatos especificados em C-1-10.
  • [C-1-11] PRECISA oferecer suporte à decodificação H.264 de pelo menos 3.840 x 2.160 a 30 fps, compactado a uma média de 40 Mbps (equivalente a 4 instâncias de 1.920 x 1.080 a 30 fps a 10 Mbps ou duas instâncias de 1.920 x 1.080 a 60 fps a 20 Mbps).
  • [C-1-12] PRECISA oferecer suporte a HEVC e VP9. Precisa ser capaz de decodificar pelo menos 1920 x 1080 a 30 fps, comprimido a uma média de 10 Mbps e DEVE ser capaz de decodificar 3.840 x 2.160 a 30 fps a 20 Mbps (equivalente a 4 instâncias de 1.920 x 1.080 a 30 fps a 5 Mbps).
  • [C-1-13] PRECISA oferecer suporte à API HardwarePropertiesManager.getDeviceTemperatures. e retornar valores precisos para a temperatura