Definição de compatibilidade do Android 13

1. Introdução

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

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 13. Uma "implementação de dispositivo" ou "implementação" é solução de hardware/software tão desenvolvida.

Para ser considerado compatível com o Android 13, 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 de 3,3 polegadas (ou 2,5 polegadas para implementações de dispositivos enviadas no nível 29 da API ou antes) para oito polegadas.

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 que atenda a todos os requisitos descritos neste documento.

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

Se as implementações de dispositivos portáteis permitirem a rotação da tela de software, elas:

• [7.1.1.1/H-1-1]* PRECISA criar a tela lógica disponibilizada para aplicativos de terceiros esteja a pelo menos 5 centímetros canto(s) curto(s) e 2,7 polegadas nas bordas longas. Os dispositivos fornecidos com a API do Android de nível 29 ou anterior podem ser isentos dessa exigência.

Se as implementações de dispositivos portáteis não oferecerem suporte à rotação da tela do software, eles:

• [7.1.1.1/H-2-1]* PRECISA criar a tela lógica disponibilizada para aplicativos de terceiros tenha pelo menos 7,8 centímetros as arestas curtas. Os dispositivos fornecidos com a API do Android de nível 29 ou anterior podem ser isentos dessa exigência.

Se as implementações de dispositivos portáteis forem compatíveis com High Dynamic Range exibe 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.
• [7.4.3/H] DEVE incluir suporte para Bluetooth e Bluetooth LE

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 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 95 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 "true" 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.

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

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

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 o papel isSink() se o campo do tipo do 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 o papel isSink() se o campo do tipo do 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.

Se as implementações de dispositivos portáteis declararem android.hardware.audio.output e android.hardware.microphone, eles:

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

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

Se as implementações de dispositivos portáteis incluírem pelo menos um atuador tátil, elas:

• [7,10/H]* NÃO DEVE usar uma massa giratória excêntrica (ERM, na sigla em inglês) atuador tátil (vibrador).
• [7,10/H]* DEVE posicionar o posicionamento do atuador perto do local em que o dispositivo normalmente é segurado ou tocado pelas mãos.
• [7.10/H]* DEVE implementar todas as constantes públicas para retorno tátil limpo 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).
• [7.10/H]* DEVE implementar todas as constantes públicas para retorno tátil limpo em android.os.VibrationEffect ou seja (Efeito_TICK, EF_CLICK, EF_HEAVY_CLICK e Effect_DOUBLE_CLICK) e todos os públicos viáveis PRIMITIVE_* constantes para retorno tátil avançado em android.os.VibrationEffect.Composition ou seja (CLICK, TICK, LOW_TICK, QUICK_FALL, ACELERAÇÃO RÁPIDA, ENCERRADA_Lenta, GIRADA, QUI). Alguns desses primitivos, LOW_TICK e SPIN só serão viáveis se a vibração for compatível frequências relativamente baixas.

• [7.10/H]* DEVE seguir as orientações para mapeamento de constantes públicas em android.view.HapticFeedbackConstants às constantes android.os.VibrationEffect recomendadas, com as relações de amplitude correspondentes.

• [7,10/H]* DEVE seguir avaliação de qualidade para createOneShot() e createWaveform() APIs de terceiros.

• [7.10/H]* DEVE verificar se o resultado do comando público android.os.Vibrator.hasAmplitudeControl() A API reflete corretamente os recursos da vibração.

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 ressonante linear atuador, eles:

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

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

• [7,10/H]* DEVE ter a frequência ressonante do eixo X O LRA precisa estar abaixo de 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.

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

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

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 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 API, bem como todos os campos especificados fornecidos pelo 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.

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 portátil implementar uma funcionalidade dividida, usando a incorporação de atividades, eles:

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

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 em o menu "Configurações" com a capacidade de interromper um app em execução em primeiro plano e exibir todos os apps que têm serviços em primeiro plano ativos e a duração de cada um desses serviços, desde o início, conforme descrito no do documento.
  • Alguns apps PODEM estar isentos de serem interrompidos ou listados em uma dessas funcionalidade do usuário, conforme descrito no documento do SDK.

2.2.5 Modelo de segurança

