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.

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:

• [7.1.4.2/H-1-1] PRECISA atender aos requisitos. especificados pelo perfil de referência do Android 2021.

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:

• [7.1.4.6/H-1-1] PRECISA informar como saída uma rastro protobuf que está em conformidade com o esquema de contadores de GPU e GPU Renderstages definidos na documentação do Perfetto (links em inglês).
• [7.1.4.6/H-1-2] PRECISA informar os valores em conformidade para os contadores de GPU do dispositivo seguindo o proto do pacote de trace do contador de gpu.
• [7.1.4.6/H-1-3] PRECISA informar os valores em conformidade para os RenderStages da GPU do dispositivo após o proto do pacote de trace do estágio de renderização.
• [7.1.4.6/H-1-4] PRECISA informar uma frequência de GPU. tracepoint, conforme especificado pelo formato: power/gpu_frequency.

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)

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 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)

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:

• [7.10/H]* DEVE verificar o status da implementação executando android.os.Vibrator.areAllEffectssupported() e android.os.Vibrator.arePrimitivesSuporte() APIs de terceiros.

• [7,10/H]* DEVE realizar uma avaliação de qualidade para constantes táteis.

• [7.10/H]* DEVE verificar e atualizar o substituto, se necessário configuração para primitivos não suportados, conforme descrito nas orientações para implementação para constantes.

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:

• [3.9/H-1-1] PRECISA implementar toda a gama de administração de dispositivos políticas definidas na documentação do SDK do Android.

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:

• [3.8.16/H-2-1] PRECISA informar null para a ControlsProviderService e o Control APIs de terceiros.
• [3.8.16/H-2-2] PRECISA declarar o recurso sinalizar android.software.controls e a defina como false.

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:

• [7.5.4/H-1-1] PRECISA respeitar o android.media.action.STILL_IMAGE_CAMERA. e android.media.action.STILL_IMAGE_CAMERA_SECURE e inicializar a câmera em modo de imagem estática, conforme descrito no SDK.
• [7.5.4/H-1-2] PRECISA respeitar o android.media.action.VIDEO_CAMERA. de iniciar a câmera em modo de vídeo, conforme descrito no SDK.

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

• [3.2.3.1/ H-1-1] PRECISA ter uma atividade que gerencie Settings#ACTION_CONFIG_EMBED_DEEP_LINK_ACTIVITY quando a funcionalidade de divisão estiver ativada. A atividade PRECISA ser protegida android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK e PRECISA iniciar a atividade da intent analisada Configurações#EXTRA_CONFIG_EMBEDDED_DEEP_LINK_INTENT_URI.

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

• [7.4.1.2/H-0-1] PRECISA declarar a flag de recurso android.software.telecom.
• [7.4.1.2/H-0-2] PRECISA implementar o framework de telecomunicações.

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:

• [8.4/H-1-1] PRECISA respeitar o android.intent.action.POWER_USAGE_SUMMARY e exibirá um menu de configurações que mostra esse consumo de energia.

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)

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)

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)

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)

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)

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:

• PRECISA atender aos requisitos de mídia listados na seção 2.2.7.1 do CDD do Android 14.

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

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

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

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

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

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

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

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

• [5.2/H-2-1] PRECISA atender à meta mínima de qualidade definida pelo vídeo. curvas de distorção da taxa do codificador para codecs AVC e HEVC de hardware, conforme definido em Executar testes de classe de desempenho 14 (PC14): qualidade de codificação de vídeo (VEQ, na sigla em inglês).

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:

• PRECISA atender aos requisitos de mídia listados na seção 2.2.7.2 do CDD do Android 14.

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

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

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

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:

• PRECISA atender aos requisitos de mídia listados na seção 2.2.7.3 do CDD do Android 14.

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

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

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:

• PRECISA atender aos requisitos de desempenho listados na seção 2.2.7.4 do CDD do Android 14.

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

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

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:

• [5.3.3/T-0-1] MPEG-4 SP
• [5.3.4/T-0-2] H.264 AVC
• [5.3.5/T-0-3] H.265 HEVC
• [5.3.6/T-0-4] VP8
• [5.3.7/T-0-5] VP9
• [5.3.1/T-0-6] MPEG-2
• [5.3.2/T-0-7] AV1

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)

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

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:

• [8.3/T-1-2] PRECISA registrar o dispositivo como um dispositivo sem bateria, conforme descrito em Suporte a dispositivos sem bateria.

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)

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)

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:

• [7.1.4.2/W-1-1] PRECISA atender aos requisitos. especificados pelo perfil de referência do Android 2021.

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 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:

• [7.1.4.2/A-1-1] PRECISA atender aos requisitos. especificados pelo perfil de referência do Android 2021.

Implementações de dispositivos automotivos:

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

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

• [7.2.3/A-0-2] PRECISA enviar os comandos normal e longo Evento da função Voltar (KEYCODE_BACK) para o aplicativo em primeiro plano.
• [7.3/A-0-1] PRECISA implementar e informar GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED e PARKING_BRAKE_ON.
• [7.3/A-0-2] O valor do atributo NIGHT_MODE PRECISA ser consistente com o modo dia/noite do painel e DEVE se basear na do sensor de luz ambiente. O sensor de luz ambiente pode ser o mesmo como Photometer.
• [7.3/A-0-3] PRECISA fornecer o campo de informações adicionais do sensor. TYPE_SENSOR_PLACEMENT como parte de SensorAdditionalInfo para cada sensor fornecido.
• [7.3/A-SR1] Pode estar em dúvida sobre o local combinando GPS/GNSS com sensores adicionais. Se Local não foi reconhecido, é MUITO RECOMENDADO implementar e informar os Sensor correspondente tipos e/ou IDs de propriedade do veículo usados.

• [7.3/A-0-4] O local solicitada por LocationManager#requestLocationUpdates() NÃO PODE haver correspondência no mapa.

• [7.3.1/A-0-4] PRECISA estar em conformidade com a sistema de coordenadas do sensor de carros.

• [7.3/A-SR-1] São STRONGLY_RECOMMENDED para incluir um eixo acelerômetro e giroscópio de 3 eixos.

• [7.3/A-SR-2] São STRONGLY_RECOMENDADOS para implementar e informar Sensor TYPE_HEADING.

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

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)

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

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:

• [7.5/A-7-1] PRECISA implementar essa API de câmera usando o android.hardware.camera2 ou a API Extended View System.

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 forem de 64 bits:

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

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)

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)

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)

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:

• [3.9.3/A-1-1] PRECISA implementar todos os Propriedades do ciclo de vida do usuário
  • INITIAL_USER_INFO, SWITCH_USER, CREATE_USER, REMOVE_USER.

Implementações de dispositivos automotivos:

• [3.14/A-0-1] PRECISA incluir um framework de interface para dar suporte aplicativos de terceiros que usam as APIs de mídia, conforme descrito na seção 3,14.
• [3.14/A-0-2] PRECISA permitir que o usuário interaja com segurança com aplicativos de mídia ao dirigir.
• [3.14/A-0-3] PRECISA ser compatível com o CAR_INTENT_ACTION_MEDIA_TEMPLATE uma ação de intent implícita com CAR_EXTRA_MEDIA_PACKAGE extra.
• [3.14/A-0-4] PRECISA fornecer uma affordance para navegar de um aplicativo de mídia preferência atividade, mas PRECISA ativá-la apenas quando as Restrições de UX para carros não estiverem em vigor.
• [3.14/A-0-5] PRECISA exibir mensagens de erro definido por aplicativos de mídia e PRECISA oferecer suporte aos extras opcionais ERROR_RESOLUTION_ACTION_LABEL e ERROR_RESOLUTION_ACTION_INTENT.
• [3.14/A-0-6] PRECISA ser compatível com uma funcionalidade de pesquisa no app para apps compatíveis com a pesquisa.
• [3.14/A-0-7] PRECISA respeitar! CONTENT_STYLE_BROWSABLE_HINT e CONTENT_STYLE_PLAYABLE_HINT definições ao exibir o MediaBrowser hierarquia.

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

• [3.14/A-1-1] PRECISA incluir serviços de mídia e abri-los. com o CAR_INTENT_ACTION_MEDIA_TEMPLATE intenção.

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:

• [9.5/A-1-1] NÃO PODE permitir que os usuários interajam com nem mudar para o usuário do sistema headless, exceto para o provisionamento de dispositivos.
• [9.5/A-1-2] PRECISA mudar para um Usuário secundário. antes de BOOT_COMPLETED.
• [9.5/A-1-3] PRECISA oferecer suporte à capacidade de criação um usuário convidado mesmo quando o número máximo de usuários em um dispositivo for atingido.

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)

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)

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 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)

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_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_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_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_32_BIT_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_64_BIT_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_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_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_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:

• [C-1-1] PRECISA respeitar o android.settings.HOME_SETTINGS. para mostrar um menu de configurações padrão do app na tela inicial.

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

• [C-2-1] PRECISA fornecer um menu de configurações que chame a função android.provider.Telephony.ACTION_CHANGE_DEFAULT para mostrar uma caixa de diálogo para alterar o aplicativo de SMS padrão.

• [C-2-2] PRECISA respeitar o android.telecom.action.CHANGE_DEFAULT_DIALER. de mostrar uma caixa de diálogo para permitir que o usuário altere a configuração Telefone padrão para o aplicativo.

  • PRECISA usar a interface do app Telefone padrão selecionada pelo usuário para chamadas recebidas e chamadas realizadas, exceto para chamadas de emergência, que usariam o Telefone pré-instalado.

• [C-2-3] PRECISA respeitar android.telecom.action.CHANGE_PHONE_ACCOUNTS. para fornecer affordance ao usuário para configurar o ConnectionServices. associados ao PhoneAccounts, conforme assim como uma PhoneAccount padrão que o provedor de serviços de telecomunicações usar para efetuar chamadas. A implementação do AOSP atende a esse requisito incluindo uma "opção para chamadas em "Chamadas", no menu de configurações.

• [C-2-4] PRECISA permitir android.telecom.CallRedirectionService. para um app que contém a android.app.role.CALL_REDIRECTION de rede.

• [C-2-5] PRECISA fornecer ao usuário affordance para escolher um app que tenha a android.app.role.CALL_REDIRECTION de rede.

• [C-2-6] PRECISA respeitar a solicitação android.intent.action.SENDTO. e android.intent.action.VIEW e fornecem uma atividade para enviar/exibir mensagens SMS.

• [C-SR-1] É FORTEMENTE RECOMENDADO para respeitar android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_Button, android.intent.action.VIEW e android.intent.action.DIAL com um aplicativo discador pré-carregado que pode lidar com essas intents e fornecer o fulfillment conforme descrito no SDK.

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

• [C-3-1] PRECISA respeitar as android.settings.NFC_PAYMENT_CONFIG. intenção de mostrar um menu de configurações padrão do app para pagamento por aproximação.
• [C-3-2] PRECISA respeitar android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT. para mostrar uma atividade que abre uma caixa de diálogo para pedir que o usuário mude a serviço de emulação de cartão padrão para uma determinada categoria, conforme descrito no SDK.

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

• [C-4-1] PRECISA respeitar as intents android.nfc.action.NDEF_DISCOVERED. android.nfc.action.TAG_DISCOVERED (link em inglês) e android.nfc.action.TECH_DISCOVERED para mostrar uma atividade que atende às expectativas do desenvolvedor para essas intents como descritos no SDK.

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

• [C-5-1] PRECISA respeitar a permissão 'android.bluetooth.adapter.action.REQUEST_ENABLE'. e mostrar uma atividade do sistema para permitir que o usuário ative o Bluetooth.
• [C-5-2] PRECISA respeitar "android.bluetooth.adapter.action.REQUEST_DISCOVERABLE" e mostrar uma atividade do sistema que solicita o modo detectável.

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:

• [C-7-1] PRECISA fornecer um mecanismo acessível ao usuário para adicionar e configurar métodos de entrada de terceiros em resposta à android.settings.INPUT_METHOD_SETTINGS intenção.

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:

• [C-9-1] PRECISA implementar Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI. APIs de intent conforme descrito na documentação do SDK.

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

• [C-10-1] PRECISA fornecer nas configurações uma interface do usuário que gerencie Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS permitindo que os usuários adicionem ou removam aplicativos a lista de permissões.

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

• [C-11-1] PRECISA ter uma atividade para lidar com Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS mas PODE implementá-lo como um ambiente autônomo.

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

• [C-12-3] PRECISA processar e permitir apenas apps Android pré-instalados para processar as seguintes intents MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE, e MediaStore.ACTION_VIDEO_CAPTURE conforme descrito no documento do SDK.

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

• [C-13-1] PRECISA respeitar a intent android.app.action.ADD_DEVICE_ADMIN. invocar uma interface para levar o usuário à adição do administrador do dispositivo ao pelo sistema (ou permitir que ele a rejeite).

• [C-13-2] PRECISA respeitar as intents. android.app.action.PROVISION_MANAGED_PROFILE. android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD e android.app.action.START_ENCRYPTION e ter uma atividade para fornecer o fulfillment para essas intents, conforme descrito no SDK aqui.

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

• [C-14-1] PRECISA implementar totalmente o AutofillService. e AutofillManager e respeitar a política android.settings.REQUEST_SET_AUTOFILL_SERVICE, de mostrar um menu de configurações de aplicativo padrão para ativar e desativar o preenchimento automático e alterar o serviço de preenchimento automático padrão para o usuário.

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:

• [C-18-1] PRECISA respeitar o android.settings.ACTION_VOICE_INPUT_SETTINGS. de mostrar um menu de configurações padrão do app para entrada de texto por voz e assistência.

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:

• [C-19-1] PRECISA implementar o NfcAdapter.ACTION_TRANSACTION_DETECTED. API Intent (como "EVT_TRANSACTION" definida pela especificação técnica TS.26 da GSM Association - Requisitos do celular NFC).

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-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:
  • cache do app/operação off-line
  • <vídeo> tag
  • geolocalização
• [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. BC – com.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:

• [C-2-1] PRECISA informar true para ShortcutManager.isRequestPinShortcutSupported().
• [C-2-2] PRECISA ter affordance do usuário antes de adicionar um atalho solicitado. por apps usando o ShortcutManager.requestPinShortcut() Método de API.
• [C-2-3] PRECISA oferecer suporte a atalhos fixados e a atalhos dinâmicos e estáticos conforme documentado na página Atalhos de apps.

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

• [C-3-1] PRECISA informar false para ShortcutManager.isRequestPinShortcutSupported().

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:

• [C-2-1] PRECISA informar true para AppWidgetManager.html.isRequestPinAppWidgetSupported().
• [C-2-2] PRECISA ter affordance do usuário antes de adicionar um atalho solicitado. por apps usando o AppWidgetManager.requestPinAppWidget() Método de API.

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

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.

• As implementações de dispositivos podem modificar os atributos de tema padrão do dispositivo expostos a aplicativos conteinerizados.

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,

• [C-1-2] PRECISA mostrar o status atual do local. no menu "Local" em "Configurações".
• [C-1-3] NÃO PODE mostrar os modos de localização no menu "Local" em "Configurações".

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)

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)

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)

3.9.1.2 Provisionamento de perfil gerenciado

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

• [C-1-1] PRECISA implementar as APIs. permitindo que um aplicativo controlador de política de dispositivo (DPC) se torne o proprietário de um novo Perfil gerenciado.

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

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

• [C-2-1] As implementações de dispositivos PRECISAM ser compatíveis com o provisionamento sem um dispositivo aplicativo detentor da função de gerenciamento de políticas O AOSP oferece uma implementação de referência.

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:

• [C-1-1] PRECISA resolver os conflitos de políticas do dispositivo, conforme documentado em Framework de resolução de políticas do dispositivo.

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:

• [C-1-1] PRECISA oferecer suporte à Framework de TTS do Android APIs de terceiros.

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

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:

• [C-1-1] PRECISA declarar a flag de recurso FEATURE_COMPANION_DEVICE_SETUP. ,
• [C-1-2] PRECISA garantir que as APIs no android.companion totalmente implementado.

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

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

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:

• [C-3-1] Frames de áudio PCM de 16 bits em ordem nativa de bytes por meio do android.media.MediaCodec API.

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:

• [C-6-1] Frames de áudio PCM de 16 bits em ordem nativa de bytes por meio do android.media.MediaCodec API.

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	WebM (.webm) Matroska (.mkv)
VP9	Consulte detalhes na seção 5.3	WebM (.webm) Matroska (.mkv)
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-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:

  • Formato:PCM linear de 16 bits
  • Taxas de amostragem:8000, 11025, 16.000, 44.100, 48.000 Hz
  • Canais:mono
  • Fontes de áudio: DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED, ou VOICE_PERFORMANCE. Isso também se aplica às predefinições de entrada equivalentes em AAudio, para exemplo: AAUDIO_INPUT_PRESET_CAMCORDER.

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

• [C-SR-1] precisa STRONGLY_RECOMMENDED para declarar isso pelo AcousticEchoCanceler Método de API AcousticEchoCanceler.isAvailable()
• [C-SR-2] estão STRONGLY_RECOMMENDED para permitir que este efeito de áudio seja controlável com o método AcousticEchoCanceler API.
• [C-SR-3] são STRONGLY_RECOMMENDED para identificar exclusivamente cada tecnologia AEC implementação por meio do objeto AudioEffect.Descriptor.uuid .

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)

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

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

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

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-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)

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

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

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

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-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)

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

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

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

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

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:

  • Modo host USB, seção 7.7
  • MIDI sobre Bluetooth LE atuando em função central, seção 7.4.3

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

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

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)

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

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)

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

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)

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

  • [C-2-1] PRECISA retornar true para ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] PRECISA implementar o modo de arcabouço de testes, conforme descrito em Documentação do modo de arcabouço de testes.

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

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)

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

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

• [C-0-1] PRECISA incluir um mecanismo de entrada, como tela touch ou navegação sem toque para navegar entre os elementos da interface.

7.2.1. Teclado

Caso as implementações de dispositivos incluam suporte a aplicativos os aplicativos Editor de método de entrada (IME), eles:

• [C-1-1] PRECISA declarar o android.software.input_methods flag de recurso.
• [C-1-2] PRECISA implementar totalmente Input Management Framework
• [C-1-3] PRECISA ter um teclado de software pré-instalado.

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:

