Registro de alterações no Documento de definição de compatibilidade do Android

Android 14

26 de junho de 2024

2. tipos de dispositivos

  • 2.2.1. Hardware:

    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:

  • 2.4.1. Hardware:

    Ver revisão

    Iniciar novos requisitos

    Se as implementações de dispositivos Watch incluírem suporte ao Vulkan, elas vão:

  • 2.5.1. Hardware:

    Ver revisão

    Iniciar novos requisitos

    Se as implementações de dispositivos automotivos incluírem suporte ao Vulkan, elas:

3. software

  • 3.2.2. Parâmetros de build:

    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

9. Compatibilidade do modelo de segurança

  • 9.7. Recurso 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 ou EFI_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 e CONFIG_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 ou CONFIG_INIT_STACK_ALL_ZERO). Além disso, as implementações de dispositivos NÃO DEVEM presumir o valor usado pelo compilador para inicializar os locais.

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

  • 9.11. Chaves e credenciais:

    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.

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

8 de abril de 2024

2. tipos de dispositivos

  • 2.2.1. Hardware:

    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.

  • 2.2.5. Modelo de segurança:

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

  • 2.2.7.2. Câmera:

    Ver revisão

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

    • [7.5/H-1-3] PRECISA oferecer suporte à propriedade android.info.supportedHardwareLevel como FULL ou melhor para a câmera principal traseira e LIMITED ou melhor para a câmera principal frontal.

  • 2.3.2. Multimídia:

    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.

3. software

5. Compatibilidade multimídia

  • 5.3.8. Dolby Vision:

    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 por 1518 dp está ancorada em cada canto da tela lógica, pelo menos um pixel de cada caixa fica visível na tela.

  • 7.4.3. Bluetooth:

    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

  • 2.2.1. Hardware:

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

  • 2.2.7.2. Câmera:

    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.

  • 2.3.2. Multimídia:

    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.

  • 2.4.5. Modelo de segurança:

    Ver revisão

    • [9/W-0-1] PRECISA declarar a android.hardware.security.model.compatible feature.

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

9. Compatibilidade do modelo de segurança

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

  • 2.2.1. Hardware:

    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 e android.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:

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

  • 2.2.2. Multimídia:

    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

  • 2.2.3. Software:

    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 e Control e permitirem que apps de terceiros publiquem controles de dispositivos, elas:

    Se as implementações de dispositivos permitirem que os usuários façam qualquer tipo de ligação, eles

  • 2.2.4. Desempenho e potência:

    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.

  • 2.2.5. Modelo de segurança:

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

    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 como true, elas

    • [9.5/H-4-1] NÃO PODE incluir suporte para eUICCs, nem para eSIMs com capacidade de chamada.
    • [9.5/H-4-2] NÃO PODE declarar suporte para android.hardware.telephony.

    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-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 por SpeechRecognizer#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 por SpeechRecognizer#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 para ContentCaptureService 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.

  • 2.2.7.1. Mídia:

    Ver revisão

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

    Iniciar novos requisitos

    Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.U para android.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() e VideoCapabilities.getSupportedPerformancePoints().
    • [5.1/H-1-2] PRECISA oferecer suporte a seis instâncias de sessões de decodificador de vídeo por hardware 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() e VideoCapabilities.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() e VideoCapabilities.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 ou AUDIO_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 recurso Feature_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 para android.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.

  • 2.2.7.2. Câmera:

    Ver revisão

    Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.U para android.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 900 ms 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 e android.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 e Modo 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.

  • 2.2.7.3. Hardware:

    Ver revisão

    Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.U para android.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.

  • 2.2.7.4. Desempenho:

    Ver revisão

    Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.U para android.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.

  • 2.3.2. Multimídia:

    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:

  • 2.4.5. Modelo de segurança:

    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.

  • 2.5.1. Hardware:

    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 a FEATURE_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 ou android.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 ou android.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 ou android.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.

  • 2.5.3. Software:

    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.

  • 2.5.5. Modelo de segurança:

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

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 ou android.hardware.nfc.ese, elas:

  • 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.0 Vulkan 1.1, assim como as extensões VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 e VK_KHR_get_physical_device_properties2 usando a biblioteca libvulkan.so. Embora todos os símbolos PRECISAM estar presentes, a seção 7.1.4.2 descreve em mais detalhes os requisitos de quando a implementação completa de cada função correspondente é esperada.

  • 3.8.6. Temas:

    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 (consulte android.theme.customization.theme_styles), ou seja, TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD, eMONOCHROMATIC.

  • 3.8.8. Troca de atividades:

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

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

  • 5.1.4. Codificação de imagem:

    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.

  • 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
    VP9 Consulte detalhes na seção 5.3
    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)

  • 5.2. Codificação de vídeo:

    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 como BITRATE_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] PRECISA NÃO ter mais de 15% da taxa de bits entre intervalos intraframe (I-frame) em uma janela deslizante.
    • [C-5-2] PRECISA NÃ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 como BITRATE_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.

  • 5.2.1. H.263:

    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.

  • 5.2.5. H.265:

    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() ou getSupportedPerformancePoints() 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

  • 5.3.2. H.263:

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

  • 5.3.9. AV1:

    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 de ao lado do microfone) produza uma resposta ideal de 1.500 a cada

  • 5.5.2. Efeitos de áudio:

    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.

  • 5.6. Latência de áudio:

    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 para AAUDIO_PERFORMANCE_MODE_NONE e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY para alto-falantes e fones de ouvido com e sem fio.

