Andróide 14
20 de novembro de 2023
2. Tipos de dispositivos
Ver revisão
Se as implementações de dispositivos portáteis declararem suporte a qualquer ABI de 64 bits (com ou sem qualquer ABI de 32 bits):
Ver revisão
- [ 7.5 /H-1-13] DEVE suportar o recurso
LOGICAL_MULTI_CAMERA
para a câmera traseira principal se houver mais de 1 câmera traseira RGB.
- [ 7.5 /H-1-13] DEVE suportar o recurso
Ver revisão
[ 5.8 /T-0-1] DEVE definir o modo de saída HDMI para a resolução mais alta para o formato SDR ou HDR escolhido que funcione com taxa de atualização de 50 Hz ou 60 Hz para o monitor externo.
DEVE definir o modo de saída HDMI para selecionar a resolução máxima que pode ser suportada com uma taxa de atualização de 50 Hz ou 60 Hz.
Ver revisão
- [9/W-0-1] DEVE declarar o
android.hardware.security.model.compatible feature
.
- [9/W-0-1] DEVE declarar o
6. Compatibilidade com ferramentas e opções do desenvolvedor
6.1. Ferramentas de desenvolvimento :
Ver revisão
- [C-0-12] DEVE escrever um átomo
LMK_KILL_OCCURRED_FIELD_NUMBER
no
Ver revisão
- [C-0-13] DEVE implementar o comando shell
dumpsys gpu --gpuwork
para exibir
- [C-0-12] DEVE escrever um átomo
9. Compatibilidade do modelo de segurança
Ver revisão
Se as implementações de dispositivos usarem um kernel Linux capaz de suportar SELinux, elas:
Ver revisão
Se as implementações de dispositivos usarem um kernel diferente do Linux ou Linux sem SELinux, elas:
4 de outubro de 2023
2. Tipos de dispositivos
Ver revisão
As implementações de dispositivos Android são classificadas como portáteis se atenderem a todos os critérios a seguir:
- Ter um tamanho de tela diagonal física na faixa de 4 polegadas
e 3,3 polegadas (ou 2,5 polegadas para implementações de dispositivos fornecidos no nível API 29 ou anterior)a 8 polegadas.
Iniciar novos requisitos
- Possui uma interface de entrada touchscreen.
- Ter um tamanho de tela diagonal física na faixa de 4 polegadas
Ver revisão
Implementações de dispositivos portáteis:
- [ 7.1 .1.1/H-0-1] DEVE ter pelo menos um
monitor compatível com Android que atenda a todos os requisitos descritos neste documento.tela que mede pelo menos 2,2” na borda curta e 3,4” na borda longa.
Se as implementações de dispositivos portáteis suportarem rotação de tela de software, elas:
- [ 7.1 .1.1/H-1-1]* DEVE fazer com que a tela lógica disponibilizada para aplicativos de terceiros tenha pelo menos 2 polegadas na(s) borda(s) curta(s) e 2,7 polegadas na(s) borda(s) longa(s). Dispositivos fornecidos com Android API de nível 29 ou anterior PODEM estar isentos deste requisito.
Se as implementações de dispositivos portáteis não suportarem a rotação de tela do software, elas:
- [ 7.1 .1.1/H-2-1]* DEVE fazer com que a tela lógica disponibilizada para aplicativos de terceiros tenha pelo menos 2,7 polegadas na(s) borda(s) curta(s). Dispositivos fornecidos com Android API de nível 29 ou anterior PODEM estar isentos deste requisito.
Iniciar novos requisitos
[ 7.1 .1.1/H-0-3]* DEVE mapear cada display
UI_MODE_NORMAL
disponibilizado para aplicativos de terceiros em uma área de exibição física desobstruída que tenha pelo menos 2,2" polegadas na borda curta e 3,4" polegadas na borda longa.[ 7.1 .1.3/H-0-1]* DEVE definir o valor de
DENSITY_DEVICE_STABLE
como 92% ou maior que a densidade física real do display correspondente.
Se as implementações de dispositivos portáteis declararem
android.hardware.audio.output
eandroid.hardware.microphone
, elas:[ 5.6 /H-1-1] DEVE ter uma latência média contínua de ida e volta de 300 milissegundos ou menos em 5 medições, com um desvio médio absoluto inferior a 30 ms , nos seguintes caminhos de dados: "alto-falante para microfone", 3,5 mm adaptador de loopback (se compatível), loopback USB (se compatível).
[ 5.6 /H-1-2] DEVE ter uma latência média Tap-to-tone de 300 milissegundos ou menos em pelo menos 5 medições no caminho de dados do alto-falante para o 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 um atuador háptico (vibrador) de massa rotativa excêntrica (ERM).
- [ 7.10 /H] * DEVE implementar todas as constantes públicas para uma sensação tátil clara em android.view.HapticFeedbackConstants , nomeadamente (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 uma sensação tátil clara em Android.os.VibrationEffect , ou seja, (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK e EFFECT_DOUBLE_CLICK) e todas as constantes
PRIMITIVE_*
públicas viáveis para uma sensação tátil rica em Android.os.VibrationEffect.Composition , ou seja, ( CLIQUE, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Algumas dessas primitivas, como LOW_TICK e SPIN, só podem ser viáveis se o vibrador puder suportar frequências relativamente baixas. - [7.10/H]* DEVE seguir as orientações para mapear constantes públicas em android.view.HapticFeedbackConstants para as constantes android.os.VibrationEffect recomendadas, com as relações de amplitude correspondentes.
- [ 7.10 /H]* DEVE seguir a avaliação de qualidade para APIs createOneShot() e createWaveform() .
- [ 7.10 /H]* DEVE verificar se o resultado da API pública android.os.Vibrator.hasAmplitudeControl() reflete corretamente as capacidades do vibrador.
- [ 7.10 /H]* DEVE posicionar o atuador próximo ao local onde o dispositivo normalmente é segurado ou tocado pelas mãos.
Se as implementações de dispositivos portáteis incluírem pelo menos um atuador ressonante linear 7.10 de uso geral , elas:
- [ 7.10 /H] DEVE posicionar o atuador próximo ao local onde o dispositivo normalmente é segurado ou tocado pelas mãos.
- [ 7.10 /H] DEVE mover o atuador háptico no eixo X (esquerda-direita) da orientação
retratonatural do dispositivo .
Se as implementações de dispositivos portáteis tiverem um atuador háptico de uso geral que seja um atuador ressonante linear do eixo X (LRA), elas:
- [ 7.10 /H] DEVE ter a frequência de ressonância do LRA do eixo X abaixo de 200 Hz.
- [ 7.1 .1.1/H-0-1] DEVE ter pelo menos um
Ver revisão
As implementações de dispositivos portáteis DEVEM suportar os seguintes formatos de codificação de vídeo e disponibilizá-los para aplicativos de terceiros:
- [ 5.2 /H-0-3] AV1
As implementações de dispositivos portáteis DEVEM suportar os seguintes formatos de decodificação de vídeo e disponibilizá-los para aplicativos de terceiros:
- [ 5.3 /H-0-6] AV1
Ver revisão
Se as implementações do dispositivo, incluindo a tecla de navegação da função recente, conforme detalhado na seção 7.2.3 , alterarem a interface, elas:
- [ 3.8.3 /H-1-1] DEVE implementar o comportamento de fixação de tela e fornecer ao usuário um menu de configurações para alternar o recurso.
Se as implementações de dispositivos portáteis incluírem suporte para APIs
ControlsProviderService
eControl
e permitirem que aplicativos de terceiros publiquem controles de dispositivos , então elas:- [ 3.8.16 /H-1-6] As implementações de dispositivos DEVEM renderizar com precisão a capacidade do usuário da seguinte forma:
- Se o dispositivo tiver definido
config_supportsMultiWindow=true
e o aplicativo declarar os metadadosMETA_DATA_PANEL_ACTIVITY
na declaraçãoControlsProviderService
, incluindo o ComponentName de uma atividade válida (conforme definido pela API), o aplicativo DEVE incorporar essa atividade nesta capacidade do usuário. - Se o aplicativo não declarar metadados
META_DATA_PANEL_ACTIVITY
, ele DEVE renderizar os campos especificados conforme fornecidos pela APIControlsProviderService
, bem como quaisquer campos especificados fornecidos pelas APIs de controle .
- Se o dispositivo tiver definido
- [ 3.8.16 /H-1-7] Se o aplicativo declarar os metadados
META_DATA_PANEL_ACTIVITY
, ele DEVE passar o valor da configuração definida em [3.8.16/H-1-5] usandoEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS
ao iniciar a atividade incorporada.
Se as implementações de dispositivos permitirem que os usuários façam chamadas de qualquer tipo, elas
- [ 7.4.1.2 /H-0-1] DEVE declarar o sinalizador de recurso
android.software.telecom
. - [ 7.4.1.2 /H-0-2] DEVE implementar a estrutura de telecomunicações .
2.2.4. Desempenho e potência :
Ver revisão
Implementações de dispositivos portáteis:
- [ 8.5 /H-0-1] DEVE fornecer uma capacidade de usuário
no menu Configuraçõespara ver todos os aplicativos com serviços ativos em primeiro plano ou trabalhos iniciados pelo usuário, incluindo a duração de cada um desses serviços desde que foi iniciado, conforme descrito no documento SDK .e a capacidade de interromper um aplicativo que esteja executando um serviço em primeiro plano ou um trabalho iniciado pelo usuário.com a capacidade de interromper um aplicativo que esteja executando um serviço em primeiro plano e exibir todos os aplicativos que possuem serviços em primeiro plano ativos e a duração de cada um desses serviços desde que foi iniciado, conforme descrito no documento do SDK .- Alguns aplicativos PODEM ser isentos de serem interrompidos ou listados em recursos de usuário, conforme descrito no documento do SDK .
- [ 8.5 /H-0-1] DEVE fornecer uma capacidade de usuário
- [ 8.5 /H-0-2]DEVE fornecer ao usuário uma oportunidade para interromper um aplicativo que esteja executando um serviço em primeiro plano ou um trabalho iniciado pelo usuário.
Ver revisão
Se as implementações de dispositivos declararem suporte para android.hardware.telephony
, elas:
- [ 9.5 /H-1-1] NÃO DEVE definir
UserManager.isHeadlessSystemUserMode
comotrue
.
Se as implementações de dispositivos tiverem uma tela de bloqueio segura e incluírem um ou mais agentes confiáveis, que implementam a API do sistema TrustAgentService
, elas:
- [ 9.11.1 /H-1-1] DEVE desafiar o usuário para um dos métodos de autenticação primários recomendados (por exemplo: PIN, padrão, senha) com mais frequência do que uma vez a cada 72 horas.
Se as implementações de dispositivos portáteis definirem UserManager.isHeadlessSystemUserMode
como true
, elas
Se as implementações de dispositivos portáteis suportarem a API do sistema HotwordDetectionService
ou outro mecanismo para detecção de hotword sem indicação de acesso ao microfone, elas:
- [9.8/H-1-1] DEVE garantir que o serviço de detecção de hotword só possa transmitir dados para o sistema,
ContentCaptureService
ou serviço de reconhecimento de fala no dispositivo criado porSpeechRecognizer#createOnDeviceSpeechRecognizer()
. - [9.8/H-1-6] NÃO DEVE permitir que mais de 100 bytes de dados (excluindo fluxos de áudio) sejam transmitidos para fora do serviço de detecção de hotword em cada resultado de hotword bem-sucedido.
- [9.8/H-1-15] DEVE garantir que os fluxos de áudio fornecidos em resultados de hotword bem-sucedidos sejam transmitidos unidirecionalmente do serviço de detecção de hotword para o serviço de interação de voz.
Se as implementações do dispositivo incluírem um aplicativo que usa a API do sistema HotwordDetectionService
ou um mecanismo semelhante para detecção de hotword sem indicação de uso do microfone, o aplicativo:
- [9.8/H-2-3] NÃO DEVE transmitir do serviço de detecção de hotword dados de áudio, dados que possam ser usados para reconstruir (total ou parcialmente) o áudio ou conteúdos de áudio não relacionados à hotword em si, exceto para o
ContentCaptureService
ou serviço de reconhecimento de fala no dispositivo.
Se as implementações de dispositivos portáteis suportarem a API do sistema VisualQueryDetectionService
ou outro mecanismo para detecção de consulta sem indicação de acesso de microfone e/ou câmera, elas:
- [9.8/H-3-1] DEVE garantir que o serviço de detecção de consulta só possa transmitir dados para o Sistema, ou
ContentCaptureService
, ou serviço de reconhecimento de fala no dispositivo (criado porSpeechRecognizer#createOnDeviceSpeechRecognizer()
). - [9.8/H-3-2] NÃO DEVE permitir que nenhuma informação de áudio ou vídeo seja transmitida para fora do
VisualQueryDetectionService
, exceto paraContentCaptureService
ou serviço de reconhecimento de fala no dispositivo. - [9.8/H-3-3] DEVE exibir um aviso ao usuário na UI do sistema quando o dispositivo detecta a intenção do usuário de interagir com o aplicativo Digital Assistant (por exemplo, detectando a presença do usuário por meio da câmera).
- [9.8/H-3-4] DEVE exibir um indicador de microfone e exibir a consulta do usuário detectada na UI logo após a consulta do usuário ser detectada.
- [9.8/H-3-5] NÃO DEVE permitir que um aplicativo instalável pelo usuário forneça o serviço de detecção de consulta visual.
2.2.7.1. Meios de comunicação :
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
, então elas:
- DEVE atender aos requisitos de mídia listados na seção 2.2.7.1 do CDD do Android 13 .
Iniciar novos requisitos
Se as implementações de dispositivos portáteis retornaremandroid.os.Build.VERSION_CODES.U
para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, então elas:- [5.1/H-1-1] DEVE anunciar o número máximo de sessões de decodificador de vídeo de hardware que podem ser executadas simultaneamente em qualquer combinação de codec por meio dos métodos
CodecCapabilities.getMaxSupportedInstances()
eVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-2] DEVE suportar 6 instâncias de sessões de decodificador de vídeo de hardware de 8 bits (SDR) (AVC, HEVC, VP9, AV1 ou posterior) em qualquer combinação de codec em execução simultaneamente com 3 sessões com resolução de 1080p a 30 fps e 3 sessões com resolução 4k a 30fps, a menos que AV1. Os codecs AV1 são necessários apenas para oferecer suporte à resolução de 1080p, mas ainda são necessários para oferecer suporte a 6 instâncias a 1080p30fps.
- [5.1/H-1-3] DEVE anunciar o número máximo de sessões de codificador de vídeo de hardware que podem ser executadas simultaneamente em qualquer combinação de codec por meio dos métodos
CodecCapabilities.getMaxSupportedInstances()
eVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-4] DEVE suportar 6 instâncias de sessões de codificador de vídeo de hardware de 8 bits (SDR) (AVC, HEVC, VP9, AV1 ou posterior) em qualquer combinação de codec em execução simultaneamente com 4 sessões com resolução de 1080p a 30 fps e 2 sessões com resolução 4k a 30fps, a menos que AV1. Os codecs AV1 são necessários apenas para oferecer suporte à resolução de 1080p, mas ainda são necessários para oferecer suporte a 6 instâncias a 1080p30fps.
- [5.1/H-1-5] DEVE anunciar o número máximo de sessões de codificador e decodificador de vídeo de hardware que podem ser executadas simultaneamente em qualquer combinação de codec por meio dos métodos
CodecCapabilities.getMaxSupportedInstances()
eVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-6] DEVE suportar 6 instâncias de decodificador de vídeo de hardware de 8 bits (SDR) e sessões de codificador de vídeo de hardware (AVC, HEVC, VP9, AV1 ou posterior) em qualquer combinação de codec em execução simultaneamente com 3 sessões em 4K Resolução de @30fps (a menos que AV1), das quais no máximo 2 são sessões de codificador e 3 sessões com resolução de 1080p. Os codecs AV1 são necessários apenas para oferecer suporte à resolução de 1080p, mas ainda são necessários para oferecer suporte a 6 instâncias a 1080p30fps.
- [5.1/H-1-19] DEVE suportar 3 instâncias de decodificador de vídeo de hardware de 10 bits (HDR) e sessões de codificador de vídeo de hardware (AVC, HEVC, VP9, AV1 ou posterior) em qualquer combinação de codec executada simultaneamente em resolução de 4K@30fps (a menos que AV1) dos quais no máximo 1 é uma sessão do codificador, que pode ser configurada no formato de entrada RGBA_1010102 através de uma superfície GL. A geração de metadados HDR pelo codificador não é necessária se a codificação for da superfície GL. As sessões do codec AV1 só são necessárias para oferecer suporte à resolução 1080p, mesmo quando esse requisito exige 4K.
- [5.1/H-1-7] DEVE ter uma latência de inicialização do codec de 40 ms ou menos para uma sessão de codificação de vídeo de 1080p ou menor para todos os codificadores de vídeo de hardware quando sob carga. O carregamento aqui é definido como uma sessão simultânea de transcodificação somente de vídeo de 1080p a 720p usando codecs de vídeo de hardware junto com a inicialização da gravação de áudio e vídeo de 1080p. Para o codec Dolby Vision, a latência de inicialização do codec DEVE ser de 50 ms ou menos.
- [5.1/H-1-8] DEVE ter uma latência de inicialização do codec de 30 ms ou menos para uma sessão de codificação de áudio com taxa de bits de 128 kbps ou inferior para todos os codificadores de áudio quando sob carga. O carregamento aqui é definido como uma sessão simultânea de transcodificação somente de vídeo de 1080p a 720p usando codecs de vídeo de hardware junto com a inicialização da gravação de áudio e vídeo de 1080p.
- [5.1/H-1-9] DEVE suportar 2 instâncias de sessões seguras de decodificador de vídeo de hardware (AVC, HEVC, VP9, AV1 ou posterior) em qualquer combinação de codecs executadas simultaneamente com resolução de 4k a 30 fps (a menos que AV1) para ambos 8- bit (SDR) e conteúdo HDR de 10 bits. As sessões do codec AV1 só são necessárias para oferecer suporte à resolução 1080p, mesmo quando esse requisito exige 4K.
- [5.1/H-1-10] DEVE suportar 3 instâncias de sessões de decodificador de vídeo de hardware não seguro junto com 1 instância de sessão de decodificador de vídeo de hardware seguro (4 instâncias no total) (AVC, HEVC, VP9, AV1 ou posterior) em qualquer codec combinação executada simultaneamente com 3 sessões com resolução 4K a 30 fps (a menos que AV1), que inclui uma sessão de decodificador seguro e 1 sessão nn-segura com resolução de 1080p a 30 fps, onde no máximo 2 sessões podem ser em HDR de 10 bits. As sessões do codec AV1 só são necessárias para oferecer suporte à resolução 1080p, mesmo quando esse requisito exige 4K.
- [5.1/H-1-11] DEVE suportar um decodificador seguro para cada decodificador de hardware AVC, HEVC, VP9 ou AV1 no dispositivo.
- [5.1/H-1-12] DEVE ter uma latência de inicialização do codec de 40 ms ou menos para uma sessão de decodificação de vídeo de 1080p ou menor para todos os decodificadores de vídeo de hardware quando sob carga. O carregamento aqui é definido como uma sessão simultânea de transcodificação somente de vídeo de 1080p a 720p usando codecs de vídeo de hardware junto com a inicialização da reprodução de áudio e vídeo de 1080p. Para o codec Dolby Vision, a latência de inicialização do codec DEVE ser de 50 ms ou menos.
- [5.1/H-1-13] DEVE ter uma latência de inicialização do codec de 30 ms ou menos para uma sessão de decodificação de áudio com taxa de bits de 128 kbps ou inferior para todos os decodificadores de áudio quando sob carga. O carregamento aqui é definido como uma sessão simultânea de transcodificação somente de vídeo de 1080p a 720p usando codecs de vídeo de hardware junto com a inicialização da reprodução de áudio e vídeo de 1080p.
- [5.1/H-1-14] DEVE suportar o decodificador de hardware AV1 Main 10, Nível 4.1 e granulação de filme.
- [5.1/H-1-15] DEVE ter pelo menos 1 decodificador de vídeo de hardware compatível com 4K60.
- [5.1/H-1-16] DEVE ter pelo menos 1 codificador de vídeo de hardware compatível com 4K60.
- [5.3/H-1-1] NÃO DEVE perder mais de 1 quadro em 10 segundos (ou seja, menos de 0,167 por cento de queda de quadro) para uma sessão de vídeo 4K a 60 fps sob carga.
- [5.3/H-1-2] NÃO DEVE perder mais de 1 quadro em 10 segundos durante uma alteração na resolução de vídeo em uma sessão de vídeo de 60 fps sob carga para uma sessão de 4K.
- [5.6/H-1-1] DEVE ter uma latência tap-to-tone de 80 milissegundos ou menos usando o teste tap-to-tone do CTS Verifier.
- [5.6/H-1-2] DEVE ter uma latência de áudio de ida e volta de 80 milissegundos ou menos em pelo menos um caminho de dados suportado.
- [5.6/H-1-3] DEVE suportar >= áudio de 24 bits para saída estéreo em conectores de áudio de 3,5 mm, se houver, e áudio USB, se for compatível com todo o caminho de dados para configurações de baixa latência e streaming. Para a configuração de baixa latência, o AAudio deve ser usado pelo aplicativo no modo de retorno de chamada de baixa latência. Para a configuração do streaming, um Java AudioTrack deve ser utilizado pelo aplicativo. Nas configurações de baixa latência e streaming, o coletor de saída HAL deve aceitar
AUDIO_FORMAT_PCM_24_BIT
,AUDIO_FORMAT_PCM_24_BIT_PACKED
,AUDIO_FORMAT_PCM_32_BIT
ouAUDIO_FORMAT_PCM_FLOAT
para seu formato de saída de destino. - [5.6/H-1-4] DEVE suportar >= dispositivos de áudio USB de 4 canais (isso é usado por controladores de DJ para pré-visualização de músicas).
- [5.6/H-1-5] DEVE suportar dispositivos MIDI compatíveis com a classe e declarar o sinalizador de recurso MIDI.
- [5.6/H-1-9] DEVE suportar mixagem de pelo menos 12 canais. Isto implica a capacidade de abrir uma AudioTrack com máscara de canal 7.1.4 e espacializar ou mixar adequadamente todos os canais para estéreo.
- [5.6/H-SR] São FORTEMENTE RECOMENDADOS para suportar mixagem de 24 canais com pelo menos suporte para máscaras de canais 9.1.6 e 22.2.
- [5.7/H-1-2] DEVE 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 KB |
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 as sessões) | 6 |
Tamanho da mensagem | 16 KiB |
Quadros descriptografados por segundo | 60fps |
- [5.1/H-1-17] DEVE ter pelo menos 1 decodificador de imagem de hardware compatível com AVIF Baseline Profile.
- [5.1/H-1-18] DEVE suportar o codificador AV1, que pode codificar resolução de até 480p a 30fps e 1Mbps.
-
[5.12/H-1-1] DEVE[5.12/H-SR] São fortemente recomendados para oferecer suporte ao recursoFeature_HdrEditing
para todos os codificadores AV1 e HEVC de hardware presentes no dispositivo. - [5.12/H-1-2] DEVE suportar o formato de cores RGBA_1010102 para todos os codificadores AV1 e HEVC de hardware presentes no dispositivo.
- [5.12/H-1-3] DEVE anunciar suporte para a extensão EXT_YUV_target para amostrar texturas YUV em 8 e 10 bits.
- [7.1.4/H-1-1] DEVE ter pelo menos 6 sobreposições de hardware na unidade de processamento de dados (DPU) Hardware Composer (HWC), com pelo menos 2 delas capazes de exibir conteúdo de vídeo de 10 bits.
Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.U
para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
e incluírem suporte para um codificador AVC ou HEVC de hardware, elas:
- [5.2/H-2-1] DEVE atender à meta de qualidade mínima definida pelas curvas de distorção de taxa do codificador de vídeo para codecs de hardware AVC e HEVC, conforme definido na próxima documentação.
Ver revisão
android.os.Build.VERSION_CODES.U
para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, então elas:- [ 7.5 /H-1-1] DEVE ter uma câmera traseira primária com resolução de pelo menos 12 megapixels com suporte para captura de vídeo a 4k a 30fps. A câmera traseira principal é a câmera traseira com o ID de câmera mais baixo.
- [ 7.5 /H-1-2] DEVE ter uma câmera frontal primária com resolução de pelo menos 6 megapixels e suporte para captura de vídeo em 1080p a 30fps. A câmera frontal principal é a câmera frontal com o ID de câmera mais baixo.
- [ 7.5 /H-1-3] DEVE oferecer suporte à propriedade
android.info.supportedHardwareLevel
como FULL ou melhor para ambas as câmeras primárias. - [ 7.5 /H-1-4] DEVE oferecer suporte
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
para ambas as câmeras primárias. - [ 7.5 /H-1-5] DEVE ter latência de captura JPEG da câmera2 < 1000
900ms para resolução de 1080p, conforme medido pelo Teste de desempenho da câmera CTS sob condições de iluminação ITS (3000K) para ambas as câmeras primárias. - [ 7.5 /H-1-6] DEVE ter latência de inicialização da câmera2 (câmera aberta para o primeiro quadro de visualização) <500 ms conforme medido pelo Teste de desempenho da câmera CTS sob condições de iluminação ITS (3000K) para ambas as câmeras primárias.
- [ 7.5 /H-1-8] DEVE oferecer suporte
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW
eandroid.graphics.ImageFormat.RAW_SENSOR
para a câmera traseira principal. - [ 7.5 /H-1-9] DEVE ter uma câmera primária voltada para trás com suporte a 720p ou 1080p a 240fps.
- [ 7.5 /H-1-10] DEVE ter mínimo ZOOM_RATIO <1.0 para as câmeras primárias se houver uma câmera RGB ultralarga voltada para a mesma direção.
- [ 7.5 /H-1-11] DEVE implementar streaming frontal-traseiro simultâneo em câmeras primárias.
- [ 7.5 /H-1-12] DEVE oferecer suporte
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
para câmera frontal primária e traseira primária. - [ 7.5 /H-1-13] DEVE suportar o recurso
LOGICAL_MULTI_CAMERA
para as câmeras primárias se houver mais de 1 câmera RGB voltada para a mesma direção. - [ 7.5 /H-1-14] DEVE oferecer suporte ao recurso
STREAM_USE_CASE
para câmera frontal primária e traseira primária. - [ 7.5 /H-1-15] DEVE oferecer suporte a extensões de modo
Bokeh enoturno por meio das extensões CameraX e Camera2 para câmeras primárias. - [ 7.5 /H-1-16] DEVE oferecer suporte ao recurso DYNAMIC_RANGE_TEN_BIT para as câmeras primárias.
- [ 7.5 /H-1-17] DEVE suportar CONTROL_SCENE_MODE_FACE_PRIORITY e detecção de rosto ( STATISTICS_FACE_DETECT_MODE_SIMPLE ou STATISTICS_FACE_DETECT_MODE_FULL ) para as câmeras primárias.
Ver revisão
android.os.Build.VERSION_CODES.U
para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, então elas:- [7.1.1.1/H-2-1] DEVE ter resolução de tela de pelo menos 1080p.
- [7.1.1.3/H-2-1] DEVE ter densidade de tela de pelo menos 400 dpi.
- [7.1.1.3/H-3-1] DEVE ter uma tela HDR que suporte pelo menos 1000 nits em média.
- [7.6.1/H-2-1] DEVE ter pelo menos 8 GB de memória física.
Ver revisão
android.os.Build.VERSION_CODES.U
para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, então elas:- [8.2/H-1-1] DEVE garantir um desempenho de gravação sequencial de pelo menos 150 MB/s.
- [8.2/H-1-2] DEVE garantir um desempenho de gravação aleatória de pelo menos 10 MB/s.
- [8.2/H-1-3] DEVE garantir um desempenho de leitura sequencial de pelo menos 250 MB/s.
- [8.2/H-1-4] DEVE garantir um desempenho de leitura aleatória de pelo menos 100 MB/s.
- [8.2/H-1-5] DEVE garantir um desempenho de leitura e gravação sequencial paralela com desempenho de leitura 2x e gravação 1x de pelo menos 50 MB/s.
Ver revisão
As implementações de dispositivos de televisão DEVEM suportar os seguintes formatos de codificação de vídeo e disponibilizá-los para aplicativos de terceiros:
- [ 5.2 /T-0-3] AV1
As implementações de dispositivos de televisão DEVEM suportar os seguintes formatos de decodificação de vídeo e disponibilizá-los para aplicativos de terceiros:
- [ 5.3.2 /T-0-7] AV1
Ver revisão
Se as implementações de dispositivos tiverem uma tela de bloqueio segura e incluírem um ou mais agentes confiáveis, que implementam a API do sistema TrustAgentService
, elas:
- [ 9.11.1 /W-1-1] DEVE desafiar o usuário para um dos métodos de autenticação primários recomendados (por exemplo: PIN, padrão, senha) com mais frequência do que uma vez a cada 72 horas.
Ver revisão
Se as implementações do dispositivo incluírem suporte para transmissão de rádio AM/FM e exporem a funcionalidade a qualquer aplicativo, elas:
- [ 7.4
.10/A-0-1] DEVE declarar suporte paraFEATURE_BROADCAST_RADIO
.
Uma câmera de visão externa é uma câmera que captura imagens de cenas fora da implementação do dispositivo, como a câmera retrovisora.
Implementações de dispositivos automotivos:
- DEVE incluir uma ou mais câmeras de visão externa.
Se as implementações de dispositivos automotivos incluírem uma câmera de visão externa, para tal câmera, elas:
- [ 7.5 /A-1-1] NÃO DEVE ter câmeras de visão externa acessíveis por meio das APIs de câmera do Android , a menos que cumpram os requisitos principais da câmera.
- [ 7.5 /A-SR-1] É FORTEMENTE RECOMENDADO não girar ou espelhar horizontalmente a visualização da câmera.
- [ 7.5 /A-SR-2] É FORTEMENTE RECOMENDADO ter uma resolução de pelo menos 1,3 megapixels.
- DEVE ter foco fixo ou hardware EDOF (profundidade de campo estendida).
- PODE ter foco automático de hardware ou foco automático de software implementado no driver da câmera.
Se as implementações de dispositivos automotivos incluírem uma ou mais câmeras de visão externa e carregarem o serviço Exterior View System (EVS), então, para tal câmera, elas:
- [ 7.5 /A-2-1] NÃO DEVE girar ou espelhar horizontalmente a visualização da câmera.
Implementações de dispositivos automotivos:
- PODE incluir uma ou mais câmeras disponíveis para aplicativos de terceiros.
Se as implementações de dispositivos automotivos incluírem pelo menos uma câmera e a disponibilizarem para aplicativos de terceiros, elas:
- [ 7.5 /A-3-1] DEVE relatar o sinalizador de recurso
android.hardware.camera.any
. - [ 7.5 /A-3-2] Não DEVE declarar a câmera como uma câmera de sistema .
- PODE suportar câmeras externas descritas na seção 7.5.3 .
- PODE incluir recursos (como foco automático, etc.) disponíveis para câmeras traseiras, conforme descrito na seção 7.5.1 .
Uma câmara traseira significa uma câmara voltada para o mundo que pode estar localizada em qualquer lugar do veículo e está voltada para o exterior da cabina do veículo; isto é, ele captura cenas do outro lado da carroceria do veículo, como a câmera retrovisora.
Uma câmara frontal significa uma câmara voltada para o utilizador que pode estar localizada em qualquer local do veículo e está voltada para o interior da cabina do veículo; isto é, imagens do usuário, como para videoconferência e aplicativos semelhantes.
Implementações de dispositivos automotivos:
- [7.5/A-SR-1] É FORTEMENTE RECOMENDADO incluir uma ou mais câmeras voltadas para o mundo.
- PODE incluir uma ou mais câmeras voltadas para o usuário.
- [7.5/A-SR-2] São FORTEMENTE RECOMENDADOS para suportar streaming simultâneo de múltiplas câmeras.
Se as implementações de dispositivos automotivos incluírem pelo menos uma câmera voltada para o mundo, então, para tal câmera, elas:
- [7.5/A-1-1] DEVE ser orientado de forma que a dimensão longa da câmera se alinhe com o plano XY dos eixos do sensor automotivo Android.
- [7.5/A-SR-3] É FORTEMENTE RECOMENDADO ter hardware de foco fixo ou EDOF (Profundidade de Campo Estendida).
- [7.5/A-1-2] DEVE ter a câmera primária voltada para o mundo como a câmera voltada para o mundo com o ID de câmera mais baixo.
Se as implementações de dispositivos automotivos incluírem pelo menos uma câmera voltada para o usuário, então, para tal câmera:
- [7.5/A-2-1] A câmera primária voltada para o usuário DEVE ser a câmera voltada para o usuário com o ID de câmera mais baixo.
- PODE ser orientado de forma que a dimensão longa da câmera se alinhe com o plano XY dos eixos do sensor automotivo Android.
Se as implementações de dispositivos automotivos incluírem uma câmera acessível por meio da API android.hardware.Camera
ou android.hardware.camera2
, elas:
- [7.5/A-3-1] DEVE cumprir os requisitos principais da câmera na seção 7.5.
Se as implementações de dispositivos automotivos incluírem uma câmera que não é acessível por meio da API android.hardware.Camera
ou android.hardware.camera2
, elas:
- [7.5/A-4-1] DEVE ser acessível através do serviço Extended View System.
Se as implementações de dispositivos automotivos incluírem uma ou mais câmeras acessíveis por meio do Extended View System Service, para tal câmera, elas:
- [7.5/A-5-1] NÃO DEVE girar ou espelhar horizontalmente a visualização da câmera.
- [7.5/A-SR-4] É FORTEMENTE RECOMENDADO ter uma resolução de pelo menos 1,3 megapixels.
Se as implementações de dispositivos automotivos incluírem uma ou mais câmeras acessíveis por meio do Extended View System Service e da API android.hardware.Camera
ou android.hardware.Camera2
, então, para tal câmera, elas:
- [7.5/A-6-1] DEVE informar o mesmo ID de câmera.
Se as implementações de dispositivos automotivos fornecerem uma API de câmera proprietária, elas:
- [7.5/A-7-1] DEVE implementar essa API de câmera usando a API
android.hardware.camera2
ou a API do sistema Extended View.
Ver revisão
Implementações de dispositivos automotivos:
- [ 3.8 /A-0-1] NÃO DEVE permitir que usuários secundários completos que não sejam o usuário em primeiro plano atual iniciem atividades e tenham acesso à IU em qualquer monitor.
Ver revisão
Se as implementações de dispositivos automotivos declararem android.hardware.microphone
, elas:
- [ 9.8.2 /A-1-1] DEVE exibir o indicador do microfone quando um aplicativo está acessando dados de áudio do microfone, mas não quando o microfone é acessado apenas por
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
ou aplicativos que possuem as funções indicadas na seção 9.1 com identificador CDD [C-4-X]. - [ 9.8.2 /A-1-2] NÃO DEVE ocultar o indicador do microfone para aplicativos do sistema que tenham interfaces de usuário visíveis ou interação direta do usuário.
- [ 9.8.2 /A-1-3] DEVE fornecer ao usuário a capacidade de alternar o microfone no aplicativo Configurações.
Se as implementações de dispositivos automotivos declararem android.hardware.camera.any
, elas:
- [ 9.8.2 /A-2-1] DEVE exibir o indicador da câmera quando um aplicativo estiver acessando dados da câmera ao vivo, mas não quando a câmera estiver sendo acessada apenas por aplicativos que detêm as funções
definidasna Seção 9.1 Permissões com identificador CDD [C-4-X][C-3-X].
- [ 9.8.2 /A-2-3] DEVE fornecer ao usuário recursos para alternar a câmera no aplicativo Configurações.
- [ 9.8.2 /A-2-4] DEVE exibir aplicativos recentes e ativos usando câmera conforme retornado de
PermissionManager.getIndicatorAppOpUsageData()
, juntamente com quaisquer mensagens de atribuição associadas a eles.
Se as implementações de dispositivos tiverem uma tela de bloqueio segura e incluírem um ou mais agentes confiáveis, que implementam a API do sistema TrustAgentService
, elas:
- [ 9.11.1 /A-1-1] DEVE desafiar o usuário para um dos métodos de autenticação primários recomendados (por exemplo: PIN, padrão, senha) com mais frequência do que uma vez a cada 336 horas.
3. Programas
3.1. Compatibilidade de API gerenciada :
Ver revisão
Implementações de dispositivos:
- [C-0-8] NÃO DEVE oferecer suporte à instalação de aplicativos direcionados a um nível de API inferior a 23.
3.2.3.5. Intenções de aplicação condicional :
Ver revisão
Se as implementações de dispositivos relatarem
android.hardware.nfc.uicc
ouandroid.hardware.nfc.ese
, elas:- [C-19-1] deve implementar a API NFCADAPTER.ACTION_TRANSACTION_DETETED API (como "EVT_TRANSACTION" definida pela especificação técnica da GSM Association TS.26-NFC Requisitos de aparelho) .
3.3.1. Interfaces binárias do aplicativo :
Veja revisão
Implementações de dispositivos:
- [C-0-12] MUST export function symbols for the core
Vulkan 1.0Vulkan 1.1 function symbols, as well as theVK_KHR_surface
,VK_KHR_android_surface
,VK_KHR_swapchain
,VK_KHR_maintenance1
, andVK_KHR_get_physical_device_properties2
extensions through thelibvulkan.so
library. Observe que, embora todos os símbolos devam estar presentes, a Seção 7.1.4.2 descreve em mais detalhes os requisitos para quando a implementação completa de cada funções correspondentes forem esperadas.
- [C-0-12] MUST export function symbols for the core
Veja revisão
Se as implementações do dispositivo incluem uma tela ou saída de vídeo, eles:
- [
android.theme.customization.theme_styles
-1-5]VIBRANT
gerar paletasSPRITZ
TONAL_SPOT
coresRAINBOW
usandoMONOCHROMATIC
EXPRESSIVE
FRUIT_SALAD
coloridos enumerados nosSettings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
.
- [
3.8.8. Comutação de atividades :
Veja revisão
Se as implementações do dispositivo, incluindo a chave de navegação da função dos recentes, conforme detalhado na Seção 7.2.3 Alterar a interface, eles:
- [C-1-2] deve implementar o comportamento de fixação da tela e fornecer ao usuário um menu de configurações para alternar o recurso.
3.9.2 Suporte ao perfil gerenciado :
Veja revisão
Se as implementações do dispositivo declararem
android.software.managed_users
, elas:- [C-1-10] deve garantir que os dados da captura de tela sejam salvos no armazenamento do perfil de trabalho quando uma captura de tela é capturada com uma janela
topActivity
que tem foco (aquele com o qual o usuário interagiu com o último entre todas as atividades) e pertence a um perfil de trabalho aplicativo . - [C-1-11] não deve capturar nenhum outro conteúdo da tela (barra do sistema, notificações ou qualquer conteúdo do perfil pessoal), exceto a janela/janela do aplicativo de perfil de trabalho ao salvar uma captura de tela no perfil de trabalho (para garantir que os dados do perfil pessoal sejam não salvo no perfil de trabalho).
- [C-1-10] deve garantir que os dados da captura de tela sejam salvos no armazenamento do perfil de trabalho quando uma captura de tela é capturada com uma janela
3.9.5 Estrutura de resolução da política do dispositivo : Nova seção
Veja revisão
Se as implementações do dispositivo relatar
android.software.device_admin
ouandroid.software.managed_users
, eles: eles:- [C-1-1] deve resolver os conflitos de política do dispositivo, conforme documentado na documentação da AOSP.
5. Compatibilidade multimídia
5.1.4. Codificação de imagem :
Veja revisão
As implementações do dispositivo devem suportar a codificação da codificação de imagem a seguir:
- [C-0-4] Avif
- Os dispositivos devem suportar
BITRATE_MODE_CQ
e o perfil da linha de base.
- Os dispositivos devem suportar
- [C-0-4] Avif
5.1.5. Decodificação da imagem :
Veja revisão
As implementações do dispositivo devem suportar a decodificação da seguinte codificação de imagem:
[C-0-7] AVIF (perfil de linha de base)
5.1.6. Detalhes de codecs de imagem :
Veja revisão
Formato/codec Detalhes Tipos de arquivo suportados/formatos de contêiner JPEG Base+progressiva Jpeg (.jpg) GIFs Gif (.gif) png Png (.png) BMP BMP (.bmp) WebP Webp (.Webp) Cru Arw (.arw), Cr2 (.Cr2), DNG (.dng), nef (.nef), nrw (.nrw), orf (.orf), PEF (.pef), raf (.raf), rw2 ( .rw2), srw (.srw) Novilha Imagem, coleta de imagens, sequência de imagens Heif (.Heif), heic (.Heic) AVIF (perfil de linha de base) Imagem, coleta de imagens, perfil de linha de base de sequência de imagens Contêiner de novilha (.avif) 5.1.8. Lista de codecs de vídeo :
Veja revisão
Formato/codec Detalhes Tipos de arquivo/formatos de contêiner a serem suportados H.263 - 3GPP (.3GP)
- MPEG-4 (.mp4)
- Matroska (.mkv, apenas decodifica)
H.264 AVC Consulte a Seção 5.2 e 5.3 para obter detalhes - 3GPP (.3GP)
- MPEG-4 (.mp4)
- Mpeg-2 ts (.ts, não procurável)
- Matroska (.mkv, apenas decodifica)
H.265 HEVC Consulte a Seção 5.3 para obter detalhes - MPEG-4 (.mp4)
- Matroska (.mkv, apenas decodifica)
MPEG-2 Perfil principal - Mpeg2-ts (.ts, não procurável)
- MPEG-4 (.mp4, apenas decodificar)
- Matroska (.mkv, apenas decodifica)
MPEG-4 sp - 3GPP (.3GP)
- MPEG-4 (.mp4)
- Matroska (.mkv, apenas decodifica)
VP8 Consulte a Seção 5.2 e 5.3 para obter detalhes - WebM (.Webm)
- Matroska (.mkv)
VP9 Consulte a Seção 5.3 para obter detalhes - WebM (.Webm)
- Matroska (.mkv)
AV1 Consulte a Seção 5.2 e Seção 5.3 para obter detalhes - MPEG-4 (.mp4)
- Matroska (.mkv, apenas decodifica)
5.1.10. Caracterização de codec de mídia :
Veja revisão
Se as implementações do dispositivo suportarem codecs de vídeo:
- [C-2-1] Todos os codecs de vídeo devem publicar dados de taxa de quadros alcançáveis para os seguintes tamanhos se suportados pelo codec:
SD (baixa qualidade) SD (alta qualidade) HD 720p HD 1080p Ultra HD Resolução de 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 (outro)
- 704 x 576 px (H263)
- 640 x 360 px (VP8, VP9)
- 640 x 480 px (codificador MPEG4)
- 720 x 480 px (outro, av1 )
- 1408 x 1152 px (H263)
- 1280 x 720 px (outro, av1 )
1920 x 1080 px (exceto MPEG4, AV1 ) 3840 x 2160 px (HEVC, VP9, AV1 ) Veja revisão
Se as implementações do dispositivo suportarem qualquer codificador de vídeo e o disponibilizam para aplicativos de terceiros, eles:- Não deve ser, em duas janelas deslizantes, mais de 15% sobre a taxa de bits entre os intervalos intra-quadro (I-Frame).
- Não deve ser superior a 100% sobre a taxa de bits em uma janela deslizante de 1 segundo.
Se as implementações do dispositivo suportarem qualquer codificador de vídeo e o disponibilize para aplicativos de terceiros e defina o
MediaFormat.KEY_BITRATE_MODE
paraBITRATE_MODE_VBR
para que o codificador opere no modo de taxa de bits variável, então, desde que não afete o piso de qualidade mínima , a taxa de bits codificada:-
[C-5-1] não deveestar , em uma janela deslizante, mais de 15% sobre a taxa de bits entre os intervalos intra-quadro (i-quadro). -
[C-5-2]não deve ser superior a 100% sobre a taxa de bits sobre uma janela deslizante de 1 segundo.
Se as implementações do dispositivo suportarem qualquer codificador de vídeo e disponibilizá-lo para aplicativos de terceiros e definir o
MediaFormat.KEY_BITRATE_MODE
comoBITRATE_MODE_CBR
para que o codificador opere no modo de taxa de bits constante, a taxa de bits codificada:-
[C-6-1] deve[C-SR-2] é fortemente recomendado para não ser superior a 15% sobre a taxa de bits de destino em uma janela deslizante de 1 segundo.
Veja revisão
Se as implementações do dispositivo suportarem os codificadores H.263 e o disponibilizam para aplicativos de terceiros, eles:
- [C-1-1] deve suportar a resolução do QCIF (176 x 144) usando o nível do perfil da linha de base 45. A resolução do SQCIF é opcional.
-
Deve suportar taxas de bits dinamicamente configuráveis para o codificador suportado.
Veja revisão
Se as implementações do dispositivo suportarem o codec H.265, elas:
- [C-1-1] deve suportar o nível principal de nível 3 de até 512 x 512 resolução .
-
Deve apoiar os perfis de codificação HD, conforme indicado na tabela a seguir. - [C-SR-1] são fortemente recomendados para apoiar o perfil SD 720 x 480 e os perfis de codificação HD, conforme indicado na tabela a seguir, se houver um codificador de hardware.
5.2.6. AV1 : Nova seção
Veja revisão
Se as implementações do dispositivo suportarem o codec AV1, eles: eles:
- [C-1-1] deve suportar o perfil principal, incluindo conteúdo de 8 e 10 bits.
[C-1-2] deve publicar dados de desempenho, isto é, dados de desempenho de relatório por meio das APIs
getSupportedFrameRatesFor()
ougetSupportedPerformancePoints()
para resoluções suportadas na tabela abaixo.[C-1-3] deve aceitar metadados hdr e emitir para o BitStream
Se o codificador AV1 for acelerado de hardware, então:
- [C-2-1] deve apoiar até e incluindo o perfil de codificação HD1080p da tabela abaixo:
SD HD 720p HD 1080p Ultra HD Resolução de vídeo 720 x 480 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 px Taxa de quadros de vídeo 30fps 30fps 30fps 30fps Taxa de bits de vídeo 5 Mbps 8 Mbps 16 Mbps 50Mbps Veja revisão
Se as implementações do dispositivo suportarem os decodificadores H.263, eles:
- [C-1-1] deve suportar o nível de perfil da linha de base 30 (resoluções CIF, QCIF e SQCIF @ 30FPS 384kbps) e Nível 45 (resoluções QCIF e SQCIF @ 30FPS 128kbps) .
Veja revisão
Se as implementações do dispositivo suportarem o codec AV1, eles:- [C-1-1] deve suportar o perfil 0, incluindo conteúdo de 10 bits.
Se as implementações do dispositivo suportarem o codec AV1 e o disponibilizam para aplicativos de terceiros, eles:
- [C-1-1] deve suportar o perfil principal, incluindo conteúdo de 8 e 10 bits.
Se as implementações do dispositivo fornecerem suporte ao codec AV1 com um decodificador acelerado de hardware, eles: eles:
- [C-2-1] deve ser capaz de decodificar pelo menos os perfis de decodificação de vídeo HD 720p da tabela abaixo quando a altura relatada pelo método
Display.getSupportedModes()
for igual ou superior a 720p. - [C-2-2] deve ser capaz de decodificar pelo menos os perfis de decodificação de vídeo HD 1080p da tabela abaixo quando a altura relatada pelo método
Display.getSupportedModes()
for igual ou superior a 1080p.
SD HD 720p HD 1080p Ultra HD Resolução de vídeo 720 x 480 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 px Taxa de quadros de vídeo 30fps 30fps 30fps 30fps Taxa de bits de vídeo 5 Mbps 8 Mbps 16 Mbps 50Mbps Se as implementações do dispositivo suportarem o perfil HDR através das APIs de mídia, elas:
- [C-3-1] deve suportar a extração e saída de metadados HDR do BitStream e/ou contêiner.
- [C-3-2] deve exibir corretamente o conteúdo HDR na tela do dispositivo ou em uma porta de saída de vídeo padrão (por exemplo, HDMI).
5.4.2. Capture para reconhecimento de voz :
Veja revisão
Se as implementações do dispositivo declararem
android.hardware.microphone
, elas:- Deve definir a sensibilidade de entrada de áudio, de modo que uma fonte de tom sinusoidal de 1000 Hz seja jogada no nível de pressão sonora de 90 dB (SPL) (medido
a uma distância de 30 cm dopróximo ao microfone) produz uma resposta ideal do RMS 2500 dentro de um intervalo de 1770 e 3530 para 16 amostras de bit (ou -22,35 dB ± 3dB em escala completa para amostras de ponto flutuante/dupla precisão) para cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.
- Deve definir a sensibilidade de entrada de áudio, de modo que uma fonte de tom sinusoidal de 1000 Hz seja jogada no nível de pressão sonora de 90 dB (SPL) (medido
Veja revisão
Se as implementações do dispositivo declararem o recurso
android.hardware.audio.output
, eles:- [C-1-4] deve suportar efeitos de áudio com entrada e saída de ponto flutuante.
- [C-1-5] deve garantir que os efeitos de áudio suportem vários canais até a contagem de canais do mixer, também conhecida como FCC_LIMIT.
Veja revisão
Se as implementações do dispositivo declararem
android.hardware.audio.output
, eles são fortemente recomendados para atender ou exceder os seguintes requisitos:- [C-SR-4] O registro de data e hora de saída retornado pelo AudioTrack.GetTimestamp e
AAudioStream_getTimestamp
é preciso para +/- 1 ms.
- [C-SR-4] As latências de ida e volta calculadas com base nos registros de data e hora de entrada e saída retornados por
AAudioStream_getTimestamp
são fortemente recomendados para estar dentro de 30 ms da latência de ida e volta medida paraAAUDIO_PERFORMANCE_MODE_NONE
eAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
para falantes, wirled, wirless e wirless.
- [C-SR-4] O registro de data e hora de saída retornado pelo AudioTrack.GetTimestamp e
7. Compatibilidade de hardware
Veja revisão
O Android inclui instalações que ajustam automaticamente os ativos de aplicativos e os layouts da interface do usuário adequadamente para o dispositivo para garantir que os aplicativos de terceiros funcionem bem em uma
variedade de configurações de hardware .Variedade de displays e configurações de hardware. Uma tela compatível com Android é uma tela de exibição que implementa todos os comportamentos e APIs descritas nos desenvolvedores Android-Visão geral da compatibilidade de tela , esta seção (7.1) e suas subseções, bem como quaisquer comportamentos específicos do tipo de dispositivo adicional documentados na Seção 2 da Este CDD.Nos exibições compatíveis com Android, onde todos os aplicativos compatíveis com Android de terceiros podem ser executados, as implementações de dispositivos devem implementar adequadamente essas APIs e comportamentos, conforme detalhado nesta seção.Inicie novos requisitos
Implementações de dispositivos:
- [C-0-1] deve, por padrão, renderizar aplicativos de terceiros apenas em telas compatíveis com Android.
As unidades referenciadas pelos requisitos nesta seção são definidas da seguinte forma:
- Tamanho diagonal físico . A distância em polegadas entre dois cantos opostos da parte iluminada da tela.
- densidade
de pontos por polegada (DPI). O número de pixels abrangidos por uma extensão horizontal ou vertical linear de 1 ” , expressa como pixels por polegada (PPI ou DPI) . Onde os valoresDPIPPI e DPI são listados, o DPI horizontal e vertical deve se enquadrar no intervalo listado . - proporção da tela . A razão entre os pixels da dimensão mais longa e a dimensão mais curta da tela. Por exemplo, uma exibição de 480x854 pixels seria 854/480 = 1,779, ou aproximadamente "16: 9".
- Pixel independente de densidade (DP) .
Aunidade de pixel virtual normalizada para uma densidade de tela de160 DPI na telade 160. Para alguma densidade d e vários pixels p, o número de pixels independentes de densidade DP, é calculado como: pixels = dps * (densidade/160)dp = (160 / d) * p .
7.1.1.1. Tamanho e forma da tela :
Veja revisão
Se as implementações do dispositivo suportarem telas capazes da configuração de tamanho
UI_MODE_TYPE_NORMAL
e incluirá exibição física (s)compatível com Androidcom cantos arredondados para renderizar essas telas , elas:- [C-1-1] deve garantir que pelo menos um dos seguintes requisitos seja atendido para cada uma dessas exibições :
- O raio dos cantos arredondados é menor ou igual a 38 dp.
Quando uma caixa de 15 dp por 15 DP está ancorada em cada canto da tela lógica, pelo menos um pixel de cada caixa é visível na tela.
Deve incluir a oferta do usuário para mudar para o modo de exibição com os cantos retangulares.
Inicie novos requisitos
Se as implementações do dispositivo forem capazes apenas da configuração do teclado
NO_KEYS
e pretendem relatar suporte para a configuração do modoUI_MODE_TYPE_NORMAL
UI, eles:- [C-4-1] deve ter um tamanho de layout, excluindo quaisquer recortes de exibição, de pelo menos 596 dp x 384 dp ou mais.
Se as implementações do dispositivo incluirem um (s) exibição (s) compatível com Android, que é dobrável ou incluir uma dobradiça dobrável entre vários painéis de exibição e disponibilize esse (s) exibição (s) para renderizar aplicativos de terceiros, eles:
- [C-2-1] deve implementar a mais recente versão estável disponível da API de extensões ou a versão estável da API Sidecar a ser usada pela Biblioteca Jetpack do Window Manager .
Se as implementações do dispositivo incluirem um (s) exibição (s) compatível com o Android que é dobrável ou incluir uma dobradiça dobrável entre vários painéis de exibição e se a dobradiça ou dobra cruzar uma janela de aplicativo de tela cheia, eles: eles: eles: eles: eles: eles: eles: eles: eles: eles: eles: eles: eles: eles: eles: eles:
- [C-3-1] deve relatar a posição, os limites e o estado da dobradiça ou dobra através de extensões ou APIs de carros laterais ao aplicativo.
Se as implementações do dispositivo incluirem uma ou mais áreas de exibição compatíveis com Android que são dobráveis ou incluam uma dobradiça dobrável entre as áreas de painel de exibição múltipla compatível com Android e disponibilizam essas áreas de exibição para aplicações, elas: elas:
- [C-4-1] deve implementar a versão correta do nível da API de extensões do gerenciador de janelas, conforme descrito na próxima documentação.
7.1.1.2. Razão da tela : removido
Veja revisão
Implementações de dispositivos:
- [C-0-1]
Por padrão, as implementações do dispositivodevem relatarapenasuma das densidades da estrutura do Android listadas noDisplayMetrics
através da APIDENSITY_DEVICE_STABLE
e esse valor deve ser um valor estático para cada exibição físicanão deve mudar a nenhum momento; No entanto,no entanto , o dispositivo pode relatar uma densidadeDisplayMetrics.density
arbitráriadiferente.
- As implementações do dispositivo devem definir a densidade padrão do Android Framework que é numericamente mais próxima da densidade física da tela, a menos que essa densidade lógica aumente o tamanho da tela relatado abaixo do mínimo suportado. Se a densidade padrão da estrutura Android que estiver numericamente mais próxima da densidade física resultar em um tamanho de tela menor que o menor tamanho de tela compatível com suporte (largura de 320 dp), as implementações do dispositivo devem relatar a próxima densidade de estrutura Android mais baixa.
Inicie novos requisitos
- Deve definir a densidade padrão do Android Framework que está numericamente mais próxima da densidade física da tela, ou um valor que mapearia para as mesmas medições de campo de visão angular equivalente de um dispositivo portátil.
Se as implementações do dispositivo fornecer,
existeuma possibilidade de alterar o tamanho da exibição do dispositivo , elas :- [C-1-1]
O tamanho da tela não deve ser escalonado,não deve escalar a tela maior que 1,5 vezesDENSITY_DEVICE_STABLE
densidade nativaou produzir uma dimensão mínima eficaz da tela menor que 320dp (equivalente ao qualificador de recursos SW320DP), o que ocorrer primeiro. - [C-1-2]
O tamanho da exibição não deve ser escalonado,não deve escalar a tela menor que 0,85 vezes adensidade nativaDENSITY_DEVICE_STABLE
.
- [C-0-1]
Veja revisão
Se as implementações do dispositivo incluirem suporte para Vulkan
1.0 ou superior, eles:[C-1-3] deve implementar completamente as APIs
Vulkan 1.0Vulkan 1.1 para cadaVkPhysicalDevice
enumerada.[C-1-5] não deve enumerar camadas fornecidas por bibliotecas fora do pacote de aplicativos ou fornecer outras maneiras de rastrear ou interceptar a API Vulkan, a menos que o aplicativo tenha o
android:debuggable
conjunto comotrue
ou os metadadoscom.android.graphics.injectLayers.enable
Definir comotrue
.
- Deve suportar
VkPhysicalDeviceProtectedMemoryFeatures
eVK_EXT_global_priority
.
- [C-1-13] deve atender aos requisitos especificados pelo perfil da linha de base Android 2021 .
[C-SR-5] são fortemente recomendados para suportar
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
eVK_EXT_global_priority
.[C-SR-6] são fortemente recomendados para usar
SkiaVk
com HWUI.
Se as implementações do dispositivo incluirem suporte para o Vulkan 1.1 e declararem algum dos bandeiras de recursos vulkan descritos aqui , eles:
- [C-SR-7] são fortemente recomendados para disponibilizar a extensão
VK_KHR_external_fence_fd
para aplicativos de terceiros e permitir que o aplicativo exporte a carga útil da cerca e importe a carga útil de cerca dos descritores de arquivos POSIX, conforme descrito aqui .
7.3.10. Sensores biométricos :
Veja revisão
Se as implementações do dispositivo tiverem vários sensores biométricos, eles:
[C-7-1] Deve, quando um biométrico está em bloqueio (ou seja, o biométrico está desativado até que o usuário desbloqueie com autenticação primária) ou bloqueio de tempo (ou seja, o biométrico está temporariamente desativado até que o usuário aguarde um intervalo de tempo) Devido a muitas tentativas fracassadas, também bloqueia todas as outras biometria de uma classe biométrica mais baixa. No caso de bloqueio limitado, o tempo de retirada para a verificação biométrica deve ser o tempo máximo de retorno de toda a biometria no bloqueio limitado do tempo.
[C-SR-12] são fortemente recomendados, quando um biométrico está em bloqueio (ou seja, o biométrico é desativado até que o usuário desbloqueie com autenticação primária) ou bloqueio de tempo (ou seja, o biométrico está temporariamente desativado até que o usuário aguarde um tempo intervalo) devido a muitas tentativas fracassadas, de bloquear também todas as outras biometria da mesma classe biométrica. No caso de bloqueio de tempo, o tempo de retirada para a verificação biométrica é fortemente recomendado como o tempo máximo de retirada de toda a biometria no bloqueio limitado do tempo.
[C-7-2] deve desafiar o usuário pela autenticação primária recomendada (por exemplo: pino, padrão, senha) para redefinir o contador de bloqueio para que um biométrico esteja sendo bloqueado. A biometria da classe 3 pode poder redefinir o contador de bloqueio para um biométrico biométrico da mesma ou classe baixa. A biometria de classe 2 ou classe 1 não deve concluir uma operação de bloqueio de redefinição para qualquer biometria.
Se as implementações do dispositivo desejarem tratar um sensor biométrico como classe 1 (anteriormente conveniente ), eles:
[C-1-12] deve ter uma taxa de aceitação de paródia e impostor, não superior a 40% por apresentação, espécies (PAI) , conforme medido pelos protocolos de teste de biometria do Android .
[C-SR-13] são fortemente recomendados para ter uma taxa de aceitação de paródia e impostor não superior a 30% por instrumento de ataque de apresentação (PAI) , conforme medido pelos protocolos de teste de biometria Android .
[C-SR-14] são fortemente recomendados para divulgar a classe biométrica do sensor biométrico e os riscos correspondentes de habilitá-lo.
[C-SR-17] são fortemente recomendados para implementar as novas interfaces AIDL (como
IFace.aidl
eIFingerprint.aidl
).
Se as implementações do dispositivo desejarem tratar um sensor biométrico como classe 2 (anteriormente fraco ), eles:
- [C-SR-15] são fortemente recomendados para ter uma taxa de aceitação de paródia e impostor não superior a 20% por instrumento de ataque de apresentação (PAI) , conforme medido pelos protocolos de teste de biometria Android .
- [C-2-3] deve executar a correspondência biométrica em um ambiente de execução isolado fora do espaço do usuário ou do kernel do Android, como o ambiente de execução confiável (TEE)
ouem um chip com um canal seguro para o ambiente de execução isolado ou em protegido Máquina virtual que atende aos requisitos na Seção 9.17 . - [C-2-4] deve ter todos os dados identificáveis criptografados e autenticados criptograficamente, de modo que não possam ser adquiridos, lidos ou alterados fora do ambiente de execução isolado ou um chip com um canal seguro para o ambiente de execução isolado, conforme documentado nas diretrizes de implementação No site do projeto de código aberto Android ou em uma máquina virtual protegida controlada pelo hipervisor que atenda aos requisitos na Seção 9.17 .
- [C-2-5] para biometria baseada em câmera, enquanto a autenticação ou inscrição baseada em biométricas está acontecendo:
- Deve operar a câmera em um modo que impede que os quadros da câmera sejam lidos ou alterados fora do ambiente isolado de execução ou um chip com um canal seguro para o ambiente de execução isolado ou uma máquina virtual protegida controlada pelo hipervisor que atenda aos requisitos na Seção 9.17 .
- Para soluções de câmera única RGB, os quadros da câmera podem ser legíveis fora do ambiente de execução isolado para apoiar operações como a visualização para a inscrição, mas ainda não deve ser alterável.
- [C-2-7] não deve permitir acesso não criptografado a dados biométricos identificáveis ou a quaisquer dados derivados dele (como incorporação) ao processador de aplicativos fora do contexto da TEE ou da máquina virtual protegida controlada pelo hipervisor que atende aos requisitos na seção 9.17 . Os dispositivos de atualização lançados na versão 9 do Android ou anterior não estão isentos do C-2-7.
Se as implementações do dispositivo desejarem tratar um sensor biométrico como classe 3 (anteriormente forte ), eles:
- [C-SR-16] são fortemente recomendados para ter uma taxa de aceitação de paródia e impostor não superior a 7% por instrumento de ataque de apresentação (PAI) , conforme medido pelos protocolos de teste de biometria Android .
7.3.13. IEEE 802.1.15.4 (UWB) :
Veja revisão
Se as implementações do dispositivo incluirem suporte para 802.1.15.4 e expor a funcionalidade a um aplicativo de terceiros, eles:
- [C-1-2] deve relatar o recurso de hardware sinalizador
android.hardware.uwb
. - [C-1-3] deve suportar todos os seguintes conjuntos de configurações (combinações predefinidas dos parâmetros FIRA UCI ) definidos na implementação do AOSP.
-
CONFIG_ID_1
: unicastSTATIC STS DS-TWR
, modo diferido, intervalo de variação 240 ms. -
CONFIG_ID_2
: FIRA definido por um para muitosSTATIC STS DS-TWR
, Modo adiado, intervalo de variação de 200 ms. Caso de uso típico: o smartphone interage com muitos dispositivos inteligentes. -
CONFIG_ID_3
: o mesmo que os dadosCONFIG_ID_1
, exceto o ângulo de chegada (AOA), não são relatados. -
CONFIG_ID_4
: o mesmo queCONFIG_ID_1
, exceto que o modo de segurança P-STS está ativado. -
CONFIG_ID_5
: o mesmo queCONFIG_ID_2
, exceto que o modo de segurança P-STS está ativado. -
CONFIG_ID_6
: o mesmo queCONFIG_ID_3
, exceto que o modo de segurança P-STS está ativado. -
CONFIG_ID_7
: o mesmo queCONFIG_ID_2
, exceto que o modo de chave controlista individual P-STS está ativado.
-
- [C-1-4] deve fornecer uma possibilidade de um usuário para permitir que o usuário atenda o estado de rádio UWB ON/OFF.
- [C-1-5] deve aplicar que os aplicativos usando o Rádio UWB mantenham a permissão
UWB_RANGING
(no grupo de permissãoNEARBY_DEVICES
).
A aprovação nos testes relevantes de conformidade e certificação definidos por organizações padrão, incluindo FIRA , CCC e CSA, ajuda a garantir que o 802.1.15.4 funcione corretamente.
- [C-1-2] deve relatar o recurso de hardware sinalizador
Veja revisão
“Telefonia”, conforme usado pelas APIs do Android e este documento se refere especificamente a hardware relacionado à colocação de chamadas de voz e envio de mensagens SMS ou estabelecendo dados móveis por meio de uma rede móvel (por exemplo, GSM, CDMA, LTE, NR) GSM ou CDMA. Um dispositivo que suporta "telefonia" pode optar por oferecer algumas ou todas as chamadas, mensagens e serviços de dados, como se encaixa no produto.
através de uma rede GSM ou CDMA. Embora essas chamadas de voz possam ou não ser comutadas por pacotes, elas são para fins de Android considerados independentes de qualquer conectividade de dados que possam ser implementados usando a mesma rede. Em outras palavras, a funcionalidade de “telefonia” do Android e as APIs se refere especificamente a chamadas de voz e SMS. Por exemplo, as implementações do dispositivo que não podem fazer chamadas ou enviar/receber mensagens SMS não são consideradas um dispositivo de telefonia, independentemente de usarem uma rede celular para conectividade de dados.Veja revisão
Se as implementações do dispositivo incluirem suporte para 802.11 e expor a funcionalidade a um aplicativo de terceiros, eles:
- [C-1-4] deve suportar DNs multicast (MDNs) e não devem filtrar pacotes MDNS (224.0.0.251 ou FF02 :: FB ) em qualquer momento de operação, inclusive quando a tela não estiver em um estado ativo, a menos que cair ou A filtragem desses pacotes é necessária para permanecer dentro das faixas de consumo de energia exigidas pelos requisitos regulatórios aplicáveis ao mercado -alvo.
Para implementações de dispositivos de televisão Android, mesmo quando em estados de energia em espera.
- [C-1-4] deve suportar DNs multicast (MDNs) e não devem filtrar pacotes MDNS (224.0.0.251 ou FF02 :: FB ) em qualquer momento de operação, inclusive quando a tela não estiver em um estado ativo, a menos que cair ou A filtragem desses pacotes é necessária para permanecer dentro das faixas de consumo de energia exigidas pelos requisitos regulatórios aplicáveis ao mercado -alvo.
Veja revisão
Se as implementações do dispositivo declararem festere_bluetooth_le, elas:
- [C-SR-2] são fortemente recomendados para medir e compensar o deslocamento RX para garantir que o RSSI mediano seja -60dbm +/- 10 dB a 1 m de distância de um dispositivo de referência transmitindo em
ADVERTISE_TX_POWER_HIGH
, onde os dispositivos são orientados para que sejam Em 'Planos Parallel', com telas voltadas para a mesma direção. - [C-SR-3] são fortemente recomendados para medir e compensar o deslocamento do TX para garantir que o RSSI mediano seja de -60dbm +/- 10 dB quando a digitalização de um dispositivo de referência posicionado a 1 m de distância e transmitindo em
ADVERTISE_TX_POWER_HIGH
, onde os dispositivos são orientados de modo que eles estejam em 'aviões paralelos' com telas voltadas para a mesma direção.
- [C-10-3] deve medir e compensar o deslocamento RX para garantir que o RSSI mediano de BLE seja -55dbm +/- 10 dB a 1 m de distância de um dispositivo de referência que transmite em
ADVERTISE_TX_POWER_HIGH
. - [C-10-4] deve medir e compensar o deslocamento do TX para garantir que o RSSI mediano de BLE seja -55dbm +/- 10 dB ao digitalizar a partir de um dispositivo de referência posicionado a 1 m de distância e transmitindo em
ADVERTISE_TX_POWER_HIGH
.
Se as implementações do dispositivo suportarem a versão 5.0 do Bluetooth, elas: elas:
- [C-SR-4] são fortemente recomendados para fornecer suporte para:
- Le 2M Phy
- Le codec phy
- Extensão de publicidade
- Publicidade periódica
- Pelo menos 10 conjuntos de anúncios
- Pelo menos 8 conexões simultâneas. Cada conexão pode estar em ambos os papéis de topologia de conexão.
- Privacidade da camada de link
- Um tamanho de "lista de resolução" de pelo menos 8 entradas
- [C-SR-2] são fortemente recomendados para medir e compensar o deslocamento RX para garantir que o RSSI mediano seja -60dbm +/- 10 dB a 1 m de distância de um dispositivo de referência transmitindo em
Veja revisão
- [C-1-7] deve garantir que a mediana das medições de distância a 1 m do dispositivo de referência esteja dentro de [0,75m, 1,25m], onde a distância da verdade do solo é medida a partir da borda superior do DUT.
Segurou a face para cima e inclinou 45 graus.
- [C-1-7] deve garantir que a mediana das medições de distância a 1 m do dispositivo de referência esteja dentro de [0,75m, 1,25m], onde a distância da verdade do solo é medida a partir da borda superior do DUT.
7.5.1. Câmera voltada para trás :
Veja revisão
Uma câmera traseira é uma câmera localizada na lateral do dispositivo em frente à tela; Ou seja, imagens de cenas do outro lado do dispositivo, como uma câmera tradicional.
Uma câmera voltada para trás é uma câmera voltada para o mundo que imagens de cenas no lado oposto do dispositivo, como uma câmera tradicional; Em dispositivos portáteis, essa é uma câmera localizada na lateral do dispositivo em frente à tela.
Veja revisão
Uma câmera frontal é uma câmera localizada no mesmo lado do dispositivo que a tela; Ou seja, uma câmera normalmente usada para imaginar o usuário, como para videoconferência e aplicativos semelhantes.
Uma câmera frontal é uma câmera voltada para o usuário que normalmente é usada para imaginar o usuário, como para videoconferência e aplicativos semelhantes; Em dispositivos portáteis, essa é uma câmera localizada no mesmo lado do dispositivo que a tela.
Veja revisão
Uma câmera externa é uma câmera que pode ser fisicamente anexada ou destacada da implementação do dispositivo a qualquer momento e pode enfrentar qualquer direção; como câmeras USB.
7.5.4. Comportamento da API da câmera :
Veja revisão
As implementações do dispositivo devem implementar os seguintes comportamentos para as APIs relacionadas à câmera, para todas as câmeras disponíveis. Implementações de dispositivos:
- [C-SR-1] Para dispositivos com várias câmeras RGB nas proximidades e voltados para a mesma direção, é fortemente recomendável suportar um dispositivo de câmera lógica que lista a capacidade
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
, consistindo em todas as câmeras RGB FACANTES como sub-dispositivos físicos.
- [C-SR-1] Para dispositivos com várias câmeras RGB nas proximidades e voltados para a mesma direção, é fortemente recomendável suportar um dispositivo de câmera lógica que lista a capacidade
Veja revisão
Os dispositivos que atendem a todos os critérios a seguir estão isentos do requisito acima:
- As implementações de dispositivos que não são capazes de serem giradas pelo usuário, como dispositivos automotivos.
Veja revisão
Os dispositivos destinados a serem usados ou usados podem incluir um atuador háptico de uso geral, disponível para aplicações para fins, incluindo a atenção através de toques, alarmes, notificações e feedback geral do toque.
Se as implementações de dispositivos não incluirem um atuador háptico de propósito geral, eles:
- [7.10/c] devem retornar false para
Vibrator.hasVibrator()
.
Se as implementações do dispositivo incluirem pelo menos um desses atuadores híticos de uso geral, eles:
- [C-1-1] deve retornar true para
Vibrator.hasVibrator()
. - Não deve usar um atuador héptico excêntrico de massa rotativa (ERM) (vibrador).
- SHOULD implement all public constants for clear haptics in
android.view.HapticFeedbackConstants
namely (CLOCK_TICK
,CONTEXT_CLICK
,KEYBOARD_PRESS
,KEYBOARD_RELEASE
,KEYBOARD_TAP
,LONG_PRESS
,TEXT_HANDLE_MOVE
,VIRTUAL_KEY
,VIRTUAL_KEY_RELEASE
,CONFIRM
,REJECT
,GESTURE_START
andGESTURE_END
). - Deve implementar todas as constantes públicas para haptics claros em
android.os.VibrationEffect
nomeadamente (EFFECT_TICK
,EFFECT_CLICK
,EFFECT_HEAVY_CLICK
eEFFECT_DOUBLE_CLICK
) e todos osPRIMITIVE_*
constantes para ricos em haptics inandroid.os.VibrationEffect.Composition
(CLICK
,, cliques,TICK
,LOW_TICK
in Android.QUICK_FALL
,QUICK_RISE
,SLOW_RISE
,SPIN
,THUD
). Algumas dessas primitivas, comoLOW_TICK
eSPIN
podem ser viáveis apenas se o vibrador puder suportar frequências relativamente baixas. - Deve seguir as orientações para mapear constantes públicas em
android.view.HapticFeedbackConstants
para as constantes recomendadasandroid.os.VibrationEffect
, com as relações de amplitude correspondentes. - Deve usar esses mapeamentos de constantes hápticos vinculados.
- Deve seguir a avaliação da qualidade para as APIs
createOneShot()
ecreateWaveform()
. - Deve verificar se o resultado da API
android.os.Vibrator.hasAmplitudeControl()
reflete corretamente as capacidades de seus vibradores. - Deve verificar os recursos de escalabilidade da amplitude executando
android.os.Vibrator.hasAmplitudeControl()
.
Se as implementações do dispositivo seguirem o mapeamento de constantes hápticos, eles:
- Deve verificar o status de implementação executando
android.os.Vibrator.areAllEffectsSupported()
eandroid.os.Vibrator.arePrimitivesSupported()
APIs. - Deve realizar uma avaliação de qualidade para constantes hápticas.
- Deve verificar e atualizar, se necessário, a configuração de fallback para primitivas não suportadas, conforme descrito nas orientações de implementação para constantes.
- Deve fornecer suporte de fallback para mitigar o risco de falha, conforme descrito aqui .
Consulte a Seção 2.2.1 para obter requisitos específicos do dispositivo.
- [7.10/c] devem retornar false para
9. Compatibilidade do modelo de segurança
Veja revisão
Implementações de dispositivos:
- [C-0-4] deve ter uma e apenas uma implementação de ambas as interfaces de usuário.
Se as implementações do dispositivo pré-instalam os pacotes que mantêm qualquer inteligência da interface do usuário do sistema , inteligência de áudio ambiental do sistema , inteligência de áudio do sistema , inteligência de notificação do sistema , inteligência de texto do sistema ou funções de inteligência visual do sistema , os pacotes:
- [C-4-1] MUST fulfill all requirements outlined for device implementations in sections
"9.8.6 Content Capture""9.8.6 OS-level and ambient data and 9.8.15 Sandboxed API implementations".
- [C-4-2] MUST NOT have android.permission.INTERNET permission. This is stricter than the STRONGLY RECOMMENDED listed in section 9.8.6.
- [C-4-3] MUST NOT bind to other apps, except for the following system apps: Bluetooth, Contacts, Media, Telephony, SystemUI, and components providing Internet APIs. This is stricter than the STRONGLY RECOMMENDED listed in section 9.8.6.
If device implementations include a default application to support the
VoiceInteractionService
they:- [C-5-1] MUST NOT grant
ACCESS_FINE_LOCATION
as the default for that application.
See revision
If device implementations create the additional user profile discussed above, then they:
- [C-4-5] MUST visually distinguish the dual instance application icons when the icons are presented to users.
- [C-4-6] MUST provide a user-affordance to delete entire clone profile data.
- [C-4-7] MUST uninstall all Clone apps, delete the private app data directories and their content, and delete Clone profile data, when the user chooses to delete entire Clone profile data.
- SHOULD prompt the user to delete entire Clone Profile data when the last clone app is deleted.
- [C-4-8] MUST inform the user that app data will be deleted when the clone application is uninstalled, or provide an option to users to keep app data when the application is uninstalled from the device.
- [C-4-9] MUST delete the private app data directories and their content, when the user chooses to delete the data during uninstall.
[C-4-1] MUST allow the below intents originating from the additional profile to be handled by applications of the primary user on the device:
-
Intent.ACTION_VIEW
-
Intent.ACTION_SENDTO
-
Intent.ACTION_SEND
-
Intent.ACTION_EDIT
-
Intent.ACTION_INSERT
-
Intent.ACTION_INSERT_OR_EDIT
-
Intent.ACTION_SEND_MULTIPLE
-
Intent.ACTION_PICK
-
Intent.ACTION_GET_CONTENT
-
MediaStore.ACTION_IMAGE_CAPTURE
-
MediaStore.ACTION_VIDEO_CAPTURE
-
[C-4-2] MUST inherit all device policy user restrictions and selected non-user restrictions(list below) applied on the primary user of the device to this additional user profile.
[C-4-3] MUST only allow writing contacts from this additional profile via the following intents:
[C-4-4] MUST NOT have contact syncs running for applications running in this additional user profile.
- [C-4-14] MUST have separate permission and storage management for the applications running in this additional profile
- [C-4-5] MUST only allow applications in the additional profile that have a launcher activity to access contacts that are already accessible to the parent user profile.
See revision
A Memory Safety technology is a technology that mitigates at least the following classes of bugs with a high (> 90%) probability in applications that use the
android:memtagMode
manifest option:- heap buffer overflow
- use after free
- double free
- wild free (free of a non-malloc pointer)
Device implementations:
- [C-SR-15] Are STRONGLY RECOMMENDED to set
ro.arm64.memtag.bootctl_supported
.
If device implementations set the system property
ro.arm64.memtag.bootctl_supported
to true, they:[C-3-1] MUST allow the system property
arm64.memtag.bootctl
to accept a comma-separated list of the following values, with the desired effect applied on the next subsequent reboot:-
memtag
: a Memory Safety technology as defined above is enabled -
memtag-once
: a Memory Safety technology as defined above is transiently enabled, and is automatically disabled upon, next reboot -
memtag-off
: a Memory Safety technology as defined above is disabled
-
[C-3-2] MUST allow the shell user to set
arm64.memtag.bootctl
.[C-3-3] MUST allow any process to read
arm64.memtag.bootctl
.[C-3-4] MUST set
arm64.memtag.bootctl
to the currently requested state upon boot, it MUST also update the property, if the device implementation allows to modify the state without changing the system property.[C-SR-16] Are STRONGLY RECOMMENDED to show a Developer Setting that sets memtag-once and reboots the device. With a compatible bootloader, the Android Open Source Project meets the above requirements through the MTE bootloader protocol .
- [C-SR-17] Are STRONGLY RECOMMENDED to show a Setting in the Security Settings menu that allows the user to enable
memtag
.
See revision
Device implementations:
- [C-0-2] MUST display a user warning and obtain explicit user consent allowing any sensitive information that is displayed on the user's screen to be captured
enabled that includes exactly the same message as AOSPwhenevereach and every time a session to capture the screencasting or screen recordingisenabledstarted via theMediaProjection.createVirtualDisplay()
,VirtualDeviceManager.createVirtualDisplay()
, or proprietary APIs.MUST NOT provide users an affordance to disable future display of the user consent.
[C-SR-1] Are STRONGLY RECOMMENDED to display a user warning which is exactly the same message as implemented in AOSP but CAN be altered as long as the message clearly warns the user that any sensitive information on the user's screen is captured.
[C-0-4] MUST NOT provide users an affordance to disable future prompts of the user consent to capture the screen, unless the session is started by a system app that the user has allowed to
associate()
with theandroid.app.role.COMPANION_DEVICE_APP_STREAMING
or theandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING
device profile.
- [C-0-2] MUST display a user warning and obtain explicit user consent allowing any sensitive information that is displayed on the user's screen to be captured
9.8.6. OS-level and ambient data : This section was renamed from Content Capture and App Search to OS-level and ambient data .
See revision
Android, through the System APIs
, supports a mechanism for device implementations to capture the followingContentCaptureService
,AugmentedAutofillService
,AppSearchGlobalManager.query
, or by other proprietary meansapplication data interactions between the applications and the usersensitive data :- Any screen or other data sent via the
AugmentedAutofillService
to the system. - Any screen or other data accessible via
Content Capture
API. - Any screen or other data accessible via
FieldClassificationService
API - Any application data passed to the system via the
AppSearchManager
API and accessible viaAppSearchGlobalManager.query
.
- Any other events that an application provides to the system via the
Content Capture
API or orAppSearchManager
API a similarly capable Android and proprietary API.
- Audio data obtained as a result of using
SpeechRecognizer#onDeviceSpeechRecognizer()
by the Speech Recognizer Implementation. - Audio data obtained in background (continuously) through
AudioRecord
,SoundTrigger
or other Audio APIs, and not resulting in a user-visible indicator - Camera data obtained in background (continuously) through CameraManager or other Camera APIs, and not resulting in a user-visible indicator
If device implementations capture any of the data above, they:
[C-1-3] MUST only send all such data
and the logoff the device using a privacy-preserving mechanism , except with explicit user consent every time the data is shared . The privacy-preserving mechanism is defined as “those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users”, to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such asRAPPOR
).[C-1-5] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.6
Content CaptureOS-level and ambient data ), except with explicit user consent every time it is compartilhado. Unless such functionality is built as an Android SDK API (AmbientContext
,HotwordDetectionService
).[C-1-6] MUST provide user affordance to erase such data that the
implementation or the proprietary means collectsContentCaptureService
ifwhen the data is stored in any form on the device. If the user chooses to erase the data, MUST remove all collected historical data.
- [C-SR-3] Are STRONGLY RECOMMENDED to be implemented with Android SDK API or a similar OEM-owned open-source repository; and / or be performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementations).
Android, through
SpeechRecognizer#onDeviceSpeechRecognizer()
provides ability to perform speech recognition on the device, without involving the network. Any implementation of on-device SpeechRecognizer MUST follow the policies outlined in this section.- Any screen or other data sent via the
9.8.10. Connectivity Bug Report :
See revision
If device implementations declare the
android.hardware.telephony
feature flag, they:- [C-1-4] Reports generated using
BUGREPORT_MODE_TELEPHONY
MUST contain at least the following information:-
SubscriptionManagerService
dump
-
- [C-1-4] Reports generated using
9.8.14. Credential Manager : Removed
9.8.15. Sandboxed API Implementations : New section
See revision
Android, through a set of delegate APIs provides a mechanism to process secure OS-level and ambient data. Such processing can be delegated to a preinstalled apk with privileged access and reduced communication capabilities, known as a Sandboxed API Implementation.
Any Sandboxed API implementation:
- [C-0-1] MUST NOT request the INTERNET permission.
- [C-0-2] MUST only access the internet through structured APIs backed by publicly available open-source implementations using privacy-preserving mechanisms, or indirectly via Android SDK APIs. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST keep the services separate from other system components (eg not binding the service or sharing process IDs) except for the following:
- Telephony, Contacts, System UI, and Media
- [C-0-4] MUST NOT allow users to replace the services with a user-installable application or service
- [C-0-5] MUST only allow the preinstalled services to capture such data. Unless the replacement capability is built into AOSP (eg for Digital Assistant Apps).
- [C-0-6] MUST NOT allow any apps other than the preinstalled services mechanism to be able to capture such data. Unless such capture capability is implemented with an Android SDK API.
- [C-0-7] MUST provide user affordance to disable the services.
- [C-0-8] MUST NOT omit user affordance to manage Android permissions that are held by the services and follow the Android permissions model as described in Section 9.1. Permission .
9.8.16. Continuous Audio and Camera data : New section
See revision
In addition to requirements outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, and 9.8.15 Sandboxed API implementations, implementations that make use of Audio data obtained in background (continuously) through AudioRecord, SoundTrigger or other Audio APIs OR Camera data obtained in background (continuously) through CameraManager or other Camera APIs:
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
- This access is performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementation), through a package holding one or more of the following roles: System UI Intelligence , System Ambient Audio Intelligence , System Audio Intelligence , System Notification Intelligence , System Text Intelligence , or System Visual Intelligence .
- The access is performed through a sandbox, implemented and enforced via mechanisms in AOSP (
HotwordDetectionService
,WearableSensingService
,VisualQueryDetector
). - Audio access is performed for assistive purposes by the Digital Assistant application, supplying
SOURCE_HOTWORD
as an audio source. - The access is performed by the system and implemented with open-source code.
- [C-SR-1] Is STRONGLY RECOMMENDED to require user consent for every functionality utilizing such data, and be disabled by default.
- [C-SR-2] STRONGLY RECOMMENDED to apply the same treatment (ie follow the restrictions outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, 9.8.15 Sandboxed API implementations, and 9.8.16 Continuous Audio and Camera data) to Camera data coming from a remote wearable device.
If the Camera data is supplied from a remote wearable device and accessed in an unencrypted form outside Android OS, sandboxed implementation or a sandboxed functionality built by
WearableSensingManager
, then they:- [C-1-1] MUST indicate to the remote wearable device to display an additional indicator there.
If devices provide capability to engage with a Digital Assistant Application without the assigned keyword (either handling generic user queries, or analyzing user presence through camera):
- [C-2-1] MUST ensure such implementation is provided by a package holding the
android.app.role.ASSISTANT
role. - [C-2-2] MUST ensure such implementation utilizes
HotwordDetectionService
and/orVisualQueryDetectionService
Android APIs.
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
9.8.17. Telemetry : New section
See revision
Android stores system and app logs using StatsLog APIs. These logs are managed via StatsManager APIs which can be used by privileged system applications.
StatsManager also provides a way to collect data categorized as privacy sensitive from devices with a privacy preserving mechanism. In particular,
StatsManager::query
API provides the ability to query restricted metric categories defined in StatsLog .Any implementation querying and collecting restricted metrics from StatsManager:
- [C-0-1] MUST be the sole application/implementation on the device and hold the
READ_RESTRICTED_STATS
permission. - [C-0-2] MUST only send telemetry data and the log of the device using a privacy-preserving mechanism. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST NOT associate such data with any user identity (such as Account ) on the device.
- [C-0-4] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.17 Privacy-preserving Telemetry).
- [C-0-5] MUST provide a user affordance to enable/disable privacy-preserving telemetry collection, use, and sharing.
- [C-0-6] MUST provide user affordance to erase such data that the implementation collects if the data is stored in any form on the device. If the user chose to erase the data, MUST remove all data currently stored on the device.
- [C-0-7] MUST disclose underlying privacy-preserving protocol implementation in an open source repository.
- [C-0-8 ]MUST enforce data egress policies in this section to gate collection of data in restricted metric categories defined in StatsLog .
- [C-0-1] MUST be the sole application/implementation on the device and hold the
See revision
Device implementationsIf device implementations have the ability to verify file content on the per-page basis, then they :
[
C-0-3C-2-1 ] support cryptographically verifying file contentagainst a trusted keywithout reading the whole file.[
C-0-4C-2-2 ] MUST NOT allow the read requests on a protected file to succeed when the read contentdo not verify against a trusted keyis not verified per [C-2-1] above .
- [C-2-4] MUST return file checksum in O(1) for enabled files.
See revision
The Android Keystore System allows app developers to store cryptographic keys in a container and use them in cryptographic operations through the KeyChain API or the Keystore API . Device implementations:
- [C-0-3] MUST limit the number of failed primary authentication attempts.
- [C-SR-2] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations add or modify the authentication methods to unlock the lock screen if based on a known secret and use a new authentication method to be treated as a secure way to lock the screen, then:
- [C-SR-3] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-2-1] A PIN of a length less than 6 digits MUST NOT allow automatic entry without user interaction to avoid revealing the PIN length.
9.11.1. Secure Lock Screen, Authentication and Virtual Devices :
See revision
Device implementations:
- [C-0-1] MUST limit the number of failed primary authentication attempts.
- [C-SR-5] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations set a numerical PIN as the recommended primary authentication method, then:
- [C-SR-6] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-SR-7] A PIN of a length less than 6 digits is STRONGLY RECOMMENDED NOT to allow automatic entry without user interaction to avoid revealing the PIN length.
If device implementations have a secure lock screen and include one or more trust agent, which implements the
TrustAgentService
System API, they:[C-7-8] The user MUST be challenged for one of the recommended primary authentication (eg: PIN, pattern, password) methods at least once every 72 hours or less unless the safety of the user (eg driver distraction) is of preocupação.If device implementations allow applications to create secondary virtual displays and support associated input events such as via VirtualDeviceManager and the displays are not marked with VIRTUAL_DISPLAY_FLAG_SECURE, they:
[C-13-10] MUST disable installation of apps initiated from virtual devices.9.17. Android Virtualization Framework :
See revision
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), the Android host:- [C-1-1] MUST support all the APIs defined by the
android.system.virtualmachine
package. - [C-1-2] MUST NOT modify the Android SELinux and permission model for the management of Protected Virtual Machines (pVM) .
- [C-1-3] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow rules present.
- [C-1-4] MUST only allow platform signed code & privileged apps
MUST NOT allow untrusted code (eg 3p apps)to create and run aProtected Virtual MachinepVM . Note: This might change in future Android releases.
- [C-1-5] MUST NOT allow a
Protected Virtual MachinepVM to execute code that is not part of the factory image or their updates.Anything that is not covered by Android Verified Boot (eg files downloaded from the Internet or sideloaded) MUST NOT be allowed to be run in a Protected Virtual Machine.
- [C-1-5] MUST only allow a non-debuggable pVM to execute code from the factory image or their platform updates which also includes any updates to privileged apps.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), then anyProtected Virtual MachinepVM instance:- [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a
Protected Virtual MachinepVM . - [C-2-2] MUST NOT allow a
Protected Virtual MachinepVM to run an operating system that is not signed by the device implementor or OS vendor. - [C-2-3] MUST NOT allow a
Protected Virtual MachinepVM to execute data as code (eg SELinux neverallow execmem).
- [C-2-4] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy/microdroid provided in the upstream Android Open Source Project (AOSP).
- [C-2-5] MUST implement
Protected Virtual MachinepVM defense-in-depth mechanisms (eg SELinux for pVMs) even for non-Microdroid operating systems. - [C-2-6] MUST ensure that the pVM fails
firmware refusesto boot ifit cannot verify the initialimages that the VM will run cannot be verified. The verification MUST be done inside the VM. - [C-2-7] MUST ensure that the pVM fails
firmware refusesto boot if the integrity of the instance.img is compromised.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), then the hypervisor:- [C-3-1] MUST ensure that memory pages exclusively owned by a VM (either pVM or host VM) are accessible only to the virtual machine itself or the hypervisor, not by other virtual machines - either protected or non-protected.
MUST NOT allow any pVM to have access to a page belonging to another entity (ie other pVM or hypervisor), unless explicitly shared by the page owner. This includes the host VM. This applies to both CPU and DMA accesses. - [C-3-2] MUST wipe a page after it is used by a pVM and before it is returned to the host (eg the pVM is destroyed).
- [C-
3-3SR-1 ] Is STRONGLY RECOMMENDED to ensureMUST ensurethat that the pVM firmware is loaded and executed prior to any code in a pVM. - [C-3-4] MUST ensure that each VM derives a per-VM secret which
{Boot Certificate Chain (BCC) and Compound Device Identifier (CDIs) provided to a pVM instancecan only be derived by that particular VM instance and changes upon factory reset and OTA.
If the device implements support for the Android Virtualization Framework APIs, then across all areas:
- [C-4-1] MUST NOT provide functionality to a pVM that allows bypassing the Android Security Model.
If the device implements support for the Android Virtualization Framework APIs, then:
- [C-5-1] MUST be capable to support Isolated Compilation but may disable Isolated Compilation feature on the device shipment
of an ART runtime update.
If the device implements support for the Android Virtualization Framework APIs, then for Key Management:
- [C-6-1] MUST root DICE chain at a point that the user cannot modify, even on unlocked devices. (To ensure it cannot be spoofed).
- [C- SR-2
6-2] Is STRONGLY RECOMMENDED to use DICE as the per-VM secret derivation mechanism.MUST do DICE properly ie provide the correct values.
- [C-1-1] MUST support all the APIs defined by the