• [C-0-1] PRECISA informar o valor correto para android.content.res.Configuration.navigation.

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:

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() DEVE ser usado apenas para informar a área de reconhecimento de gestos para casa.
• [C-6-2] Gestos que começam dentro de um retângulo de exclusão, conforme fornecido pelo aplicativo em primeiro plano com o View#setSystemGestureExclusionRects(), mas fora WindowInsets#getMandatorySystemGestureInsets(), NÃO PODE ser interceptado para a função de navegação, desde que a exclusão retângulo é permitido dentro do limite máximo de exclusão conforme especificado no documentação sobre View#setSystemGestureExclusionRects().
• [C-6-3] PRECISA enviar ao app em primeiro plano uma MotionEvent.ACTION_CANCEL quando os toques começam a ser interceptados para um gesto do sistema, se o aplicativo em primeiro plano já tiver recebido uma MotionEvent.ACTION_DOWN evento.
• [C-6-4] PRECISA fornecer affordance para o usuário alternar para uma tela navegação baseada em botões (por exemplo, em Configurações).
• DEVE fornecer a função "Início" deslizando para cima a partir da borda inferior da orientação atual da tela.
• DEVE fornecer a função "Recentes" deslizando para cima e pressionado antes da liberação, desde na mesma área do gesto de casa.
• Gestos que começam dentro WindowInsets#getMandatorySystemGestureInsets() NÃO DEVE ser afetado por retângulos de exclusão fornecidos pelo primeiro plano aplicativo por View#setSystemGestureExclusionRects()

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:

• [C-2-1] NÃO PODE definir SENSOR_TYPE_AMBIENT_TEMPERATURE para o sensor de temperatura.

Se as implementações de dispositivos incluírem um sensor para monitorar a temperatura da pele, então eles:

• [C-SR-1] É FORTEMENTE RECOMENDADO para oferecer suporte à PowerManager.getThermalHeadroom (em inglês) API.

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.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• 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)

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-6] PRECISA respeitar a sinalização individual dessa biometria (ou seja, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE, ou DevicePolicymanager.KEYGUARD_DISABLE_IRIS).

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

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

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

• [C-1-1] PRECISA implementar e informar TYPE_HINGLE_ANGLE.
• [C-1-2] PRECISA oferecer suporte a pelo menos duas leituras entre 0 e 360 graus. (inclusive, por exemplo, incluindo 0 e 360 graus).
• [C-1-3] PRECISA retornar uma ativação. sensor para getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

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:

• [C-3-1] PRECISA declarar os android.hardware.telephony.euicc flag de recurso.

Se as implementações de dispositivo não definirem a propriedade do sistema ro.telephony.iwlan\_operation\_mode como "legacy", elas:

• [C-4-1] NÃO É POSSÍVEL informar "NETWORK_TYPE_IWLAN" por NetworkRegistrationInfo#getAccessNetworkTechnology() quando NetworkRegistrationInfo#getTransportType() é relatado como "TRANSPORT_TYPE_WWAN" para a mesma instância NetworkRegistrationInfo.

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:

• [C-5-1] PRECISA declarar o android.hardware.telephony.ims flag de recurso e fornecer uma implementação completa do API ImsService para MMTEL e RCS User Capabilities Exchange API.
• [C-5-2] PRECISA declarar o android.hardware.telephony.ims.singlereg e fornecem uma implementação completa da API SipTransport, a API GbaService, indicações do portador dedicado usando a HAL IRadio 1.6 e o provisionamento via servidor de configuração automática (ACS) ou outro provisionamento proprietário usando a API de configuração IMS.

Se as implementações de dispositivos informarem o recurso android.hardware.telephony:

• [C-6-1] O SmsManager#sendTextMessage e SmsManager#sendMultipartTextMessage PRECISA resultar em chamadas correspondentes para CarrierMessagingService por fornecer a funcionalidade de mensagens de texto. SmsManager#sendMultimediaMessage e SmsManager#downloadMultimediaMessage PRECISA resultar em chamadas correspondentes para CarrierMessagingService para fornecer funcionalidade de mensagens multimídia.
• [C-6-2] O aplicativo designado por android.provider.Telephony.Sms#getDefaultSmsPackage OBRIGATÓRIO usar SmsManager (link em inglês) ao enviar e receber mensagens SMS e MMS. A referência do AOSP a implementação em pacotes/apps/mensagens atende a esse requisito.
• [C-6-3] O aplicativo que responde Intent#ACTION_DIAL PRECISA ser compatível com a entrada de códigos de discador arbitrários formatados como *#*#CODE#*#* e acionar um modelo TelephonyManager#ACTION_SECRET_CODE transmissão.
• [C-6-4] O aplicativo que responde Intent#ACTION_DIAL OBRIGATÓRIO usar VoicemailContract.Voicemails#TRANSCRIPTION para exibir a transcrição do correio de voz visual aos usuários, caso seja compatível com transcrições do correio de voz.
• [C-6-5] PRECISA representar todas as SubscriptionInfo com equivalentes agrupar UUIDs como uma única assinatura em todas as affordances visíveis ao usuário que exibem e controlar as informações do chip. Exemplos dessas affordances incluem configurações as interfaces correspondentes Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS ou EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
• [C-6-6] NÃO PODE exibir ou permitir o controle de nenhum SubscriptionInfo com um UUID de grupo não nulo e oportunista em quaisquer affordances visíveis ao usuário permitir a configuração ou o controle das configurações do chip.

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:

• [C-9-1] NÃO PODE declarar PackageManager#FEATURE_TELEPHONY_CDMA.
• [C-9-2] PRECISA gerar uma IllegalArgumentException nas tentativas de definir Tipos de rede 3GPP2 em bitmasks de tipo de rede preferencial ou permitido.
• [C-9-3] PRECISA retornar uma string vazia de TelephonyManager#getMeid

Se as implementações do dispositivo oferecerem suporte a eUICCs com várias portas e perfis:

• [C-10-1] PRECISA declarar os android.hardware.telephony.euicc.mep flag de recurso.

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-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:

• [C-2-1] PRECISA fornecer uma funcionalidade do usuário para ativar/desativar a leitura de valor. por meio do WifiManager.isScanAlwaysAvailable Método de API.

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.

7.4.2.2. Configuração de link direto encapsulado Wi-Fi

Implementações de dispositivos:

• DEVE incluir suporte para Configuração de link direto encapsulado por Wi-Fi (TDLS, na sigla em inglês) conforme descrito na Documentação do SDK do Android.

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:

• DEVE incluir compatibilidade com o Wi-Fi Aware.

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:

• [C-2-1] PRECISA implementar as APIs de descoberta com reconhecimento de local: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm, e onServiceDiscoveredWithinRange.

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:

• DEVE incluir suporte para Localização de Wi-Fi.

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:

• [C-2-1] PRECISA retornar ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (protocolo de provisionamento de dispositivo)

Implementações de dispositivos:

• DEVE incluir suporte ao Wi-Fi Easy Connect (DPP).

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

• [C-1-1] PRECISA ter o WifiManager#isEasyConnectSupported() retornam true.

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:

• [C-5-1] PRECISA retornar true para BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

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:

• [C-6-2] PRECISA bloquear o acesso ao Bluetooth atrás do android.permission.ACCESS_FINE_LOCATION.

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:

• [C-2-1] PRECISA retornar o valor RESTRICT_BACKGROUND_STATUS_DISABLED para ConnectivityManager.getRestrictBackgroundStatus()
• [C-2-2] NÃO PODE transmitir ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED:

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:

• [C-1-1] PRECISA enumerar os leitores de elementos de segurança disponíveis usando API android.se.omapi.SEService.getReaders().

• [C-1-2] PRECISA declarar as flags de recurso corretas usando o android.hardware.se.omapi.uicc para o dispositivo com elementos de segurança baseados em UICC, android.hardware.se.omapi.ese para o dispositivo com elementos de segurança baseados em eSE e android.hardware.se.omapi.sd para o dispositivo com elementos de segurança baseados em SD.

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:

• [C-1-1] PRECISA implementar essa API de câmera usando android.hardware.camera2. API.
• PODE fornecer tags e/ou extensões do fornecedor para android.hardware.camera2 API.

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:

• [C-SR-2] MUITO RECOMENDADO para implementar armazenamento adotável.

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 da pele.
• [C-1-14] PRECISA ter uma tela incorporada, e a resolução PRECISA ser de pelo menos 1.920 x 1.080.
• [C-SR-6] É RECOMENDADO que você tenha uma resolução de tela de pelo menos 2.560 x 1.440.
• [C-1-15] A tela PRECISA ser atualizada para pelo menos 60 Hz no modo RV.
• [C-1-17] A tela PRECISA ser compatível com um modo de baixa persistência com ≤ 5 milissegundos persistência, sendo definida como a quantidade de tempo quais pixels estão emitindo luz.
• [C-1-18] PRECISA oferecer suporte a Bluetooth 4.2 e à extensão de comprimento de dados Bluetooth LE. seção 7.4.3.
• [C-1-19] PRECISA oferecer suporte e relatar adequadamente Tipo de canal direto para todos os seguintes tipos de sensor padrão:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR-7] É FORTEMENTE RECOMENDADO para oferecer suporte à TYPE_HARDWARE_BUFFER tipo de canal direto para todos os tipos listados acima.
• [C-1-21] PRECISA atender aos requisitos relacionados ao giroscópio, acelerômetro e magnetômetro. requisitos para android.hardware.hifi_sensors, conforme especificado em seção 7.3.9.
• [C-SR-8] É FORTEMENTE RECOMENDADO para oferecer suporte à android.hardware.sensor.hifi_sensors.
• [C-1-22] PRECISA ter latência de movimento de ponta a ponta para fótons não superior a 28 milissegundos.
• [C-SR-9] É FORTEMENTE RECOMENDADO que tenham movimento de ponta a ponta para latência de fótons não pode ser superior a 20 milissegundos.
• [C-1-23] PRECISA ter a proporção do primeiro frame, que é a proporção entre brilho de pixels no primeiro quadro após uma transição de preto para branco e o brilho dos pixels brancos em estado estável de pelo menos 85%.
• [C-SR-10] É RECOMENDADO que a proporção do primeiro frame seja de pelo menos 90%.
• PODE oferecer um núcleo exclusivo para o primeiro plano e PODE oferecer suporte à API Process.getExclusiveCores para retornar os números dos núcleos de CPU exclusivos do primeiro plano superior para o aplicativo.

Se houver suporte ao núcleo exclusivo, então o núcleo:

• [C-2-1] NÃO PODE permitir que nenhum outro processo do espaço do usuário seja executado nele. (exceto drivers de dispositivo usados pelo aplicativo), mas PODE permitir parte do kernel que os processos sejam executados conforme necessário.

7,10. Retorno tátil

Dispositivos destinados a serem manuais ou usados podem incluir um retorno tátil para uso geral atuador, disponível para aplicativos com finalidades que incluem a chamada de atenção por meio de toques, alarmes, notificações e feedback geral por toque.

Se as implementações de dispositivos NÃO incluírem esse atuador tátil de uso geral, eles:

• [7.10/C] PRECISA retornar "false" para Vibrator.hasVibrator().

Se as implementações do dispositivo ENVOLVEREM pelo menos um retorno tátil de uso geral atuador, eles:

• [C-1-1] PRECISA retornar "true" para Vibrator.hasVibrator().
• NÃO DEVE usar um atuador tátil (vibrador) de massa giratória excêntrica (ERM).
• DEVE implementar todas as constantes públicas para retorno tátil claro. em android.view.HapticFeedbackConstants ou seja (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START e GESTURE_END).
• DEVE implementar todas as constantes públicas para retorno tátil claro. em android.os.VibrationEffect ou seja (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK e EFFECT_DOUBLE_CLICK) e todas as constantes públicas viáveis de PRIMITIVE_* para retorno tátil avançado em android.os.VibrationEffect.Composition ou seja (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN e THUD). Alguns desses primitivos, como LOW_TICK e SPIN só será viável se a vibração oferecer suporte a níveis relativamente baixos e frequências diferentes.
• DEVE seguir as orientações para mapeamento de constantes públicas em android.view.HapticFeedbackConstants para o android.os.VibrationEffect recomendado com as relações de amplitude correspondentes.
• DEVE usar estes mapeamentos de constantes táteis vinculados.
• DEVE seguir a avaliação de qualidade para createOneShot() e createWaveform() APIs de terceiros.
• DEVE confirmar se o resultado das android.os.Vibrator.hasAmplitudeControl() públicas A API reflete corretamente os recursos da vibração.
• DEVE verificar os recursos de escalonabilidade de amplitude executando android.os.Vibrator.hasAmplitudeControl().

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

• DEVE verificar o status da implementação executando android.os.Vibrator.areAllEffectsSupported() e android.os.Vibrator.arePrimitivesSupported() APIs de terceiros.
• DEVEM fazer uma avaliação de qualidade para constantes táteis.
• DEVE verificar e atualizar, se necessário, a configuração de fallback primitivos não compatíveis, conforme descrito nas orientações de implementação para constantes.
• DEVE fornecer suporte substituto para reduzir o risco de falha, conforme descrito aqui.

7,11. Classe de desempenho de mídia

A classe de desempenho de mídia da implementação do dispositivo pode ser obtida em a API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. Requisitos da classe de desempenho de mídia são definidos para cada versão do Android que começa com R (versão 30). O valor especial de 0 designa que o dispositivo não é classe de desempenho de mídia.

Se as implementações de dispositivo retornarem um valor diferente de zero para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, eles:

• [C-1-1] PRECISA retornar pelo menos um valor de android.os.Build.VERSION_CODES.R.

• [C-1-2] PRECISA ser uma implementação de dispositivo portátil.

• [C-1-3] PRECISA atender a todos os requisitos de "Classe de desempenho de mídia" descreveu na seção 2.2.7.

Em outras palavras, a classe de desempenho de mídia no Android T é definida apenas para dispositivos portáteis nas versões T, S ou R.

Consulte a seção 2.2.7 para informações específicas do dispositivo e cumprimento de requisitos regulatórios.

8. Desempenho e potência

Alguns critérios mínimos de desempenho e potência são essenciais para a experiência do usuário. e afetar as suposições básicas que os desenvolvedores teriam ao desenvolver app.

8.1. Consistência da experiência do usuário

Uma interface de usuário tranquila pode ser fornecida ao usuário final se houver certos requisitos mínimos para garantir um frame rate e tempos de resposta consistentes para aplicativos e jogos. Implementações de dispositivos, dependendo do tipo, podem ter requisitos mensuráveis de latência da interface do usuário e como descrito na seção 2.

8.2. Desempenho do acesso a E/S de arquivos

O fornecimento de um valor de referência comum para um desempenho consistente de acesso a arquivos no O armazenamento de dados particulares do aplicativo (partição /data) permite que os desenvolvedores de apps definir uma expectativa adequada para ajudar no design do software. Dispositivo implementações, dependendo do tipo de dispositivo, PODEM ter determinados requisitos descritos na seção 2 para o seguinte e operações de gravação:

• Desempenho de gravação sequencial. Medida pela gravação de um arquivo de 256 MB usando 10 MB de gravação.
• Desempenho de gravação aleatória. Medida por meio da gravação de um arquivo de 256 MB usando 4 KB de gravação de dados.
• Desempenho de leitura sequencial. Medida pela leitura de um arquivo de 256 MB com o 10 MB de gravação.
• Desempenho de leitura aleatória. Medida pela leitura de um arquivo de 256 MB usando 4 KB de gravação de dados.

8.3. Modos de economia de energia

Se as implementações de dispositivos incluírem recursos para melhorar o gerenciamento de energia do dispositivo incluídos no AOSP (por exemplo, App em espera, Soneca) ou que estendam os recursos para aplicar restrições mais fortes do que o bucket RESTRITO do App em espera, eles:

• [C-1-1] NÃO PODE se desviar da implementação do AOSP para o acionamento. algoritmos de ativação e uso de configurações globais do sistema ou DeviceConfig (em inglês) dos modos de economia de energia "App em espera" e "Soneca".
• [C-1-2] NÃO PODE se desviar da implementação do AOSP para usar ou DeviceConfig para gerenciar a limitação de jobs, para apps em cada bucket para o App em espera.
• [C-1-3] NÃO PODE se desviar da implementação do AOSP para o número de Buckets do App em espera usados para o App em espera.
• [C-1-4] PRECISA implementar os buckets do App em espera e "Soneca", conforme descrito em Gerenciamento de energia.
• [C-1-5] PRECISA retornar true para PowerManager.isPowerSaveMode() quando o dispositivo está no modo de economia de energia.
• [C-1-6] PRECISA fornecer recursos do usuário para mostrar todos os apps isentos. dos modos de economia de energia App em espera e Soneca ou qualquer otimização de bateria e PRECISA implementar a configuração ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS de solicitar que o usuário permita que um app ignore a bateria. e otimizações.
• [C-SR-1] É FORTEMENTE RECOMENDADO para fornecer recursos ao usuário para ativar e desativar o recurso de economia de bateria.
• [C-SR-2] É FORTEMENTE RECOMENDADO para fornecer recursos ao usuário para exibir todos apps isentos dos modos de economia de energia "App em espera" e "Soneca".

Se as implementações de dispositivos estenderem os recursos de gerenciamento de energia incluídos no AOSP, e essa extensão aplica restrições mais rigorosas o bucket "Rare App Standby", consulte a seção 3.5.1.

Além dos modos de economia de energia, as implementações de dispositivos Android podem implementar qualquer um ou todos os quatro estados de suspensão conforme definido pelo interface de configuração e energia (ACPI, na sigla em inglês).

Se as implementações de dispositivos implementam estados de energia S4 conforme definido pelas ACPI:

• [C-1-1] PRECISA inserir esse estado somente depois que o usuário tiver realizado uma ação explícita. Colocar o dispositivo em um estado inativo (por exemplo, fechando uma tampa que esteja fisicamente do dispositivo ou desligar um veículo ou televisão) e antes do o usuário ativa novamente o dispositivo (por exemplo, abrindo a tampa ou girando o veículo) ou a televisão ligada).

Se as implementações de dispositivos implementam estados de energia S3 conforme definido pelas ACPI:

