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 KiB |
Número mínimo de sessões simultâneas | 30 |
Número mínimo de chaves por sessão | 20 |
Número total mínimo de chaves (todas as sessões) | 80 |
Número total mínimo de chaves DRM (todas 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 tal API de câmera usando
android.hardware.camera2
API ou Extended View System API.
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 quaisquer monitores.
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 possibilidade 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 de intenção NfcAdapter.ACTION_TRANSACTION_DETECTED (como “EVT_TRANSACTION” definido pela especificação técnica TS.26 da GSM Association - Requisitos do aparelho NFC) .
3.3.1. Interfaces binárias do aplicativo :
Ver revisão
Implementações de dispositivos:
- [C-0-12] DEVE exportar símbolos de função para os símbolos de função principais
do Vulkan 1.0Vulkan 1.1 , bem como as extensõesVK_KHR_surface
,VK_KHR_android_surface
,VK_KHR_swapchain
,VK_KHR_maintenance1
eVK_KHR_get_physical_device_properties2
por meio da bibliotecalibvulkan.so
. Observe que embora todos os símbolos DEVEM estar presentes, a seção 7.1.4.2 descreve com mais detalhes os requisitos para quando a implementação completa de cada função correspondente é esperada.
- [C-0-12] DEVE exportar símbolos de função para os símbolos de função principais
Ver revisão
Se as implementações de dispositivos incluírem uma tela ou saída de vídeo, elas:
- [C-1-5] DEVE gerar paletas de tons de cores dinâmicas usando estilos de tema de cores enumerados na documentação
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
(consulteandroid.theme.customization.theme_styles
), ou seja,TONAL_SPOT
,VIBRANT
,EXPRESSIVE
,SPRITZ
,RAINBOW
,FRUIT_SALAD
eMONOCHROMATIC
.
- [C-1-5] DEVE gerar paletas de tons de cores dinâmicas usando estilos de tema de cores enumerados na documentação
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:
- [C-1-2] DEVE implementar o comportamento de fixação de tela e fornecer ao usuário um menu de configurações para alternar o recurso.
3.9.2 Suporte a perfil gerenciado :
Ver revisão
Se as implementações de dispositivos 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 for capturada com uma janela
topActivity
que tenha foco (aquela com a qual o usuário interagiu por último entre todas as atividades) e pertença a um perfil de trabalho aplicativo . - [C-1-11] NÃO DEVE capturar qualquer outro conteúdo da tela (barra do sistema, notificações ou qualquer conteúdo do perfil pessoal), exceto as janelas/janelas do aplicativo do 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 for capturada com uma janela
3.9.5 Estrutura de resolução de políticas de dispositivos : nova seção
Ver revisão
Se as implementações de dispositivos reportarem
android.software.device_admin
ouandroid.software.managed_users
, então elas:- [C-1-1] DEVE resolver conflitos de políticas de dispositivos conforme documentado na documentação do AOSP.
5. Compatibilidade multimídia
5.1.4. Codificação de imagem :
Ver revisão
As implementações de dispositivos DEVEM suportar a codificação da seguinte codificação de imagem:
- [C-0-4] AVIF
- Os dispositivos devem suportar
BITRATE_MODE_CQ
e perfil de linha de base.
- Os dispositivos devem suportar
- [C-0-4] AVIF
5.1.5. Decodificação de imagem :
Ver revisão
As implementações de dispositivos DEVEM suportar a decodificação da seguinte codificação de imagem:
[C-0-7] AVIF (perfil de linha de base)
5.1.6. Detalhes dos codecs de imagem :
Ver revisão
Formato/Codec Detalhes Tipos de arquivo/formatos de contêiner suportados JPEG Base+progressiva JPEG (.jpg) GIFs GIF (.gif) png PNG (.png) Veículo de combate de infantaria 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) HEIF Imagem, Coleção de imagens, Sequência de imagens HEIF (.heif), HEIC (.heic) AVIF (perfil de linha de base) Imagem, coleção de imagens, perfil de linha de base da sequência de imagens Contêiner HEIF (.avif) 5.1.8. Lista de codecs de vídeo :
Ver 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ção)
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 pesquisável)
- Matroska (.mkv, apenas decodificação)
H.265 HEVC Consulte a seção 5.3 para obter detalhes - MPEG-4 (.mp4)
- Matroska (.mkv, apenas decodificação)
MPEG-2 Perfil Principal - MPEG2-TS (.ts, não pesquisável)
- MPEG-4 (.mp4, apenas decodificação)
- Matroska (.mkv, apenas decodificação)
MPEG-4SP - 3GPP (.3gp)
- MPEG-4 (.mp4)
- Matroska (.mkv, apenas decodificação)
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 a seção 5.3 para obter detalhes - MPEG-4 (.mp4)
- Matroska (.mkv, apenas decodificação)
5.1.10. Caracterização do Codec de Mídia :
Ver revisão
Se as implementações de dispositivos 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) Alta definição 720p HD 1080p Ultra HD Resolução de vídeo - 176 x 144 pixels (H263, MPEG2, MPEG4)
- 352 x 288 px (codificador MPEG4, H263, MPEG2)
- 320 x 180 pixels (VP8, VP8)
- 320 x 240 px (outro)
- 704 x 576 pixels (H263)
- 640 x 360 pixels (VP8, VP9)
- 640 x 480 px (codificador MPEG4)
- 720 x 480 px (outro, AV1 )
- 1408 x 1152 pixels (H263)
- 1280 x 720 px (outro, AV1 )
1920 x 1080 px (exceto MPEG4, AV1 ) 3840 x 2160 pixels (HEVC, VP9, AV1 ) Ver revisão
Se as implementações de dispositivos oferecerem suporte a qualquer codificador de vídeo e o disponibilizarem para aplicativos de terceiros, elas:- NÃO DEVE ser, em duas janelas deslizantes, mais de 15% acima da taxa de bits entre os intervalos intraframe (quadro I).
- NÃO DEVE ser superior a 100% da taxa de bits em uma janela deslizante de 1 segundo.
Se as implementações do dispositivo suportarem qualquer codificador de vídeo e o disponibilizarem para aplicativos de terceiros, e definir 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 mínimo de qualidade , a taxa de bits codificada:-
[C-5-1] NÃO DEVEser , em uma janela deslizante, mais de 15% acima da taxa de bits entre os intervalos intraquadro (quadro I). -
[C-5-2] NÃO DEVEser superior a 100% da taxa de bits em uma janela deslizante de 1 segundo.
Se as implementações do dispositivo suportarem qualquer codificador de vídeo e o disponibilizarem para aplicativos de terceiros e definirem
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% acima da taxa de bits alvo em uma janela deslizante de 1 segundo.
Ver revisão
Se as implementações de dispositivos suportarem codificadores H.263 e os disponibilizarem para aplicativos de terceiros, elas:
- [C-1-1] DEVE suportar a resolução QCIF (176 x 144) usando o nível de perfil de linha de base 45. A resolução SQCIF é opcional.
-
DEVE suportar taxas de bits configuráveis dinamicamente para o codificador suportado.
Ver revisão
Se as implementações de dispositivos suportarem o codec H.265, elas:
- [C-1-1] DEVE suportar o nível de perfil principal 3 com resolução de até 512 x 512 .
-
DEVE suportar os perfis de codificação HD conforme indicado na tabela a seguir. - [C-SR-1] são FORTEMENTE RECOMENDADOS para suportar 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
Ver revisão
Se as implementações de dispositivos suportarem o codec AV1, elas:
- [C-1-1] DEVE oferecer suporte ao perfil principal, incluindo conteúdo de 8 e 10 bits.
[C-1-2] DEVE publicar dados de desempenho, ou seja, relatar dados de desempenho por meio das APIs
getSupportedFrameRatesFor()
ougetSupportedPerformancePoints()
para resoluções suportadas na tabela abaixo.[C-1-3] DEVE aceitar metadados HDR e enviá-los para o fluxo de bits
Se o codificador AV1 for acelerado por hardware, então:
- [C-2-1] DEVE suportar até e incluindo o perfil de codificação HD1080p da tabela abaixo:
SD Alta definição 720p HD 1080p Ultra HD Resolução de vídeo 720 x 480 pixels 1280 x 720 pixels 1920 x 1080 pixels 3840 x 2160 pixels Taxa de quadros de vídeo 30fps 30fps 30fps 30fps Taxa de bits de vídeo 5Mbps 8Mbps 16Mbps 50Mbps Ver revisão
Se as implementações de dispositivos suportarem decodificadores H.263, elas:
- [C-1-1] DEVE suportar o perfil de linha de base nível 30 (resoluções CIF, QCIF e SQCIF a 30fps 384kbps) e nível 45 (resoluções QCIF e SQCIF a 30fps 128kbps) .
Ver revisão
Se as implementações de dispositivos suportarem o codec AV1, elas:- [C-1-1] DEVE suportar o Perfil 0, incluindo conteúdo de 10 bits.
Se as implementações de dispositivos suportarem o codec AV1 e o disponibilizarem para aplicativos de terceiros, elas:
- [C-1-1] DEVE oferecer suporte ao perfil principal, incluindo conteúdo de 8 e 10 bits.
Se as implementações de dispositivos fornecerem suporte para o codec AV1 com um decodificador acelerado por hardware, elas:
- [C-2-1] DEVE ser capaz de decodificar pelo menos 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 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 Alta definição 720p HD 1080p Ultra HD Resolução de vídeo 720 x 480 pixels 1280 x 720 pixels 1920 x 1080 pixels 3840 x 2160 pixels Taxa de quadros de vídeo 30fps 30fps 30fps 30fps Taxa de bits de vídeo 5Mbps 8Mbps 16Mbps 50Mbps Se as implementações de dispositivos oferecerem suporte ao perfil HDR por meio das APIs de mídia, elas:
- [C-3-1] DEVE suportar a extração e saída de metadados HDR do fluxo de bits 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. Captura para reconhecimento de voz :
Ver revisão
Se as implementações de dispositivos declararem
android.hardware.microphone
, elas:- DEVE definir a sensibilidade de entrada de áudio de forma que uma fonte de tom senoidal de 1000 Hz tocada a 90 dB de nível de pressão sonora (SPL) (medido
a uma distância de 30 cmpróximo ao microfone) produza uma resposta ideal de RMS 2500 dentro de uma faixa de 1770 e 3530 para amostras de 16 bits (ou -22,35 db ±3dB Full Scale para amostras de ponto flutuante/precisão dupla) para cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.
- DEVE definir a sensibilidade de entrada de áudio de forma que uma fonte de tom senoidal de 1000 Hz tocada a 90 dB de nível de pressão sonora (SPL) (medido
Ver revisão
Se as implementações de dispositivos declararem o recurso
android.hardware.audio.output
, elas:- [C-1-4] DEVE suportar efeitos de áudio com entrada e saída de ponto flutuante.
- [C-1-5] DEVE certificar-se de que os efeitos de áudio suportam vários canais até a contagem de canais do mixer, também conhecida como FCC_LIMIT.
Ver revisão
Se as implementações de dispositivos declararem
android.hardware.audio.output
, elas serão FORTEMENTE RECOMENDADAS para atender ou exceder os seguintes requisitos:- [C-SR-4] O carimbo de data/hora de saída retornado por AudioTrack.getTimestamp e
AAudioStream_getTimestamp
tem precisão de +/- 1 ms.
- [C-SR-4] As latências de ida e volta calculadas com base nos carimbos de data e hora de entrada e saída retornados por
AAudioStream_getTimestamp
são FORTEMENTE RECOMENDADAS para estarem dentro de 30 ms da latência de ida e volta medida paraAAUDIO_PERFORMANCE_MODE_NONE
eAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
para alto-falantes e fones de ouvido com e sem fio.
- [C-SR-4] O carimbo de data/hora de saída retornado por AudioTrack.getTimestamp e
7. Compatibilidade de Hardware
Ver revisão
O Android inclui recursos que ajustam automaticamente os recursos do aplicativo e os layouts da interface do usuário de forma adequada ao dispositivo, para garantir que os aplicativos de terceiros funcionem bem em
diversas configurações de hardware .variedade de exibições e configurações de hardware. Um monitor compatível com Android é uma tela que implementa todos os comportamentos e APIs descritos em Desenvolvedores Android – Visão geral da compatibilidade de tela , nesta seção (7.1) e suas subseções, bem como quaisquer comportamentos adicionais específicos do tipo de dispositivo documentados na seção 2 de este CDD.Nos monitores compatíveis com Android onde todos os aplicativos de terceiros compatíveis com Android podem ser executados, as implementações de dispositivos DEVEM implementar adequadamente essas APIs e comportamentos, conforme detalhado nesta seção.Iniciar novos requisitos
Implementações de dispositivos:
- [C-0-1] DEVE, por padrão, renderizar aplicativos de terceiros apenas em monitores compatíveis com Android.
As unidades referenciadas pelos requisitos desta 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 linear horizontal ou vertical de 1” , expresso como pixels por polegada (ppi ou dpi) . Onde os valoresde dpippi e dpi estão listados, tanto o dpi horizontal quanto o vertical devem estar dentro do intervalo listado . - proporção da tela . A proporçã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 A normalizada para uma densidade detela de 160 dpide 160. Para alguma densidade d e um número de 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 formato da tela :
Ver revisão
Se as implementações de dispositivos suportarem telas capazes de configurar o tamanho
UI_MODE_TYPE_NORMAL
e incluírem telas físicascompatíveis 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 exibição :
- O raio dos cantos arredondados é menor ou igual a 38 dp.
Quando uma caixa de 15 por 15 dp é ancorada em cada canto da exibição lógica, pelo menos um pixel de cada caixa fica visível na tela.
DEVE incluir recursos do usuário para alternar para o modo de exibição com cantos retangulares.
Iniciar novos requisitos
Se as implementações de dispositivos forem capazes apenas de configuração de teclado
NO_KEYS
e pretenderem relatar suporte para a configuração do modo UIUI_MODE_TYPE_NORMAL
, elas:- [C-4-1] DEVE ter um tamanho de layout, excluindo quaisquer recortes de exibição, de pelo menos 596 dp x 384 dp ou superior.
Se as implementações de dispositivos incluírem telas dobráveis compatíveis com Android ou incluírem uma dobradiça dobrável entre vários painéis de tela e disponibilizarem essas telas para renderizar aplicativos de terceiros, elas:
- [C-2-1] DEVE implementar a versão estável mais recente disponível da API de extensões ou a versão estável da API secundária a ser usada pela biblioteca Window Manager Jetpack .
Se as implementações de dispositivos incluírem telas dobráveis compatíveis com Android ou incluírem uma dobradiça dobrável entre vários painéis de tela e se a dobradiça ou dobra cruzar uma janela de aplicativo em tela cheia, elas:
- [C-3-1] DEVE relatar a posição, os limites e o estado da dobradiça ou dobra por meio de extensões ou APIs secundárias para o aplicativo.
Se as implementações de dispositivos incluírem uma ou mais áreas de exibição dobráveis compatíveis com Android ou incluírem uma dobradiça dobrável entre diversas áreas do painel de exibição compatíveis com Android e disponibilizarem essas áreas de exibição para aplicativos, elas:
- [C-4-1] DEVE implementar a versão correta do nível da API de extensões do Window Manager, conforme descrito na documentação futura.
7.1.1.2. Proporção da tela : removida
Ver revisão
Implementações de dispositivos:
- [C-0-1]
Por padrão, as implementações de dispositivosDEVEM relatarapenasuma das densidades da estrutura Android listadas noDisplayMetrics
por meio da APIDENSITY_DEVICE_STABLE
e esse valor deve ser um valor estático para cada exibição físicaNÃO DEVE mudar em nenhum momento; no entanto,no entanto , o dispositivo PODE relatar umadensidade arbitráriadiferenteDisplayMetrics.density
de acordo com as alterações na configuração de exibição feitas pelo usuário (por exemplo, tamanho da tela) definidas após a inicialização.
- As implementações de dispositivos DEVEM definir a densidade padrão da estrutura Android que é numericamente mais próxima da densidade física da tela, a menos que essa densidade lógica empurre o tamanho da tela relatado abaixo do mínimo suportado. Se a densidade da estrutura Android padrão que é numericamente mais próxima da densidade física resultar em um tamanho de tela menor que o menor tamanho de tela compatível suportado (largura de 320 dp), as implementações de dispositivos DEVEM relatar a próxima densidade de estrutura Android padrão mais baixa.
Iniciar novos requisitos
- DEVE definir a densidade padrão da estrutura Android que é numericamente mais próxima da densidade física da tela, ou um valor que seria mapeado para as mesmas medidas de campo de visão angular equivalentes de um dispositivo portátil.
Se as implementações de dispositivos fornecerem
apossibilidade de alterar o tamanho de exibição do dispositivo , elas :- [C-1-1]
O tamanho da tela NÃO DEVE ser dimensionado NÃODEVE dimensionar a exibição para mais de 1,5 vezesa densidade nativaDENSITY_DEVICE_STABLE
ou produzir uma dimensão de tela mínima efetiva menor que 320 dp (equivalente ao qualificador de recurso sw320dp), o que ocorrer primeiro. - [C-1-2]
O tamanho da exibição NÃO DEVE ser dimensionado NÃODEVE dimensionar a exibição para menos de 0,85 vezes adensidade nativaDENSITY_DEVICE_STABLE
.
- [C-0-1]
Ver revisão
Se as implementações de dispositivos incluírem suporte para Vulkan
1.0 ou superior, elas:[C-1-3] DEVE implementar totalmente as APIs
Vulkan 1.0Vulkan 1.1 para cadaVkPhysicalDevice
enumerado.[C-1-5] NÃO DEVE enumerar camadas fornecidas por bibliotecas fora do pacote do aplicativo ou fornecer outras maneiras de rastrear ou interceptar a API Vulkan, a menos que o aplicativo tenha o atributo
android:debuggable
definido comotrue
ou os metadadoscom.android.graphics.injectLayers.enable
definido comotrue
.
- DEVE suportar
VkPhysicalDeviceProtectedMemoryFeatures
eVK_EXT_global_priority
.
- [C-1-13] DEVE atender aos requisitos especificados pelo perfil Android Baseline 2021 .
[C-SR-5] São FORTEMENTE RECOMENDADOS para oferecer suporte
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
eVK_EXT_global_priority
.[C-SR-6] É FORTEMENTE RECOMENDADO usar
SkiaVk
com HWUI.
Se as implementações de dispositivos incluírem suporte para Vulkan 1.1 e declararem qualquer um dos sinalizadores de recurso Vulkan descritos aqui , elas:
- [C-SR-7] É FORTEMENTE RECOMENDADO disponibilizar a extensão
VK_KHR_external_fence_fd
para aplicativos de terceiros e permitir que o aplicativo exporte a carga útil do fence e importe a carga útil do fence dos descritores de arquivo POSIX conforme descrito aqui .
7.3.10. Sensores Biométricos :
Ver revisão
Se as implementações de dispositivos tiverem vários sensores biométricos, elas:
[C-7-1] OBRIGATÓRIO, quando uma biometria está bloqueada (ou seja, a biométrica é desativada até que o usuário desbloqueie com autenticação primária) ou bloqueio com limite de tempo (ou seja, a biometria é temporariamente desativada até que o usuário aguarde um intervalo de tempo) devido a muitas tentativas fracassadas, bloqueie também todos os outros dados biométricos de uma classe biométrica inferior. No caso de bloqueio com limite de tempo, o tempo de espera para verificação biométrica DEVE ser o tempo máximo de espera de todos os dados biométricos no bloqueio com limite de tempo.
[C-SR-12] São FORTEMENTE RECOMENDADOS quando uma biometria está bloqueada (ou seja, a biométrica é desativada até que o usuário desbloqueie com autenticação primária) ou bloqueio com limite de tempo (ou seja, a biométrica é temporariamente desativada até que o usuário aguarde um tempo intervalo) devido a muitas tentativas fracassadas, para também bloquear todos os outros dados biométricos da mesma classe biométrica. No caso de bloqueio com limite de tempo, o tempo de espera para verificação biométrica é FORTEMENTE RECOMENDADO para ser o tempo máximo de espera de todos os dados biométricos em bloqueio com limite de tempo.
[C-7-2] DEVE desafiar o usuário para a autenticação primária recomendada (por exemplo: PIN, padrão, senha) para redefinir o contador de bloqueio para uma biometria sendo bloqueada. A biometria de classe 3 PODE ser permitida para zerar o contador de bloqueio para uma biometria bloqueada da mesma classe ou de classe inferior. A biometria Classe 2 ou Classe 1 NÃO DEVE ser autorizada a concluir uma operação de redefinição de bloqueio para qualquer biometria.
Se as implementações de dispositivos desejarem tratar um sensor biométrico como Classe 1 (anteriormente Conveniência ), elas:
[C-1-12] DEVE ter uma taxa de aceitação de falsificação e impostor não superior a 40% por espécie de instrumento de ataque de apresentação (PAI) , conforme medido pelos protocolos de teste de biometria do Android .
[C-SR-13] É FORTEMENTE RECOMENDADO ter uma taxa de aceitação de falsificação e impostor não superior a 30% por espécie de instrumento de ataque de apresentação (PAI) , conforme medido pelos protocolos de teste de biometria do Android .
[C-SR-14] É FORTEMENTE RECOMENDADO 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 de dispositivos desejarem tratar um sensor biométrico como Classe 2 (anteriormente Fraco ), elas:
- [C-SR-15] É FORTEMENTE RECOMENDADO ter uma taxa de aceitação de falsificação e impostor não superior a 20% por espécie de instrumento de ataque de apresentação (PAI) , conforme medido pelos protocolos de teste de biometria do Android .
- [C-2-3] DEVE realizar a correspondência biométrica em um ambiente de execução isolado fora do espaço do usuário Android ou do kernel, como o Trusted Execution Environment (TEE),
ouem um chip com canal seguro para o ambiente de execução isolado ou em ambiente protegido Máquina Virtual que atende aos requisitos da 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 de um chip com um canal seguro para o ambiente de execução isolado, conforme documentado nas diretrizes de implementação no site do Android Open Source Project ou em uma máquina virtual protegida controlada por hipervisor que atenda aos requisitos da Seção 9.17 .
- [C-2-5] Para biometria baseada em câmera, enquanto a autenticação ou registro biométrico está acontecendo:
- DEVE operar a câmera em um modo que evite que os quadros da câmera sejam lidos ou alterados fora do ambiente de execução isolado ou de um chip com canal seguro para o ambiente de execução isolado ou de uma Máquina Virtual Protegida controlada por hipervisor que atenda aos requisitos da Seção 9.17 .
- Para soluções RGB de câmera única, os quadros da câmera PODEM ser legíveis fora do ambiente de execução isolado para suportar operações como visualização para registro, mas ainda assim NÃO DEVEM ser alteráveis.
- [C-2-7] NÃO DEVE permitir acesso não criptografado a dados biométricos identificáveis ou quaisquer dados derivados deles (como incorporações) ao Processador de Aplicativos fora do contexto do TEE ou da Máquina Virtual Protegida controlada pelo hipervisor que atenda aos requisitos da Seção 9.17 . A atualização de dispositivos lançados com Android versão 9 ou anterior não está isenta do C-2-7.
Se as implementações de dispositivos desejarem tratar um sensor biométrico como Classe 3 (anteriormente Strong ), elas:
- [C-SR-16] É FORTEMENTE RECOMENDADO ter uma taxa de aceitação de falsificação e impostor não superior a 7% por espécie de instrumento de ataque de apresentação (PAI) , conforme medido pelos protocolos de teste de biometria do Android .
7.3.13. IEEE 802.1.15.4 (UWB) :
Ver revisão
Se as implementações de dispositivos incluírem suporte para 802.1.15.4 e exporem a funcionalidade a um aplicativo de terceiros, elas:
- [C-1-2] DEVE relatar o sinalizador de recurso de hardware
android.hardware.uwb
. - [C-1-3] DEVE suportar todos os seguintes conjuntos de configurações (combinações pré-definidas de parâmetros FIRA UCI ) definidos na implementação do AOSP.
-
CONFIG_ID_1
: alcance unicastSTATIC STS DS-TWR
definido por FiRa, modo diferido, intervalo de alcance de 240 ms. -
CONFIG_ID_2
: alcance um para muitosSTATIC STS DS-TWR
definido por FiRa, modo diferido, intervalo de alcance de 200 ms. Caso de uso típico: o smartphone interage com muitos dispositivos inteligentes. -
CONFIG_ID_3
: O mesmo queCONFIG_ID_1
, exceto que os dados do ângulo de chegada (AoA) não são relatados. -
CONFIG_ID_4
: Igual aCONFIG_ID_1
, exceto que o modo de segurança P-STS está ativado. -
CONFIG_ID_5
: Igual aCONFIG_ID_2
, exceto que o modo de segurança P-STS está ativado. -
CONFIG_ID_6
: Igual aCONFIG_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 de controle individual P-STS está habilitado.
-
- [C-1-4] DEVE fornecer uma capacidade de usuário para permitir que o usuário alterne o estado ligado/desligado do rádio UWB.
- [C-1-5] DEVE impor que os aplicativos que usam rádio UWB tenham a permissão
UWB_RANGING
(no grupo de permissõesNEARBY_DEVICES
).
Passar 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 sinalizador de recurso de hardware
Ver revisão
“Telefonia”, conforme usado pelas APIs do Android, e este documento refere-se especificamente ao hardware relacionado à realização de chamadas de voz e ao envio de mensagens SMS ou ao estabelecimento de dados móveis por meio de uma rede móvel (por exemplo, GSM, CDMA, LTE, NR) GSM ou CDMA. Um dispositivo que suporte “Telefonia” pode optar por oferecer alguns ou todos os serviços de chamadas, mensagens e dados conforme adequado ao 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 do Android, consideradas independentes de qualquer conectividade de dados que possa ser implementada usando a mesma rede. Em outras palavras, a funcionalidade e APIs de “telefonia” do Android referem-se especificamente a chamadas de voz e SMS. Por exemplo, implementações de dispositivos que não podem fazer chamadas ou enviar/receber mensagens SMS não são consideradas dispositivos de telefonia, independentemente de usarem uma rede celular para conectividade de dados.Ver revisão
Se as implementações de dispositivos incluírem suporte para 802.11 e exporem a funcionalidade a um aplicativo de terceiros, elas:
- [C-1-4] DEVE suportar DNS multicast (mDNS) e NÃO DEVE filtrar pacotes mDNS (224.0.0.251 ou ff02::fb ) em qualquer momento da operação, inclusive quando a tela não estiver em estado ativo, a menos que seja descartada 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 Android Television, mesmo quando em estado de espera.
- [C-1-4] DEVE suportar DNS multicast (mDNS) e NÃO DEVE filtrar pacotes mDNS (224.0.0.251 ou ff02::fb ) em qualquer momento da operação, inclusive quando a tela não estiver em estado ativo, a menos que seja descartada 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.
Ver revisão
Se as implementações de dispositivos declararem FEATURE_BLUETOOTH_LE, elas:
- [C-SR-2] É FORTEMENTE RECOMENDADO medir e compensar o deslocamento de Rx para garantir que a mediana do BLE RSSI 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 de forma que sejam em 'planos paralelos' com telas voltadas na mesma direção. - [C-SR-3] São FORTEMENTE RECOMENDADOS para medir e compensar o deslocamento de Tx para garantir que a mediana do BLE RSSI seja -60dBm +/-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
, onde os dispositivos são orientados de modo que estejam em 'planos paralelos' com as telas voltadas na mesma direção.
- [C-10-3] DEVE medir e compensar o deslocamento Rx para garantir que a mediana do BLE RSSI seja -55dBm +/-10 dB a 1m de distância de um dispositivo de referência transmitindo em
ADVERTISE_TX_POWER_HIGH
. - [C-10-4] DEVE medir e compensar o deslocamento de Tx para garantir que o BLE RSSI mediano 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 de dispositivos oferecerem suporte ao Bluetooth versão 5.0, elas:
- [C-SR-4] É FORTEMENTE RECOMENDADO fornecer suporte para:
- LE 2M PHY
- LE Codec PHY
- Extensão de publicidade LE
- Publicidade periódica
- Pelo menos 10 conjuntos de anúncios
- Pelo menos 8 conexões simultâneas LE. Cada conexão pode estar em qualquer uma das funções de topologia de conexão.
- Privacidade da camada de link LE
- Um tamanho de "lista de resolução" de pelo menos 8 entradas
- [C-SR-2] É FORTEMENTE RECOMENDADO medir e compensar o deslocamento de Rx para garantir que a mediana do BLE RSSI seja -60dBm +/- 10 dB a 1 m de distância de um dispositivo de referência transmitindo em
Ver revisão
- [C-1-7] DEVE garantir que a mediana das medições de distância a 1m do dispositivo de referência esteja dentro de [0,75m, 1,25m], onde a distância real do solo é medida a partir da borda superior do DUT.
mantido virado para cima e inclinado 45 graus.
- [C-1-7] DEVE garantir que a mediana das medições de distância a 1m do dispositivo de referência esteja dentro de [0,75m, 1,25m], onde a distância real do solo é medida a partir da borda superior do DUT.
Ver revisão
Uma câmera traseira é uma câmera localizada na lateral do dispositivo oposta à tela; isto é, ele captura cenas do outro lado do dispositivo, como uma câmera tradicional.
Uma câmera traseira é uma câmera voltada para o mundo que captura cenas do outro lado do dispositivo, como uma câmera tradicional; em dispositivos portáteis, é uma câmera localizada na lateral do dispositivo oposta à tela.
Ver revisão
Uma câmera frontal é uma câmera localizada no mesmo lado do dispositivo que a tela; isto é, uma câmera normalmente usada para capturar imagens do usuário, como para videoconferência e aplicações semelhantes.
Uma câmera frontal é uma câmera voltada para o usuário normalmente usada para gerar imagens do usuário, como para videoconferência e aplicativos semelhantes; em dispositivos portáteis, é uma câmera localizada no mesmo lado do dispositivo que a tela.
Ver revisão
Uma câmera externa é uma câmera que pode ser fisicamente conectada ou desconectada da implementação do dispositivo a qualquer momento e pode estar voltada para qualquer direção; como câmeras USB.
7.5.4. Comportamento da API da câmera :
Ver revisão
As implementações de dispositivos 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
, só podem ser viáveis 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] deve atender a todos os requisitos descritos para implementações de dispositivos nas seções
"9.8.6 Captura de conteúdo""9.8.6 Dados do nível do SO e ambiental e 9.8.15 implementações de API em caixa de areia".
- [C-4-2] não deve ter a permissão Android.permission.internet. Isso é mais rigoroso do que o fortemente recomendado listado na Seção 9.8.6.
- [C-4-3] não deve vincular a outros aplicativos, exceto os seguintes aplicativos do sistema: Bluetooth, contatos, mídia, telefonia, sistema e componentes que fornecem APIs da Internet. Isso é mais rigoroso do que o fortemente recomendado listado na Seção 9.8.6.
Se as implementações do dispositivo incluirem um aplicativo padrão para apoiar o
VoiceInteractionService
, eles:- [C-5-1] não deve conceder
ACCESS_FINE_LOCATION
como padrão para esse aplicativo.
Veja revisão
Se as implementações do dispositivo criarem o perfil de usuário adicional discutido acima, elas:
- [C-4-5] deve distinguir visualmente os ícones de aplicativos de instância dupla quando os ícones são apresentados aos usuários.
- [C-4-6] deve fornecer um encordação do usuário para excluir dados inteiros do perfil de clone.
- [C-4-7] deve desinstalar todos os aplicativos de clone, excluir os diretórios de dados do aplicativo privado e seu conteúdo e excluir dados do perfil do clone, quando o usuário optar por excluir dados inteiros do perfil de clone.
- Deve solicitar ao usuário que exclua dados inteiros do perfil do clone quando o último aplicativo clone for excluído.
- [C-4-8] deve informar ao usuário que os dados do aplicativo serão excluídos quando o aplicativo clone não for desinstalado ou fornecer uma opção para os usuários para manter os dados do aplicativo quando o aplicativo não for inspirado no dispositivo.
- [C-4-9] deve excluir os diretórios de dados do aplicativo privado e seu conteúdo, quando o usuário escolhe excluir os dados durante a desinstalação.
[C-4-1] deve permitir que as intenções abaixo originadas no perfil adicional sejam tratadas por aplicações do usuário principal no dispositivo:
-
Intent.ACTION_VIEW
-
Intent.ACTION_SENDTO
-
Intent.ACTION_SEND
-
Intent.ACTION_EDIT
-
Intent.ACTION_INSERT
-
Intent.ACTION_INSERT_OR_EDIT
-
Intent.ACTION_SEND_MULTIPLE
-
Intent.ACTION_PICK
-
Intent.ACTION_GET_CONTENT
-
MediaStore.ACTION_IMAGE_CAPTURE
-
MediaStore.ACTION_VIDEO_CAPTURE
-
[C-4-2] deve herdar todas as restrições do usuário da política do dispositivo e restrições não usuários selecionadas (lista abaixo) aplicadas no usuário principal do dispositivo a esse perfil de usuário adicional.
[C-4-3] deve permitir apenas a escrita de contatos desse perfil adicional através dos seguintes intenções:
[C-4-4] não deve ter sincronização de contato em execução para aplicativos em execução neste perfil de usuário adicional.
- [C-4-14] deve ter permissão e gerenciamento de armazenamento separado para os aplicativos em execução neste perfil adicional
- [C-4-5] deve permitir apenas aplicativos no perfil adicional que possui uma atividade do lançador para acessar contatos que já são acessíveis ao perfil do usuário pai.
Veja revisão
Uma tecnologia de segurança de memória é uma tecnologia que atenua pelo menos as seguintes classes de bugs com uma probabilidade alta (> 90%) em aplicativos que usam o
android:memtagMode
Manifest Option:- Buffer de heap Overflow
- Use depois de grátis
- duplo livre
- Wild Free (livre de um ponteiro não-maloc)
Implementações de dispositivos:
- [C-SR-15] são fortemente recomendados para definir
ro.arm64.memtag.bootctl_supported
.
Se as implementações de dispositivos definirem a propriedade do sistema
ro.arm64.memtag.bootctl_supported
como true, eles:[C-3-1] deve permitir que a propriedade do sistema
arm64.memtag.bootctl
aceite uma lista separada por vírgula dos seguintes valores, com o efeito desejado aplicado na próxima reinicialização subsequente:-
memtag
: Uma tecnologia de segurança de memória, conforme definida acima, está ativada -
memtag-once
: Uma tecnologia de segurança de memória, conforme definida acima, é ativada transitoriamente e é automaticamente desativada, a próxima reinicialização -
memtag-off
: Uma tecnologia de segurança de memória, conforme definida acima, está desativada
-
[C-3-2] deve permitir que o usuário do shell defina
arm64.memtag.bootctl
.[C-3-3] deve permitir que qualquer processo leia
arm64.memtag.bootctl
.[C-3-4] deve definir
arm64.memtag.bootctl
para o estado solicitado atualmente na inicialização, ele também deve atualizar a propriedade, se a implementação do dispositivo permitir modificar o estado sem alterar a propriedade do sistema.[C-SR-16] são fortemente recomendados para mostrar uma configuração de desenvolvedor que define o MEMTAG-ONCE e reinicia o dispositivo. Com um carregador de inicialização compatível, o projeto de código aberto Android atende aos requisitos acima através do protocolo MTE BootLoader .
- [C-SR-17] são fortemente recomendados para mostrar uma configuração no menu Configurações de segurança que permite ao usuário ativar
memtag
.
Veja revisão
Implementações de dispositivos:
- [C-0-2] deve exibir um aviso de usuário e obter o consentimento explícito do usuário , permitindo qualquer informação confidencial exibida na tela do usuário a ser capturada,
que inclui exatamente a mesma mensagem que a AOSPsempre quecada vez que uma sessão para capturar o Agravura ou gravação de tela de telaéativadapor meio doMediaProjection.createVirtualDisplay()
,VirtualDeviceManager.createVirtualDisplay()
ou APIs proprietárias.Não deve fornecer aos usuários uma possibilidade de desativar a exibição futura do consentimento do usuário.
[C-SR-1] é fortemente recomendado para exibir um aviso de usuário que é exatamente a mesma mensagem implementada no AOSP, mas pode ser alterada desde que a mensagem alerifique claramente ao usuário de que qualquer informação confidencial na tela do usuário é capturada.
[C-0-4] não deve fornecer aos usuários uma possibilidade de desativar prompts futuros do consentimento do usuário para capturar a tela, a menos que a sessão seja iniciada por um aplicativo do sistema que o usuário tenha permitido
associate()
aoandroid.app.role.COMPANION_DEVICE_APP_STREAMING
ouandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING
Perfil do dispositivo.
- [C-0-2] deve exibir um aviso de usuário e obter o consentimento explícito do usuário , permitindo qualquer informação confidencial exibida na tela do usuário a ser capturada,
9.8.6. Dados do nível do SO e do ambiente : Esta seção foi renomeada desde a captura de conteúdo e a pesquisa de aplicativos até os dados do nível do SO e do ambiente .
Veja revisão
Android, por meio do sistema APIs
, suporta um mecanismo para implementações de dispositivos capturar as seguintesContentCaptureService
,AugmentedAutofillService
,AppSearchGlobalManager.query
, ou por outros meios proprietáriosinterações de dados do aplicativo entre os aplicativos e osdados sensíveis ao usuário:- Qualquer tela ou outros dados enviados através do
AugmentedAutofillService
para o sistema. - Qualquer tela ou outros dados acessíveis via API
Content Capture
. - Qualquer tela ou outros dados acessíveis via
FieldClassificationService
API - Quaisquer dados de aplicativos passados para o sistema através da
AppSearchManager
API e acessíveis viaAppSearchGlobalManager.query
.
- Quaisquer outros eventos que um aplicativo forneça ao sistema por meio da API
Content Capture
ou da APIAppSearchManager
A API Android e API proprietária e com capacidade igualmente capaz.
- Dados de áudio obtidos como resultado do uso
SpeechRecognizer#onDeviceSpeechRecognizer()
pela implementação do reconhecimento de fala. - Dados de áudio obtidos em segundo plano (continuamente) através
AudioRecord
,SoundTrigger
ou outras APIs de áudio, e não resultando em um indicador visível do usuário - Dados da câmera obtidos em plano de fundo (continuamente) através do cinegrafista ou de outras APIs da câmera, e não resultando em um indicador visível ao usuário
Se as implementações do dispositivo capturarem algum dos dados acima, eles:
[C-1-3] Deve enviar apenas todos esses dados
e o logOff do dispositivo usando um mecanismo de preservação de privacidade , exceto com consentimento explícito do usuário sempre que os dados são compartilhados . O mecanismo de preservação de privacidade é definido como “aqueles que permitem apenas análises agregados e impedem a correspondência de eventos registrados ou resultados derivados a usuários individuais”, para impedir que qualquer dados por usuário seja introspecável (por exemplo, implementado usando uma tecnologia de privacidade diferencial, comoRAPPOR
).[C-1-5] não deve compartilhar esses dados com outros componentes do sistema operacional que não seguem os requisitos descritos na seção atual (9.8.6
Captura de conteúdoDados no nível do SO e do ambiente ), exceto com consentimento explícito do usuário toda vez que for compartilhado. A menos que essa funcionalidade seja construída como uma API do Android SDK (AmbientContext
,HotwordDetectionService
).[C-1-6] Deve fornecer acessórios para o usuário para apagar esses dados que a implementação
ou os meios proprietários coletaContentCaptureService
sequando os dados forem armazenados de qualquer forma no dispositivo. Se o usuário optar por apagar os dados, remova todos os dados históricos coletados.
- [C-SR-3] são fortemente recomendados para serem implementados com a API Android SDK ou um repositório de código aberto de propriedade de OEM semelhante; e / ou ser realizado em uma implementação de caixa de areia (consulte 9.8.15 implementações de API em caixa de areia).
Android, através
SpeechRecognizer#onDeviceSpeechRecognizer()
fornece capacidade de executar o reconhecimento de fala no dispositivo, sem envolver a rede. Qualquer implementação do reconhecimento de discurso no dispositivo deve seguir as políticas descritas nesta seção.- Qualquer tela ou outros dados enviados através do
9.8.10. Relatório de bug de conectividade :
Veja revisão
Se as implementações do dispositivo declararem o sinalizador
android.hardware.telephony
, eles:- [C-1-4] Relatórios gerados usando
BUGREPORT_MODE_TELEPHONY
devem conter pelo menos as seguintes informações:-
SubscriptionManagerService
Dump
-
- [C-1-4] Relatórios gerados usando
9.8.14. Gerente de credenciais : removido
9.8.15. Implementações de API em sandbox : Nova seção
Veja revisão
O Android, através de um conjunto de APIs delegadas, fornece um mecanismo para processar dados seguros no nível do SO e ambiente. Esse processamento pode ser delegado a um APK pré -instalado com acesso privilegiado e recursos de comunicação reduzidos, conhecidos como implementação da API com caixa de areia.
Qualquer implementação da API em sandbox:
- [C-0-1] não deve solicitar a permissão da Internet.
- [C-0-2] deve acessar apenas a Internet por meio de APIs estruturadas apoiadas por implementações de código aberto disponíveis ao público usando mecanismos de preservação da privacidade ou indiretamente via Android SDK APIs. O mecanismo de preservação de privacidade é definido como "aqueles que permitem apenas análises agregados e impedem a correspondência de eventos registrados ou resultados derivados a usuários individuais", para impedir que qualquer dados por usuário seja introspecável (por exemplo, implementado usando uma tecnologia de privacidade diferencial, como Rappor ).
- [C-0-3] deve manter os serviços separados de outros componentes do sistema (por exemplo, não vinculando os IDs do processo de serviço ou compartilhamento), exceto pelo seguinte:
- Telefonia, contatos, interface do sistema e mídia
- [C-0-4] não deve permitir que os usuários substituam os serviços por um aplicativo ou serviço instalável pelo usuário
- [C-0-5] deve permitir apenas que os serviços pré-instalados capturem esses dados. A menos que a capacidade de substituição seja incorporada ao AOSP (por exemplo, para aplicativos de assistente digital).
- [C-0-6] não deve permitir que outros aplicativos além do mecanismo de serviços pré-instalados possam capturar esses dados. A menos que essa capacidade de captura seja implementada com uma API Android SDK.
- [C-0-7] deve fornecer acessibilidade ao usuário para desativar os serviços.
- [C-0-8] não deve omitir a oferta do usuário para gerenciar as permissões Android que são mantidas pelos Serviços e seguir o modelo de permissões do Android, conforme descrito na Seção 9.1. Permissão .
9.8.16. Dados de áudio e câmera contínuos : nova seção
Veja revisão
Além dos requisitos descritos em 9.8.2 gravação, 9.8.6 Dados do nível do SO e de ambientes e 9.8.15 implementações de API em caixa de areia, implementações que utilizam dados de áudio obtidos em plano de fundo (continuamente) através do AudiorCord, SoundTrigger ou outros APIs de áudio Ou dados da câmera obtidos em segundo plano (continuamente) através do cinegrafista ou de outras APIs da câmera:
- [C-0-1] deve aplicar um indicador correspondente (câmera e/ou microfone conforme a seção 9.8.2 gravação), a menos que:
- Esse acesso é realizado em uma implementação de caixa de areia (consulte a implementação da API 9.8.15 Sandboxed), através de um pacote que mantém uma ou mais das seguintes funções: Inteligência do Sistema da UI , Inteligência de Áudio Ambiente do Sistema , Inteligência de Áudio do Sistema , Inteligência de Notificação do Sistema , Inteligência de Texto do Sistema , ou inteligência visual do sistema .
- O acesso é realizado através de uma caixa de areia, implementado e aplicado por meio de mecanismos no AOSP (
HotwordDetectionService
,WearableSensingService
,VisualQueryDetector
). - O acesso de áudio é realizado para fins de assistência pelo aplicativo de assistente digital, fornecendo
SOURCE_HOTWORD
como fonte de áudio. - O acesso é realizado pelo sistema e implementado com código de código aberto.
- [C-SR-1] é fortemente recomendado para exigir o consentimento do usuário para todas as funcionalidades que utilizam esses dados e sejam desativados por padrão.
- [C-SR-2] Recomendado fortemente para aplicar o mesmo tratamento (ou seja, siga as restrições descritas na gravação 9.8.2, 9.8.6 Dados do nível do OS e ambiental, 9.8.15 implementações de API em caixa de areia e 9.8.16 Audio contínuo e Audio e Dados da câmera) aos dados da câmera provenientes de um dispositivo vestível remoto.
Se os dados da câmera forem fornecidos a partir de um dispositivo vestível remoto e acessados em uma forma não criptografada fora do sistema operacional Android, implementação da caixa de areia ou uma funcionalidade de caixa de areia construída pelo
WearableSensingManager
, eles: eles:- [C-1-1] deve indicar ao dispositivo vestível remoto para exibir um indicador adicional lá.
Se os dispositivos fornecerem capacidade de se envolver com um aplicativo de assistente digital sem a palavra -chave atribuída (lidando com consultas genéricas de usuário ou analisando a presença do usuário através da câmera):
- [C-2-1] deve garantir que essa implementação seja fornecida por um pacote que possui a função
android.app.role.ASSISTANT
. - [C-2-2] deve garantir que essa implementação utilize
HotwordDetectionService
e/ouVisualQueryDetectionService
Android APIs.
- [C-0-1] deve aplicar um indicador correspondente (câmera e/ou microfone conforme a seção 9.8.2 gravação), a menos que:
9.8.17. Telemetria : nova seção
Veja revisão
O Android armazena logs e logs de aplicativos usando APIs STATSLOG. Esses logs são gerenciados por meio de APIs do StatsManager, que podem ser usadas por aplicativos de sistema privilegiados.
O StatsManager também fornece uma maneira de coletar dados categorizados como privacidade sensível aos dispositivos com um mecanismo de preservação de privacidade. Em particular,
StatsManager::query
fornece a capacidade de consultar as categorias métricas restritas definidas no StatsLog .Qualquer consulta de implementação e coleta de métricas restritas do StatsManager:
- [C-0-1] deve ser o único aplicativo/implementação no dispositivo e segurar a permissão
READ_RESTRICTED_STATS
. - [C-0-2] deve enviar apenas dados de telemetria e o log do dispositivo usando um mecanismo de preservação de privacidade. O mecanismo de preservação de privacidade é definido como "aqueles que permitem apenas análises agregados e impedem a correspondência de eventos registrados ou resultados derivados a usuários individuais", para impedir que qualquer dados por usuário seja introspecável (por exemplo, implementado usando uma tecnologia de privacidade diferencial, como Rappor ).
- [C-0-3] não deve associar esses dados a qualquer identidade do usuário (como conta ) no dispositivo.
- [C-0-4] não deve compartilhar esses dados com outros componentes do SO que não seguem os requisitos descritos na seção atual (9.8.17 Telemetria de preservação da privacidade).
- [C-0-5] deve fornecer uma possibilidade de usuário para ativar/desativar a coleta, uso e compartilhamento de telemetria que preserva a privacidade.
- [C-0-6] Deve fornecer a disponibilidade do usuário para apagar esses dados que a implementação coleta se os dados forem armazenados de qualquer forma no dispositivo. Se o usuário optar por apagar os dados, remova todos os dados atualmente armazenados no dispositivo.
- [C-0-7] deve divulgar a implementação do protocolo de preservação de privacidade subjacente em um repositório de código aberto.
- [C-0-8] deve aplicar as políticas de saída de dados nesta seção para a coleta de dados de gate em categorias métricas restritas definidas no statsllog .
- [C-0-1] deve ser o único aplicativo/implementação no dispositivo e segurar a permissão
9.10. Integridade do dispositivo :
Veja revisão
Implementações de dispositivosSe as implementações do dispositivo tiverem a capacidade de verificar o conteúdo do arquivo por página, elas: elas :
[
C-0-3C-2-1 ] Suporta o conteúdo do arquivo criptograficamente verificandouma chave confiávelsem ler o arquivo inteiro.[
C-0-4C-2-2 ] Não deve permitir que as solicitações de leitura em um arquivo protegido sejam bem-sucedidas quando o conteúdo de leituranão verificar em uma chave confiávelnão é verificada por [C-2-1] acima .
- [C-2-4] deve retornar a soma de verificação do arquivo em O (1) para arquivos ativados.
Veja revisão
O sistema Android Keystore permite que os desenvolvedores de aplicativos armazenem chaves criptográficas em um contêiner e as usem em operações criptográficas através da API do chaveiro ou da API Keystore . Implementações de dispositivos:
- [C-0-3] deve limitar o número de tentativas de autenticação primária com falha.
- [C-SR-2] são fortemente recomendados para implementar um limite superior de 20 tentativas de autenticação primária com falha e, se os usuários consentirem e optarem pelo recurso, execute uma "redefinição de dados da fábrica" após exceder o limite das tentativas de autenticação primária com falha.
Se as implementações do dispositivo adicionar ou modificar os métodos de autenticação para desbloquear a tela de bloqueio se baseado em um segredo conhecido e usar um novo método de autenticação para ser tratado como uma maneira segura de bloquear a tela, então:
- [C-SR-3] Um pino é fortemente recomendado para ter pelo menos 6 dígitos, ou equivalentemente uma entropia de 20 bits.
- [C-2-1] Um alfinete de comprimento inferior a 6 dígitos não deve permitir entrada automática sem interação do usuário para evitar revelar o comprimento do pino.
9.11.1. Tela de bloqueio segura, autenticação e dispositivos virtuais :
Veja revisão
Implementações de dispositivos:
- [C-0-1] deve limitar o número de tentativas de autenticação primária com falha.
- [C-SR-5] são fortemente recomendados para implementar um limite superior de 20 tentativas de autenticação primária com falha e, se os usuários consentirem e optarem pelo recurso, execute uma "redefinição de dados da fábrica" após exceder o limite das tentativas de autenticação primária com falha.
Se as implementações do dispositivo definem um pino numérico como o método de autenticação primária recomendada, então:
- [C-SR-6] Um pino é fortemente recomendado para ter pelo menos 6 dígitos, ou equivalentemente uma entropia de 20 bits.
- [C-SR-7] Um alfinete de comprimento inferior a 6 dígitos é fortemente recomendado para não permitir entrada automática sem interação do usuário para evitar revelar o comprimento do pino.
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:[C-7-8] O usuário deve ser desafiado para um dos métodos de autenticação primária recomendada (por exemplo: pino, padrão, senha) pelo menos uma vez a cada 72 horas ou menos, a menos que a segurança do usuário (por exemplo, distração do driver) seja de preocupação.Se as implementações do dispositivo permitirem que os aplicativos criem displays virtuais secundários e suporte a eventos de entrada associados, como via VirtualDevicemanager e os monitores não estiverem marcados com virtual_display_flag_secure, eles:
[C-13-10] deve desativar a instalação de aplicativos iniciados a partir de dispositivos virtuais.9.17. Estrutura de virtualização do Android :
Veja revisão
Se o dispositivo implementar o suporte às APIs da estrutura de virtualização do Android (
android.system.virtualmachine.*
), O host Android:- [C-1-1] deve suportar todas as APIs definidas pelo pacote
android.system.virtualmachine
. - [C-1-2] não deve modificar o Android Selinux e o modelo de permissão para o gerenciamento de máquinas virtuais protegidas (PVM) .
- [C-1-3] não deve modificar, omitir ou substituir as regras nunca mais presentes no sistema/sepolicia fornecidas no projeto Android de código aberto a montante (AOSP) e a política deve compilar com todas as regras nunca mais presentes presentes.
- [C-1-4] deve permitir apenas que o código assinado da plataforma e os aplicativos privilegiados
não devem permitir que o código não confiável (por exemplo, aplicativos 3P)crie e execute um PVMde máquina virtual protegida. Nota: Isso pode mudar nos futuros lançamentos do Android.
- [C-1-5] não deve permitir um
Máquina virtual protegidaPVM para executar o código que não faz parte da imagem da fábrica ou de suas atualizações.Qualquer coisa que não seja coberta pelo Android Verificou Boot (por exemplo, arquivos baixados da Internet ou Sideloaded) não deve ser permissão para ser executado em uma máquina virtual protegida.
- [C-1-5] deve permitir apenas que um PVM não prejudicial execute o código da imagem da fábrica ou de suas atualizações de plataforma, que também incluem atualizações para aplicativos privilegiados.
Se o dispositivo implementar
suportaro suporte para as APIs da estrutura de virtualização do Android (android.system.virtualmachine.*
.- [C-2-1] deve ser capaz de executar todos os sistemas operacionais disponíveis no ápice da virtualização em um PVM
de máquina virtual protegida. - [C-2-2] não deve permitir que um PVM
de máquina virtual protegidaexecute um sistema operacional que não seja assinado pelo implementador do dispositivo ou pelo fornecedor do SO. - [C-2-3] não deve permitir que uma
máquina virtual protegidaPVM execute dados como código (por exemplo, Selinux Neverallow ExecMem).
- [C-2-4] não deve modificar, omitir ou substituir as regras nunca mais presentes no sistema/sepolicia/microdroid fornecido no projeto de código aberto Android a montante (AOSP).
- [C-2-5] deve implementar mecanismos de defesa de defesa de PVM da
Máquina Virtual protegida(por exemplo, Selinux para PVMs), mesmo para sistemas operacionais não-microdroides. - [C-2-6] deve garantir que o
firmwaredo PVM falhe se recusar a inicializar senão puder verificar as imagens iniciaisque a VM será executada não pode ser verificada. A verificação deve ser feita dentro da VM. - [C-2-7] deve garantir que o
firmwaredo PVM falhe se recusar a inicializar se a integridade da instância.Img estiver comprometida.
Se o dispositivo implementar o suporte às APIs da estrutura de virtualização do Android (
android.system.virtualmachine.*
), O hipervisor:- [C-3-1] deve garantir que as páginas de memória pertencentes a uma VM (PVM ou VM do host) sejam acessíveis apenas à própria máquina virtual ou ao hipervisor, não por outras máquinas virtuais-protegidas ou não protegidas.
Não deve permitir que nenhum PVM tenha acesso a uma página pertencente a outra entidade (ou seja, outro PVM ou hipervisor), a menos que seja explicitamente compartilhado pelo proprietário da página. Isso inclui a VM do host. Isso se aplica aos acessos de CPU e DMA. - [C-3-2] deve limpar uma página após ser usada por um PVM e antes de ser devolvido ao host (por exemplo, o PVM é destruído).
- [C-
3-3SR-1 ] é fortemente recomendado para garantirqueo firmware PVM seja carregado e executado antes de qualquer código em um PVM. - [C-3-4] deve garantir que cada VM deriva um segredo por VM que
{Cadeia de certificado de inicialização (BCC) e identificador de dispositivo composto (CDIS) fornecido a uma instância de PVMsó podem ser derivados por essa instância específica da VM e alterações após Redefinição de fábrica e OTA.
Se o dispositivo implementar o suporte às APIs da estrutura de virtualização do Android, em todas as áreas:
- [C-4-1] não deve fornecer funcionalidade a um PVM que permita ignorar o modelo de segurança do Android.
Se o dispositivo implementar o suporte às APIs da estrutura de virtualização do Android, então:
- [C-5-1] deve ser capaz de suportar compilação isolada , mas pode desativar o recurso de compilação isolada no envio do dispositivo
de uma atualização de tempo de execução do ART.
Se o dispositivo implementar o suporte às APIs da estrutura de virtualização do Android, para gerenciamento de chaves:
- [C-6-1] deve enraizar a cadeia de dados em um ponto que o usuário não pode modificar, mesmo em dispositivos desbloqueados. (Para garantir que não possa ser falsificado).
- [C- SR-2
6-2] é fortemente recomendado para usar dados como mecanismo de derivação secreta por VM.Deve fazer dados corretamente, ou seja, fornecer os valores corretos.
- [C-1-1] deve suportar todas as APIs definidas pelo pacote