Implementações de dispositivos portáteis:

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

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, SHA1 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.
• [9.11/H-0-5] PRECISA oferecer suporte ao atestado de chaves em que o a chave de assinatura de atestado é protegida por um hardware seguro e a assinatura é executadas em hardware seguro. As chaves de assinatura de atestado PRECISAM ser compartilhadas em um número grande de dispositivos para impedir o uso das chaves como identificadores de dispositivo. Uma forma de atender a esse requisito é compartilhar o mesma chave de atestado,a menos que pelo menos 100.000 unidades de uma determinada SKU sejam produzidos. Se mais de 100.000 unidades de uma SKU forem produzidas, outro chave PODE ser usada para cada 100.000 unidades.
• [9/H-0-1] PRECISA declarar o "android.hardware.security.model.compatível". .

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

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

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 para o sistema ou o ContentCaptureService
• [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 que não sejam de áudio sejam transmitida pelo serviço de detecção de hotword para cada hotword bem-sucedida resultado.
• [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 o resultado bem-sucedido da hotword é transmitido serviço de interação ou entidade semelhante.
• [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:

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.

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.

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

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

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

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.S para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, eles:

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

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

• [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().
• [5.1/H-1-2] PRECISA oferecer suporte a seis instâncias de sessões de decodificador de vídeo por hardware. (AVC, HEVC, VP9, AV1 ou posterior) em qualquer combinação de codecs em execução ao mesmo tempo, com resolução de 1080p a 30 fps.
• [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().
• [5.1/H-1-4] PRECISA oferecer suporte a seis instâncias de codificador de vídeo em hardware. sessões (AVC, HEVC, VP9, AV1 ou posteriores) em qualquer combinação de codec em execução ao mesmo tempo, com resolução de 1080p a 30 fps.
• [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 de CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-6] PRECISA oferecer suporte a seis instâncias de hardware de decodificador de vídeo e hardware. sessões do codificador de vídeo (AVC, HEVC, VP9, AV1 ou posterior) em qualquer codec em execução simultaneamente a uma resolução de 1080p a 30 fps.
• [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 é 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 de gravação de áudio e vídeo em 1080p. Para o codec Dolby Vision, a latência de inicialização do codec 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 e inicialização de gravação de áudio e vídeo.
• [5.1/H-1-9] PRECISA oferecer suporte a duas instâncias de decodificador de vídeo por hardware seguro sessões (AVC, HEVC, VP9, AV1 ou posteriores) em qualquer combinação de codec em execução ao mesmo tempo, com resolução de 1080p a 30 fps.
• [5.1/H-1-10] PRECISA oferecer suporte a três instâncias de decodificador de vídeo por hardware não seguro sessões com 1 instância de sessão de decodificador de vídeo por hardware seguro (4 instâncias no total) (AVC, HEVC, VP9, AV1 ou posterior) em qualquer combinação de codecs em execução simultânea com resolução de 1080p a 30 fps.
• [5.1/ H-1-11] PRECISA oferecer suporte a um decodificador seguro para cada hardware AVC, HEVC, Decodificador VP9 ou 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.
• [5.1/H-1-14] PRECISA ser compatível com o decodificador de hardware AV1 Main 10, Level 4.1.
• [5.1/H-SR-1] É FORTEMENTE RECOMENDADO para oferecer suporte a grão de filme para hardware AV1 decodificador.
• [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.
• [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 frame) para uma sessão de vídeo com 1080p a 60 fps sob carga. O carregamento é definido como um vídeo simultâneo de 1080p a 720p de transcodificação usando codecs de vídeo de hardware, além de Reprodução de áudio AAC a 128 kbps.
• [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. O carregamento é definido como um Sessão simultânea de transcodificação apenas de vídeo de 1080p a 720p usando hardware e uma reprodução de áudio AAC de 128 kbps.
• [5.6/H-1-1] PRECISA ter uma latência de toque para tom de 80 milissegundos ou menos. usando o teste toque a tom do OboeTester ou 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 menos. em pelo menos um caminho de dados com suporte.
• [5.6/H-1-3] PRECISA oferecer suporte a áudio de pelo menos 24 bits para saída estéreo de áudio com mais de 3,5 mm. entradas, se presente, e via áudio USB, se compatível com o caminho de dados inteiro para configurações de baixa latência e de streaming. Para baixo configuração de latência, a AAudio deve ser usada pelo app em baixa latência o modo de callback. Para o streaming do Java, uma faixa de áudio Java deve ser usada pelo aplicativo. Tanto no nível latência e configurações de streaming, o coletor de saída da HAL aceitará AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED AUDIO_FORMAT_PCM_32_BIT ou AUDIO_FORMAT_PCM_FLOAT para a saída de destino .
• [5.6/H-1-4] PRECISA oferecer suporte a dispositivos de áudio USB com mais de 4 canais usados por DJs. controles para visualizar as músicas.
• [5.6/H-1-5] PRECISA oferecer suporte a dispositivos MIDI compatíveis com a classe e declarar o MIDI flag de recurso.
• [5.7/H-1-2] PRECISA oferecer suporte a MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL com os recursos de descriptografia de conteúdo abaixo.

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

2.2.7.2 Câmera

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

• PRECISA atender aos requisitos de câmera listados no CDD do Android 12. seção 2.2.7.2.

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

• [7.5/H-1-1] PRECISA ter uma câmera traseira principal com resolução de pelo menos 12 megapixels com suporte para captura de vídeo a 4k a 30 fps. O principal que é a traseira com o menor ID de câmera.
• [7.5/H-1-2] PRECISA ter uma câmera frontal principal com resolução de pelo menos 5 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 primária secundária e LIMITED ou melhor para a primária 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 latência de captura JPEG da Camera2 < 1.000 ms para Resolução de 1080p medida 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-6] PRECISA ter 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 oferecer suporte a CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION. para a câmera traseira principal.
• [7.5/H-1-13] PRECISA oferecer suporte ao recurso LOGICAL_MULTI_CAMERA para a instância principal. câmera traseira se houver mais de uma câmera traseira RGB
• [7.5/H-1-14] PRECISA oferecer suporte ao recurso STREAM_USE_CASE para as contas primárias câmera frontal e traseira principal.

2.2.7.3 Hardware

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.S para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, ele poderá fazer o seguinte:

• PRECISA atender aos requisitos de hardware listados no CDD do Android 12. seção 2.2.7.3.

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.T para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, ele poderá fazer o seguinte:

• [7.1.1.1/H-2-1] PRECISA ter uma resolução de tela de pelo menos 1080p.
• [7.1.1.3/H-2-1] PRECISA ter uma densidade de tela de pelo menos 400 dpi.
• [7.6.1/H-2-1] PRECISA ter pelo menos 8 GB de memória física.

2.2.7.4 Desempenho

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.S para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, ele poderá fazer o seguinte:

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

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.T para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, ele poderá fazer o seguinte:

• [8.2/H-1-1] PRECISA garantir um desempenho de gravação sequencial de pelo menos 125 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 40 MB/s.

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 do BigQuery).

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

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

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 selecione a resolução máxima compatível com 50 Hz ou 60 Hz e a taxa de atualização.
• [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.

Implementações de dispositivos de televisão:

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

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.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, SHA1 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.
• [9.11/T-0-4] PRECISA oferecer suporte ao atestado de chaves em que o a chave de assinatura de atestado é protegida por um hardware seguro e a assinatura é executadas em hardware seguro. As chaves de assinatura de atestado PRECISAM ser compartilhadas em um número grande de dispositivos para impedir o uso das chaves como identificadores de dispositivo. Uma forma de atender a esse requisito é compartilhar o mesma chave de atestado,a menos que pelo menos 100.000 unidades de uma determinada SKU sejam produzidos. Se mais de 100.000 unidades de uma SKU forem produzidas, outro chave PODE ser usada para cada 100.000 unidades.
• [9/T-0-1] PRECISA declarar "android.hardware.security.model.compatível". .

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

Implementações de dispositivos de televisão:

• Perfetto (link em inglês)
  • [6.1/T-0-1] PRECISA expor um /system/bin/perfetto. binário para o usuário do shell com o qual o cmdline obedece a documentação do perfetto.
  • [6.1/T-0-2] O binário do perfetto PRECISA ser aceito como insira uma configuração protobuf que esteja em conformidade com o esquema definido em a documentação do perfetto.
  • [6.1/T-0-3] O binário do perfetto PRECISA ser escrito como gera um trace protobuf que cumpre o esquema definido em a documentação do perfetto.
  • [6.1/T-0-4] PRECISA fornecer, pelo perfetto. binário, pelo menos as fontes de dados descritas na documentação do Perfeito.

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

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.

• [7.2.3/A-0-1] PRECISA fornecer a função Home e PODE fornecem as funções Voltar e Recentes.

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

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

• [7.4.3/A-SR-1] É FORTEMENTE RECOMENDADO para o suporte Perfil de acesso a mensagens (MAP).

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

Uma câmera de visualização externa é uma câmera que captura cenas fora do dispositivo como a câmera traseira.

Implementações de dispositivos automotivos:

• DEVE incluir uma ou mais câmeras de visualização externa.

Se as implementações de dispositivos automotivos incluírem uma câmera de visualização externa, uma câmera, eles:

• [7.5/A-1-1] NÃO PODE ter câmeras de visualização externa acessíveis pelas APIs Android Camera, a menos que estejam em conformidade com os requisitos principais da câmera.

• [7.5/A-SR-1] É FORTEMENTE RECOMENDADO não girar ou espelhar a visualização da câmera horizontalmente.

• [7.5/A-SR-2] É MUITO RECOMENDADO para ter uma resolução de pelo menos 1,3 megapixels.

• DEVE ter hardware de foco fixo ou EDOF (profundidade de campo estendida).

• PODE ter o autofoco em hardware ou em software implementado o driver da câmera.

Se as implementações de dispositivos automotivos incluírem uma ou mais câmeras de visão externa, e carregam o serviço Exterior View System (EVS). Depois, para essa câmera, eles:

• [7.5/A-2-1] NÃO PODE girar nem espelhar horizontalmente a visualização da câmera.

Implementações de dispositivos automotivos:

• PODE incluir uma ou mais câmeras disponíveis para terceiros aplicativos conteinerizados.

Se as implementações de dispositivos automotivos incluem pelo menos uma câmera e a tornam para aplicativos de terceiros:

• [7.5/A-3-1] PRECISA informar o flag de recurso. android.hardware.camera.any
• [7.5/A-3-2] não PRECISA declarar a câmera como um câmera do sistema.
• PODE ser compatível com câmeras externas descritas na seção 7.5.3.
• PODE incluir recursos (como autofoco etc.) disponíveis para a direção traseira câmeras, conforme descrito na seção 7.5.1.

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 (também conhecida como 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.

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

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

  • 280 dpi ou menos em telas pequenas/normais
  • Ldpi ou menor em telas muito grandes
  • Mdpi ou menor em telas grandes

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

  • xhdpi ou maior em telas pequenas/normais
  • hdpi ou maior em telas grandes
  • mdpi ou maior em telas muito grandes

• [7.6.1/A-2-3] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 1.280 MB 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

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

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

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

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

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

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.

• [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.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 com os papéis destacados Seção 9.1 Permissões com o identificador CDD [C-3-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.

Implementações de dispositivos automotivos:

• [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, SHA1 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.
• [9.11/A-0-4] PRECISA oferecer suporte ao atestado de chaves em que o a chave de assinatura de atestado é protegida por um hardware seguro e a assinatura é executadas em hardware seguro. As chaves de assinatura de atestado PRECISAM ser compartilhadas em um número grande de dispositivos para impedir o uso das chaves como identificadores de dispositivo. Uma forma de atender a esse requisito é compartilhar o mesma chave de atestado,a menos que pelo menos 100.000 unidades de uma determinada SKU sejam produzidos. Se mais de 100.000 unidades de uma SKU forem produzidas, outro chave PODE ser usada para cada 100.000 unidades.
• [9/A-0-1] PRECISA declarar o "android.hardware.security.model.compatível". .

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

Implementações de dispositivos automotivos:

• Perfetto (link em inglês)
  • [6.1/A-0-1] PRECISA expor um /system/bin/perfetto. binário para o usuário do shell com o qual o cmdline obedece a documentação do perfetto.
  • [6.1/A-0-2] O binário do perfetto PRECISA ser aceito como insira uma configuração protobuf que esteja em conformidade com o esquema definido em a documentação do perfetto.
  • [6.1/A-0-3] O binário do perfetto PRECISA ser escrito como gera um trace protobuf que cumpre o esquema definido em a documentação do perfetto.
  • [6.1/A-0-4] PRECISA fornecer, pelo perfetto. binário, pelo menos as fontes de dados descritas na documentação do Perfeito.

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.

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

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

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

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 comportamentos de qualquer API documentada exposta pelo SDK do Android ou qualquer API decorada com o marcador "@SystemApi" no sistema operacional 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 cada interface externa 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.

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. O 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 API significativa somente no tempo de execução, 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 13.
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 13, este campo PRECISA ter o valor inteiro: 13_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 13, este campo PRECISA ter o valor inteiro: 13_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_SUPORTE	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.
SUPORTE_32_ABIS_BIT	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.
SUPORTE_64_ABIS_BIT	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.
CPU_ABI	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:13/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 DE SOC	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 um 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 começar 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 à expressão regular “^[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 ("").
PATCH DE SEGURANÇA	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 Boletim de segurança pública do Android ou no elemento Consultoria de segurança do Android, por exemplo, "2015-11-01".
BASE_SO	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 permitem 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. O 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, a desativação do usuário "Seletor" 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 um um atributo mais específico do URI de dados. Por exemplo, um padrão de filtro de intent especificar o URI de dados “http://www.android.com” é mais específico 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 os filtros 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 os as substituições apropriadas por padrão de URI no menu de configurações.
• PRECISA oferecer ao usuário controles de links do app por app nas "Configurações" como segue:
  • [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 do dispositivo 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 aos usuários affordance para escolher um app que contenha 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 &amp; 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) &amp; 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 opçã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 &amp; 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.

• [C-17-1] [Movido para 2.2.3]

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

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

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.

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

  • armeabi (não tem mais suporte como destino pelo NDK)
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64

• [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 para a função principal do Vulkan 1.0 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, a seção 7.1.4.2 descreve em mais detalhes os requisitos de quando o 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 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 13 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 fornecido ao app pelo LocationManager Classe de 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 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çosstopSelf() 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. de implementação, 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 por meio da classe 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.

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 a classe 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 mecanismo para os aplicativos aplicarem estilos toda uma atividade ou aplicativo.

O Android inclui um "Holo" e um "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 oferecer suporte à família de temas "Material" e NÃO PODE alterar nenhum deles 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.

  "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 uma família de temas “Padrão do dispositivo” 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 aplicativo 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.
• [C-1-2] PRECISA implementar o comportamento de fixação da tela. e forneça ao usuário um menu de configurações para ativar ou desativar o recurso.
• 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 apoiar o tom de pele e os diversos emojis de família, 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 do 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 modo 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.

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

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

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

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

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. O 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.
• [C-1-2] PRECISA mostrar um aviso de divulgação adequado (conforme mencionado no AOSP) e receba o consentimento afirmativo do usuário final antes de abrir o app. definido como proprietário do dispositivo, a menos que o dispositivo seja configurado de forma programática para modo de demonstração na loja antes da interação do usuário final na tela.

Se as implementações de dispositivos declararem android.software.device_admin, mas também incluir uma solução reservada de gerenciamento de dispositivos e fornecer um mecanismo promover um aplicativo configurado na solução como "Proprietário do dispositivo" equivalente" para "Proprietário do dispositivo" padrão, reconhecida pela norma Android DevicePolicyManager (link em inglês) APIs, eles:

• [C-2-1] PRECISA ter um processo para verificar se um determinado app promovida pertence a um sistema legítimo de gerenciamento e tenha sido configurado na solução proprietária ter os direitos equivalentes como "Proprietário do dispositivo".
• [C-2-2] PRECISA mostrar a mesma declaração de consentimento do proprietário do dispositivo AOSP que a fluxo iniciado por android.app.action.PROVISION_MANAGED_DEVICE antes de registrar o aplicativo DPC como "Proprietário do dispositivo".
• [C-2-3] NÃO PODE codificar o consentimento nem impedir o uso de outros apps do proprietário do dispositivo.

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.

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

• [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 de perfil gerenciado

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.

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 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 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,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.

3,12. TV Input Framework

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

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

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

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 a 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.
• [C-1-3] PRECISA fornecer recursos do usuário para que ele selecione/confirme um companion dispositivo está presente e funcionando.

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 o dispositivo e não associados a uma conta no AccountManager, que são criado 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.

4. Compatibilidade do empacotamento de aplicativos

Implementações de dispositivos:

• [C-0-1] PRECISA ser capaz de instalar e executar arquivos ".apk" do Android como geradas pela ferramenta “aapt” incluída 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 arquivos ".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 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 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) intent e o app gerenciador de armazenamento processa ACTION_MANAGE_STORAGE 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 isso 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. O 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)	Suporte para 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

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 a BITRATE_MODE_CQ modo de controle da 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

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)

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)

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)	1.408 x 1.152 px (H263) 1280 x 720 px (outros)	1920 x 1080 px (exceto MPEG4)	3.840 x 2.160 px (HEVC, VP9)

• [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 a apps de terceiros, ela:

• Em duas janelas deslizantes, NÃO DEVE ser mais de 15% acima da taxa de bits entre os intervalos intraframe (I-frame).
• O valor NÃO DEVE estar acima de 100% da taxa de bits 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 ao perfil de referência de nível 45.
• DEVE oferecer suporte a taxas de bits configuráveis dinamicamente para o codificador compatível.

5.2.2. H.264

Se as implementações de dispositivos 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.
• DEVE oferecer suporte aos perfis de codificação em HD conforme indicado na tabela a seguir.
• [C-SR-1] é FORTEMENTE RECOMENDADO para oferecer suporte aos perfis de codificação em 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

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 aos perfis de referência de nível 30 e 45.

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 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 ao decodificador Dolby Vision usando HDR_TYPE_DOLBY_VISION , eles:

• [C-1-1] PRECISA fornecer um extrator compatível com Dolby Vision.
• [C-1-2] PRECISA mostrar corretamente o conteúdo do Dolby Vision na tela do dispositivo ou em uma porta de saída de vídeo padrão (por exemplo, HDMI.
• [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, elas:

• [C-1-1] PRECISA oferecer suporte ao Perfil 0, incluindo conteúdo de 10 bits.

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.4.6. Níveis de ganho do microfone [migrado para 5.4.2]

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.
• 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 de 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. A média do valor absoluto do desvios da média de um conjunto de valores.
• latência do toque para tom. O tempo entre o toque na tela e o momento em que um som gerado como resultado desse toque é ouvido no alto-falante.

Se as implementações de dispositivos declararem android.hardware.audio.output, elas PRECISA atender ou exceder os seguintes requisitos:

• [C-1-1] O carimbo de data/hora da saída retornado por AudioTrack.getTimestamp (link em inglês) e AAudioStream_getTimestamp tem precisão de +/- 2 ms.

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

Se as implementações de dispositivos declararem android.hardware.audio.output, elas serão É RECOMENDADO atender ou superar os seguintes requisitos:

• [C-SR-1] Latência de saída fria de 100 milissegundos ou menos nos dados dos alto-falantes caminho.

• [C-SR-2] Latência de toque para tom de 80 milissegundos ou menos.

• [C-SR-4] O carimbo de data/hora de saída retornado por AudioTrack.getTimestamp (link em inglês) e AAudioStream_getTimestamp tem precisão de +/- 1 ms.

Se as implementações de dispositivos atenderem aos requisitos acima, após qualquer calibração, ao usar a API de áudio nativo da AAudio, para saída contínua e a latência de saída fria em pelo menos um áudio com suporte dispositivo de saída, eles são:

• [C-SR-5] É FORTEMENTE RECOMENDADO que você informe áudio de baixa latência ao declarar Sinalização de recurso android.hardware.audio.low_latency.
• [C-SR-6] É MUITO RECOMENDADO para atender aos requisitos de baixa latência áudio pela API AAudio.
• [C-SR-7] É MUITO RECOMENDADO para garantir que os streams que retornam AAUDIO_PERFORMANCE_MODE_LOW_LATENCY de AAudioStream_getPerformanceMode(), o valor retornado por AAudioStream_getFramesPerBurst() é menor ou igual ao valor retornado por android.media.AudioManager.getProperty(String) para a chave de propriedade AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

Se as implementações do dispositivo não atenderem aos requisitos de áudio de baixa latência via API de áudio nativa da AAudio, eles:

• [C-2-1] NÃO É POSSÍVEL informar suporte para áudio de baixa latência.

Se as implementações de dispositivos incluírem android.hardware.microphone, elas PRECISA atender a estes requisitos de áudio de entrada:

• [C-3-1] Limite o erro nos carimbos de data/hora de entrada, conforme retornado por AudioRecord.getTimestamp (link em inglês) ou AAudioStream_getTimestamp, para +/- 2 ms. "Erro" aqui significa o desvio do valor correto.

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

Se as implementações de dispositivos incluírem android.hardware.microphone, elas serão É RECOMENDADO atender a estes requisitos de entrada de áudio:

• [C-SR-8] Latência de entrada a frio de 100 milissegundos ou menos pelo microfone caminho dos dados.

• [C-SR-11] Limite o erro nos carimbos de data/hora de entrada, conforme retornado por AudioRecord.getTimestamp (link em inglês) ou AAudioStream_getTimestamp, para +/- 1 ms.

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

• [C-SR-12] É FORTEMENTE RECOMENDADO ter uma latência média contínua de ida e volta de 50 milissegundos ou menos em 5 medições, com um Desvio médio absoluto menos de 10 ms em pelo menos um caminho compatível.

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:
• [C-1-2] PRECISA ter a latência de ida e volta contínua do áudio, conforme definido em seção 5.6 Latência de áudio de 25 milissegundos ou menos em pelo menos um caminho compatível.
• [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.
• [C-1-5] PRECISA atender aos requisitos de latência e áudio USB usando o Áudio nativo AAudio API e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
• [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.
• [C-1-8] PRECISA ter uma latência média entre toques e tons de 80 milissegundos ou menos. em pelo menos cinco medições do alto-falante para o caminho de dados do microfone.
• [C-SR-1] É FORTEMENTE RECOMENDADO para atender às latências definidas na seção 5,6 Latência de áudio, de 20 milissegundos ou menor que 5 medições com desvio absoluto médio menor que 5 milésimos de segundo entre o alto-falante e o microfone.
• [C-SR-2] É FORTEMENTE RECOMENDADO a atender aos requisitos de áudio profissional para: latência de áudio de ida e volta contínua, latência de entrada a frio e saída de frio latência e requisitos de áudio USB usando a API de áudio nativo da AAudio no caminho do MMAP.

• [C-SR-3] É FORTEMENTE RECOMENDADO para fornecer um nível consistente de CPU desempenho enquanto o áudio está ativo e a carga da CPU varia. Isso deve ser testado usando o app Android SynthMark. O SynthMark usa um sintetizador de software executado em um framework de áudio simulado que mede o desempenho do sistema. Consulte a Documentação do SynthMark para conferir uma explicação sobre os comparativos de mercado. SynthMark precisa ser executado usando o a opção de "Teste automatizado" e obter os seguintes resultados:

  • Voicemark.90 >= 32 vozes
  • latênciamark.Fixed.little <= 15 ms
  • latênciamark.dynamic.little <= 50 ms

• DEVE minimizar a imprecisão e o desvio do relógio de áudio em relação ao horário padrão.

• DEVE minimizar a variação do relógio de áudio em relação à CPU CLOCK_MONOTONIC quando ambos estão ativos.

• DEVE minimizar a latência de áudio em transdutores no dispositivo.

• DEVE minimizar a latência de áudio no áudio digital USB.

• DEVE documentar as medições de latência de áudio em todos os caminhos.

• DEVE minimizar a instabilidade nos tempos de entrada de callback para conclusão do buffer de áudio, já que esse afeta a porcentagem utilizável da largura de banda total da CPU pelo callback.

• DEVE fornecer zero falhas de áudio em condições normais de uso na latência relatada.

• DEVE fornecer zero diferença de latência entre os canais.

• DEVE minimizar a latência média de MIDI em todos os transportes.

• DEVE minimizar a variabilidade de latência MIDI sob carga (instabilidade) em todos os transportes.

• DEVE fornecer carimbos de data/hora MIDI precisos em todos os transportes.

• DEVE minimizar o ruído do sinal de áudio em transdutores do dispositivo, incluindo os imediatamente após a inicialização a frio.

• DEVE fornecer zero diferença de relógio de áudio entre os lados de entrada e saída do endpoints correspondentes, quando ambos estão ativos. Exemplos de respostas os endpoints incluem o microfone e o alto-falante do dispositivo ou a entrada de entrada de áudio e saída.

• DEVE lidar com callbacks de conclusão do buffer de áudio para os lados de entrada e saída de endpoints correspondentes no mesmo encadeamento quando ambos estiverem ativos, e inserir o callback de saída imediatamente após o retorno do callback de entrada. Ou se não for viável lidar com os retornos de chamada no mesmo thread, insira o de saída logo após inserir o retorno de chamada para permitir que o tenha um tempo consistente entre os lados de entrada e saída.

• DEVE minimizar a diferença de fase entre o buffer de áudio HAL para a entrada e lados de saída dos endpoints correspondentes.

• DEVE minimizar a latência de toque.

• DEVE minimizar a variabilidade da latência de toque sob carga (instabilidade).

Se as implementações de dispositivos atenderem a todos os requisitos acima, elas:

• [C-SR-4] É MUITO RECOMENDADO para informar o suporte para o recurso android.hardware.audio.pro pelo android.content.pm.PackageManager .

Se as implementações do dispositivo incluírem uma entrada para fone de ouvido de 3,5 mm com quatro condutores, elas:

• [C-2-1] PRECISA ter uma latência média contínua de áudio de ida e volta, conforme definido em seção 5.6 Latência de áudio, de 20 milissegundos ou menos, mais de 5 medições com desvio absoluto médio inferior a 5 milissegundos o caminho da entrada de áudio usando um dongle de loopback de áudio.
• [C-SR-5] MUITO RECOMENDADO para obedecer à seção Especificações para dispositivos móveis (jack) da Especificação de fone de ouvido de áudio com fio (v1.1).

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.
• [C-3-2] PRECISA ter uma latência média contínua de áudio de ida e volta de 25 milissegundos ou menos, mais de 5 medições com desvio absoluto médio menos de 5 milissegundos pela porta do modo host USB usando a classe de áudio USB. (Isso pode ser medido com o uso de um adaptador USB-3,5 mm e um loopback de áudio ou uma interface de áudio USB com cabos patch para conectar entradas para saídas).
• [C-SR-6] É FORTEMENTE RECOMENDADO para oferecer suporte a E/S simultâneas com até oito canais em cada direção, taxa de amostragem de 96 kHz e profundidade de 24 ou 32 bits, quando usadas com periféricos de áudio USB que também atendem a esses requisitos.
• [C-SR-7] É FORTEMENTE RECOMENDADO para atender a esse grupo de requisitos usando a API de áudio nativa da AAudio no caminho do MMAP.

Se as implementações de dispositivos incluírem uma porta HDMI, elas:

• DEVE oferecer suporte à saída em estéreo e oito canais em 20 bits ou 24 bits de profundidade e 192 kHz sem perda ou reamostragem de profundidade de bits em pelo menos uma configuração.

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 nos 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 ao recurso FEATURE_HdrEditing para 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)

  • [C-0-2] PRECISA oferecer suporte ao adb, conforme documentado no SDK do Android e no shell fornecidos no AOSP, que podem ser usados por desenvolvedores de apps, incluindo dumpsys cmd stats
  • [C-0-11] PRECISA oferecer suporte ao comando shell cmd testharness. Fazendo upgrade implementações de dispositivos de uma versão anterior do Android sem uma um bloco de dados persistente pode ser isento de C-0-11.
  • [C-0-3] NÃO PODE alterar o formato ou o conteúdo do sistema do dispositivo eventos (bateriastats , discostats, impressão digital, Graphstats, netstats, notificação, procstats) registrados pelo comando dumpsys.
  • [C-0-10] PRECISA gravar, sem omissão, e fazer os seguintes eventos acessível e disponível para o comando shell do cmd stats e o StatsManager Classe da API do sistema.
    • ActivityForegroundStateChanged
    • Anomalia detectada
    • AppBreadcrumbReported
    • Ocorreram AppCrash
    • O AppStart ocorreu
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • CobrançaStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • JobStateChanged
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • UidProcessStateChanged
    • WakelockStateChanged
    • Alarme de ativação ocorreu
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged
  • [C-0-4] PRECISA fazer com que o daemon do adb do lado do dispositivo fique inativo por padrão e É NECESSÁRIO haver um mecanismo acessível ao usuário para ativar o Android Debug Ponte
  • [C-0-5] PRECISA oferecer suporte ao adb seguro. O Android inclui suporte a chamadas adb: O adb seguro permite o uso do adb em hosts autenticados conhecidos.
  • [C-0-6] PRECISA fornecer um mecanismo que permita a conexão do adb de uma máquina host. Especificamente:

  Se as implementações de dispositivos sem porta USB forem compatíveis com o modo periférico, elas:

  • [C-3-1] PRECISA implementar o adb via rede de área local (como ou Wi-Fi).
  • [C-3-2] PRECISA fornecer drivers para Windows 7, 8 e 10, permitindo que os desenvolvedores se conectem ao dispositivo usando o protocolo adb.

  Se as implementações de dispositivos oferecerem suporte a conexões adb com uma máquina host via Wi-Fi ou Ethernet, eles:

  • [C-4-1] PRECISA ter o método AdbManager#isAdbWifiSupported(). retornar true.

  Se as implementações de dispositivos oferecerem suporte a conexões adb com uma máquina host via Wi-Fi ou Ethernet inclui pelo menos uma câmera, eles:

  • [C-5-1] PRECISA ter o método AdbManager#isAdbWifiQrSupported(). retornar true.

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

  • [C-0-7] PRECISA oferecer suporte a todos os recursos de ddms, conforme documentado no SDK do Android. Como o ddms usa adb, o suporte para ddms DEVE estar inativo por padrão, mas DEVE ser suportado sempre que o usuário ativar o Android Debug Bridge. acima.

• SysTrace (em inglês)

  • [C-0-9] PRECISA oferecer suporte à ferramenta Systrace, conforme documentado no SDK do Android. O Systrace precisa estar inativo por padrão e PRECISA haver uma instância acessível ao usuário para ativar o Systrace.

• Perfetto (link em inglês)

  • [C-SR-1] É FORTEMENTE RECOMENDADO expor um /system/bin/perfetto binário para o usuário do shell com o qual o cmdline obedece a documentação do perfetto (link em inglês).
  • [C-SR-2] O binário do perfetto é FORTEMENTE RECOMENDADO para aceitar como entrada uma protobuf que está em conformidade com o esquema definido em a documentação do perfetto (link em inglês).
  • [C-SR-3] O binário do perfetto é MUITO RECOMENDADO para escrever como saída uma rastro protobuf que esteja em conformidade com o esquema definido em a documentação do perfetto (link em inglês).
  • [C-SR-4] É MUITO RECOMENDADO fornecer, pelo binário perfetto, Pelo menos as fontes de dados descritas na documentação do Perfeito.

• Baixa memória assassina

  • [C-0-12] É NECESSÁRIO gravar um Atom LMK_KILL_OCCURRED_FIELD_NUMBER no Status do registro quando um app é encerrado pelo Low Memory Killer.

• Modo arcabouço de testes Se as implementações de dispositivos oferecerem suporte ao comando shell cmd testharness e executar cmd testharness enable, eles:

  • [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 várias configurações de hardware. Nas telas compatíveis com Android em que todos os dispositivos de terceiros compatíveis aplicativos possam ser executados, as implementações de dispositivos PRECISAM implementar essas APIs corretamente e comportamentos, conforme detalhado nesta seção.

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.
• pontos por polegada (dpi). O número de pixels abrangidos por uma linha horizontal ou vertical de 1”. Quando os valores de dpi estão listados, tanto horizontais e o DPI vertical precisam estar dentro do intervalo.
• 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). A unidade de pixel virtual normalizada para um Tela de 160 dpi, calculada como: pixels = dps * (densidade/160).

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 oferecem suporte a UI_MODE_TYPE_NORMAL e incluem Telas compatíveis com Android com cantos arredondados:

• [C-1-1] PRECISA garantir que pelo menos um dos requisitos a seguir for satisfeita:

  • O raio dos cantos arredondados será menor ou igual a 38 dp.
  • Quando uma caixa de 15 dp por 15 dp está ancorada em cada canto da 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 do dispositivo incluírem telas compatíveis com Android que sejam dobrável, ou inclui uma articulação dobrável entre vários painéis de tela e faz para renderizar apps de terceiros, elas:

• [C-2-1] PRECISA implementar a versão estável mais recente disponível do API de extensões ou a versão estável da API secundária que será usada pela biblioteca do Window Manager Jetpack.

Se as implementações do dispositivo incluírem telas compatíveis com Android que sejam dobrável, ou inclui uma articulação dobrável entre vários painéis de tela e, se a articulação ou dobra cruzar uma janela de aplicativo em tela cheia, elas:

• [C-3-1] PRECISA informar a posição, os limites e o estado da articulação ou dobra ou APIs de arquivo secundário ao aplicativo.

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.

7.1.1.2 Proporção da tela

Embora não haja restrições à proporção da tela física para Telas compatíveis com Android, a proporção da tela lógica em que apps de terceiros são renderizados, os quais podem ser derivados da altura e valores de largura informados por meio do view.Display APIs e configuração APIs, PRECISAM atender aos seguintes requisitos:

• [C-0-1] Implementações de dispositivos com Configuration.uiMode definido como UI_MODE_TYPE_NORMAL PRECISA ter um valor de proporção menor ou igual a a 1,86 (aproximadamente 16:9), a menos que o app atenda a um dos seguintes condições:

  • O app declarou que oferece suporte a uma proporção de tela maior por meio do android.max_aspect do valor dos metadados.
  • O app declara que é redimensionável usando a classe android:resizeableActivity. .
  • O app é direcionado ao nível 24 da API ou mais recente e não declara uma android:maxAspectRatio restringiria a proporção permitida.

• [C-0-3] Implementações de dispositivos com o Configuration.uiMode definido como O valor de proporção do UI_MODE_TYPE_WATCH PRECISA ter o valor 1,0 (1:1) definido.

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.

• [C-0-1] Por padrão, as implementações de dispositivos PRECISAM informar apenas um dos As densidades de framework do Android que estão listadas em DisplayMetrics usando a API DENSITY_DEVICE_STABLE e esse valor NÃO PODE ser alterado em nenhum momento. No entanto, o dispositivo PODE informar uma densidade arbitrária diferente de acordo com a configuração de tela mudanças feitas pelo usuário (por exemplo, tamanho de exibição) definidas após o valor inicial inicialização.

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

Se houver uma affordance para mudar o tamanho de exibição do dispositivo:

• [C-1-1] O tamanho de exibição NÃO PODE ser dimensionado maior que 1,5 vez a densidade nativa ou produzir uma dimensão mínima efetiva da tela menor que 320 dp (equivalente a para o qualificador de recurso sw320dp), o que ocorrer primeiro.
• [C-1-2] O tamanho de exibição NÃO PODE ser dimensionado menor que 0,85 vezes a densidade nativa.
• 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

OpenGL ES 7.1.4.1

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:

• [C-1-1] PRECISA oferecer suporte ao OpenGL ES 1.1 e 2.0, conforme incorporado e detalhado. na documentação do SDK do Android.
• [C-SR-1] É FORTEMENTE RECOMENDADO para oferecer suporte ao OpenGL ES 3.1.
• 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-main-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 ao 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 ao 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 ao 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-main-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 1.0 ou mais recente, 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.0 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.
• [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.
• DEVE oferecer suporte a VkPhysicalDeviceProtectedMemoryFeatures e VK_EXT_global_priority.
• [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 2021.

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 As sinalizações de recurso do Vulkan são:

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

7.1.4.3 RenderScript

• [C-0-1] As implementações de dispositivos PRECISAM ser compatíveis 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.

Telas de ampla gama 7.1.4.5

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.touch (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. O 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 para os 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 estar "Voltar" e ser fornecida como um gesto de deslizar da as extremidades esquerda e direita da orientação atual da 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 (semelhante ao mouse ou ao toque).
• 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, eles:

• [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 cursor e exibir 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 que desce ou sobe sobre o 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 compatibilidade com 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_BOT_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 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 relatado de cada 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 no 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 do 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 os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
• [C-SR-7] É FORTEMENTE RECOMENDADO para implementar a TYPE_GAME_ROTATION_VECTOR sensor composto.

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 meio da API GNSS Location Provider 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 leitura binária "perto" ou "longe", 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/Ajudar Hz.
  • 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.

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-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) após no máximo 20 tentativas falsas e nenhum 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.
• [C-1-5] PRECISA remover completamente todos os dados biométricos identificáveis de um usuário. quando a conta do usuário é removida, inclusive por meio de uma redefinição para a configuração original.
• [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 ).
• [C-1-7] PRECISA desafiar o usuário quanto à autenticação principal recomendada. (por exemplo, PIN, padrão, senha) uma vez a cada 24 horas ou menos. Observação: o upgrade de dispositivos lançados com o Android 9 ou versões anteriores PRECISA contestar o usuário quanto à autenticação principal recomendada (por exemplo, PIN, padrão, senha) uma vez a cada 72 horas ou menos.
• [C-1-8] PRECISA desafiar o usuário na pergunta principal recomendada. Autenticação (por exemplo: PIN, padrão, senha) ou biometria de Classe 3 (STRONG) depois de uma das seguintes opções:
  • um tempo limite de inatividade de 4 horas OU
  • 3 tentativas de autenticação biométrica falharam.
  • O tempo limite de inatividade e a contagem de autenticação com falha são redefinidos após qualquer confirmação das credenciais do dispositivo. Observação: o upgrade de dispositivos lançados com o Android 9 ou versões anteriores pode ser isentos de C-1-8.
• [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 que tenham uma taxa de rejeição falsa 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.

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 impostor e spoofing para a apresentação de Nível A espécies com instrumento de ataque (PAI) não superior a 20%, e (2) um spoof e taxa de aceitação de impostores de espécies PAI de nível B não superior a 30%, como 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), ou em um chip com um canal seguro para o ambiente de execução isolado.

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

• [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.
  • 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. Upgrade de dispositivos lançados no Android versão 9 ou anterior não estão isentos do 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 (por exemplo, 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.

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 [Movido para 7.4.9]

7,4. Conectividade de dados

7.4.1. Telefonia

A "Telefonia", conforme usada pelas APIs do Android, e este documento se refere especificamente ao hardware relacionado a chamadas de voz e ao envio de mensagens SMS via GSM. ou CDMA. Embora essas chamadas de voz possam ou não ter comutação por pacote, para fins do Android, considerados independentes de quaisquer dados conectividade que pode ser implementada usando a mesma rede. Em outras palavras, a funcionalidade de “telefonia” do Android e as APIs se referem especificamente chamadas e SMS. Por exemplo, implementações de dispositivos que não podem fazer chamadas ou enviar/receber mensagens SMS não são considerados um dispositivo de telefonia, independentemente se uma rede celular é usada para conectar dados.

• 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 dispositivos não definirem a propriedade do sistema ro.telephony.iwlan\_operation\_mode como "legada", 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.
• [C-1-4] PRECISA oferecer suporte a multicast DNS (mDNS) e NÃO PODE filtrar pacotes mDNS (224.0.0.251) a qualquer momento de operação, incluindo:
  • Mesmo quando a tela não está ativa.
  • Para implementações de dispositivos Android Television, mesmo quando em espera estados de potência.
• [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() e WifiManager.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 oferecer suporte a 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) com A2DP.

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 entre si 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 Calibragem de presença.

Se as implementações de dispositivos forem compatíveis com o Bluetooth versão 5.0, elas:

• [C-SR-4] É FORTEMENTE RECOMENDADO oferecer suporte para:
  • LE 2M PHY
  • Codec LE PHY
  • Extensão de publicidade LE
  • Publicidade periódica
  • Pelo menos 10 conjuntos de anúncios
  • Pelo menos oito conexões simultâneas do LE. Cada conexão pode estar e papéis de topologia de conexão.
  • Privacidade da camada de links do LE
  • Uma "lista de resolução" de pelo menos oito entradas

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 incluírem suporte para 802.1.15.4 e exporem a a um aplicativo de terceiros, elas:

• [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 a distância é medida a partir da borda superior do DUT voltado para cima e inclinado 45 graus.
  • [C-SR-2] É FORTEMENTE RECOMENDADO seguir as etapas de configuração da medição especificado em 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 finalidade da visualização básica e ainda capturar.
• [C-1-3] PRECISA garantir que o aplicativo padrão de câmera pré-instalado como processar 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 HDR HLG 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 pela 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 localizada na lateral de o dispositivo em frente à tela; ou seja, ela retrata cenas do outro lado no dispositivo, como uma câmera tradicional.

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 é aquela localizada no mesmo lado do dispositivo como a tela, ou seja, uma câmera normalmente usada para imagens do usuário, como videoconferência e outros aplicativos semelhantes.

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 prévia 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 à a orientação atual do dispositivo.

7.5.3. Câmera externa

Implementações de dispositivos:

• PODE incluir suporte para uma câmera externa que não 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 voltadas na mesma direção, É FORTEMENTE RECOMENDADO para 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).

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

• 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" no 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] É MUITO RECOMENDADO implementar a classe de áudio USB conforme documentado na documentação do SDK do Android.
• DEVE oferecer suporte ao carregamento do dispositivo periférico USB conectado 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 conexão ou a porta de carregamento downstream(CDP) de saída da faixa atual especificado nas 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 "porta de saída" não é considerada uma rede celular ou Wi-Fi.

7.8.2.1. Portas de áudio analógico

Para serem compatíveis com 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 recurso de áudio quase ultrassom por AudioManager.getProperty 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 fluxos 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

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

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 Em espera.
• [C-1-4] PRECISA implementar os buckets do App em espera e o recurso "Soneca" como descritos 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 bucket Rare App Standby, consulte 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 por meio 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 o 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 pelo 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 operacional (bem como arquivos APEX) e ser 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.

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-4] PRECISA ter apenas uma implementação do usuário do Google Cloud. Se a implementação do dispositivo for compatível com um dispositivo complementar, o o dispositivo complementar pode oferecer uma interface adicional.

• [C-0-5] NÃO PODE conceder permissões de execução para aplicativos, 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 atender a todos os requisitos descritos para implementações de dispositivos na seção "9.8.6 Captura de conteúdo".
• [C-4-2] NÃO PODE ter a permissão android.permission.INTERNET. Este é mais restrito do que o FORTEMENTE RECOMENDADO listado na seção 9.8.6.
• [C-4-3] NÃO PODE SER vinculado a outros apps, exceto aos seguintes apps do sistema: Bluetooth, Contatos, Mídia, Telefonia, SystemUI e componentes que fornecem APIs de Internet.Isso é mais restrito que o FORTEMENTE RECOMENDADO listado na seção 9.8.6.

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.

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.

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] PRECISA exibir e receber o consentimento explícito do usuário, permitindo que qualquer exibidas na tela do usuário sejam capturadas sempre que a transmissão de tela ou a gravação de tela são ativadas pelo MediaProjection ou APIs proprietárias. NÃO PODE fornecer aos usuários uma affordance para desativar futuras exibição do consentimento do usuário.
• [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.

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 Captura de Conteúdo, os seguintes requisitos:

• [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" se refere 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" se refere a uma visualização na tela, que fica constantemente visível para 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, encaminha 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 dar 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. Captura de conteúdo e pesquisa de apps

Android, pela API do sistema ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query ou por outro meios reservados, oferece suporte a um mecanismo para implementações de dispositivos a fim de capturar as seguintes interações de dados entre os aplicativos e o usuário:

• 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).
• Quaisquer outros eventos que um aplicativo fornece ao sistema por meio do Content Capture ou AppSearchManager uma API Android e API proprietária.
• 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.

Se as implementações de dispositivos capturarem os 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 somente todos esses dados e o registro do dispositivo usando um mecanismo de preservação da privacidade. O mecanismo de preservação da privacidade é definida como “aqueles que permitem somente análises agregadas e evitam correspondência de eventos registrados ou resultados derivados para usuários individuais” a 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 Captura de Conteúdo), exceto quando houver consentimento explícito do usuário eles sejam compartilhados.
• [C-1-6] PRECISA fornecer recursos ao usuário para apagar dados que a ContentCaptureService ou os meios reservados coletam se o os dados são armazenados de qualquer forma no dispositivo.
• [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, launcher.
• [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.

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

O Android, pelo SpeechRecognizer#onDeviceSpeechRecognizer(), permite para realizar o reconhecimento de fala no dispositivo sem envolver a rede. Qualquer implementação do SpeechReconhecedor no dispositivo PRECISA seguir as políticas descritos nesta seção.

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 API), a menos que o app de terceiros seja o IME padrão ou seja o app que está 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 todos os modems celulares futuros) 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 da API Emergency Location Bypass 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 ao app no armazenamento externo. As únicas exceções são as seguintes:
  • A autoridade do provedor de armazenamento externo (por exemplo, apps como DocumentsUI).
  • "Download Provider", que usa a autoridade do provedor "downloads" 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ó podem acessar diretórios "obb" para 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
• [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 o 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,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 de arquivos 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 refere-se 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. 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 do arquivo. conteúdos do 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-SR-1] Se houver vários chips distintos no dispositivo (por exemplo, rádio, um processador de imagem especializado), o processo de inicialização de cada um desses chips RECOMENDADO DE VERIFICAR cada estágio na 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).
• [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.

Se as implementações de dispositivos já foram lançadas sem suporte a C-1-8 a C-1-11 em uma versão anterior do Android e não pode adicionar suporte para esses requisitos com uma atualização de software do sistema, eles PODEM ser isentos da e cumprimento de requisitos regulatórios.

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

Implementações de dispositivos:

• [C-0-3] PRECISA ser compatível com a verificação criptográfica do conteúdo do arquivo em relação a uma sem ler o arquivo inteiro.
• [C-0-4] NÃO PODE permitir que as solicitações de leitura em um arquivo protegido tenham êxito quando o conteúdo lido não confirma com base em uma chave confiável.

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.

Implementações de dispositivos:

• [C-SR-4] É RECOMENDADO A compatibilidade com a API Android Protected Confirmation.

Se as implementações de dispositivos oferecem suporte à Confirmação protegida pelo Android API, eles:

• [C-3-1] PRECISA informar true para ConfirmationPrompt.isSupported() API.

• [C-3-2] PRECISA garantir que o código em execução no SO Android, incluindo kernel, malicioso ou outros, não pode gerar uma resposta positiva sem interação do usuário.

• [C-3-3] PRECISA garantir que o usuário analisou e aprovou a mesmo que o sistema operacional Android, incluindo seu kernel, está comprometido.

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 tempo o intervalo PRECISA ser de pelo menos 30 segundos para 9 < n < 30. Para n > 29, o 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 devem 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, SHA1 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.
• [C-1-4] PRECISA oferecer suporte ao atestado de chaves em que a chave de assinatura do atestado é protegidos por um hardware seguro, e a assinatura é realizada em um hardware seguro. As chaves de assinatura de atestado PRECISAM ser compartilhadas entre um número suficiente de dispositivos para evitar que as chaves sejam usadas como identificadores de dispositivos. Só de ida de atender a esse requisito é compartilhar a mesma chave de atestado, a menos que pelo menos 100.000 unidades de uma determinada SKU são produzidas. Se mais de 100.000 unidades de uma SKU são produzidos, uma chave diferente PODE ser usada para cada 100.000 unidades.

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.

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:
  • O DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) método
  • O 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-8] 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 72 horas ou menos, a menos que a segurança do usuário (por exemplo, distração do motorista) é preocupante.
• [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.
• [C-10-6] PRECISA desativar a criação de eventos de entrada associados usando VirtualDeviceManager quando indicado por DevicePolicyManager.setNearbyAppStreamingPolicy
• [C-10-7] PRECISA usar uma área de transferência separada apenas para cada dispositivo virtual. (ou desativar a área de transferência para dispositivos virtuais)
• [C-10-11] PRECISA desativar a interface de autenticação em dispositivos virtuais, incluindo: entrada de fator de conhecimento e solicitação biométrica
• [C-10-12] PRECISA restringir intents iniciadas por um dispositivo virtual para exibição apenas no mesmo dispositivo virtual
• [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*:

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 "false" na inicialização virtual. dispositivo.
• [C-13-9] PRECISA bloquear atividades. que não ativam explicitamente o streaming e que indicam que eles mostram conteúdo sensível, inclusive via SurfaceView#setSecure, FLAG_SECURE ou SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS sejam iniciado no dispositivo virtual.

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-10] PRECISA incluir o hardware certificado de acordo com a Perfil de proteção de IC seguro BSI-CC-PP-0084-2014 ou avaliado por um laboratório de testes credenciado nacional que incorpora Avaliação de vulnerabilidade de alto potencial de ataque de acordo com a Aplicação de critérios comuns de potencial de ataque a Cartões inteligentes.
  • [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.

9,17 Framework de virtualização do Android

Se o dispositivo implementar suporte para as APIs do Framework de virtualização do Android (android.system.virtualmachine.*), o host do Android:

• [C-1-1] PRECISA oferecer suporte a todas as APIs definidas pelos android.system.virtualmachine.*.
• [C-1-2] NÃO PODE modificar o SELinux do Android e o modelo de permissão da gerenciamento de máquinas virtuais protegidas.
• [C-1-3] NÃO PODE modificar, omitir ou substituir as regras de nunca permitir presentes em a system/sepolicy fornecida no Android Open Source Project upstream (AOSP) e a política PRECISA ser compilada com todas as regras de "proibição" presentes.
• [C-1-4] NÃO É POSSÍVEL permitir que códigos não confiáveis (por exemplo, apps de terceiros) criem e executem uma Máquina virtual protegida. Observação: isso pode mudar em versões futuras do Android.
• [C-1-5] NÃO PODE permitir que uma máquina virtual protegida execute um código que não está não fazem parte da imagem de fábrica ou de suas atualizações. Tudo o que não estiver coberto pela Inicialização verificada do Android (por exemplo, arquivos baixados da Internet ou transferidos por sideload) NÃO PODEM ser executados em uma máquina virtual protegida.

Se o dispositivo implementar suporte para as APIs do Framework de virtualização do Android (android.system.virtualmachine.*), qualquer instância de máquina virtual protegida:

• [C-2-1] PRECISA executar todos os sistemas operacionais disponíveis no virtualização APEX em uma máquina virtual protegida.
• [C-2-2] NÃO PODE permitir que uma máquina virtual protegida execute um sistema operacional que não seja assinado pelo implementador do dispositivo ou pelo fornecedor do SO.
• [C-2-3] NÃO PODE permitir que uma máquina virtual protegida execute dados como código (por exemplo, SELinux nunca permite execmem).
• [C-2-4] NÃO PODE modificar, omitir ou substituir as regras de nunca permitir presentes em o system/sepolicy/microdroide fornecido no Android Open Source AOSP.
• [C-2-5] PRECISA implementar mecanismos de defesa em profundidade de máquinas virtuais protegidas. (por exemplo, SELinux para pVMs), mesmo para sistemas operacionais não Microdroid.
• [C-2-6] PRECISA garantir que o firmware da pVM se recuse a inicializar se não for possível fazer a verificação. a imagem inicial.
• [C-2-7] PRECISA garantir que o firmware da pVM se recuse à inicialização se a integridade da a instância.img for comprometido.

Se o dispositivo implementar suporte para as APIs do Framework de virtualização do Android (android.system.virtualmachine.*), o hipervisor:

• [C-3-1] NÃO PODE permitir que uma pVM tenha acesso a uma página que pertença a outra. entidade (ou seja, outra pVM ou hipervisor), a menos que seja explicitamente compartilhada pela página proprietário. Isso inclui a VM do host. Isso se aplica a acessos de CPU e DMA.
• [C-3-2] PRECISA excluir permanentemente uma página depois que ela for usada por uma VM e antes que ela seja retornada ao host (por exemplo, a pVM é destruída).
• [C-3-3] PRECISA garantir que o firmware da pVM seja carregado e executado antes qualquer código em uma pVM.
• [C-3-4] PRECISA garantir que o BCC e os CDIs fornecidos a uma instância de pVM só possam ser derivadas por essa instância específica.

Se o dispositivo implementar suporte para as APIs do Framework de virtualização do Android, depois em todas as áreas:

• [C-4-1] NÃO PODE fornecer funcionalidade a uma pVM que permita ignorar o Modelo de segurança do Android.

Se o dispositivo implementar suporte para as APIs do Framework de virtualização do Android:

• [C-5-1] PRECISA oferecer suporte à compilação isolada de uma atualização do tempo de execução do ART.

Se o dispositivo implementar suporte para as APIs do framework de virtualização do Android, para o gerenciamento de chaves:

• [C-6-1] PRECISA codificar a cadeia do DICE em um ponto que o usuário não pode modificar, mesmo e dispositivos desbloqueados. Para garantir que não seja falsificado.
• [C-6-2] PRECISA usar o DICE corretamente, ou seja, fornecer os valores corretos.

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 13

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 são diferentes de uma implementação que passou 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

Veja a seguir um resumo das mudanças na definição de compatibilidade neste lançamento:

4 de outubro de 2023

2. tipos de dispositivos

• 2.2.5. Modelo de segurança:

  Ver revisão

  • [9.8/H-1-14] PRECISA exibir o indicador de microfone, conforme descrito na seção 9.8.2. [9.8/C-3-1], quando um resultado de hotword bem-sucedido é transmitido para a voz

• 2.2.7.1 Mídia:

  Ver revisão

  • [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 é definido como um vídeo simultâneo de 1080p a 720p sessão de transcodificação somente de vídeo usando codecs de vídeo de hardware com o Inicialização de gravação de áudio e vídeo em 1080p. Para o codec Dolby Vision, a latência de inicialização do codec PRECISA ser de 50 ms ou menos.

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

7.4. conectividade de dados

• 7.4.1.1. Compatibilidade com bloqueio de número:

  Ver revisão

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

• 7.4.1.2. API Telecom:

  Ver revisão

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

9.11. chaves e credenciais

• 9.11.2. StrongBox:

  Ver revisão

  é fornecida pela HAL IAuthSecret.

  A IAR vai se tornar um requisito OBRIGATÓRIO no Android 14.

26 de junho de 2023

2. tipos de dispositivos

• 2.2.1. Hardware

  • Remoção dos requisitos 7.2.3/H-0-5, 7.2.3/H-0-6, 7.2.3/H-0-7

  • Outra atualização:

    Ver revisão

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

• 2.5.1. Hardware

  Ver revisão

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

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

    • 280 dpi ou menos em telas pequenas/normais
    • Ldpi ou menor em telas muito grandes
    • Mdpi ou menor em telas grandes

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

    • xhdpi ou maior em telas pequenas/normais
    • hdpi ou maior em telas grandes
    • mdpi ou maior em telas muito grandes

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

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

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

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

3. software

• 3.2.3.5. Intents de aplicativos condicionais

  Ver revisão

  Se as implementações do dispositivo informarem android.hardware.telephony.calling android.hardware.telephony, eles:

7. Compatibilidade de hardware

• 7.4. Conectividade de dados

  Ver revisão

  Requisitos da calibragem de presença.

9. Compatibilidade do modelo de segurança

• 9.1 Permissões

  Ver revisão

  Implementações de dispositivos:

  • [C-0-5] NÃO PODE conceder permissões de execução para usuários pré-instalados aplicativos, a menos que:

    • São instalados no momento do envio do dispositivo E
    • O consentimento do usuário pode ser obtido antes que o aplicativo utiliza it a permissão,

    OU

    • As permissões de execução são concedidas pelo política de concessão de permissão padrão seja para ter um papel de plataforma. associado a um padrão de intent para o qual o aplicativo pré-instalado é definido como o gerenciador padrão.

• 9.11. chaves e credenciais

  • Remoção dos requisitos [C-13-10] e 9.11.4.

20 de março de 2023

2. tipos de dispositivos

• 2.2.3. software

  Ver revisão

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

  • [C-17-13.2.3.1/ H-1-1] PRECISA ter uma atividade para lidar com Configurações#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.

  Encerrar novos requisitos

• 2.3.2. multimídia

  Ver revisão

  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-1SR1] É RECOMENDADO PARA oferecer suporte à decodificação UHD perfil a 60 quadros por segundo com o perfil 2 (profundidade de cor de 10 bits).

• 2.5.1. Hardware

  Ver revisão

  Implementações de dispositivos automotivos:

  • [7.3/A-0-1SR1] PODE identificar a localização ao combinar 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-20-4] O local solicitada por LocationManager#requestLocationUpdates() NÃO PODE haver correspondência no mapa.

3. software

• 3,18. Contatos

  Ver revisão

  Conta padrão para novos contatos:o Provedor de contatos fornece APIs para gerenciar a configuração da conta padrão ao criar um novo contato.

  Se as implementações do dispositivo pré-carregarem um app de contatos, os contatos pré-carregados aplicativo:

  • [C-2-1] PRECISA processar a intent ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT para iniciar uma interface seleção de conta e salvar a configuração no Provedor de contatos quando uma conta for selecionados.

  • [C-2-2] PRECISA respeitar a configuração de conta padrão ao lidar com Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT para o ContactsContracts.Contacts.CONTENT_TYPE e ContactsContract.RawContacts.CONTENT_TYPE selecionando inicialmente o do Compute Engine.

  Encerrar novos requisitos

• 3.2.3.5. Intents de aplicativos condicionais

  Ver revisão

  [Movido para 2.2.3]

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

  • [C-17-1] PRECISA ter uma atividade para lidar com Settings#ACTION_CONFIG_EMBED_DEEP_LINK_ACTIVITY quando a funcionalidade de divisão estiver ativada. A Activity PRECISA ser protegida por android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK e PRECISA ser. iniciar a atividade da intent analisada Configurações#EXTRA_CONFIG_EMBEDDED_DEEP_LINK_INTENT_URI.

  Encerrar novos requisitos

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

• 6.1. Ferramentas para desenvolvedores

  Ver revisão

  • Macaco
    • [C-0-8] PRECISA incluir o framework Monkey e disponibilizá-lo para aplicativos usarem.

7. Compatibilidade de hardware

• 7.3.13. IEEE 802.1.15.4 (UWB)

  Ver revisão

  [Migração para a versão 7.4.9]

  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-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-1-6] São RECOMENDADOS para passar na conformidade e de certificação definidos por organizações padrão, incluindo FIRA e CCC e CSA.

  Encerrar novos requisitos

• 7.4.1. Telefonia

  Ver revisão

  Se as implementações de dispositivos incluirem telefonia GSM ou CDMA, se as implementações do dispositivo forem relacionadas ao recurso android.hardware.telephony, faça o seguinte:

  • [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 de dispositivos incluirem telefonia GSM ou CDMA, informarão o android.hardware.telephony e forneça uma barra de status do sistema. Em seguida:

  • [C-6-7-1] PRECISA selecionar uma assinatura ativa representativa para uma determinada assinatura 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 incluirem telefonia GSM ou CDMA, informem android.hardware.telephony , faça o seguinte:

  • [C-6-87] 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-108] NÃO É POSSÍVEL aplicar nenhum dos seguintes comportamentos a apps de operadoras ativas. (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 incluirem telefonia GSM ou CDMA, informem o recurso android.hardware.telephony e todas as assinaturas não oportunistas ativas que compartilham um UUID de grupo são desativados,removidos fisicamente do dispositivo, ou marcados como oportunistas, o dispositivo:

  • [C-78-1] PRECISA desativar automaticamente todos os 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-89-1] NÃO PODE declarar PackageManager#FEATURE_TELEPHONY_CDMA.
  • [C-89-2] PRECISA gerar uma IllegalArgumentException nas tentativas de definir qualquer Tipos de rede 3GPP2 em bitmasks de tipo de rede preferencial ou permitido.
  • [C-89-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-1110-1] PRECISA declarar os android.hardware.telephony.euicc.mep flag de recurso.

• 7.4.9. UWB

  Ver revisão

  Se as implementações do dispositivo relatarem compatibilidade com o recurso android.hardware.uwb pela android.content.pm.PackageManager Se as implementações de dispositivos incluírem 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-16] PRECISA garantir que as medições 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-27] 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 a distância é medida a partir da borda superior do DUT voltado para cima e inclinado 45 graus.
  • [C-SR-2] É FORTEMENTE RECOMENDADO seguir as etapas de configuração da medição especificado em Requisitos para a calibragem de presença.

  É MUITO RECOMENDADO seguir a medição etapas de configuração especificadas nos Requisitos para a calibragem de presença.

  Encerrar novos requisitos

• 7.8.2.2. Portas de áudio digitais

  Ver revisão

  Para ser compatível com os fones de ouvido e outros acessórios de áudio usando conectores USB-C e a implementação (classe de áudio USB) no ecossistema Android, conforme definido nas especificações de fone de ouvido USB do Android.

19 de outubro de 2022

2. tipos de dispositivos

• 2.2.3 Software

  Ver revisão

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

  • [3.8.17/H-1-1] PRECISA apresentar uma confirmação para 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.

3. software

• 3.2.3.5. Intents de aplicativos condicionais

  Ver revisão

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

  • [C-17-1] PRECISA ter uma atividade para lidar com Configurações#ACTION_CONFIG_EMBED_DEEP_LINK_ACTIVITY quando a funcionalidade de divisão estiver ativada. A atividade PRECISA ser protegida. por 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 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.

• 3.4.1 Compatibilidade do WebView

  Ver revisão

  • [C-1-4]PRECISA renderizar o conteúdo fornecido ou conteúdo de URL remoto em um processo diferente do aplicativo que instancia a WebView. Especificamente, o processo de renderizador separado PRECISA ter privilégio mínimo, ser executado como um ID de usuário separado, não ter acesso ao diretório de dados do app nem acesso direto à rede e só ter acesso aos serviços mínimos exigidos do sistema pelo binder. A implementação do WebView do AOSP atende a esse requisito.

7. Compatibilidade de hardware

• 7.4.2 IEEE 802.11 (Wi-Fi)

  Ver revisã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:

  • [C-3-1] PRECISA DEVE desativar o modo de economia de energia Wi-Fi sempre que um aplicativo adquirir Fechadura WIFI_MODE_FULL_HIGH_PERF ou WIFI_MODE_FULL_LOW_LATENCY fechadura por WifiManager.createWifiLock() e WifiManager.WifiLock.acquire()

• 7.4.3 Bluetooth

  Ver revisão

  Se as implementações de dispositivos incluírem suporte ao Bluetooth de baixa energia (BLE), eles:

  • [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 ativamente o BLE na 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.

• 7.5.5 Orientação da câmera

  Ver revisão

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

  Encerrar novos requisitos

9. Compatibilidade do modelo de segurança

• 9.11 Chaves e credenciais

  Ver revisão

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

  • [C-1-6] PRECISA oferecer suporte a IKeymasterDevice 4.0, IKeymasterDevice 4.1, IKeyMintDevice versão 1 ou IKeyMintDevice versão 2.

• 9.17 Framework de virtualização do Android

  Ver revisão

  Se o dispositivo implementa suporte para o Framework de virtualização do Android APIs (android.system.virtualmachine.*), o host do Android:

  • [C-1-3] NÃO PODE modificar, omitir ou substituir as regras de nunca permitir presentes em a system/sepolicy fornecida no Android Open Source Project upstream (AOSP) e a política PRECISA ser compilada com todas as regras de nunca permitir presentes.

  Se o dispositivo implementa suporte para o Framework de virtualização do Android (android.system.virtualmachine.*) e qualquer máquina virtual protegida. instância:

  • [C-2-4] NÃO PODE modificar, omitir ou substituir as regras de nunca permitir presentes em o system/sepolicy/microdroide fornecido no Android Open Source Project (AOSP).

  Se o dispositivo implementar suporte para as APIs do framework de virtualização do Android, para o gerenciamento de chaves:

  • [C-6-2] PRECISA usar o DICE corretamente, ou seja, fornecer os valores corretos. No entanto, talvez ela não precise ter esse nível de detalhes.

15 de agosto de 2022

2. tipos de dispositivos

• 2.2.1 Hardware: mudanças no requisitos de hardware.

  • Dispositivos de entrada:

    Ver revisão

    Implementações de dispositivos portáteis:

    • [7.2.3/H-0-5] PRECISA chamar OnBackInvokedCallback.onBackStarted() no(a) atual janela em foco quando o gesto "Voltar" é iniciado ou o botão "Voltar" (KEYCODE_BACK) está pressionada.
    • [7.2.3/H-0-6] PRECISA chamar OnBackInvokedCallback.onBackInvoked() quando o gesto "Voltar" é confirmado ou o botão Voltar é liberado (UP).
    • [7.2.3/H-0-7] PRECISA chamar OnBackInvokedCallback.onBackCancelled() quando o gesto "Voltar" não é confirmado ou o evento KEYCODE_BACK é cancelado.

    Encerrar novos requisitos

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

    • [7.4.2.5/H-1-1] PRECISA informar o intervalo com precisão para dentro de +/-1 metro a uma largura de banda de 160 MHz no 68o percentil (conforme calculado com a função de distribuição cumulativa), +/-2 metros a uma largura de banda de 80 MHz no 68o percentil, +/-4 metros a 40 MHz de largura de banda no 68o e +/- 8 metros a 20 MHz de largura de banda 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] São RECOMENDADOS ! API WifiRttManager#startRanging do Android.

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

    Encerrar novos requisitos

  • Latência de áudio:

    Ver revisão

    Se as implementações de dispositivos portáteis declararem android.hardware.audio.output e android.hardware.microphone, eles:

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

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

    Encerrar novos requisitos

  • Entradas táteis:

    Ver revisão

    Se as implementações de dispositivos portáteis incluírem pelo menos um atuador tátil, elas:

    • [7,10/H]* NÃO DEVE usar uma massa giratória excêntrica (ERM, na sigla em inglês) atuador tátil (vibrador).
    • [7,10/H]* DEVE posicionar o posicionamento do atuador perto do local em que o dispositivo normalmente é segurado ou tocado pelas mãos.
    • [7.10/H]* DEVE implementar todas as constantes públicas para retorno tátil limpo 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).
    • [7.10/H]* DEVE implementar todas as constantes públicas para retorno tátil limpo em android.os.VibrationEffect ou seja (Efeito_TICK, EF_CLICK, EF_HEAVY_CLICK e EF_DOUBLE_CLICK) e todos os públicos viáveis Constantes PRIMITIVE_* para retorno tátil avançado em android.os.VibrationEffect.Composition ou seja (PRIMITIVE_CLICK e PRIMITIVE_TICK) (CLICK, TICK, LOW_TICK, QUICK_FALL, ACELERAÇÃO RÁPIDA, ENCERRADA_Lenta, GIRADA, QUI). Alguns desses primitivos, LOW_TICK e SPIN só serão viáveis se a vibração for compatível frequências relativamente baixas.

    • [7.10/H]* DEVE seguir as orientações para mapeamento de constantes públicas em android.view.HapticFeedbackConstants às constantes android.os.VibrationEffect recomendadas, com as relações de amplitude correspondentes.

    Encerrar novos requisitos

    • [7.10/H]* DEVE usar estas constantes táteis vinculadas mapeamentos.

    • [7.10/H]* DEVE verificar se o resultado do comando público android.os.Vibrator.hasAmplitudeControl() A API reflete corretamente os recursos da vibração.

    Encerrar novos requisitos

    • [7,10/H]* DEVE verificar as capacidades de amplitude escalonabilidade executando android.os.Vibrator.hasAmplitudeControl()

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

    • [7,10/H]* DEVE mover o atuador tátil no eixo X (esquerda-direita) de orientação retrato.

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

    • [7,10/H]* DEVE fornecer suporte substituto para mitigar o risco de falha, conforme descrito aqui.

• 2.2.3 Software:

  • Cotntrols de dispositivo trivial de autenticação:

    Ver revisão

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

  • Notificações MediaStyle:

    Ver revisão

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

    • [3.8.3.1/H-1-SR] São FORTEMENTE RECOMENDADOS para fornecer uma funcionalidade de usuário(por exemplo, “seletor de saída”) acessado pela IU do sistema, que permite que os usuários alternem entre as opções rotas de mídia(por exemplo, dispositivos Bluetooth e rotas fornecidas para MediaRouter2Manager) quando um app posta uma notificação MediaStyle com um token MediaSession.

• 2.2.4 Desempenho e energia: novo requisito para apps executados em serviços em primeiro plano.

  Ver revisão

  Implementações de dispositivos portáteis:

  • [8.5/H-0-1] PRECISA fornecer uma funcionalidade de usuário em o menu "Configurações" com a capacidade de interromper um app em execução em primeiro plano e exibir todos os apps que têm serviços em primeiro plano ativos e a duração de cada um desses serviços, desde o início, conforme descrito no do documento.
    • Alguns apps PODEM estar isentos de serem interrompidos ou listados em uma dessas funcionalidade do usuário, conforme descrito no documento do SDK.

  Encerrar novos requisitos

• 2.2.7.1 Mídia: atualizações na Seção de Mídia de requisitos para dispositivos portáteis da seguinte forma:

  Ver revisão

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

  • [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().
  • [5.1/H-1-2] PRECISA oferecer suporte a seis instâncias de sessões de decodificador de vídeo por hardware. (AVC, HEVC, VP9, AV1 ou posterior) em qualquer combinação de codecs em execução ao mesmo tempo, com resolução de 1080p a 30 fps.
  • [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().
  • [5.1/H-1-4] PRECISA oferecer suporte a seis instâncias de codificador de vídeo em hardware. sessões (AVC, HEVC, VP9, AV1 ou posteriores) em qualquer combinação de codec em execução ao mesmo tempo, com resolução de 1080p a 30 fps.
  • [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 de CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().
  • [5.1/H-1-6] PRECISA oferecer suporte a seis instâncias de hardware de decodificador de vídeo e hardware. sessões do codificador de vídeo (AVC, HEVC, VP9, AV1 ou posterior) em qualquer codec em execução simultaneamente a uma resolução de 1080p a 30 fps.
  • [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 é 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 de gravação de áudio e vídeo em 1080p.
  • [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 e inicialização de gravação de áudio e vídeo.
  • [5.1/H-1-9] PRECISA oferecer suporte a duas instâncias de decodificador de vídeo por hardware seguro sessões (AVC, HEVC, VP9, AV1 ou posteriores) em qualquer combinação de codec em execução ao mesmo tempo, com resolução de 1080p a 30 fps.
  • [5.1/H-1-10] PRECISA oferecer suporte a três instâncias de decodificador de vídeo por hardware não seguro sessões com 1 instância de sessão de decodificador de vídeo por hardware seguro (4 instâncias no total) (AVC, HEVC, VP9, AV1 ou posterior) em qualquer combinação de codecs em execução simultânea com resolução de 1080p a 30 fps.
  • [5.1/ H-1-11] PRECISA oferecer suporte a um decodificador seguro para cada hardware AVC, HEVC, Decodificador VP9 ou AV1 no dispositivo.
  • [5.1/H-1-12] PRECISA ter uma latência de inicialização do decodificador de vídeo de 40 ms ou menos.
  • [5.1/H-1-13] PRECISA ter uma latência de inicialização do decodificador de áudio de 30 ms ou menos.
  • [5.1/H-1-14] PRECISA ser compatível com o decodificador de hardware AV1 Main 10, Level 4.1.
  • [5.1/H-SR] É altamente recomendado para oferecer suporte a granulação de filme para hardware AV1 decodificador.
  • [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.
  • [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 frame) para uma sessão de vídeo com 1080p a 60 fps sob carga. O carregamento é definido como um vídeo simultâneo de 1080p a 720p de transcodificação usando codecs de vídeo de hardware, além de Reprodução de áudio AAC a 128 kbps.
  • [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. O carregamento é definido como um Sessão simultânea de transcodificação apenas de vídeo de 1080p a 720p usando hardware e uma reprodução de áudio AAC de 128 kbps.
  • [5.6/H-1-1] PRECISA ter uma latência de toque para tom de 80 milissegundos ou menos. usando o teste toque a tom do OboeTester ou 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 menos. em pelo menos um caminho de dados com suporte.
  • [5.6/H-1-3] PRECISA oferecer suporte a áudio de pelo menos 24 bits para saída estéreo de áudio com mais de 3,5 mm. entradas, se presente, e via áudio USB, se compatível com o caminho de dados inteiro para configurações de baixa latência e de streaming. Para baixo configuração de latência, a AAudio deve ser usada pelo app em baixa latência o modo de callback. Para o streaming do Java, uma faixa de áudio Java deve ser usada pelo aplicativo. Tanto no nível latência e configurações de streaming, o coletor de saída da HAL aceitará AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED AUDIO_FORMAT_PCM_32_BIT ou AUDIO_FORMAT_PCM_FLOAT para a saída de destino .
  • [5.6/H-1-4] PRECISA oferecer suporte a dispositivos de áudio USB com mais de 4 canais usados por DJs. controles para visualizar as músicas.
  • [5.6/H-1-5] PRECISA oferecer suporte a dispositivos MIDI compatíveis com a classe e declarar o MIDI flag de recurso.
  • [5.7/H-1-2] PRECISA oferecer suporte a MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL com os recursos de descriptografia de conteúdo abaixo.

  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

  Encerrar novos requisitos

• 2.2.7.2 Câmera: atualizações nos requisitos da Media Performance Class Camera.

  Ver revisão

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

  • [7.5/H-1-1] PRECISA ter uma câmera traseira principal com resolução de pelo menos 12 megapixels com suporte para captura de vídeo a 4k a 30 fps. O principal que é a traseira com o menor ID de câmera.
  • [7.5/H-1-2] PRECISA ter uma câmera frontal principal com resolução de pelo menos 5 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 ambas as câmeras principais.
  • [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 latência de captura JPEG da Camera2 < 1.000 ms para Resolução de 1080p medida 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-6] PRECISA ter 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 oferecer suporte a CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION. para a câmera frontal e a traseira principal.
  • [7.5/H-1-13] PRECISA oferecer suporte ao recurso LOGICAL_MULTI_CAMERA para a instância principal. câmeras se houver mais de uma câmera RGB voltada para a mesma direção.
  • [7.5/H-1-14] PRECISA oferecer suporte ao recurso STREAM_USE_CASE para as contas primárias câmera frontal e traseira principal.

  Encerrar novos requisitos

• 2.2.7.3 Hardware: Atualizações nos requisitos da classe de desempenho de mídia para hardware.

  Ver revisão

  Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.T para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, ele poderá fazer o seguinte:

  • [7.1.1.1/H-2-1] PRECISA ter uma resolução de tela de pelo menos 1080p.
  • [7.1.1.3/H-2-1] PRECISA ter uma densidade de tela de pelo menos 400 dpi.
  • [7.6.1/H-2-1] PRECISA ter pelo menos 8 GB de memória física.

  Encerrar novos requisitos

• 2.2.7.4 Desempenho: Atualizações na classe de desempenho de mídia para desempenho.

  Ver revisão

  Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.T para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, ele poderá fazer o seguinte:

  • [8.2/H-1-1] PRECISA garantir um desempenho de gravação sequencial de pelo menos 125 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 40 MB/s.

  Encerrar novos requisitos

• 2.5.1 Hardware: atualizações em os requisitos do acelerômetro de três eixos e do giroscópio de três eixos, assim como o requisitos para câmeras de visão externa.

  Ver revisão

  Implementações de dispositivos automotivos:

  • [7.3.1/A-0-4] PRECISA estar em conformidade com a sistema de coordenadas do sensor de carros.
  • [7,3/A-SR] São STRONGLY_RECOMENDADOS para incluir um eixo 3 acelerômetro e giroscópio de 3 eixos.
  • [7,3/A-SR] São STRONGLY_RECOMENDADOS para implementar e informar Sensor TYPE_HEADING.

  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] É 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] É 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.

  Encerrar novos requisitos

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

  • [7.3.4/A-SR] É MUITO 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 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] STRONGLY_RECOMENDED 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.

  Encerrar novos requisitos

  Uma câmera de visualização externa é uma câmera que captura cenas fora do dispositivo implementação, como a câmera traseira uma câmera veicular .

  Se as implementações de dispositivos automotivos incluírem uma câmera de visualização externa, uma câmera, eles:

  • [7.5,5/A-SR] São RECOMENDADAS FORTEMENTE para serem orientadas para que a dimensão longa da câmera se alinha ao horizonte.

  • DEVE apoiar Framework de sincronização do Android.

  • PODE ter o autofoco em hardware ou em software implementado o driver da câmera.

  Se as implementações de dispositivos automotivos incluírem uma ou mais câmeras de visão externa, e carregam o serviço Exterior View System (EVS). Depois, para essa câmera, eles:

  • [7.5/A-2-1] NÃO PODE girar nem espelhar horizontalmente a visualização da câmera.

  Implementações de dispositivos automotivos:

  • PODE incluir uma ou mais câmeras disponíveis para terceiros aplicativos conteinerizados.

  Se as implementações de dispositivos automotivos incluem pelo menos uma câmera e a tornam para aplicativos de terceiros:

  • [7.5/A-3-1] PRECISA informar o flag de recurso. android.hardware.camera.any
  • [7.5/A-3-2] não PRECISA declarar a câmera como um câmera do sistema.
  • PODE ser compatível com câmeras externas descritas na seção 7.5.3.
  • PODE incluir recursos (como autofoco etc.) disponíveis para a direção traseira câmeras, conforme descrito na seção 7.5.1.

  Encerrar novos requisitos

• 2.5.5 Modelo de segurança: Novos requisitos de permissões de câmera para dispositivos automotivos.

  Ver revisão

  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 com os papéis destacados Seção 9.1 Permissões com o identificador CDD [C-3-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.

  Encerrar novos requisitos

• 2.6.1 Requisitos do tablet — Hardware: Atualização dos requisitos de tamanho de tela para tablets.

  Ver revisão

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

  • A tela tem um tamanho de tela maior do que 7” e menor que 18", medidas diagonalmente.

  Tamanho da tela

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

3. software

• 3.2.2 Parâmetros de build: Caracteres ASCII atualizados em getSerial().

  Ver revisão

  • [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
  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.5 Intents de aplicação condicional: Atualização dos requisitos para intents de aplicativos condicionais.

  Ver revisão

  Se as implementações de dispositivos incluem uma tela grande (geralmente com largura e altura de exibição de 600 dp+) e suporte funcionalidade dividida, então eles:

  • [C-17-1] PRECISA ter uma atividade para lidar com Configurações#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.

  Encerrar novos requisitos

• 3.5.1 Restrição de Aplicativo: Atualizações nas restrições de aplicativos.

  Ver revisão

  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 esse mecanismo é mais restritiva que Bucket restrito para o 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. de implementação, 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() (em inglês) 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-9] PRECISA informar todos esses eventos de restrições de propriedade pelo UsageStats.

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

  Encerrar novos requisitos

• 3.8.1 Tela de início (tela inicial): Atualizações do suporte a monochrome/adaptive-icon.

  Ver revisão

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

  Encerrar novos requisitos

• 3.8.2 Widgets: atualizar para presença de widget de apps de terceiros no acesso rápido.

  Ver revisão

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

  • [C-1-2] PRECISA incluir suporte integrado para AppWidgets e expor funcionalidades da interface do usuário para adicionar, configurar, exibir e remover AppWidgets diretamente no acesso rápido.

• 3.8.3.1 Apresentação de Notificações: Esclarecimento da definição de notificações de alerta.

  Ver revisão

  As notificações de alerta são aquelas que são apresentadas ao usuário à medida que chegam, independentemente da superfície em que em breve.

• 3.8.3.3 Não perturbe (Não perturbe) / Modo de prioridade: Atualize para incluir o modo de prioridade nos requisitos de Não perturbe.

  Ver revisão

  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:

• 3.8.6 Temas: novos requisitos para paletas de tons de cores dinâmicas.

  Ver revisão

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

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

    "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.

  Encerrar novos requisitos

• 3.8.17 Copiar e colar: adicionada nova seção de requisitos para conteúdo na área de transferência.

  Ver revisão

  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.

  Encerrar novos requisitos

• 3.9.1.1 Provisionamento do Proprietário do Dispositivo: Atualizações nos requisitos de provisionamento do proprietário do dispositivo.

  Ver revisão

  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 nenhum 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 ative 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 contexto de que há apenas uma opção válida. (como para NFC sem suporte ao provisionamento do proprietário do perfil).
      • [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. O 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 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.
  • [C-1-2] PRECISA mostrar um aviso de divulgação apropriado. (conforme mencionado no AOSP) e receba o consentimento afirmativo do usuário final antes de abrir o app. definido como proprietário do dispositivo, a menos que o dispositivo seja configurado de forma programática para o modo de demonstração na loja antes da interação na tela com o usuário final. exigem alguma ação afirmativa antes ou durante o processo de provisionamento para consentir app sendo definido como Proprietário do dispositivo. O consentimento pode ser por ação do usuário ou por alguns meios programáticos, mas apropriados o aviso de divulgação (conforme mencionado no AOSP) PRECISA ser exibido antes do proprietário do dispositivo. antes que o provisionamento seja iniciado. Além disso, o consentimento do proprietário do dispositivo programático mecanismo usado (pelas empresas) para o provisionamento do proprietário do dispositivo NÃO PODE SER interferir na experiência inicial de para uso não empresarial.
  • [C-1-3] NÃO PODE codificar o consentimento nem impedir o uso de outro dispositivo proprietários de apps.

  Se as implementações de dispositivos declararem android.software.device_admin, mas também incluem um modelo Proprietário do dispositivo de gerenciamento de dispositivos móveis e fornecer um mecanismo promover um aplicativo configurado na solução como "Proprietário do dispositivo" equivalente" para "Proprietário do dispositivo" padrão, reconhecida pela norma Android DevicePolicyManager APIs, eles:

  • [C-2-1] PRECISA ter um processo para verificar se um determinado app promovida pertence a um sistema legítimo de gerenciamento e tenha sido configurado na solução proprietária ter os direitos equivalentes como "Proprietário do dispositivo".
  • [C-2-2] PRECISA mostrar a mesma declaração de consentimento do proprietário do dispositivo AOSP que a fluxo iniciado por android.app.action.PROVISION_MANAGED_DEVICE antes de registrar o aplicativo DPC como "Proprietário do dispositivo".
  • [C-2-3] NÃO PODE codificar o consentimento nem impedir o uso de outros apps do proprietário do dispositivo.
  • PODEM ter dados do usuário no dispositivo antes do registro do aplicativo DPC como "Proprietário do dispositivo".

• 3.9.4 Requisitos do papel "Gerenciamento de dispositivos": Adicionamos uma seção sobre os requisitos da função "Gerenciamento de dispositivos".

  Ver revisão

  3.9.4 Requisitos do papel de gerenciamento 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 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:

  Encerrar novos requisitos

• 3.18 Contatos: como adicionar informações para novos contatos.

  Ver revisão

  Conta padrão para novos contatos:o Provedor de contatos fornece APIs para gerenciar a configuração da conta padrão ao criar um novo contato.

  Se as implementações do dispositivo pré-carregarem um app de contatos, os contatos pré-carregados aplicativo:

  • [C-2-1] PRECISA processar a intent ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT para iniciar uma interface seleção de conta e salvar a configuração no Provedor de contatos quando uma conta for selecionados.

  • [C-2-2] PRECISA respeitar a configuração de conta padrão ao lidar com Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT para o ContactsContracts.Contacts.CONTENT_TYPE e ContactsContract.RawContacts.CONTENT_TYPE selecionando inicialmente o do Compute Engine.

  Encerrar novos requisitos

4. Compatibilidade com empacotamento de aplicativos

• 4. Compatibilidade de empacotamento de aplicativos: Atualizações na versão do esquema de assinatura de APK.

  Ver revisão

  Implementações de dispositivos:

  • [C-0-2] PRECISA ser compatível com a verificação de arquivos ".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-9] PRECISA ser compatível com a 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

• 5.1.2 Decodificação de áudio: adicionamos novos requisitos para decodificadores capazes de produzir áudio com vários canais.

  Ver revisão

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

  Encerrar novos requisitos

• 5.4.1 Informações brutas de captura de áudio e microfone: Atualizações das fontes de áudio compatíveis com streams de entrada de áudio.

  Ver revisão

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

  • [C-1-1] PRECISA permitir a captura de conteúdo de áudio bruto com as seguintes características para qualquer AudioRecord ou AAudio INPUT que foi aberto. No mínimo, os 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.
    • [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() API, para AudioRecord ativo usando MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED ou VOICE_PERFORMANCE. e os microfones ativos no momento, que são acessíveis para o terceiro aplicativos de terceiros por meio do AudioRecord.getActiveMicrophones() e MediaRecorder.getActiveMicrophones() APIs.

• 5.4.2 Captura para reconhecimento de voz: Requisitos atualizados para o stream de áudio de reconhecimento de voz e outros requisitos para os níveis de ganho do microfone.

  Ver revisão

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

  • DEVE gravar o stream de áudio de reconhecimento de voz com aproximadamente características de amplitude em relação à frequência: especificamente, ±3 dB, a partir de 100 Hz para 4.000 Hz.
  • DEVE gravar o stream de áudio do reconhecimento de voz com a sensibilidade de entrada definida de modo que uma fonte de nível de potência do som (SPL) de 90 dB a 1.000 Hz produza um RMS de 2500 para amostras de 16 bits.

  • 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] É 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] É 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.

  Encerrar novos requisitos

• 5.4.6 Níveis de ganho do microfone: Os requisitos dos níveis de ganho de microfone foram movidos para a seção 5.4.2.

  Ver revisão

  5.4.6. Níveis de ganho do microfone [migrado para 5.4.2]

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

  • DEVE exibir amplitude versus frequência aproximadamente plana características na faixa média de frequência: especificamente ±3 dB de 100 Hz a 4.000 Hz para cada microfone usado para gravar a voz fonte de áudio de reconhecimento de marca.
  • [C-SR] É MUITO RECOMENDADO a exibir níveis de amplitude em baixos intervalo de frequência: especificamente de ±20 dB de 5 Hz a 100 Hz em comparação faixa de média frequência de cada microfone usado para gravar a fonte de áudio do reconhecimento de voz.
  • [C-SR] é MUITO RECOMENDADO a exibir níveis de amplitude no faixa de alta frequência: especificamente de ±30 dB e 4.000 Hz a 22 KHz em comparação com o intervalo de frequência média de cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.
  • DEVE definir a sensibilidade da entrada de áudio de forma que um valor senoidal de 1.000 Hz a fonte de tons reproduzida a um Nível de pressão sonora (SPL, na sigla em inglês) de 90 dB emite uma resposta com RMS de 2.500 para amostras de 16 bits (ou escala total de -22,35 dB para flutuantes amostras de ponto/precisão dupla) para cada microfone usado para gravar a fonte de áudio do reconhecimento de voz.

• 5.5.4 Descarregamento de áudio: Atualizações nos requisitos de reprodução de descarregamento de áudio.

  Ver revisão

  Se as implementações de dispositivos forem compatíveis com a reprodução de descarregamento de áudio, elas:

  • [C-SR] É ALTAMENTE RECOMENDADO para cortar o conteúdo de áudio reproduzido sem lacunas entre dois clipes com o mesmo formato quando especificado pelo API sem lacunas do AudioTrack e o contêiner de mídia do MediaPlayer.

• 5.6 Latência de áudio: Atualizações nos requisitos de latência de áudio.

  Ver revisão

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

  • instabilidade na saída a frio. A variabilidade entre medições separadas de frio e os valores de latência de saída.
  • instabilidade de entrada a frio. A variabilidade entre medições separadas de frio e os valores de latência de entrada.

  Se as implementações de dispositivos declararem android.hardware.audio.output, elas PRECISA atender ou exceder os seguintes requisitos:

  • [C-1-2] Latência de saída de frio de 500 milissegundos ou menos.
  • [C-1-3] Abrir um stream de saída usando AAudioStreamBuilder_openStream() PRECISA levar menos de 1.000 milissegundos.

  Se as implementações de dispositivos declararem android.hardware.audio.output, elas serão É RECOMENDADO atender ou superar os seguintes requisitos:

  • [C-SR] Latência de saída fria de 100 milissegundos ou menos nos dados dos alto-falantes caminho. Os dispositivos novos e existentes que executam essa versão do Android são MUITO RECOMENDADO VOLTAR a cumprir esses requisitos agora. Em uma plataforma futura será necessária uma latência de frio de 200 ms ou menos como OBRIGATÓRIO.
  • [C-SR] Minimizar a instabilidade da saída a frio.

  Se as implementações de dispositivos incluírem android.hardware.microphone, elas PRECISA atender a estes requisitos de áudio de entrada:

  • [C-3-2] Latência de entrada de frio de 500 milissegundos ou menos.
  • [C-3-3] Abrir um stream de entrada usando AAudioStreamBuilder_openStream() PRECISA levar menos de 1.000 milissegundos.

  Se as implementações de dispositivos incluírem android.hardware.microphone, elas serão É RECOMENDADO atender a estes requisitos de entrada de áudio:

  • [C-SR] Latência de entrada a frio de 100 milissegundos ou menos pelo microfone caminho dos dados. Dispositivos novos e existentes que são executados nesta versão do Android estão É MUITO RECOMENDADO atender a esses requisitos. Em um futuro exigimos uma latência de entrada a frio de 200 ms ou menos, um OBRIGATÓRIO.

  • [C-SR] Latência de entrada contínua de 30 milissegundos ou menos.
  • [C-SR] Minimize a instabilidade da entrada a frio.

• 5.10 Áudio profissional: Atualizações dos requisitos de latência de áudio para suporte profissional de áudio.

  Ver revisão

  Se as implementações de dispositivos relatarem compatibilidade com o recurso android.hardware.audio.pro pelo android.content.pm.PackageManager , ela:

  • [C-1-2] PRECISA ter a latência de ida e volta contínua do áudio, conforme definido em seção 5.6 Latência de áudio de 25 milissegundos ou menos e DEVE ter 10 milissegundos ou menos em pelo menos um caminho compatível.
  • [C-1-5] PRECISA atender aos requisitos de latência e áudio USB usando o Áudio nativo AAudio API e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
  • [C-1-8] PRECISA ter uma latência média entre toques. de 80 milissegundos ou menos em pelo menos 5 medições pelo alto-falante para o caminho de dados do microfone.
  • [C-SR] É MUITO RECOMENDADO que você ofereça um nível consistente de CPU desempenho enquanto o áudio está ativo e a carga da CPU varia. Isso deve ser testado usando o app Android SynthMark. O SynthMark usa um sintetizador de software executado em um framework de áudio simulado que mede o desempenho do sistema. Consulte Documentação do SynthMark para conferir uma explicação sobre os comparativos de mercado. SynthMark precisa ser executado usando o a opção de "Teste automatizado" e obter os seguintes resultados: * voicemark.90 >= 32 vozes * latemark.Fixed.little <= 15 ms * latênciamark.dynamic.little <= 50 ms
  • DEVE ter latência desde a entrada por toque até a entrada de áudio de saída menor ou igual a 40 ms.

  Se as implementações do dispositivo incluírem uma entrada para fone de ouvido de 3,5 mm com quatro condutores, elas:

  • [C-2-1] PRECISA ter uma latência média contínua de áudio de ida e volta, conforme definido em seção 5.6 Latência de áudio, de 20 milissegundos ou menos, mais de 5 medições com desvio absoluto médio inferior a 5 milissegundos o caminho da entrada de áudio usando uma dongle de loopback de áudio.

• Vídeo em HDR 5.12: Adicionamos uma nova seção para requisitos de vídeo em HDR.

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

• 6.1 Ferramentas para Desenvolvedores: Atualizações nos requisitos de conectividade e do kernel da GPU.

  Ver revisão

  Se as implementações de dispositivos oferecerem suporte a conexões adb com uma máquina host via Wi-Fi ou Ethernet:

  • [C-4-1] PRECISA ter o método AdbManager#isAdbWifiSupported(). retornar true.

  Se as implementações de dispositivos oferecerem suporte a conexões adb com uma máquina host via Wi-Fi ou Ethernet inclui pelo menos uma câmera, eles:

  • [C-5-1] PRECISA ter o método AdbManager#isAdbWifiQrSupported(). retornar true.

  • Informações de trabalho da GPU

    Implementações de dispositivos:

    • [C-6-1] PRECISA 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/.

  Encerrar novos requisitos

7. Compatibilidade de hardware

• 7.1.4.1 OpenGL ES: atualização às extensões recomendadas.

  Ver revisão

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

  • DEVE oferecer suporte aos EGL_IMG_context_priority e EGL_EXT_protected_content extensão.

  Encerrar novos requisitos

• 7.1.4.2 Vulkan: atualizações no compatível com o Vulkan.

  Ver revisão

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

  • [SR] É FORTEMENTE RECOMENDADO incluir suporte para Vulkan 1.3 Vulkan 1.1 (link em inglês)
  • NÃO PODE oferecer suporte a uma versão de variante do Vulkan (ou seja, a parte variante do A 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:

  • [SR] É FORTEMENTE RECOMENDADO incluir suporte para Vulkan 1.3 Vulkan 1.1 (link em inglês)

  Se as implementações de dispositivos incluírem suporte ao Vulkan 1.0 ou mais recente, elas:

  • DEVE oferecer suporte VkPhysicalDeviceProtectedMemoryFeatures e VK_EXT_global_priority.
  • [C-1-12] NÃO PODE enumerar o suporte para o extensão VK_KHR_performance_query.
  • [C-SR] É FORTEMENTE RECOMENDADO para atender aos requisitos especificados pelo perfil de referência do Android 2021.

• 7.2.3 Teclas de navegação:

  Ver revisão

  Implementações de dispositivos:

  • [C-SR] É FORTEMENTE RECOMENDADO que forneça todas as funções de navegação como 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.

  Encerrar novos requisitos

  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.

  Encerrar novos requisitos

• 7.3.1 Acelerômetro: Atualizações nos requisitos de sensores para acelerômetros.

  Ver revisão

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

  • [C-1-2] PRECISA implementar e informar TYPE_ACCELEROMETER sensor.
  • [SR] é altamente RECOMENDADO para implementar a Sensor composto TYPE_SIGNIFICANT_MOTION.
  • [SR] é MUITO RECOMENDADO para implementar e relatório TYPE_ACCELEROMETER_UNCALIBRATED sensor Os dispositivos Android são MUITO RECOMENDADOS para atender a esse requisito. poderão fazer upgrade para uma versão futura da plataforma, em que é possível se tornar REQUIRED.
  • DEVE implementar os TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER composto como descrito no documento do SDK do Android.

  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] É MUITO RECOMENDADO para implementar a TYPE_SIGNIFICANT_MOTION sensor composto.
  • [C-SR] É MUITO 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] São STRONGLY_RECOMMENDED para implementar e informar Sensor TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

  Encerrar novos requisitos

  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.

  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 os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.

  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 uma Sensor composto TYPE_ROTATION_VECTOR.

• 7.3.4 Giroscópios: atualizações aos requisitos de sensores para giroscópios.

  Ver revisão

  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] O erro de calibragem é FORTEMENTE RECOMENDADO ser menor que 0,01 rad/s quando o dispositivo está parado em temperatura ambiente.
  • [C-SR] É MUITO RECOMENDADO ter uma resolução de 16 bits ou mais.
  • DEVE relatar eventos de até pelo menos 200 Hz.

  Encerrar novos requisitos

  Se as implementações de dispositivos incluem um giroscópio de três eixos, eles:

  • [C-2-1] PRECISA implementar o sensor TYPE_GYROSCOPE.

  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] São STRONGLY_RECOMMENDED para implementar e informar Sensor TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

  Encerrar novos requisitos

  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 uma 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 os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.

• 7.3.10 Sensores biométricos: Atualizações nos requisitos para sensores biométricos.

  Ver revisão

  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 outras conforme detalhado abaixo, se quiserem ser classificados Classe 1, Classe 2 ou Classe 3. Os sensores são classificados como Classe 1 por padrão e precisam para atender aos requisitos adicionais, conforme detalhado abaixo, caso queiram ser classificados como Classe 2 ou Classe 3. Classe 2 e Classe 3 biometria têm outros recursos, conforme detalhado abaixo.

  Se as implementações de dispositivos quiserem tratar um sensor biométrico como Classe 1 (anteriormente Conveniência), eles:

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

  Encerrar novos requisitos

  Se as implementações de dispositivos quiserem tratar um sensor biométrico como Classe 2 (link em inglês) (anteriormente fraco), eles:

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

  Se as implementações de dispositivos quiserem tratar um sensor biométrico como Classe 3 (link em inglês) (anteriormente Forte), eles:

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

• 7.3.13 IEEE 802.1.15.4 (UWB): Adicionamos uma nova seção de requisitos para UWB.

  Ver revisão

  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-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-1-6] São RECOMENDADOS para passar na conformidade e de certificação definidos por organizações padrão, incluindo FIRA e CCC e CSA.

  Encerrar novos requisitos

• 7.4.1 Telefonia: atualizações atender aos requisitos de telefonia para telefonia GSM e CDMA e uso de redes celulares; configurações.

  Ver revisão

  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. oferecem uma implementação completa do EuiccManager API.

  Se as implementações de dispositivos incluírem telefonia GSM ou CDMA:

  • [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 de dispositivos incluírem telefonia GSM ou CDMA e fornecerem uma barra de status do sistema, então:

  • [C-6-7] É 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] É FORTEMENTE RECOMENDADO que a assinatura do representante 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 incluírem telefonia GSM ou CDMA:

  • [C-6-8] 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-10] NÃO É POSSÍVEL aplicar nenhum dos seguintes comportamentos a apps de operadoras ativas (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 incluem telefonia GSM ou CDMA e todas as ativo, 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-7-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-8-1] NÃO PODE declarar PackageManager#FEATURE_TELEPHONY_CDMA.
  • [C-8-2] É NECESSÁRIO gerar uma IllegalArgumentException quando há tentativas de definir Tipos de rede 3GPP2 em bitmasks de tipo de rede preferencial ou permitido.
  • [C-8-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-11-1] PRECISA declarar android.hardware.telephony.euicc.mep flag de recurso.

  Encerrar novos requisitos

• 7.4.1.1 Compatibilidade do bloqueio de números: Atualizações nos requisitos de bloqueio de números.

  Ver revisão

  Se as implementações de dispositivos informarem o android.hardware.telephony feature, eles:

  • [C-1-4] NÃO PODE gravar no provedor de registro de chamadas da plataforma para uma chamada bloqueada.

  • [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.
  • DEVE fornecer uma funcionalidade de usuário para mostrar chamadas bloqueadas no de telefone.

  Encerrar novos requisitos

• 7.4.1.3 Descarregamento de sinal de atividade NAT-T da rede celular: nova seção para rede celular. Descarregamento de sinal de atividade NAT-T.

  Ver revisão

  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] É FORTEMENTE RECOMENDADO 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.

  Encerrar novos requisitos

• 7.4.2.5 Local do Wi-Fi (tempo de retorno do Wi-Fi – RTT): Atualizações na precisão de local do Wi-Fi.

  Ver revisão

  Se as implementações do dispositivo incluem suporte à localização por Wi-Fi e expõem a a aplicativos de terceiros, elas:

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

  Encerrar novos requisitos

• 7.4.2.6 Descarga de sinal de atividade Wi-Fi: Atualização para adicionar requisitos de descarregamento de sinal de atividade da rede celular.

  Ver revisão

  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
    e pelo menos um slot de sinal de atividade pela rede celular.

  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.9 Confiança no primeiro uso (TOFU): Adicionamos a seção de requisitos de Confiança no primeiro uso.

  Ver revisão

  7.4.2.9 Confiança no primeiro uso (TOFU)

  Se as implementações de dispositivos oferecerem suporte à confiabilidade no primeiro uso (TOFU) e permitirem que defina as configurações WPA/WPA2/WPA3-Enterprise, então ele:

  • [C-4-1] PRECISA oferecer ao usuário a opção de usar o TOFU.

  Encerrar novos requisitos

• 7.4.3 Bluetooth: atualizar para Requisitos de Bluetooth.

  Ver revisão

  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) com A2DP.

  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] É MUITO 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 entre si por 95% do medições.
  • [C-SR] É 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] É 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 da medição especificadas nos Requisitos para a calibragem de presença.

  Se as implementações de dispositivos forem compatíveis com o Bluetooth versão 5.0, elas:

  • [C-SR] É FORTEMENTE RECOMENDADO oferecer suporte para:
    • LE 2M PHY
    • Codec LE PHY
    • Extensão de publicidade LE
    • Publicidade periódica
    • Pelo menos 10 conjuntos de anúncios
    • Pelo menos oito conexões simultâneas do LE. Cada conexão pode estar e papéis de topologia de conexão.
    • Privacidade da camada de links do LE
    • Uma "lista de resolução" de pelo menos oito entradas

  Encerrar novos requisitos

• 7.4.9 UWB: requisitos adicionados para hardware UWB.

  Ver revisão

  7.4.9. UWB

  Se as implementações de dispositivos relatarem compatibilidade com o recurso android.hardware.uwb por meio do android.content.pm.PackageManager da turma, eles:

  • [C-1-1] 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-2] PRECISA garantir que a mediana das medições 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 a distância é medida a partir da borda superior do DUT voltado para cima e inclinado 45 graus.

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

  Encerrar novos requisitos

• 7.5 Câmeras: atualizações na para a capacidade de saída HDR de 10 bits.

  Ver revisão

  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 HDR HLG 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 pela câmera frontal principal.
  • [C-SR] É 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.

  Encerrar novos requisitos

• 7.7.2 Modo host USB: Revisões para portas de função dupla.

  Ver revisão

  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 Dual 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á-la.

• 7.11 Classe de desempenho de mídia: Atualização para incluir o Android T.

  Ver revisão

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

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

  Encerrar novos requisitos

  Consulte a seção 2.2.7 para requisitos específicos do dispositivo.

9. Compatibilidade do modelo de segurança

• 9.1 Permissões: estender caminhos aceitos para listas de permissões de apps pré-instalados para arquivos APEX.

  Ver revisão

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

• 9.7 Recursos de Segurança: Atualizações nos requisitos de inicialização para manter a integridade do kernel.

  Ver revisão

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

  • [C-SR] É MUITO RECOMENDADO permitir a inicialização de pilhas no kernel para impede 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 presumir o valor usado pelo compilador para inicializar os locais.

  Encerrar novos requisitos

• 9.8.7 Privacidade: acesso à área de transferência: Limpar automaticamente os dados da área de transferência após 60 minutos após recortar/copiar/colar para proteger a privacidade do usuário.

  Ver revisão

  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 API), 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 interação colocado em uma área de transferência ou lido de uma área de transferência.

• 9.11 Chaves e credenciais: Atualizações nos requisitos de segurança da tela de bloqueio, incluindo o adição de ECDH e 3DES a algoritmos de criptografia.

  Ver revisão

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

  • [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, SHA1 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 .

• 9.11.1 Tela de bloqueio segura, autenticação e dispositivos virtuais: Adição de uma seção de requisitos para dispositivos virtuais e transferências de autenticação.

  Ver revisão

  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-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 ao requisitos para implementações do TrustAgent em C-X, restrições de tempo limite definidos em C-9-5 são aplicados no lugar.

  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 dão suporte a eventos de entrada associados, como via 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.
  • [C-10-6] PRECISA desativar a criação de eventos de entrada associados usando VirtualDeviceManager quando indicado por DevicePolicyManager.setNearbyAppStreamingPolicy
  • [C-10-7] PRECISA usar uma área de transferência separada apenas para cada dispositivo virtual. (ou desativar a área de transferência para dispositivos virtuais)
  • [C-10-11] PRECISA desativar a interface de autenticação em dispositivos virtuais, incluindo: entrada de fator de conhecimento e solicitação biométrica
  • [C-10-12] PRECISA restringir intents iniciadas por um dispositivo virtual para exibição apenas no mesmo dispositivo virtual
  • [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*:

  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() após no máximo 24 horas a partir da concessão de confiança, uma janela de inatividade de 8 horas ou quando a conexão com o dispositivo físico próximo é perdida.

  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 definido como falso na inicialização do dispositivo virtual.
  • [C-13-9] PRECISA bloquear atividades. que não ativam explicitamente o streaming e que indicam que eles mostram conteúdo sensível, inclusive via SurfaceView#setSecure, FLAG_SECURE ou SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS sejam iniciado no dispositivo virtual.
  • [C-13-10] PRECISA desativar a instalação de apps iniciados em dispositivos virtuais.

  Encerrar novos requisitos

• 9.11.2 Strongbox: criação a resistência a ataques de pessoas com informações privilegiadas (IAR, na sigla em inglês) é um requisito necessário.

  Ver revisão

  Para validar a conformidade com [C-1-3] a [C-1-9], as implementações de dispositivos:

  • [C-SR] é FORTEMENTE RECOMENDADO a fornecer resistência a ataques de pessoas com informações privilegiadas (IAR), o que significa que uma com acesso a chaves de assinatura de firmware, não pode produzir um firmware faz com que o StrongBox vaze segredos para contornar a segurança funcional ou permitir o acesso a dados sensíveis de usuários. O recomendada de implementar a IAR é permitir atualizações de firmware apenas quando a senha principal do usuário é fornecida pela HAL IAuthSecret. A IAR se tornará um requisito OBRIGATÓRIO em Android 14.

• 9.11.3 Credencial de identidade: Adicionamos informações sobre a implementação de referência do sistema de credenciais de identidade.

  Ver revisão

  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:

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

  Encerrar novos requisitos

• 9.11.4 Atestado de ID: Adicionamos uma seção para o requisito de atestado de ID.

  Ver revisão

  9.11.4. Atestado de ID

  As implementações de dispositivos PRECISAM oferecer suporte ao atestado de IDs.

  Encerrar novos requisitos

• 9.17 Framework de virtualização do Android: Adicionamos uma seção de requisitos para o Framework de virtualização do Android.

  Ver revisão

  9,17 Framework de virtualização do Android

  Se o dispositivo implementar suporte para as APIs do Framework de virtualização do Android (android.system.virtualmachine.*), o host do Android:

  • [C-1-1] PRECISA oferecer suporte a todas as APIs definidas pelos android.system.virtualmachine.*.
  • [C-1-2] NÃO PODE modificar o SELinux do Android e o modelo de permissão da gerenciamento de máquinas virtuais protegidas.
  • [C-1-3] NÃO PODE modificar, omitir ou substituir as regras de nunca permitir presentes em a system/sepolicy fornecida no Android Open Source Project upstream (AOSP) e a política PRECISA ser compilada com todas as regras de "proibição" presentes.
  • [C-1-4] NÃO É POSSÍVEL permitir que códigos não confiáveis (por exemplo, apps de terceiros) criem e executem uma Máquina virtual protegida. Observação: isso pode mudar em versões futuras do Android.
  • [C-1-5] NÃO PODE permitir que uma máquina virtual protegida execute um código que não está não fazem parte da imagem de fábrica ou de suas atualizações. Tudo o que não estiver coberto pela Inicialização verificada do Android (por exemplo, arquivos baixados da Internet ou transferidos por sideload) NÃO PODEM ser executados em uma máquina virtual protegida.

  Se o dispositivo implementar suporte para as APIs do Framework de virtualização do Android (android.system.virtualmachine.*), qualquer instância de máquina virtual protegida:

  • [C-2-1] PRECISA executar todos os sistemas operacionais disponíveis no virtualização APEX em uma máquina virtual protegida.
  • [C-2-2] NÃO PODE permitir que uma máquina virtual protegida execute um sistema operacional que não seja assinado pelo implementador do dispositivo ou pelo fornecedor do SO.
  • [C-2-3] NÃO PODE permitir que uma máquina virtual protegida execute dados como código (por exemplo, SELinux nunca permite execmem).
  • [C-2-4] NÃO PODE modificar, omitir ou substituir as regras de nunca permitir presentes em o system/sepolicy/microdroide fornecido no Android Open Source AOSP.
  • [C-2-5] PRECISA implementar mecanismos de defesa em profundidade de máquinas virtuais protegidas. (por exemplo, SELinux para pVMs), mesmo para sistemas operacionais não Microdroid.
  • [C-2-6] PRECISA garantir que o firmware da pVM se recuse a inicializar se não for possível fazer a verificação. a imagem inicial.
  • [C-2-7] PRECISA garantir que o firmware da pVM se recuse à inicialização se a integridade da a instância.img for comprometido.

  Se o dispositivo implementar suporte para as APIs do Framework de virtualização do Android (android.system.virtualmachine.*), o hipervisor:

  • [C-3-1] NÃO PODE permitir que uma pVM tenha acesso a uma página que pertença a outra. entidade (ou seja, outra pVM ou hipervisor), a menos que seja explicitamente compartilhada pela página proprietário. Isso inclui a VM do host. Isso se aplica a acessos de CPU e DMA.
  • [C-3-2] PRECISA excluir permanentemente uma página depois que ela for usada por uma VM e antes que ela seja retornada ao host (por exemplo, a pVM é destruída).
  • [C-3-3] PRECISA garantir que o firmware da pVM seja carregado e executado antes qualquer código em uma pVM.
  • [C-3-4] PRECISA garantir que o BCC e os CDIs fornecidos a uma instância de pVM só possam ser derivadas por essa instância específica.

  Se o dispositivo implementar suporte para as APIs do Framework de virtualização do Android, depois em todas as áreas:

  • [C-4-1] NÃO PODE fornecer funcionalidade a uma pVM que permita ignorar o Modelo de segurança do Android.

  Se o dispositivo implementar suporte para as APIs do Framework de virtualização do Android:

  • [C-5-1] PRECISA oferecer suporte à compilação isolada de uma atualização do tempo de execução do ART.

  Se o dispositivo implementar suporte para as APIs do framework de virtualização do Android, para o gerenciamento de chaves:

  • [C-6-1] PRECISA codificar a cadeia do DICE em um ponto que o usuário não pode modificar, mesmo e dispositivos desbloqueados. Para garantir que não seja falsificado.
  • [C-6-2] PRECISA usar o DICE corretamente, ou seja, fornecer os valores corretos. Mas pode não ter que acessar esse nível de detalhes.

  Encerrar novos requisitos

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.