• [C-2-1] PRECISA estar em conformidade com C-1-1 acima ou PRECISA inserir o estado S3 somente quando terceiros os aplicativos não precisam dos recursos do sistema (por exemplo, a tela, CPU).

  Por outro lado, PRECISA sair do estado S3 quando aplicativos de terceiros precisarem da do sistema, conforme descrito neste SDK.

  Por exemplo, enquanto os aplicativos de terceiros pedem para manter a tela por meio de FLAG_KEEP_SCREEN_ON ou manter a CPU em execução PARTIAL_WAKE_LOCK, o dispositivo NÃO PODE entrar no estado S3, a menos que, conforme descrito em C-1-1, o usuário tomou medidas explícitas para colocar o dispositivo inativo. Por outro lado, em uma tarefa em que apps de terceiros implementar pelo JobScheduler é acionado ou o Firebase Cloud Messaging é entregue a apps de terceiros, o dispositivo PRECISA sair do estado S3, a menos que o o usuário colocou o dispositivo em um estado inativo. Elas não estão completas e o AOSP implementa amplos sinais de ativação que acionam uma ativação a partir desse estado.

8.4. Contabilidade de consumo de energia

Uma contabilidade e relatórios mais precisos do consumo de energia proporciona ao desenvolvedor de aplicativos os incentivos e as ferramentas para otimizar o uso de energia padrão do aplicativo.

Implementações de dispositivos:

• [C-SR-1] É MUITO RECOMENDADO fornecer um perfil de energia por componente que define o valor atual de consumo 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.
• [C-SR-2] É MUITO RECOMENDADO informar todos os valores de consumo de energia em milímetros horas (mAh).
• [C-SR-3] É MUITO RECOMENDADO informar o consumo de energia da CPU por UID de cada processo. O Android Open Source Project atende ao requisito por meio do Implementação do módulo do kernel uid_cputime.
• [C-SR-4] É MUITO RECOMENDADO disponibilizar esse uso de energia pela adb shell dumpsys batterystats shell para o desenvolvedor do app.
• DEVE ser atribuído ao componente de hardware se não for possível atribui o consumo de energia do componente de hardware a um aplicativo.

8.5. Desempenho consistente

O desempenho pode variar drasticamente para apps de alto desempenho e longa duração, seja por conta de outros apps em execução em segundo plano ou da limitação de CPU devido aos limites de temperatura. O Android inclui interfaces programáticas para que, quando o dispositivo é capaz, o aplicativo de primeiro plano superior pode solicitar que o sistema otimizar a alocação de recursos para lidar com essas flutuações.

Implementações de dispositivos:

• [C-0-1] PRECISA informar o suporte ao Modo de desempenho sustentado com precisão através do PowerManager.isSustainedPerformanceModeSupported() Método de API.

• DEVE oferecer suporte ao modo de desempenho sustentado.

Se as implementações de dispositivos relatarem suporte ao modo de desempenho sustentado, elas:

• [C-1-1] PRECISA fornecer ao aplicativo em primeiro plano um nível consistente de performance por pelo menos 30 minutos, quando o app solicitar.
• [C-1-2] PRECISA respeitar Window.setSustainedPerformanceMode() e outras APIs relacionadas.

Se as implementações de dispositivos incluírem dois ou mais núcleos de CPU, elas:

• DEVE fornecer pelo menos um núcleo exclusivo que possa ser reservado pelas principais aplicativo em primeiro plano.

Se as implementações de dispositivos oferecerem suporte à reserva de um núcleo exclusivo para o aplicativo em primeiro plano, eles:

• [C-2-1] PRECISA gerar relatórios pela Process.getExclusiveCores() Método de API com os números de ID dos núcleos exclusivos que podem ser reservados pelo aplicativo principal em primeiro plano.
• [C-2-2] Não pode permitir processos do espaço do usuário, exceto os drivers do dispositivo pelo aplicativo para execução nos núcleos exclusivos, mas PODE permitir que alguns que os processos do kernel sejam executados conforme necessário.

Se as implementações de dispositivos não oferecerem suporte a um núcleo exclusivo, elas:

• [C-3-1] PRECISA retornar uma lista vazia usando o Process.getExclusiveCores() Método de API.

9. Compatibilidade do modelo de segurança

Implementações de dispositivos:

• [C-0-1] PRECISA implementar um modelo de segurança consistente com o modelo de segurança da plataforma Android, conforme definido Documento de referência de segurança e permissões nas APIs na documentação do desenvolvedor Android.

• [C-0-2] PRECISA ser compatível com a instalação de modelos de aplicativos sem a necessidade de permissões/certificados adicionais de qualquer terceiros/autoridades.

Se as implementações do dispositivo declararem o android.hardware.security.model.compatible eles:

• [C-1-1] PRECISA ser compatível com os requisitos listados nas subseções a seguir.

9,1. Permissões

Implementações de dispositivos:

• [C-0-1] PRECISA oferecer suporte ao modelo de permissões do Android e o Modelo de papéis do Android conforme definido na documentação do desenvolvedor Android. Especificamente, eles PRECISA aplicar cada permissão e papel definidos conforme descrito nos Documentação do SDK. permissões e papéis não podem ser omitidos, alterados ou ignoradas.

• PODE adicionar outras permissões, desde que as novas strings de ID de permissão não estão no namespace android.\*.

• [C-0-2] Permissões com protectionLevel de PROTECTION_FLAG_PRIVILEGED Só PRECISA ser concedido a apps pré-instalados nos caminhos privilegiados do imagem do sistema (bem como arquivos APEX) e no subconjunto de permissões explicitamente permitidas para cada app. A implementação do AOSP atende a esse requisito, lendo e respeitando a permissões de cada app dos arquivos na etc/permissions/ e usando o caminho system/priv-app como o caminho privilegiado.

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

Permissões com um nível de proteção perigoso são as permissões de execução. Aplicativos com targetSdkVersion > 22 solicitá-las no ambiente de execução.

Implementações de dispositivos:

• [C-0-3] PRECISA mostrar uma interface dedicada para o usuário decidir se concede ou não as permissões de execução solicitadas e também fornece uma interface para o usuário gerenciar as permissões de execução.

• [C-0-5] NÃO PODE conceder permissões de execução a apps, a menos que:

  • forem instalados no momento do envio do dispositivo;

  • O consentimento do usuário pode ser obtido antes que o aplicativo usa a permissão,

    OU

  • As permissões de execução são concedidas pela política de concessão de permissão padrão ou para ter um papel de plataforma.

• [C-0-6] PRECISA conceder a permissão android.permission.RECOVER_KEYSTORE. somente a apps do sistema que registram um Agente de recuperação protegido. Um o Agente de recuperação bem protegido é definido como um agente de software no dispositivo sincronizado com um armazenamento remoto fora do dispositivo, equipado com um hardware seguro com proteção equivalente ou mais forte descritos em Serviço Google Cloud Key Vault para evitar ataques de força bruta no fator de conhecimento da tela de bloqueio.

Implementações de dispositivos:

• [C-0-7] PRECISA aderir às propriedades de permissão de localização do Android quando um app solicita os dados de local ou atividade física por meio da API Android padrão ou mecanismo reservado. Esses dados incluem, entre outros:

  • Localização do dispositivo (por exemplo, latitude e longitude), conforme descrito em seção 9.8.8.
  • Informações que podem ser usadas para determinar ou estimar o local (por exemplo, SSID, BSSID, ID do celular ou local da rede em que a dispositivo está conectado).
  • Atividade física do usuário ou classificação da atividade física.

Mais especificamente, implementações de dispositivos:

• [C-0-8] PRECISA ter o consentimento do usuário para permitir que o app acesse a dados de local ou atividade física.
• [C-0-9] PRECISA conceder uma permissão de execução APENAS ao app que contém permissão suficiente, conforme descrito no SDK. Por exemplo: TelephonyManager#getServiceState requer android.permission.ACCESS_FINE_LOCATION).

As únicas exceções às propriedades de permissão de localização do Android acima são para Apps que não acessam a Localização para obter ou identificar a localização do usuário. especificamente:

• Quando os apps têm a permissão RADIO_SCAN_WITHOUT_LOCATION.
• Para fins de configuração e configuração do dispositivo, quando os apps do sistema mantêm o Permissão NETWORK_SETTINGS ou NETWORK_SETUP_WIZARD.

As permissões podem ser marcadas como restritas, alterando o comportamento delas.

• [C-0-10] As permissões marcadas com a sinalização hardRestricted NÃO PODEM ser concedidas a um app, a menos que:

  • Um arquivo APK do app está na partição do sistema.
  • O usuário atribui um papel associado a hardRestricted. permissões de acesso a um app.
  • O instalador concede a hardRestricted a um app.
  • Um app recebe o hardRestricted em uma versão anterior do Android.

• [C-0-11] Os apps com uma permissão softRestricted PRECISAM ser limitados. acesso e NÃO PODE ter acesso total até que esteja na lista de permissões, conforme descrito nas SDK, em que o acesso total e limitado é definido para cada softRestricted permissão (por exemplo, READ_EXTERNAL_STORAGE).

• [C-0-12] NÃO PODE fornecer nenhuma função personalizada ou API para ignorar a restrições de permissão definidas em setPermissionPolicy e setPermissionGrantState APIs de terceiros.

• [C-0-13] PRECISA usar as APIs AppOpsManager para registrar e rastrear cada uma todo acesso programático a dados protegidos por permissões perigosas Atividades e serviços do Android.

• [C-0-14] PRECISA atribuir funções apenas a aplicativos com funcionalidades que atendem aos requisitos da função.

• [C-0-15] PRECISA não definir papéis que sejam cópias ou funcionalidades superconjunto. de papéis definidos pela plataforma.

Se os dispositivos informarem android.software.managed_users, eles:

• [C-1-1] NÃO PODE ter as seguintes permissões concedidas silenciosamente pelo Administrador:
  • Local (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
  • Câmera (CAMERA)
  • Microfone (RECORD_AUDIO)
  • Sensor corporal (BODY_SENSORS)
  • Atividade física (ACTIVITY_RECOGNITION)

Se as implementações de dispositivos fornecerem funcionalidade ao usuário para escolher quais aplicativos podem se sobrepõe a outros aplicativos com uma atividade que lida com ACTION_MANAGE_OVERLAY_PERMISSION intenção, eles:

• [C-2-1] PRECISA garantir que todas as atividades com filtros de intents para ACTION_MANAGE_OVERLAY_PERMISSION têm a mesma tela de interface, independentemente do app inicial ou de qualquer informações que ela fornece.

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

• [C-3-1] É NECESSÁRIO mostrar uma exoneração de responsabilidade durante a configuração do dispositivo totalmente gerenciado (configuração do proprietário do dispositivo) informando que o administrador de TI poderá permite que os apps controlem as configurações do telefone, incluindo microfone, câmera e local, com opções para o usuário continuar a configuração ou sair dela, A MENOS QUE a administrador desativou o controle das permissões no dispositivo.

Se as implementações do dispositivo pré-instalarem qualquer pacote que tenha qualquer um dos papéis System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence ou System Visual Intelligence, os pacotes:

• [C-4-1] PRECISA cumprir todos os requisitos descritos para implementações de dispositivos em seções "9.8.6 Dados ambientes e do SO e 9.8.15 implementações de API no modo sandbox".

Se as implementações de dispositivos incluem um aplicativo padrão para dar suporte ao VoiceInteractionService eles:

• [C-5-1] NÃO PODE conceder ACCESS_FINE_LOCATION como padrão para isso para o aplicativo.

9,2. UID e isolamento de processos

Implementações de dispositivos:

• [C-0-1] PRECISA ser compatível com o app Android. em que cada aplicativo é executado como um UID exclusivo de estilo Unix e em um processo separado.
• [C-0-2] PRECISA oferecer suporte à execução de vários aplicativos. como o mesmo ID de usuário do Linux, desde que os aplicativos sejam assinados e construído, conforme definido nas Referência de segurança e permissões.

9,3 Permissões do sistema de arquivos

Implementações de dispositivos:

• [C-0-1] PRECISA oferecer suporte ao acesso a arquivos do Android. de permissões do usuário, conforme definido Referência de segurança e permissões.

9,4. Ambientes de execução alternativos

As implementações de dispositivos PRECISAM manter a consistência da segurança do Android de permissão de acesso, mesmo que incluam ambientes de execução que executam aplicativos que usam algum outro software ou tecnologia que não o Dalvik Executable Formato ou código nativo. Resumindo:

• [C-0-1] Os tempos de execução alternativos PRECISAM ser aplicativos Android, e respeitar o modelo de segurança padrão do Android, conforme descrito em outros locais. na seção 9.

• [C-0-2] Ambientes de execução alternativos NÃO PODEM ter acesso aos recursos protegido por permissões não solicitadas no AndroidManifest.xml do ambiente de execução pelo <uses-permission> mecanismo de atenção.

• [C-0-3] Tempos de execução alternativos NÃO PODEM permitir que aplicativos usem recursos protegidos por permissões do Android restritas a aplicativos do sistema.

• [C-0-4] Tempos de execução alternativos PRECISAM respeitar o modelo de sandbox do Android e aplicativos instalados usando um tempo de execução alternativo NÃO PODEM reutilizar o sandbox de qualquer outro aplicativo instalado no dispositivo, exceto por meio de os mecanismos Android padrão do ID de usuário compartilhado e do certificado de assinatura.

• [C-0-5] Ambientes de execução alternativos NÃO PODEM ser iniciados, concedidos ou concedidos acesso às sandboxes correspondentes a outros aplicativos Android.

• [C-0-6] Ambientes de execução alternativos NÃO PODEM ser iniciados, concedidos ou concedidos a outros aplicativos qualquer privilégio do superusuário (raiz) ou de qualquer outro ID do usuário.

• [C-0-7] Quando os arquivos .apk de ambientes de execução alternativos são incluídos no imagem do sistema de implementações de dispositivos, ele PRECISA ser assinado com uma chave diferente da chave usada para assinar outros apps incluídos no dispositivo e implementações.

• [C-0-8] Ao instalar aplicativos, os ambientes de execução alternativos PRECISAM ter o consentimento do usuário para as permissões do Android usadas pelo aplicativo.

• [C-0-9] Quando um aplicativo precisa usar um recurso de dispositivo para que há uma permissão correspondente do Android (como Câmera, GPS etc.), o ambiente de execução alternativo PRECISA informar ao usuário que o aplicativo vai poder para acessar esse recurso.

• [C-0-10] Quando o ambiente de execução não grava o aplicativo dessa maneira, o ambiente de execução PRECISA listar todas as permissões mantidos pelo próprio ambiente de execução ao instalar qualquer aplicativo que use esse ambiente de execução.

• Ambientes de execução alternativos DEVEM instalar apps pelo PackageManager nos sandboxes do Android separados (IDs de usuário do Linux etc.).

• Tempos de execução alternativos PODEM fornecer um único sandbox do Android compartilhado por todos aplicativos usando o ambiente de execução alternativo.

9,5 Suporte a multiusuário

O Android inclui suporte para vários usuários e oferece suporte para isolamento total e clone perfis de usuário com isolamento parcial(ou seja, um único perfil de usuário adicional do tipo android.os.usertype.profile.CLONE).

• As implementações de dispositivos PODEM, mas NÃO DEVEM habilitar o grupo multiusuário se usarem mídia removível para o armazenamento externo principal.

Se as implementações de dispositivos tiverem suporte para vários usuários, elas:

• [C-1-2] PRECISA, para cada usuário, implementar uma política consistente com o modelo de segurança da plataforma Android, conforme definido Documento de referência de segurança e permissões nas APIs.
• [C-1-3] PRECISA ter armazenamento compartilhado separado e isolado para apps (conhecidos como /sdcard) para cada instância de usuário.
• [C-1-4] PRECISA garantir que os aplicativos pertencentes e executados em nome de um determinado usuário não pode listar, ler ou gravar nos arquivos de outro usuário; mesmo que os dados dos dois usuários estejam armazenados no mesmo volume ou sistema de arquivos.
• [C-1-5] É NECESSÁRIO criptografar o conteúdo do cartão SD quando o recurso multiusuário está ativado usando uma chave armazenada apenas em mídia não removível, que só pode ser acessada pelo sistema se as implementações de dispositivos usam mídia removível para as APIs de armazenamento externo. Como isso torna a mídia ilegível para um PC host, as implementações de dispositivos será necessário mudar para o MTP ou um sistema similar para fornecer aos PCs host acesso aos dados do usuário atual.

Se as implementações de dispositivos incluírem suporte para vários usuários, para Todos os usuários, exceto aqueles criados especificamente para executar instâncias duplas do mesmo app, elas:

• [C-2-1] PRECISA ter armazenamento compartilhado para aplicativos separado e isolado diretórios (conhecidos como /sdcard) para cada instância de usuário.
• [C-2-2] PRECISA garantir que os aplicativos de propriedade da nome de um determinado usuário não pode listar, ler ou gravar nos arquivos de propriedade por qualquer outro usuário, mesmo que os dados de ambos os usuários estejam armazenados no mesmo volume ou sistema de arquivos.

As implementações de dispositivos PODEM criar um único perfil de usuário adicional do tipo android.os.usertype.profile.CLONE em relação ao usuário principal (e somente contra o usuário principal) com a finalidade de executar instâncias duplas do mesmo app. Essas instâncias duplas compartilham armazenamento parcialmente isolado e são apresentadas ao usuário final no acesso rápido ao mesmo tempo e aparecem na mesma visualização Recentes. Por exemplo, isso pode ser usado para ajudar o usuário a instalar dois dispositivos instâncias de um único app em um dispositivo dual chip.

Se as implementações de dispositivos criarem o perfil de usuário adicional discutido acima, então eles:

• [C-3-1] PRECISA fornecer acesso apenas ao armazenamento ou aos dados que já estão pode ser acessado pelo perfil do usuário pai ou pertence diretamente a ele perfil de usuário adicional.
• [C-3-2] NÃO PODE ter este perfil de trabalho.
• [C-3-3] PRECISA ter diretórios de dados particulares do app isolados do pai. conta de usuário.
• [C-3-4] NÃO PODE permitir a criação do perfil de usuário adicional se houver é um proprietário do dispositivo aprovisionado (consulte a seção 3.9.1) ou permite que um proprietário de dispositivo seja provisionado sem remover o perfil de usuário adicional primeiro.

Se as implementações de dispositivos criarem o perfil de usuário adicional discutido acima, então eles:

• [C-4-1] PRECISA permitir as intents abaixo, originárias das outras perfil seja gerenciado pelos aplicativos do usuário principal no dispositivo:

  • Intent.ACTION_VIEW
  • Intent.ACTION_SENDTO
  • Intent.ACTION_SEND
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT
  • Intent.ACTION_INSERT_OR_EDIT
  • Intent.ACTION_SEND_MULTIPLE
  • Intent.ACTION_PICK
  • Intent.ACTION_GET_CONTENT
  • MediaStore.ACTION_IMAGE_CAPTURE
  • MediaStore.ACTION_VIDEO_CAPTURE

• [C-4-2] PRECISA herdar todas as restrições de usuário da política do dispositivo e selecionar restrictions(list below) (não usuário) foi aplicado ao usuário principal do dispositivo para esse perfil de usuário adicional.

  • setScreenCaptureDisabled
  • setAccountManagementDisabled
  • setCameraDisabled
  • setPermittedInputMethods
  • setApplicationHidden
  • setPersonalAppsSuspended

• [C-4-3] PRECISA permitir a gravação de contatos deste perfil adicional apenas pelo estas intents:

  • ContactsContract.Intents.Insert.ACTION
  • Intent.ACTION_PICK
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT_OR_EDIT

• [C-4-4] NÃO PODE ter sincronizações de contatos em execução para aplicativos em execução esse perfil de usuário adicional.

• [C-4-5] PRECISA permitir somente aplicativos no perfil adicional que tenham um do inicializador para acessar os contatos que já estão acessíveis ao perfil de usuário principal.

9,6. Aviso de SMS premium

O Android inclui suporte para alertar os usuários sobre quaisquer mensagem SMS premium. SMS premium as mensagens de texto são mensagens de texto enviadas a um serviço registrado com uma operadora que pode gerar uma cobrança para o usuário.

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

• [C-1-1] PRECISA avisar os usuários antes de enviar mensagens SMS para números. identificados por expressões regulares definidas em /data/misc/sms/codes.xml no dispositivo. O Android Open Source Project upstream fornece uma implementação que atenda a esse requisito.

9,7. Recursos de segurança

As implementações de dispositivos PRECISAM garantir a conformidade com os recursos de segurança nos dois kernel e plataforma, conforme descrito abaixo.

O Android Sandbox inclui recursos que usam a biblioteca Security-Enhanced Linux (SELinux), o sistema de controle de acesso obrigatório (MAC), o seccomp sandboxing e outros recursos de segurança no kernel do Linux. Implementações de dispositivos:

• [C-0-1] PRECISA manter a compatibilidade com os aplicativos atuais, mesmo quando O SELinux ou qualquer outro recurso de segurança seja implementado abaixo da de análise de dados em nuvem.
• [C-0-2] NÃO PODE ter uma interface do usuário visível quando um sistema a violação é detectada e bloqueada pelo recurso de segurança implementados abaixo da estrutura do Android, mas PODEM ter uma interface do usuário visível quando ocorre uma violação de segurança desbloqueada que resulta em uma exploração bem-sucedida.
• [C-0-3] NÃO PODE implementar o SELinux ou qualquer outro recurso de segurança abaixo do framework do Android, configurável pelo usuário ou desenvolvedor do aplicativo.
• [C-0-4] NÃO PODE permitir um aplicativo que possa afetar outro aplicativo usando uma API (como uma API Device Administration) para configurar uma política que invalide a compatibilidade.
• [C-0-5] PRECISA dividir o framework de mídia em vários processos para que é possível conceder acesso mais restrito a cada processo conforme descrito no site do Android Open Source Project.
• [C-0-6] PRECISA implementar um mecanismo de sandbox do aplicativo do kernel que permite filtrar chamadas do sistema usando uma política configurável de programas com várias linhas de execução. O Android Open Source Project upstream atende a esse ao ativar o seccomp-BPF com o grupo de linhas de execução (TSYNC), conforme descrito na seção "Configuração do kernel" em source.android.com.

A integridade do kernel e os recursos de autoproteção são essenciais para o Android segurança dos dados. Implementações de dispositivos:

• [C-0-7] PRECISA implementar mecanismos de proteção contra estouro do buffer da pilha do kernel. Exemplos desses mecanismos são CC_STACKPROTECTOR_REGULAR e CONFIG_CC_STACKPROTECTOR_STRONG.
• [C-0-8] PRECISA implementar proteções rigorosas de memória do kernel quando executável o código é somente leitura, os dados somente leitura não são executáveis nem graváveis os dados graváveis não são executáveis (por exemplo, CONFIG_DEBUG_RODATA ou CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] PRECISA implementar tamanhos de objetos estáticos e dinâmicos verificação de limites de cópias entre o espaço do usuário e o espaço do kernel (por exemplo, CONFIG_HARDENED_USERCOPY) em dispositivos originalmente enviados com o nível da API. 28 ou superior.
• [C-0-10] NÃO PODE executar a memória do espaço do usuário ao executar no modo kernel (por exemplo, PXN de hardware ou emulado via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) nos dispositivos enviado originalmente com o nível de API 28 ou superior.
• [C-0-11] NÃO PODE ler nem gravar a memória do espaço do usuário na fora das APIs normais de acesso à cópia do usuário (por exemplo, PAN de hardware ou emulado via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) em dispositivos originalmente fornecidos com o nível 28 da API ou mais recente.
• [C-0-12] PRECISA implementar o isolamento da tabela da página do kernel se o hardware estiver vulnerável à CVE-2017-5754 em todos os dispositivos originalmente enviados com nível de API 28 ou mais recente (por exemplo, CONFIG_PAGE_TABLE_ISOLATION ou CONFIG_UNMAP_KERNEL_AT_EL0).

• [C-0-13] PRECISA implementar o aumento da proteção de previsão da ramificação se o hardware estiver vulnerável à CVE-2017-5715 em todos os dispositivos originalmente enviados com nível de API 28 ou mais recente (por exemplo, CONFIG_HARDEN_BRANCH_PREDICTOR).

• [C-SR-1] É MUITO RECOMENDADO manter os dados do kernel que é gravado apenas durante a inicialização marcado como somente leitura após inicialização (por exemplo, __ro_after_init).

• [C-SR-2] São RECOMENDADOS ALTAMENTE para randomizar o layout do código do kernel e da memória e para evitar exposições que comprometam a randomização Por exemplo, CONFIG_RANDOMIZE_BASE com entropia do carregador de inicialização pela /chosen/kaslr-seed Device Tree node ou EFI_RNG_PROTOCOL).

