Andróide 14
8 de abril de 2024
2. Tipos de dispositivos
Ver revisão
Iniciar novos requisitos
Se as implementações de dispositivos portáteis declararem
FEATURE_BLUETOOTH_LE, elas:- [ 7.4 .3/H-1-3] DEVE medir e compensar o deslocamento Rx para garantir que a mediana do BLE RSSI seja -50dBm +/- 15 dB a 1 m de distância de um dispositivo de referência transmitindo em
ADVERTISE_TX_POWER_HIGH. - [ 7.4 .3/H-1-4] DEVE medir e compensar o deslocamento de Tx para garantir que a mediana do BLE RSSI seja -50dBm +/- 15 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.
- [ 7.4 .3/H-1-3] DEVE medir e compensar o deslocamento Rx para garantir que a mediana do BLE RSSI seja -50dBm +/- 15 dB a 1 m de distância de um dispositivo de referência transmitindo em
Ver revisão
Se as implementações de dispositivos portáteis suportarem a API do sistema
HotwordDetectionServiceou outro mecanismo para detecção de hotword sem indicação de acesso ao microfone, elas:- [9.8/H-1-6] NÃO DEVE permitir que mais de 100 bytes de dados sejam transmitidos para fora do serviço de detecção de hotword em cada resultado de hotword bem-sucedido , exceto para dados de áudio transmitidos por HotwordAudioStream .
Ver revisão
Altere [9.8/H-1-13] para:
- [9.8/H-SR-3] É FORTEMENTE RECOMENDADO reiniciar o processo que hospeda o serviço de detecção de hotword pelo menos uma vez a cada hora ou a cada 30 eventos acionados por hardware, o que ocorrer primeiro.
Ver revisão
Requisitos removidos [9.8.2/H-4-3], [9.8.2/H-4-4], [9.8.2/H-5-3].
Ver revisão
Se as implementações de dispositivos portáteis retornarem
android.os.Build.VERSION_CODES.Uparaandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, então elas:- [ 7.5 /H-1-3] DEVE oferecer suporte à propriedade
android.info.supportedHardwareLevelcomoFULLou melhor para câmera primária traseira eLIMITEDou melhor para câmera primária frontal.
- [ 7.5 /H-1-3] DEVE oferecer suporte à propriedade
Ver revisão
Se as implementações de dispositivos de televisão não tiverem um monitor integrado, mas suportarem um monitor externo conectado via HDMI, elas:
- [ 5.8 /T-0-1] DEVE definir o modo de saída HDMI para a resolução mais alta para o formato de pixel escolhido que funcione com taxa de atualização de 50 Hz ou 60 Hz para o monitor externo, dependendo da taxa de atualização de vídeo para a região em que o dispositivo é vendido 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.
- [ 5.8 /T-0-1] DEVE definir o modo de saída HDMI para a resolução mais alta para o formato de pixel escolhido que funcione com taxa de atualização de 50 Hz ou 60 Hz para o monitor externo, dependendo da taxa de atualização de vídeo para a região em que o dispositivo é vendido DEVE
3. Programas
3.5.1. Restrição de aplicação :
Ver revisão
- Requisito removido [C-1-9]
5. Compatibilidade multimídia
Ver revisão
Se as implementações de dispositivos declararem suporte para o decodificador Dolby Vision por meio de
HDR_TYPE_DOLBY_VISION, elas:- [C-1-3] DEVE definir o ID da trilha das camadas base compatíveis com versões anteriores (se presentes) para ser o mesmo que o ID da trilha combinada da camada Dolby Vision.
7. Compatibilidade de Hardware
7.1.1.1. Tamanho e formato da tela :
Ver revisão
Se as implementações de dispositivos suportarem telas capazes de configuração de tamanho
UI_MODE_TYPE_NORMALe usarem telas físicas com 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:
- Quando
uma caixa de 15a 18 dp por1518 dp está ancorada em cada canto da exibição lógica, pelo menos um pixel de cada caixa fica visível na tela.
- Quando
- [C-1-1] DEVE garantir que pelo menos um dos seguintes requisitos seja atendido para cada exibição:
Ver revisão
Restabelecidos os seguintes requisitos:
Se as implementações de dispositivos declararem
FEATURE_BLUETOOTH_LE, elas:[C-SR-2] É FORTEMENTE RECOMENDADO medir e compensar o deslocamento 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.
Ver revisão
Requisitos [C-10-3] e [C-10-4] movidos para 2.2.1. Ferragens .
- [C-10-3] DEVE medir e compensar o deslocamento Rx para garantir que a mediana do BLE RSSI seja -55dBm +/-10 dB a 1 m 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.
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_CAMERApara 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_NUMBERno
Ver revisão
- [C-0-13] DEVE implementar o comando shell
dumpsys gpu --gpuworkpara 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_NORMALdisponibilizado 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_STABLEcomo 92% ou maior que a densidade física real do display correspondente.
Se as implementações de dispositivos portáteis declararem
android.hardware.audio.outputeandroid.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
ControlsProviderServiceeControle 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=truee o aplicativo declarar os metadadosMETA_DATA_PANEL_ACTIVITYna 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_CONTROLSao 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.isHeadlessSystemUserModecomotrue.
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,
ContentCaptureServiceou 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
ContentCaptureServiceou 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 paraContentCaptureServiceou 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_BITouAUDIO_FORMAT_PCM_FLOATpara 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
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALLcom 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_HdrEditingpara 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.supportedHardwareLevelcomo FULL ou melhor para ambas as câmeras primárias. - [ 7.5 /H-1-4] DEVE oferecer suporte
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIMEpara 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_RAWeandroid.graphics.ImageFormat.RAW_SENSORpara 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_STABILIZATIONpara câmera frontal primária e traseira primária. - [ 7.5 /H-1-13] DEVE suportar o recurso
LOGICAL_MULTI_CAMERApara 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_CASEpara 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.camera2API 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,ContentCaptureServiceou 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.uiccouandroid.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_maintenance1eVK_KHR_get_physical_device_properties2por 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_SALADeMONOCHROMATIC.
- [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
topActivityque 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_adminouandroid.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_CQe 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_MODEparaBITRATE_MODE_VBRpara 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_MODEcomoBITRATE_MODE_CBRpara 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.outputelas 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_getTimestamptem 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_getTimestampsão FORTEMENTE RECOMENDADAS para estarem dentro de 30 ms da latência de ida e volta medida paraAAUDIO_PERFORMANCE_MODE_NONEeAAUDIO_PERFORMANCE_MODE_LOW_LATENCYpara 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 normalizada para uma densidade detela de 160 DPI na telade 160. Para alguma densidade d e vários pixels p, o número de pixels independentes de densidade DP, é calculado como:pixels = dps * (densidade/160)dp = (160 / d) * p .
7.1.1.1. Tamanho e forma da tela :
Veja revisão
Se as implementações do dispositivo suportarem telas capazes da configuração de tamanho de
UI_MODE_TYPE_NORMALe incluirá exibição física (s)compatível com Androidcom cantos arredondados para renderizar essas telas , elas:- [C-1-1] deve garantir que pelo menos um dos seguintes requisitos seja atendido para cada uma dessas exibições :
- O raio dos cantos arredondados é menor ou igual a 38 dp.
Quando uma caixa de 15 dp por 15 DP está ancorada em cada canto da tela lógica, pelo menos um pixel de cada caixa é visível na tela.
Deve incluir a oferta do usuário para mudar para o modo de exibição com os cantos retangulares.
Inicie novos requisitos
Se as implementações do dispositivo forem capazes apenas da configuração do teclado
NO_KEYSe pretendem relatar suporte para a configuração do modoUI_MODE_TYPE_NORMALUI, eles:- [C-4-1] deve ter um tamanho de layout, excluindo quaisquer recortes de exibição, de pelo menos 596 dp x 384 dp ou mais.
Se as implementações do dispositivo incluirem um (s) exibição (s) compatível com Android, que é dobrável ou incluir uma dobradiça dobrável entre vários painéis de exibição e disponibilize esse (s) exibição (s) para renderizar aplicativos de terceiros, eles:
- [C-2-1] deve implementar a mais recente versão estável disponível da API de extensões ou a versão estável da API Sidecar a ser usada pela Biblioteca Jetpack do Window Manager .
Se as implementações do dispositivo incluirem um (s) exibição (s) compatível com o Android que é dobrável ou incluir uma dobradiça dobrável entre vários painéis de exibição e se a dobradiça ou dobra cruzar uma janela de aplicativo de tela cheia, eles: eles: eles: eles: eles: eles: eles: eles: eles: eles: eles: eles: eles: eles: eles: eles:
- [C-3-1] deve relatar a posição, os limites e o estado da dobradiça ou dobra através de extensões ou APIs de carros laterais ao aplicativo.
Se as implementações do dispositivo incluirem uma ou mais áreas de exibição compatíveis com Android que são dobráveis ou incluam uma dobradiça dobrável entre as áreas de painel de exibição múltipla compatível com Android e disponibilizam essas áreas de exibição para aplicações, elas: elas:
- [C-4-1] deve implementar a versão correta do nível da API de extensões do gerenciador de janelas, conforme descrito na próxima documentação.
7.1.1.2. Razão da tela : removido
Veja revisão
Implementações de dispositivos:
- [C-0-1]
Por padrão, as implementações do dispositivodevem relatarapenasuma das densidades da estrutura do Android listadas noDisplayMetricsatravés da APIDENSITY_DEVICE_STABLEe esse valor deve ser um valor estático para cada exibição físicanão deve mudar a nenhum momento; No entanto,no entanto, o dispositivo pode relatar umaDisplayMetrics.densityde densidade arbitráriadiferente.
- As implementações do dispositivo devem definir a densidade padrão do Android Framework que é numericamente mais próxima da densidade física da tela, a menos que essa densidade lógica aumente o tamanho da tela relatado abaixo do mínimo suportado. Se a densidade padrão da estrutura Android que estiver numericamente mais próxima da densidade física resultar em um tamanho de tela menor que o menor tamanho de tela compatível com suporte (largura de 320 dp), as implementações do dispositivo devem relatar a próxima densidade de estrutura Android mais baixa.
Inicie novos requisitos
- Deve definir a densidade padrão do Android Framework que está numericamente mais próxima da densidade física da tela, ou um valor que mapearia para as mesmas medições de campo de visão angular equivalente de um dispositivo portátil.
Se as implementações do dispositivo fornecer,
existeuma possibilidade de alterar o tamanho da exibição do dispositivo , elas :- [C-1-1]
O tamanho da tela não deve ser escalonado,não deve escalar a tela maior que 1,5 vezesDENSITY_DEVICE_STABLEdensidade nativaou produzir uma dimensão mínima eficaz da tela menor que 320dp (equivalente ao qualificador de recursos SW320DP), o que ocorrer primeiro. - [C-1-2]
O tamanho da exibição não deve ser escalonado,não deve escalar a tela menor que 0,85 vezes adensidade nativaDENSITY_DEVICE_STABLE.
- [C-0-1]
Veja revisão
Se as implementações do dispositivo incluirem suporte para Vulkan
1.0 ou superior, eles:[C-1-3] deve implementar completamente as APIs
Vulkan 1.0Vulkan 1.1 para cadaVkPhysicalDeviceenumerada.[C-1-5] não deve enumerar camadas fornecidas por bibliotecas fora do pacote de aplicativos ou fornecer outras maneiras de rastrear ou interceptar a API Vulkan, a menos que o aplicativo tenha o
android:debuggableconjunto comotrueou os metadadoscom.android.graphics.injectLayers.enableDefinir comotrue.
- Deve suportar
VkPhysicalDeviceProtectedMemoryFeatureseVK_EXT_global_priority.
- [C-1-13] deve atender aos requisitos especificados pelo perfil da linha de base Android 2021 .
[C-SR-5] são fortemente recomendados para suportar
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemoryeVK_EXT_global_priority.[C-SR-6] são fortemente recomendados para usar
SkiaVkcom HWUI.
Se as implementações do dispositivo incluirem suporte para o Vulkan 1.1 e declararem algum dos bandeiras de recursos vulkan descritos aqui , eles:
- [C-SR-7] são fortemente recomendados para disponibilizar a extensão
VK_KHR_external_fence_fdpara aplicativos de terceiros e permitir que o aplicativo exporte a carga útil da cerca e importe a carga útil de cerca dos descritores de arquivos POSIX, conforme descrito aqui .
7.3.10. Sensores biométricos :
Veja revisão
Se as implementações do dispositivo tiverem vários sensores biométricos, eles:
[C-7-1] Deve, quando um biométrico está em bloqueio (ou seja, o biométrico está desativado até que o usuário desbloqueie com autenticação primária) ou bloqueio de tempo (ou seja, o biométrico está temporariamente desativado até que o usuário aguarde um intervalo de tempo) Devido a muitas tentativas fracassadas, também bloqueia todas as outras biometria de uma classe biométrica mais baixa. No caso de bloqueio limitado, o tempo de retirada para a verificação biométrica deve ser o tempo máximo de retorno de toda a biometria no bloqueio limitado do tempo.
[C-SR-12] são fortemente recomendados, quando um biométrico está em bloqueio (ou seja, o biométrico é desativado até que o usuário desbloqueie com autenticação primária) ou bloqueio de tempo (ou seja, o biométrico está temporariamente desativado até que o usuário aguarde um tempo intervalo) devido a muitas tentativas fracassadas, de bloquear também todas as outras biometria da mesma classe biométrica. No caso de bloqueio de tempo, o tempo de retirada para a verificação biométrica é fortemente recomendado como o tempo máximo de retirada de toda a biometria no bloqueio limitado do tempo.
[C-7-2] deve desafiar o usuário pela autenticação primária recomendada (por exemplo: pino, padrão, senha) para redefinir o contador de bloqueio para que um biométrico esteja sendo bloqueado. A biometria da classe 3 pode poder redefinir o contador de bloqueio para um biométrico biométrico da mesma ou classe baixa. A biometria de classe 2 ou classe 1 não deve concluir uma operação de bloqueio de redefinição para qualquer biometria.
Se as implementações do dispositivo desejarem tratar um sensor biométrico como classe 1 (anteriormente conveniente ), eles:
[C-1-12] deve ter uma taxa de aceitação de paródia e impostor, não superior a 40% por apresentação, espécies (PAI) , conforme medido pelos protocolos de teste de biometria do Android .
[C-SR-13] são fortemente recomendados para ter uma taxa de aceitação de paródia e impostor não superior a 30% por instrumento de ataque de apresentação (PAI) , conforme medido pelos protocolos de teste de biometria Android .
[C-SR-14] são fortemente recomendados para divulgar a classe biométrica do sensor biométrico e os riscos correspondentes de habilitá-lo.
[C-SR-17] são fortemente recomendados para implementar as novas interfaces AIDL (como
IFace.aidleIFingerprint.aidl).
Se as implementações do dispositivo desejarem tratar um sensor biométrico como classe 2 (anteriormente fraco ), eles:
- [C-SR-15] são fortemente recomendados para ter uma taxa de aceitação de paródia e impostor não superior a 20% por instrumento de ataque de apresentação (PAI) , conforme medido pelos protocolos de teste de biometria Android .
- [C-2-3] deve executar a correspondência biométrica em um ambiente de execução isolado fora do espaço do usuário ou do kernel do Android, como o ambiente de execução confiável (TEE)
ouem um chip com um canal seguro para o ambiente de execução isolado ou em protegido Máquina virtual que atende aos requisitos na Seção 9.17 . - [C-2-4] deve ter todos os dados identificáveis criptografados e autenticados criptograficamente, de modo que não possam ser adquiridos, lidos ou alterados fora do ambiente de execução isolado ou um chip com um canal seguro para o ambiente de execução isolado, conforme documentado nas diretrizes de implementação No site do projeto de código aberto Android ou em uma máquina virtual protegida controlada pelo hipervisor que atenda aos requisitos na Seção 9.17 .
- [C-2-5] para biometria baseada em câmera, enquanto a autenticação ou inscrição baseada em biométricas está acontecendo:
- Deve operar a câmera em um modo que impede que os quadros da câmera sejam lidos ou alterados fora do ambiente isolado de execução ou um chip com um canal seguro para o ambiente de execução isolado ou uma máquina virtual protegida controlada pelo hipervisor que atenda aos requisitos na Seção 9.17 .
- Para soluções de câmera única RGB, os quadros da câmera podem ser legíveis fora do ambiente de execução isolado para apoiar operações como a visualização para a inscrição, mas ainda não deve ser alterável.
- [C-2-7] não deve permitir o acesso não criptografado a dados biométricos identificáveis ou a quaisquer dados derivados dele (como incorporação) ao processador de aplicativos fora do contexto da TEE ou da máquina virtual protegida controlada pelo hipervisor que atende aos requisitos na seção 9.17 . Os dispositivos de atualização lançados na versão 9 do Android ou anterior não estão isentos do C-2-7.
Se as implementações do dispositivo desejarem tratar um sensor biométrico como classe 3 (anteriormente forte ), eles:
- [C-SR-16] são fortemente recomendados para ter uma taxa de aceitação de paródia e impostor não superior a 7% por instrumento de ataque de apresentação (PAI) , conforme medido pelos protocolos de teste de biometria Android .
7.3.13. IEEE 802.1.15.4 (UWB) :
Veja revisão
Se as implementações do dispositivo incluirem suporte para 802.1.15.4 e expor a funcionalidade a um aplicativo de terceiros, eles:
- [C-1-2] deve relatar o recurso de hardware sinalizador
android.hardware.uwb. - [C-1-3] deve suportar todos os seguintes conjuntos de configurações (combinações predefinidas dos parâmetros FIRA UCI ) definidos na implementação do AOSP.
-
CONFIG_ID_1: unicast estático definido porSTATIC STS DS-TWR, modo diferido, intervalo de variação 240 ms. -
CONFIG_ID_2: FIRA definido por um para muitosSTATIC STS DS-TWR, Modo adiado, intervalo de variação de 200 ms. Caso de uso típico: o smartphone interage com muitos dispositivos inteligentes. -
CONFIG_ID_3: o mesmo que os dadosCONFIG_ID_1, exceto o ângulo de chegada (AOA), não são relatados. -
CONFIG_ID_4: o mesmo queCONFIG_ID_1, exceto que o modo de segurança P-STS está ativado. -
CONFIG_ID_5: o mesmo queCONFIG_ID_2, exceto que o modo de segurança P-STS está ativado. -
CONFIG_ID_6: o mesmo queCONFIG_ID_3, exceto que o modo de segurança P-STS está ativado. -
CONFIG_ID_7: o mesmo queCONFIG_ID_2, exceto que o modo de chave controlista individual P-STS está ativado.
-
- [C-1-4] deve fornecer uma possibilidade de um usuário para permitir que o usuário atenda o estado de rádio UWB ON/OFF.
- [C-1-5] deve aplicar que os aplicativos usando o Rádio UWB mantenham a permissão
UWB_RANGING(no grupo de permissãoNEARBY_DEVICES).
A aprovação nos testes relevantes de conformidade e certificação definidos por organizações padrão, incluindo FIRA , CCC e CSA, ajuda a garantir que o 802.1.15.4 funcione corretamente.
- [C-1-2] deve relatar o recurso de hardware sinalizador
Veja revisão
“Telefonia”, conforme usado pelas APIs do Android e este documento se refere especificamente a hardware relacionado à colocação de chamadas de voz e envio de mensagens SMS ou estabelecendo dados móveis por meio de uma rede móvel (por exemplo, GSM, CDMA, LTE, NR) GSM ou CDMA. Um dispositivo que suporta "telefonia" pode optar por oferecer algumas ou todas as chamadas, mensagens e serviços de dados, como se encaixa no produto.
através de uma rede GSM ou CDMA. Embora essas chamadas de voz possam ou não ser comutadas por pacotes, elas são para fins de Android considerados independentes de qualquer conectividade de dados que possam ser implementados usando a mesma rede. Em outras palavras, a funcionalidade de “telefonia” do Android e as APIs se refere especificamente a chamadas de voz e SMS. Por exemplo, as implementações do dispositivo que não podem fazer chamadas ou enviar/receber mensagens SMS não são consideradas um dispositivo de telefonia, independentemente de usarem uma rede celular para conectividade de dados.Veja revisão
Se as implementações do dispositivo incluirem suporte para 802.11 e expor a funcionalidade a um aplicativo de terceiros, eles:
- [C-1-4] deve suportar DNs multicast (MDNs) e não devem filtrar pacotes MDNS (224.0.0.251 ou FF02 :: FB ) em qualquer momento de operação, inclusive quando a tela não estiver em um estado ativo, a menos que cair ou A filtragem desses pacotes é necessária para permanecer dentro das faixas de consumo de energia exigidas pelos requisitos regulatórios aplicáveis ao mercado -alvo.
Para implementações de dispositivos de televisão Android, mesmo quando em estados de energia em espera.
- [C-1-4] deve suportar DNs multicast (MDNs) e não devem filtrar pacotes MDNS (224.0.0.251 ou FF02 :: FB ) em qualquer momento de operação, inclusive quando a tela não estiver em um estado ativo, a menos que cair ou A filtragem desses pacotes é necessária para permanecer dentro das faixas de consumo de energia exigidas pelos requisitos regulatórios aplicáveis ao mercado -alvo.
Veja revisão
Se as implementações do dispositivo declararem festere_bluetooth_le, elas:
- [C-SR-2] são fortemente recomendados para medir e compensar o deslocamento RX para garantir que o RSSI mediano seja -60dbm +/- 10 dB a 1 m de distância de um dispositivo de referência transmitindo em
ADVERTISE_TX_POWER_HIGH, onde os dispositivos são orientados para que sejam Em 'Planos Parallel', com telas voltadas para a mesma direção. - [C-SR-3] são fortemente recomendados para medir e compensar o deslocamento do TX para garantir que o RSSI mediano seja de -60dbm +/- 10 dB quando a digitalização de um dispositivo de referência posicionado a 1 m de distância e transmitindo em
ADVERTISE_TX_POWER_HIGH, onde os dispositivos são orientados de modo que eles estejam em 'aviões paralelos' com telas voltadas para a mesma direção.
- [C-10-3] deve medir e compensar o deslocamento RX para garantir que o RSSI mediano de BLE seja -55dbm +/- 10 dB a 1 m de distância de um dispositivo de referência que transmite em
ADVERTISE_TX_POWER_HIGH. - [C-10-4] deve medir e compensar o deslocamento do TX para garantir que o RSSI mediano de BLE seja -55dbm +/- 10 dB ao digitalizar a partir de um dispositivo de referência posicionado a 1 m de distância e transmitindo em
ADVERTISE_TX_POWER_HIGH.
Se as implementações do dispositivo suportarem a versão 5.0 do Bluetooth, elas: elas:
- [C-SR-4] são fortemente recomendados para fornecer suporte para:
- Le 2M Phy
- Le codec phy
- Extensão de publicidade
- Publicidade periódica
- Pelo menos 10 conjuntos de anúncios
- Pelo menos 8 conexões simultâneas. Cada conexão pode estar em ambos os papéis de topologia de conexão.
- Privacidade da camada de link
- Um tamanho de "lista de resolução" de pelo menos 8 entradas
- [C-SR-2] são fortemente recomendados para medir e compensar o deslocamento RX para garantir que o RSSI mediano seja -60dbm +/- 10 dB a 1 m de distância de um dispositivo de referência transmitindo em
Veja revisão
- [C-1-7] deve garantir que a mediana das medições de distância a 1 m do dispositivo de referência esteja dentro de [0,75m, 1,25m], onde a distância da verdade do solo é medida a partir da borda superior do DUT.
Segurou a face para cima e inclinou 45 graus.
- [C-1-7] deve garantir que a mediana das medições de distância a 1 m do dispositivo de referência esteja dentro de [0,75m, 1,25m], onde a distância da verdade do solo é medida a partir da borda superior do DUT.
7.5.1. Câmera voltada para trás :
Veja revisão
Uma câmera traseira é uma câmera localizada na lateral do dispositivo em frente à tela; Ou seja, imagens de cenas do outro lado do dispositivo, como uma câmera tradicional.
Uma câmera voltada para trás é uma câmera voltada para o mundo que imagens de cenas no lado oposto do dispositivo, como uma câmera tradicional; Em dispositivos portáteis, essa é uma câmera localizada na lateral do dispositivo em frente à tela.
Veja revisão
Uma câmera frontal é uma câmera localizada no mesmo lado do dispositivo que a tela; Ou seja, uma câmera normalmente usada para imaginar o usuário, como para videoconferência e aplicativos semelhantes.
Uma câmera frontal é uma câmera voltada para o usuário que normalmente é usada para imaginar o usuário, como para videoconferência e aplicativos semelhantes; Em dispositivos portáteis, essa é uma câmera localizada no mesmo lado do dispositivo que a tela.
Veja revisão
Uma câmera externa é uma câmera que pode ser fisicamente anexada ou destacada da implementação do dispositivo a qualquer momento e pode enfrentar qualquer direção; como câmeras USB.
7.5.4. Comportamento da API da câmera :
Veja revisão
As implementações do dispositivo devem implementar os seguintes comportamentos para as APIs relacionadas à câmera, para todas as câmeras disponíveis. Implementações de dispositivos:
- [C-SR-1] Para dispositivos com várias câmeras RGB nas proximidades e voltados para a mesma direção, é fortemente recomendável suportar um dispositivo de câmera lógica que lista a capacidade
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, consistindo em todas as câmeras RGB FACANTES como sub-dispositivos físicos.
- [C-SR-1] Para dispositivos com várias câmeras RGB nas proximidades e voltados para a mesma direção, é fortemente recomendável suportar um dispositivo de câmera lógica que lista a capacidade
Veja revisão
Os dispositivos que atendem a todos os critérios a seguir estão isentos do requisito acima:
- As implementações de dispositivos que não são capazes de serem giradas pelo usuário, como dispositivos automotivos.
Veja revisão
Os dispositivos destinados a serem usados ou usados podem incluir um atuador háptico de uso geral, disponível para aplicações para fins, incluindo a atenção através de toques, alarmes, notificações e feedback geral do toque.
Se as implementações de dispositivos não incluirem um atuador háptico de propósito geral, eles:
- [7.10/c] devem retornar false para
Vibrator.hasVibrator().
Se as implementações do dispositivo incluirem pelo menos um desses atuadores híticos de uso geral, eles:
- [C-1-1] deve retornar true para
Vibrator.hasVibrator(). - Não deve usar um atuador héptico excêntrico de massa rotativa (ERM) (vibrador).
- SHOULD implement all public constants for clear haptics in
android.view.HapticFeedbackConstantsnamely (CLOCK_TICK,CONTEXT_CLICK,KEYBOARD_PRESS,KEYBOARD_RELEASE,KEYBOARD_TAP,LONG_PRESS,TEXT_HANDLE_MOVE,VIRTUAL_KEY,VIRTUAL_KEY_RELEASE,CONFIRM,REJECT,GESTURE_STARTandGESTURE_END). - Deve implementar todas as constantes públicas para haptics claros em
android.os.VibrationEffectnomeadamente (EFFECT_TICK,EFFECT_CLICK,EFFECT_HEAVY_CLICKeEFFECT_DOUBLE_CLICK) e todas as possíveis públicas viáveis_PRIMITIVE_*constantes para ricos em haptics inandroid.os.VibrationEffect.Composition(CLICK,TICK,LOW_TICKin Android.QUICK_FALL,QUICK_RISE,SLOW_RISE,SPIN,THUD). Algumas dessas primitivas, comoLOW_TICKeSPINpodem ser viáveis apenas se o vibrador puder suportar frequências relativamente baixas. - Deve seguir as orientações para mapear constantes públicas em
android.view.HapticFeedbackConstantspara 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_LOCATIONcomo 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:memtagModeManifest Option:- Buffer de heap Overflow
- Use depois de grátis
- duplo grátis
- 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_supportedcomo true, eles:[C-3-1] deve permitir que a propriedade do sistema
arm64.memtag.bootctlaceite 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.bootctlpara 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 oA gravura 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_STREAMINGouandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMINGPerfil 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
ContentCaptureService,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
AugmentedAutofillServicepara o sistema. - Qualquer tela ou outros dados acessíveis via API
Content Capture. - Qualquer tela ou outros dados acessíveis via
FieldClassificationServiceAPI - Quaisquer dados de aplicativos passados para o sistema através da
AppSearchManagerAPI e acessíveis viaAppSearchGlobalManager.query.
- Quaisquer outros eventos que um aplicativo forneça ao sistema por meio da API
Content Captureou da APIAppSearchManagerA API Android e API proprietária e com capacidade igualmente capaz.
- Dados de áudio obtidos como resultado do uso do
SpeechRecognizer#onDeviceSpeechRecognizer()pela implementação do reconhecimento de fala. - Dados de áudio obtidos em segundo plano (continuamente) através
AudioRecord,SoundTriggerou 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 do
ContentCaptureServicesequando 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_TELEPHONYdevem conter pelo menos as seguintes informações:-
SubscriptionManagerServiceDump
-
- [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_HOTWORDcomo fonte de áudio. - The access is performed by the system and implemented with open-source code.
- [C-SR-1] Is STRONGLY RECOMMENDED to require user consent for every functionality utilizing such data, and be disabled by default.
- [C-SR-2] STRONGLY RECOMMENDED to apply the same treatment (ie follow the restrictions outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, 9.8.15 Sandboxed API implementations, and 9.8.16 Continuous Audio and Camera data) to Camera data coming from a remote wearable device.
If the Camera data is supplied from a remote wearable device and accessed in an unencrypted form outside Android OS, sandboxed implementation or a sandboxed functionality built by
WearableSensingManager, then they:- [C-1-1] MUST indicate to the remote wearable device to display an additional indicator there.
If devices provide capability to engage with a Digital Assistant Application without the assigned keyword (either handling generic user queries, or analyzing user presence through camera):
- [C-2-1] MUST ensure such implementation is provided by a package holding the
android.app.role.ASSISTANTrole. - [C-2-2] MUST ensure such implementation utilizes
HotwordDetectionServiceand/orVisualQueryDetectionServiceAndroid 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. Telemetry : New section
See revision
Android stores system and app logs using StatsLog APIs. These logs are managed via StatsManager APIs which can be used by privileged system applications.
StatsManager also provides a way to collect data categorized as privacy sensitive from devices with a privacy preserving mechanism. In particular,
StatsManager::queryAPI provides the ability to query restricted metric categories defined in StatsLog .Any implementation querying and collecting restricted metrics from StatsManager:
- [C-0-1] MUST be the sole application/implementation on the device and hold the
READ_RESTRICTED_STATSpermission. - [C-0-2] MUST only send telemetry data and the log of the device using a privacy-preserving mechanism. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST NOT associate such data with any user identity (such as Account ) on the device.
- [C-0-4] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.17 Privacy-preserving Telemetry).
- [C-0-5] MUST provide a user affordance to enable/disable privacy-preserving telemetry collection, use, and sharing.
- [C-0-6] MUST provide user affordance to erase such data that the implementation collects if the data is stored in any form on the device. If the user chose to erase the data, MUST remove all data currently stored on the device.
- [C-0-7] MUST disclose underlying privacy-preserving protocol implementation in an open source repository.
- [C-0-8 ]MUST enforce data egress policies in this section to gate collection of data in restricted metric categories defined in StatsLog .
- [C-0-1] MUST be the sole application/implementation on the device and hold the
See revision
Device implementationsIf device implementations have the ability to verify file content on the per-page basis, then they :
[
C-0-3C-2-1 ] support cryptographically verifying file contentagainst a trusted keywithout reading the whole file.[
C-0-4C-2-2 ] MUST NOT allow the read requests on a protected file to succeed when the read contentdo not verify against a trusted keyis not verified per [C-2-1] above .
- [C-2-4] MUST return file checksum in O(1) for enabled files.
See revision
The Android Keystore System allows app developers to store cryptographic keys in a container and use them in cryptographic operations through the KeyChain API or the Keystore API . Implementações de dispositivos:
- [C-0-3] MUST limit the number of failed primary authentication attempts.
- [C-SR-2] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations add or modify the authentication methods to unlock the lock screen if based on a known secret and use a new authentication method to be treated as a secure way to lock the screen, then:
- [C-SR-3] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-2-1] A PIN of a length less than 6 digits MUST NOT allow automatic entry without user interaction to avoid revealing the PIN length.
9.11.1. Secure Lock Screen, Authentication and Virtual Devices :
See revision
Implementações de dispositivos:
- [C-0-1] MUST limit the number of failed primary authentication attempts.
- [C-SR-5] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations set a numerical PIN as the recommended primary authentication method, then:
- [C-SR-6] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-SR-7] A PIN of a length less than 6 digits is STRONGLY RECOMMENDED NOT to allow automatic entry without user interaction to avoid revealing the PIN length.
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] The user MUST be challenged for one of the recommended primary authentication (eg: PIN, pattern, password) methods at least once every 72 hours or less unless the safety of the user (eg driver distraction) is of preocupação.If device implementations allow applications to create secondary virtual displays and support associated input events such as via VirtualDeviceManager and the displays are not marked with VIRTUAL_DISPLAY_FLAG_SECURE, they:
[C-13-10] MUST disable installation of apps initiated from virtual devices.9.17. Android Virtualization Framework :
See revision
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*), the Android host:- [C-1-1] MUST support all the APIs defined by the
android.system.virtualmachinepackage. - [C-1-2] MUST NOT modify the Android SELinux and permission model for the management of Protected Virtual Machines (pVM) .
- [C-1-3] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow rules present.
- [C-1-4] MUST only allow platform signed code & privileged apps
MUST NOT allow untrusted code (eg 3p apps)to create and run aProtected Virtual MachinepVM . Note: This might change in future Android releases.
- [C-1-5] MUST NOT allow a
Protected Virtual MachinepVM to execute code that is not part of the factory image or their updates.Anything that is not covered by Android Verified Boot (eg files downloaded from the Internet or sideloaded) MUST NOT be allowed to be run in a Protected Virtual Machine.
- [C-1-5] MUST only allow a non-debuggable pVM to execute code from the factory image or their platform updates which also includes any updates to privileged apps.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*), then anyProtected Virtual MachinepVM instance:- [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a
Protected Virtual MachinepVM . - [C-2-2] MUST NOT allow a
Protected Virtual MachinepVM to run an operating system that is not signed by the device implementor or OS vendor. - [C-2-3] MUST NOT allow a
Protected Virtual MachinepVM to execute data as code (eg SELinux neverallow execmem).
- [C-2-4] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy/microdroid provided in the upstream Android Open Source Project (AOSP).
- [C-2-5] MUST implement
Protected Virtual MachinepVM defense-in-depth mechanisms (eg SELinux for pVMs) even for non-Microdroid operating systems. - [C-2-6] MUST ensure that the pVM fails
firmware refusesto boot ifit cannot verify the initialimages that the VM will run cannot be verified. The verification MUST be done inside the VM. - [C-2-7] MUST ensure that the pVM fails
firmware refusesto boot if the integrity of the instance.img is compromised.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*), then the hypervisor:- [C-3-1] MUST ensure that memory pages exclusively owned by a VM (either pVM or host VM) are accessible only to the virtual machine itself or the hypervisor, not by other virtual machines - either protected or non-protected.
MUST NOT allow any pVM to have access to a page belonging to another entity (ie other pVM or hypervisor), unless explicitly shared by the page owner. This includes the host VM. This applies to both CPU and DMA accesses. - [C-3-2] MUST wipe a page after it is used by a pVM and before it is returned to the host (eg the pVM is destroyed).
- [C-
3-3SR-1 ] Is STRONGLY RECOMMENDED to ensureMUST ensurethat that the pVM firmware is loaded and executed prior to any code in a pVM. - [C-3-4] MUST ensure that each VM derives a per-VM secret which
{Boot Certificate Chain (BCC) and Compound Device Identifier (CDIs) provided to a pVM instancecan only be derived by that particular VM instance and changes upon factory reset and OTA.
If the device implements support for the Android Virtualization Framework APIs, then across all areas:
- [C-4-1] MUST NOT provide functionality to a pVM that allows bypassing the Android Security Model.
If the device implements support for the Android Virtualization Framework APIs, then:
- [C-5-1] MUST be capable to support Isolated Compilation but may disable Isolated Compilation feature on the device shipment
of an ART runtime update.
If the device implements support for the Android Virtualization Framework APIs, then for Key Management:
- [C-6-1] MUST root DICE chain at a point that the user cannot modify, even on unlocked devices. (To ensure it cannot be spoofed).
- [C- SR-2
6-2] Is STRONGLY RECOMMENDED to use DICE as the per-VM secret derivation mechanism.MUST do DICE properly ie provide the correct values.
- [C-1-1] MUST support all the APIs defined by the