7. Compatibilidade de hardware

  • 7.1. Tela e gráficos:

    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 de dpi ppi 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). A unidade de pixel virtual A normalizada para uma tela de 160 dpi densidade 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 e incluem compatíveis com o Android usam 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 interface UI_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:

    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

  • 7.1.1.3. Densidade da tela:

    Ver revisão

    Implementações de dispositivos:

    • [C-0-1] Por padrão, as implementações do dispositivo PRECISAM informar apenas uma das densidades do framework do Android listadas em DisplayMetrics pela API DENSITY_DEVICE_STABLE. Esse valor precisa ser um valor estático para cada tela física NÃ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 houve uma funcionalidade para mudar o tamanho da tela do dispositivo, elas:

    • [C-1-1] O tamanho da tela NÃO PODE ser dimensionado NÃO PODE dimensionar a tela mais que 1,5 vez DENSITY_DEVICE_STABLE densidade nativa ou 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 dimensionado NÃO PODE dimensionar a tela menor que 0,85 vezes a densidade nativa da DENSITY_DEVICE_STABLE.

  • 7.1.4.2 Vulkan:

    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.0 Vulkan 1.1 para cada VkPhysicalDevice 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 como true ou os metadados com.android.graphics.injectLayers.enable definidos como true .

    • DEVE oferecer suporte a VkPhysicalDeviceProtectedMemoryFeatures e VK_EXT_global_priority.

    • [C-SR-5] É FORTEMENTE RECOMENDADO para oferecer suporte a VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory e VK_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.

  • 7.3.10. Sensores biométricos:

    Ver revisão

    Se as implementações de dispositivos tiverem vários sensores biométricos, elas:

    • [C-7-1] 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 e IFingerprint.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), ou em 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 de STATIC STS DS-TWR unicast definido pela FiRa, modo adiado, intervalo de alcance de 240 ms.
      • CONFIG_ID_2: alcance de STATIC 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 a CONFIG_ID_1, exceto que os dados de ângulo de chegada (AoA) não são informados.
      • CONFIG_ID_4: igual a CONFIG_ID_1, exceto pelo modo de segurança do P-STS, ativado.
      • CONFIG_ID_5: igual a CONFIG_ID_2, exceto pelo modo de segurança do P-STS, ativado.
      • CONFIG_ID_6: igual a CONFIG_ID_3, exceto pelo modo de segurança do P-STS, ativado.
      • CONFIG_ID_7: igual a CONFIG_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ões NEARBY_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.

  • 7.4.1. Telefonia:

    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.

  • 7.4.2. IEEE 802.11 (Wi-Fi):

    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.

  • 7.4.3. Bluetooth:

    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

  • 7.4.9. UWB:

    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.

  • 7.5.1. Câmera traseira:

    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.

  • 7.5.2. Front-Facing Camera:

    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.

  • 7.5.3. Câmera externa:

    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.

  • 7.5.5. Orientação da câmera:

    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.

  • 7.10. Retorno tátil:

    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:

    Se as implementações de dispositivos seguirem o mapeamento de constantes táteis, elas:

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

9. Compatibilidade do modelo de segurança

  • 9.1. Permissões:

    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.

  • 9.5. Suporte multiusuário:

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

  • 9.7. Recursos de segurança:

    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á ativada
      • memtag-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.

  • 9.8.2. Gravação:

    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 capturadasativadas que incluam exatamente a mesma mensagem do AOSP sempre cada vez que uma sessão para capturar a tela a transmissão ou a gravação de tela com as APIs for pró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 dispositivo android.app.role.COMPANION_DEVICE_APP_STREAMING ou android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING.

  • 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 ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query ou outros meios proprietários, oferece suporte a um mecanismo para implementações de dispositivos que capturam as seguintes interações de dados entre os aplicativos e o usuário dados 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 por AppSearchGlobalManager.query.

    • Quaisquer outros eventos que um aplicativo fornece ao sistema pela API Content Capture ou pela API AppSearchManager, 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 registro do 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, como RAPPOR).

    • [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údo Dados 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 ContentCaptureService ou o método proprietário coleta se quando 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.

  • 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

  • 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:
    • [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/ou VisualQueryDetectionService do Android.

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

  • 9.10. Integridade do dispositivo:

    Ver revisão

    Implementações de dispositivos

    Se as implementações de dispositivos puderem verificar o conteúdo do arquivo por página, elas:

    • [C-0-3 C-2-1] é compatível com a verificação criptográfica do conteúdo do arquivo em relação a uma chave confiável sem ler o arquivo inteiro.

    • [C-0-4 C-2-2] NÃO PODE permitir que as solicitações de leitura em um arquivo protegido sejam bem-sucedidas quando o conteúdo de leitura não for verificado com base em uma chave confiável nã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.

  • 9.11. Chaves e credenciais:

    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 privilegiadosNÃO É POSSÍVEL permitir que códigos não confiáveis (por exemplo, apps de terceiros) criem e executem uma máquina virtual protegida pVM . Observação: isso pode mudar em versões futuras do Android.

    • [C-1-5] NÃO PODE permitir que uma pVM protegida execute 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 de Protected Virtual Machine pVM :

    • [C-2-1] PRECISA executar todos os sistemas operacionais disponíveis no APEX de virtualização em uma máquina virtual protegida pVM .
    • [C-2-2] NÃO PODE permitir que uma máquina virtual protegida pVM 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 protegida execute 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 protegida pVM (por exemplo, SELinux para pVMs), mesmo para sistemas operacionais não Microdroid.
    • [C-2-6] PRECISA garantir a inicialização da pVM o firmware recusa se não for possível verificar as imagens iniciais 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á inicializado se 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 que PRECISA garantir que 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 pVM só 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-26-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.

Voltar ao início