• [C-SR-3] É FORTEMENTE RECOMENDADO para ativar a integridade do fluxo de controle (CFI) em o kernel para fornecer mais proteção contra ataques de reutilização de código (por exemplo, CONFIG_CFI_CLANG e CONFIG_SHADOW_CALL_STACK).

• [C-SR-4] É FORTEMENTE RECOMENDADO não desativar a integridade do fluxo de controle (CFI), O Shadow Call Stack (SCS) ou a limpeza de estouro de números inteiros (IntSan) estão ativados componentes em que ele está ativado.

• [C-SR-5] É MUITO RECOMENDADO ativar CFI, SCS e IntSan para componentes adicionais do espaço do usuário sensíveis à segurança, conforme explicado em CFI e IntSan (links em inglês).

• [C-SR-6] É FORTEMENTE RECOMENDADO para permitir a inicialização de pilha no kernel para evitar o uso de variáveis locais não inicializadas (CONFIG_INIT_STACK_ALL ou CONFIG_INIT_STACK_ALL_ZERO). Além disso, as implementações de dispositivos NÃO DEVEM assumir o valor usado pelo compilador para e inicializar os locais.

• [C-SR-7] É FORTEMENTE RECOMENDADO para ativar a inicialização de heap no kernel para evitar o uso de alocações de heap não inicializadas (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) e NÃO DEVEM assumir o valor usado por ao kernel para inicializar essas alocações.

Se as implementações de dispositivos usam um kernel do Linux capaz de dar suporte SELinux, eles:

• [C-1-1] PRECISA implementar o SELinux.
• [C-1-2] PRECISA configurar o SELinux para o modo de aplicação global.
• [C-1-3] PRECISA configurar todos os domínios no modo de aplicação. Sem modo permissivo domínios são permitidos, incluindo domínios específicos de um dispositivo/fornecedor.
• [C-1-4] NÃO PODE modificar, omitir ou substituir as regras de nunca permitir presentes na pasta system/sepolicy fornecida no código aberto upstream do Android o Project (AOSP) e a política PRECISAM ser compilados com todas as regras de bloqueio presentes, para domínios SELinux do AOSP, bem como domínios específicos do dispositivo/fornecedor.
• [C-1-5] É NECESSÁRIO executar aplicativos de terceiros direcionados ao nível 28 da API ou mais recente. em sandboxes SELinux por aplicativo com restrições de SELinux por aplicativo em cada ao diretório de dados privados do seu aplicativo.
• DEVE manter a política SELinux padrão fornecida na política de SELinux do Android Open Source Project upstream e só adicionar a essa pasta política para a própria configuração específica do dispositivo.

Se as implementações de dispositivos usarem kernel diferente do Linux ou do Linux sem SELinux, eles:

• [C-2-1] PRECISA usar um sistema de controle de acesso obrigatório que seja equivalente ao SELinux.

Se as implementações de dispositivos usarem dispositivos de E/S compatíveis com DMA, elas:

• [C-SR-9] É FORTEMENTE RECOMENDADO para isolar cada dispositivo de E/S capaz de DMA, usando uma IOMMU (por exemplo, ARM SMMU).

O Android tem vários recursos de defesa em profundidade que são essenciais para o dispositivo segurança dos dados. Além disso, o Android se concentra em reduzir as classes principais de bugs comuns que contribuem para a segurança e qualidade insatisfatória.

Para reduzir bugs de memória, as implementações de dispositivos:

• [C-SR-10] É RECOMENDADO que eles sejam testados usando o erro de memória do espaço do usuário ferramentas de detecção como MTE para dispositivos ARMv9, HWASan para dispositivos ARMv8+ ou ASan para outros tipos de dispositivos.
• [C-SR-11] É RECOMENDADO que eles sejam testados usando o erro de memória do kernel ferramentas de detecção como KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS para Dispositivos ARMv9, CONFIG_KASAN_SW_TAGS para dispositivos ARMv8 ou CONFIG_KASAN_GENERIC para outros tipos de dispositivos).
• [C-SR-12] É FORTEMENTE RECOMENDADO usar ferramentas de detecção de erros de memória produção, como MTE, GWP-ASan e KFENCE.

Se as implementações de dispositivos usarem um TEE baseado em Arm TrustZone, elas:

• [C-SR-13] É FORTEMENTE RECOMENDADO usar um protocolo padrão para memória entre o Android e o TEE, como o Arm Firmware Framework para Armv8-A (FF-A).
• [C-SR-14] É FORTEMENTE RECOMENDADO restringir os aplicativos confiáveis apenas a acessar a memória que foi compartilhada explicitamente com eles por meio do comando protocolo. Se o dispositivo tiver suporte para o nível de exceção Arm S-EL2, devem ser aplicadas pelo gerenciador de partições seguras. Caso contrário, ele deve ser aplicada pelo SO TEE.

Uma tecnologia de segurança de memória é uma tecnologia que mitiga pelo menos os seguintes classes de bugs com alta probabilidade (> 90%) em aplicativos que usam a android:memtagMode opção do manifesto:

• estouro do buffer de heap
• usar após a gratuidade
• Dupla sem custo financeiro
• Wild free (sem um ponteiro não Malloc)

Implementações de dispositivos:

• [C-SR-15] É MUITO RECOMENDADO de configurar ro.arm64.memtag.bootctl_supported:

Se as implementações do dispositivo definirem a propriedade do sistema ro.arm64.memtag.bootctl_supported como verdadeiro, eles:

• [C-3-1] PRECISA permitir que a propriedade do sistema arm64.memtag.bootctl aceite uma lista separada por vírgulas dos valores a seguir, com o efeito desejado aplicada na próxima reinicialização seguinte:

  • memtag: uma tecnologia de segurança de memória, conforme definido acima, está ativada
  • memtag-once: uma tecnologia de segurança de memória, conforme definido acima, é ativada temporariamente e desativada automaticamente na próxima reiniciar
  • memtag-off: uma tecnologia de segurança de memória, conforme definido acima, está desativada.

• [C-3-2] PRECISA permitir que o usuário do shell defina arm64.memtag.bootctl.

• [C-3-3] PRECISA permitir que qualquer processo leia arm64.memtag.bootctl.

• [C-3-4] PRECISA definir arm64.memtag.bootctl como o estado solicitado no momento na inicialização, ele PRECISA também atualizar a propriedade, se a implementação do dispositivo permite modificar o estado sem alterar a propriedade do sistema.

• [C-SR-16] É FORTEMENTE RECOMENDADO mostrar uma configuração do desenvolvedor que defina "memtag-uma" e reinicializa o dispositivo. Com um carregador de inicialização compatível, o O Android Open Source Project atende aos requisitos acima por meio do protocolo do carregador de inicialização da MTE.

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

9,8. Privacidade

9.8.1. Histórico de uso

O Android armazena o histórico de escolhas do usuário e o gerencia UsageStatsManager.

Implementações de dispositivos:

• [C-0-1] PRECISA manter um período de retenção razoável desse histórico do usuário.
• [C-SR-1] É FORTEMENTE RECOMENDADO manter o período de retenção de 14 dias como configurado por padrão na implementação do AOSP.

O Android armazena os eventos do sistema usando o StatsLog. identificadores e gerencia esse histórico por meio do StatsManager e do API do sistema IncidentManager.

Implementações de dispositivos:

• [C-0-2] É PRECISO incluir apenas os campos marcados com DEST_AUTOMATIC no relatório de incidentes criado pela classe IncidentManager da API do sistema.
• [C-0-3] NÃO É NECESSÁRIO usar os identificadores de eventos do sistema para registrar outros eventos. do que o descrito nos StatsLog documentos do SDK. Se eventos adicionais do sistema forem registrados, eles PODEM usar uma identificador atômico diferente no intervalo entre 100.000 e 200.000.

9.8.2. Gravações

Implementações de dispositivos:

• [C-0-1] NÃO PODE pré-carregar nem distribuir componentes de software prontos para uso que enviar informações particulares do usuário (por exemplo, pressionamentos de teclas, texto exibido no tela, relatório de bug) para fora do dispositivo sem o consentimento do usuário ou claro notificações em andamento.

• [C-0-2] O usuário PRECISA exibir um aviso e receber o consentimento explícito dele. permitindo que qualquer informação confidencial exibida na tela do usuário ser capturada toda vez que uma sessão a tela for iniciada pela MediaProjection.createVirtualDisplay(), VirtualDeviceManager.createVirtualDisplay(), ou APIs proprietárias.

• [C-0-3] O usuário PRECISA ter uma notificação contínua para o usuário durante a transmissão de tela. ou a gravação de tela está ativada. O AOSP atende a esse requisito mostrando uma ícone de notificação em andamento na barra de status.

• [C-SR-1] É FORTEMENTE RECOMENDADO a exibição de um aviso ao usuário exatamente a mesma mensagem implementada no AOSP, mas PODE ser alterada, desde que a avisar claramente ao usuário que qualquer informação sensível na conta do usuário é capturada.

• [C-0-4] NÃO PODE fornecer aos usuários uma affordance para desativar futuros prompts de o consentimento do usuário para capturar a tela, a menos que a sessão seja iniciada por um app do sistema que o usuário permitiu associate() com o android.app.role.COMPANION_DEVICE_APP_STREAMING ou o android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING do dispositivo.

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

Se as implementações de dispositivos incluem funcionalidades no sistema que Captura o conteúdo exibido na tela e/ou grava o stream de áudio reproduzido no dispositivo que não seja pela API do sistema ContentCaptureService ou outros meios reservados descritos em Seção 9.8.6 Dados do ambiente e do SO, são:

• [C-1-1] O usuário PRECISA ter uma notificação em andamento ao usuário esteja ativada e esteja ativamente capturando/gravando.

Se as implementações do dispositivo incluem um componente habilitado para uso, capaz de gravar o áudio do ambiente e/ou gravar o áudio tocado no dispositivo para inferir informações úteis sobre o contexto do usuário, eles:

• [C-2-1] NÃO PODE armazenar no armazenamento persistente no dispositivo nem transmitir o o áudio bruto gravado ou qualquer formato que possa ser convertido de volta o áudio original ou um fax, exceto com o consentimento explícito do usuário.

Um "indicador de microfone" refere-se a uma visualização na tela, que fica constantemente visível para o usuário, que não pode ser ocultada, o que os usuários entendem como um microfone usar(por meio de texto, cor, ícone ou alguma combinação exclusiva).

Um "indicador da câmera" refere-se a uma visualização na tela, que fica constantemente visível para os o usuário e não pode ser ocultada, o que os usuários entendem como uma câmera está em uso (por meio de texto, cor, ícone ou alguma combinação exclusiva).

Após o primeiro segundo exibido, um indicador pode mudar visualmente, como ficando menor e não precisa aparecer como apresentado originalmente e entendido.

O indicador de microfone pode ser mesclado com uma câmera exibida ativamente indicador, desde que o texto, os ícones ou as cores indiquem ao usuário que o uso do microfone tiver começado.

O indicador da câmera pode ser mesclado com um microfone ativo indicador, desde que o texto, os ícones ou as cores indiquem ao usuário que o a câmera começou.

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

• [C-SR-1] É FORTEMENTE RECOMENDADO mostrar o indicador de microfone quando um app está acessando dados de áudio do microfone, mas não quando ele está acessado apenas por HotwordDetectionService, SOURCE_HOTWORD ContentCaptureService ou apps com os papéis destacados na seção 9.1 Permissões com identificador CDD [C-3-X]. .
• [C-SR-2] É FORTEMENTE RECOMENDADO a exibição da lista de itens recentes e ativos Apps que usam o microfone como retornado PermissionManager.getIndicatorAppOpUsageData(), com qualquer atribuição mensagens associadas a elas.
• [C-SR-3] É FORTEMENTE RECOMENDADO não 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 dispositivo declararem android.hardware.camera.any, elas:

