Android 14
26 de junho de 2024
2. tipos de dispositivos
-
Ver revisão
- [7.6.1/H-1-1] PRECISA oferecer suporte a apenas uma ABI (somente 64 bits ou 32 bits).
Ver revisão
Iniciar novos requisitos
Se as implementações de dispositivos portáteis tiverem suporte ao Vulkan, elas:
- [7.1.4.2/H-1-1] PRECISA atender aos requisitos especificados pelo perfil de referência do Android 2021.
-
Ver revisão
Iniciar novos requisitos
Se as implementações de dispositivos Watch incluírem suporte ao Vulkan, elas vão:
- [7.1.4.2/W-1-1] PRECISA atender aos requisitos especificados pelo perfil de referência do Android 2021.
-
Ver revisão
Iniciar novos requisitos
Se as implementações de dispositivos automotivos incluírem suporte ao Vulkan, elas:
- [7.1.4.2/A-1-1] PRECISA atender aos requisitos especificados pelo perfil de referência do Android 2021.
3. software
-
Para o parâmetro ODM_SKU:
Ver revisão
O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular
^([0-9A-Za-z.,_-]+)$
.
5. Compatibilidade multimídia
5.1.3. Detalhes dos codecs de áudio:
Detalhes adicionados para o formato/codec Vorbis:
Ver revisão
Decodificação: suporte a conteúdo mono, estéreo, 5.0 e 5.1 com taxas de amostragem de 8.000, 12.000, 16.000, 24.000 e 48.000 Hz.
Codificação: suporte a conteúdo mono e estéreo com taxas de amostragem de 8.000, 12.000, 0.000, 0.000, 8.000 e 8.000
7. Compatibilidade de hardware
-
Ver revisão
- [C-1-13] PRECISA atender aos requisitos especificados pelo perfil de referência do Android 2021.
-
Remoção de:
Ver revisão
- NÃO DEVE implementar o áudio AOAv2 documentado na documentação do Android Open Accessory Protocol 2.0. O áudio AOAv2 foi descontinuado no Android 8.0 (nível 26 da API).
9. Compatibilidade do modelo de segurança
-
[C-SR-1] foi renumerado para [C-SR-7] para remover o conteúdo duplicado e [C-SR-8] foi removido:
Ver revisão
[C-SR-1] FORTEMENTE RECOMENDADO para manter os dados do kernel que são gravados somente durante a inicialização marcados como somente leitura após a inicialização (por exemplo,
__ro_after_init
).[C-SR-2] São RECOMENDADOS ALTAMENTE para randomizar o layout do código e da memória do kernel e evitar exposições que possam comprometer a aleatoriedade (por exemplo,
CONFIG_RANDOMIZE_BASE
com entropia do carregador de inicialização usando/chosen/kaslr-seed Device Tree node
ouEFI_RNG_PROTOCOL
).[C-SR-3] É FORTEMENTE RECOMENDADO para ativar a integridade do fluxo de controle (CFI) no kernel para fornecer mais proteção contra ataques de reutilização de código (por exemplo,
CONFIG_CFI_CLANG
eCONFIG_SHADOW_CALL_STACK
).[C-SR-4] É RECOMENDADO que não desative a integridade do fluxo de controle (CFI), a pilha de chamada de sombra (SCS) ou a limpeza de estouro de números inteiros (IntSan) em componentes em que ela está ativada.
[C-SR-5] É RECOMENDADO que você ative CFI, SCS e IntSan para qualquer outro componente de espaço do usuário sensível à segurança, conforme explicado em CFI e IntSan.
[C-SR-6] É FORTEMENTE RECOMENDADO para ativar a inicialização de pilha no kernel para evitar o uso de variáveis locais não inicializadas (
CONFIG_INIT_STACK_ALL
ouCONFIG_INIT_STACK_ALL_ZERO
). Além disso, as implementações de dispositivos NÃO DEVEM presumir o valor usado pelo compilador para inicializar os locais.[C-SR-7] É FORTEMENTE RECOMENDADO para ativar a inicialização de heap no kernel para evitar usos de alocações de heap não inicializadas (
CONFIG_INIT_ON_ALLOC_DEFAULT_ON
) e NÃO DEVEM assumir o valor usado pelo kernel para inicializar essas alocações.
-
Ver revisão
- [C-1-6] PRECISA oferecer suporte a uma das seguintes opções:
- IKeymasterDevice 3.0,
- IKeymasterDevice 4.0,
- IKeymasterDevice 4.1,
- IKeyMintDevice versão 1 ou
- IKeyMintDevice versão 2.
- [C-1-6] PRECISA oferecer suporte a uma das seguintes opções:
9.11.1. Tela de bloqueio segura, autenticação e dispositivos virtuais:
Ver revisão
- [C-8-3] Elas NÃO PODEM expor uma API para uso por apps de terceiros com o objetivo de mudar o estado de bloqueio.
Ver revisão
- [C-12-4] PRECISA chamar
TrustManagerService.revokeTrust()
- depois de no máximo 24 horas da concessão da confiança ou
- Depois de um período de inatividade de 8 horas ou
- Se as implementações não estiverem usando o alcance criptograficamente seguro e preciso, conforme definido em [C-12-5], quando a conexão com o dispositivo físico próximo for perdida.
- [C-12-5] As implementações que dependem de um alcance seguro e preciso para atender aos
requisitos de [C-12-4] PRECISAM usar uma das soluções abaixo:
- Implementações que usam UWB:
- PRECISA atender aos requisitos de calibragem, certificação, precisão e conformidade da UWB descritos em 7.4.9.
- PRECISA usar um dos modos de segurança do P-STS listados em 7.4.9.
- Implementações usando a Rede de Reconhecimento de Vizinhança (NAN, na sigla em inglês) Wi-Fi:
- PRECISA atender aos requisitos de precisão em 2.2.1 [7.4.2.5/H-SR-1], usar a largura de banda de 160 MHz (ou mais recente) e seguir as etapas de configuração de medição especificadas em Calibragem de presença.
- PRECISA usar o LTF seguro, conforme definido na IEEE 802.11az.
- Implementações que usam UWB:
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] PRECISA medir e compensar o deslocamento Rx
para garantir que o RSSI médio do BLE seja de -50 dBm +/-15 dB a 1 m de distância de
um dispositivo de referência transmitindo em
ADVERTISE_TX_POWER_HIGH
. - [7.4.3/H-1-4] PRECISA medir e compensar o deslocamento Tx para garantir que o RSSI médio do BLE seja -50 dBm +/-15 dB ao ler 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] PRECISA medir e compensar o deslocamento Rx
para garantir que o RSSI médio do BLE seja de -50 dBm +/-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 forem compatíveis com a API System
HotwordDetectionService
ou outro mecanismo para detecção de hotword sem indicação de acesso ao microfone, elas:- [9.8/H-1-6] NÃO PODE permitir que mais de 100 bytes de dados sejam transmitidos do serviço de detecção de hotword em cada resultado bem-sucedido de hotword, exceto dados de áudio transmitidos pelo HotwordAudioStream.
Ver revisão
Mude [9.8/H-1-13] para:
- [9.8/H-SR-3] É RECOMENDADO ALTAMENTE para reiniciar o processo que hospeda o serviço de detecção de hotwords pelo menos uma vez a cada hora ou a cada 30 eventos de acionamento de hardware, o que ocorrer primeiro.
Ver revisão
Remoção dos requisitos [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.U
paraandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, elas:- [7.5/H-1-3] PRECISA oferecer suporte à propriedade
android.info.supportedHardwareLevel
comoFULL
ou melhor para a câmera principal traseira eLIMITED
ou melhor para a câmera principal frontal.
- [7.5/H-1-3] PRECISA oferecer suporte à propriedade
-
Ver revisão
Se as implementações de dispositivos de televisão não tiverem uma tela integrada, mas forem compatíveis com uma tela externa conectada via HDMI, elas:
- [5.8/T-0-1] PRECISA definir o modo de saída HDMI
com a resolução mais alta para o formato de pixel escolhido que funcione
com taxa de atualização de 50 ou 60 Hz para a tela externa, dependendo da taxa de atualização de vídeo
da região em que o dispositivo é vendido.
É NECESSÁRIO configurar o modo de saída HDMI para selecionar a resolução máxima compatível com uma taxa de atualização de 50 Hz ou 60 Hz.
- [5.8/T-0-1] PRECISA definir o modo de saída HDMI
com a resolução mais alta para o formato de pixel escolhido que funcione
com taxa de atualização de 50 ou 60 Hz para a tela externa, dependendo da taxa de atualização de vídeo
da região em que o dispositivo é vendido.
3. software
3.5.1. Restrição de aplicativo:
Ver revisão
- Requisito removido [C-1-9]
5. Compatibilidade multimídia
-
Ver revisão
Se as implementações de dispositivos declararem suporte ao decodificador Dolby Vision usando
HDR_TYPE_DOLBY_VISION
, elas:- [C-1-3] PRECISA definir o ID da faixa das camadas de base compatíveis com versões anteriores (se houver) para ser igual ao ID da faixa 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 oferecerem suporte a telas com a configuração de tamanho
UI_MODE_TYPE_NORMAL
e usarem telas físicas com cantos arredondados para renderizar essas telas, elas:- [C-1-1] PRECISA garantir que pelo menos um dos requisitos a seguir
seja atendido para cada tela:
- Quando
uma caixa de 15uma dp de 18 dp por1518 dp está ancorada em cada canto da tela lógica, pelo menos um pixel de cada caixa fica visível na tela.
- Quando
- [C-1-1] PRECISA garantir que pelo menos um dos requisitos a seguir
seja atendido para cada tela:
-
Ver revisão
Os seguintes requisitos foram restabelecidos:
Se as implementações de dispositivo declararem
FEATURE_BLUETOOTH_LE
, elas:[C-SR-2] É MUITO RECOMENDADO para medir e compensar o deslocamento Rx para garantir que o RSSI médio do BLE seja de -60 dBm +/-10 dB a 1 m de distância de um dispositivo de referência transmitindo em
ADVERTISE_TX_POWER_HIGH
, em que os dispositivos são orientados de forma que estejam em "planos paralelos" com telas voltadas para a mesma direção.[C-SR-3] É MUITO RECOMENDADO para medir e compensar o deslocamento Tx para garantir que o RSSI médio do BLE seja -60 dBm +/-10 dB ao ler a partir de um dispositivo de referência posicionado a 1 m de distância e transmitindo em
ADVERTISE_TX_POWER_HIGH
, em que os dispositivos são orientados de tal forma que estejam em "planos paralelos" com telas voltadas para a mesma direção.
Ver revisão
Os requisitos [C-10-3] e [C-10-4] foram movidos para 2.2.1. Hardware.
- [C-10-3] PRECISA medir e compensar o deslocamento Rx para
garantir que o RSSI médio do BLE seja -55 dBm +/-10 dB a 1 m de distância de um
dispositivo de referência transmitindo em
ADVERTISE_TX_POWER_HIGH
. - [C-10-4] PRECISA medir e compensar o deslocamento Tx para
garantir que o RSSI médio do BLE seja -55 dBm +/-10 dB ao ler 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 compatibilidade com qualquer ABI de 64 bits (com ou sem ABI de 32 bits):
-
Ver revisão
- [7.5/H-1-13] PRECISA oferecer suporte ao recurso
LOGICAL_MULTI_CAMERA
para a câmera traseira principal se houver mais de uma câmera RGB.
- [7.5/H-1-13] PRECISA oferecer suporte ao recurso
-
Ver revisão
[5.8/T-0-1] PRECISA definir o modo de saída HDMI com a resolução mais alta para o formato SDR ou HDR escolhido que funcione com uma taxa de atualização de 50 ou 60 Hz para a tela externa.
É NECESSÁRIO definir o modo de saída HDMI para selecionar a resolução máxima compatível com uma taxa de atualização de 50 Hz ou 60 Hz.
-
Ver revisão
- [9/W-0-1] PRECISA declarar a
android.hardware.security.model.compatible feature
.
- [9/W-0-1] PRECISA declarar a
6. Compatibilidade com opções e ferramentas para desenvolvedores
6.1. Ferramentas para desenvolvedores:
Ver revisão
- [C-0-12] É NECESSÁRIO gravar um Atom
LMK_KILL_OCCURRED_FIELD_NUMBER
no
Ver revisão
- [C-0-13] É NECESSÁRIO implementar o comando shell
dumpsys gpu --gpuwork
para exibir
- [C-0-12] É NECESSÁRIO gravar um Atom
9. Compatibilidade do modelo de segurança
-
Ver revisão
Se as implementações de dispositivos usarem um kernel do Linux capaz de oferecer suporte ao SELinux, elas:
Ver revisão
Se as implementações de dispositivos usarem kernel diferente do Linux ou Linux sem SELinux, elas:
4 de outubro de 2023
2. tipos de dispositivos
2.2. Requisitos do dispositivo portátil:
Ver revisão
As implementações de dispositivos Android serão classificadas como portáteis se atenderem a todos os critérios abaixo:
- Ter uma tela diagonal física no intervalo de
4 polegadas
3,3 polegadas (ou 2,5 polegadas para implementações de dispositivos enviadas no nível 29 da API ou anterior)a 8 polegadas.
Iniciar novos requisitos
- Ter uma interface de entrada touchscreen.
- Ter uma tela diagonal física no intervalo de
4 polegadas
-
Ver revisão
Implementações de dispositivos portáteis:
- [7.1.1.1/H-0-1] PRECISA ter pelo menos uma
tela compatível com Android que atenda a todos os requisitos descritos neste documento.que mede pelo menos 2,2” na borda curta e 3,4” na borda longa.
Se as implementações de dispositivos portáteis permitirem a rotação da tela de software, elas:
- [7.1.1.1/H-1-1]* PRECISA disponibilizar a tela lógica para aplicativos de terceiros com pelo menos 2 polegadas nas bordas curtas e 2,7 polegadas nas bordas maiores. Os dispositivos que foram enviados com uma API do Android de nível 29 ou anterior podem ser isentos desse requisito.
Se as implementações de dispositivos portáteis não oferecerem suporte à rotação da tela de software, elas vão:
- [7.1.1.1/H-2-1]* PRECISA fazer com que a tela lógica disponibilizada para aplicativos de terceiros tenha pelo menos 2,7 polegadas nas bordas curtas. Os dispositivos que foram enviados com uma API do Android de nível 29 ou anterior podem ser isentos desse requisito.
Iniciar novos requisitos
[7.1.1.1/H-0-3]* É NECESSÁRIO mapear cada tela
UI_MODE_NORMAL
disponibilizada para aplicativos de terceiros em uma área de tela física desobstruída que tenha pelo menos 2,2” na borda curta e 3,4” na borda longa.[7.1.1.3/H-0-1]* PRECISA definir o valor de
DENSITY_DEVICE_STABLE
como 92% ou maior que a densidade física real da tela correspondente.
Se as implementações de dispositivos portáteis declararem
android.hardware.audio.output
eandroid.hardware.microphone
, elas:[5.6/H-1-1] PRECISA ter uma latência média contínua de ida e volta de 300 milissegundos ou menos de 5 medições, com um Desvio médio absoluto menor que 30 ms, nos seguintes caminhos de dados: "alto-falante para microfone", adaptador de loopback de 3,5 mm (se compatível) e loopback USB (se compatível).
[5.6/H-1-2] PRECISA ter uma latência média entre o toque e o tom de 300 milissegundos ou menos em pelo menos cinco medições do alto-falante para o caminho de dados do microfone.
Se as implementações de dispositivos portáteis incluírem pelo menos um atuador tátil, elas:
- [7,10/H]* NÃO DEVE usar um atuador tátil (vibrador) de massa giratória excêntrica (ERM).
- [7.10/H]* DEVE implementar todas as constantes públicas para retorno tátil claro em android.view.HapticFeedbackConstants, ou seja, (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_START, KEY_PRESS, TEXT_HAND_VILEASE_MOV, KEY_PRESS, TEXT_HAND_VILE
PRIMITIVE_*
Algumas dessas primitivas, como LOW_TICK e SPIN, só serão viáveis se a vibração for compatível com frequências relativamente baixas.- [7.10/H]* DEVE seguir as orientações de mapeamento de 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 as APIs createOneShot() e createWaveform().
- [7.10/H]* DEVE verificar se o resultado da API pública android.os.Vibrator.hasAmplitudeControl() reflete corretamente os recursos da vibração.
- [7,10/H]* DEVE posicionar o posicionamento do atuador perto do local em que 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 de uso geral 7.10 , elas:
- [7,10/H] DEVE posicionar o posicionamento do atuador perto do local em que o dispositivo normalmente é segurado ou tocado pelas mãos.
- [7,10/H] DEVE mover o atuador tátil no eixo X (esquerda-direita) da orientação natural
retratodo dispositivo.
Se as implementações de dispositivos portáteis tiverem um atuador tátil de uso geral que é um atuador ressonante linear (LRA, na sigla em inglês) do eixo X, elas:
- [7,10/H] DEVE ter a frequência ressonante do LRA do eixo X abaixo de 200 Hz.
- [7.1.1.1/H-0-1] PRECISA ter pelo menos uma
-
Ver revisão
As implementações de dispositivos portáteis PRECISAM oferecer suporte aos 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 PRECISAM oferecer suporte aos 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 Recentes, conforme detalhado na seção 7.2.3, mudarem a interface, elas:
- [3.8.3/H-1-1] PRECISA implementar o comportamento de fixação da tela e fornecer ao usuário um menu de configurações para ativar ou desativar o recurso.
Se as implementações de dispositivos portáteis incluírem suporte às APIs
ControlsProviderService
eControl
e permitirem que apps de terceiros publiquem controles de dispositivos, elas:- [3.8.16/H-1-6] As implementações de dispositivos
PRECISAM renderizar com precisão a funcionalidade do usuário da seguinte maneira:
- Se o dispositivo tiver definido
config_supportsMultiWindow=true
e o app declarar os metadadosMETA_DATA_PANEL_ACTIVITY
na declaraçãoControlsProviderService
, incluindo o ComponentName de uma atividade válida (conforme definido pela API), o app PRECISA incorporar essa atividade nessa funcionalidade do usuário. - Se o app não declarar os metadados
META_DATA_PANEL_ACTIVITY
, ele PRECISA renderizar os campos especificados conforme fornecido pela APIControlsProviderService
, bem como todos os campos especificados fornecidos pelas APIs Control.
- Se o dispositivo tiver definido
- [3.8.16/H-1-7] Se o app declarar os metadados
META_DATA_PANEL_ACTIVITY
, ele PRECISA transmitir o valor da configuração definida em [3.8.16/H-1-5] usandoEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS
ao iniciar a atividade incorporada.
Se as implementações de dispositivos permitirem que os usuários façam qualquer tipo de ligação, eles
- [7.4.1.2/H-0-1] PRECISA declarar a flag de recurso
android.software.telecom
. - [7.4.1.2/H-0-2] PRECISA implementar o framework de telecomunicações.
-
Ver revisão
Implementações de dispositivos portáteis:
- [8.5/H-0-1] PRECISA fornecer
uma funcionalidade de usuário
no menu "Configurações"para conferir todos os apps com serviços em primeiro plano ativos ou jobs iniciados pelo usuário, incluindo a duração de cada um desses serviços desde que começaram conforme descrito no documento do SDK.e a capacidade de interromper um app que está executando um serviço em primeiro plano ou um job iniciado pelo usuário que esteja executando um serviço em primeiro plano ou que tenha a capacidade de interromper os serviços em primeiro plano ou um job iniciado pelo usuário.- Alguns apps podem estar isentos de serem interrompidos ou listados em uma funcionalidade do usuário, conforme descrito no documento do SDK.
- [8.5/H-0-2]PRECISA fornecer uma funcionalidade de usuário para interromper um app que esteja executando um serviço em primeiro plano ou um job iniciado pelo usuário.
- [8.5/H-0-1] PRECISA fornecer
uma funcionalidade de usuário
-
Ver revisão
Se as implementações de dispositivos declararem suporte a
android.hardware.telephony
, elas:- [9.5/H-1-1] NÃO PODE definir
UserManager.isHeadlessSystemUserMode
comotrue
.
Se as implementações do dispositivo tiverem uma tela de bloqueio segura e incluírem um ou mais agentes de confiança, que implementam a API do sistema
TrustAgentService
, elas:- [9.11.1/H-1-1] PRECISA desafiar o usuário quanto a um dos métodos principais de autenticação recomendados (por exemplo, PIN, padrão ou senha) com mais frequência do que uma vez a cada 72 horas.
Se as implementações de dispositivos portáteis definirem
UserManager.isHeadlessSystemUserMode
comotrue
, elasSe as implementações de dispositivos portáteis forem compatíveis com a API System
HotwordDetectionService
ou outro mecanismo para detecção de hotword sem indicação de acesso ao microfone, elas:- [9.8/H-1-1] PRECISA garantir que o serviço de detecção de hotwords só possa transmitir
dados para o sistema,
ContentCaptureService
ou o serviço de reconhecimento de fala no dispositivo criado porSpeechRecognizer#createOnDeviceSpeechRecognizer()
. - [9.8/H-1-6] NÃO PODE permitir que mais de 100 bytes de dados (excluindo streams de áudio) sejam transmitidos do serviço de detecção de hotword em cada resultado bem-sucedido de hotword.
- [9.8/H-1-15] PRECISA garantir que os streams 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 por voz.
Se as implementações do dispositivo incluem um aplicativo que usa a API System
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 PODE transmitir do serviço de detecção de hotword, dados de áudio, dados que podem ser usados para reconstruir (total ou parcialmente) o áudio ou conteúdos de áudio não relacionados à própria hotword, exceto para
ContentCaptureService
ou o serviço de reconhecimento de fala no dispositivo.
Se as implementações de dispositivos portáteis oferecerem suporte à API System
VisualQueryDetectionService
ou a outro mecanismo para detecção de consultas sem indicação de acesso ao microfone e/ou à câmera, elas:- [9.8/H-3-1] PRECISA garantir que o serviço de detecção de consultas só possa transmitir
dados para o sistema, para a
ContentCaptureService
ou para o serviço de reconhecimento de fala no dispositivo (criado porSpeechRecognizer#createOnDeviceSpeechRecognizer()
). - [9.8/H-3-2] NÃO PODE permitir que nenhuma informação de áudio ou vídeo seja transmitida
para fora do
VisualQueryDetectionService
, exceto paraContentCaptureService
ou para o serviço de reconhecimento de fala no dispositivo. - [9.8/H-3-3] PRECISA mostrar um aviso do usuário na interface do sistema quando o dispositivo detectar a intenção do usuário de interagir com o aplicativo de assistente digital (por exemplo, detectando a presença do usuário pela câmera).
- [9.8/H-3-4] PRECISA exibir um indicador de microfone e mostrar a consulta do usuário detectada na interface logo após a consulta do usuário ser detectada.
- [9.8/H-3-5] NÃO PODE permitir que um aplicativo instalável pelo usuário forneça o serviço de detecção de consulta visual.
- [9.5/H-1-1] NÃO PODE definir
-
Ver revisão
Se as implementações de dispositivos portáteis retornarem
android.os.Build.VERSION_CODES.T
paraandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, elas:- PRECISA 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
paraandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, elas:- [5.1/H-1-1] PRECISA 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 codecs pelos métodos
CodecCapabilities.getMaxSupportedInstances()
eVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-2] PRECISA oferecer suporte a seis instâncias de sessões de decodificador de vídeo por hardware de 8 bits (SDR), (AVC, HEVC, VP9, AV1 ou mais recente) em qualquer combinação de codecs executada simultaneamente com três sessões com resolução de 1080p a 30 fps e três sessões com resolução de 4K a 30fps, a menos que AV1. Os codecs AV1 só são necessários para oferecer suporte à resolução de 1080p, mas ainda precisam oferecer suporte a seis instâncias a 1080p30 fps.
- [5.1/H-1-3] PRECISA 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 codecs pelos métodos
CodecCapabilities.getMaxSupportedInstances()
eVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-4] PRECISA oferecer suporte a seis instâncias de codificadores de vídeo de hardware de 8 bits (SDR), (AVC, HEVC, VP9, AV1 ou mais recente), em qualquer combinação de codecs executada simultaneamente com quatro sessões com resolução de 1080p a 30 fps e duas sessões com resolução de 4K a 30fps, a menos que AV1. Os codecs AV1 só são necessários para oferecer suporte à resolução de 1080p, mas ainda precisam oferecer suporte a seis instâncias a 1080p30 fps.
- [5.1/H-1-5] PRECISA anunciar o número máximo de sessões de codificadores e decodificadores de vídeo em hardware que podem ser executadas simultaneamente em qualquer combinação de codecs por meio dos métodos
CodecCapabilities.getMaxSupportedInstances()
eVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-6] PRECISA oferecer suporte a seis instâncias de decodificador de vídeo por hardware de 8 bits (SDR) e sessões de codificador de vídeo de hardware (AVC, HEVC, VP9, AV1 ou mais recentes) em qualquer combinação de codec que seja executada simultaneamente a três sessões com resolução de 4K a 30 fps (a menos que sessões AV1 sejam de 0p e 10, sendo que, no máximo, 2 são 10p. Os codecs AV1 só são necessários para oferecer suporte à resolução de 1080p, mas ainda precisam oferecer suporte a seis instâncias a 1080p30 fps.
- [5.1/H-1-19] PRECISA oferecer suporte a três 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 mais recentes) em qualquer combinação de codec executada a 4K a 30 fps (RGB AV1), que pode ter no máximo um formato de entrada de superfície em que uma sessão de codificador 02 em que seja possível configurar no máximo 1. A geração de metadados HDR pelo codificador não será necessária se a codificação for pela superfície GL. As sessões do codec AV1 só precisam oferecer suporte à resolução de 1080p, mesmo quando esse requisito exigir 4K.
- [5.1/H-1-7] PRECISA ter uma latência de inicialização de 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 sob carga. O carregamento é definido como uma sessão simultânea de transcodificação de vídeo somente de vídeo de 1080p a 720p usando codecs de vídeo de hardware junto com a inicialização de gravação de áudio e vídeo em 1080p. Para o codec Dolby Vision, a latência de inicialização do codec PRECISA ser de 50 ms ou menos.
- [5.1/H-1-8] PRECISA ter uma latência de inicialização de codec de 30 ms ou menos para uma sessão de codificação de áudio com taxa de bits de 128 kbps ou menor para todos os codificadores de áudio quando estiver sob carga. O carregamento é definido como uma sessão simultânea de transcodificação de vídeo somente de vídeo de 1080p a 720p usando codecs de vídeo de hardware junto com a inicialização de gravação de áudio e vídeo em 1080p.
- [5.1/H-1-9] PRECISA oferecer suporte a duas instâncias de sessões de decodificador de vídeo por hardware seguro (AVC, HEVC, VP9, AV1 ou mais recente) em qualquer combinação de codecs executada simultaneamente em resolução 4K a 30 fps (exceto AV1) para conteúdo HDR de 8 bits (SDR) e 10 bits. As sessões do codec AV1 só precisam oferecer suporte à resolução de 1080p, mesmo quando esse requisito exigir 4K.
- [5.1/H-1-10] PRECISA oferecer suporte a três instâncias de sessões de decodificador de vídeo de hardware não seguras juntas a uma instância de sessão de decodificador de vídeo de hardware seguro (4 instâncias no total) (AVC, HEVC, VP9, AV1 ou mais recente) em qualquer combinação de codecs executada simultaneamente a três sessões com resolução de 4K de 4K a 30 QPS e 1bit fps com resolução máxima de 4K-10 As sessões do codec AV1 só precisam oferecer suporte à resolução de 1080p, mesmo quando esse requisito exigir 4K.
- [5.1/H-1-11] PRECISA oferecer suporte a um decodificador seguro para cada decodificador de hardware AVC, HEVC, VP9 ou AV1 no dispositivo.
- [5.1/H-1-12] PRECISA ter uma latência de inicialização de codec de 40 ms ou menos para uma sessão de decodificação de vídeo de 1080p ou menor para todos os decodificadores de vídeo em hardware quando sob carga. O carregamento é 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 com a inicialização de reprodução de áudio e vídeo em 1080p. Para o codec Dolby Vision, a latência de inicialização do codec PRECISA ser de 50 ms ou menos.
- [5.1/H-1-13] PRECISA ter uma latência de inicialização de codec de 30 ms ou menos para uma sessão de decodificação de áudio com taxa de bits de 128 kbps ou menor para todos os decodificadores de áudio quando estiver sob carga. O carregamento é definido como uma sessão simultânea de transcodificação de vídeo somente de vídeo de 1080p a 720p usando codecs de vídeo de hardware junto com a inicialização de reprodução de áudio e vídeo de 1080p.
- [5.1/H-1-14] PRECISA oferecer suporte ao decodificador de hardware AV1 Main 10, Level 4.1 e granulação.
- [5.1/H-1-15] PRECISA ter pelo menos um decodificador de vídeo por hardware compatível com 4K60.
- [5.1/H-1-16] PRECISA ter pelo menos um codificador de vídeo de hardware compatível com 4K60.
- [5.3/H-1-1] NÃO PODE cair mais de 1 frame em 10 segundos (ou seja, menos de 0,167% de queda de frames) para uma sessão de vídeo de 4K 60 QPS sob carga.
- [5.3/H-1-2] NÃO É POSSÍVEL abandonar mais de 1 frame em 10 segundos durante uma mudança de resolução de vídeo em uma sessão de vídeo de 60 QPS carregada para uma sessão de 4K.
- [5.6/H-1-1] PRECISA ter uma latência de toque para tom de 80 milissegundos ou menos usando o teste por toque do CTS Verifier.
- [5.6/H-1-2] PRECISA ter uma latência de ida e volta de áudio de 80 milissegundos ou menos em pelo menos um caminho de dados compatível.
- [5.6/H-1-3] PRECISA oferecer suporte a áudio de 24 bits ou mais para saída estéreo de mais de 3,5 mm de áudio,
se presente, e por áudio USB, se 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, a AAudio precisa ser usada pelo app no modo de callback de baixa latência. Para a configuração de streaming, um AudioTrack Java precisa ser usado pelo
app. Nas configurações de baixa latência e de streaming, o coletor
de saída HAL precisa aceitar
AUDIO_FORMAT_PCM_24_BIT
,AUDIO_FORMAT_PCM_24_BIT_PACKED
,AUDIO_FORMAT_PCM_32_BIT
ouAUDIO_FORMAT_PCM_FLOAT
como formato de saída de destino. - [5.6/H-1-4] PRECISA oferecer suporte a dispositivos de áudio USB com mais de quatro canais. Essa opção é usada pelos controladores de DJ para a prévia de músicas.
- [5.6/H-1-5] PRECISA oferecer suporte a dispositivos MIDI compatíveis com a classe e declarar a flag de recurso MIDI.
- [5.6/H-1-9] PRECISA oferecer suporte a pelo menos 12 mixes de canais. Isso implica a capacidade de abrir uma faixa de áudio com máscara de canal 7.1.4 e espacializar ou fazer o downmix corretamente de todos os canais para estéreo.
- [5.6/H-SR] É FORTEMENTE RECOMENDADO oferecer suporte a mixagem de 24 canais com pelo menos suporte para máscaras de canal 9.1.6 e 22.2.
- [5.7/H-1-2] PRECISA oferecer suporte a
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
com 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 Frames descriptografados por segundo 60 QPS - [5.1/H-1-17] É NECESSÁRIO ter pelo menos um decodificador de imagem de hardware compatível com o perfil de referência AVIF.
- [5.1/H-1-18] PRECISA oferecer suporte ao codificador AV1, que pode codificar até 480p de resolução a 30 fps e 1 Mbps.
[5.12/H-1-1] PRECISA[5.12/H-SR] é altamente recomendado para oferecer suporte ao recursoFeature_HdrEditing
para todos os codificadores AV1 e HEVC de hardware presentes no dispositivo.- [5.12/H-1-2] PRECISA oferecer suporte ao formato de cores RGBA_1010102 para todos os codificadores AV1 e HEVC de hardware presentes no dispositivo.
- [5.12/H-1-3] PRECISA anunciar o suporte à extensão EXT_YUV_target para amostras de texturas YUV em 8 e 10 bits.
- [7.1.4/H-1-1] PRECISA ter pelo menos seis sobreposições de hardware no compositor de hardware (HWC) da unidade de processamento de dados (DPU, na sigla em inglês), sendo que pelo menos duas delas podem exibir conteúdo de vídeo de 10 bits.
Se as implementações de dispositivos portáteis retornarem
android.os.Build.VERSION_CODES.U
paraandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
e incluírem suporte a um codificador AVC ou HEVC de hardware, elas:- [5.2/H-2-1] PRECISA atender à meta de qualidade mínima definida pelas curvas de distorção de taxa do codificador de vídeo para codecs AVC e HEVC de hardware, conforme definido na documentação que será lançada em breve.
-
Ver revisão
Se as implementações de dispositivos portáteis retornaremandroid.os.Build.VERSION_CODES.U
paraandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, elas:- [7.5/H-1-1] PRECISA ter uma câmera traseira principal com resolução de pelo menos 12 megapixels e compatível com captura de vídeo a 4k a 30 fps. A câmera traseira principal é a traseira com o menor ID de câmera.
- [7.5/H-1-2] PRECISA ter uma câmera frontal principal com resolução de pelo menos 6 megapixels e oferecer suporte a captura de vídeo a 1080p a 30 fps. A câmera frontal principal é a frontal com o menor ID de câmera.
- [7.5/H-1-3] PRECISA oferecer suporte à propriedade
android.info.supportedHardwareLevel
como FULL ou melhor para as duas câmeras principais. - [7.5/H-1-4] PRECISA oferecer suporte a
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
para as duas câmeras principais. - [7.5/H-1-5] PRECISA ter uma latência de captura JPEG da Camera2 menor que 1.000
900ms para uma resolução de 1080p, conforme medido pelo PerformanceTest da câmera CTS em condições de iluminação ITS (3000K) para as duas câmeras principais. - [7.5/H-1-6] PRECISA ter a latência de inicialização da câmera2 (abrir a câmera para o primeiro frame de visualização) menor que 500 ms, conforme medido pelo PerformanceTest da câmera CTS em condições de iluminação ITS (3.000K) para as duas câmeras principais.
- [7.5/H-1-8] PRECISA oferecer suporte a
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW
eandroid.graphics.ImageFormat.RAW_SENSOR
para a câmera traseira principal. - [7.5/H-1-9] PRECISA ter uma câmera principal traseira com suporte a 720p ou 1080p a 240 fps.
- [7.5/H-1-10] PRECISA ter ZOOM_RATIO mínimo de < 1.0 para as câmeras principais se houver uma câmera RGB ultra grande angular voltada para a mesma direção.
- [7.5/H-1-11] PRECISA implementar streaming simultâneo front-back nas câmeras principais.
- [7.5/H-1-12] PRECISA oferecer suporte a
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
para a câmera frontal e a traseira principal. - [7.5/H-1-13] PRECISA oferecer suporte ao recurso
LOGICAL_MULTI_CAMERA
para as câmeras principais se houver mais de uma câmera RGB voltada para a mesma direção. - [7.5/H-1-14] PRECISA oferecer suporte ao recurso
STREAM_USE_CASE
para a câmera frontal principal e a traseira principal. - [7.5/H-1-15] PRECISA oferecer suporte às extensões
Bokeh eModo noturno pelas extensões CameraX e Camera2 para câmeras principais. - [7.5/H-1-16] PRECISA oferecer suporte ao recurso DYNAMIC_RANGE_TEN_BIT para as câmeras principais.
- O dispositivo [7.5/H-1-17] PRECISA oferecer suporte ao CONTROL_SCENE_MODE_FACE_PRIORITY e à detecção facial (STATISTICS_FACE_DETECT_MODE_SIMPLE ou STATISTICS_FACE_DETECT_MODE_FULL) para as câmeras principais.
-
Ver revisão
Se as implementações de dispositivos portáteis retornaremandroid.os.Build.VERSION_CODES.U
paraandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, elas:- [7.1.1.1/H-2-1] PRECISA ter uma resolução de tela de pelo menos 1080p.
- [7.1.1.3/H-2-1] PRECISA ter uma densidade de tela de pelo menos 400 dpi.
- [7.1.1.3/H-3-1] PRECISA ter uma tela HDR com suporte a pelo menos 1.000 nits, em média.
- [7.6.1/H-2-1] PRECISA ter pelo menos 8 GB de memória física.
-
Ver revisão
Se as implementações de dispositivos portáteis retornaremandroid.os.Build.VERSION_CODES.U
paraandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, elas:- [8.2/H-1-1] PRECISA garantir um desempenho de gravação sequencial de pelo menos 150 MB/s.
- [8.2/H-1-2] PRECISA garantir um desempenho de gravação aleatória de pelo menos 10 MB/s.
- [8.2/H-1-3] PRECISA garantir um desempenho de leitura sequencial de pelo menos 250 MB/s.
- [8.2/H-1-4] PRECISA garantir um desempenho de leitura aleatória de pelo menos 100 MB/s.
- [8.2/H-1-5] PRECISA garantir um desempenho de leitura e gravação sequencial paralelo, com desempenho de leitura e gravação 2x e 1x de pelo menos 50 MB/s.
-
Ver revisão
As implementações de dispositivos de televisão PRECISAM oferecer suporte aos 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 PRECISAM oferecer suporte aos 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 do dispositivo tiverem uma tela de bloqueio segura e incluírem um ou mais agentes de confiança, que implementam a API do sistema
TrustAgentService
, elas:- [9.11.1/W-1-1] PRECISA desafiar o usuário quanto a um dos métodos principais de autenticação recomendados (por exemplo, PIN, padrão ou senha) com mais frequência do que uma vez a cada 72 horas.
-
Ver revisão
Se as implementações de dispositivos incluírem suporte a rádio de transmissão AM/FM e expõem a funcionalidade a qualquer app, elas:
- [7.4
.10/A-0-1] PRECISA declarar suporte aFEATURE_BROADCAST_RADIO
.
Uma câmera de visualização externa é uma câmera que captura cenas fora da implementação do dispositivo, como a câmera traseira.
Implementações de dispositivos automotivos:
- DEVE incluir uma ou mais câmeras de visualização externa.
Se as implementações de dispositivos automotivos incluírem uma câmera de visualização externa, essa câmera:
- [7.5/A-1-1] NÃO PODE ter câmeras de visualização externa acessíveis pelas APIs Android Camera, a menos que obedeçam aos requisitos principais da câmera.
- [7.5/A-SR-1] É FORTEMENTE RECOMENDADO não girar ou espelhar a visualização da câmera horizontalmente.
- [7.5/A-SR-2] É MUITO RECOMENDADO ter uma resolução de pelo menos 1,3 megapixels.
- DEVE ter hardware de foco fixo ou EDOF (profundidade de campo estendida).
- PODE ter o foco automático de hardware ou de software implementado no driver da câmera.
Se as implementações de dispositivos automotivos incluírem uma ou mais câmeras de visualização externa e carregarem o serviço Exterior View System (EVS), para essa câmera, elas:
- [7.5/A-2-1] NÃO PODE girar nem espelhar a visualização da câmera horizontalmente.
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] PRECISA informar o flag de recurso
android.hardware.camera.any
. - [7.5/A-3-2] não PRECISA declarar a câmera como uma câmera do sistema.
- PODE ser compatível com câmeras externas descritas na seção 7.5.3.
- PODE incluir recursos (como foco automático etc.) disponíveis para as câmeras traseiras, conforme descrito na seção 7.5.1.
Uma câmera traseira significa uma câmera voltada para o mundo que pode estar localizada em qualquer lugar no veículo e voltada para o lado de fora da cabine. Ou seja, ela imagens na lateral do carro, como a câmera traseira.
Uma câmera frontal significa uma câmera voltada ao usuário, que pode estar localizada em qualquer lugar do veículo e voltada para o interior da cabine. Ou seja, imagens do usuário, por exemplo, para videoconferências e aplicativos semelhantes.
Implementações de dispositivos automotivos:
- [7.5/A-SR-1] É FORTEMENTE RECOMENDADO a inclusão de uma ou mais câmeras voltadas para o mundo.
- PODE incluir uma ou mais câmeras voltadas para o usuário.
- [7.5/A-SR-2] É FORTEMENTE RECOMENDADO para oferecer suporte a streaming simultâneo de várias câmeras.
Se as implementações de dispositivos automotivos incluírem pelo menos uma câmera voltada para o mundo, elas:
- [7.5/A-1-1] PRECISA estar orientada para que a dimensão longa da câmera se alinhe ao plano X-Y dos eixos do sensor automotivo do Android.
- [7.5/A-SR-3] É FORTEMENTE RECOMENDADO ter o hardware de foco fixo ou EDOF (profundidade estendida de campo).
- [7.5/A-1-2] PRECISA ter a câmera voltada para o mundo principal com o menor ID de câmera.
Se as implementações de dispositivos automotivos incluírem pelo menos uma câmera voltada ao usuário, para essa câmera:
- [7.5/A-2-1] A principal câmera voltada ao usuário PRECISA ser aquela com o menor ID.
- PODE ser orientado para que a dimensão longa da câmera se alinhe ao plano X-Y dos eixos do sensor automotivo do Android.
Se as implementações de dispositivos automotivos incluírem uma câmera acessível pela API
android.hardware.Camera
ouandroid.hardware.camera2
, elas:- [7.5/A-3-1] PRECISA obedecer aos principais requisitos de câmera da seção 7.5.
Se as implementações de dispositivos automotivos incluírem uma câmera que não pode ser acessada pela API
android.hardware.Camera
ouandroid.hardware.camera2
, elas:- [7.5/A-4-1] PRECISA estar acessível pelo serviço do sistema de visualização estendida.
Se as implementações de dispositivos automotivos incluírem uma ou mais câmeras acessíveis pelo serviço de sistema de visualização estendido, para essas câmeras, elas:
- [7.5/A-5-1] NÃO PODE girar nem espelhar a visualização da câmera horizontalmente.
- [7.5/A-SR-4] É MUITO RECOMENDADO ter uma resolução de pelo menos 1,3 megapixel.
Se as implementações de dispositivos automotivos incluírem uma ou mais câmeras acessíveis pelo serviço do sistema de visualização estendida e pela API
android.hardware.Camera
ouandroid.hardware.Camera2
, elas:- [7.5/A-6-1] PRECISA informar o mesmo ID da câmera.
Se as implementações de dispositivos automotivos fornecerem uma API de câmera reservada, elas:
- [7.5/A-7-1] PRECISA implementar essa API de câmera usando a
API
android.hardware.camera2
ou a API Extended View System.
- [7.4
-
Ver revisão
Implementações de dispositivos automotivos:
- [3.8/A-0-1] NÃO PODE permitir que usuários secundários completos que não sejam o usuário atual em primeiro plano iniciem atividades e tenham acesso à interface em qualquer tela.
-
Ver revisão
Se as implementações de dispositivos automotivos declararem
android.hardware.microphone
, elas vão:- [9.8.2/A-1-1] PRECISA exibir o indicador de microfone quando
um app estiver acessando dados de áudio pelo microfone, mas não quando o
microfone é acessado somente por
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
ou apps com as funções mencionadas na seção 9.1 com o identificador CDD [C-4-X]. - [9.8.2/A-1-2] não pode ocultar o indicador de microfone para apps do sistema que têm interfaces do usuário visíveis ou interação direta com o usuário.
- [9.8.2/A-1-3] PRECISA fornecer uma funcionalidade de usuário para ativar ou desativar o microfone no app Configurações.
Se as implementações de dispositivos automotivos declararem
android.hardware.camera.any
, elas:- [9.8.2/A-2-1] PRECISA exibir o indicador da câmera quando um app estiver acessando dados da câmera em tempo real, mas não quando a câmera só estiver sendo acessada por apps que desempenham as funções conforme definido
chamadona Seção 9.1 Permissões com identificador CDD [C-4-X][C-3-X].
- [9.8.2/A-2-3] PRECISA fornecer uma funcionalidade de usuário para ativar ou desativar a câmera no app Configurações.
- [9.8.2/A-2-4] PRECISA mostrar apps recentes e ativos usando a câmera como retornada
de
PermissionManager.getIndicatorAppOpUsageData()
, com todas as mensagens de atribuição associadas a eles.
Se as implementações do dispositivo tiverem uma tela de bloqueio segura e incluírem um ou mais agentes de confiança, que implementam a API
TrustAgentService
do sistema, elas:- [9.11.1/A-1-1] PRECISA desafiar o usuário quanto a um dos métodos de autenticação principais recomendados (por exemplo: PIN, padrão ou senha) com mais frequência do que uma vez a cada 336 horas.
- [9.8.2/A-1-1] PRECISA exibir o indicador de microfone quando
um app estiver acessando dados de áudio pelo microfone, mas não quando o
microfone é acessado somente por
3. software
3.1. Compatibilidade de APIs gerenciadas:
Ver revisão
Implementações de dispositivos:
- [C-0-8] NÃO É POSSÍVEL oferecer suporte à instalação de aplicativos destinados a um nível de API menor que 23.
3.2.3.5. Intents de aplicativos condicionais:
Ver revisão
Se as implementações de dispositivos informarem
android.hardware.nfc.uicc
ouandroid.hardware.nfc.ese
, elas:- [C-19-1] PRECISA implementar a API de intent NfcAdapter.ACTION_TRANSACTION_DETECTED (como "EVT_TRANSACTION" definido pela especificação técnica TS.26 da GSM Association: requisitos de dispositivo NFC).
3.3.1. Interfaces binárias do aplicativo:
Ver revisão
Implementações de dispositivos:
- [C-0-12] É NECESSÁRIO exportar os símbolos de função para os principais símbolos de função
Vulkan 1.0Vulkan 1.1, assim como as extensõesVK_KHR_surface
,VK_KHR_android_surface
,VK_KHR_swapchain
,VK_KHR_maintenance1
eVK_KHR_get_physical_device_properties2
usando a bibliotecalibvulkan.so
. Embora todos os símbolos PRECISAM estar presentes, a seção 7.1.4.2 descreve em mais detalhes os requisitos de quando a implementação completa de cada função correspondente é esperada.
- [C-0-12] É NECESSÁRIO exportar os símbolos de função para os principais símbolos de função
-
Ver revisão
Se as implementações de dispositivos incluírem uma saída de tela ou vídeo, elas:
- [C-1-5] PRECISA gerar paletas de tons de cores dinâmicas usando estilos de temas de cores
enumerados na documentação do
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
(consulteandroid.theme.customization.theme_styles
), ou seja,TONAL_SPOT
,VIBRANT
,EXPRESSIVE
,SPRITZ
,RAINBOW
,FRUIT_SALAD
, eMONOCHROMATIC
.
- [C-1-5] PRECISA gerar paletas de tons de cores dinâmicas usando estilos de temas de cores
enumerados na documentação do
-
Ver revisão
Se as implementações do dispositivo, incluindo a tecla de navegação da função Recentes, conforme detalhado na seção 7.2.3, mudarem a interface, elas:
- [C-1-2] PRECISA implementar o comportamento de fixação da tela e fornecer ao usuário um menu de configurações para ativar ou desativar o recurso.
3.9.2 Suporte de perfil gerenciado:
Ver revisão
Se as implementações de dispositivo declararem
android.software.managed_users
, elas:- [C-1-10] PRECISA garantir que os dados da captura de tela sejam salvos no armazenamento do perfil de trabalho
quando uma captura de tela for feita com uma janela
topActivity
com foco (aquela com que o usuário interagiu por último entre todas as atividades) e pertence a um app do perfil de trabalho. - [C-1-11] NÃO É POSSÍVEL capturar nenhum outro conteúdo da tela (barra do sistema, notificações ou qualquer conteúdo do perfil pessoal), exceto a janela/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 não sejam salvos no perfil de trabalho).
- [C-1-10] PRECISA garantir que os dados da captura de tela sejam salvos no armazenamento do perfil de trabalho
quando uma captura de tela for feita com uma janela
3.9.5 Framework de resolução de políticas do dispositivo: nova seção.
Ver revisão
Se as implementações de dispositivos informarem
android.software.device_admin
ouandroid.software.managed_users
, elas:- [C-1-1] PRECISA resolver os conflitos de políticas do dispositivo, conforme documentado na documentação do AOSP.
5. Compatibilidade multimídia
-
Ver revisão
As implementações de dispositivos PRECISAM ser compatíveis com a seguinte codificação de imagem:
- [C-0-4] AVIF
- Os dispositivos precisam oferecer suporte a
BITRATE_MODE_CQ
e ao perfil de referência.
- Os dispositivos precisam oferecer suporte a
- [C-0-4] AVIF
5.1.5. Decodificação de imagens:
Ver revisão
As implementações de dispositivos PRECISAM oferecer suporte à decodificação da seguinte codificação de imagem:
[C-0-7] AVIF (perfil de referência)
5.1.6. Detalhes dos codecs de imagem:
Ver revisão
Formato/Codec Detalhes Tipos de arquivos/formatos de contêiner compatíveis JPEG Básico+progressivo JPEG (.jpg) GIF GIF (.gif) PNG PNG (.png) BMP BMP (.bmp) WebP WebP (.webp) Raw ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw) HEIF Imagem, Coleção de imagens, Sequência de imagens HEIF (.heif), HEIC (.heic) AVIF (perfil de referência) Imagem, coleta de imagens, perfil de referência de sequência de imagens Contêiner HEIF (.avif) 5.1.8. Lista de codecs de vídeo:
Ver revisão
Formato/Codec Detalhes Tipos de arquivos/formatos de contêiner aceitos H.263 - 3GPP (.3gp)
- MPEG-4 (.mp4)
- Matroska (.mkv, somente decodificação)
H.264 AVC Consulte detalhes nas seções 5.2 e 5.3 - 3GPP (.3gp)
- MPEG-4 (.mp4)
- MPEG-2 TS (.ts, não pesquisável)
- Matroska (.mkv, somente decodificação)
H.265 HEVC Consulte detalhes na seção 5.3 - MPEG-4 (.mp4)
- Matroska (.mkv, somente decodificação)
MPEG-2 Perfil principal - MPEG2-TS (.ts, não pesquisável)
- MPEG-4 (.mp4, somente decodificação)
- Matroska (.mkv, somente decodificação)
MPEG-4 SP - 3GPP (.3gp)
- MPEG-4 (.mp4)
- Matroska (.mkv, somente decodificação)
VP8 Consulte detalhes nas seções 5.2 e 5.3 - WebM (.webm)
- Matroska (.mkv)
VP9 Consulte detalhes na seção 5.3 - WebM (.webm)
- Matroska (.mkv)
AV1 Consulte as seções 5.2 e 5.3 para mais detalhes - MPEG-4 (.mp4)
- Matroska (.mkv, somente decodificação)
5.1.10. Caracterização do codec de mídia:
Ver revisão
Se as implementações de dispositivos forem compatíveis com codecs de vídeo:
- [C-2-1] Todos os codecs de vídeo PRECISAM publicar dados alcançáveis de frame rate nos tamanhos a seguir se compatíveis com o codec:
SD (baixa qualidade) SD (alta qualidade) HD 720p HD 1080p Ultra HD Resolução do vídeo - 176 x 144 px (H263, MPEG2, MPEG4)
- 352 x 288 px (codificador MPEG4, H263, MPEG2)
- 320 x 180 px (VP8, VP8)
- 320 x 240 px (outros)
- 704 x 576 px (H263)
- 640 x 360 px (VP8, VP9)
- 640 x 480 px (codificador MPEG4)
- 720 x 480 px (outro, AV1)
- 1.408 x 1.152 px (H263)
- 1280 x 720 px (outro, AV1)
1920 x 1080 px (exceto MPEG4, AV1) 3.840 x 2.160 px (HEVC, VP9, AV1) -
Ver revisão
Se as implementações de dispositivos oferecerem suporte a qualquer codificador de vídeo e o disponibilizarem para apps de terceiros, elas:- em duas janelas deslizantes, NÃO É POSSÍVEL TER mais de 15% da taxa de bits entre intervalos intraframe (I-frame).
- NÃO SEJA mais que 100% acima da taxa de bits em uma janela deslizante de 1 segundo.
Se as implementações de dispositivos oferecerem suporte a qualquer codificador de vídeo e os disponibilizarem para apps de terceiros, e definirem
MediaFormat.KEY_BITRATE_MODE
comoBITRATE_MODE_VBR
para que o codificador opere no modo "Taxa de bits variável", enquanto isso não afetar o valor mínimo de qualidade mínimo, a taxa de bits codificada :[C-5-1] PRECISANÃO ter mais de 15% da taxa de bits entre intervalos intraframe (I-frame) em uma janela deslizante.[C-5-2] PRECISANÃO estar acima de 100% da taxa de bits em uma janela deslizante de um segundo.
Se as implementações de dispositivos oferecerem suporte a qualquer codificador de vídeo e os disponibilizarem para apps de terceiros, e definirem
MediaFormat.KEY_BITRATE_MODE
comoBITRATE_MODE_CBR
para que o codificador opere no modo de taxa de bits constante, a taxa de bits codificada:[C-6-1] PRECISA[C-SR-2] é FORTEMENTE RECOMENDADO para NÃO estar acima de 15% da taxa de bits desejada em uma janela deslizante de 1 segundo.
-
Ver revisão
Se as implementações de dispositivos oferecerem suporte a codificadores H.263 e as disponibilizarem para apps de terceiros, elas:
- [C-1-1] PRECISA oferecer suporte à resolução QCIF (176 x 144) usando o perfil de referência de nível 45. A resolução do SQCIF é opcional.
DEVE oferecer suporte a taxas de bits configuráveis dinamicamente para o codificador compatível.
-
Ver revisão
Se as implementações de dispositivos oferecerem suporte ao codec H.265, elas:
- [C-1-1] PRECISA oferecer suporte ao perfil principal de nível 3 com até resolução de 512 x 512.
DEVE oferecer suporte aos perfis de codificação em HD, conforme indicado na tabela a seguir.- [C-SR-1] é FORTEMENTE RECOMENDADO oferecer suporte ao perfil SD de 720 x 480 e aos 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 forem compatíveis com o codec AV1, elas:
- [C-1-1] PRECISA oferecer suporte ao Perfil principal, incluindo conteúdo de 8 e 10 bits.
[C-1-2] PRECISA publicar os dados de desempenho, ou seja, informar os dados usando as APIs
getSupportedFrameRatesFor()
ougetSupportedPerformancePoints()
para as resoluções compatíveis na tabela abaixo.[C-1-3] PRECISA aceitar metadados HDR e enviá-los para o bitstream.
Se o codificador AV1 tiver aceleração de hardware, ele:
- [C-2-1] PRECISA oferecer suporte ao perfil de codificação HD1080p da tabela abaixo, inclusive:
SD HD 720p HD 1080p Ultra HD Resolução do vídeo 720 x 480 px 1.280 x 720 px 1.920 x 1.080 px 3.840 x 2.160 px Frame rate do vídeo 30 fps 30 fps 30 fps 30 fps Taxa de bits do vídeo 5 Mbps 8 Mbps 16 Mbps 50 Mbps -
Ver revisão
Se as implementações de dispositivos oferecerem suporte a decodificadores H.263, elas:
- [C-1-1] PRECISA oferecer suporte ao perfil de referência de nível 30 (resoluções CIF, QCIF e SQCIF a 30 fps 384 kbps) e nível 45 (resoluções QCIF e SQCIF a 30 fps 128 kbps).
-
Ver revisão
Se as implementações de dispositivos oferecerem suporte ao codec AV1, elas:- [C-1-1] PRECISA oferecer suporte ao Perfil 0, incluindo conteúdo de 10 bits.
Se as implementações de dispositivos forem compatíveis com o codec AV1 e o disponibilizarem para aplicativos de terceiros, elas:
- [C-1-1] PRECISA oferecer suporte ao Perfil principal, incluindo conteúdo de 8 e 10 bits.
Se as implementações de dispositivos oferecerem suporte ao codec AV1 com um decodificador acelerado por hardware, elas:
- [C-2-1] PRECISA decodificar pelo menos os perfis de decodificação de vídeo em HD de 720p da tabela abaixo quando a altura informada pelo método
Display.getSupportedModes()
for igual ou maior que 720p. - [C-2-2] PRECISA decodificar pelo menos os perfis de decodificação de vídeo em HD de 1080p
da tabela abaixo quando a altura informada pelo método
Display.getSupportedModes()
é igual ou maior que 1080p.
SD HD 720p HD 1080p Ultra HD Resolução do vídeo 720 x 480 px 1.280 x 720 px 1.920 x 1.080 px 3.840 x 2.160 px Frame rate do vídeo 30 fps 30 fps 30 fps 30 fps Taxa de bits do vídeo 5 Mbps 8 Mbps 16 Mbps 50 Mbps Se as implementações de dispositivos oferecerem suporte ao perfil HDR usando as APIs Media, elas:
- [C-3-1] PRECISA oferecer suporte à extração e saída de metadados HDR do bitstream e/ou do contêiner.
- [C-3-2] PRECISA mostrar 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 dispositivo declararem
android.hardware.microphone
, elas:- DEVE definir a sensibilidade da entrada de áudio de modo que uma fonte de tom sinusoidal de 1.000 Hz seja reproduzida a 90 dB de nível de pressão sonora (SPL, na sigla em inglês) (medido
a uma distância deao lado do microfone) produza uma resposta ideal de 1.500 a cada
- DEVE definir a sensibilidade da entrada de áudio de modo que uma fonte de tom sinusoidal de 1.000 Hz seja reproduzida a 90 dB de nível de pressão sonora (SPL, na sigla em inglês) (medido
-
Ver revisão
Se as implementações de dispositivo declararem o recurso
android.hardware.audio.output
, elas:- [C-1-4] PRECISA oferecer suporte a efeitos de áudio com entrada e saída de ponto flutuante.
- [C-1-5] PRECISA garantir que os efeitos de áudio ofereçam suporte a vários canais até a contagem de canais do mixer, também conhecida como FCC_LIMIT.
-
Ver revisão
Se as implementações de dispositivos declararem
android.hardware.audio.output
, elas serão altamente RECOMENDADAS a atender ou exceder os seguintes requisitos:- [C-SR-4] O carimbo de data/hora de saída retornado por AudioTrack.getTimestamp e
AAudioStream_getTimestamp
tem precisão de +/- 1 ms.
- [C-SR-4] As latências de ida e volta calculadas com base nos carimbos de data/hora
de entrada e saída retornados por
AAudioStream_getTimestamp
são RECOMENDADAS que estejam dentro de 30 ms da latência de ida e volta medida paraAAUDIO_PERFORMANCE_MODE_NONE
eAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
para alto-falantes e fones de ouvido com e sem fio.
- [C-SR-4] O carimbo de data/hora de saída retornado por AudioTrack.getTimestamp e
7. Compatibilidade de hardware
-
Ver revisão
O Android inclui instalações que ajustam automaticamente os recursos de aplicativos e os layouts de interface de forma adequada para o dispositivo, a fim de garantir que aplicativos de terceiros sejam executados bem em
várias configurações de hardware.diversas telas e configurações de hardware. Uma tela compatível com o Android é uma tela que implementa todos os comportamentos e APIs descritos em Desenvolvedores Android: visão geral da compatibilidade da tela, nesta seção (7.1) e nas subseções dela, assim como qualquer outro comportamento específico do tipo de dispositivo documentado na seção 2 deste CDD.Nas telas compatíveis com Android em que todos os apps de terceiros compatíveis com Android podem ser executados, as implementações de dispositivos PRECISAM implementar corretamente essas APIs e comportamentos, conforme detalhado nesta seção.Iniciar novos requisitos
Implementações de dispositivos:
- [C-0-1] PRECISA, por padrão, renderizar aplicativos de terceiros apenas em telas compatíveis com o Android.
As unidades referenciadas pelos requisitos nesta seção são definidas da seguinte maneira:
- tamanho diagonal físico. A distância em polegadas entre dois cantos opostos da parte iluminada da tela.
pontos por polegada (dpi)densidade. O número de pixels abrangidos por um período linear horizontal ou vertical de 1 pol., expresso em pixels por polegada (ppi ou dpi). Quando os valores dedpippi e dpi estão listados, os dpi horizontal e vertical precisam estar no intervalo listado.- proporção. A proporção dos pixels da dimensão maior com a menor dimensão da tela. Por exemplo, uma tela de 480 x 854 pixels seria 854/480 = 1,779, ou aproximadamente “16:9”.
- pixel de densidade independente (dp, na sigla em inglês).
Aunidade de pixel virtual A normalizada para umatela de 160 dpidensidade de tela de 160. Para algumas densidades d e um número de pixels p, o número de pixels de densidade independente dp é calculado como:pixels = dps * (densidade/160)dp = (160 / d) * p .
7.1.1.1. Tamanho e formato da tela:
Ver revisão
Se as implementações de dispositivos oferecem suporte a telas com a configuração de tamanho
UI_MODE_TYPE_NORMAL
eincluem compatíveis com o Androidusam telas físicas com cantos arredondados para renderizar essas telas, elas:- [C-1-1] PRECISA garantir que pelo menos um dos requisitos a seguir seja atendido para cada tela:
- O raio dos cantos arredondados será menor ou igual a 38 dp.
Quando uma caixa de 15 dp por 15 dp está ancorada em cada canto da tela lógica, pelo menos um pixel de cada caixa fica visível na tela.
DEVE incluir affordance do usuário para alternar para o modo de exibição com os cantos retangulares.
Iniciar novos requisitos
Se as implementações do dispositivo só puderem fazer a configuração de teclado
NO_KEYS
e pretendem informar suporte à configuração do modo de interfaceUI_MODE_TYPE_NORMAL
, elas:- [C-4-1] PRECISA ter um tamanho de layout de pelo menos 596 dp x 384 dp ou mais, excluindo os cortes de tela.
Se as implementações do dispositivo incluírem telas compatíveis com Android que sejam dobráveis ou uma articulação dobrável entre vários painéis e disponibilizem essas telas para renderizar apps de terceiros, elas:
- [C-2-1] PRECISA implementar a versão estável mais recente disponível da API de extensões ou a versão estável da API secundária para ser usada pela biblioteca do Window Manager Jetpack.
Se as implementações do dispositivo incluírem telas compatíveis com Android dobráveis ou uma articulação dobrável entre vários painéis e se a articulação ou dobra cruzar uma janela do app em tela cheia, elas:
- [C-3-1] PRECISA informar a posição, os limites e o estado da articulação ou dobra pelas extensões ou APIs sidecar para o aplicativo.
Se as implementações de dispositivos incluírem uma ou mais áreas de exibição compatíveis com Android que sejam dobráveis ou se incluírem uma articulação dobrável entre várias áreas de exibição compatíveis com o Android e disponibilizarem essas áreas para aplicativos, elas:
- [C-4-1] PRECISA implementar a versão correta do nível da API Window Manager Extensions, conforme descrito na próxima documentação.
7.1.1.2. Proporção da tela: removida
-
Ver revisão
Implementações de dispositivos:
- [C-0-1]
Por padrão, as implementações do dispositivoPRECISAM informarapenasuma das densidades do framework do Android listadas emDisplayMetrics
pela APIDENSITY_DEVICE_STABLE
. Esse valor precisa ser um valor estático para cada tela físicaNÃO DEVE mudar a qualquer momento. No entanto,a exibição do dispositivo MA/}.DisplayMetrics.density
- As implementações de dispositivos DEVEM definir a densidade padrão do framework do Android que é numericamente mais próxima da densidade física da tela, a menos que essa densidade lógica coloque o tamanho da tela informado abaixo do mínimo compatível. Se a densidade do framework padrão do Android que é numericamente mais próxima da densidade física resultar em um tamanho de tela menor que o menor tamanho de tela compatível com suporte (320 dp de largura), as implementações de dispositivos DEVEM informar a próxima densidade mais baixa de framework padrão do Android.
Iniciar novos requisitos
- DEVE definir a densidade padrão do framework do Android que seja numericamente próxima da densidade física da tela ou um valor que seria mapeado para as mesmas medidas de campo de visão angular equivalentes de um dispositivo portátil.
Se as implementações de dispositivos fornecerem
houveuma funcionalidade para mudar o tamanho da tela do dispositivo, elas:- [C-1-1]
O tamanho da tela NÃO PODE ser dimensionadoNÃO PODE dimensionar a tela mais que 1,5 vezDENSITY_DEVICE_STABLE
densidade nativaou produzir uma dimensão mínima efetiva menor que 320 dp (equivalente ao qualificador de recurso sw320dp), o que ocorrer primeiro. - [C-1-2]
O tamanho da tela NÃO PODE ser dimensionadoNÃO PODE dimensionar a tela menor que 0,85 vezes adensidade nativadaDENSITY_DEVICE_STABLE
.
- [C-0-1]
-
Ver revisão
Se as implementações de dispositivos incluírem suporte ao Vulkan
1.0 ou mais recente, elas:[C-1-3] PRECISA implementar totalmente as APIs
Vulkan 1.0Vulkan 1.1 para cadaVkPhysicalDevice
enumerado.[C-1-5] NÃO É POSSÍVEL enumerar as camadas fornecidas por bibliotecas fora do pacote do aplicativo nem fornecer outras maneiras de rastrear ou interceptar a API Vulkan, a menos que o aplicativo tenha o atributo
android:debuggable
definido comotrue
ou os metadadoscom.android.graphics.injectLayers.enable
definidos comotrue
.
- DEVE oferecer suporte a
VkPhysicalDeviceProtectedMemoryFeatures
eVK_EXT_global_priority
.
- [C-1-13] PRECISA atender aos requisitos especificados pelo perfil de referência do Android 2021.
[C-SR-5] É FORTEMENTE RECOMENDADO para oferecer suporte a
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
eVK_EXT_global_priority
.[C-SR-6] É FORTEMENTE RECOMENDADO usar o
SkiaVk
com HWUI.
Se as implementações de dispositivos incluírem suporte ao Vulkan 1.1 e declararem qualquer uma das flags de recurso do Vulkan descritas aqui , elas:
- [C-SR-7] É FORTEMENTE RECOMENDADO disponibilizar a extensão
VK_KHR_external_fence_fd
para aplicativos de terceiros e permitir que o aplicativo exporte o payload de limite para e importe o payload de limite dos descritores de arquivo POSIX, conforme descrito aqui.
-
Ver revisão
Se as implementações de dispositivos tiverem vários sensores biométricos, elas:
[C-7-1] PRECISA, quando uma biometria está bloqueada (ou seja, a biometria fica desativada até o usuário desbloquear com a autenticação primária) ou um bloqueio com limite de tempo (ou seja, a biometria é desativada temporariamente até o usuário aguardar um intervalo de tempo) devido a muitas tentativas com falha, também bloqueia todas as outras biométricas de uma classe biométrica menor. No caso de bloqueio com limite de tempo, o tempo de espera para a verificação biométrica PRECISA ser o tempo máximo de espera de todas as biometrias no bloqueio com limite de tempo.
[C-SR-12] São RECOMENDADOS FORTEMENTE quando uma biometria está em bloqueio (ou seja, a biométrica fica desativada até que o usuário faça o desbloqueio com autenticação primária) ou bloqueio com limite de tempo (ou seja, a biometria é desativada temporariamente até que o usuário espere um intervalo de tempo) devido a muitas tentativas com falha, para também bloquear todas as outras biometrias da mesma classe. No caso de bloqueio com limite de tempo, o tempo de espera para a verificação biométrica é FORTEMENTE RECOMENDADO para ser o tempo máximo de espera de todas as biometrias no bloqueio com limite de tempo.
[C-7-2] PRECISA contestar o usuário quanto à autenticação principal recomendada (por exemplo, PIN, padrão, senha) para redefinir o contador de bloqueio para uma biometria que está sendo bloqueada. A biometria de Classe 3 PODE ser permitida para redefinir o contador de bloqueio para uma biometria bloqueada da classe igual ou inferior. A biometria de classe 2 ou classe 1 NÃO PODE ser permitida para concluir uma operação de redefinição de bloqueio para qualquer biometria.
Se as implementações de dispositivos quiserem tratar um sensor biométrico como Class 1 (anteriormente Convenience), elas:
[C-1-12] PRECISA ter uma taxa de aceitação de impostor e de impostor não superior a 40% por espécie de instrumento de ataque de apresentação (PAI, na sigla em inglês), conforme medido pelos Protocolos de teste biométricos do Android (link em inglês).
[C-SR-13] É RECOMENDADO que tenha uma taxa de aceitação de spoofing e impostor não superior a 30% por espécie de instrumento de ataque de apresentação (PAI, na sigla em inglês), conforme medido pelos Protocolos de teste de biometria do Android (link em inglês).
[C-SR-14] É FORTEMENTE RECOMENDADO a divulgação da classe biométrica do sensor biométrico e os riscos correspondentes de ativá-lo.
[C-SR-17] É FORTEMENTE RECOMENDADO para implementar as novas interfaces AIDL (como
IFace.aidl
eIFingerprint.aidl
).
Se as implementações de dispositivos quiserem tratar um sensor biométrico como Class 2 (anteriormente fraco), elas:
- [C-SR-15] É RECOMENDADO que tenha uma taxa de aceitação de spoofing e impostor não superior a 20% por espécie de instrumento de ataque de apresentação (PAI, na sigla em inglês), conforme medido pelos Protocolos de teste de biometria do Android (link em inglês).
- [C-2-3] PRECISA realizar 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 uma máquina virtual protegida que atenda aos requisitos da Seção 9.17. - [C-2-4] PRECISA ter todos os dados identificáveis criptografados e autenticados criptograficamente para que não possam ser adquiridos, lidos ou alterados fora do ambiente de execução isolado ou de um chip com um canal seguro para o ambiente de execução isolado, conforme documentado nas diretrizes de implementação no site do Android Open Source Project ou uma máquina virtual protegida controlada por hipervisor que atenda aos requisitos da Seção 9.17.
- [C-2-5] Para biometria baseada em câmera, enquanto a autenticação ou o registro biométrico
estão acontecendo:
- PRECISA operar a câmera de um modo que impeça a leitura ou alteração dos frames fora do ambiente de execução isolado ou de um chip com um canal seguro para o ambiente de execução isolado ou uma máquina virtual protegida controlada por hipervisor que atenda aos requisitos da Seção 9.17.
- Para soluções RGB de câmera única, os frames da câmera PODEM ser legíveis fora do ambiente de execução isolado para oferecer suporte a operações como a visualização para registro, mas NÃO PODEM ser alterados.
- [C-2-7] NÃO PODE permitir acesso não criptografado a dados biométricos identificáveis ou dados derivados deles (como embeddings) para o processador de aplicativos fora do contexto do TEE ou da máquina virtual protegida controlada pelo hipervisor que atende aos requisitos na Seção 9.17. O upgrade de dispositivos lançados com o Android 9 ou versões anteriores não está isento do C-2-7.
Se as implementações de dispositivos quiserem tratar um sensor biométrico como Class 3 (anteriormente Strong), elas:
- [C-SR-16] É RECOMENDADO que você tenha uma taxa de aceitação de spoofing e impostor não superior a 7% por espécie de instrumento de ataque de apresentação (PAI, na sigla em inglês), conforme medido pelos Protocolos de teste de biometria do Android (link em inglês).
7.3.13. IEEE 802.1.15.4 (UWB):
Ver revisão
Se as implementações de dispositivos incluírem suporte para 802.1.15.4 e expõem a funcionalidade a um aplicativo de terceiros, elas:
- [C-1-2] PRECISA informar a flag de recurso de hardware
android.hardware.uwb
. - [C-1-3] PRECISA oferecer suporte a todos os conjuntos de configurações abaixo (combinações
predefinidas de parâmetros da FIRA UCI)
definidos na implementação do AOSP.
CONFIG_ID_1
: alcance deSTATIC STS DS-TWR
unicast definido pela FiRa, modo adiado, intervalo de alcance de 240 ms.CONFIG_ID_2
: alcance deSTATIC STS DS-TWR
de um para muitos definido pela FiRa, modo adiado, intervalo de 200 ms. Caso de uso típico: o smartphone interage com muitos dispositivos inteligentes.CONFIG_ID_3
: igual aCONFIG_ID_1
, exceto que os dados de ângulo de chegada (AoA) não são informados.CONFIG_ID_4
: igual aCONFIG_ID_1
, exceto pelo modo de segurança do P-STS, ativado.CONFIG_ID_5
: igual aCONFIG_ID_2
, exceto pelo modo de segurança do P-STS, ativado.CONFIG_ID_6
: igual aCONFIG_ID_3
, exceto pelo modo de segurança do P-STS, ativado.CONFIG_ID_7
: igual aCONFIG_ID_2
, exceto pelo fato de que o modo de chave de controle individual do P-STS é ativado.
- [C-1-4] PRECISA fornecer uma funcionalidade de usuário para permitir que ele ative/desative o estado de rádio UWB.
- [C-1-5] PRECISA impor que os apps que usam a opção UWB mantenham a permissão
UWB_RANGING
(no grupo de permissõesNEARBY_DEVICES
).
Ser aprovado nos testes de conformidade e certificação relevantes definidos por organizações padrão, incluindo FIRA, CCC e CSA, ajuda a garantir o funcionamento correto do 802.1.15.4.
- [C-1-2] PRECISA informar a flag de recurso de hardware
-
Ver revisão
A "telefonia", conforme usada pelas APIs do Android e neste documento, se refere especificamente ao hardware relacionado à realização de chamadas de voz e ao envio de mensagens SMS ou ao estabelecimento de dados móveis por meio de uma rede móvel (por exemplo, GSM, CDMA, LTE, NR) GSM ou CDMA. Um dispositivo com suporte a "Telefonia" pode oferecer alguns ou todos os serviços de chamadas, mensagens e dados que se adequam ao produto.
via rede GSM ou CDMA. Embora essas chamadas de voz possam ou não ter comutação por pacote,elas são para os fins do Android consideradas independentes de qualquer conectividade de dados que possa ser implementada usando a mesma rede. Em outras palavras,a funcionalidade de “telefonia” do Android e as APIs se referem especificamente a chamadas de voz e SMS. Por exemplo, implementações de dispositivos que não podem fazer chamadas ou enviar/receber mensagens SMS não são consideradas dispositivos de telefonia, mesmo que usem uma rede celular para conectividade de dados. -
Ver revisão
Se as implementações de dispositivos incluírem suporte para o 802.11 e exporem a funcionalidade a um aplicativo de terceiros, elas:
- [C-1-4] PRECISA oferecer suporte ao multicast DNS (mDNS, na sigla em inglês) e NÃO PODE 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 seja necessário descartar ou filtrar esses pacotes para permanecer dentro dos intervalos de consumo de energia exigidos pelos requisitos regulatórios aplicáveis ao mercado de destino.
Para implementações de dispositivos Android Television, mesmo nos estados de energia em espera.
- [C-1-4] PRECISA oferecer suporte ao multicast DNS (mDNS, na sigla em inglês) e NÃO PODE 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 seja necessário descartar ou filtrar esses pacotes para permanecer dentro dos intervalos de consumo de energia exigidos pelos requisitos regulatórios aplicáveis ao mercado de destino.
-
Ver revisão
Se as implementações de dispositivos declararem FEATURE_BLUETOOTH_LE, elas:
- [C-SR-2] É MUITO RECOMENDADO para medir e compensar o deslocamento Rx para
garantir que o RSSI médio do BLE seja de -60 dBm +/-10 dB a 1 m de distância de um
dispositivo de referência transmitindo em
ADVERTISE_TX_POWER_HIGH
, em que os dispositivos são orientados de forma que estejam em "planos paralelos" com telas voltadas para a mesma direção. - [C-SR-3] É MUITO RECOMENDADO para medir e compensar o deslocamento Tx para
garantir que o RSSI médio do BLE seja -60 dBm +/-10 dB ao ler a partir de um dispositivo
de referência posicionado a 1 m de distância e transmitindo em
ADVERTISE_TX_POWER_HIGH
, em que os dispositivos estão orientados de tal forma que estejam em "planos paralelos" com telas voltadas para a mesma direção.
- [C-10-3] PRECISA medir e compensar o deslocamento Rx para
garantir que o RSSI médio do BLE seja -55 dBm +/-10 dB a 1 m de distância de um
dispositivo de referência transmitindo em
ADVERTISE_TX_POWER_HIGH
. - [C-10-4] PRECISA medir e compensar o deslocamento Tx para
garantir que o RSSI médio do BLE seja -55 dBm +/-10 dB ao ler a partir de um dispositivo
de referência posicionado a 1 m de distância e transmitindo em
ADVERTISE_TX_POWER_HIGH
.
Se as implementações de dispositivos forem compatíveis com o Bluetooth versão 5.0, elas:
- [C-SR-4] É FORTEMENTE RECOMENDADO oferecer suporte para:
- LE 2M PHY
- Codec LE PHY
- Extensão de publicidade LE
- Publicidade periódica
- Pelo menos 10 conjuntos de anúncios
- Pelo menos oito conexões simultâneas do LE. Cada conexão pode estar em qualquer um dos papéis de topologia de conexão.
- Privacidade da camada de links do LE
- Um tamanho de "lista de resoluções" de pelo menos oito entradas
- [C-SR-2] É MUITO RECOMENDADO para medir e compensar o deslocamento Rx para
garantir que o RSSI médio do BLE seja de -60 dBm +/-10 dB a 1 m de distância de um
dispositivo de referência transmitindo em
-
Ver revisão
- [C-1-7] PRECISA garantir que a média das medidas de distância a 1 m do dispositivo de referência esteja dentro de [0,75 m, 1,25 m], em que a distância das informações empíricas é medida a partir da borda superior do DUT.
Segure a face para cima e inclinada 45 graus.
- [C-1-7] PRECISA garantir que a média das medidas de distância a 1 m do dispositivo de referência esteja dentro de [0,75 m, 1,25 m], em que a distância das informações empíricas é medida a partir da borda superior do DUT.
-
Ver revisão
Uma câmera traseira é uma câmera localizada na lateral do dispositivo oposta à tela. Ou seja, ela captura cenas no outro lado do dispositivo, como uma câmera tradicional.
Uma câmera traseira é uma câmera voltada para o mundo que captura cenas no lado oposto do dispositivo, como uma câmera tradicional. Em dispositivos portáteis, é uma câmera localizada na lateral do dispositivo em frente à tela.
-
Ver 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 imagens do usuário, por exemplo, para videoconferências e aplicativos semelhantes.
Uma câmera frontal é uma câmera voltada ao usuário que normalmente é usada para capturar a imagem do usuário, por exemplo, para videoconferência e aplicativos semelhantes. Em dispositivos portáteis, é uma câmera localizada no mesmo lado do dispositivo que a tela.
-
Ver revisão
Uma câmera externa pode ser conectada ou removida fisicamente da implementação do dispositivo a qualquer momento e pode estar voltada para qualquer direção, como câmeras USB.
7.5.4. Comportamento da API Camera:
Ver revisão
As implementações de dispositivos PRECISAM implementar os seguintes comportamentos para as APIs relacionadas à câmera em todas as câmeras disponíveis. Implementações de dispositivos:
- [C-SR-1] Para dispositivos com várias câmeras RGB próximas
e voltadas para a mesma direção,
é RECOMENDADO oferecer suporte a um dispositivo de câmera lógico que liste
a capacidade
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
, que consiste em todas as câmeras RGB voltadas para essa direção como subdispositivos físicos.
- [C-SR-1] Para dispositivos com várias câmeras RGB próximas
e voltadas para a mesma direção,
é RECOMENDADO oferecer suporte a um dispositivo de câmera lógico que liste
a capacidade
-
Ver revisão
Os dispositivos que atenderem a todos os critérios a seguir estão isentos do requisito acima:
- Implementações de dispositivos que não podem ser giradas pelo usuário, como dispositivos automotivos.
-
Ver revisão
Os dispositivos destinados à mão ou no uso podem incluir um atuador tátil de uso geral, disponível para aplicativos com finalidades que incluem a chamada de atenção por toques, alarmes, notificações e feedback geral de toque.
Se as implementações do dispositivo NÃO incluírem esse atuador tátil de uso geral, elas:
- [7.10/C] PRECISA retornar "false" para
Vibrator.hasVibrator()
.
Se as implementações de dispositivos incluírem pelo menos um desses atuadores táteis de uso geral, elas:
- [C-1-1] PRECISA retornar "true" para
Vibrator.hasVibrator()
. - NÃO DEVE usar um atuador tátil (vibrador) de massa giratória excêntrica (ERM).
- DEVE implementar todas as constantes públicas para retorno tátil
em
android.view.HapticFeedbackConstants
, ou seja, (CLOCK_TICK
,CONTEXT_CLICK
,KEYBOARD_PRESS
,KEYBOARD_RELEASE
,KEYBOARD_TAP
,LONG_PRESS
,TEXT_HANDLE_MOVE
,VIRTUAL_KEY
,VIRTUAL_KEY_RELEASE
,CONFIRM
,REJECT
,GESTURE_START
eGESTURE_END
). - DEVE
android.os.VibrationEffect
EFFECT_TICK
EFFECT_CLICK
EFFECT_HEAVY_CLICK
EFFECT_DOUBLE_CLICK
PRIMITIVE_*
android.os.VibrationEffect.Composition
CLICK
TICK
LOW_TICK
LOW_TICK
QUICK_FALL
QUICK_RISE
SLOW_RISE
SPIN
SPIN
THUD
- DEVE seguir as orientações de mapeamento de constantes públicas
em
android.view.HapticFeedbackConstants
para as constantesandroid.os.VibrationEffect
recomendadas, com as relações de amplitude correspondentes. - DEVE usar estes mapeamentos de constantes táteis vinculados.
- DEVE seguir a avaliação de qualidade
para APIs
createOneShot()
ecreateWaveform()
. - DEVE verificar se o resultado da API pública
android.os.Vibrator.hasAmplitudeControl()
reflete corretamente os recursos da vibração. - DEVE verificar os recursos de escalonabilidade de amplitude executando
android.os.Vibrator.hasAmplitudeControl()
.
Se as implementações de dispositivos seguirem o mapeamento de constantes táteis, elas:
- O QUE PRECISA verificar o status da implementação executando as APIs
android.os.Vibrator.areAllEffectsSupported()
eandroid.os.Vibrator.arePrimitivesSupported()
. - Realize uma avaliação de qualidade para constantes de retorno tátil.
- DEVE verificar e atualizar, se necessário, a configuração substituta para primitivos sem suporte, conforme descrito na orientação de implementação para constantes.
- DEVE fornecer suporte substituto para reduzir o risco de falha, conforme descrito aqui.
Consulte a Seção 2.2.1 para ver os requisitos específicos dos dispositivos.
- [7.10/C] PRECISA retornar "false" para
9. Compatibilidade do modelo de segurança
-
Ver revisão
Implementações de dispositivos:
- [C-0-4] PRECISA ter apenas uma implementação das duas interfaces do usuário.
Se as implementações do dispositivo pré-instalarem qualquer pacote que tenha qualquer um dos papéis System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence ou System Visual Intelligence, os pacotes:
- [C-4-1] PRECISA atender a todos os requisitos descritos para implementações de dispositivos nas
seções
"9.8.6 Captura de conteúdo""9.8.6 Dados do SO e do ambiente e 9.8.15 Implementações de API no modo sandbox".
- [C-4-2] NÃO PODE ter a permissão android.permission.INTERNET. Isso é mais estrito do que o FORTEMENTE RECOMENDADO listado na seção 9.8.6.
- [C-4-3] NÃO PODE SER vinculado a outros apps, exceto aos seguintes apps do sistema: Bluetooth, Contatos, Mídia, Telefonia, SystemUI e componentes que fornecem APIs da Internet. Isso é mais rigoroso do que o RECOMENDADO FORTEMENTE listado na seção 9.8.6.
Se as implementações de dispositivos incluírem um aplicativo padrão para oferecer suporte ao
VoiceInteractionService
:- [C-5-1] NÃO PODE conceder
ACCESS_FINE_LOCATION
como padrão para esse aplicativo.
-
Ver revisão
Se as implementações de dispositivos criarem o perfil de usuário adicional discutido acima, elas:
- [C-4-5] PRECISA distinguir visualmente os ícones de aplicativo de instância dupla quando os ícones são apresentados aos usuários.
- [C-4-6] PRECISA fornecer uma disponibilidade do usuário para excluir todos os dados do perfil do clone.
- [C-4-7] PRECISA desinstalar todos os apps, excluir os diretórios de dados particulares e o conteúdo deles e, quando o usuário optar por excluir todos os dados do perfil.
- DEVE solicitar que o usuário exclua todos os dados do perfil de clone quando o último app clone for excluído.
- [C-4-8] PRECISA informar ao usuário que os dados do app serão excluídos quando o aplicativo clonado for desinstalado ou oferecer uma opção para os usuários manterem os dados quando o app for desinstalado do dispositivo.
- [C-4-9] PRECISA excluir os diretórios de dados particulares do app e o conteúdo deles, quando o usuário optar por excluir os dados durante a desinstalação.
[C-4-1] PRECISA permitir que as intents abaixo originadas do perfil extra sejam processadas pelos aplicativos do usuário principal no dispositivo:
Intent.ACTION_VIEW
Intent.ACTION_SENDTO
Intent.ACTION_SEND
Intent.ACTION_EDIT
Intent.ACTION_INSERT
Intent.ACTION_INSERT_OR_EDIT
Intent.ACTION_SEND_MULTIPLE
Intent.ACTION_PICK
Intent.ACTION_GET_CONTENT
MediaStore.ACTION_IMAGE_CAPTURE
MediaStore.ACTION_VIDEO_CAPTURE
[C-4-2] PRECISA herdar todas as restrições de usuário da política do dispositivo e restrições não relacionadas a usuários selecionadas(listadas abaixo) aplicadas ao usuário principal do dispositivo para esse perfil de usuário extra.
[C-4-3] PRECISA permitir apenas a gravação de contatos desse perfil extra pelas seguintes intents:
[C-4-4] NÃO PODE ter sincronizações de contatos em execução para aplicativos em execução nesse perfil de usuário extra.
- [C-4-14] PRECISA ter permissões e gerenciamento de armazenamento separados para os aplicativos em execução nesse perfil extra.
- [C-4-5] PRECISA permitir que apenas aplicativos do perfil extra que tenham uma atividade de tela de início acessem contatos já acessíveis ao perfil de usuário pai.
-
Ver revisão
Uma tecnologia de segurança de memória é uma tecnologia que mitiga pelo menos as seguintes classes de bugs com uma probabilidade alta (> 90%) em aplicativos que usam a opção de manifesto
android:memtagMode
:- estouro do buffer de heap
- usar após a gratuidade
- Dupla sem custo financeiro
- Wild free (sem um ponteiro não Malloc)
Implementações de dispositivos:
- [C-SR-15] É FORTEMENTE RECOMENDADO para definir
ro.arm64.memtag.bootctl_supported
.
Se as implementações de dispositivos definirem a propriedade do sistema
ro.arm64.memtag.bootctl_supported
como "true", elas:[C-3-1] PRECISA permitir que a propriedade do sistema
arm64.memtag.bootctl
aceite uma lista separada por vírgulas dos valores abaixo, com o efeito desejado aplicado na próxima reinicialização:memtag
: uma tecnologia de segurança de memória, conforme definido acima, está ativadamemtag-once
: uma tecnologia de segurança de memória, conforme definido acima, é ativada temporariamente e desativada automaticamente na próxima reinicialização.memtag-off
: uma tecnologia de segurança de memória, conforme definido acima, está desativada.
[C-3-2] PRECISA permitir que o usuário do shell defina
arm64.memtag.bootctl
.[C-3-3] PRECISA permitir que qualquer processo leia
arm64.memtag.bootctl
.[C-3-4] PRECISA definir
arm64.memtag.bootctl
como o estado solicitado na inicialização. Ele também PRECISA atualizar a propriedade se a implementação do dispositivo permitir modificar o estado sem mudar a propriedade do sistema.[C-SR-16] É RECOMENDADO para mostrar uma configuração do desenvolvedor que define a memória uma vez e reinicia o dispositivo. Com um carregador de inicialização compatível, o Android Open Source Project atende aos requisitos acima usando o protocolo do carregador de inicialização da MTE.
- [C-SR-17] É RECOMENDADO para mostrar uma configuração no menu
"Configurações de segurança" que permite ao usuário ativar
memtag
.
-
Ver revisão
Implementações de dispositivos:
- [C-0-2] PRECISA mostrar um aviso do usuário
e receber o consentimento explícito dele, permitindo que todas
as informações sensíveis mostradas na tela do usuário sejam
capturadas
ativadas que incluam exatamente a mesma mensagem do AOSPsemprecada vez que uma sessão para capturar a telaa transmissão ou a gravação de telacom as APIsforprópria,1} 1.MediaProjection.createVirtualDisplay()
VirtualDeviceManager.createVirtualDisplay()
NÃO PODE oferecer aos usuários a possibilidade de desativar a exibição futura do consentimento do usuário.
[C-SR-1] É RECOMENDADO para mostrar um aviso do usuário exatamente a mesma mensagem implementada no AOSP, mas PODE ser modificado, desde que a mensagem avise claramente ao usuário que informações sensíveis na tela dele foram capturadas.
[C-0-4] NÃO PODE fornecer aos usuários uma affordance para desativar futuras solicitações do consentimento do usuário para capturar a tela, a menos que a sessão seja iniciada por um app do sistema que o usuário tenha autorizado a
associate()
com o perfil do dispositivoandroid.app.role.COMPANION_DEVICE_APP_STREAMING
ouandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING
.
- [C-0-2] PRECISA mostrar um aviso do usuário
e receber o consentimento explícito dele, permitindo que todas
as informações sensíveis mostradas na tela do usuário sejam
capturadas
9.8.6. Dados do SO e do ambiente: esta seção foi renomeada de Captura de conteúdo e pesquisa de apps para Dados ambientes e no nível do SO.
Ver revisão
O Android, com as APIs do sistema
, oferece suporte a um mecanismo para implementações de dispositivos que capturam as seguintesContentCaptureService
,AugmentedAutofillService
,AppSearchGlobalManager.query
ou outros meios proprietáriosinterações de dados entre os aplicativos e o usuáriodados sensíveis:- Qualquer tela ou outros dados enviados pelo
AugmentedAutofillService
ao sistema. - Qualquer tela ou outros dados acessíveis pela
API
Content Capture
. - Qualquer tela ou outros dados acessíveis pela API
FieldClassificationService
- Todos os dados do aplicativo transmitidos ao sistema pela API
AppSearchManager
e acessíveis porAppSearchGlobalManager.query
.
- Quaisquer outros eventos que um aplicativo fornece ao sistema pela API
Content Capture
ou pela APIAppSearchManager
, uma API Android e proprietária semelhante.
- Dados de áudio recebidos como resultado do uso de
SpeechRecognizer#onDeviceSpeechRecognizer()
pela implementação do reconhecedor de fala. - Dados de áudio recebidos em segundo plano (continuamente) por
AudioRecord
,SoundTrigger
ou outras APIs de áudio que não resultam em um indicador visível para o usuário - Dados da câmera recebidos em segundo plano (continuamente) pelo CameraManager ou outras APIs da câmera e que não resultam em um indicador visível para o usuário
Se as implementações de dispositivo capturarem qualquer um dos dados acima, elas:
[C-1-3] PRECISA enviar somente todos esses dados
e o registrodo dispositivo usando um mecanismo que preserva a privacidade, exceto com o consentimento explícito do usuário toda vez que os dados forem compartilhados. O mecanismo de preservação de privacidade é definido como "aqueles que permitem apenas análises agregadas e impedem a correspondência de eventos registrados ou resultados derivados a usuários individuais" para evitar que qualquer dado por usuário seja introspectivo (por exemplo, implementado usando uma tecnologia de privacidade diferencial, comoRAPPOR
).[C-1-5] NÃO PODE compartilhar esses dados com outros componentes do SO que não seguem os requisitos descritos na seção atual (9.8.6
Captura de conteúdoDados do ambiente e do SO), exceto com consentimento explícito do usuário sempre que eles são compartilhados. A menos que essa funcionalidade seja criada como uma API do SDK do Android (AmbientContext
,HotwordDetectionService
).[C-1-6] PRECISA fornecer recursos ao usuário para apagar os dados que a implementação
ou o método proprietário coletaContentCaptureService
sequando os dados forem armazenados de qualquer forma no dispositivo. Se o usuário optar por apagar os dados, PRECISA remover todos os dados históricos coletados.
- [C-SR-3] É RECOMENDADO que ela seja implementada com a API Android SDK ou um repositório de código aberto semelhante de propriedade do OEM e / ou seja realizada em uma implementação no modo sandbox (consulte 9.8.15 Implementações da API no modo sandbox).
O Android, por meio de
SpeechRecognizer#onDeviceSpeechRecognizer()
, oferece a capacidade de realizar reconhecimento de fala no dispositivo, sem envolver a rede. Qualquer implementação do SpeechReconhecedor no dispositivo PRECISA seguir as políticas descritas nesta seção.- Qualquer tela ou outros dados enviados pelo
9.8.10. Relatório de bugs de conectividade:
Ver revisão
Se as implementações de dispositivo declararem a flag de recurso
android.hardware.telephony
, elas:- [C-1-4] Os relatórios gerados com
BUGREPORT_MODE_TELEPHONY
PRECISAM conter pelo menos as seguintes informações:- Despejo
SubscriptionManagerService
- Despejo
- [C-1-4] Os relatórios gerados com
9.8.14. Gerenciador de credenciais: removido
9.8.15. Implementações da API no modo sandbox: nova seção
Ver revisão
O Android, com um conjunto de APIs delegadas, oferece um mecanismo para processar dados seguros do SO e do ambiente. Esse processamento pode ser delegado a um APK pré-instalado com acesso privilegiado e recursos de comunicação reduzidos, conhecido como implementação de API no modo sandbox.
Qualquer implementação de API no modo sandbox:
- [C-0-1] NÃO PODE solicitar a permissão INTERNET.
- [C-0-2] PRECISA acessar a Internet apenas por APIs estruturadas com suporte de implementações de código aberto disponíveis publicamente usando mecanismos que preservam a privacidade ou indiretamente usando APIs do SDK do Android. O mecanismo de preservação de privacidade é definido como "aqueles que permitem apenas análises agregadas e impedem a correspondência de eventos registrados ou resultados derivados a usuários individuais", para evitar que qualquer dado por usuário seja introspectivo (por exemplo, implementado usando uma tecnologia de privacidade diferencial, como RAPPOR).
- [C-0-3] PRECISA manter os serviços separados de outros componentes do sistema
(por exemplo, não vincular os IDs dos processos de compartilhamento ou serviço), exceto pelo
seguinte:
- Telefonia, Contatos, interface do sistema e mídia
- [C-0-4] NÃO PODE permitir que os usuários substituam os serviços por um aplicativo ou serviço instalável pelo usuário
- [C-0-5] PRECISA permitir que apenas os serviços pré-instalados capturem esses dados. A menos que o recurso de substituição esteja integrado ao AOSP (por exemplo, para apps de assistente digital).
- [C-0-6] NÃO PODE permitir que outros apps além do mecanismo de serviços pré-instalados capturem esses dados. A menos que esse recurso de captura seja implementado com uma API do SDK do Android.
- [C-0-7] PRECISA fornecer recursos do usuário para desativar os serviços.
- [C-0-8] NÃO É POSSÍVEL omitir a funcionalidade do usuário para gerenciar as permissões do Android retidas pelos serviços e seguir o modelo de permissões do Android, conforme descrito na Seção 9.1. Permissão.
9.8.16. Áudio contínuo e dados da câmera: nova seção
Ver revisão
Além dos requisitos descritos em 9.8.2, Gravação, 9.8.6, dados no nível do SO e
- [C-0-1] PRECISA 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 no modo sandbox (consulte 9.8.15 Implementação da API no modo sandbox), por meio de um pacote com um ou mais dos seguintes papéis: System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Audio Intelligence, System Text Intelligence ou System Visual Intelligence.
- O acesso é realizado por um sandbox, implementado e
aplicado por mecanismos no AOSP (
HotwordDetectionService
,WearableSensingService
,VisualQueryDetector
). - O acesso ao áudio é realizado para fins de assistência pelo aplicativo
Assistente Digital, fornecendo
SOURCE_HOTWORD
como uma fonte de áudio. - O acesso é realizado pelo sistema e implementado com código aberto.
- [C-SR-1] É FORTEMENTE RECOMENDADO exigir o consentimento do usuário para todas as funcionalidades que usam esses dados e ser desativado por padrão.
- [C-SR-2] RECOMENDADO fortemente para aplicar o mesmo tratamento (ou seja, seguir as restrições descritas em 9.8.2 Gravação, 9.8.6 no nível do SO e dados do ambiente, 9.8.15 Implementações da API no modo sandbox e 9.8.16 Áudio e dados contínuos da câmera) aos dados da câmera provenientes de um dispositivo wearable remoto.
Se os dados da câmera forem fornecidos por um dispositivo wearable remoto e acessados de forma não criptografada fora do SO Android, uma implementação em sandbox ou uma funcionalidade em sandbox criada pelo
WearableSensingManager
, eles:- [C-1-1] PRECISA indicar ao dispositivo wearable remoto que exibir um outro indicador nele.
Se os dispositivos oferecerem recursos para interagir com um aplicativo de assistente digital sem a palavra-chave atribuída (processando consultas genéricas do usuário ou analisando a presença do usuário pela câmera):
- [C-2-1] PRECISA garantir que essa implementação seja fornecida por um pacote com o
papel
android.app.role.ASSISTANT
. - [C-2-2] PRECISA garantir que essa implementação use as APIs
HotwordDetectionService
e/ouVisualQueryDetectionService
do Android.
- [C-0-1] PRECISA aplicar um indicador correspondente (câmera e/ou microfone, conforme
a seção 9.8.2, Gravação), a menos que:
9.8.17. Telemetria: nova seção
Ver revisão
O Android armazena registros do sistema e do app usando as APIs StatsLog. Esses registros são gerenciados pelas APIs do StatsManager, que podem ser usadas por aplicativos do sistema com privilégios.
O StatsManager também oferece uma maneira de coletar dados categorizados como confidenciais de dispositivos com um mecanismo de preservação de privacidade. Em particular, a API
StatsManager::query
permite consultar categorias de métricas restritas definidas no StatsLog.Qualquer consulta de implementação e coleta de métricas restritas do StatsManager:
- [C-0-1] PRECISA ser o único aplicativo/implementação no dispositivo e ter
a permissão
READ_RESTRICTED_STATS
. - [C-0-2] PRECISA enviar apenas dados de telemetria e o registro do dispositivo usando um mecanismo de preservação de privacidade. O mecanismo de preservação de privacidade é definido como "aqueles que permitem apenas análises agregadas e impedem a correspondência de eventos registrados ou resultados derivados a usuários individuais", para evitar que qualquer dado do usuário seja introspectivo (por exemplo, implementado usando uma tecnologia de privacidade diferencial, como RAPPOR).
- [C-0-3] NÃO PODE associar esses dados a nenhuma identidade do usuário (como Conta) no dispositivo.
- [C-0-4] NÃO PODE compartilhar esses dados com outros componentes do SO que não seguem os requisitos descritos na seção atual (9.8.17 Telemetria que preserva a privacidade).
- [C-0-5] PRECISA fornecer recursos do usuário para ativar/desativar a coleta, o uso e o compartilhamento de telemetria com preservação da privacidade.
- [C-0-6] PRECISA fornecer recursos do usuário para apagar os dados que a implementação coleta, se eles estiverem armazenados de qualquer forma no dispositivo. Se o usuário tiver optado por apagar os dados, PRECISA remover todos os dados atualmente armazenados no dispositivo.
- [C-0-7] PRECISA divulgar a implementação do protocolo de preservação de privacidade em um repositório de código aberto.
- [C-0-8 ]PRECISA aplicar políticas de saída de dados nesta seção para bloquear a coleta de dados nas categorias de métricas restritas definidas no StatsLog.
- [C-0-1] PRECISA ser o único aplicativo/implementação no dispositivo e ter
a permissão
9.10. Integridade do dispositivo:
Ver revisão
Implementações de dispositivosSe as implementações de dispositivos puderem verificar o conteúdo do arquivo por página, elas:
[
C-0-3C-2-1] é compatível com a verificação criptográfica do conteúdo do arquivoem relação a uma chave confiávelsem ler o arquivo inteiro.[
C-0-4C-2-2] NÃO PODE permitir que as solicitações de leitura em um arquivo protegido sejam bem-sucedidas quando o conteúdo de leituranão for verificado com base em uma chave confiávelnão for verificado de acordo com [C-2-1] acima.
- [C-2-4] PRECISA retornar a soma de verificação do arquivo em O(1) para arquivos ativados.
-
Ver revisão
O sistema Android Keystore permite que os desenvolvedores de apps armazenem chaves criptográficas em um contêiner e as usem em operações criptográficas com a API KeyChain ou a API Keystore. Implementações de dispositivos:
- [C-0-3] PRECISA limitar o número de tentativas de autenticação primária com falha.
- [C-SR-2] É FORTEMENTE RECOMENDADO implementar um limite superior de 20 tentativas de autenticação primária com falha e, se os usuários consentirem e ativarem o recurso, realizar uma "redefinição para configuração original" depois de exceder o limite de tentativas de autenticação primária com falha.
Se as implementações do dispositivo adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio se estiverem baseados em um secret conhecido e usarem um novo método de autenticação a ser tratado como uma maneira segura de bloquear a tela:
- [C-SR-3] É RECOMENDADO que um PIN tenha pelo menos seis dígitos ou uma entropia de 20 bits.
- [C-2-1] Um PIN com menos de seis dígitos NÃO pode permitir a entrada automática sem interação do usuário para evitar revelar o tamanho dele.
9.11.1. Tela de bloqueio segura, autenticação e dispositivos virtuais:
Ver revisão
Implementações de dispositivos:
- [C-0-1] PRECISA limitar o número de tentativas de autenticação primária com falha.
- [C-SR-5] É FORTEMENTE RECOMENDADO implementar um limite superior de 20 tentativas de autenticação primária com falha e, se os usuários consentirem e ativarem o recurso, realizar uma "redefinição para configuração original" depois de exceder o limite de tentativas de autenticação principais com falha.
Se as implementações de dispositivos definirem um PIN numérico como o método de autenticação principal recomendado:
- [C-SR-6] É RECOMENDADO que um PIN tenha pelo menos seis dígitos ou uma entropia de 20 bits.
- [C-SR-7] Um PIN com menos de seis dígitos é FORTEMENTE RECOMENDADO para NÃO permitir a entrada automática sem interação do usuário para evitar revelar o tamanho do PIN.
Se as implementações do dispositivo tiverem uma tela de bloqueio segura e incluírem um ou mais agentes de confiança que implementam a API
TrustAgentService
do sistema, elas:[C-7-8] O usuário PRECISA ser contestado a um dos métodos principais de autenticação recomendados (por exemplo, PIN, padrão ou senha) pelo menos uma vez a cada 72 horas ou menos, a menos que a segurança do usuário (por exemplo, distração do motorista) seja preocupante.Se as implementações de dispositivos permitirem que os aplicativos criem telas virtuais secundárias e ofereçam suporte a eventos de entrada associados, como via VirtualDeviceManager, e as telas não estiverem marcadas com VIRTUAL_DISPLAY_FLAG_SECURE, elas:
[C-13-10] PRECISA desativar a instalação de apps iniciados em dispositivos virtuais.9.17. Framework de virtualização do Android:
Ver revisão
Se o dispositivo implementar suporte para as APIs do Framework de virtualização do Android (
android.system.virtualmachine.*
), o host do Android:- [C-1-1] PRECISA oferecer suporte a todas as APIs definidas pelo pacote
android.system.virtualmachine
. - [C-1-2] NÃO É POSSÍVEL modificar o SELinux do Android e o modelo de permissão para o gerenciamento de máquinas virtuais protegidas (pVM).
- [C-1-3] NÃO PODE modificar, omitir ou substituir as regras de nunca permitir presentes no sistema/sepolicy fornecidas no Android Open Source Project (AOSP) upstream, e a política PRECISA ser compilada com todas as regras Nunca permitir presentes.
- [C-1-4] SÓ É NECESSÁRIO permitir código assinado pela plataforma e
apps privilegiados
NÃO É POSSÍVEL permitir que códigos não confiáveis (por exemplo, apps de terceiros)criem e executem umamáquina virtual protegidapVM . Observação: isso pode mudar em versões futuras do Android.
- [C-1-5] NÃO PODE permitir que uma pVM
protegidaexecute um código que não faça parte da imagem de fábrica ou das atualizações dela.Nem tudo o que não estiver coberto pela Inicialização verificada do Android (por exemplo, arquivos transferidos da Internet ou transferidos por sideload) NÃO PODE ser executado em uma máquina virtual protegida.
- [C-1-5] PRECISA permitir que uma pVM não depurável execute código da imagem de fábrica ou das atualizações da plataforma, o que também inclui atualizações de apps privilegiados.
Se o dispositivo implementar suporte para as APIs do framework de virtualização do Android (
android.system.virtualmachine.*
), qualquer instância deProtected Virtual MachinepVM :- [C-2-1] PRECISA executar todos os sistemas operacionais disponíveis no
APEX de virtualização em uma
máquina virtual protegidapVM . - [C-2-2] NÃO PODE permitir que uma
máquina virtual protegidapVM execute um sistema operacional que não esteja assinado pelo implementador do dispositivo ou pelo fornecedor do SO. - [C-2-3] NÃO PODE permitir que uma pVM
protegidaexecute dados como código (por exemplo, SELinux nunca permitir execmem).
- [C-2-4] NÃO PODE modificar, omitir ou substituir as regras de nunca permitir presentes no system/sepolicy/microdroid fornecidos no Android Open Source Project (AOSP).
- [C-2-5] PRECISA implementar mecanismos de defesa profunda de
máquina virtual protegidapVM (por exemplo, SELinux para pVMs), mesmo para sistemas operacionais não Microdroid. - [C-2-6] PRECISA garantir a inicialização da pVM
o firmware recusasenão for possível verificar as imagensiniciais que a VM será executada. A verificação PRECISA ser feita dentro da VM. - [C-2-7] PRECISA garantir que a pVM falhe
o firmware não será inicializadose a integridade da instance.img for comprometida.
Se o dispositivo implementar suporte para as APIs do Framework de virtualização do Android (
android.system.virtualmachine.*
), o hipervisor:- [C-3-1] PRECISA garantir que as páginas de memória de propriedade exclusiva de uma VM (pVM ou VM host) sejam acessíveis apenas pela própria máquina virtual ou pelo hipervisor, não por outras máquinas virtuais, protegidas ou não.
NÃO É POSSÍVEL permitir que uma pVM tenha acesso a uma página que pertence a outra entidade (ou seja, outra pVM ou hipervisor), a menos que seja explicitamente compartilhada pelo proprietário da página. Isso inclui a VM do host. Isso se aplica aos acessos de CPU e DMA. - [C-3-2] PRECISA excluir permanentemente uma página depois que ela for usada por uma pVM e antes de ser retornada ao host (por exemplo, a pVM será destruída).
- [C-
3-3SR-1] É FORTEMENTE RECOMENDADO para garantir quePRECISA garantirque o firmware da pVM seja carregado e executado antes de qualquer código em uma pVM. - [C-3-4] PRECISA garantir que cada VM gere uma chave secreta por VM, que a
{cadeia de certificados de inicialização (BCC) e o identificador de dispositivo composto (CDIs) fornecidos a uma instância de pVMsó pode ser derivada por essa instância de VM específica e alterada após a redefinição para a configuração original e o OTA.
Se o dispositivo implementar suporte para as APIs do framework de virtualização do Android, em todas as áreas:
- [C-4-1] NÃO PODE fornecer funcionalidade a uma pVM que permita ignorar o modelo de segurança do Android.
Se o dispositivo implementar suporte para as APIs do Framework de virtualização do Android:
- [C-5-1] PRECISA oferecer suporte à compilação isolada, mas pode desativar esse recurso no envio de dispositivos
de uma atualização de tempo de execução de ART.
Se o dispositivo implementar suporte para as APIs do framework de virtualização do Android, para o gerenciamento de chaves:
- [C-6-1] PRECISA acessar a cadeia do DICE em um ponto que o usuário não possa modificar, mesmo em dispositivos desbloqueados. Para garantir que não seja falsificado.
- [C-SR-2
6-2] É altamente RECOMENDADO usar o DICE como o mecanismo de derivação de secrets por VM.O DICE precisa ser usado corretamente, ou seja, fornecer os valores corretos.
- [C-1-1] PRECISA oferecer suporte a todas as APIs definidas pelo pacote