• [C-SR-4] É FORTEMENTE RECOMENDADO a exibição do indicador da câmera quando um app for acessar dados da câmera em tempo real, mas não quando ela só estiver sendo acessada por aplicativos com as funções mencionadas na Seção 9.1 Permissões com CDD identificador [C-3-X].
• [C-SR-5] É FORTEMENTE RECOMENDADO a exibição de apps recentes e ativos usando câmera conforme retornado de PermissionManager.getIndicatorAppOpUsageData(), além de mensagens de atribuição associadas.
• [C-SR-6] É FORTEMENTE RECOMENDADO para não ocultar o indicador da câmera para o sistema apps com interfaces do usuário visíveis ou interação direta com o usuário.

9.8.3. Conectividade

Se as implementações de dispositivos tiverem uma porta USB com suporte ao modo de periférico USB, eles:

• [C-1-1] PRECISA apresentar uma interface do usuário solicitando o consentimento antes de permitindo acesso ao conteúdo do armazenamento compartilhado pela porta USB.

9.8.4. Tráfego de rede

Implementações de dispositivos:

• [C-0-1] É NECESSÁRIO pré-instalar os mesmos certificados raiz para os certificados raiz confiáveis pelo sistema Repositório da autoridade certificadora (CA) conforme fornecido no Android Open Source Project.
• [C-0-2] PRECISA enviar com um repositório de CAs raiz de usuário vazio.
• [C-0-3] PRECISA mostrar um aviso ao usuário indicando o tráfego de rede. pode ser monitorada quando uma CA raiz do usuário é adicionada.

Se o tráfego do dispositivo for roteado por uma VPN, as implementações do dispositivo:

• [C-1-1] PRECISA exibir um aviso ao usuário indicando:
  • Esse tráfego de rede pode ser monitorado.
  • O tráfego de rede está sendo roteado pela VPN específica aplicativo que fornece a VPN.

Se as implementações do dispositivo tiverem um mecanismo ativado e pronto para uso por padrão, roteia o tráfego de dados de rede por um servidor proxy ou gateway de VPN (por exemplo, pré-carregando um serviço de VPN com android.permission.CONTROL_VPN concedido), eles:

• [C-2-1] PRECISA solicitar o consentimento do usuário antes de ativar esse mecanismo. a menos que a VPN seja ativada pelo controlador de política de dispositivo por meio do DevicePolicyManager.setAlwaysOnVpnPackage(), Nesse caso, o usuário não precisa fornecer um consentimento separado, mas PRECISA ser notificado apenas.

Se as implementações de dispositivo implementam uma affordance do usuário para alternar na "VPN sempre ativa" de um app de VPN de terceiros, elas:

• [C-3-1] PRECISA desativar essa funcionalidade do usuário para apps incompatíveis. serviço de VPN sempre ativa no arquivo AndroidManifest.xml pela configuração do SERVICE_META_DATA_SUPPORTS_ALWAYS_ON para false.

9.8.5. Identificadores de dispositivo

Implementações de dispositivos:

• [C-0-1] PRECISA impedir o acesso ao número de série do dispositivo. Quando aplicável, IMEI/MEID, número de série do chip e número de celular internacional Identidade do assinante (IMSI, na sigla em inglês) de um app, a menos que atenda a uma das seguintes condições requisitos:
  • é um app de operadora assinado verificado pelos fabricantes de dispositivos.
  • recebeu a permissão READ_PRIVILEGED_PHONE_STATE.
  • tem privilégios de operadora, conforme definido nos Privilégios de operadora do UICC.
  • é um proprietário de dispositivo ou perfil que recebeu o READ_PHONE_STATE.
  • (somente para o número de série do chip/ICCID) tem o requisito de regulamentações locais. que o app detecte alterações na identidade do assinante.

9.8.6. Dados do SO e do ambiente

O Android, por meio das APIs do sistema, oferece suporte a um mecanismo para para capturar os seguintes dados sensíveis:

• Texto e gráficos renderizados na tela, incluindo, entre outros, notificações e dados de assistência pelo AssistStructure API.
• Dados de mídia, como áudio ou vídeo, gravados ou reproduzidos pelo dispositivo.

• Eventos de entrada (por exemplo, tecla, mouse, gesto, voz, vídeo e acessibilidade).

• Qualquer tela ou outros dados enviados pelo AugmentedAutofillService para o sistema.

• Qualquer tela ou outros dados acessíveis via Content Capture APIs de terceiros.

• Todos os dados do aplicativo transmitidos ao sistema pela API AppSearchManager e acessível via AppSearchGlobalManager.query.

• Qualquer texto ou outro dado enviado por meio do TextClassifier API ao TextClassifier do sistema, ou seja, ao serviço do sistema para entender o significado do texto, além de gerar as próximas ações previstas com base no o texto.

• Dados indexados pela implementação da plataforma AppSearch, incluindo, mas não Limitado a texto, gráficos, dados de mídia ou outros dados semelhantes.

• Dados de áudio como resultado do uso SpeechRecognizer#onDeviceSpeechRecognizer() pelo reconhecedor de fala Implementação.

• Dados de áudio recebidos em segundo plano (continuamente) por AudioRecord. SoundTrigger ou outras APIs de áudio que não resultem em um indicador

• Dados da câmera obtidos em segundo plano (continuamente) pelo CameraManager ou outras APIs de câmera e não resulta em um indicador visível para o usuário

Se as implementações de dispositivo capturarem qualquer um dos dados acima, elas:

• [C-1-1] PRECISA criptografar todos esses dados quando armazenados no dispositivo. Isso pode ser realizada com a criptografia baseada em arquivos do Android ou qualquer das criptografias listadas como API versão 26+ descritas em Cipher SDK.
• [C-1-2] NÃO PODE fazer backup de dados brutos ou criptografados usando o Métodos de backup do Android ou qualquer outro .
• [C-1-3] PRECISA enviar apenas esses dados do do dispositivo usando um mecanismo de preservação de privacidade, exceto com o consentimento explícito do usuário sempre que os dados compartilhadas. O mecanismo de preservação da privacidade é definida como "aqueles que permitem apenas análises agregadas e evitam correspondência de eventos registrados ou resultados derivados para usuários individuais", para evitar que dados por usuário sejam introspectáveis (por exemplo, implementados usando uma tecnologia de privacidade diferencial, como RAPPOR).
• [C-1-4] NÃO PODE associar esses dados a nenhuma identidade do usuário (como como Account) no dispositivo, exceto com o consentimento explícito do usuário sempre que os dados forem associadas.
• [C-1-5] NÃO PODE compartilhar esses dados com outros componentes do SO que não siga os requisitos descritos na seção atual. (9.8.6 Nível do SO e dados ambientes), exceto com consentimento explícito do usuário a cada o horário em que é compartilhado. A menos que tal funcionalidade seja criado como uma API do SDK do Android (AmbientContext, HotwordDetectionService).
• [C-1-6] PRECISA fornecer recursos ao usuário para apagar dados que a implementação ou os meios reservados coletam quando os dados são armazenados de qualquer forma no dispositivo. Se o o usuário optar por apagar os dados, PRECISA remover todos os dados históricos dados.

• [C-1-7] PRECISA fornecer recursos para o usuário recusar os dados coletados. via AppSearch ou meios reservados para exibição na plataforma Android (por exemplo, tela de início).

• [C-SR-1] É RECOMENDADO NÃO solicitar a permissão de INTERNET.

• [C-SR-2] É FORTEMENTE RECOMENDADO que você só acesse a Internet usando o APIs estruturadas baseadas em implementações de código aberto disponíveis publicamente.

• [C-SR-4] É FORTEMENTE RECOMENDADO que sejam implementadas com a API do SDK do Android ou um repositório de código aberto semelhante de propriedade do OEM; e / ou ser realizado em uma Implementação no modo sandbox (consulte 9.8.15 Implementações da API no modo sandbox).

Se as implementações de dispositivos incluem um serviço que implementa a API do sistema ContentCaptureService, AppSearchManager.index ou qualquer serviço reservado que captura os dados conforme descrito acima, eles:

• [C-2-1] NÃO PODE permitir que os usuários substituam os serviços por um aplicativo ou serviço instalável pelo usuário e PRECISA permitir somente o serviços pré-instalados para capturar esses dados.
• [C-2-2] NÃO PODE permitir outros apps além dos serviços pré-instalados mecanismo de pesquisa para coletar esses dados.
• [C-2-3] PRECISA fornecer recursos do usuário para desativar os serviços.

• [C-2-4] NÃO PODE omitir affordance do usuário para gerenciar permissões do Android que são mantidos pelos serviços e seguem as permissões do Android conforme descrito na Seção 9.1. Permissão.

• [C-SR-3] É FORTEMENTE RECOMENDADO para manter os serviços separados dos outros componentes do sistema (por exemplo, não vincular os IDs de processos de serviço ou compartilhamento) exceto:

  • Telefonia, Contatos, interface do sistema e mídia

9.8.7. Acesso à área de transferência

Implementações de dispositivos:

• [C-0-1] NÃO PODE retornar dados recortados da área de transferência (por exemplo, por meio do método ClipboardManager a menos que o terceiro app é o IME padrão ou é o app em foco no momento.

• [C-0-2] PRECISA limpar os dados da área de transferência no máximo 60 minutos após a última vez. colocado em uma área de transferência ou lido de uma área de transferência.

9.8.8. Local

O local inclui informações na classe Location do Android( como Latitude, Longitude, Altitude), bem como identificadores que podem ser convertidos para "Location". A localização pode ser tão adequada quanto DGPS (Sistema de Posicionamento Global Diferencial) ou aproximada quanto aos locais no nível do país (como o local do código do país - MCC - Celular código do país).

Veja a seguir uma lista de tipos de local que derivam diretamente o valor da local ou podem ser convertidos à localização de um usuário. Esta não é uma lista completa mas deve ser usado como um exemplo de qual local pode ou não ser derivados indiretamente de:

• GPS/GNSS/DGPS/PPP
  • Solução de Posicionamento Global ou Sistema Global de Navegação por Satélite ou Solução de posicionamento global diferencial
  • Isso também inclui medições brutas de GNSS e o status de GNSS
    • O local preciso pode ser derivado das medições GNSS brutas
• Tecnologias sem fio com identificadores exclusivos, como:
  • Pontos de acesso Wi-Fi (MAC, BSSID, Nome ou SSID)
  • Bluetooth/BLE (MAC, BSSID, nome ou SSID)
  • UWB (MAC, BSSID, nome ou SSID)
  • ID de torre de celular (3G, 4G, 5G... incluindo todo o modem celular futuro) tecnologias que têm identificadores exclusivos)

Como ponto de referência principal, consulte as APIs do Android que exigem ACCESS_FINE_Location ou ACCESS_COARSE_Location.

Implementações de dispositivos:

• [C-0-1] NÃO É POSSÍVEL ativar/desativar a configuração de localização do dispositivo nem o Wi-Fi/Bluetooth configurações de verificação sem o consentimento explícito do usuário ou a iniciação dele.
• [C-0-2] PRECISA fornecer recursos para o usuário acessar a localização. informações, incluindo solicitações de localização recentes, uso e permissões no nível do app de busca por Wi-Fi/Bluetooth para determinar a localização.
• [C-0-3] PRECISA garantir que o app use a API Emergency Location Bypass [LocationRequest.setLocationSettingsIgnored()] é uma emergência iniciada pelo usuário sessão (por exemplo, disque 911 ou envie uma mensagem de texto para 190). Para o setor automotivo, no entanto, um veículo pode iniciar uma sessão de emergência sem interação do usuário ativo no caso um acidente/acidente é detectado (por exemplo, para atender aos requisitos de chamada telefônica);
• [C-0-4] PRECISA preservar a capacidade das APIs de ignorar local de emergência de ignorar as configurações de localização do dispositivo sem mudar as configurações.
• [C-0-5] PRECISA programar uma notificação para lembrar o usuário depois de abrir o app o segundo plano acessou a localização dela usando o Permissão [ACCESS_BACKGROUND_LOCATION].

9.8.9. Apps instalados

Os apps Android destinados ao nível 30 da API ou mais recente não podem ver detalhes sobre outros apps instalados por padrão. Consulte Visibilidade do pacote na documentação do SDK).

Implementações de dispositivos:

• [C-0-1] NÃO É POSSÍVEL expor a nenhum app direcionado aos detalhes da API de nível 30 ou mais recente. sobre qualquer outro aplicativo instalado, a menos que o aplicativo já possa ver detalhes sobre o outro app instalado pelas APIs gerenciadas. Isso inclui, mas não não se limitam aos detalhes expostos por quaisquer APIs personalizadas adicionadas pelo dispositivo ou pode ser acessado pelo sistema de arquivos.
• [C-0-2] NÃO PODE conceder a qualquer aplicativo acesso de leitura ou gravação a arquivos de qualquer outro diretório dedicado e específico do app no armazenamento externo. As únicas exceções são as seguintes:
  • A autoridade do provedor de armazenamento externo (por exemplo, apps como DocumentsUI).
  • O provedor de download que usa a opção "downloads" do provedor para fazer o download de arquivos para o armazenamento do app.
  • Aplicativos de protocolo de transferência de mídia (MTP, na sigla em inglês) assinados pela plataforma que usam o permissão privilegiada ACCESS_MTP para permitir a transferência de arquivos para em outro dispositivo.
  • Apps que instalam outros apps e têm permissão INSTALL_PACKAGES só pode acessar "obb" diretórios com o objetivo de gerenciar Arquivos de expansão APK

9.8.10. Relatório de bugs de conectividade

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

• [C-1-1] PRECISA oferecer suporte à geração de relatórios de bugs de conectividade por BUGREPORT_MODE_TELEPHONY com BugreportManager.
• [C-1-2] PRECISA ter o consentimento do usuário sempre que BUGREPORT_MODE_TELEPHONY for usados para gerar um relatório e NÃO PODEM solicitar que o usuário autorize todos os futuras solicitações do aplicativo.
• [C-1-3] NÃO PODE retornar o relatório gerado ao aplicativo solicitante sem o consentimento explícito do usuário.
• [C-1-4] Os relatórios gerados usando BUGREPORT_MODE_TELEPHONY PRECISAM conter pelo menos as seguintes informações:
  • TelephonyDebugService despejados
  • TelephonyRegistry despejados
  • WifiService despejados
  • ConnectivityService despejados
  • Um despejo da instância CarrierService do pacote de chamada (se vinculado).
  • Buffer de registro de rádio
  • SubscriptionManagerService despejados
• [C-1-5] NÃO PODE incluir o seguinte nos relatórios gerados:
  • Qualquer tipo de informação que não esteja diretamente relacionada à conectividade depuração.
  • Qualquer tipo de registros de tráfego de aplicativos instalados pelo usuário ou perfis detalhados de aplicativos/pacotes instalados pelo usuário (UIDs são aceitáveis, nomes de pacotes são não).
• PODE incluir informações adicionais que não estão associadas a nenhum usuário identidade. (por exemplo, registros do fornecedor).

Se as implementações de dispositivos incluírem informações adicionais (por exemplo, registros do fornecedor) no relatórios de bugs e se as informações têm privacidade/segurança/bateria/armazenamento/memória impacto, eles:

• [C-SR-1] É ALTAMENTE RECOMENDADO ter uma configuração de desenvolvedor definida como padrão desativado. A implementação de referência do AOSP atende a isso, fornecendo o Enable verbose vendor logging opção nas configurações do desenvolvedor para incluir mais registros de fornecedores específicos do dispositivo nos relatórios de bugs.

9.8.11. Compartilhamento de blobs de dados

Android, por meio do BlobStoreManager permite que apps contribuam com blobs de dados para que o sistema seja compartilhado com um completo de aplicativos.

Se as implementações de dispositivos forem compatíveis com blobs de dados compartilhados, conforme descrito nas Documentação do SDK, eles:

• [C-1-1] NÃO PODE compartilhar blobs de dados pertencentes a apps além do que eles para permitir (ou seja, o escopo do acesso padrão e as outras que podem ser especificados usando BlobStoreManager.session#allowPackageAccess(); BlobStoreManager.session#allowSameSignatureAccess(), ou BlobStoreManager.session#allowPublicAccess() NÃO PODE ser modificado). A implementação de referência do AOSP atende a essas e cumprimento de requisitos regulatórios.
• [C-1-2] NÃO É POSSÍVEL enviar os hashes seguros para fora do dispositivo nem compartilhar com outros apps os hashes seguros de blobs de dados usados para controlar o acesso.

9.8.12. Identificação de música

O Android, por meio da API MusicRecognitionManager do sistema, oferece suporte a um mecanismo para implementações de dispositivos para solicitar reconhecimento de música, com base em uma gravação de áudio e delegar o reconhecimento de música a um app privilegiado que implementa o API MusicRecognitionService.

Se as implementações de dispositivos incluem um serviço que implementa a API do sistema MusicRecognitionManager ou qualquer serviço reservado que transmita dados de áudio como descritos acima, eles:

• [C-1-1] PRECISA garantir que o autor da chamada do MusicRecognitionManager mantenha o Permissão para MANAGE_MUSIC_RECOGNITION
• [C-1-2] PRECISA impor que um único sistema de reconhecimento de música aplicativo implementa MusicRecognitionService.
• [C-1-3] NÃO PODE permitir que os usuários substituam o MusicRecognitionManagerService ou MusicRecognitionService com um aplicativo ou serviço instalável pelo usuário.
• [C-1-4] PRECISA garantir que, quando o MusicRecognitionManagerService acessa o gravação de áudio e o encaminha para o aplicativo implementando a MusicRecognitionService, o acesso ao áudio é rastreado por meio de invocações de AppOpsManager.noteOp / startOp

Se as implementações do dispositivo MusicRecognitionManagerService ou O MusicRecognitionService armazena todos os dados de áudio capturados. Eles:

• [C-2-1] NÃO É POSSÍVEL armazenar impressões digitais de áudio ou áudio brutas em disco de nenhuma forma, ou na memória por mais de 14 dias.
• [C-2-2] NÃO PODE compartilhar esses dados além do MusicRecognitionService, exceto com o consentimento explícito do usuário sempre que é compartilhado.

9.8.13. SensorPrivacyManager

Se as implementações de dispositivos fornecerem ao usuário uma funcionalidade de software para desativar a entrada de câmera e/ou microfone para a implementação do dispositivo, eles:

• [C-1-1] PRECISA retornar "true" com precisão. nos formatos supportsSensorToggle() Método de API.
• [C-1-2] PRECISA, quando um app tenta acessar uma câmera ou um microfone bloqueado. apresentar ao usuário uma funcionalidade de usuário não dispensável que claramente indica que o sensor está bloqueado e requer uma escolha para continuar bloquear ou desbloquear de acordo com a implementação do AOSP que atenda a requisito fundamental.
• [C-1-3] PRECISA transmitir apenas dados de áudio e câmera em branco (ou falsos) para apps e não informa um código de erro porque o usuário não ligou a câmera. nem microfone pela affordance do usuário apresentada de acordo com [C-1-2] acima.

9.8.14. N/A

9.8.15. Implementações da API no modo sandbox

O Android, por meio de um conjunto de APIs delegadas, fornece um mecanismo para processar dados Dados do SO e do ambiente. Esse processamento pode ser delegado com acesso privilegiado e capacidades de comunicação reduzidas, conhecido como Implementação da API no modo sandbox.

Qualquer implementação de API no modo sandbox:

• [C-0-1] NÃO PODE solicitar a permissão INTERNET.
• [C-0-2] PRECISA acessar a Internet apenas por APIs estruturadas com suporte de em implementações de código aberto públicas que preservam a privacidade ou indiretamente por meio de APIs do SDK do Android. O papel que preserva a privacidade mecanismo é definido como "aqueles que permitem apenas análises agregadas e impedir a correspondência de eventos registrados ou resultados derivados a usuários individuais", para evitar que dados por usuário sejam introspectáveis (por exemplo, implementados usando uma tecnologia de privacidade diferencial, RAPPOR).
• [C-0-3] PRECISA manter os serviços separados de outros componentes do sistema (por exemplo, não vincule os IDs de processo de serviço ou compartilhamento), exceto pelas seguinte:
  • Telefonia, Contatos, interface do sistema e mídia
• [C-0-4] NÃO PODE permitir que os usuários substituam os serviços por um aplicativo ou serviço instalável pelo usuário
• [C-0-5] PRECISA permitir que apenas os serviços pré-instalados capturem esses dados. A menos que o recurso de substituição esteja integrado ao AOSP (por exemplo, para apps do Assistente).
• [C-0-6] NÃO PODE permitir outros apps além dos serviços pré-instalados mecanismo de pesquisa para coletar esses dados. A menos que esse recurso de captura é implementado com uma API Android SDK.
• [C-0-7] PRECISA fornecer recursos do usuário para desativar os serviços.
• [C-0-8] NÃO PODE omitir affordance do usuário para gerenciar permissões do Android que são mantidos pelos serviços e seguem o modelo de permissões do Android. descritos em Seção 9.1. Permissão.

9.8.16. Áudio contínuo e dados da câmera

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

• [C-0-1] PRECISA aplicar um indicador correspondente (câmera e/ou microfone como de acordo com a seção 9.8.2 Gravação), a menos que:
  • Esse acesso é realizado em uma implementação no modo sandbox (consulte 9.8.15 Implementação de API no modo sandbox), por meio de um pacote contendo um ou mais dos seguintes papéis: Inteligência de interface do sistema, Inteligência de áudio ambiente do sistema, Inteligência de áudio do sistema, Inteligência de notificações do sistema, Inteligência de texto do sistema, ou Inteligência visual do sistema.
  • O acesso é realizado por meio de um sandbox, implementado e aplicada por mecanismos no AOSP (HotwordDetectionService, WearableSensingService e VisualQueryDetector).
  • O acesso ao áudio é realizado para fins de assistência pelo App do Assistente, fornecendo SOURCE_HOTWORD como fonte de áudio.
  • O acesso é realizado pelo sistema e implementado com com código-fonte aberto.
• [C-SR-1] É FORTEMENTE RECOMENDADO exigir o consentimento do usuário para cada que utilizam esses dados e ficam desativados por padrão.
• [C-SR-2] RECOMENDOU FORTEMENTE a aplicar o mesmo tratamento (por exemplo, seguir as restrições descritas em 9.8.2 Gravação, 9.8.6 Dados do ambiente e do SO 9.8.15 Implementações da API no modo sandbox e 9.8.16 Áudio e câmera contínuos para dados da Câmera provenientes de um dispositivo wearable remoto.

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

• [C-1-1] PRECISA indicar ao dispositivo wearable remoto que exibir um indicador adicional lá.

Se os dispositivos oferecerem a capacidade de interagir com um aplicativo de assistente digital sem a palavra-chave atribuída (tratando consultas genéricas do usuário ou analisando a presença do usuário pela câmera), eles:

• [C-2-1] PRECISA garantir que essa implementação seja fornecida por um pacote contendo a android.app.role.ASSISTANT.
• [C-2-2] PRECISA garantir que essa implementação use HotwordDetectionService. e/ou VisualQueryDetectionService APIs do Android.

9.8.17. Telemetry

O Android armazena registros do sistema e do app usando as APIs StatsLog. Esses registros são gerenciados via APIs do StatsManager, que podem ser usadas por aplicativos de sistema com privilégios.

O StatsManager também oferece uma maneira de coletar dados categorizados como dados de privacidade sensíveis de dispositivos com um mecanismo de preservação da privacidade. Especificamente, A API StatsManager::query possibilita consultar métricas restritas categorias definidas no StatsLog.

As consultas de implementação e a coleta de métricas restritas Gerenciador de estatísticas:

• [C-0-1] PRECISA ser o único aplicativo/implementação no dispositivo e manter a permissão READ_RESTRICTED_STATS.
• [C-0-2] PRECISA enviar somente dados de telemetria e o registro do dispositivo usando um mecanismo de preservação da privacidade. O mecanismo de preservação de privacidade é definido como "aqueles que permitem somente análise agregada e impedem a correspondência de eventos registrados ou resultados derivados para usuários individuais", a fim de evitar que qualquer dados por usuário sendo introspectivos (por exemplo, implementados usando um diferencial tecnologia de privacidade, como RAPPOR).
• [C-0-3] NÃO PODE associar esses dados a nenhuma identidade do usuário (como Account) no dispositivo.
• [C-0-4] NÃO PODE compartilhar esses dados com outros componentes do SO que não seguem. requisitos descritos na seção atual (9.8.17 Preservação da privacidade telemetria).
• [C-0-5] PRECISA fornecer recursos do usuário para ativar/desativar a preservação da privacidade. a coleta, o uso e o compartilhamento de telemetria.
• [C-0-6] PRECISA fornecer recursos ao usuário para apagar dados que coleta se os dados estão armazenados de alguma forma no dispositivo. Se o usuário optou por apagar os dados, PRECISA remover todos os dados atualmente armazenados no o dispositivo.
• [C-0-7] PRECISA divulgar a implementação do protocolo que preserva a privacidade em um repositório de código aberto.
• [C-0-8 ]É NECESSÁRIO aplicar as políticas de saída de dados nesta seção para bloquear a coleta de dados em categorias de métricas restritas definidas em StatsLog.

9,9. Criptografia do armazenamento de dados

Todos os dispositivos PRECISAM atender aos requisitos da seção 9.9.1. Os dispositivos iniciados em um nível de API anterior ao deste documento não isento dos requisitos das seções 9.9.2 e 9.9.3; em vez disso, eles PRECISA atender aos requisitos da seção 9.9 da Política de compatibilidade do Android Documento de definição correspondente ao nível da API em que o dispositivo foi iniciado.

9.9.1. Inicialização direta

Implementações de dispositivos:

• [C-0-1] PRECISA implementar as APIs do modo de inicialização direta, mesmo que ela não é compatível com a criptografia de armazenamento.

• [C-0-2] O ACTION_LOCKED_BOOT_COMPLETED e ACTION_USER_UNLOCKED As intents ainda DEVEM ser transmitidas para sinalizar aplicativos cientes do Direct Boot que Os locais de armazenamento criptografado pelo dispositivo (DE) e criptografado por credencial (CE, na sigla em inglês) são disponíveis para o usuário.

9.9.2. Requisitos de criptografia

Implementações de dispositivos:

• [C-0-1] PRECISA criptografar o aplicativo como privado dados (partição /data), bem como a partição de armazenamento compartilhado do aplicativo (partição /sdcard) se for uma parte permanente e não removível do dispositivo.
• [C-0-2] PRECISA ativar a criptografia do armazenamento de dados por padrão no momento o usuário tiver concluído a experiência de configuração pronta para uso.

• [C-0-3] PRECISA atender à criptografia de armazenamento de dados acima. requisito implementando um dos dois métodos de criptografia a seguir:

  • Criptografia baseada em arquivos (FBE) e Criptografia de metadados conforme descrito na seção 9.9.3.1.
  • Criptografia em nível de bloco por usuário, conforme descrito na seção 9.9.3.2.

.

9.9.3. Métodos de criptografia

Se as implementações de dispositivos forem criptografadas, elas:

• [C-1-1] PRECISA inicializar sem desafiar o usuário quanto a credenciais e permitir que apps com reconhecimento de inicialização direta acessem o armazenamento criptografado do dispositivo (DE) depois que a mensagem ACTION_LOCKED_BOOT_COMPLETED é transmitida.
• [C-1-2] PRECISA permitir o acesso ao armazenamento criptografado por credencial (CE, na sigla em inglês) apenas após o usuário desbloqueou o dispositivo informando as credenciais (por exemplo, senha, PIN, padrão ou impressão digital) e o ACTION_USER_UNLOCKED é transmitida.
• [C-1-13] NÃO PODE oferecer nenhum método para desbloquear o armazenamento protegido CE sem as credenciais fornecidas pelo usuário, uma chave de garantia registrada ou retomar a implementação na reinicialização atendendo aos requisitos em seção 9.9.4.
• [C-1-4] PRECISA usar a Inicialização verificada.

9.9.3.1. Criptografia baseada em arquivos e metadados

Se as implementações de dispositivos usam criptografia baseada em arquivos com criptografia de metadados, eles:

• [C-1-5] PRECISA criptografar conteúdos e metadados do sistema de arquivos usando AES-256-XTS ou Adiantum. O AES-256-XTS se refere ao Padrão de criptografia avançada com comprimento de chave de criptografia de 256 bits, operada no modo XTS; toda a extensão é de 512 bits.Adiantum se refere a Adiantum-XChaCha12-AES, conforme especificado em https://github.com/google/adiantum Os metadados do sistema de arquivos são dados como tamanhos, propriedade, modos e atributos estendidos (xattrs).
• [C-1-6] PRECISA criptografar nomes de arquivos usando AES-256-CBC-CTS, AES-256-HCTR2; ou Adiantum.
• [C-1-12] Se o dispositivo tiver o Padrão de criptografia avançada (AES) (como extensões de criptografia ARMv8 em dispositivos baseados em ARM ou AES-NI em dispositivos baseados em x86), depois as opções baseadas em AES acima para nome de arquivo; e a criptografia de metadados do sistema de arquivos PRECISA ser usada, não Adiantum.
• [C-1-13] PRECISA usar uma chave com criptografia forte e irreversível função de derivação (por exemplo, HKDF-SHA512) para derivar qualquer subchave necessária (por exemplo, por arquivo) das chaves CE e DE. "Criptograficamente forte e irreversível" significa que a função de derivação de chaves tem força de segurança de pelo menos 256 bits e se comporta como uma função pseudoaleatória família sobre as entradas.
• [C-1-14] NÃO PODE usar as mesmas chaves ou subchaves de criptografia baseada em arquivos (FBE, na sigla em inglês) para diferentes propósitos criptográficos (por exemplo, para criptografia e chaves ou para dois algoritmos de criptografia diferentes).
• [C-1-15] PRECISA garantir que todos os blocos não excluídos do conteúdo dos arquivos criptografados no armazenamento permanente foram criptografadas usando combinações de chaves de criptografia vetor de inicialização (IV) que dependem do arquivo e do deslocamento dentro o arquivo. Além disso, todas essas combinações PRECISAM ser distintas, exceto quando a criptografia é feita com hardware em linha que suporta apenas uma Comprimento de IV de 32 bits.
• [C-1-16] PRECISA garantir que todos os nomes de arquivo criptografados não excluídos nos arquivos armazenamento em diretórios diferentes era criptografado usando combinações distintas de chave de criptografia e vetor de inicialização (IV, na sigla em inglês).

• [C-1-17] PRECISA garantir que todos os blocos de metadados do sistema de arquivos criptografados o armazenamento permanente foram criptografados com combinações distintas de chaves de criptografia e vetor de inicialização (IV).

• Chaves que protegem as áreas de armazenamento CE e DE e os metadados do sistema de arquivos:

  • [C-1-7] PRECISA estar vinculado criptograficamente a um Keystore protegido por hardware. Este keystore PRECISA estar vinculado à Inicialização verificada e ao hardware do dispositivo. raiz de confiança.
  • [C-1-8] As chaves CE PRECISAM estar vinculadas às credenciais da tela de bloqueio de um usuário.
  • [C-1-9] As chaves CE PRECISAM ser vinculadas a uma senha padrão quando o usuário credenciais da tela de bloqueio não foram especificadas.
  • [C-1-10] PRECISA ser único e distinto, ou seja, nenhum CE ou DE do usuário corresponde a qualquer chave CE ou DE de outro usuário.
  • [C-1-11] PRECISA usar as criptografias, os comprimentos de chave e as dois modos.
  • [C-1-12] PRECISA ser apagado com segurança durante o desbloqueio e bloqueio do carregador de inicialização conforme descrito aqui.

• DEVE fazer apps essenciais pré-instalados (por exemplo, Alarme, Telefone, Messenger) Percepção do Direct Boot.

O projeto Android Open Source oferece uma implementação preferencial de Criptografia baseada em arquivos baseada no kernel "fscrypt" do Linux recurso de criptografia, e da criptografia de metadados com base no kernel do Linux "dm-default-key" .

9.9.3.2. Criptografia no nível de bloco por usuário

Se as implementações de dispositivos usarem criptografia no nível de bloco por usuário, elas:

• [C-1-1] PRECISA ativar o suporte multiusuário, conforme descrito na seção 9.5.
• [C-1-2] PRECISA fornecer partições por usuário, usando partições brutas ou como volumes lógicos.
• [C-1-3] PRECISA usar chaves de criptografia exclusivas e distintas por usuário para e a criptografia dos dispositivos de bloco subjacentes.

• [C-1-4] PRECISA usar AES-256-XTS para a criptografia em nível de bloco do usuário. partições diferentes.

• As chaves que protegem os dispositivos criptografados no nível de bloco por usuário:

  • [C-1-5] PRECISA estar vinculado criptograficamente a um Keystore protegido por hardware. Este keystore PRECISA estar vinculado à Inicialização verificada e ao hardware do dispositivo. raiz de confiança.
  • [C-1-6] PRECISA estar vinculado à tela de bloqueio do usuário correspondente. credenciais.

A criptografia no nível de bloco por usuário pode ser implementada usando o kernel do Linux "dm-crypt" em partições por usuário.

9.9.4. Retomar na reinicialização

A opção "Retomar na reinicialização" permite desbloquear o armazenamento CE de todos os apps, incluindo aqueles que ainda não sejam compatíveis com inicialização direta, após uma reinicialização iniciada por uma atualização OTA. Isso permite que os usuários recebam notificações de aplicativos instalados após a reiniciar o dispositivo.

A implementação de Retomar na reinicialização deve continuar para garantir que, quando um dispositivo cai nas mãos de um atacante, é extremamente difícil para que o invasor recupere os dados criptografados por CE do usuário, mesmo se o dispositivo estiver ligado ativado, o armazenamento CE é desbloqueado e o usuário desbloqueia o dispositivo depois de receber uma agência de viagens on-line. Para a resistência a ataques de pessoas com informações privilegiadas, também presumimos que o atacante obtém acesso para transmitir chaves de assinatura criptográficas.

Especificamente:

• [C-0-1] O armazenamento CE NÃO PODE ser legível, mesmo para o invasor que tenha fisicamente do dispositivo e, em seguida, tem estes recursos e limitações:

  • É possível usar a chave de assinatura de qualquer fornecedor ou empresa para assinar e envio de mensagens.
  • Pode fazer com que um OTA seja recebido pelo dispositivo.
  • Pode modificar a operação de qualquer hardware (AP, flash etc.), exceto as detalhadas abaixo, mas essa modificação envolve um atraso de pelo menos um por uma hora e uma reinicialização que destrói o conteúdo da RAM.
  • Não pode modificar a operação de hardware resistente a adulterações (por exemplo, Titan M).
  • Não é possível ler a RAM do dispositivo ativo.
  • Não é possível receber a credencial do usuário (PIN, padrão, senha) ou fazer com que ele seja inserido.

Por exemplo, uma implementação de dispositivo que implementa e está em conformidade com todos das descrições encontradas aqui será compatível com [C-0-1].

9,10 Integridade do dispositivo

Os requisitos a seguir garantem a transparência no status dos integridade do dispositivo. Implementações de dispositivos:

• [C-0-1] PRECISA gerar relatórios corretamente pelo método da API do sistema. PersistentDataBlockManager.getFlashLockState() se o carregador de inicialização permite a atualização da imagem do sistema.

• [C-0-2] PRECISA oferecer suporte à Inicialização verificada para garantir a integridade do dispositivo.

Se as implementações de dispositivos já tiverem sido lançadas sem suporte à Inicialização verificada em uma versão anterior do Android e não é possível adicionar suporte para isso com uma atualização de software do sistema, eles PODEM ficar isentos da requisito fundamental.

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

• [C-1-1] PRECISA declarar a flag de recurso da plataforma android.software.verified_boot:
• [C-1-2] PRECISA fazer a verificação em todas as sequências de inicialização.
• [C-1-3] PRECISA iniciar a verificação usando uma chave de hardware imutável, raiz de confiança e vão até a partição do sistema.
• [C-1-4] PRECISA implementar cada estágio da verificação para conferir a integridade. e a autenticidade de todos os bytes no estágio seguinte antes de executar o código para a próxima etapa.
• [C-1-5] PRECISA usar algoritmos de verificação tão fortes quanto os atuais. recomendações do NIST para algoritmos de hash (SHA-256) e chaves públicas (RSA-2048).
• [C-1-6] NÃO PODE permitir que a inicialização seja concluída quando a verificação do sistema falhar. a menos que o usuário concorde em tentar inicializar de qualquer maneira. Nesse caso, os dados nenhum bloco de armazenamento não verificado PRECISA ser usado.
• [C-1-7] NÃO PODE permitir a modificação de partições verificadas no dispositivo a menos que o usuário tenha desbloqueado explicitamente o carregador de inicialização.
• [C-1-8] PRECISA usar armazenamento à prova de adulterações: para armazenar carregador de inicialização está desbloqueado. Isso significa que o carregador de inicialização pode detectar se o armazenamento foi adulterado no Android.
• [C-1-9] PRECISA solicitar ao usuário durante o uso do dispositivo. exigem confirmação física antes de permitir uma transição do carregador de inicialização modo bloqueado para o modo desbloqueado pelo carregador de inicialização.
• [C-1-10] PRECISA implementar a proteção contra reversão para partições usadas pelo Android. por exemplo, inicialização, partições do sistema) e usar armazenamento à prova de adulterações para metadados usados para determinar a versão mínima permitida do SO.
• [C-1-11] PRECISA apagar com segurança todos os dados do usuário durante o desbloqueio do carregador de inicialização e de acordo com a seção 9.12. Exclusão de dados incluindo a partição de dados do usuário e espaços NVRAM).

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

• [C-SR-2] É FORTEMENTE RECOMENDADO para verificar todos os arquivos APK de apps privilegiados com uma cadeia de confiança enraizada em partições protegidas pela Inicialização verificada.
• [C-SR-3] É FORTEMENTE RECOMENDADO para verificar todos os artefatos executáveis carregados por um app privilegiado de fora do arquivo APK (como um código carregado dinamicamente ou código compilado) antes de executá-los ou FOR FORTEMENTE RECOMENDADO não executá-los de verdade.
• DEVE implementar a proteção contra reversão em todos os componentes com (por exemplo, modem, câmera) e DEVE usar armazenamento à prova de adulterações para armazenamento dos metadados usados para determinar a versão mínima permitida.

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

O Android Open Source Project fornece uma implementação preferencial de esse recurso no external/avb/ , que pode ser integrado ao carregador de inicialização usado para Android

Se as implementações de dispositivos puderem verificar o arquivo conteúdo por página, eles:

• [C-2-1] oferece suporte à verificação criptográfica do conteúdo do arquivo sem ler o em todo o arquivo.

• [C-2-2] NÃO PODE permitir o solicitações de leitura em um arquivo protegido para que tenham êxito quando o conteúdo de leitura não for de acordo com [C-2-1] acima.

• [C-2-4] PRECISA retornar a soma de verificação do arquivo em O(1) para arquivos ativados.

Se as implementações de dispositivos já tiverem sido lançadas sem a capacidade de verificação conteúdo do arquivo para uma chave confiável em uma versão anterior do Android e não pode adicionar suporte para esse recurso com uma atualização de software do sistema, eles PODEM ser isentos do requisito. O projeto Android Open Source disponibiliza implementação preferencial desse recurso com base no recurso fs-verity do kernel do Linux.

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

9,11. Chaves e credenciais

O sistema Android Keystore permite que os desenvolvedores de apps armazenem chaves criptográficas em um contêiner e as usem em operações criptográficas com a API KeyChain ou a API Keystore. Implementações de dispositivos:

• [C-0-1] PRECISA permitir a importação ou geração de pelo menos 8.192 chaves.
• [C-0-2] A autenticação da tela de bloqueio PRECISA implementar um intervalo de tempo. entre as tentativas com falha. Com "n" como a contagem de tentativas malsucedidas, o intervalo de tempo PRECISA ser de pelo menos 30 segundos para 9 < n < 30. Para n > 29, o valor do intervalo de tempo PRECISA ser de pelo menos 30*2^floor((n-30)/10)) segundos ou pelo menos 24 horas, o que for menor.
• Não DEVE limitar o número de chaves que podem ser geradas.

Quando a implementação do dispositivo é compatível com uma tela de bloqueio segura, ela:

• [C-1-1] PRECISA fazer backup da implementação do keystore com uma camada ou ambiente de execução.
• [C-1-2] PRECISA ter implementações de RSA, AES, ECDSA, ECDH (se IKeyMintDevice for compatível), 3DES, e algoritmos criptográficos HMAC e hash da 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 confiável, mas outra solução baseada em ARM TrustZone ou um terceiro avaliado como seguro a implementação adequada de um isolamento baseado em hipervisor são alternativas .
• [C-1-3] PRECISA executar a autenticação da tela de bloqueio no ambiente de execução e, somente quando bem-sucedido, permitem que os domínios de chaves sejam usadas. As credenciais da tela de bloqueio PRECISAM ser armazenadas em um permitindo que apenas o ambiente de execução isolado execute a tela de bloqueio autenticação. O Android Open Source Project upstream fornece a 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)

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.

• [C-1-5] PRECISA permitir que o usuário escolha o tempo limite de suspensão para fazer a transição. o desbloqueado para o estado bloqueado, com um tempo limite mínimo permitido até 15 segundos. Dispositivos automotivos que bloqueiam a tela sempre que a unidade principal for desligado ou o usuário for ligado, PODE NÃO ter o tempo limite de suspensão configuração do Terraform.
• [C-1-6] PRECISA oferecer suporte a uma das opções a seguir:
  • IKeymasterDevice 3.0,
  • IKeymasterDevice 4.0,
  • IKeymasterDevice 4.1,
  • IKeyMintDevice versão 1 ou
  • IKeyMintDevice versão 2.
• [C-SR-1] É FORTEMENTE RECOMENDADO para oferecer suporte ao IKeyMintDevice versão 1.

9.11.1. Tela de bloqueio segura, autenticação e dispositivos virtuais

A implementação do AOSP segue um modelo de autenticação em camadas em que um autenticação primária baseada na fábrica de conhecimento pode ser apoiada por um biometria forte secundária ou por modalidades terciárias mais fracas.

Implementações de dispositivos:

• [C-SR-1] É FORTEMENTE RECOMENDADO definir apenas uma das opções a seguir como autenticação principal :

  • Um PIN numérico
  • Uma senha alfanumérica

  • Um padrão de deslizar em uma grade de exatamente 3 x 3 pontos

    Os métodos de autenticação acima são conhecidos como o método métodos de autenticação principais neste documento.

• [C-0-1] PRECISA limitar o número de tentativas de autenticação primária com falha.

• [C-SR-5] É FORTEMENTE RECOMENDADO a implementação de um limite superior de 20 com falha tentativas principais de autenticação e, se os usuários consentirem e usarem o recurso, faça uma "redefinição para configuração original" após exceder o limite de solicitações de autenticação.

Se as implementações do dispositivo definirem um PIN numérico como principal recomendado método de autenticação, faça o seguinte:

• [C-SR-6] É FORTEMENTE RECOMENDADO um PIN que tenha pelo menos seis dígitos ou que é equivalente a uma entropia de 20 bits.
• [C-SR-7] É RECOMENDADO NÃO QUE O PIN com menos de seis dígitos Permitir a entrada automática sem interação do usuário para evitar que o PIN seja revelado comprimento.

Se as implementações do dispositivo adicionarem ou modificarem a autenticação principal recomendada e usar um novo método de autenticação como uma forma segura de bloquear a tela, o novo método de autenticação:

• [C-2-1] PRECISA ser o método de autenticação do usuário, conforme descrito em Exigir autenticação do usuário para o uso de chaves.

Se as implementações do dispositivo adicionarem ou modificarem os métodos de autenticação para desbloquear na tela de bloqueio se for baseado em um secret conhecido e usar uma nova seja tratado como uma forma segura de bloquear a tela:

• [C-3-1] A entropia do menor comprimento permitido das entradas PRECISA ser maior que 10 bits.
• [C-3-2] A entropia máxima de todas as entradas possíveis PRECISA ser maior que 18 bits.
• [C-3-3] O novo método de autenticação NÃO PODE substituir nenhum dos métodos de autenticação principais recomendados (por exemplo, PIN, padrão, senha) implementadas e fornecidas no AOSP.
• [C-3-4] O novo método de autenticação PRECISA ser desativado quando o O aplicativo controlador de política de dispositivo (DPC) definiu a senha de compliance com a política de requisitos da DevicePolicyManager.setRequiredPasswordComplexity() (link em inglês) com uma constante de complexidade mais restritiva PASSWORD_COMPLEXITY_NONE (em inglês) ou por meio do método DevicePolicyManager.setPasswordQuality() com uma constante mais restritiva PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-3-5] Novos métodos de autenticação DEVEM recorrer à métodos de autenticação primários recomendados (por exemplo, PIN, padrão, senha) uma vez a cada 72 horas ou menos OU divulgar claramente ao usuário de que alguns dados não serão salvos em backup a fim de preservar a privacidade dos dados.

Se as implementações do dispositivo adicionarem ou modificarem a autenticação principal recomendada para desbloquear a tela de bloqueio e usar um novo método de autenticação que é baseado em biometria para ser tratado como uma forma segura de bloquear a tela, o novo :

• [C-4-1] PRECISA cumprir todos os requisitos descritos na seção 7.3.10 para Classe 1 (anteriormente Conveniência).
• [C-4-2] PRECISA ter um mecanismo de fallback para o uso de uma das métodos de autenticação primários, que são baseados em um secret conhecido.
• [C-4-3] PRECISA estar desativada e permitir apenas as instâncias principais recomendadas para desbloquear a tela quando o controlador de política de dispositivo (DPC) aplicativo definiu a política de recurso de proteção de teclado chamando o método DevicePolicyManager.setKeyguardDisabledFeatures(), com qualquer uma das sinalizações biométricas associadas (por exemplo, KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT. KEYGUARD_DISABLE_FACE ou KEYGUARD_DISABLE_IRIS).

Se os métodos de autenticação biométrica não atenderem aos requisitos para Classe 3 (anteriormente Forte), conforme descrito em seção 7.3.10:

• [C-5-1] Os métodos PRECISAM ser desativados se o controlador de política de dispositivo (DPC) aplicativo definiu a política de qualidade dos requisitos de senha por meio de que é o método DevicePolicyManager.setRequiredPasswordComplexity(). com um bucket de complexidade mais restritivo que PASSWORD_COMPLEXITY_LOW ou usar DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-5-2] O usuário PRECISA ser desafiado na principal recomendada. (por exemplo, PIN, padrão, senha), conforme descrito em [C-1-7] e [C-1-8] na seção 7.3.10.
• [C-5-3] Os métodos NÃO PODEM ser tratados como uma tela de bloqueio segura e PRECISAM ser tratados como uma tela de bloqueio segura. atendem aos requisitos que começam com C-8 na seção abaixo.

Se as implementações do dispositivo adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio e um novo método de autenticação é baseado em um token físico ou o local:

• [C-6-1] Ela PRECISA ter um mecanismo de fallback para o uso de uma das métodos de autenticação primários, que são baseados em um secret conhecido e atendem os requisitos para ser tratado como uma tela de bloqueio segura.
• [C-6-2] O novo método PRECISA ser desativado e permitir apenas um dos métodos de autenticação principais recomendados para desbloquear a tela quando o O aplicativo do controlador de política de dispositivo (DPC) definiu a política com:
  • A DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) método
  • A DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva PASSWORD_QUALITY_NONE.
  • O DevicePolicyManager.setRequiredPasswordComplexity() com um bucket de complexidade mais restritivo PASSWORD_COMPLEXITY_NONE.
• [C-6-3] O usuário PRECISA ser contestado em uma das principais opções recomendadas métodos de autenticação (por exemplo, PIN, padrão, senha) pelo menos uma vez a cada 4 horas ou menos. Quando um token físico atende requisitos para implementações do TrustAgent em C-X, restrições de tempo limite definidos em C-9-5 são aplicados no lugar.
• [C-6-4] O novo método NÃO PODE ser tratado como uma tela de bloqueio segura e PRECISA ser. seguir as restrições listadas em C-8 abaixo.

Se as implementações do dispositivo têm uma tela de bloqueio segura e incluem uma ou mais agente de confiança, que implementa a API TrustAgentService System, ele:

• [C-7-1] PRECISA ter uma indicação clara no menu de configurações e na fechadura tela quando o bloqueio do dispositivo é adiado ou pode ser desbloqueado por agentes de confiança. Por exemplo, o AOSP atende a esse requisito mostrando uma descrição em texto para a opção "Bloquear configuração automaticamente" e "Botão liga/desliga bloqueia instantaneamente" no menu de configurações e um ícone distinguível na tela de bloqueio.
• [C-7-2] PRECISA respeitar e implementar totalmente todas as APIs do agente de confiança na classe DevicePolicyManager, como KEYGUARD_DISABLE_TRUST_AGENTS constante.
• [C-7-3] NÃO É POSSÍVEL implementar totalmente o TrustAgentService.addEscrowToken() função em um dispositivo usado como dispositivo pessoal principal. (por exemplo, portátil), mas PODE implementar totalmente a função no dispositivo implementações que são normalmente compartilhadas (por exemplo, Android Television ou dispositivo automotivo).
• [C-7-4] PRECISA criptografar todos os tokens armazenados adicionados pelo TrustAgentService.addEscrowToken():
• [C-7-5] NÃO PODE armazenar a chave de criptografia ou o token de garantia na mesmo dispositivo em que a chave é usada. Por exemplo, é permitido uma chave armazenada em um smartphone para desbloquear uma conta de usuário em uma TV. Para dispositivos automotivos, o armazenamento do token de garantia não é permitido. em qualquer parte do veículo.
• [C-7-6] PRECISA informar o usuário sobre as implicações de segurança antes de ativar o token de garantia para descriptografar o armazenamento de dados.
• [C-7-7] PRECISA ter um mecanismo de fallback para o uso de uma das métodos de autenticação principais.
• [C-7-9] O usuário PRECISA ser desafiado por uma das principais opções recomendadas métodos de autenticação (por exemplo: PIN, padrão, senha), conforme descrito em [C-1-7] e [C-1-8] na seção 7.3.10, a menos que a segurança do usuário (por exemplo, distração do motorista) é preocupante.
• [C-7-10] NÃO PODE ser tratada como uma tela de bloqueio segura e PRECISA seguir as restrições listadas em C-8 abaixo.
• [C-7-11] NÃO É POSSÍVEL permitir TrustAgents em dispositivos pessoais principais (por exemplo, portátil) para desbloquear o dispositivo, e só pode usá-lo para manter um dispositivo já desbloqueado nesse estado por até um no máximo 4 horas. A implementação padrão O TrustManagerService no AOSP atende a esse requisito.
• [C-7-12] PRECISA usar uma criptografia segura (por exemplo, UKEY2) canal de comunicação para transmitir o token de garantia do armazenamento ao dispositivo de destino.

Se as implementações do dispositivo adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio que não seja uma tela de bloqueio segura, como descrito acima, e use um novo método de autenticação para desbloquear o bloqueio de teclado:

• [C-8-1] O novo método PRECISA ser desativado quando o Device Policy Controller aplicativo (DPC) definiu a política de qualidade de senha por meio do DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva PASSWORD_QUALITY_NONE ou pelo DevicePolicyManager.setRequiredPasswordComplexity() com uma constante de complexidade mais restritiva "PASSWORD_COMPLEXITY_NONE".
• [C-8-2] Eles NÃO PODEM redefinir os timers de expiração de senha definidos por DevicePolicyManager.setPasswordExpirationTimeout()
• [C-8-3] Eles NÃO PODEM expor uma API para uso por apps de terceiros com o objetivo de alterar o estado de bloqueio.

Se as implementações de dispositivos permitirem que os aplicativos criem instâncias telas virtuais e não oferecem suporte a eventos de entrada associados, como via VirtualDeviceManager, eles:

• [C-9-1] PRECISA bloquear essas telas virtuais secundárias quando o dispositivo a tela padrão fica bloqueada e desbloqueia os monitores virtuais secundários quando a tela padrão do dispositivo está desbloqueada.

Se as implementações de dispositivos permitirem que os aplicativos criem telas virtuais secundárias e sejam compatíveis com a entrada associada eventos, como por meio do VirtualDeviceManager, eles:

• [C-10-1] PRECISA oferecer suporte a estados de bloqueio separados por dispositivo virtual.
• [C-10-2] PRECISA desconectar todos os dispositivos virtuais após o tempo limite de inatividade
• [C-10-3] PRECISA ter um tempo limite de inatividade
• [C-10-4] PRECISA bloquear todas as telas quando o usuário iniciar uma bloqueio total, incluindo por meio da funcionalidade de bloqueio total do usuário necessária para dispositivos portáteis (consulte Seção 2.2.5[9.11/H-1-2])
• [C-10-5] PRECISA ter instâncias de dispositivos virtuais separadas por usuário.

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

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

• [C-10-11] PRECISA desativar a interface de autenticação em dispositivos virtuais, incluindo: entrada de fator de conhecimento e solicitação biométrica

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

• [C-10-13] NÃO É NECESSÁRIO usar um estado de bloqueio do dispositivo virtual como autenticação do usuário autorização com o sistema Android Keystore. Consulte KeyGenParameterSpec.Builder.setUserAuthentication*:

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

Quando as implementações de dispositivos permitem que o usuário transfira a instância principal fator de conhecimento de autenticação de um dispositivo de origem para um dispositivo de destino, como para a configuração inicial do dispositivo de destino, eles:

• [C-11-1] PRECISA criptografar o fator de conhecimento com garantias de proteção semelhantes às aqueles descritos nos Serviço Google Cloud Key Vault sobre segurança ao transferir fator de conhecimento do dispositivo de origem para o dispositivo de destino, de modo que fator de conhecimento não pode ser descriptografado ou usado remotamente para desbloquear remotamente para qualquer dispositivo.
• [C-11-2] PRECISA, no dispositivo de origem , pedir ao usuário para confirmar a fator de conhecimento do dispositivo de origem antes de transferir o fator de conhecimento ao dispositivo de destino.
• [C-11-3] PRECISA, em um dispositivo de destino sem autenticação principal definida. de conhecimento, peça para o usuário confirmar um fator de conhecimento transferido no dispositivo de destino antes de definir esse fator de conhecimento como o principal. de conhecimento de autenticação para o dispositivo de destino e antes de tomar todos os dados transferidos de um dispositivo de origem.

Se as implementações do dispositivo têm uma tela de bloqueio segura e incluem uma ou mais agentes de confiança, que chamam a API System TrustAgentService.grantTrust() com a sinalização FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE, eles:

• [C-12-1] PRECISA chamar grantTrust() com a flag apenas quando conectado a um dispositivo físico próximo com uma tela de bloqueio própria e quando o usuário autenticamos sua identidade nessa tela de bloqueio. Dispositivos proxy podem use mecanismos de detecção no pulso ou no bolso após um desbloqueio único do usuário para atendem ao requisito de autenticação do usuário.
• [C-12-2] PRECISA colocar a implementação do dispositivo no TrustState.TRUSTABLE. quando a tela está desligada (por exemplo, pressionando um botão ou tempo limite) e o TrustAgent não revogou a confiança. O AOSP atende esse requisito.
• [C-12-3] PRECISA mover o dispositivo apenas de TrustState.TRUSTABLE para TrustState.TRUSTED se o TrustAgent ainda estiver concedendo confiança com base os requisitos do ensino C-12-1.
• [C-12-4] PRECISA chamar TrustManagerService.revokeTrust()
  • depois de no máximo 24 horas da concessão da confiança ou
  • Depois de um período de inatividade de 8 horas ou
  • Se as implementações não estiverem usando alcance preciso conforme definido em [C-12-5], quando a conexão para o dispositivo físico próximo é perdida.
• [C-12-5] Implementações que contam com alcance seguro e preciso para atender ao requisitos de [C-12-4] PRECISAM usar uma das soluções a seguir:
  • Implementações que usam UWB:
    • DEVE atender aos requisitos de conformidade, certificação, requisitos de calibragem para UWB descrita em 7.4.9.
    • PRECISA usar um dos modos de segurança do P-STS listados no 7.4.9.
  • Implementações usando a rede Wi-Fi Neighborhood Awareness (NAN):
    • PRECISA atender aos requisitos de precisão 2.2.1 [7.4.2.5/H-SR-1], use a largura de banda de 160 MHz (ou superior) e siga as etapas de configuração da medição especificadas em Calibragem de presença.
    • PRECISA usar o LTF seguro, conforme definido no IEEE 802.11az.

Se as implementações de dispositivos permitirem que os aplicativos criem telas virtuais secundárias e sejam compatíveis com a entrada associada eventos, como via VirtualDeviceManager e as telas não estiverem marcadas com VIRTUAL_DISPLAY_FLAG_SECURE, elas:

• [C-13-8] PRECISA bloquear atividades com o atributo android:canDisplayOnRemoteDevices ou os metadados android.activity.can_display_on_remote_devices definidos como falsos para que não sejam iniciadas no ambiente virtual. dispositivo.

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

Se as implementações de dispositivos oferecerem suporte a estados de energia de tela separados usando DeviceStateManager E oferecem suporte a estados de bloqueio de tela separados por meio de KeyguardDisplayManager, eles:

• [C-SR-2] É FORTEMENTE RECOMENDADO para usar uma reunião de credencial requisitos definidos na seção 9.11.1 ou um documento de biometria que atenda pelo menos As especificações de classe 1 definidas na seção 7.3.10 permitem desbloqueando a partir da tela padrão do dispositivo.
• [C-SR-3] É FORTEMENTE RECOMENDADO para restringir o desbloqueio da tela separada por um tempo limite de exibição definido.
• [C-SR-4] É FORTEMENTE RECOMENDADO para permitir que o usuário bloqueie globalmente todas as telas pelo bloqueio total do dispositivo portátil principal.

9.11.2. StrongBox

O Sistema Android Keystore permite que os desenvolvedores de aplicativos armazenem as chaves criptográficas em um processador seguro dedicado como bem como o ambiente de execução isolado descrito acima. Que processador seguro dedicado é chamado de "StrongBox". Requisitos C-1-3 de C-1-11 abaixo definem os requisitos que um dispositivo deve atender para podem ser qualificados como StrongBox.

Implementações de dispositivos que têm um processador seguro dedicado:

• [C-SR-1] É RECOMENDADO A compatibilidade com o StrongBox. O StrongBox vai provavelmente se tornará uma exigência em uma versão futura.

Se as implementações de dispositivos oferecerem suporte ao StrongBox, elas:

• [C-1-1] PRECISA declarar FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] PRECISA fornecer hardware seguro dedicado que é usado para e proteger a autenticação do usuário. O serviço de armazenamento dedicado o hardware também pode ser usado para outros fins.

• [C-1-3] PRECISA ter uma CPU discreta que não compartilha cache, DRAM e coprocessadores. ou outros recursos principais com o processador do aplicativo (AP).

• [C-1-4] PRECISA garantir que qualquer periférico compartilhado com o AP não possa ser alterado o StrongBox processar ou obter qualquer informação do StrongBox. O AP PODE desativar ou bloquear o acesso ao StrongBox.

• [C-1-5] PRECISA ter um relógio interno com precisão razoável (+-10%). imune a manipulações pela AP.

• [C-1-6] PRECISA ter um gerador de número aleatório real que produza distribuído de maneira uniforme e imprevisível.

• [C-1-7] PRECISA ter resistência a adulterações, incluindo resistência contra penetração física e falhas.

• [C-1-8] PRECISA ter resistência ao canal lateral, incluindo resistência contra vazando informações por meio de potência, tempo, radiação eletromagnética e temperatura canais laterais de radiação.

• [C-1-9] PRECISA ter um armazenamento seguro que garanta a confidencialidade, integridade, autenticidade, consistência e atualização dos conteúdo. O armazenamento NÃO PODE ser lido ou alterado, exceto conforme permitido pelas APIs do StrongBox.

• Para validar a conformidade com [C-1-3] a [C-1-9], o dispositivo implementações:

• [C-1-11] PRECISA incluir o firmware que é avaliado por um laboratório de testes credenciado nacionalmente que incorpora de uma possível avaliação de vulnerabilidade Aplicação dos critérios comuns de potencial de ataque a cartões inteligentes (em inglês).
• [C-SR-2] É FORTEMENTE RECOMENDADO a inclusão do hardware que é é avaliado usando uma meta de segurança, um nível de garantia de avaliação (EAL) 5, aumentado por AVA_VAN.5. A certificação EAL 5 provavelmente se tornar um requisito em uma versão futura.
• [C-SR-3] É FORTEMENTE RECOMENDADO para fornecer resistência a ataques de pessoas com informações privilegiadas (IAR), o que significa que uma pessoa com acesso privilegiado à assinatura do firmware não podem produzir firmwares que causem vazamentos no StrongBox para burlar requisitos de segurança funcional ou de outra forma permitir o acesso a dados sensíveis do usuário. A maneira recomendada de implementar A IAR permite atualizações de firmware apenas quando a senha do usuário principal é fornecida pela HAL IAuthSecret.

9.11.3. Credencial de identidade

O Sistema de Credenciais de Identidade é definido e alcançado por meio da implementação de todas no android.security.identity.* . Essas APIs permitem que os desenvolvedores de aplicativos armazenem e recuperem a identidade do usuário documentos. Implementações de dispositivos:

• [C-SR-1] é MUITO RECOMENDADO para implementar a credencial de identidade do sistema.

Se as implementações de dispositivos implementarem o sistema de credenciais de identidade, elas:

• [C-1-1] PRECISA retornar um valor não nulo para a propriedade IdentityCredentialStore#getInstance() .

• [C-1-2] PRECISA implementar o Identity Credential System (por exemplo, o android.security.identity.* APIs) com código que se comunica com uma rede confiável aplicativo 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.

• [C-1-3] As operações criptográficas necessárias para implementar a identidade O sistema de credenciais (por exemplo, as APIs android.security.identity.*) PRECISA ser realizado inteiramente no aplicativo confiável e no material de chave privada PRECISA Nunca saia do ambiente de execução isolado, a menos que seja especificamente necessário por APIs de nível superior (por exemplo, createEphemeralKeyPair() ).

• [C-1-4] O aplicativo confiável PRECISA ser implementado as propriedades de segurança não são afetadas (por exemplo, os dados das credenciais não são liberados a menos que as condições de controle de acesso sejam atendidas, MACs não podem ser produzidos para dados arbitrários), mesmo que o Android esteja com comportamento inadequado ou comprometido.

O Android Open Source Project upstream fornece uma referência implementação de um aplicativo confiável (libeic) que pode ser usado para implementar o sistema de credenciais de identidade.

9,12 Exclusão de dados

Todas as implementações de dispositivos:

• [C-0-1] PRECISA fornecer aos usuários um mecanismo para realizar uma "redefinição para configuração original".
• [C-0-2] PRECISA excluir todos os dados do sistema de arquivos userdata ao realizar uma "Redefinir para configuração original".
• [C-0-3] PRECISA excluir os dados de modo que satisfaçam os requisitos padrões do setor, como o NIST SP800-88 ao realizar uma tarefa Redefinir".
• [C-0-4] PRECISA acionar a "Redefinição para configuração original" acima de produção quando o DevicePolicyManager.wipeData() A API é chamada pelo app Device Policy Controller do usuário principal.
• PODE fornecer uma opção rápida de limpeza de dados que conduz apenas uma limpeza lógica de dados.

9,13 Modo de inicialização segura

O Android oferece o modo de inicialização segura, que permite aos usuários inicializar em um modo somente apps do sistema pré-instalados podem ser executados, e todos os apps de terceiros estão desativados. Esse modo, conhecido como "modo de inicialização segura", oferece ao usuário para desinstalar apps de terceiros potencialmente nocivos.

As implementações de dispositivos são:

• [C-SR-1] É MUITO RECOMENDADO a implementação do modo de inicialização segura.

Se as implementações de dispositivos implementarem o modo de inicialização segura, elas:

• [C-1-1] PRECISA fornecer ao usuário a opção de entrar no modo de inicialização segura de modo que não possa ser interrompido por terceiros aplicativos instalados no dispositivo, exceto quando o aplicativo de terceiros é um o Device Policy Controller e definiu o UserManager.DISALLOW_SAFE_BOOT como "true".

• [C-1-2] PRECISA fornecer ao usuário a capacidade de desinstalar todos os apps de terceiros no modo de segurança.

• DEVE fornecer ao usuário a opção de entrar no modo de inicialização segura pelo usando um fluxo de trabalho diferente daquele de uma inicialização normal.

9,14 Isolamento de sistemas veiculares automotivos

Espera-se que os dispositivos Android Automotive troquem dados com veículos importantes subsistemas usando a HAL de veículo para enviar e receber mensagens por redes de veículos, como o barramento CAN.

A troca de dados pode ser garantida com a implementação de recursos de segurança abaixo do Camadas do framework do Android para evitar interações maliciosas ou não intencionais com esses subsistemas.

9,15 Planos de assinatura

"Planos de assinatura" consulte os detalhes do plano de relação de faturamento fornecidos por uma operadora de celular por meio do SubscriptionManager.setSubscriptionPlans()

Todas as implementações de dispositivos:

• [C-0-1] PRECISA devolver os planos de assinatura apenas para o app da operadora de celular que forneceu originalmente.
• [C-0-2] NÃO PODE fazer backup nem upload remotamente de planos de assinatura.
• [C-0-3] PRECISA permitir somente substituições, como SubscriptionManager.setSubscriptionOverrideCongested(), no aplicativo da operadora de celular que está oferecendo planos de assinatura válidos.

9,16 Migração de dados do aplicativo

Se as implementações de dispositivos incluírem um recurso para migrar dados de um dispositivo para o outro dispositivo e não limitam os dados do aplicativo que copiam para o que é configurado pelo desenvolvedor do aplicativo no manifesto por meio do android:fullBackupContent (link em inglês) , eles:

• [C-1-1] NÃO PODE iniciar transferências de dados de aplicativos de dispositivos em que o usuário não definiu uma autenticação principal como descritos em 9.11.1 Tela de Bloqueio e Autenticação Seguras.
• [C-1-2] PRECISA confirmar com segurança a autenticação principal na origem. dispositivo e confirmar com a intenção do usuário de copiar os dados na fonte no dispositivo antes da transferência.
• [C-1-3] PRECISA usar o atestado de chaves de segurança para garantir que o código-fonte dispositivo e o dispositivo de destino na migração entre dispositivos são dispositivos Android legítimos e tenham um carregador de inicialização bloqueado.
• [C-1-4] PRECISA migrar somente os dados para o mesmo aplicativo no dispositivo de destino, com o mesmo nome de pacote E certificado de assinatura.
• [C-1-5] PRECISA mostrar uma indicação de que o dispositivo de origem tem dados. migrados por uma migração de dados de dispositivo para dispositivo no menu de configurações. Um usuário NÃO É POSSÍVEL remover essa indicação.

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

9,17 Framework de virtualização do Android

10. Teste de compatibilidade de software

As implementações de dispositivos PRECISAM ser aprovadas em todos os testes descritos nesta seção. No entanto, observe que nenhum pacote de teste de software é totalmente abrangente. Por isso, é altamente RECOMENDADO implementar os implementadores de dispositivos para que a o número mínimo de alterações possível na referência e nos arquivos preferidos implementação do Android disponível no Android Open Source Project. Isso vai minimizar o risco de introduzir bugs que criem incompatibilidades. que exigem retrabalho e possíveis atualizações do dispositivo.

10.1 Conjunto de teste de compatibilidade

Implementações de dispositivos:

• [C-0-1] PRECISA ser aprovado no conjunto de teste de compatibilidade (CTS) do Android. disponíveis no Android Open Source Project, usando o pacote final de software no dispositivo.

• [C-0-2] PRECISA garantir a compatibilidade em casos de ambiguidade no CTS reimplementações de partes do código-fonte de referência.

O CTS foi projetado para ser executado em um dispositivo real. Como qualquer software, o CTS pode conter bugs. A versão do CTS será controlada independentemente disso a Definição de compatibilidade. Várias revisões do CTS podem ser lançadas para Android 15

Implementações de dispositivos:

• [C-0-3] PRECISA passar pela versão mais recente do CTS disponível no momento em que o dispositivo quando o software é concluído.

• DEVE usar a implementação de referência na árvore de código aberto do Android o máximo possível.

10,2 Verificador do CTS

o Verificador do CTS está incluído no conjunto de teste de compatibilidade. deve ser executado por um operador humano para testar uma funcionalidade que não pode ser testado por um sistema automatizado, como o funcionamento correto de uma câmera e ou sensores.

Implementações de dispositivos:

• [C-0-1] PRECISA executar corretamente todos os casos aplicáveis no verificador do CTS.

O CTS Verifier tem testes para muitos tipos de hardware, incluindo alguns isso é opcional.

Implementações de dispositivos:

• [C-0-2] PRECISA passar em todos os testes de hardware que possui; por exemplo, Se um dispositivo tiver um acelerômetro, ele DEVE executar corretamente o Caso de teste do acelerômetro no verificador do CTS.

Casos de teste para recursos indicados como opcionais por esta Definição de compatibilidade O documento PODE ser ignorado ou omitido.

• [C-0-2] Todos os dispositivos e builds PRECISAM executar corretamente o CTS Verifier. como mencionado acima. No entanto, como muitos builds são muito semelhantes, o não se espera que os implementadores executem explicitamente o verificador do CTS nos builds que diferem apenas de maneiras triviais. Especificamente, implementações de dispositivos que diferente de uma implementação que foi aprovada no Verificador do CTS apenas pelo conjunto de localidades incluídas, branding etc. PODE omitir o teste do CTS Verifier.

11. Software atualizável

• [C-0-1] As implementações de dispositivos PRECISAM incluir um mecanismo para substituir os de todo o software do sistema. O mecanismo não precisa executar ou seja, pode ser necessário reiniciar o dispositivo. Qualquer método pode ser usado, desde que possa substituir todo o pré-instalado no dispositivo. Por exemplo, qualquer um dos seguintes vão atender a esse requisito:

  • "Over the Air (OTA)" com atualização off-line por reinicialização.
  • "Vinculado" por USB a partir de um PC host.
  • "Off-line" atualizações por reinicialização e atualizar a partir de um arquivo no armazenamento removível.

• [C-0-2] O mecanismo de atualização usado PRECISA ser compatível com as atualizações sem excluir permanentemente os dados do usuário dados. Ou seja, o mecanismo de atualização PRECISA preservar os dados privados do aplicativo e dados compartilhados por aplicativos. O software Android upstream inclui um que atenda a esse requisito.

• [C-0-3] Toda a atualização PRECISA ser assinada e o mecanismo de atualização no dispositivo PRECISA estar assinado. PRECISA verificar a atualização e a assinatura usando uma chave pública armazenada no dispositivo.

• [C-SR-1] O mecanismo de assinatura é FORTEMENTE RECOMENDADO para gerar hash da atualização com SHA-256 e validar o hash em relação à chave pública usando o ECDSA NIST P-256

Se as implementações do dispositivo incluírem suporte para uma quantidade ilimitada de dados como 802.11 ou Bluetooth PAN (rede de área pessoal), então, eles:

• [C-1-1] PRECISA oferecer suporte a downloads OTA com atualização off-line por reinicialização.

As implementações de dispositivos DEVEM verificar se a imagem do sistema é idêntica ao binário para o resultado esperado após uma OTA. A OTA baseada em blocos no Android Open Source Project, adicionado desde o Android 5.1, atende a esse requisito.

Além disso, as implementações de dispositivos DEVEM oferecer suporte às atualizações do sistema A/B. O AOSP implementa esse recurso usando a HAL de controle de inicialização.

Se um erro for encontrado em uma implementação de dispositivo após o lançamento, mas durante a vida útil razoável do produto, que é determinada em consulta com a Equipe de Compatibilidade do Android para afetar a compatibilidade de aplicativos aplicativos, faça o seguinte:

• [C-2-1] O implementador do dispositivo PRECISA corrigir o erro usando um software. disponível e que pode ser aplicada de acordo com o mecanismo que acabamos de descrever.

O Android inclui recursos que permitem que o aplicativo Proprietário do dispositivo (se houver) controlar a instalação de atualizações do sistema. Se o subsistema de atualização do sistema para dispositivos relatam android.software.device_admin, então eles:

• [C-3-1] PRECISA implementar o comportamento descrito em SystemUpdatePolicy. .

12. Registro de alterações do documento

Para ver um resumo das mudanças na definição de compatibilidade nesta versão:

• Registro de alterações do documento

13. Entre em contato

Você pode participar do fórum de compatibilidade do android e pedir esclarecimentos ou mencionar problemas que você acha que o documento não capa.