1. Introdução
Este documento enumera os requisitos que precisam ser atendidos para que os dispositivos para compatibilidade com o Android 14.
O uso de "PRECISA", "NÃO PODE", "OBRIGATÓRIO", "DEVERÁ", "NÃO DEVE", "DEVERIA", "NÃO DEVE", "RECOMENDADO", "PODE" e "OPCIONAL" é de acordo com o padrão IETF definido na RFC2119.
Conforme usado neste documento, um "implementador de dispositivo" ou "implementador" é uma pessoa ou organização que desenvolve uma solução de hardware/software executando Android 14. Uma "implementação de dispositivo" ou "implementação" é solução de hardware/software tão desenvolvida.
Para ser considerado compatível com o Android 14, o dispositivo implementações PRECISAM atender aos requisitos apresentados nesta seção Definição, incluindo quaisquer documentos incorporados por referência.
Onde essa definição ou os testes de software descritos em a seção 10 for silenciosa, ambígua ou incompletas, é responsabilidade do implementador do dispositivo garantir compatibilidade com as implementações atuais.
Por esse motivo, o Android Open Source Project é a referência e a implementação preferida do Android. Dispositivo implementadores são FORTEMENTE RECOMENDADOS a basear as implementações na o máximo possível no fluxo de origem o código-fonte disponível Android Open Source Project. Embora alguns componentes possam ser substituído por implementações alternativas, é FORTEMENTE RECOMENDADO não seguir essa prática, pois passar nos testes de software se tornará significativamente fica mais difícil. É responsabilidade do implementador garantir compatibilidade comportamental com a implementação padrão do Android, incluindo e além do Teste de Compatibilidade do Android. Por fim, observe que determinados componentes substituições e modificações são expressamente proibidas por este documento.
Muitos dos recursos vinculados a este documento são derivados diretamente ou indiretamente do SDK do Android e será funcionalmente idêntica à na documentação do SDK. Nos casos em que essa Compatibilidade A definição ou o conjunto de teste de compatibilidade discorda do SDK a documentação do SDK é considerada oficial. Qualquer modelo os detalhes fornecidos nos recursos vinculados ao longo deste documento são considerados por inclusão como parte da Definição de Compatibilidade.
1.1 Estrutura do documento
1.1.1. Requisitos por tipo de dispositivo
A Seção 2 contém todos os requisitos que se aplicam a uma tipo de dispositivo específico. Cada subseção da Seção 2 é é dedicada a um tipo específico de dispositivo.
Todos os outros requisitos que se aplicam universalmente a qualquer dispositivo Android implementações, estão listadas nas seções após a Seção 2. Esses requisitos são chamados de "Requisitos principais" neste documento.
1.1.2. ID do requisito
O ID do requisito é atribuído para os requisitos OBRIGATÓRIOS.
- O ID é atribuído apenas para os requisitos OBRIGATÓRIOS.
- Os requisitos FORTEMENTE RECOMENDADOS são marcados como [SR], mas o ID não foi atribuído.
- O ID consiste em : ID do tipo de dispositivo, ID da condição e ID do requisito (por exemplo, C-0-1).
Cada ID é definido conforme abaixo:
- ID do tipo de dispositivo (mais informações em 2. Tipos de dispositivos)
- C: Principais requisitos aplicados a todas as implementações de dispositivos Android.
- H: Dispositivo portátil Android
- T: Dispositivo Android Television
- R: Implementação no Android Automotive
- W: implementação do Android Watch
- Guia: implementação nos tablets Android
- ID da condição
- Quando o requisito é incondicional, esse ID é definido como 0.
- Quando o requisito é condicional, 1 é atribuído ao primeiro e o número aumenta em 1 na mesma seção, e do mesmo tipo de dispositivo.
- ID do requisito
- Esse ID começa em 1 e incrementa em 1 dentro da mesma seção, e a mesma condição.
1.1.3 ID do requisito na seção 2
Os IDs de requisitos na Seção 2 têm duas partes. A primeira corresponde a um ID de seção, conforme descrito acima. A segunda parte identifica formato e o requisito específico dele.
ID da seção, seguido pelo ID do requisito descrito acima.
- O ID na Seção 2 consiste em : ID da seção / ID do tipo de dispositivo: ID da condição - ID do requisito (por exemplo, 7.4.3/A-0-1).
2. Tipos de dispositivos
O Android Open Source Project fornece uma pilha de software que pode ser usada para uma variedade de tipos de dispositivos e formatos. Para reforçar a segurança dos dispositivos, da pilha de software, incluindo SOs substitutos ou kernels alternativos deve ser executada em um ambiente seguro, conforme descrito na seção 9 e em outras seções deste CDD. Existem alguns tipos de dispositivos com um ecossistema de distribuição de aplicativos relativamente melhor estabelecido.
Esta seção descreve esses tipos de dispositivos e outros requisitos e recomendações aplicáveis a cada tipo de dispositivo.
Todas as implementações de dispositivos Android que não se encaixam em nenhuma das os tipos de dispositivos PRECISAM atender a todos os requisitos das demais seções deste documento. Definição de compatibilidade.
2.1 Configurações do dispositivo
Para as principais diferenças na configuração de hardware por dispositivo tipo de dispositivo, consulte os requisitos específicos do dispositivo nesta seção.
2.2. Requisitos para dispositivos portáteis
Um dispositivo portátil Android é uma implementação de dispositivo Android que é normalmente usado segurando-o na mão, como um player de mp3, telefone ou tablet.
As implementações de dispositivos Android serão classificadas como portáteis se atenderem a todos os seguintes critérios:
- usar uma fonte de energia que ofereça mobilidade, como uma bateria;
- Ter um tamanho de tela diagonal físico dentro do intervalo de
4 polegadas
3,3 polegadas (ou 2,5 polegadas para implementações de dispositivos enviadas no nível 29 da API ou antes)para 20 centímetros. - Use uma interface de entrada com tela sensível ao toque.
Os requisitos adicionais no restante desta seção são específicos para o Android Implementações de dispositivos portáteis.
2.2.1. Hardware
Implementações de dispositivos portáteis:
- [7.1.1.1/H-0-1] PRECISA ter pelo menos um
Tela compatível com Android
que atende a todos os requisitos descritas neste documento.tela que mede pelo menos 2,2” na borda curta e 3,4” na borda longa. [7.1.1.3/H-SR-1] É FORTEMENTE RECOMENDADO para fornecem aos usuários uma affordance para alterar o tamanho de exibição (densidade da tela).
[7.1.1.1/H-0-2] PRECISA oferecer suporte à composição de GPU de Os buffers gráficos têm no mínimo a maior resolução de qualquer exibição.
Iniciar novos requisitos
[7.1.1.1/H-0-3]* PRECISA mapear cada
UI_MODE_NORMAL
tela disponibilizada para aplicativos de terceiros em um local área de exibição física de pelo menos 2,2” polegadas na borda curta e 3,4” centímetros na borda longa.[7.1.1.3/H-0-1]* PRECISA definir o valor de
DENSITY_DEVICE_STABLE
seja 92% ou maior do que a densidade física real da exibição correspondente.
Encerrar novos requisitos
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 criar a tela lógica disponibilizada para aplicativos de terceiros esteja a pelo menos 5 centímetros canto(s) curto(s) e 2,7 polegadas nas bordas longas. Os dispositivos fornecidos com a API do Android de nível 29 ou anterior podem ser isentos dessa exigência.
Se as implementações de dispositivos portáteis não oferecerem suporte à rotação da tela do software, eles:
- [7.1.1.1/H-2-1]* PRECISA criar a tela lógica disponibilizada para aplicativos de terceiros tenha pelo menos 7,8 centímetros as arestas curtas. Os dispositivos fornecidos com a API do Android de nível 29 ou anterior podem ser isentos dessa exigência.
Iniciar novos requisitos
Se as implementações de dispositivos portáteis tiverem suporte ao Vulkan, elas:
- [7.1.4.2/H-1-1] PRECISA atender aos requisitos. especificados pelo perfil de referência do Android 2021.
Encerrar novos requisitos
Se as implementações de dispositivos portáteis forem compatíveis com High Dynamic Range
exibe por meio de Configuration.isScreenHdr()
, eles:
- [7.1.4.5/H-1-1] PRECISA anunciar o suporte para o
EGL_EXT_gl_colorspace_bt2020_pq
,EGL_EXT_surface_SMPTE2086_metadata
,EGL_EXT_surface_CTA861_3_metadata
,VK_EXT_swapchain_colorspace
eVK_EXT_hdr_metadata
extensões.
Implementações de dispositivos portáteis:
- [7.1.4.6/H-0-1] PRECISA informar se o dispositivo
oferece suporte à criação de perfil da GPU por uma propriedade do sistema
graphics.gpu.profiler.support
Se as implementações de dispositivos portáteis declararem suporte por meio de uma propriedade do sistema
graphics.gpu.profiler.support
, eles:
- [7.1.4.6/H-1-1] PRECISA informar como saída uma rastro protobuf que está em conformidade com o esquema de contadores de GPU e GPU Renderstages definidos na documentação do Perfetto (links em inglês).
- [7.1.4.6/H-1-2] PRECISA informar os valores em conformidade para os contadores de GPU do dispositivo seguindo o proto do pacote de trace do contador de gpu.
- [7.1.4.6/H-1-3] PRECISA informar os valores em conformidade para os RenderStages da GPU do dispositivo após o proto do pacote de trace do estágio de renderização.
- [7.1.4.6/H-1-4] PRECISA informar uma frequência de GPU. tracepoint, conforme especificado pelo formato: power/gpu_frequency.
Implementações de dispositivos portáteis:
- [7.1.5/H-0-1] PRECISA incluir suporte para modelos legados. o modo de compatibilidade do aplicativo conforme implementado pelo Android upstream o código-fonte. Ou seja, as implementações de dispositivos NÃO PODEM alterar os acionadores ou limites em que o modo de compatibilidade é ativado e NÃO PODE alterar o do próprio modo de compatibilidade.
- [7.2.1/H-0-1] PRECISA incluir suporte para terceiros. Aplicativos do Editor de método de entrada (IME, na sigla em inglês).
- [7.2.3/H-0-2] PRECISA enviar os comandos normal e longo
Evento da função Voltar (
KEYCODE_BACK
) para o aplicativo em primeiro plano. Esses eventos NÃO PODEM ser consumidos pelo sistema e PODE ser acionado fora do dispositivo Android (por exemplo, hardware externo teclado conectado ao dispositivo Android). - [7.2.3/H-0-3] PRECISA fornecer a função Home no todas as telas compatíveis com Android que fornecem a tela inicial.
- [7.2.3/H-0-4] PRECISA fornecer a função "Voltar" em todas telas compatíveis com Android e a função Recentes em pelo menos um telas compatíveis com Android.
- [7.2.4/H-0-1] PRECISA oferecer suporte à entrada touchscreen.
- [7.2.4/H-SR-1] É FORTEMENTE RECOMENDADO para lançar a
app assistivo selecionado pelo usuário, ou seja, o app que implementa
VoiceInteractionService ou uma atividade que processa a
ACTION_ASSIST
(link em inglês). ao tocar e manter o botãoKEYCODE_MEDIA_PLAY_PAUSE
pressionado ouKEYCODE_HEADSETHOOK
se a atividade em primeiro plano não processar esses eventos de tocar e manter pressionado. - [7.3.1/H-SR-1] É MUITO RECOMENDADO a inclusão de um eixo acelerômetro.
Se as implementações de dispositivos portáteis incluírem um acelerômetro de três eixos, elas:
- [7.3.1/H-1-1] PRECISA relatar eventos até uma frequência. de pelo menos 100 Hz.
Se as implementações de dispositivos portáteis incluírem um receptor GPS/GNSS e informarem o
aos aplicativos pelo recurso android.hardware.location.gps
ele:
- [7.3.3/H-2-1] PRECISA informar as medições de GNSS assim que elas forem encontrados, mesmo que uma localização calculada a partir de GPS/GNSS ainda não tenha sido relatada.
- [7.3.3/H-2-2] PRECISA informar as pseudodistâncias e pseudodistâncias do GNSS. em condições de céu aberto após a determinação do local, enquanto parado ou em movimento com menos de 0,2 metro por segundo ao quadrado de são suficientes para calcular uma posição dentro de 20 metros, e a velocidade em 0,2 metro por segundo, pelo menos 95% do tempo.
Se as implementações de dispositivos portáteis incluírem um giroscópio de três eixos, elas:
- [7.3.4/H-3-1] PRECISA relatar eventos até uma frequência. de pelo menos 100 Hz.
- [7.3.4/H-3-2] PRECISA ser capaz de medir mudanças de orientação. até 1.000 graus por segundo.
Implementações de dispositivos portáteis que podem fazer chamadas de voz e indicar
qualquer valor diferente de PHONE_TYPE_NONE
em getPhoneType
:
- [7.3,8/H] DEVEM incluir um sensor de proximidade.
Implementações de dispositivos portáteis:
- [7.3.11/H-SR-1] É FORTEMENTE RECOMENDADO para oferecer suporte ao sensor de pose com 6 graus de liberdade.
- [7.4.3/H] DEVE incluir suporte para Bluetooth e Bluetooth LE
Se os dispositivos forem compatíveis com o protocolo Wi-Fi Neighbor Awareness Networking (NAN)
declarar PackageManager.FEATURE_WIFI_AWARE
e a localização de Wi-Fi (Wi-Fi Round
Tempo de viagem (RTT)) ao declarar PackageManager.FEATURE_WIFI_RTT
. Depois, eles:
[7.4.2.5/H-1-1] PRECISA informar o intervalo com precisão para dentro de +/-1 metro a uma largura de banda de 160 MHz no 68o percentil (conforme calculado com a função de distribuição cumulativa), +/-2 metros a 80 MHz de largura de banda a no 68o percentil, +/-4 metros a 40 MHz de largura de banda no 68o percentil, e +/-8 metros a uma largura de banda de 20 MHz no 68o percentil a distâncias de 10 cm, 1 m, 3 m e 5 m, conforme observado pelo API WifiRttManager#startRanging do Android.
[7.4.2.5/H-SR-1] É FORTEMENTE RECOMENDADO para informar o intervalo com precisão de +/-1 metro a uma largura de banda de 160 MHz no 90o percentil (conforme calculado com a função de distribuição cumulativa), +/-2 metros a 80 MHz de largura de banda no 90o percentil, +/- 4 metros a 40 MHz largura de banda no 90o percentil e +/-8 metros a 20 MHz de largura de banda no 90o percentil a distâncias de 10 cm, conforme observado pelo API WifiRttManager#startRanging do Android.
É RECOMENDADO seguir as etapas de configuração de medição especificadas no Calibragem de presença.
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 Rx
para garantir que o RSSI médio do BLE seja -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 Tx
para garantir que o RSSI médio do BLE seja -50 dBm +/-15 dB ao ler a partir de
dispositivo de referência posicionado a 1 m de distância e transmitindo a
ADVERTISE_TX_POWER_HIGH
Encerrar novos requisitos
Se as implementações de dispositivos portáteis incluírem um dispositivo de câmera lógico que liste
recursos usando
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
,
eles:
- [7.5.4/H-1-1] PRECISA ter o campo de visão (FOV) normal por padrão e PRECISA estar entre 50 e 50 graus.
Implementações de dispositivos portáteis:
- [7.6.1/H-0-1] PRECISA ter pelo menos 4 GB de armazenamento não volátil disponível para dados privados de aplicativos (também conhecida como partição "/data").
- [7.6.1/H-0-2] PRECISA retornar "true" para
ActivityManager.isLowRamDevice()
quando há menos de 1 GB de memória disponíveis para o kernel e o espaço do usuário.
Se as implementações de dispositivos portáteis declararem compatibilidade somente com ABI de 32 bits:
[7.6.1/H-1-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 416 MB se a exibição padrão usar framebuffer resoluções até qHD (por exemplo, FWVGA).
[7.6.1/H-2-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 592 MB se a exibição padrão usar framebuffer resoluções até HD+ (por exemplo, HD, WSVGA).
[7.6.1/H-3-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 896 MB se a exibição padrão usar framebuffer resoluções até FHD (ex.: WSXGA+).
[7.6.1/H-4-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 1.344 MB se a tela padrão usar resoluções de framebuffer até QHD (por exemplo, QWXGA).
Se as implementações de dispositivos portáteis declararem compatibilidade com qualquer ABI de 64 bits (com ou sem ABI de 32 bits):
[7.6.1/H-5-1] A memória disponível para o kernel e o espaço do usuário PRECISAM ter pelo menos 816 MB se a tela padrão usar resoluções de framebuffer acima para qHD (por exemplo, FWVGA).
[7.6.1/H-6-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser pelo menos 944 MB se a tela padrão usar resoluções de framebuffer até HD+ (por exemplo, HD, WSVGA).
[7.6.1/H-7-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser pelo menos 1.280 MB se a tela padrão usar resoluções de framebuffer até FHD (por exemplo, WSXGA+).
[7.6.1/H-8-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser pelo menos 1.824 MB se a tela padrão usar resoluções de framebuffer até QHD (por exemplo, QWXGA).
Observe que a "memória disponível para o kernel e o espaço do usuário" acima refere-se à além de qualquer memória já dedicada ao hardware como rádio, vídeo, entre outros, que não estão no kernel nas implementações de dispositivos.
Se as implementações de dispositivos portáteis incluírem menos ou iguais a 1 GB de memória disponíveis para o kernel e o espaço do usuário, eles:
- [7.6.1/H-9-1] PRECISA declarar a flag de recurso.
android.hardware.ram.low
. - [7.6.1/H-9-2] PRECISA ter pelo menos 1,1 GB de armazenamento não volátil para aplicativos dados privados (também conhecida como partição "/data").
Se as implementações de dispositivos portáteis incluírem mais de 1 GB de memória disponível ao kernel e ao espaço do usuário, eles:
- [7.6.1/H-10-1] PRECISA ter pelo menos 4 GB de não volátil disponível para dados privados do aplicativo (também conhecida como partição "/data").
- DEVE declarar a flag de recurso
android.hardware.ram.normal
.
Se as implementações de dispositivos portáteis incluírem maior ou igual a 2 GB e menos de 4 GB de memória disponíveis para o kernel e o espaço do usuário, eles:
- [7.6.1/H-SR-1] É FORTEMENTE RECOMENDADO para oferecer suporte apenas ao espaço do usuário de 32 bits (apps e código do sistema)
Se as implementações de dispositivos portáteis incluírem menos de 2 GB de memória disponível para o kernel e o espaço do usuário, eles:
- [7.6.1/H-1-1] PRECISA oferecer suporte a apenas uma ABI (somente 64 ou 32 bits). apenas).
Implementações de dispositivos portáteis:
- [7.6.2/H-0-1] NÃO PODE fornecer uma inscrição armazenamento compartilhado menor que 1 GiB.
- [7.7.1/H] DEVE incluir uma porta USB compatível com o modo de periféricos.
Se as implementações de dispositivos portáteis incluírem uma porta USB compatível com periféricos , eles:
- [7.7.1/H-1-1] PRECISA implementar o Android Open Accessory (AOA). API.
Se as implementações de dispositivos portáteis incluírem uma porta USB compatível com o modo host, eles:
- [7.7.2/H-1-1] PRECISA implementar a classe de áudio USB. conforme documentado na documentação do SDK do Android.
Implementações de dispositivos portáteis:
- [7.8.1/H-0-1] PRECISA incluir um microfone.
- [7.8.2/H-0-1] PRECISA ter uma saída de áudio e declarar
android.hardware.audio.output
Se as implementações de dispositivos portáteis forem capazes de atender a todos os requisitos de desempenho requisitos para oferecer suporte ao modo RV e incluir suporte para ele, eles:
- [7.9.1/H-1-1] PRECISA declarar a
android.hardware.vr.high_performance
. - [7.9.1/H-1-2] PRECISA incluir um aplicativo
implementar
android.service.vr.VrListenerService
que podem ser ativados pela RV peloandroid.app.Activity#setVrModeEnabled
.
Se as implementações de dispositivos portáteis incluírem uma ou mais portas USB-C no host e implementar (classe de áudio USB), além dos requisitos de seção 7.7.2, eles:
- [7.8.2.2/H-1-1] PRECISA fornecer o seguinte mapeamento de software de códigos HID:
Função | Mapeamentos | Contexto | Comportamento |
---|---|---|---|
A | Página de uso do HID: 0x0C Uso de HID: 0x0CD Chave do kernel: KEY_PLAYPAUSE Chave do Android: KEYCODE_MEDIA_PLAY_PAUSE |
Controles de mídia | Entrada: pressione rapidamente Saída: reproduzir ou pausar |
Entrada: toque e mantenha pressionado . Saída: iniciar o comando de voz Envios: android.speech.action.VOICE_SEARCH_HANDS_FREE se o dispositivo
está bloqueado ou a tela está desligada. Envios
Caso contrário android.speech.RecognizerIntent.ACTION_WEB_SEARCH |
|||
Chamada recebida | Entrada: pressione rapidamente Saída: aceitar chamada |
||
Entrada: toque e mantenha pressionado . Saída: rejeitar chamada |
|||
Chamada em andamento | Entrada: pressione rapidamente Saída: fim da chamada |
||
Entrada: toque e mantenha pressionado . Saída: ativar ou desativar o som do microfone |
|||
B | Página de uso do HID: 0x0C Uso de HID: 0x0E9 Chave do kernel: KEY_VOLUMEUP Chave do Android: VOLUME_UP |
Reprodução de mídia, ligação em andamento | Entrada: toque curto ou longo Saída: aumenta o volume do sistema ou do fone de ouvido |
C | Página de uso do HID: 0x0C Uso de HID: 0x0EA Chave do kernel: KEY_VOLUMEDOWN Chave do Android: VOLUME_DOWN |
Reprodução de mídia, ligação em andamento | Entrada: toque curto ou longo Saída: diminui o volume do sistema ou do fone de ouvido. |
D | Página de uso do HID: 0x0C Uso de HID: 0x0CF Chave do kernel: KEY_VOICECOMMAND Chave do Android: KEYCODE_VOICE_ASSIST |
Todas. Pode ser acionado em qualquer instância. | Entrada: toque curto ou longo Saída: iniciar o comando de voz |
- [7.8.2.2/H-1-2] PRECISA acionar ACTION_HEADSET_PLUG na inserção de um plugue, mas somente depois que as interfaces de áudio USB e os endpoints foram enumerados corretamente para identificar o tipo de terminal conectado.
Quando o terminal de áudio USB do tipo 0x0302 é detectado, ele:
- [7.8.2.2/H-2-1] PRECISA transmitir a intent ACTION_HEADSET_PLUG com "microfone" o extra é definido como zero.
Quando o terminal de áudio USB do tipo 0x0402 é detectado, ele:
- [7.8.2.2/H-3-1] PRECISA transmitir a intent ACTION_HEADSET_PLUG com "microfone" o extra foi definido como 1.
Quando a API AudioManager.getDevices() é chamada enquanto o periférico USB está conectaram:
[7.8.2.2/H-4-1] PRECISA listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_HEADSET e o papel isSink() se o campo do tipo do terminal de áudio USB for 0x0302.
[7.8.2.2/H-4-2] PRECISA listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_HEADSET e função isSink() se o terminal de áudio USB é 0x0402.
[7.8.2.2/H-4-3] PRECISA listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_HEADSET e função isSource() se o terminal de áudio USB é 0x0402.
[7.8.2.2/H-4-4] PRECISA listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_DEVICE. e o papel isSink() se o campo do tipo do terminal de áudio USB for 0x603.
[7.8.2.2/H-4-5] PRECISA listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_DEVICE e função isSource() se o terminal de áudio USB é 0x604.
[7.8.2.2/H-4-6] PRECISA listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_DEVICE e função isSink() se o tipo de terminal de áudio USB é 0x400.
[7.8.2.2/H-4-7] PRECISA listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_DEVICE e função isSource() se o terminal de áudio USB campo de tipo é 0x400.
[7.8.2.2/H-SR-1] São RECOMENDADOS FORTEMENTE na conexão de um Periférico de áudio USB-C, para realizar a enumeração de descritores USB, identificar e transmitir a intent ACTION_HEADSET_PLUG em menos de 1.000 milissegundos.
Se as implementações de dispositivos portáteis declararem android.hardware.audio.output
e
android.hardware.microphone
, eles:
[5.6/H-1-1] PRECISA ter uma viagem de ida e volta contínua média latência de 300 milissegundos ou menos de 5 medições, com um Desvio médio absoluto menor que 30 ms, acima estes caminhos de dados: "alto-falante para o microfone", Adaptador de loopback de 3,5 mm (se compatível), loopback USB (se compatível).
[5.6/H-1-2] PRECISA ter uma latência média entre toques. de 300 milissegundos ou menos em pelo menos cinco medições pelo alto-falante para o caminho de dados do microfone.
Se as implementações de dispositivos portáteis incluírem pelo menos um atuador tátil, elas:
- [7,10/H]* NÃO DEVE usar uma massa giratória excêntrica (ERM, na sigla em inglês) atuador tátil (vibrador).
- [7.10/H]* DEVE implementar todas as constantes públicas para retorno tátil limpo em android.view.HapticFeedbackConstants ou seja (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START e GESTURE_END).
- [7.10/H]* DEVE implementar todas as constantes públicas para
retorno tátil limpo
em android.os.VibrationEffect
ou seja (Efeito_TICK, EF_CLICK, EF_HEAVY_CLICK e
Effect_DOUBLE_CLICK) e todos os públicos viáveis
PRIMITIVE_*
constantes para retorno tátil avançado em android.os.VibrationEffect.Composition ou seja (CLICK, TICK, LOW_TICK, QUICK_FALL, ACELERAÇÃO RÁPIDA, ENCERRADA_Lenta, GIRADA, QUI). Alguns desses primitivos, LOW_TICK e SPIN só serão viáveis se a vibração for compatível frequências relativamente baixas. - [7.10/H]* DEVE seguir as orientações para mapeamento de constantes públicas em android.view.HapticFeedbackConstants às constantes android.os.VibrationEffect recomendadas, com as relações de amplitude correspondentes.
- [7,10/H]* DEVE seguir avaliação de qualidade para createOneShot() e createWaveform() APIs de terceiros.
- [7.10/H]* DEVE verificar se o resultado do comando público android.os.Vibrator.hasAmplitudeControl() A API reflete corretamente os recursos da vibração.
- [7,10/H]* DEVE posicionar o posicionamento do atuador perto do local em que o dispositivo normalmente é segurado ou tocado pelas mãos.
Um atuador ressonante linear (LRA, na sigla em inglês) é um sistema de mola de massa simples com frequência ressonante dominante, em que a massa se traduz na direção movimento desejado.
Se as implementações de dispositivos portáteis incluírem pelo menos um uso geral 7.10 atuador ressonante linear, eles:
Iniciar novos requisitos
- [7,10/H] DEVE posicionar o posicionamento do atuador próximo o local em que o dispositivo normalmente é segurado ou tocado pelas mãos.
Encerrar novos requisitos
- [7,10/H]
DEVE mover o atuador tátil no eixo X
(à esquerda) da parte natural do dispositivo
É a orientação
retrato.
Se as implementações de dispositivos portáteis tiverem um uso geral atuador tátil, que é um atuador ressonante linear do eixo X (LRA, na sigla em inglês), eles:
- [7,10/H] A frequência ressonante do LRA do eixo X DEVE ser menor que 200 Hz.
Se as implementações de dispositivos portáteis seguirem o mapeamento de constantes táteis, elas:
- [7.10/H]* DEVE verificar o status da implementação executando android.os.Vibrator.areAllEffectssupported() e android.os.Vibrator.arePrimitivesSuporte() APIs.
[7,10/H]* DEVE realizar uma avaliação de qualidade para constantes táteis.
[7.10/H]* DEVE verificar e atualizar o substituto, se necessário configuração para primitivos não suportados, conforme descrito nas orientações para implementação para constantes.
2.2.2. Multimídia
As implementações de dispositivos portáteis PRECISAM ser compatíveis com as seguintes codificações de áudio e formatos de decodificação e disponibilizá-los para aplicativos de terceiros:
- [5.1/H-0-1] AMR-NB
- [5.1/H-0-2] AMR-WB
- [5.1/H-0-3] Perfil AAC MPEG-4 (AAC LC)
- [5.1/H-0-4] Perfil MPEG-4 HE AAC (AAC+)
- [5.1/H-0-5] AAC ELD (AAC com atraso baixo aprimorado)
As implementações de dispositivos portáteis PRECISAM ser compatíveis com a seguinte codificação de vídeo formatos e disponibilizá-los para aplicativos de terceiros:
As implementações de dispositivos portáteis PRECISAM ser compatíveis com a seguinte decodificação de vídeo formatos e disponibilizá-los para aplicativos de terceiros:
2.2.3. Software
Implementações de dispositivos portáteis:
- [3.2.3.1/H-0-1] PRECISA ter uma
aplicativo que lida com o
ACTION_GET_CONTENT
,ACTION_OPEN_DOCUMENT
,ACTION_OPEN_DOCUMENT_TREE
, eACTION_CREATE_DOCUMENT
intents conforme descrito nos documentos do SDK e fornecem a affordance do usuário para acessar os dados do provedor de documentos usando a APIDocumentsProvider
. - [3.2.3.1/H-0-2]* É NECESSÁRIO pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents, para todos os padrões de filtro de intent pública definidos pelo seguinte aplicativo intents listadas aqui.
- [3.2.3.1/H-SR-1] São FORTES RECOMENDADO de pré-carregar um aplicativo de e-mail que pode lidar com ACTION_SENDTO ou ACTION_SEND ou ACTION_SEND_MULTIPLE para enviar um e-mail.
- [3.4.1/H-0-1] PRECISA fornecer um
implementação da API
android.webkit.Webview
. - [3.4.2/H-0-1] PRECISA incluir um navegador autônomo. para a navegação na Web de usuários gerais.
- [3.8.1/H-SR-1] São FORTEMENTE RECOMENDADOS para implementar uma tela de início padrão com suporte à fixação de atalhos no app. widgets e widgetFeatures.
- [3.8.1/H-SR-2] São FORTEMENTE RECOMENDADOS implementar um inicializador padrão que fornece acesso rápido aos recursos atalhos fornecidos por apps de terceiros usando o ShortcutsManager API.
- [3.8.1/H-SR-3] São FORTEMENTE RECOMENDADOS para incluir um app de tela de início padrão que mostra selos para os ícones de apps.
- [3.8.2/H-SR-1] São FORTEMENTE RECOMENDADOS para oferecer suporte a widgets de apps de terceiros.
- [3.8.3/H-0-1] PRECISA permitir serviços de terceiros
para notificar os usuários sobre eventos importantes usando o
Notification
e oNotificationManager
Classes de API. - [3.8.3/H-0-2] PRECISA ser compatível com rich notificações.
- [3.8.3/H-0-3] PRECISA ser compatível com os avisos notificações.
- [3.8.3/H-0-4] PRECISA incluir um aba de notificações, fornecendo ao usuário a capacidade de controlar diretamente (por exemplo, responder, adiar, dispensar, bloquear) as notificações por meio de affordance do usuário, como ou o painel de controle conforme implementado no AOSP.
- [3.8.3/H-0-5] PRECISA mostrar as opções
fornecido pelo parceiro
RemoteInput.Builder setChoices()
na aba de notificações. - [3.8.3/H-SR-1] São FORTEMENTE RECOMENDADOS
para mostrar a primeira opção fornecida por
RemoteInput.Builder setChoices()
na aba de notificações sem precisar de interação adicional do usuário. - [3.8.3/H-SR-2] São FORTEMENTE RECOMENDADOS
para mostrar todas as opções fornecidas em
RemoteInput.Builder setChoices()
na aba de notificações quando o usuário expandir todas as notificações da aba de notificações. - [3.8.3.1/H-SR-1] São FORTEMENTE RECOMENDADOS
para mostrar ações para quais
Notification.Action.Builder.setContextual
está definido comotrue
alinhado com as respostas exibidas porNotification.Remoteinput.Builder.setChoices
. - [3.8.4/H-SR-1] São FORTEMENTE RECOMENDADOS para implementar um assistente no dispositivo e processar a ação de assistência.
Se as implementações de dispositivos portáteis forem compatíveis com notificações do MediaStyle eles:
- [3.8.3.1/H-SR-2] São FORTEMENTE RECOMENDADOS
para fornecer uma funcionalidade de usuário (por exemplo, seletor de saída) acessada
interface do sistema que permite aos usuários alternar entre as mídias adequadas disponíveis
rotas (por exemplo, dispositivos Bluetooth e rotas fornecidas para
MediaRouter2Manager
). quando um app posta uma notificaçãoMediaStyle
com um tokenMediaSession
.
Iniciar novos requisitos
Se as implementações do dispositivo, incluindo a tecla de navegação da função Recentes, como detalhadas na seção 7.2.3 alteram a interface, eles:
- [3.8.3/H-1-1] PRECISA implementar a tela. comportamento de fixação e fornecer ao usuário um menu de configurações para alternar o .
Encerrar novos requisitos
Se as implementações de dispositivos portáteis forem compatíveis com a ação de assistência, elas:
- [3.8.4/H-SR-2] São FORTEMENTE RECOMENDADOS
para usar a tecla
HOME
como a interação designada para iniciar o como descrito na seção 7.2.3. PRECISA ser lançado o app assistivo selecionado pelo usuário, ou seja, o app que implementaVoiceInteractionService
ou uma atividade que processa a intentACTION_ASSIST
.
Se as implementações de dispositivos portáteis forem compatíveis com conversation notifications
e agrupe-as em uma seção separada dos alertas e das conversas silenciosas
notificações, eles:
- [3.8.4/H-1-1]* PRECISA exibir notificações de conversa antes das notificações que não são de conversa com com exceção das notificações de serviços em primeiro plano importance:alta notificações.
Se as implementações de dispositivos portáteis Android oferecerem suporte a uma tela de bloqueio, elas:
- [3.8.10/H-1-1] PRECISA exibir o ícone de cadeado. Notificações da tela, incluindo o Modelo de notificação de mídia.
Se as implementações de dispositivos portáteis forem compatíveis com uma tela de bloqueio segura, elas:
- [3.9/H-1-1] PRECISA implementar toda a gama de administração de dispositivos políticas definidas na documentação do SDK do Android.
Se as implementações de dispositivos portáteis incluírem suporte para
ControlsProviderService
e Control
e permitem que aplicativos de terceiros publiquem controles de dispositivos. Em seguida, eles:
- [3.8.16/H-1-1] PRECISA declarar o recurso
sinalizar
android.software.controls
e a defina comotrue
. - [3.8.16/H-1-2] PRECISA fornecer um usuário
com a capacidade de adicionar, editar, selecionar e operar o ambiente
controles de dispositivo favoritos dos controles registrados pelo terceiro
aplicativos por meio do
ControlsProviderService
e oControl
APIs de terceiros. - [3.8.16/H-1-3] PRECISA fornecer acesso a essa funcionalidade do usuário dentro de três interações de uma tela de início padrão.
[3.8.16/H-1-4] PRECISA renderizar com precisão nesta funcionalidade de usuário, o nome e o ícone de cada aplicativo de terceiros que oferece controles pelo
ControlsProviderService
a API, bem como quaisquer campos especificados fornecidos pelaControl
APIs de terceiros.[3.8.16/H-1-5] PRECISA fornecer um usuário affordance para desativar os controles de dispositivo de autenticação triviais designados pelo aplicativo controles registrados pelos aplicativos de terceiros por meio do
ControlsProviderService
e oControl
APIControl.isAuthRequired
.
Iniciar novos requisitos
- [3.8.16/H-1-6] Implementações de dispositivos
PRECISA renderizar com precisão a affordance do usuário da seguinte forma:
- Se o dispositivo tiver definido
config_supportsMultiWindow=true
e o app declarar os metadadosMETA_DATA_PANEL_ACTIVITY
noControlsProviderService
declaração, incluindo o ComponentName de um uma atividade válida (conforme definido pela API), o app PRECISA incorporar essa atividade nesta funcionalidade do usuário. - Se o app não declarar os metadados
META_DATA_PANEL_ACTIVITY
, ele PRECISA renderizar os campos especificados conforme fornecido peloControlsProviderService
a API, bem como quaisquer campos especificados fornecidos pela Control APIs.
- Se o dispositivo tiver definido
- [3.8.16/H-1-7] Se o app declarar os metadados
META_DATA_PANEL_ACTIVITY
, ele PRECISA passar o valor da configuração definida em [3.8.16/H-1-5] usandoEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS
ao iniciar a atividade incorporada.
Encerrar novos requisitos
Por outro lado, se as implementações de dispositivos portáteis não implementarem esses controles, eles:
- [3.8.16/H-2-1] PRECISA informar
null
para aControlsProviderService
e oControl
APIs de terceiros. - [3.8.16/H-2-2] PRECISA declarar o recurso
sinalizar
android.software.controls
e a defina comofalse
.
Se as implementações de dispositivos portáteis não estiverem em execução no modo de bloqueio de tarefas, quando o conteúdo for copiado para a área de transferência, elas:
- [3.8.17/H-1-1] PRECISA apresentar uma confirmação ao usuário de que os dados foram copiado para a área de transferência (por exemplo, uma miniatura ou alerta de "Conteúdo copiado"). Além disso, inclua uma indicação se os dados da área de transferência serão sincronizados. entre dispositivos.
Implementações de dispositivos portáteis:
- [3.10/H-0-1] PRECISA ser compatível com acessibilidade de terceiros. serviços.
- [3.10/H-SR-1] É FORTEMENTE RECOMENDADO o pré-carregamento serviços de acessibilidade no dispositivo comparáveis com funcionalidades superiores ou iguais a elas do acesso com interruptor e do TalkBack (para os idiomas compatíveis com os recursos mecanismo de conversão de texto em voz) conforme fornecido no talkback aberto no projeto de origem.
- [3.11/H-0-1] PRECISA ser compatível com a instalação do mecanismos TTS de terceiros.
- [3.11/H-SR-1] É FORTEMENTE RECOMENDADO a inclusão de um Mecanismo de TTS com suporte para os idiomas disponíveis no dispositivo.
- [3.13/H-SR-1] É FORTEMENTE RECOMENDADO a inclusão de um Componente de interface das Configurações rápidas.
Se as implementações de dispositivos portáteis Android declararem FEATURE_BLUETOOTH
ou
FEATURE_WIFI
, eles:
- [3.16/H-1-1] PRECISA oferecer suporte ao pareamento do dispositivo complementar .
Se a função de navegação for fornecida como uma ação na tela baseada em gestos:
- [7.2.3/H] A zona de reconhecimento de gestos da casa DEVE ter no máximo 32 dp de altura a partir da parte inferior tela.
Se as implementações de dispositivos portáteis fornecerem uma função de navegação como um gesto de qualquer lugar nas extremidades esquerda e direita da tela:
- [7.2.3/H-0-1] A área de gestos da função de navegação PRECISA ter menos de 40 dp de largura em cada lado. A área de gestos DEVE ser 24 dp de largura por padrão.
Se as implementações de dispositivos portáteis forem compatíveis com uma tela de bloqueio segura e tiverem mais ou igual a 2 GB de memória disponível para o kernel e o espaço do usuário, eles:
- [3.9/H-1-2] PRECISA declarar o suporte de perfis gerenciados pela
Sinalização de recurso
android.software.managed_users
.
Se as implementações de dispositivos portáteis Android declararem suporte à câmera por meio de
android.hardware.camera.any
eles:
- [7.5.4/H-1-1] PRECISA respeitar o
android.media.action.STILL_IMAGE_CAMERA
. eandroid.media.action.STILL_IMAGE_CAMERA_SECURE
e inicializar a câmera em modo de imagem estática, conforme descrito no SDK. - [7.5.4/H-1-2] PRECISA respeitar o
android.media.action.VIDEO_CAMERA
. de iniciar a câmera em modo de vídeo, conforme descrito no SDK.
Se o aplicativo de configurações da implementação do dispositivo implementar uma funcionalidade dividida, usando a incorporação de atividades, eles:
- [3.2.3.1/ H-1-1] PRECISA ter uma atividade que gerencie
Settings#ACTION_CONFIG_EMBED_DEEP_LINK_ACTIVITY quando a funcionalidade de divisão estiver ativada. A Activity PRECISA ser protegida por
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
e PRECISA ser. iniciar a atividade da intent analisada Configurações#EXTRA_CONFIG_EMBEDDED_DEEP_LINK_INTENT_URI.
Iniciar novos requisitos
Se as implementações de dispositivos permitirem que os usuários façam qualquer tipo de ligação, eles
- [7.4.1.2/H-0-1] PRECISA declarar a flag de recurso
android.software.telecom
. - [7.4.1.2/H-0-2] PRECISA implementar o framework de telecomunicações.
Encerrar novos requisitos
2.2.4 Desempenho e potência
- [8.1/H-0-1] Latência de frame consistente. Latência de frame inconsistente ou um atraso na renderização de frames NÃO PODEM acontecer com mais frequência geralmente que 5 quadros por segundo e DEVE estar abaixo de 1 quadros por segundo.
- [8.1/H-0-2] Latência da interface do usuário. As implementações de dispositivos DEVEM garantir uma experiência do usuário de baixa latência rolando uma lista de 10 mil entradas de lista, conforme definido pelo Teste de compatibilidade do Android. (CTS) em menos de 36 segundos.
- [8.1/H-0-3] Troca de tarefas. Quando vários aplicativos já foram lançados, o que relançou após o lançamento PRECISA levar menos de um segundo.
Implementações de dispositivos portáteis:
- [8.2/H-0-1] PRECISA garantir uma sequência de gravação de pelo menos 5 MB/s.
- [8.2/H-0-2] PRECISA garantir que uma gravação aleatória e desempenho de pelo menos 0,5 MB/s.
- [8.2/H-0-3] PRECISA garantir uma leitura sequencial. e desempenho de pelo menos 15 MB/s.
- [8.2/H-0-4] PRECISA garantir uma leitura aleatória. e desempenho de pelo menos 3,5 MB/s.
Se as implementações de dispositivos portáteis incluírem recursos para melhorar a potência do dispositivo de código aberto incluídos no AOSP ou que ampliem os recursos incluídos no AOSP:
- [8.3/H-1-1] PRECISA fornecer recursos do usuário para ativar e desative o recurso de economia de bateria.
- [8.3/H-1-2] PRECISA fornecer affordance do usuário para exibir todos os apps isentos dos modos de economia de energia "App em espera" e "Soneca".
Implementações de dispositivos portáteis:
- [8.4/H-0-1] PRECISA fornecer uma perfil de energia por componente que define o valor de consumo atual para cada componente de hardware e o consumo aproximado da bateria causado pelo ao longo do tempo, conforme documentado no site do Android Open Source Project.
- [8.4/H-0-2] PRECISA informar toda a energia valores de consumo em milissegundos/hora (mAh).
- [8.4/H-0-3] PRECISA informar a energia da CPU
e consumo de acordo com o UID de cada processo. O Android Open Source Project atende à
requisito pela implementação do módulo do kernel
uid_cputime
. - [8.4/H-0-4] PRECISA fazer esse uso de energia
disponível no
adb shell dumpsys batterystats
shell para o desenvolvedor do app. - [8,4/H] DEVE ser atribuída ao componente de hardware em si, se não for possível atribuir o uso de energia do componente de hardware a um aplicativo.
Se as implementações de dispositivos portáteis incluírem uma saída de tela ou vídeo, elas:
- [8.4/H-1-1] PRECISA respeitar o
android.intent.action.POWER_USAGE_SUMMARY
e exibirá um menu de configurações que mostra esse consumo de energia.
Implementações de dispositivos portáteis:
- [8.5/H-0-1] PRECISA fornecer
uma funcionalidade do usuário
no menu "Configurações"para ver todos os apps com serviços em primeiro plano ativos ou iniciados pelo usuário, incluindo a duração de cada um desses serviços desde que começou como descrito no documento do SDK.e a capacidade de interromper um aplicativo que esteja executando um serviço em primeiro plano ou iniciado pelo usuário.com a capacidade de interromper um app que está executando um serviço em primeiro plano e exibir todos os apps que têm serviços em primeiro plano ativos e a duração de cada um esses serviços desde que começaram conforme descrito nos Documento do SDK.- Alguns apps PODEM estar isentos de serem interrompidos ou listados em uma dessas funcionalidade do usuário, conforme descrito no documento do SDK.
Iniciar novos requisitos
- [8.5/H-0-2]DEVE fornecer uma funcionalidade de usuário para interromper um app que está executando um serviço em primeiro plano ou um job iniciado pelo usuário.
Encerrar novos requisitos
2.2.5 Modelo de segurança
Implementações de dispositivos portáteis:
- [9/H-0-1] PRECISA declarar a
android.hardware.security.model.compatible
. - [9.1/H-0-1] PRECISA permitir que apps de terceiros acessem a
estatísticas de uso com a permissão
android.permission.PACKAGE_USAGE_STATS
e fornecer um mecanismo acessível ao usuário para conceder ou revogar o acesso a esses aplicativos em resposta aosandroid.settings.ACTION_USAGE_ACCESS_SETTINGS
intenção.
Iniciar novos requisitos
Se as implementações de dispositivos declararem suporte a android.hardware.telephony
:
eles:
- [9.5/H-1-1] NÃO PODE definir
UserManager.isHeadlessSystemUserMode
paratrue
.
Encerrar novos requisitos
Implementações de dispositivos portáteis:
- [9.11/H-0-2] PRECISA fazer backup da implementação de keystore. com um ambiente de execução isolado.
- [9.11/H-0-3] PRECISA ter implementações de RSA, AES, Algoritmos criptográficos ECDSA e HMAC e família MD5, SHA1 e SHA-2 para oferecer suporte adequado ao suporte do sistema Android Keystore algoritmos em uma área segura e isolada do código em execução kernel e acima. O isolamento seguro PRECISA bloquear todos os possíveis mecanismos. pelo qual o código do kernel ou do espaço do usuário pode acessar o estado interno da ambiente isolado, incluindo DMA. O Android Open Source upstream O Project (AOSP) atende a esse requisito usando a implementação Trusty, mas outra Solução baseada em ARM TrustZone ou uma solução verificada por terceiros como segura implementação de um isolamento adequado baseado em hipervisor são alternativas .
- [9.11/H-0-4] PRECISA executar a tela de bloqueio. no ambiente de execução isolado e somente ao bem-sucedido, permite o uso das chaves vinculadas à autenticação. Bloquear tela as credenciais PRECISAM ser armazenadas de uma forma que permita somente a execução isolada para executar a autenticação da tela de bloqueio. O sistema upstream do Android O Open Source Project oferece Camada de abstração de hardware (HAL) Gatekeeper e o Trusty, que podem ser usados para atender a esse requisito.
- [9.11/H-0-5] PRECISA oferecer suporte ao atestado de chaves em que o a chave de assinatura de atestado é protegida por um hardware seguro e a assinatura é executadas em hardware seguro. As chaves de assinatura de atestado PRECISAM ser compartilhadas em um número grande de dispositivos para impedir o uso das chaves como identificadores de dispositivo. Uma forma de atender a esse requisito é compartilhar o mesma chave de atestado,a menos que pelo menos 100.000 unidades de uma determinada SKU sejam produzidos. Se mais de 100.000 unidades de uma SKU forem produzidas, outro chave PODE ser usada para cada 100.000 unidades.
Se uma implementação de dispositivo já tiver sido iniciada em uma versão anterior
versão, tal dispositivo está isento da exigência de ter um keystore
em um ambiente de execução isolado e oferecem suporte ao atestado de chaves,
a menos que declare o recurso android.hardware.fingerprint
, que requer uma
um keystore apoiado por um ambiente de execução isolado.
Quando as implementações de dispositivos portáteis são compatíveis com uma tela de bloqueio segura, elas:
- [9.11/H-1-1] PRECISA permitir que o usuário escolha a menor tempo limite de suspensão, isto é, o tempo de transição entre o status desbloqueado como 15 segundos ou menos.
- [9.11/H-1-2] PRECISA fornecer funcionalidade ao usuário para ocultar notificações e desativar todas as formas de autenticação, exceto as autenticação principal descrita em 9.11.1 Tela de bloqueio segura. O AOSP atende como o modo de bloqueio total.
Iniciar novos requisitos
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.
Encerrar novos requisitos
Se as implementações de dispositivos portáteis incluírem vários usuários e
não declararem a flag de recurso android.hardware.telephony
, eles:
- [9.5/H-2-1] PRECISA oferecer suporte a perfis restritos, um recurso que permite que os proprietários de dispositivos gerenciem outros usuários e do dispositivo. Com perfis restritos, os proprietários de dispositivos podem configurar rapidamente ambientes separados para que outros usuários trabalhem, com a capacidade de gerenciar restrições mais refinadas nos apps disponíveis nesses ambientes.
Se as implementações de dispositivos portáteis incluírem vários usuários e
declararem a flag de recurso android.hardware.telephony
, eles:
- [9.5/H-3-1] NÃO PODE oferecer suporte a restrições perfis, mas PRECISA estar alinhada com a implementação de controles do AOSP para ativar ou desativar o acesso de outros usuários a chamadas de voz e SMS.
Iniciar novos requisitos
Se as implementações de dispositivos portáteis definirem UserManager.isHeadlessSystemUserMode
para true
, ele
- [9.5/H-4-1] NÃO PODE incluir suporte para eUICCs, nem para eSIMs com recurso de chamada.
- [9.5/H-4-2] NÃO PODE declarar suporte para
android.hardware.telephony
Encerrar novos requisitos
O Android, pela API do sistema, VoiceInteractionService oferece suporte a um mecanismo para detecção de hotword sempre ativada sem indicação de acesso ao microfone e detecção de consultas sempre ativada, sem microfone ou câmera indicação de acesso.
Se as implementações de dispositivos portáteis forem compatíveis com a API do sistema
HotwordDetectionService
ou outro mecanismo para detecção de hotwords sem
indicação de acesso ao microfone, eles:
- [9.8/H-1-1] PRECISA garantir que o serviço de detecção de hotword só possa transmitir
dados para o sistema,
ContentCaptureService
, ou um serviço de reconhecimento de falaSpeechRecognizer#createOnDeviceSpeechRecognizer()
. - [9.8/H-1-2] PRECISA garantir que o serviço de detecção de hotword só possa transmitir
dados de áudio do microfone ou derivados para o servidor do sistema por meio do
API
HotwordDetectionService
ou paraContentCaptureService
por APIContentCaptureManager
. - [9.8/H-1-3] NÃO PODE fornecer áudio de microfone com mais de 30 segundos para uma solicitação individual acionada por hardware para o serviço de detecção de hotwords.
- [9.8/H-1-4] NÃO PODE fornecer áudio de microfone em buffer com mais de 8 segundos para um solicitação individual para o serviço de detecção de hotwords.
- [9.8/H-1-5] NÃO PODE fornecer áudio de microfone em buffer com mais de 30 segundos ao um serviço de interação por voz ou entidade semelhante.
- [9.8/H-1-6] NÃO PODE permitir mais de 100 bytes de dados sejam transmitidos do serviço de detecção de hotword em cada resultado de hotword, exceto para dados de áudio transmitidos HotwordAudioStream (link em inglês).
- [9.8/H-1-7] NÃO PODE permitir a transmissão de mais de 5 bits de dados do serviço de detecção de hotword em cada resultado de hotword negativa.
- [9.8/H-1-8] PRECISA permitir apenas a transmissão de dados fora da hotword. de detecção em uma solicitação de validação de hotword do servidor do sistema.
- [9.8/H-1-9] NÃO PODE permitir que um aplicativo instalável pelo usuário forneça a serviço de detecção de hotword do Google.
- [9.8/H-1-10] NÃO PODE SER na interface do usuário dados quantitativos sobre o uso do microfone por o serviço de detecção de hotwords.
- [9.8/H-1-11] PRECISA registrar o número de bytes incluídos em cada transmissão do serviço de detecção de hotword para permitir a inspeção de segurança os pesquisadores.
- [9.8/H-1-12] PRECISA oferecer suporte a um modo de depuração que registre o conteúdo bruto de cada transmissão do serviço de detecção de hotword para permitir inspeção e pesquisadores de segurança.
- [9.8/H-1-14] PRECISA exibir o indicador de microfone, conforme descrito na seção. 9.8.2, quando um resultado de hotword bem-sucedido é transmitido para a rede serviço de interação ou entidade semelhante.
Iniciar novos requisitos
- [9.8/H-1-15] PRECISA garantir que os streams de áudio fornecidos com hotword bem-sucedida os resultados são transmitidos unidirecionalmente do serviço de detecção de hotword para o serviço de interação por voz.
Encerrar novos requisitos
- [9.8/H-SR-1] É FORTEMENTE RECOMENDADO que você notifique os usuários antes de definir uma aplicativo como o provedor do serviço de detecção de hotword.
- [9.8/H-SR-2] É FORTEMENTE RECOMENDADO para proibir a transmissão de e não estruturados do serviço de detecção de hotwords.
- [9.8/H-SR-3] É FORTEMENTE RECOMENDADO 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 horas; eventos acionadores de hardware, o que ocorrer primeiro.
Se as implementações de dispositivos incluem um aplicativo que usa a API do sistema
HotwordDetectionService
ou um mecanismo semelhante para detecção de hotwords sem
indicação de uso do microfone, o aplicativo:
- [9.8/H-2-1] PRECISA fornecer aviso explícito ao usuário para cada frase de hotword. suporte.
- [9.8/H-2-2] NÃO PODE preservar dados brutos de áudio ou dados derivados deles, por meio do serviço de detecção de hotwords.
- [9.8/H-2-3] NÃO PODE transmitir do serviço de detecção de hotword, áudio
dados que podem ser usados para reconstruir (total ou parcialmente) o áudio,
ou conteúdo de áudio não relacionado à hotword em si, exceto à
ContentCaptureService
ou fala no dispositivo serviço de reconhecimento de marca.
Iniciar novos requisitos
Se as implementações de dispositivos portáteis forem compatíveis com a API do sistema
VisualQueryDetectionService
ou outro mecanismo para detecção de consultas
sem indicação de acesso ao microfone e/ou à câmera, eles:
- [9.8/H-3-1] PRECISA garantir que o serviço de detecção de consultas só transmita
para o sistema, ou
ContentCaptureService
, ou fala no dispositivo de reconhecimento de marca (criado pelaSpeechRecognizer#createOnDeviceSpeechRecognizer()
). - [9.8/H-3-2] NÃO PODE permitir a transmissão de informações de áudio ou vídeo.
de
VisualQueryDetectionService
, exceto paraContentCaptureService
ou de reconhecimento de fala no dispositivo. - [9.8/H-3-3] PRECISA exibir um aviso na interface do sistema quando o dispositivo detecta o usuário intenção de interagir com o aplicativo de assistente digital (por exemplo, detectando presença do usuário pela câmera).
- [9.8/H-3-4] PRECISA exibir um indicador de microfone e exibir o consulta do usuário 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 a com o serviço de detecção de consultas visuais.
Encerrar novos requisitos
Se as implementações de dispositivos portáteis declararem android.hardware.microphone
, elas:
- [9.8.2/H-4-1] PRECISA exibir o indicador de microfone quando:
um aplicativo está acessando dados de áudio do microfone, mas não quando o
o microfone só é acessado por
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
ou apps com as funções chamadas na seção 9.1 com o identificador CDD [C-4-X]. - [9.8.2/H-4-2] PRECISA exibir a lista de itens recentes e ativos.
Apps que usam o microfone como retornado
PermissionManager.getIndicatorAppOpUsageData()
, com qualquer atribuição mensagens associadas a elas.
Se as implementações de dispositivos portáteis declararem android.hardware.camera.any
, elas:
- [9.8.2/H-5-1] PRECISA exibir o indicador da câmera quando um está acessando dados da câmera em tempo real, mas não quando ela está sendo acessado por aplicativos que detêm os papéis destacados seção 9.1 com o identificador CDD [C-4-X].
- [9.8.2/H-5-2] PRECISA exibir apps recentes e ativos usando o
câmera retornada de
PermissionManager.getIndicatorAppOpUsageData()
, além de mensagens de atribuição associadas.
2.2.6. Compatibilidade de opções e ferramentas para desenvolvedores
Implementações de dispositivos portáteis (* não aplicável a tablets):
- [6.1/H-0-1]* PRECISA oferecer suporte ao comando shell.
cmd testharness
Implementações de dispositivos portáteis (* não aplicável a tablets):
- Perfetto (link em inglês)
- [6.1/H-0-2]* PRECISA expor um
/system/bin/perfetto
. binário para o usuário do shell com o qual o cmdline obedece a documentação do perfetto. - [6.1/H-0-3]* O binário do perfetto PRECISA aceitar como: insira uma configuração protobuf que esteja em conformidade com o esquema definido em a documentação do perfetto.
- [6.1/H-0-4]* O binário do perfetto PRECISA ser escrito como gera um trace protobuf que segue o esquema definido em a documentação do perfetto.
- [6.1/H-0-5]* PRECISA fornecer, pelo perfetto binário, pelo menos as fontes de dados descritas na documentação do Perfeito.
- [6.1/H-0-6]* O daemon rastreado do perfetto PRECISA ser
ativada por padrão (propriedade do sistema
persist.traced.enable
).
- [6.1/H-0-2]* PRECISA expor um
2.2.7. Classe de desempenho de mídia portátil
Consulte a Seção 7.11 para ver a definição de classe de desempenho de mídia.
2.2.7.1 Mídia
Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.T
para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, eles:
- PRECISA atender aos requisitos de mídia listados na seção 2.2.7.1 do CDD do Android 13.
Iniciar novos requisitos
Se as implementações de dispositivos portáteis retornaremandroid.os.Build.VERSION_CODES.U
para
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, ele poderá fazer o seguinte:
- [5.1/H-1-1] PRECISA anunciar o número máximo de hardwares decodificadores de vídeo
sessões que podem ser executadas simultaneamente em qualquer combinação de codecs por meio do
CodecCapabilities.getMaxSupportedInstances()
eVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-2] PRECISA oferecer suporte a seis instâncias de decodificador de vídeo por hardware de 8 bits (SDR). sessões (AVC, HEVC, VP9, AV1 ou posteriores) em qualquer combinação de codec em execução concomitantemente com 3 sessões com resolução de 1080p a 30 fps e 3 sessões em 4K resolução a 30 fps, a menos que AV1 Os codecs AV1 só são necessários para oferecer suporte à resolução de 1080p, necessário para dar suporte a seis instâncias a 1080p30fps.
- [5.1/H-1-3] PRECISA anunciar o número máximo de hardwares de codificador
sessões que podem ser executadas simultaneamente em qualquer combinação de codecs por meio do
CodecCapabilities.getMaxSupportedInstances()
eVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-4] PRECISA oferecer suporte a seis instâncias de codificador de vídeo de hardware de 8 bits (SDR). sessões (AVC, HEVC, VP9, AV1 ou posteriores) em qualquer combinação de codec em execução ao mesmo tempo com 4 sessões em 1080p com resolução a 30 fps e 2 sessões em 4K resolução a 30 fps, a menos que AV1 Os codecs AV1 só são necessários para oferecer suporte à resolução de 1080p, necessário para dar suporte a seis instâncias a 1080p30fps.
- [5.1/H-1-5] PRECISA anunciar o número máximo de hardwares de codificador
sessões do decodificador que podem ser executadas simultaneamente em qualquer combinação de codecs por meio do
CodecCapabilities.getMaxSupportedInstances()
eVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-6] PRECISA oferecer suporte a seis instâncias de decodificador de vídeo por hardware de 8 bits (SDR). e sessões de codificador de vídeo em hardware (AVC, HEVC, VP9, AV1 ou superior) em qualquer combinação de codecs executada simultaneamente com três sessões a 4K a 30 fps (exceto AV1), sendo que no máximo 2 são sessões do codificador e 3 com resolução de 1080p. Os codecs AV1 só são necessários para oferecer suporte à resolução de 1080p, necessário para dar suporte a seis instâncias a 1080p30fps.
- [5.1/H-1-19] PRECISA oferecer suporte a três instâncias de decodificador de vídeo por hardware de 10 bits (HDR) e sessões de codificador de vídeo em hardware (AVC, HEVC, VP9, AV1 ou superior) em qualquer combinação de codecs executada simultaneamente a uma resolução de 4K a 30 fps (exceto AV1) e no máximo 1 é uma sessão de codificador, que pode ser configurada RGBA_1010102 usando uma superfície GL. Geração de metadados HDR por o codificador não é necessário ao codificar a partir da superfície GL. As sessões do codec AV1 só precisam oferecer suporte à resolução de 1080p, mesmo quando esse requisito exige 4K.
- [5.1/H-1-7] PRECISA ter uma latência de inicialização de codec de 40 ms ou menos para um 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 aqui é definido como um vídeo simultâneo de 1080p a 720p sessão de transcodificação usando codecs de vídeo de hardware junto com a inicialização de gravação de áudio e vídeo. Para o codec Dolby Vision, a latência de inicialização 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 um Sessão de codificação de áudio com taxa de bits de 128 kbps ou menor para todos os codificadores de áudio quando sob carga. O carregamento aqui é definido como um vídeo simultâneo de 1080p a 720p sessão de transcodificação usando codecs de vídeo de hardware junto com a e inicialização de gravação de áudio e vídeo.
- [5.1/H-1-9] PRECISA oferecer suporte a duas instâncias de decodificador de vídeo por hardware seguro sessões (AVC, HEVC, VP9, AV1 ou posteriores) em qualquer combinação de codec em execução simultaneamente com resolução de 4k a 30 fps (exceto AV1) para 8 bits (SDR) e Conteúdo HDR de 10 bits. As sessões do codec AV1 só precisam oferecer suporte à resolução de 1080p, mesmo quando esse requisito exige 4K.
- [5.1/H-1-10] PRECISA oferecer suporte a três instâncias de decodificador de vídeo por hardware não seguro sessões com 1 instância de sessão de decodificador de vídeo por hardware seguro (4 instâncias no total) (AVC, HEVC, VP9, AV1 ou posterior) em qualquer combinação de codecs em execução simultaneamente a três sessões com resolução 4K a 30 fps (exceto AV1) que inclui uma sessão de decodificador segura e uma sessão não segura em 1080p resolução a 30 fps, sendo que no máximo 2 sessões podem estar em HDR de 10 bits. As sessões do codec AV1 só precisam oferecer suporte à resolução de 1080p, mesmo quando esse requisito exige 4K.
- [5.1/H-1-11] PRECISA oferecer suporte a um decodificador seguro para cada hardware AVC, HEVC, Decodificador 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 um Sessão de decodificação de vídeo de 1080p ou menor para todos os decodificadores de vídeo de hardware sob carga. O carregamento é definido como um volume de 1080p a 720p simultâneo sessão de transcodificação somente de vídeo usando codecs de vídeo de hardware com o Inicialização da reprodução de áudio e vídeo em 1080p. Para o codec Dolby Vision, a latência de inicialização 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 um Sessão de decodificação de áudio com taxa de bits de 128 kbps ou menor para todos os decodificadores de áudio quando sob carga. O carregamento aqui é definido como um vídeo simultâneo de 1080p a 720p sessão de transcodificação usando codecs de vídeo de hardware junto com a e a inicialização da reprodução de áudio e vídeo.
- [5.1/H-1-14] PRECISA ser compatível com o decodificador de hardware AV1 Main 10, Level 4.1 e film grãos
- [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 SER eliminado mais de 1 frame em 10 segundos (ou seja, menos de 0,167% de queda do quadro) para uma sessão de vídeo 4K de 60 fps sob carregamento.
- [5.3/H-1-2] NÃO PODE cair mais de 1 frame em 10 segundos durante um vídeo. mudança da resolução em uma sessão de vídeo de 60 QPS sob carga 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 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 em pelo menos um caminho de dados com suporte.
- [5.6/H-1-3] PRECISA oferecer suporte a áudio de pelo menos 24 bits para saída estéreo de áudio com mais de 3,5 mm.
Entradas, se presente, e via áudio USB, se compatível com todos os dados
para configurações de baixa latência e de streaming. Para a baixa latência
a AAudio deve ser usada pelo app em um callback de baixa latência
modo Para a configuração de streaming, um AudioTrack Java deve ser usado por
o app. Nas configurações de baixa latência e de streaming, a HAL
o coletor de saída deve aceitar
AUDIO_FORMAT_PCM_24_BIT
,AUDIO_FORMAT_PCM_24_BIT_PACKED
,AUDIO_FORMAT_PCM_32_BIT
ouAUDIO_FORMAT_PCM_FLOAT
para o formato de saída de destino. - [5.6/H-1-4] PRECISA oferecer suporte a dispositivos de áudio USB com mais de 4 canais usados por DJs. controles para visualizar as músicas.
- [5.6/H-1-5] PRECISA oferecer suporte a dispositivos MIDI compatíveis com a classe e declarar os Sinalização de recurso MIDI.
- [5.6/H-1-9] PRECISA oferecer suporte a pelo menos 12 mixes de canais. Isso implica que abrir uma faixa de áudio com máscara de canal 7.1.4 e abrir corretamente espacializar ou fazer downmix de todos os canais para estéreo.
- [5.6/H-SR] É FORTEMENTE RECOMENDADO para oferecer suporte a 24 canais de mix com oferecer suporte mínimo às 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 o abaixo dos recursos de descriptografia de conteúdo.
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 ) | 6 |
Tamanho da mensagem | 16 KiB |
Frames descriptografados por segundo | 60 QPS |
- [5.1/H-1-17] PRECISA ter pelo menos um decodificador de imagem de hardware compatível com AVIF Perfil de referência.
- [5.1/H-1-18] PRECISA oferecer suporte ao codificador AV1, que pode codificar até 480p a 30 fps e 1 Mbps.
[5.12/H-1-1] PRECISA[5.12/H-SR] São altamente recomendadas para oferecer suporte aoFeature_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 hardwares AV1 e Codificadores HEVC presentes no dispositivo.
- [5.12/H-1-3] PRECISA anunciar o suporte para a extensão EXT_YUV_target em amostra de texturas YUV em 8 e 10 bits.
- [7.1.4/H-1-1] PRECISA ter pelo menos seis sobreposições de hardware no processamento da tela. (DPU), com pelo menos dois deles capazes de exibir conteúdo de vídeo de 10 bits.
Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.U
para
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
e eles incluem
para um codificador AVC ou HEVC de hardware, eles:
- [5.2/H-2-1] PRECISA atender à meta mínima de qualidade definida pelo vídeo. curvas de distorção da taxa do codificador para codecs AVC e HEVC de hardware, conforme definido em Executar testes de classe de desempenho 14 (PC14): qualidade de codificação de vídeo (VEQ, na sigla em inglês).
Encerrar novos requisitos
2.2.7.2 Câmera
Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.T
para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, eles:
- PRECISA atender aos requisitos de mídia listados na seção 2.2.7.2 do CDD do Android 13.
Iniciar novos requisitos
Se as implementações de dispositivos portáteis retornaremandroid.os.Build.VERSION_CODES.U
para
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, ele poderá fazer o seguinte:
- [7.5/H-1-1] PRECISA ter uma câmera traseira principal com resolução de no mínimo no mínimo 12 megapixels com suporte para captura de vídeo a 4k a 30 fps. O principal que é 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 no mínimo no mínimo 6 megapixels e suporte a captura de vídeo a 1080p a 30 fps. O principal A câmera frontal é a frontal com o menor ID de câmera.
- [7.5/H-1-3] PRECISA oferecer suporte à propriedade
android.info.supportedHardwareLevel
comoFULL
ou melhor para a instância principal secundária eLIMITED
ou melhor para a principal principal câmera. - [7.5/H-1-4] PRECISA ser compatível.
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
para as contas principais câmeras. - [7.5/H-1-5] PRECISA ter a latência de captura JPEG da camera2 < 1.000
900ms para resolução de 1080p, conforme medido pelo PerformanceTest da câmera CTS em Condições de iluminação ITS (3.000K) para ambas as câmeras principais. - [7.5/H-1-6] PRECISA ter a latência de inicialização da câmera2 (abrir a câmera para a primeira visualização) frame) < 500 ms, medido pelo PerformanceTest da câmera CTS de acordo com o ITS. condições de iluminação (3.000K) para as duas câmeras principais.
- [7.5/H-1-8] PRECISA oferecer suporte a
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW
. eandroid.graphics.ImageFormat.RAW_SENSOR
para a câmera traseira principal. - [7.5/H-1-9] PRECISA ter uma câmera principal traseira compatível com 720p ou 1080p a 240 fps.
- [7.5/H-1-10] PRECISA ter ZOOM_RATIO mínimo < 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 o streaming front-back simultâneo na rede principal. câmeras.
- [7.5/H-1-12] PRECISA ser compatível.
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
para as contas principais câmera frontal e traseira principal. - [7.5/H-1-13] PRECISA oferecer suporte ao recurso
LOGICAL_MULTI_CAMERA
. para a câmera traseira principal se houver mais de uma imagem câmeras traseiras. - [7.5/H-1-14] PRECISA oferecer suporte ao recurso
STREAM_USE_CASE
para as contas principais câmera frontal e traseira principal. - [7.5/H-1-15] PRECISA oferecer suporte a
Bokeh eExtensões do Modo noturno pelas extensões CameraX e Camera2 para principais câmeras. - [7.5/H-1-16] PRECISA oferecer suporte ao recurso DYNAMIC_RANGE_TEN_BIT para a instância principal. câmeras.
- [7.5/H-1-17] PRECISA ser compatível com 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.
Encerrar novos requisitos
2.2.7.3 Hardware
Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.T
para
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, ele poderá fazer o seguinte:
- PRECISA atender aos requisitos de mídia listados na seção 2.2.7.3 do CDD do Android 13.
Iniciar novos requisitos
Se as implementações de dispositivos portáteis retornaremandroid.os.Build.VERSION_CODES.U
para
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, ele poderá fazer o seguinte:
- [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 de pelo menos 1.000 nits. média.
- [7.6.1/H-2-1] PRECISA ter pelo menos 8 GB de memória física.
Encerrar novos requisitos
2.2.7.4 Desempenho
Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.T
para
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, ele poderá fazer o seguinte:
- PRECISA atender aos requisitos de desempenho listados na seção 2.2.7.4 do CDD do Android 13.
Iniciar novos requisitos
Se as implementações de dispositivos portáteis retornaremandroid.os.Build.VERSION_CODES.U
para
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, ele poderá fazer o seguinte:
- [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 2x de leitura e 1x de gravação de pelo menos 50 MB/s.
Encerrar novos requisitos
2.3. Requisitos para televisão
Um dispositivo Android Television é uma implementação de dispositivo Android que é uma interface de entretenimento para consumo de mídia digital, filmes, jogos, aplicativos, e/ou TV ao vivo para usuários sentados a cerca de três metros de distância do BigQuery).
As implementações de dispositivos Android serão classificadas como Televisão se atenderem a todos os seguintes critérios:
- Forneceu um mecanismo para controlar remotamente a interface do usuário renderizada em a tela que pode ficar a três metros de distância do usuário.
- Ter uma tela incorporada com comprimento diagonal maior que 24 OU incluir uma porta de saída de vídeo, como VGA, HDMI, DisplayPort ou porta sem fio para display.
Os requisitos adicionais no restante desta seção são específicos para o Android Implementações de dispositivos de televisão.
2.3.1 Hardware
Implementações de dispositivos de televisão:
- [7.2.2/T-0-1] PRECISA oferecer suporte ao D-pad.
- [7.2.3/T-0-1] PRECISA fornecer o Home e o Back .
- [7.2.3/T-0-2] PRECISA enviar os comandos normal e longo
Evento da função Voltar (
KEYCODE_BACK
) para o aplicativo em primeiro plano. - [7.2.6.1/T-0-1] PRECISA incluir suporte a jogos
e declarar a flag de recurso
android.hardware.gamepad
. - [7.2.7/T] DEVE fornecer um controle remoto que os usuários podem acessar a navegação sem toque e teclas de navegação principais.
Se as implementações de dispositivos de televisão incluírem um giroscópio de três eixos, elas:
- [7.3.4/T-1-1] PRECISA relatar eventos de até uma de pelo menos 100 Hz.
- [7.3.4/T-1-2] PRECISA ser capaz de medir mudanças de orientação. até 1.000 graus por segundo.
Implementações de dispositivos de televisão:
- [7.4.3/T-0-1] PRECISA ser compatível com Bluetooth e Bluetooth LE
- [7.6.1/T-0-1] PRECISA ter pelo menos 4 GB de armazenamento não volátil disponível para dados privados de aplicativos (também conhecida como partição "/data").
Se as implementações de dispositivos de televisão incluírem uma porta USB compatível com o modo host, eles:
- [7.5.3/T-1-1] PRECISA incluir suporte a uma câmera externa. que se conecta por essa porta USB, mas que não está necessariamente sempre conectada.
Se as implementações de dispositivos de TV forem de 32 bits:
[7.6.1/T-1-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 896 MB se qualquer uma das densidades a seguir for usada:
- 400 dpi ou mais em telas pequenas/normais
- xhdpi ou maior em telas grandes
- tvdpi ou maior em telas muito grandes
Se as implementações de dispositivos de TV forem de 64 bits:
[7.6.1/T-2-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 1.280 MB se alguma das densidades a seguir for usado:
- 400 dpi ou mais em telas pequenas/normais
- xhdpi ou maior em telas grandes
- tvdpi ou maior em telas muito grandes
Observe que a "memória disponível para o kernel e o espaço do usuário" acima refere-se à o espaço na memória é fornecido além das memórias dedicados a componentes de hardware, como rádio, vídeo etc., que não são sob o controle do kernel sobre implementações de dispositivos.
Implementações de dispositivos de televisão:
- [7.8.1/T] PRECISA incluir um microfone.
- [7.8.2/T-0-1] PRECISA ter uma saída de áudio e declarar
android.hardware.audio.output
2.3.2 Multimídia
As implementações de dispositivos de televisão PRECISAM ser compatíveis com a seguinte codificação de áudio: e decodificação e disponibilizá-los para aplicativos de terceiros:
- [5.1/T-0-1] Perfil AAC MPEG-4 (AAC LC)
- [5.1/T-0-2] Perfil MPEG-4 HE AAC (AAC+)
- [5.1/T-0-3] AAC ELD (AAC com atraso baixo aprimorado)
As implementações de dispositivos de televisão PRECISAM ser compatíveis com a seguinte codificação de vídeo formatos e disponibilizá-los para aplicativos de terceiros:
Implementações de dispositivos de televisão:
- [5.2.2/T-SR-1] É FORTEMENTE RECOMENDADO para o suporte Codificação H.264 de vídeos com resolução de 720p e 1080p a 30 quadros por segundo.
As implementações de dispositivos de televisão PRECISAM ser compatíveis com a seguinte decodificação de vídeo formatos e disponibilizá-los para aplicativos de terceiros:
- [5.3.3/T-0-1] MPEG-4 SP
- [5.3.4/T-0-2] H.264 AVC
- [5.3.5/T-0-3] H.265 HEVC
- [5.3.6/T-0-4] VP8
- [5.3.7/T-0-5] VP9
- [5.3.1/T-0-6] MPEG-2
Implementações de dispositivos de televisão PRECISAM ser compatíveis com a decodificação MPEG-2, conforme detalhado em Seção 5.3.1, com frame rates e resoluções padrão de vídeo incluindo:
- [5.3.1/T-1-1] HD 1080p a 29,97 quadros por segundo com o alto nível do perfil principal.
- [5.3.1/T-1-2] HD 1080i a 59,94 quadros por segundo com o alto nível do perfil principal. É NECESSÁRIO remover o entrelaçamento dos vídeos MPEG-2 e disponibilizá-los para aplicativos de terceiros.
Implementações de dispositivos de televisão PRECISAM oferecer suporte à decodificação H.264, conforme detalhado em Seção 5.3.4, com frame rates e resoluções padrão de vídeo de até incluindo:
- [5.3.4/T-1-1] HD 1080p a 60 quadros por segundo com Perfil de referência
- [5.3.4/T-1-2] HD 1080p a 60 quadros por segundo com Perfil principal
- [5.3.4/T-1-3] HD 1080p a 60 quadros por segundo com Alto nível 4.2
Implementações de dispositivos de televisão com decodificadores de hardware H.265 PRECISAM ser compatíveis com Decodificação H.265, conforme detalhado na Seção 5.3.5, com frame rates padrão de vídeo e resoluções até, inclusive:
- [5.3.5/T-1-1] HD 1080p a 60 quadros por segundo com Nível 4.1 do perfil principal
Se as implementações de dispositivos de televisão com decodificadores de hardware H.265 forem compatíveis decodificação H.265 e o perfil de decodificação UHD, eles:
- [5.3.5/T-2-1] PRECISA ser compatível com o perfil de decodificação UHD. a 60 quadros por segundo com o perfil de nível 5 Main10 de nível 5
As implementações de dispositivos de televisão PRECISAM ser compatíveis com a decodificação VP8, conforme detalhado em Seção 5.3.6, com frame rates e resoluções padrão de vídeo de até incluindo:
- [5.3.6/T-1-1] HD de 1080p com perfil de decodificação de 60 quadros por segundo
Implementações de dispositivos de televisão com decodificadores de hardware VP9 PRECISAM ser compatíveis com esse padrão. decodificação, conforme detalhado na Seção 5.3.7, com frame rates e resoluções, incluindo:
- [5.3.7/T-1-1] HD 1080p a 60 quadros por segundo com perfil 0 (profundidade de cor de 8 bits)
Se as implementações de dispositivos de televisão com decodificadores de hardware VP9 oferecerem suporte a VP9 decodificação e o perfil de decodificação UHD, eles:
- [5.3.7/T-2-1] PRECISA ser compatível com o perfil de decodificação UHD. a 60 quadros por segundo com perfil 0 (profundidade de cor de 8 bits).
- [5.3.7/T-SR1] É FORTEMENTE RECOMENDADO para oferecer suporte à Perfil de decodificação UHD a 60 quadros por segundo com perfil 2 (profundidade de cor de 10 bits).
Implementações de dispositivos de televisão:
- [5.5/T-0-1] PRECISA incluir suporte ao mestre do sistema. Atenuação do volume e da saída de áudio digital em saídas compatíveis exceto para saída de passagem de áudio compactada, em que nenhuma decodificação de áudio é feita no dispositivo).
Se as implementações de dispositivos de televisão não tiverem um monitor integrado, mas compatíveis com um monitor externo conectado por HDMI, eles:
- [5.8/T-0-1] PRECISA configurar o HDMI
o modo de saída para a resolução mais alta do formato de pixel escolhido
com taxa de atualização de 50 ou 60 Hz para a tela externa, dependendo do tipo de
a taxa de atualização da região em que o dispositivo é vendido.
PRECISA definir o modo de saída HDMI como selecione a resolução máxima compatível com 50 Hz ou 60 Hz a taxa de atualização. - [5.8/T-SR-1] É FORTEMENTE RECOMENDADO para fornecer a um usuário seletor configurável de taxa de atualização HDMI.
- [5.8] DEVE definir a taxa de atualização do modo de saída HDMI para 50 Hz ou 60 Hz, dependendo da taxa de atualização de vídeo da região da dispositivo é vendido.
Se as implementações de dispositivos de televisão não tiverem um monitor integrado, mas compatíveis com um monitor externo conectado por HDMI, eles:
- [5.8/T-1-1] PRECISA oferecer suporte a HDCP 2.2.
Se as implementações de dispositivos de televisão não suportarem a decodificação UHD, mas oferecem suporte a uma tela externa conectada por HDMI, eles:
- [5.8/T-2-1] PRECISA oferecer suporte a HDCP 1.4.
2.3.3 Software
Implementações de dispositivos de televisão:
- [3/T-0-1] PRECISA declarar os recursos
android.software.leanback
eandroid.hardware.type.television
. - [3.2.3.1/T-0-1] PRECISA pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents para todos padrões de filtro de intent pública definidos pelas seguintes intents de aplicativo listados aqui.
- [3.4.1/T-0-1] PRECISA fornecer um
implementação da API
android.webkit.Webview
.
Se as implementações de dispositivos Android Television oferecerem suporte a uma tela de bloqueio,elas:
- [3.8.10/T-1-1] PRECISA exibir a fechadura Notificações da tela, incluindo o Modelo de notificação de mídia.
Implementações de dispositivos de televisão:
- [3.8.14/T-SR-1] São FORTEMENTE RECOMENDADOS para oferecer suporte ao modo picture-in-picture (PIP) de várias janelas.
- [3.10/T-0-1] PRECISA ser compatível com acessibilidade de terceiros. serviços.
- [3.10/T-SR-1] É FORTEMENTE RECOMENDADO para pré-carregar serviços de acessibilidade no dispositivo comparáveis ou superiores do acesso com interruptor e do TalkBack (para os idiomas compatíveis com os serviços de acessibilidade do mecanismo de conversão de texto em voz pré-instalados) conforme fornecido o projeto de código aberto TalkBack.
Se as implementações de dispositivos de televisão informarem o recurso
android.hardware.audio.output
, eles:
- [3.11/T-SR-1] É FORTEMENTE RECOMENDADO a inclusão de um Mecanismo de TTS com suporte para os idiomas disponíveis no dispositivo.
- [3.11/T-1-1] PRECISA ser compatível com a instalação do mecanismos TTS de terceiros.
Implementações de dispositivos de televisão:
- [3.12/T-0-1] PRECISA oferecer suporte ao TV Input Framework.
2.3.4 Desempenho e potência
- [8.1/T-0-1] Latência de frame consistente. Latência de frame inconsistente ou um atraso na renderização de frames NÃO PODEM acontecer com mais frequência geralmente que 5 quadros por segundo e DEVE estar abaixo de 1 quadros por segundo.
- [8.2/T-0-1] PRECISA garantir uma sequência e um desempenho de gravação de pelo menos 5 MB/s.
- [8.2/T-0-2] PRECISA garantir que uma gravação aleatória desempenho de pelo menos 0,5 MB/s.
- [8.2/T-0-3] PRECISA garantir uma sequência desempenho de leitura mínimo de 15 MB/s.
- [8.2/T-0-4] PRECISA garantir uma leitura aleatória. e desempenho de pelo menos 3,5 MB/s.
Se as implementações de dispositivos de televisão incluírem recursos para melhorar a potência do dispositivo de código aberto incluídos no AOSP ou que ampliem os recursos incluídos no AOSP:
- [8.3/T-1-1] PRECISA fornecer recursos do usuário para ativar e desative o recurso de economia de bateria.
Se as implementações de dispositivos de televisão não tiverem uma bateria, elas:
- [8.3/T-1-2] PRECISA registrar o dispositivo como um dispositivo sem bateria, conforme descrito em Suporte a dispositivos sem bateria.
Se as implementações de dispositivos de televisão tiverem uma bateria, elas:
- [8.3/T-1-3] PRECISA fornecer funcionalidade do usuário para exibir todos os apps isentos dos modos de economia de energia "App em espera" e "Soneca".
Implementações de dispositivos de televisão:
- [8.4/T-0-1] PRECISA fornecer uma perfil de energia por componente que define o valor de consumo atual para cada componente de hardware e o consumo aproximado da bateria causado pelo ao longo do tempo, conforme documentado no site do Android Open Source Project.
- [8.4/T-0-2] PRECISA informar toda a energia valores de consumo em milissegundos/hora (mAh).
- [8.4/T-0-3] PRECISA informar a energia da CPU.
e consumo de acordo com o UID de cada processo. O Android Open Source Project atende à
requisito pela implementação do módulo do kernel
uid_cputime
. - [8.4/T] DEVE ser atribuída ao componente de hardware em si, se não for possível atribuir o uso de energia do componente de hardware a um aplicativo.
- [8.4/T-0-4] PRECISA fazer esse uso de energia
disponível no
adb shell dumpsys batterystats
shell para o desenvolvedor do app.
2.3.5 Modelo de segurança
Implementações de dispositivos de televisão:
- [9/T-0-1] PRECISA declarar o
android.hardware.security.model.compatible
. - [9.11/T-0-1] PRECISA fazer backup da implementação de keystore. com um ambiente de execução isolado.
- [9.11/T-0-2] PRECISA ter implementações de RSA, AES, Algoritmos criptográficos ECDSA e HMAC e família MD5, SHA1 e SHA-2 para oferecer suporte adequado ao suporte do sistema Android Keystore algoritmos em uma área segura e isolada do código em execução kernel e acima. O isolamento seguro PRECISA bloquear todos os possíveis mecanismos. pelo qual o código do kernel ou do espaço do usuário pode acessar o estado interno da ambiente isolado, incluindo DMA. O Android Open Source upstream O Project (AOSP) atende a esse requisito usando a implementação Trusty, mas outra Uma solução baseada em ARM TrustZone ou uma solução verificada por terceiros como segura a implementação adequada de um isolamento baseado em hipervisor são alternativas .
- [9.11/T-0-3] PRECISA executar a tela de bloqueio. no ambiente de execução isolado e somente ao bem-sucedido, permite o uso das chaves vinculadas à autenticação. Bloquear tela as credenciais PRECISAM ser armazenadas de uma forma que permita somente a execução isolada para executar a autenticação da tela de bloqueio. O sistema upstream do Android O Open Source Project oferece Camada de abstração de hardware (HAL) Gatekeeper e o Trusty, que podem ser usados para atender a esse requisito.
- [9.11/T-0-4] PRECISA oferecer suporte ao atestado de chaves em que o a chave de assinatura de atestado é protegida por um hardware seguro e a assinatura é executadas em hardware seguro. As chaves de assinatura de atestado PRECISAM ser compartilhadas em um número grande de dispositivos para impedir o uso das chaves como identificadores de dispositivo. Uma forma de atender a esse requisito é compartilhar o mesma chave de atestado,a menos que pelo menos 100.000 unidades de uma determinada SKU sejam produzidos. Se mais de 100.000 unidades de uma SKU forem produzidas, outro chave PODE ser usada para cada 100.000 unidades.
Se uma implementação de dispositivo já tiver sido iniciada em uma versão anterior
versão, tal dispositivo está isento da exigência de ter um keystore
em um ambiente de execução isolado e oferecem suporte ao atestado de chaves,
a menos que declare o recurso android.hardware.fingerprint
, que requer uma
um keystore apoiado por um ambiente de execução isolado.
Se as implementações de dispositivos de televisão forem compatíveis com uma tela de bloqueio segura, elas:
- [9.11/T-1-1] PRECISA permitir que o usuário escolha a opção Sono tempo limite para a transição do estado desbloqueado para o bloqueado, com um o tempo limite mínimo permitido é de até 15 segundos.
Se as implementações de dispositivos de televisão incluírem vários usuários e
não declararem a flag de recurso android.hardware.telephony
, eles:
- [9.5/T-2-1] PRECISA oferecer suporte a perfis restritos, um recurso que permite que os proprietários de dispositivos gerenciem outros usuários e do dispositivo. Com perfis restritos, os proprietários de dispositivos podem configurar rapidamente ambientes separados para que outros usuários trabalhem, com a capacidade de gerenciar restrições mais refinadas nos apps disponíveis nesses ambientes.
Se as implementações de dispositivos de televisão incluírem vários usuários e
declararem a flag de recurso android.hardware.telephony
, eles:
- [9.5/T-3-1] NÃO PODE oferecer suporte a restrições perfis, mas PRECISA estar alinhada com a implementação de controles do AOSP para ativar ou desativar o acesso de outros usuários a chamadas de voz e SMS.
Se as implementações de dispositivos de televisão declararem android.hardware.microphone
, elas:
- [9.8.2/T-4-1] PRECISA exibir o indicador de microfone quando: um aplicativo está acessando dados de áudio do microfone, mas não quando o microfone só é acessado pelo HotwordDetectionService, SOURCE_HOTword, ContentCaptureService ou os apps que detêm as funções mencionadas na Seção 9.1 Permissões com identificador CDD C-3-X].
- [9.8.2/T-4-2] NÃO PODE ocultar o indicador de microfone para apps do sistema com interfaces do usuário visíveis ou interação direta com o usuário.
Se as implementações de dispositivos de televisão declararem android.hardware.camera.any
, elas:
- [9.8.2/T-5-1] PRECISA exibir o indicador da câmera quando um está acessando os dados da câmera em tempo real, mas não quando ela está sendo acessados por aplicativos que detêm os papéis mencionados na Seção 9.1 Permissões com identificador CDD [C-3-X].
- [9.8.2/T-5-2] NÃO PODE ocultar o indicador da câmera para apps do sistema com interfaces do usuário visíveis ou interação direta com o usuário.
2.3.6. Compatibilidade de opções e ferramentas para desenvolvedores
Implementações de dispositivos de televisão:
- Perfetto (link em inglês)
- [6.1/T-0-1] PRECISA expor um
/system/bin/perfetto
. binário para o usuário do shell com o qual o cmdline obedece a documentação do perfetto. - [6.1/T-0-2] O binário do perfetto PRECISA ser aceito como insira uma configuração protobuf que esteja em conformidade com o esquema definido em a documentação do perfetto.
- [6.1/T-0-3] O binário do perfetto PRECISA ser escrito como gera um trace protobuf que cumpre o esquema definido em a documentação do perfetto.
- [6.1/T-0-4] PRECISA fornecer, pelo perfetto. binário, pelo menos as fontes de dados descritas na documentação do Perfeito.
- [6.1/T-0-1] PRECISA expor um
2.4. Requisitos do relógio
Um dispositivo Android Watch é uma implementação de dispositivo Android destinada a: ser usado no corpo, talvez no pulso.
As implementações de dispositivos Android serão classificadas como Watch se atenderem a todos os seguintes critérios:
- Ter uma tela com o comprimento diagonal físico de 1,1 a 2,5 polegadas.
- Ter um mecanismo para ser usado no corpo.
Os requisitos adicionais no restante desta seção são específicos para o Android Relógios de implementações de dispositivos.
2.4.1. Hardware
Implementações de dispositivos de smartwatches:
[7.1.1.1/W-0-1] PRECISA ter uma tela com o tamanho diagonal físico no intervalo de 1,1 a 2,5 polegadas.
[7.2.3/W-0-1] PRECISA ter a função Home disponível ao usuário e a função Voltar, exceto quando estiver em
UI_MODE_TYPE_WATCH
.[7.2.4/W-0-1] PRECISA oferecer suporte à entrada touchscreen.
[7.3.1/W-SR-1] É MUITO RECOMENDADO a inclusão de um eixo acelerômetro.
Iniciar novos requisitos
Se as implementações de dispositivos Watch incluírem suporte ao Vulkan, elas vão:
- [7.1.4.2/W-1-1] PRECISA atender aos requisitos. especificados pelo perfil de referência do Android 2021.
Encerrar novos requisitos
Se as implementações do dispositivo Watch incluírem um receptor GPS/GNSS e informarem o
aos aplicativos pelo recurso android.hardware.location.gps
ele:
- [7.3.3/W-1-1] PRECISA informar as medições do GNSS assim que elas forem encontrados, mesmo que uma localização calculada a partir de GPS/GNSS ainda não tenha sido relatada.
- [7.3.3/W-1-2] PRECISA informar as pseudodistâncias e pseudodistâncias do GNSS. em condições de céu aberto após a determinação do local, enquanto parado ou em movimento com menos de 0,2 metro por segundo ao quadrado de são suficientes para calcular uma posição dentro de 20 metros, e a velocidade em 0,2 metro por segundo, pelo menos 95% do tempo.
Se as implementações de dispositivos Watch incluírem um giroscópio de três eixos, elas:
- [7.3.4/W-2-1] PRECISA ser capaz de medir mudanças de orientação. até 1.000 graus por segundo.
Implementações de dispositivos de smartwatches:
O [7.4.3/W-0-1] PRECISA ser compatível com Bluetooth.
[7.6.1/W-0-1] PRECISA ter pelo menos 1 GB de espaço armazenamento não volátil disponível para dados privados do aplicativo (também conhecido como partição "/data").
[7.6.1/W-0-2] PRECISA ter pelo menos 416 MB de memória disponíveis para o kernel e o espaço do usuário.
[7.8.1/W-0-1] PRECISA incluir um microfone.
[7.8.2/W] PODE ter saída de áudio.
2.4.2. Multimídia
Nenhum requisito extra.
2.4.3. Software
Implementações de dispositivos de smartwatches:
- [3/W-0-1] PRECISA declarar o recurso
android.hardware.type.watch
- [3/W-0-2] PRECISA oferecer suporte a uiMode = UI_MODE_TYPE_ASSIST.
- [3.2.3.1/W-0-1] PRECISA pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents, para todos os padrões de filtro de intent pública definidos pelo seguinte aplicativo intents listadas aqui.
Implementações de dispositivos de smartwatches:
- [3.8.4/W-SR-1] São FORTEMENTE RECOMENDADOS para implementar um assistente no dispositivo e processar a ação de assistência.
Assistir implementações de dispositivos que declaram o android.hardware.audio.output
flag de recurso:
- [3.10/W-1-1] PRECISA ser compatível com acessibilidade de terceiros. serviços.
- [3.10/W-SR-1] É FORTEMENTE RECOMENDADO o pré-carregamento serviços de acessibilidade no dispositivo comparáveis com funcionalidades superiores ou iguais a elas do acesso com interruptor e do TalkBack (para os idiomas compatíveis com os recursos mecanismo de conversão de texto em voz) fornecidos pelo projeto de código aberto do TalkBack.
Se as implementações de dispositivos Watch relatarem o recurso android.hardware.audio.output, eles:
[3.11/W-SR-1] É FORTEMENTE RECOMENDADO a inclusão de um Mecanismo de TTS com suporte para os idiomas disponíveis no dispositivo.
[3.11/W-0-1] PRECISA ser compatível com a instalação do mecanismos TTS de terceiros.
2.4.4 Desempenho e potência
Se as implementações de dispositivos Watch incluem recursos para melhorar a energia do dispositivo de código aberto incluídos no AOSP ou que ampliem os recursos incluídos no AOSP:
- [8.3/W-SR-1] É FORTEMENTE RECOMENDADO fornecer funcionalidade do usuário para exibir todos os apps isentos do App em espera e Modos de economia de energia do Soneca.
- [8.3/W-SR-2] É FORTEMENTE RECOMENDADO fornecer funcionalidade do usuário para ativar e desativar o recurso de economia de bateria.
Implementações de dispositivos de smartwatches:
- [8.4/W-0-1] PRECISA fornecer uma perfil de energia por componente que define o valor de consumo atual para cada componente de hardware e o consumo aproximado da bateria causado pelo ao longo do tempo, conforme documentado no site do Android Open Source Project.
- [8.4/W-0-2] PRECISA informar toda a energia valores de consumo em milissegundos/hora (mAh).
- [8.4/W-0-3] PRECISA informar a potência da CPU
e consumo de acordo com o UID de cada processo. O Android Open Source Project atende à
requisito pela implementação do módulo do kernel
uid_cputime
. - [8.4/W-0-4] PRECISA fazer esse uso de energia
disponível no
adb shell dumpsys batterystats
shell para o desenvolvedor do app. - [8.4/W] DEVE ser atribuída ao componente de hardware em si, se não for possível atribuir o uso de energia do componente de hardware a um aplicativo.
2.4.5. Modelo de segurança
Implementações de dispositivos de smartwatches:
- [9/W-0-1] PRECISA declarar a
android.hardware.security.model.compatible
.
Se as implementações de dispositivos Watch incluem vários usuários e
não declararem a flag de recurso android.hardware.telephony
, eles:
- [9.5/W-1-1] PRECISA oferecer suporte a perfis restritos, um recurso que permite que os proprietários de dispositivos gerenciem outros usuários e do dispositivo. Com perfis restritos, os proprietários de dispositivos podem configurar rapidamente ambientes separados para que outros usuários trabalhem, com a capacidade de gerenciar restrições mais refinadas nos apps disponíveis nesses ambientes.
Se as implementações de dispositivos Watch incluem vários usuários e
declararem a flag de recurso android.hardware.telephony
, eles:
- [9.5/W-2-1] NÃO PODE oferecer suporte a restrições perfis, mas PRECISA estar alinhada com a implementação de controles do AOSP para ativar ou desativar o acesso de outros usuários a chamadas de voz e SMS.
Iniciar novos requisitos
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.
Encerrar novos requisitos
2,5 Requisitos automotivos
A implementação do Android Automotive se refere a uma unidade principal de veículo em execução. Android como um sistema operacional para parte ou para todo o sistema e/ou funcionalidade de infoentretenimento.
As implementações de dispositivos Android serão classificadas como Automotive se declararem
o recurso android.hardware.type.automotive
ou atender a todas as
critérios.
- estejam incorporados como parte de um veículo automotivo ou conectá-lo a ele;
- estão usando uma tela na fila do assento do motorista como tela principal;
Os requisitos adicionais no restante desta seção são específicos para o Android Implementações de dispositivos automotivos.
2.5.1. Hardware
Implementações de dispositivos automotivos:
- [7.1.1.1/A-0-1] PRECISA ter uma tela de pelo menos seis polegadas de tamanho diagonal.
- [7.1.1.1/A-0-2] PRECISA ter um layout de tamanho de tela. de pelo menos 750 dp x 480 dp.
- [7.2.3/A-0-1] PRECISA fornecer a função Home e PODE fornecer as funções Voltar e Recentes.
- [7.2.3/A-0-2] PRECISA enviar os comandos normal e longo
Evento da função Voltar (
KEYCODE_BACK
) para o aplicativo em primeiro plano. - [7.3/A-0-1] PRECISA implementar e informar
GEAR_SELECTION
,NIGHT_MODE
,PERF_VEHICLE_SPEED
ePARKING_BRAKE_ON
. - [7.3/A-0-2] O valor do atributo
NIGHT_MODE
PRECISA ser consistente com o modo dia/noite do painel e DEVE se basear na do sensor de luz ambiente. O sensor de luz ambiente pode ser o mesmo como Photometer. - [7.3/A-0-3] PRECISA fornecer o campo de informações adicionais do sensor.
TYPE_SENSOR_PLACEMENT
como parte de SensorAdditionalInfo para cada sensor fornecido. - [7,3/A-SR1] PODE reconhecer o local combinando GPS/GNSS com sensores adicionais. Se Local não foi reconhecido, é MUITO RECOMENDADO implementar e informar os Sensor correspondente tipos e/ou IDs de propriedade do veículo usados.
[7.3/A-0-4] O local solicitada por LocationManager#requestLocationUpdates() NÃO PODE haver correspondência no mapa.
[7.3.1/A-0-4] PRECISA estar em conformidade com a sistema de coordenadas do sensor de carros.
[7.3/A-SR-1] São STRONGLY_RECOMMENDED para incluir um eixo acelerômetro e giroscópio de 3 eixos.
[7.3/A-SR-2] São STRONGLY_RECOMENDADOS para implementar e informar Sensor
TYPE_HEADING
.
Se as implementações de dispositivos automotivos oferecerem suporte ao OpenGL ES 3.1, elas:
- [7.1.4.1/A-0-1] PRECISA declarar OpenGL ES 3.1 ou mais recente.
- [7.1.4.1/A-0-2] PRECISA oferecer suporte ao Vulkan 1.1.
- [7.1.4.1/A-0-3] PRECISA incluir o carregador do Vulkan. e exportar todos os símbolos.
Iniciar novos requisitos
Se as implementações de dispositivos automotivos incluírem suporte ao Vulkan, elas:
- [7.1.4.2/A-1-1] PRECISA atender aos requisitos. especificados pelo perfil de referência do Android 2021.
Encerrar novos requisitos
Se as implementações de dispositivos automotivos incluírem um acelerômetro, elas:
- [7.3.1/A-1-1] PRECISA relatar eventos até uma frequência. de pelo menos 100 Hz.
Se as implementações de dispositivos incluírem um acelerômetro de três eixos, elas:
- [7.3.1/A-SR-1] É FORTEMENTE RECOMENDADO para implementar a sensor composto para acelerômetro de eixos limitados.
Se as implementações de dispositivos automotivos incluírem um acelerômetro com menos de três eixos, eles:
- [7.3.1/A-1-3] PRECISA implementar e informar
Sensor
TYPE_ACCELEROMETER_LIMITED_AXES
. - [7.3.1/A-1-4] PRECISA implementar e informar
Sensor
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
.
Se as implementações de dispositivos automotivos incluírem um giroscópio, elas:
- [7.3.4/A-2-1] PRECISA relatar eventos até uma frequência. de pelo menos 100 Hz.
- [7.3.4/A-2-3] PRECISA ser capaz de medir mudanças de orientação. até 250 graus por segundo.
- [7.3.4/A-SR-1] É FORTEMENTE RECOMENDADO para configurar o intervalo de medida do giroscópio para +/-250 dps, a fim de maximizar a resolução sempre que possível.
Se as implementações de dispositivos automotivos incluírem um giroscópio de três eixos, elas:
- [7.3.4/A-SR-2] É FORTEMENTE RECOMENDADO para implementar a sensor composto para giroscópio de eixos limitados.
Se as implementações de dispositivos automotivos incluírem um giroscópio com menos de três eixos, elas:
- [7.3.4/A-4-1] PRECISA implementar e informar
Sensor
TYPE_GYROSCOPE_LIMITED_AXES
. - [7.3.4/A-4-2] PRECISA implementar e informar
Sensor
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
.
Se as implementações de dispositivos automotivos incluírem um receptor GPS/GNSS, mas não incluem conectividade de dados com base em rede celular, eles:
- [7.3.3/A-3-1] PRECISA determinar o local na primeira vez. Se o receptor GPS/GNSS estiver ligado ou após 4 ou mais dias dentro de 60 segundos.
- [7.3.3/A-3-2] PRECISA atender aos critérios de tempo até a primeira correção, descritos em 7.3.3/C-1-2 e 7.3.3/C-1-6 para todas as outras solicitações de local (ou seja, solicitações que não são a primeira vez nunca ou depois de mais de quatro dias). O requisito 7.3.3/C-1-2 é normalmente atendidas em veículos sem conectividade de dados baseada em rede celular, usando previsões de órbita de GNSS calculadas no receptor ou última localização conhecida do veículo e a capacidade de detectar mortos pelo menos 60 segundos com uma precisão de posição satisfatória 7.3.3/C-1-3 ou uma combinação de ambos.
Se as implementações de dispositivos automotivos incluírem um sensor TYPE_HEADING
, elas:
- [7.3.4/A-4-3] PRECISA relatar eventos até uma frequência. de pelo menos 1 Hz.
- [7.3.4/A-SR-3] STRONGLY_RECOMMENDED para relatar eventos de até um de pelo menos 10 Hz.
- DEVE se referir ao norte verdadeiro.
- DEVE estar disponível mesmo quando o veículo estiver parado.
- DEVE ter uma resolução de pelo menos 1 grau.
Implementações de dispositivos automotivos:
- [7.4.3/A-0-1] PRECISA ser compatível com Bluetooth e DEVE oferecer suporte a Bluetooth LE.
- [7.4.3/A-0-2] Implementações do Android Automotive
PRECISA oferecer suporte aos seguintes perfis Bluetooth:
- Chamadas telefônicas pelo perfil viva-voz (HFP, na sigla em inglês).
- Reprodução de mídia no perfil de distribuição de áudio (A2DP, na sigla em inglês).
- Controle de reprodução de mídia sobre o perfil de controle remoto (AVRCP, na sigla em inglês).
- Compartilhamento de contatos usando o perfil de acesso à agenda telefônica (PBAP, na sigla em inglês).
[7.4.3/A-SR-1] É FORTEMENTE RECOMENDADO para o suporte Perfil de acesso a mensagens (MAP).
[7.4.5/A] DEVE incluir suporte para celular conectividade de dados baseada em rede.
[7.4.5/A] PODE usar a API System Constante
NetworkCapabilities#NET_CAPABILITY_OEM_PAID
para redes que devem estar disponíveis para apps do sistema.
Iniciar novos requisitos
Se as implementações do dispositivo incluem suporte a rádio de transmissão AM/FM e exposição a funcionalidade de qualquer aplicativo, elas:
- [7.4
.10/A-0-1] PRECISA declarar suporte paraFEATURE_BROADCAST_RADIO
.
Encerrar novos requisitos
Uma câmera de visualização externa é uma câmera que captura cenas fora 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, uma câmera, eles:
- [7.5/A-1-1] NÃO PODE ter câmeras de visualização externa acessíveis pelas APIs Android Camera, a menos que estejam em conformidade com os 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 para 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 autofoco em hardware ou em software implementado o driver da câmera.
Se as implementações de dispositivos automotivos incluírem uma ou mais câmeras de visão externa, e carregam o serviço Exterior View System (EVS). Depois, para essa câmera, eles:
- [7.5/A-2-1] NÃO PODE girar nem espelhar horizontalmente a visualização da câmera.
Implementações de dispositivos automotivos:
- PODE incluir uma ou mais câmeras disponíveis para terceiros aplicativos conteinerizados.
Se as implementações de dispositivos automotivos incluem pelo menos uma câmera e a tornam para aplicativos de terceiros:
- [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 um câmera do sistema.
- PODE ser compatível com câmeras externas descritas na seção 7.5.3.
- PODE incluir recursos (como autofoco etc.) disponíveis para a direção traseira câmeras, conforme descrito na seção 7.5.1.
Iniciar novos requisitos
Uma câmera traseira significa uma câmera voltada para o mundo que pode ser localizada em qualquer colocado no veículo e voltado para o lado de fora da cabine do veículo; ou seja, imagens na lateral do corpo do veículo, como na câmera traseira.
Uma câmera frontal refere-se a uma câmera voltada ao usuário que pode ser localizada em qualquer colocado no veículo e voltado para dentro da cabine dele; isso imagens que o usuário pode usar, 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 visualizações câmeras.
- PODE incluir uma ou mais câmeras voltadas para o usuário.
- [7.5/A-SR-2] É FORTEMENTE RECOMENDADO para oferecer suporte ao streaming simultâneo de várias câmeras.
Se as implementações de dispositivos automotivos incluírem pelo menos uma câmera voltadas para o mundo, para uma câmera, eles:
- [7.5/A-1-1] PRECISA estar orientada de modo que a dimensão longa da câmera se alinhe. com o plano X-Y dos eixos dos sensores automotivos do Android.
- [7.5/A-SR-3] É FORTEMENTE RECOMENDADO ter foco fixo ou EDOF (profundidade de campo estendida).
- [7.5/A-1-2] PRECISA ter a câmera frontal como a principal câmera com o menor ID de câmera.
Se as implementações de dispositivos automotivos incluírem pelo menos uma câmera voltado para o usuário, para uma câmera desse tipo:
- [7.5/A-2-1] A principal câmera voltada ao usuário PRECISA ser a câmera voltada ao usuário. com o menor ID de câmera.
- PODE ser orientado de modo que a dimensão longa da câmera se alinhe com o eixo X-Y plano dos eixos dos sensores automotivos do Android.
Se as implementações de dispositivos automotivos incluírem uma câmera acessível via
API android.hardware.Camera
ou android.hardware.camera2
, eles:
- [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 inacessível
usando a API android.hardware.Camera
ou android.hardware.camera2
,
eles:
- [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 por meio de Serviço de sistema de visualização estendido, para essa câmera, eles:
- [7.5/A-5-1] NÃO PODE girar nem espelhar a visualização da câmera horizontalmente.
- [7.5/A-SR-4] É FORTEMENTE RECOMENDADO que tenha uma resolução de pelo menos 1,3 megapixels.
Se as implementações de dispositivos automotivos incluem uma ou mais câmeras
acessível pelo Serviço do sistema de visualização estendida e pelo android.hardware.Camera
ou a API android.hardware.Camera2
, para essa câmera, eles:
- [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 o
android.hardware.camera2
ou a API Extended View System.
Encerrar novos requisitos
Implementações de dispositivos automotivos:
[7.6.1/A-0-1] PRECISA ter pelo menos 4 GB de armazenamento não volátil disponível para dados privados de aplicativos (também conhecida como partição "/data").
[7.6.1/A] DEVE formatar a partição de dados para oferecer melhor desempenho e longevidade no armazenamento flash, por exemplo usando o sistema de arquivos
f2fs
.
Se as implementações de dispositivos automotivos fornecerem armazenamento externo compartilhado por meio de um do armazenamento interno não removível, elas:
- [7.6.1/A-SR-1] É FORTEMENTE RECOMENDADO para reduzir
Overhead de E/S em operações realizadas no armazenamento externo, por exemplo,
usando
SDCardFS
.
Se as implementações de dispositivos automotivos forem de 64 bits:
[7.6.1/A-2-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 816 MB se qualquer uma das densidades a seguir for usada:
- 280 dpi ou menos em telas pequenas/normais
- Ldpi ou menor em telas muito grandes
- Mdpi ou menor em telas grandes
[7.6.1/A-2-2] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 944 MB se qualquer uma das densidades a seguir for usada:
- xhdpi ou maior em telas pequenas/normais
- hdpi ou maior em telas grandes
- mdpi ou maior em telas muito grandes
[7.6.1/A-2-3] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 1.280 MB se qualquer uma das densidades a seguir for usada:
- 400 dpi ou mais em telas pequenas/normais
- xhdpi ou maior em telas grandes
- tvdpi ou maior em telas muito grandes
[7.6.1/A-2-4] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 1.824 MB se qualquer uma das densidades a seguir for usada:
- 560 dpi ou mais em telas pequenas/normais
- 400 dpi ou mais em telas grandes
- xhdpi ou maior em telas muito grandes
Observe que a "memória disponível para o kernel e o espaço do usuário" acima refere-se à além de qualquer memória já dedicada ao hardware como rádio, vídeo, entre outros, que não estão no kernel nas implementações de dispositivos.
Implementações de dispositivos automotivos:
- [7.7.1/A] DEVE incluir uma porta USB compatível com o modo de periféricos.
Implementações de dispositivos automotivos:
- [7.8.1/A-0-1] PRECISA incluir um microfone.
Implementações de dispositivos automotivos:
- [7.8.2/A-0-1] PRECISA ter uma saída de áudio e declarar
android.hardware.audio.output
2.5.2 Multimídia
As implementações de dispositivos automotivos PRECISAM oferecer suporte à codificação de áudio a seguir. e decodificação e disponibilizá-los para aplicativos de terceiros:
- [5.1/A-0-1] Perfil AAC MPEG-4 (AAC LC)
- [5.1/A-0-2] Perfil MPEG-4 HE AAC (AAC+)
- [5.1/A-0-3] AAC ELD (AAC com atraso baixo aprimorado)
As implementações de dispositivos automotivos PRECISAM oferecer suporte à seguinte codificação de vídeo: formatos e disponibilizá-los para aplicativos de terceiros:
As implementações de dispositivos automotivos PRECISAM oferecer suporte à decodificação de vídeo a seguir. formatos e disponibilizá-los para aplicativos de terceiros:
As implementações de dispositivos automotivos são FORTEMENTE RECOMENDADAS para oferecer suporte à seguinte decodificação de vídeo:
- [5,3/A-SR-1] H.265 HEVC
2.5.3 Software
Implementações de dispositivos automotivos:
[3/A-0-1] PRECISA declarar o recurso
android.hardware.type.automotive
[3/A-0-2] PRECISA oferecer suporte a uiMode =
UI_MODE_TYPE_CAR
.[3/A-0-3] PRECISA oferecer suporte a todas as APIs públicas nos
android.car.*
.
Se as implementações de dispositivos automotivos fornecerem uma API reservada usando
android.car.CarPropertyManager
com
android.car.VehiclePropertyIds
,
eles:
- [3/A-1-1] NÃO PODE anexar privilégios especiais ao sistema o uso dessas propriedades por parte de um aplicativo ou impedem que aplicativos de terceiros do uso dessas propriedades.
- [3/A-1-2] NÃO PODE replicar uma propriedade do veículo que já existe no SDK.
Implementações de dispositivos automotivos:
[3.2.1/A-0-1] PRECISA oferecer suporte e aplicar todas constantes de permissão, conforme documentado pela página de referência de permissões automotivas.
[3.2.3.1/A-0-1] PRECISA pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents para todos padrões de filtro de intent pública definidos pelas seguintes intents de aplicativo listados aqui.
[3.4.1/A-0-1] PRECISA fornecer um implementação da API
android.webkit.Webview
.
Iniciar novos requisitos
- [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 nenhuma tela.
Encerrar novos requisitos
[3.8.3/A-0-1] PRECISA exibir notificações que usam o
Notification.CarExtender
API quando solicitado por aplicativos de terceiros.[3.8.4/A-SR-1] São altamente recomendados para implementar um assistente no dispositivo e processar a ação de assistência.
Se as implementações de dispositivos automotivos incluírem um botão "push-to-talk", elas:
- [3.8.4/A-1-1] PRECISA usar um pressionamento curto de
o botão de pressionar para falar como a interação designada para iniciar o
app assistivo selecionado pelo usuário, ou seja, o app que implementa
VoiceInteractionService
.
Implementações de dispositivos automotivos:
- [3.8.3.1/A-0-1] PRECISA corretamente
renderize recursos conforme descrito em
Notifications on Automotive OS
na documentação do SDK. - [3.8.3.1/A-0-2] PRECISA exibir
PLAY e MUTE para ações de notificação no lugar daquelas fornecidas por
Notification.Builder.addAction()
- [3.8.3.1/A] DEVE restringir as o uso de tarefas de gerenciamento avançado, como controles por canal de notificação. PODE usar recursos de interface por aplicativo para reduzir os controles.
Se as implementações de dispositivos automotivos oferecerem suporte às propriedades da HAL de usuário, elas:
- [3.9.3/A-1-1] PRECISA implementar todos os
Propriedades do ciclo de vida do usuário
INITIAL_USER_INFO
,SWITCH_USER
,CREATE_USER
,REMOVE_USER
.
Implementações de dispositivos automotivos:
- [3.14/A-0-1] PRECISA incluir um framework de interface para dar suporte aplicativos de terceiros que usam as APIs de mídia, conforme descrito na seção 3,14.
- [3.14/A-0-2] PRECISA permitir que o usuário interaja com segurança com aplicativos de mídia ao dirigir.
- [3.14/A-0-3] PRECISA ser compatível com o
CAR_INTENT_ACTION_MEDIA_TEMPLATE
uma ação de intent implícita comCAR_EXTRA_MEDIA_PACKAGE
extra. - [3.14/A-0-4] PRECISA fornecer uma affordance para navegar de um aplicativo de mídia preferência atividade, mas PRECISA ativá-la apenas quando as Restrições de UX para carros não estiverem em vigor.
- [3.14/A-0-5] PRECISA exibir
mensagens de erro
definido por aplicativos de mídia e PRECISA oferecer suporte aos extras opcionais
ERROR_RESOLUTION_ACTION_LABEL
eERROR_RESOLUTION_ACTION_INTENT
. - [3.14/A-0-6] PRECISA ser compatível com uma funcionalidade de pesquisa no app para apps compatíveis com a pesquisa.
- [3.14/A-0-7] PRECISA respeitar!
CONTENT_STYLE_BROWSABLE_HINT
eCONTENT_STYLE_PLAYABLE_HINT
definições ao exibir o MediaBrowser hierarquia.
Se as implementações de dispositivos automotivos incluírem um app de tela de início padrão, elas:
- [3.14/A-1-1] PRECISA incluir serviços de mídia e abri-los.
com o
CAR_INTENT_ACTION_MEDIA_TEMPLATE
intenção.
Implementações de dispositivos automotivos:
- [3.8/A] PODE restringir o aplicativo
solicitações para entrar no modo de tela cheia, conforme descrito em
immersive documentation
. - [3.8/A] PODE manter a barra de status e a barra de navegação sempre visível.
- [3.8/A] PODE restringir o aplicativo solicitações para alterar as cores atrás dos elementos da interface do sistema, a fim de garantir esses elementos estejam claramente visíveis em todos os momentos.
2.5.4 Desempenho e potência
Implementações de dispositivos automotivos:
- [8.2/A-0-1] PRECISA informar o número de
bytes lidos e gravados no armazenamento não volátil por UID de cada processo para que os
as estatísticas são disponibilizadas aos desenvolvedores pela API do sistema.
android.car.storagemonitoring.CarStorageMonitoringManager
O Android Open O projeto de origem atende ao requisito pelo módulo do kerneluid_sys_stats
. - [8.3/A-1-3] PRECISA oferecer suporte ao modo garagem.
- [8.3/A] DEVE ficar no modo garagem por pelo menos
15 minutos após cada percurso, a menos que:
- A bateria está descarregada.
- Nenhum job ocioso está programado.
- O motorista sai do modo garagem.
- [8.4/A-0-1] PRECISA fornecer uma perfil de energia por componente que define o valor de consumo atual para cada componente de hardware e o consumo aproximado da bateria causado pelo ao longo do tempo, conforme documentado no site do Android Open Source Project.
- [8.4/A-0-2] PRECISA informar toda a energia valores de consumo em milissegundos/hora (mAh).
- [8.4/A-0-3] PRECISA informar a energia da CPU.
e consumo de acordo com o UID de cada processo. O Android Open Source Project atende à
requisito pela implementação do módulo do kernel
uid_cputime
. - [8.4/A] DEVE ser atribuída ao componente de hardware em si, se não for possível atribuir o uso de energia do componente de hardware a um aplicativo.
- [8.4/A-0-4] PRECISA fazer esse uso de energia
disponível no
adb shell dumpsys batterystats
shell para o desenvolvedor do app.
2.5.5 Modelo de segurança
Se as implementações de dispositivos automotivos oferecerem suporte a vários usuários, elas:
- [9.5/A-1-1] NÃO PODE permitir que os usuários interajam com nem mudar para o usuário do sistema headless, exceto para o provisionamento de dispositivos.
- [9.5/A-1-2] PRECISA mudar para um Usuário secundário.
antes de
BOOT_COMPLETED
. - [9.5/A-1-3] PRECISA oferecer suporte à capacidade de criação um usuário convidado mesmo quando o número máximo de usuários em um dispositivo for atingido.
Iniciar novos requisitos
Se as implementações de dispositivos automotivos declararem android.hardware.microphone
,
eles:
- [9.8.2/A-1-1] PRECISA exibir o indicador de microfone quando:
um aplicativo está acessando dados de áudio do microfone, mas não quando o
o microfone só é acessado por
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
ou apps com os papéis destacados 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 com 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 alternar o microfone no app Configurações.
Encerrar novos requisitos
Se as implementações de dispositivos automotivos declararem android.hardware.camera.any
,
eles:
- [9.8.2/A-2-1] PRECISA exibir o indicador da câmera quando um
está acessando dados da câmera em tempo real, mas não quando ela está sendo
acessado por apps com os papéis definidos
mencionadosno Seção 9.1 Permissões com o identificador CDD [C-4-X][C-3-X]. - [9.8.2/A-2-2] NÃO PODE ocultar o indicador da câmera para apps do sistema com interfaces do usuário visíveis ou interação direta com o usuário.
Iniciar novos requisitos
- [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 exibir apps recentes e ativos usando a câmera como retornado
de
PermissionManager.getIndicatorAppOpUsageData()
, junto com mensagens de atribuição associadas a elas.
Encerrar novos requisitos
Implementações de dispositivos automotivos:
- [9/A-0-1] PRECISA declarar a
android.hardware.security.model.compatible
. - [9.11/A-0-1] PRECISA fazer backup da implementação de keystore. com um ambiente de execução isolado.
- [9.11/A-0-2] PRECISA ter implementações de RSA, AES, Algoritmos criptográficos ECDSA e HMAC e família MD5, SHA1 e SHA-2 para oferecer suporte adequado ao suporte do sistema Android Keystore algoritmos em uma área segura e isolada do código em execução kernel e acima. O isolamento seguro PRECISA bloquear todos os possíveis mecanismos. pelo qual o código do kernel ou do espaço do usuário pode acessar o estado interno da ambiente isolado, incluindo DMA. O Android Open Source upstream O Project (AOSP) atende a esse requisito usando a implementação Trusty, mas outra Uma solução baseada em ARM TrustZone ou uma solução verificada por terceiros como segura a implementação adequada de um isolamento baseado em hipervisor são alternativas .
- [9.11/A-0-3] PRECISA executar a tela de bloqueio. no ambiente de execução isolado e somente ao bem-sucedido, permite o uso das chaves vinculadas à autenticação. Bloquear tela as credenciais PRECISAM ser armazenadas de uma forma que permita somente a execução isolada para executar a autenticação da tela de bloqueio. O sistema upstream do Android O Open Source Project oferece Camada de abstração de hardware (HAL) Gatekeeper e o Trusty, que podem ser usados para atender a esse requisito.
- [9.11/A-0-4] PRECISA oferecer suporte ao atestado de chaves em que o a chave de assinatura de atestado é protegida por um hardware seguro e a assinatura é executadas em hardware seguro. As chaves de assinatura de atestado PRECISAM ser compartilhadas em um número grande de dispositivos para impedir o uso das chaves como identificadores de dispositivo. Uma forma de atender a esse requisito é compartilhar o mesma chave de atestado,a menos que pelo menos 100.000 unidades de uma determinada SKU sejam produzidos. Se mais de 100.000 unidades de uma SKU forem produzidas, outro chave PODE ser usada para cada 100.000 unidades.
Se uma implementação de dispositivo já tiver sido iniciada em uma versão anterior
versão, tal dispositivo está isento da exigência de ter um keystore
em um ambiente de execução isolado e oferecem suporte ao atestado de chaves,
a menos que declare o recurso android.hardware.fingerprint
, que requer uma
um keystore apoiado por um ambiente de execução isolado.
Implementações de dispositivos automotivos:
- [9.14/A-0-1] Mensagens de gatekeep PRECISA dos subsistemas do veículo do framework do Android (por exemplo, colocar uma mensagem permitida na lista de permissões) tipos e origens de mensagens.
- [9,14/A-0-2] PRECISA praticar o monitoramento contra ataques de negação de serviço do framework do Android ou de apps de terceiros. Isso protege contra software malicioso que inunda a rede do veículo com tráfego, o que pode causar o defeito de subsistemas do veículo.
2.5.6. Compatibilidade de opções e ferramentas para desenvolvedores
Implementações de dispositivos automotivos:
- Perfetto (link em inglês)
- [6.1/A-0-1] PRECISA expor um
/system/bin/perfetto
. binário para o usuário do shell com o qual o cmdline obedece a documentação do perfetto. - [6.1/A-0-2] O binário do perfetto PRECISA ser aceito como insira uma configuração protobuf que esteja em conformidade com o esquema definido em a documentação do perfetto.
- [6.1/A-0-3] O binário do perfetto PRECISA ser escrito como gera um trace protobuf que cumpre o esquema definido em a documentação do perfetto.
- [6.1/A-0-4] PRECISA fornecer, pelo perfetto. binário, pelo menos as fontes de dados descritas na documentação do Perfeito.
- [6.1/A-0-1] PRECISA expor um
2,6 Requisitos para tablets
Um tablet Android se refere a uma implementação de dispositivo Android que geralmente atende a todos os critérios a seguir:
- Usado por segurar as duas mãos.
- Não tem configuração flip ou conversível.
- As implementações de teclado físico usadas com o dispositivo são conectadas por usando uma conexão padrão (por exemplo, USB ou Bluetooth).
tem uma fonte de energia que oferece mobilidade, como uma bateria;
Tem uma tela com tamanho maior que 7” e menor que 18”, medidas diagonalmente.
Implementações de tablets têm requisitos semelhantes aos de dispositivos portáteis e implementações. As exceções são indicadas por um * na seção e indicados para referência nesta seção.
2.6.1. Hardware
Giroscópio
Se as implementações de tablets incluírem um giroscópio de três eixos, elas:
- [7.3.4/Tab-1-1] PRECISA ser capaz de medir a orientação. muda até 1.000 graus por segundo.
Memória e armazenamento mínimos (Seção 7.6.1)
As densidades de tela listadas para telas pequenas/normais no dispositivo portátil não se aplicam a tablets.
Modo de periférico USB (Seção 7.7.1)
Se as implementações de tablets incluírem uma porta USB compatível com periféricos , eles:
- [7.7.1/Tab] PODE implementar a API Android Open Accessory (AOA).
Modo de realidade virtual (Seção 7.9.1)
Alto desempenho da realidade virtual (Seção 7.9.2)
Os requisitos de realidade virtual não se aplicam a tablets.
2.6.2. Modelo de segurança
Chaves e credenciais (Seção 9.11)
Consulte a Seção [9.11].
Se as implementações de tablets incluem vários usuários e
não declararem a flag de recurso android.hardware.telephony
, eles:
- [9.5/T-1-1] PRECISA oferecer suporte a perfis restritos, um recurso que permite que os proprietários de dispositivos gerenciem outros usuários e do dispositivo. Com perfis restritos, os proprietários de dispositivos podem configurar rapidamente ambientes separados para que outros usuários trabalhem, com a capacidade de gerenciar restrições mais refinadas nos apps disponíveis nesses ambientes.
Se as implementações de tablets incluem vários usuários e
declararem a flag de recurso android.hardware.telephony
, eles:
- [9.5/T-2-1] NÃO PODE oferecer suporte a restrições perfis, mas PRECISA estar alinhada com a implementação de controles do AOSP para ativar ou desativar o acesso de outros usuários a chamadas de voz e SMS.
2.6.2. Software
- [3.2.3.1/Tab-0-1] PRECISA pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents para todos os padrões de filtro de intent pública definidos pelas seguintes intents de aplicativo listados aqui.
3. Software
3.1. Compatibilidade com APIs gerenciadas
O ambiente de execução de bytecode Dalvik gerenciado é o principal veículo para Apps Android. A interface de programação do aplicativo Android (API) é a conjunto de interfaces da plataforma Android expostas a aplicativos em execução no de um ambiente de execução gerenciado.
Implementações de dispositivos:
[C-0-1] PRECISA fornecer implementações completas, incluindo todas as documentações comportamentos de qualquer API documentada exposta pelo SDK do Android ou qualquer API decorada com o marcador "@SystemApi" no sistema operacional o código-fonte.
[C-0-2] PRECISA oferecer suporte/preservar todas as classes, métodos e elementos associados marcados pela anotação TestApi (@TestApi).
[C-0-3] NÃO PODE omitir nenhuma API gerenciada, alterar interfaces ou assinaturas de API, desviam do comportamento documentado ou incluem ambiente autônomo, exceto quando permitido especificamente por esta definição de compatibilidade.
[C-0-4] Ainda PRECISA manter as APIs presentes e se comportar. de forma razoável, mesmo quando alguns recursos de hardware para os quais o inclui APIs são omitidas. Consulte a seção 7 para requisitos específicos desse cenário.
[C-0-5] NÃO PODE permitir que apps de terceiros usem interfaces externas ao SDK, o que são definidos como métodos e campos nos pacotes de linguagem Java que são no caminho de classe de inicialização no AOSP e que não façam parte da SDK do Vertex AI Pipelines. Isso inclui APIs decoradas com a anotação
@hide
, mas não com um@SystemAPI
, conforme descrito nos documentos do SDK. e membros particulares e privados do pacote.[C-0-6] PRECISA ser enviado com cada interface externa ao SDK no mesmo listas fornecidas pelas sinalizações provisórias e de lista de bloqueio em
prebuilts/runtime/appcompat/hiddenapi-flags.csv
caminho para a ramificação de nível de API adequada no AOSP.[C-0-7] PRECISA ser compatível com a configuração assinada. mecanismo de atualização dinâmica para remover interfaces externas ao SDK de uma lista restrita incorporando a configuração assinada em qualquer APK, usando as chaves públicas existentes presentes no AOSP.
No entanto, elas:
- MAIS, se uma API oculta estiver ausente ou tiver sido implementada de maneira diferente no dispositivo de implementação, mova a API oculta para a lista de bloqueio ou omita a API todas as listas restritas.
- MAIS, se ainda não existir uma API oculta no AOSP, adicione a API oculta a qualquer uma das listas restritas.
Iniciar novos requisitos
- [C-0-8] NÃO PODE oferecer suporte à instalação de aplicativos direcionados a um nível de API menor que 23.
Encerrar novos requisitos
3.1.1. Extensões Android
O Android oferece suporte à extensão da superfície de API gerenciada de um nível de API específico ao
atualizando a versão da extensão desse nível de API. O
A API android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
retorna o
versão da extensão do apiLevel
fornecido, se houver extensões para ele
Nível da API.
Implementações de dispositivos Android:
[C-0-1] PRECISA pré-carregar a implementação do AOSP da biblioteca compartilhada.
ExtShared
e serviçosExtServices
com versões maiores ou iguais a as versões mínimas permitidas por nível de API. Por exemplo, Android 7.0 implementações de dispositivos que executam o nível 24 da API PRECISAM incluir pelo menos versão 1.[C-0-2] PRECISA retornar somente números válidos de versão de extensão que tenham sido definido pelo AOSP.
[C-0-3] PRECISA oferecer suporte a todas as APIs definidas pelas versões da extensão. devolvido por
android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
da mesma maneira que outras APIs gerenciadas têm suporte, seguindo os requisitos na seção 3.1.
3.1.2. Biblioteca do Android
Devido à descontinuação do cliente Apache HTTP, implementações de dispositivos:
- [C-0-1] NÃO PODE colocar a biblioteca
org.apache.http.legacy
no bootclasspath. - [C-0-2] É NECESSÁRIO adicionar a biblioteca
org.apache.http.legacy
ao aplicativo o caminho de classe somente quando o app atender a uma destas condições:- Segmenta a API de nível 28 ou anterior.
- Declara no manifesto que precisa da biblioteca definindo a propriedade
Atributo
android:name
de<uses-library>
aorg.apache.http.legacy
.
A implementação do AOSP atende a esses requisitos.
3.2. Compatibilidade leve com APIs
Além das APIs gerenciadas da seção 3.1, O Android também inclui uma API significativa somente no tempo de execução, na forma de tais itens como intents, permissões e aspectos semelhantes de aplicativos Android que não podem ser aplicadas no tempo de compilação do aplicativo.
3.2.1. Permissões
- [C-0-1] Os implementadores de dispositivos PRECISAM oferecer suporte e aplicar todas as permissões conforme documentado na página de referência de permissão. A seção 9 lista recursos adicionais e requisitos relacionados ao modelo de segurança do Android.
3.2.2. Parâmetros de build
As APIs do Android incluem várias constantes no Classe android.os.Build que descrevem o dispositivo atual.
- [C-0-1] Para oferecer valores consistentes e significativos em todos os dispositivos implementações, a tabela abaixo inclui restrições adicionais sobre os formatos desses valores com os quais as implementações de dispositivos PRECISAM estar em conformidade.
Parâmetro | Detalhes |
---|---|
VERSÃO.LANÇAMENTO | A versão do sistema Android em execução no momento, em formato legível . Este campo PRECISA ter um dos valores de string definidos em Strings de versão permitidas para o Android 14. |
VERSION.SDK | A versão do sistema Android em execução no momento, em um formato pode ser acessado por códigos de aplicativos de terceiros. No Android 14, este campo PRECISA ter o valor inteiro: 14_INT. |
VERSION.SDK_INT | A versão do sistema Android em execução no momento, em um formato pode ser acessado por códigos de aplicativos de terceiros. No Android 14, este campo PRECISA ter o valor inteiro: 14_INT. |
VERSÃO.INCREMENTAL | Um valor escolhido pelo implementador do dispositivo, designando o build específico do sistema Android em execução no momento e em formato legível por humanos. Isso O valor NÃO PODE ser reutilizado para builds diferentes disponibilizados aos usuários finais. Um uso típico deste campo é para indicar qual número da versão ou o identificador de mudanças de controle de origem foi usado para gerar o build. O valor desse campo PRECISA ser codificado como ASCII de 7 bits para impressão e corresponder à expressão regular “^[^ :\/~]+$”. |
TABULEIRO | Um valor escolhido pelo implementador do dispositivo para identificar o hardware interno usado pelo dispositivo, em formato legível por humanos. Uma possível o uso deste campo é para indicar a revisão específica da placa que fornece energia o dispositivo. O valor deste campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular “^[a-zA-Z0-9_-]+$”. |
MARCA | Um valor que reflete o nome da marca associada ao dispositivo, como conhecido pelo os usuários finais. PRECISA estar em um formato legível por humanos e DEVE representar os fabricante do dispositivo ou a marca da empresa sob a qual o dispositivo está comercializados. O valor deste campo PRECISA ser codificável como ASCII de 7 bits e corresponder. a expressão regular “^[a-zA-Z0-9_-]+$”. |
ABIS_SUPORTE | O nome do conjunto de instruções (tipo de CPU + convenção ABI) de código nativo o código-fonte. Consulte a seção 3.3. API nativa Compatibilidade. |
SUPORTE_32_ABIS_BIT | O nome do conjunto de instruções (tipo de CPU + convenção ABI) de código nativo o código-fonte. Consulte a seção 3.3. API nativa Compatibilidade. |
SUPORTE_64_ABIS_BIT | O nome do segundo conjunto de instruções (tipo de CPU + convenção ABI) de o código nativo. Consulte a seção 3.3. Nativo Compatibilidade da API. |
CPU_ABI | O nome do conjunto de instruções (tipo de CPU + convenção ABI) de código nativo o código-fonte. Consulte a seção 3.3. API nativa Compatibilidade. |
CPU_ABI2 | O nome do segundo conjunto de instruções (tipo de CPU + convenção ABI) de o código nativo. Consulte a seção 3.3. Nativo Compatibilidade da API. |
DISPOSITIVO | Um valor escolhido pelo implementador do dispositivo contendo o nome de desenvolvimento ou codinome que identifica a configuração dos recursos de hardware e o design industrial do dispositivo. O valor deste campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular “^[a-zA-Z0-9_-]+$”. O nome deste dispositivo NÃO PODE ser alterado durante o de vida útil do produto. |
IMPRESSORA | Uma string que identifica exclusivamente este build. DEVE ser razoavelmente
legível por humanos. Ele PRECISA seguir este modelo:
$(MARCA)/$(PRODUTO)/ Exemplo: acme/meuproduto/ A impressão digital NÃO PODE incluir caracteres de espaço em branco. O valor de este campo PRECISA ser codificável como ASCII de 7 bits. |
HARDWARE | O nome do hardware (da linha de comando do kernel ou /proc). Ela DEVE ser legíveis por humanos. O valor deste campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular “^[a-zA-Z0-9_-]+$”. |
APRESENTADOR | String que identifica exclusivamente o host em que o build foi criado. legível por humanos. Não há requisitos sobre o formato específico dos neste campo, exceto que NÃO PODE ser nulo ou a string vazia (""). |
ID | Um identificador escolhido pelo implementador do dispositivo para se referir a um determinado em um formato legível por humanos. Esse campo pode ser igual a android.os.Build.VERSION.INCREMENTAL, mas DEVE ser um valor suficiente. importante para os usuários finais distinguirem builds de software. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder ao padrão expressão “^[a-zA-Z0-9._-]+$”. |
FABRICANTE | O nome comercial do fabricante de equipamento original (OEM) do produto. Não há requisitos para o formato específico desse campo, exceto que NÃO PODE ser nulo ou uma string vazia (""). Este campo NÃO PODE ser alterado durante a vida útil do produto. |
FABRICANTE DE SOC | O nome comercial do fabricante do sistema principal em (SOC) usado no produto. Dispositivos com o mesmo fabricante de SOC devem usar o mesmo valor constante. Solicite ao fabricante do SOC a constante correta a ser usada. O valor deste campo PRECISA ser codificável como ASCII de 7 bits, PRECISA corresponder à expressão regular. “^([0-9A-Za-z ]+)”, NÃO PODE começar ou terminar com um espaço em branco; e NÃO PODE ser igual a "unknown". Este campo NÃO PODE ser alterado durante o de vida útil do produto. |
MODELO_SOC | O nome do modelo do sistema principal em um chip (SOC) usado na o produto. Dispositivos com o mesmo modelo de SOC precisam usar a mesma constante . Peça ao fabricante do SOC a constante correta a ser usada. O valor deste campo PRECISA ser codificável como ASCII de 7 bits e corresponder ao expressão regular “^([0-9A-Za-z ._/+-]+)$”, NÃO PODE começar ou terminar com um espaço em branco e NÃO PODE ser igual a "unknown". Este campo NÃO PODE ser alterado durante a vida útil do produto. |
MODEL | Um valor escolhido pelo implementador do dispositivo contendo o nome do dispositivo conhecido pelo usuário final. Este DEVE ser o mesmo nome usado o dispositivo é comercializado e vendido aos usuários finais. Não há requisitos para o formato específico deste campo, exceto que ele NÃO PODE ser nulo nem string vazia (""). Este campo NÃO PODE ser alterado durante o de vida útil do produto. |
PRODUTO | Um valor escolhido pelo implementador do dispositivo contendo o nome de desenvolvimento ou codinome do produto específico (SKU) que PRECISAM ser exclusivos dentro da pela mesma marca. PRECISA ser legível, mas não se destina necessariamente à visualização. pelos usuários finais. O valor deste campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular “^[a-zA-Z0-9_-]+$”. Este produto O nome NÃO PODE ser alterado durante a vida útil do produto. |
SKU do ODM | Um valor opcional escolhido pelo implementador do dispositivo que contém
SKU (unidade de manutenção de estoque) usada para rastrear configurações específicas do
dispositivo, por exemplo, qualquer periférico incluído no dispositivo, quando vendido.
O valor deste campo PRECISA ser codificável como ASCII de 7 bits e corresponder ao
expressão regular ^([0-9A-Za-z.,_-]+)$ . |
SÉRIE | PRECISA retornar "UNKNOWN". |
TAGS | Uma lista separada por vírgulas de tags escolhidas pelo implementador do dispositivo que diferencia ainda mais o build. As tags PRECISAM ser codificadas como ASCII de 7 bits. e corresponder à expressão regular “^[a-zA-Z0-9._-]+” e PRECISA têm um dos valores que correspondem aos três tipos de plataforma típicas de assinatura: chaves de lançamento, dev-keys e chaves de teste. |
HORÁRIO | Um valor que representa o carimbo de data/hora de quando o build ocorreu. |
MÁQUINA | Valor escolhido pelo implementador do dispositivo, especificando o ambiente de execução e a configuração do build. Este campo PRECISA ter um dos valores correspondentes às três configurações típicas do ambiente de execução do Android: usuário, userdebug ou eng. |
USUÁRIO | Um nome ou ID do usuário (ou usuário automatizado) que gerou o ser construído. Não há requisitos para o formato específico desse campo, exceto que NÃO PODE ser nulo ou uma string vazia (""). |
PATCH DE SEGURANÇA | Um valor que indica o nível do patch de segurança de uma versão. Ela PRECISA significar que o build não é de forma alguma vulnerável a nenhum dos problemas descritos com o boletim de segurança pública do Android. Ela PRECISA estar no formato [AAAA-MM-DD], correspondendo a uma string definida documentada no Segurança pública do Android Boletim ou no Consultoria de segurança do Android, por exemplo, "2015-11-01". |
BASE_SO | Um valor que representa o parâmetro FINGERPRINT da compilação que é idêntico a este build, exceto pelos patches fornecidos no Boletim de segurança pública do Android. Ela PRECISA informar o valor correto e, se um build desse tipo não existir, informe uma string vazia (""). |
BOOTLOADER | Um valor escolhido pelo implementador do dispositivo para identificar o A versão do carregador de inicialização interno usado no dispositivo, em formato legível por humanos. O valor deste campo PRECISA ser codificável como ASCII de 7 bits e corresponder ao expressão regular “^[a-zA-Z0-9._-]+$”. |
getRadioVersion() (link em inglês) | PRECISA (ser ou retornar) um valor escolhido pelo implementador do dispositivo. identificando a versão interna específica do rádio/modem usada no dispositivo, em um formato legível por humanos. Se um dispositivo não tiver rádio/modem, ele PRECISA retornar NULL. O valor deste campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular “^[a-zA-Z0-9._-,]+$”. |
getSerial() (em inglês) | PRECISA (ser ou devolver) um número de série do hardware, que PRECISA estar disponível. e exclusivos entre dispositivos com o mesmo MODEL e MANUFACTURER. O valor de este campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular “^[a-zA-Z0-9]+$”. |
3.2.3. Compatibilidade de intents
3.2.3.1. Intents comuns de aplicativos
As intents do Android permitem que os componentes do aplicativo solicitem a funcionalidade outros componentes do Android. O projeto upstream do Android inclui uma lista de aplicativos que implementam diversos padrões de intent para realizar ações comuns.
Implementações de dispositivos:
- [C-SR-1] É FORTEMENTE RECOMENDADO para pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents, para todos os filtros de intents públicos padrões definidos pelas seguintes intents de aplicativo listadas aqui e fornecer o cumprimento, ou seja, atender às expectativas dos desenvolvedores em relação a esses intents de aplicativos, conforme descrito no SDK.
Consulte a Seção 2 para intents de aplicativos obrigatórias para cada tipo de dispositivo.
3.2.3.2. Resolução de intents
[C-0-1] Como o Android é uma plataforma extensível, as implementações de dispositivos PRECISAM permitem cada padrão de intent referenciado na seção 3.2.3.1. , exceto para Configurações, para serem substituídas por aplicativos de terceiros. O A implementação de código aberto upstream do Android permite isso por padrão.
[C-0-2] Os implementadores de dispositivos NÃO PODEM anexar privilégios especiais ao sistema aplicativos uso desses padrões de intent ou impedem que aplicativos de terceiros da vinculação e assumindo o controle desses padrões. Essa proibição inclui especificamente, mas não se limita a, a desativação do usuário "Seletor" que permite que o usuário selecione entre vários aplicativos que todos para processar o mesmo padrão de intent.
[C-0-3] As implementações de dispositivos PRECISAM fornecer uma interface para que os usuários modificar a atividade padrão para intents.
No entanto, as implementações de dispositivos PODEM fornecer atividades padrão para determinados padrões de URI (por exemplo, http://play.google.com) quando a atividade padrão fornece um um atributo mais específico do URI de dados. Por exemplo, um padrão de filtro de intent especificar o URI de dados “http://www.android.com” é mais específico do que do navegador para "http://".
O Android também inclui um mecanismo para que aplicativos de terceiros declarem uma comportamento de vinculação de apps padrão autoritativo para determinados tipos de intents de URI da Web. Quando essas declarações oficiais são definido nos padrões de filtro de intent de um app, as implementações de dispositivos:
- [C-0-4] PRECISA tentar validar os filtros de intent executando a etapas de validação definidas na especificação Digital Asset Links conforme implementado pelo Package Manager no Android Open Source upstream Projeto.
- [C-0-5] PRECISA tentar a validação dos filtros de intents durante a instalação do o aplicativo e definir todos os filtros de intent de URI validados como gerenciadores de apps padrão para os URIs.
- PODE definir filtros de intent de URI específicos como gerenciadores de aplicativo padrão para seus URIs, se eles forem verificados, mas outros filtros de URI candidatos falharem verificação. Se uma implementação de dispositivo fizer isso, ela PRECISA fornecer o as substituições apropriadas por padrão de URI no menu de configurações.
- PRECISA oferecer ao usuário controles de links do app por app nas "Configurações" como
segue:
- [C-0-6] O usuário PRECISA conseguir fazer a substituição completa do app padrão comportamento de links para um app ser: sempre abrir, sempre perguntar ou nunca abrir, que precisa se aplicar a todos os filtros de intent de URI candidatos igualmente.
- [C-0-7] O usuário PRECISA ver uma lista de intents de URI candidatas. filtros.
- A implementação do dispositivo PODE fornecer ao usuário a capacidade de substituir filtros de intent de URI candidatos específicos que foram verificados por filtro de intent.
- [C-0-8] A implementação do dispositivo PRECISA oferecer aos usuários a capacidade de ver e substituir filtros de intent de URI candidatos específicos se o dispositivo permite que alguns filtros de intent de URI candidatos funcionem verificação, enquanto outras podem falhar.
3.2.3.3. Namespaces de intents
- [C-0-1] As implementações de dispositivos NÃO PODEM incluir componentes Android que respeita qualquer novo intent ou padrão de intent de transmissão usando um objeto ACTION, CATEGORY ou outra string de chave no namespace android.* ou com.android.*.
- [C-0-2] Implementadores de dispositivos NÃO PODEM incluir componentes Android que respeitar novos padrões de intent de transmissão ou de intent usando uma expressão ACTION, CATEGORY ou ou outra string de chave em um espaço de pacote pertencente a outra organização.
- [C-0-3] Os implementadores de dispositivos NÃO PODEM alterar nem estender nenhuma intent listados na seção 3.2.3.1.
- As implementações de dispositivos PODEM incluir padrões de intent usando namespaces claramente e, obviamente, associadas às próprias organizações. Essa proibição é análoga à especificada para classes da linguagem Java na seção 3.6.
3.2.3.4. Intents de transmissão
Aplicativos de terceiros dependem da plataforma para transmitir certas intents a notificá-los sobre alterações no ambiente de hardware ou software.
Implementações de dispositivos:
- [C-0-1] PRECISA transmitir as intents de transmissão públicas listadas aqui. em resposta aos eventos apropriados do sistema, conforme descrito na documentação do SDK. Observe que esse requisito não está em conflito com a seção 3.5, porque limitações para aplicativos de segundo plano também estão descritas no SDK na documentação do Google Cloud. Além disso, certas intents de transmissão são condicionais ao hardware se o dispositivo for compatível com o hardware necessário, eles DEVEM transmitir a e fornecem o comportamento inline com a documentação do SDK.
3.2.3.5. Intents de aplicativos condicionais
O Android inclui configurações que oferecem aos usuários uma maneira fácil de selecionar aplicativos padrão, como tela inicial ou SMS.
Quando fizer sentido, as implementações de dispositivos PRECISAM fornecer configurações semelhantes. e ser compatível com o padrão de filtro de intent e os métodos da API descritos na documentação do SDK, conforme mostrado abaixo.
Se as implementações de dispositivos informarem android.software.home_screen
, elas:
- [C-1-1] PRECISA respeitar o
android.settings.HOME_SETTINGS
. para mostrar um menu de configurações padrão do app na tela inicial.
Se as implementações de dispositivos informarem android.hardware.telephony.calling
, elas:
[C-2-1] PRECISA fornecer um menu de configurações que chame a função
android.provider.Telephony.ACTION_CHANGE_DEFAULT
para mostrar uma caixa de diálogo para alterar o aplicativo de SMS padrão.[C-2-2] PRECISA respeitar o
android.telecom.action.CHANGE_DEFAULT_DIALER
. de mostrar uma caixa de diálogo para permitir que o usuário altere a configuração Telefone padrão para o aplicativo.- PRECISA usar a interface do app Telefone padrão selecionada pelo usuário para chamadas recebidas e chamadas realizadas, exceto para chamadas de emergência, que usariam o Telefone pré-instalado.
[C-2-3] PRECISA respeitar android.telecom.action.CHANGE_PHONE_ACCOUNTS. para fornecer affordance ao usuário para configurar o
ConnectionServices
. associados aoPhoneAccounts
, conforme assim como uma PhoneAccount padrão que o provedor de serviços de telecomunicações usar para efetuar chamadas. A implementação do AOSP atende a esse requisito incluindo uma "opção para chamadas em "Chamadas", no menu de configurações.[C-2-4] PRECISA permitir
android.telecom.CallRedirectionService
. para um app que contém aandroid.app.role.CALL_REDIRECTION
de rede.[C-2-5] PRECISA fornecer ao usuário affordance para escolher um app que tenha a
android.app.role.CALL_REDIRECTION
de rede.[C-2-6] PRECISA respeitar a solicitação android.intent.action.SENDTO. e android.intent.action.VIEW e fornecem uma atividade para enviar/exibir mensagens SMS.
[C-SR-1] É FORTEMENTE RECOMENDADO para respeitar android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_Button, android.intent.action.VIEW & android.intent.action.DIAL com um aplicativo discador pré-carregado que pode lidar com essas intents e fornecer o fulfillment conforme descrito no SDK.
Se as implementações de dispositivos informarem android.hardware.nfc.hce
, elas:
- [C-3-1] PRECISA respeitar as android.settings.NFC_PAYMENT_CONFIG. intenção de mostrar um menu de configurações padrão do app para pagamento por aproximação.
- [C-3-2] PRECISA respeitar android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT. para mostrar uma atividade que abre uma caixa de diálogo para pedir que o usuário mude a serviço de emulação de cartão padrão para uma determinada categoria, conforme descrito no SDK.
Se as implementações de dispositivos informarem android.hardware.nfc
, elas:
- [C-4-1] PRECISA respeitar as intents android.nfc.action.NDEF_DISCOVERED. android.nfc.action.TAG_DISCOVERED (link em inglês) & android.nfc.action.TECH_DISCOVERED para mostrar uma atividade que atende às expectativas do desenvolvedor para essas intents como descritos no SDK.
Se as implementações de dispositivos informarem android.hardware.bluetooth
, elas:
- [C-5-1] PRECISA respeitar a opção "android.bluetooth.adapter.action.REQUEST_ENABLE" e mostrar uma atividade do sistema para permitir que o usuário ative o Bluetooth.
- [C-5-2] PRECISA respeitar "android.bluetooth.adapter.action.REQUEST_DISCOVERABLE" e mostrar uma atividade do sistema que solicita o modo detectável.
Se as implementações de dispositivos forem compatíveis com o recurso "Não perturbe", elas:
- [C-6-1] PRECISA implementar uma atividade que responda à intent.
ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS
, que, para implementações com UI_MODE_TYPE_NORMAL, PRECISA ser uma atividade em que o usuário pode conceder ou negar o acesso do app às configurações da política de Não perturbe.
Se as implementações de dispositivos permitirem que os usuários usem métodos de entrada de terceiros no dispositivo, eles:
- [C-7-1] PRECISA fornecer um mecanismo acessível ao usuário para adicionar e configurar
métodos de entrada de terceiros em resposta à
android.settings.INPUT_METHOD_SETTINGS
intenção.
Se as implementações de dispositivos oferecerem suporte a serviços de acessibilidade de terceiros, elas:
- [C-8-1] PRECISA respeitar o
android.settings.ACCESSIBILITY_SETTINGS
. de fornecer um mecanismo acessível ao usuário para ativar e desativar a serviços de acessibilidade de terceiros junto com os serviços serviços.
Caso as implementações do dispositivo incluam suporte ao Wi-Fi Easy Connect e exponham a a aplicativos de terceiros, elas:
- [C-9-1] PRECISA implementar Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI. APIs de intent conforme descrito na documentação do SDK.
Se as implementações de dispositivos oferecerem o modo de economia de dados, elas:
- [C-10-1] PRECISA fornecer nas configurações uma interface do usuário que gerencie
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
permitindo que os usuários adicionem ou removam aplicativos a lista de permissões.
Se as implementações de dispositivos não oferecerem o modo de economia de dados, elas:
- [C-11-1] PRECISA ter uma atividade para lidar com
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
mas PODE implementá-lo como um ambiente autônomo.
Se as implementações de dispositivos declararem suporte à câmera usando o
android.hardware.camera.any
, eles:
- [C-12-3] PRECISA processar e permitir apenas apps Android pré-instalados
para processar as seguintes intents
MediaStore.ACTION_IMAGE_CAPTURE
,MediaStore.ACTION_IMAGE_CAPTURE_SECURE
, eMediaStore.ACTION_VIDEO_CAPTURE
conforme descrito no documento do SDK.
Se as implementações de dispositivos informarem android.software.device_admin
, elas:
[C-13-1] PRECISA respeitar a intent
android.app.action.ADD_DEVICE_ADMIN
. invocar uma interface para levar o usuário à adição do administrador do dispositivo ao pelo sistema (ou permitir que ele a rejeite).[C-13-2] PRECISA respeitar as intents. android.app.action.PROVISION_MANAGED_PROFILE. android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD & android.app.action.START_ENCRYPTION e ter uma atividade para fornecer o fulfillment para essas intents, conforme descrito no SDK aqui.
Se as implementações de dispositivos declararem o android.software.autofill
sinalização de recurso, elas:
- [C-14-1] PRECISA implementar totalmente o
AutofillService
. eAutofillManager
e respeitar a política android.settings.REQUEST_SET_AUTOFILL_SERVICE, de mostrar um menu de configurações de aplicativo padrão para ativar e desativar o preenchimento automático e alterar o serviço de preenchimento automático padrão para o usuário.
Se as implementações de dispositivos incluem um app pré-instalado ou querem permitir a apps de terceiros para acessar as estatísticas de uso, eles:
- [C-SR-2] são FORTEMENTE RECOMENDADOS fornecer um mecanismo acessível ao usuário para conceder
ou revogar o acesso às estatísticas de uso em resposta aos
android.settings.ACTION_USAGE_ACCESS_CONFIG
para apps que declaram a
android.permission.PACKAGE_USAGE_STATS
permissão.
Se as implementações de dispositivos tiverem a intenção de proibir qualquer app, incluindo apps acessando as estatísticas de uso, eles:
- [C-15-1] PRECISA ter uma atividade que gerencie android.settings.ACTION_USAGE_ACCESS_CONFIG de intenção padrão, mas PRECISA implementá-lo como ambiente autônomo, ou seja, ter um padrão do usuário, como quando o acesso dele é recusado.
Se as implementações do dispositivo mostrarem links para as atividades especificadas pelo AutofillService_passwordsActivity (link em inglês) em "Configurações" ou links para senhas de usuário por um mecanismo semelhante:
- [C-16-1] PRECISA exibir esses links em todos os serviços de preenchimento automático instalados.
Se as implementações de dispositivos oferecem suporte à VoiceInteractionService
e têm mais
de um aplicativo que usa essa API instalada de cada vez, eles:
- [C-18-1] PRECISA respeitar o
android.settings.ACTION_VOICE_INPUT_SETTINGS
. de mostrar um menu de configurações padrão do app para entrada de texto por voz e assistência.
Se as implementações de dispositivos informarem o recurso android.hardware.audio.output
,
eles:
- [C-SR-3] É FORTEMENTE RECOMENDADO para respeitar android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA e As intents android.speech.tts.engine.GET_SAMPLE_TEXT têm uma atividade para fornecer o fulfillment para essas intents, conforme descrito no SDK.
O Android inclui suporte para protetores de tela interativos, anteriormente chamados como Sonhos. Os protetores de tela permitem que os usuários interajam com aplicativos quando um dispositivo conectado a uma fonte de energia está ocioso ou ancorado em uma base de mesa; Implementações do dispositivo:
- DEVE incluir suporte para protetores de tela e fornecer uma opção de configuração para
que os usuários configurem protetores de tela em resposta à
android.settings.DREAM_SETTINGS
.
Iniciar novos requisitos
Se as implementações de dispositivos informarem android.hardware.nfc.uicc
ou android.hardware.nfc.ese
,
eles:
- [C-19-1] PRECISA implementar o NfcAdapter.ACTION_TRANSACTION_DETECTED. API Intent (como "EVT_TRANSACTION" definida pela especificação técnica TS.26 da GSM Association - Requisitos do celular NFC).
Encerrar novos requisitos
3.2.4. Atividades em telas secundárias/múltiplas
Se as implementações de dispositivos permitem iniciar atividades normais do Android em mais de uma tela, eles:
- [C-1-1] PRECISA definir o
android.software.activities_on_secondary_displays
. flag de recurso. - [C-1-2] PRECISA garantir a compatibilidade das APIs, semelhante a uma atividade em execução no na tela principal.
- [C-1-3] PRECISA colocar a nova atividade na mesma tela que a atividade que
iniciou-o, quando a nova atividade é iniciada sem especificar um
exibir usando
ActivityOptions.setLaunchDisplayId()
API. - [C-1-4] PRECISA destruir todas as atividades quando uma tela com o
Display.FLAG_PRIVATE
é removida. - [C-1-5] PRECISA ocultar o conteúdo com segurança em todas as telas quando o dispositivo estiver bloqueado
com uma tela de bloqueio segura, a menos que o app permita aparecer sobre a tela de bloqueio
tela usando
Activity#setShowWhenLocked()
API. - DEVE ter
android.content.res.Configuration
que corresponde a essa tela para ser exibida, operar corretamente e manter a compatibilidade se uma atividade for iniciada tela secundária.
Se as implementações de dispositivos permitem iniciar atividades normais do Android em dispositivos secundários. e uma tela secundária tem a propriedade android.view.Display.FLAG_PRIVATE. sinalização:
- [C-3-1] Somente o proprietário da tela, do sistema e das atividades nessa tela PRECISA ser capaz de iniciar. Todos podem lançar uma tela com android.view.Display.FLAG_PUBLIC; .
3.3. Compatibilidade com API nativa
A compatibilidade do código nativo é desafiadora. Por isso, implementadores de dispositivos são:
- [C-SR-1] É MUITO RECOMENDADO usar as implementações das bibliotecas listado abaixo do projeto upstream do Android Open Source Project.
3.3.1. Interfaces binárias do aplicativo
O bytecode gerenciado do Dalvik pode chamar o código nativo fornecido no aplicativo
Arquivo .apk
como um arquivo .so
ELF compilado para o hardware do dispositivo apropriado.
do Terraform. Como o código nativo é muito dependente do processador,
tecnologia, o Android define diversas interfaces binárias de aplicativo (ABIs) em
o Android NDK.
Implementações de dispositivos:
- [C-0-1] PRECISA ser compatível com uma ou mais ABIs do Android NDK definidas.
- [C-0-2] PRECISA incluir suporte para código em execução no ambiente gerenciado para para código nativo, usando a Java Native Interface (JNI) semântica.
- [C-0-3] PRECISA ser compatível com a fonte (ou seja, com o cabeçalho) e compatível com binário (para ABI) com cada biblioteca necessária na lista a seguir.
- [C-0-5] PRECISA informar com precisão a interface binária do aplicativo nativa
(ABI) compatível com o dispositivo, pela
android.os.Build.SUPPORTED_ABIS
,android.os.Build.SUPPORTED_32_BIT_ABIS
e Parâmetrosandroid.os.Build.SUPPORTED_64_BIT_ABIS
, separados por vírgula lista de ABIs ordenadas da mais para a menos preferida. [C-0-6] PRECISA informar, usando os parâmetros acima, um subconjunto dos seguintes lista de ABIs e NÃO PODEM informar nenhuma ABI que não esteja na lista.
armeabi
(não tem mais suporte como destino pelo NDK)armeabi-v7a
arm64-v8a
x86
x86-64
[C-0-7] PRECISA criar todas as bibliotecas a seguir, fornecendo APIs nativas, disponíveis para apps que incluem código nativo:
- libaaudio.so (suporte a áudio nativo AAudio)
- libamidi.so (suporte a MIDI nativo, se o recurso
android.software.midi
é reivindicado conforme descrito na Seção 5.9) - libandroid.so (suporte a atividades nativas do Android)
- libc (biblioteca C)
- libcamera2ndk.so
- libdl (vinculador dinâmico)
- libEGL.so (gerenciamento de superfície nativo do OpenGL)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so (link em inglês)
- libicuuc.so
- libjnigraphics.so (libjnigraphics.so)
- liblog (geração de registros do Android)
- libmediandk.so (suporte a APIs de mídia nativa)
- libm (biblioteca matemática)
- libneuralnetworks.so (API Neural Networks)
- libOpenMAXAL.so (suporte a OpenMAX AL 1.0.1)
- libOpenSLES.so (suporte a áudio do OpenSL ES 1.0.1)
- libRS.so (em inglês)
- libstdc++ (suporte mínimo para C++)
- libvulkan.so (Vulkan)
- libz (compactação Zlib)
- Interface JNI
[C-0-8] NÃO PODE adicionar ou remover as funções públicas para as bibliotecas nativas listados acima.
[C-0-9] É NECESSÁRIO listar outras bibliotecas não AOSP expostas diretamente a apps de terceiros no
/vendor/etc/public.libraries.txt
.[C-0-10] NÃO PODE expor outras bibliotecas nativas, implementadas e fornecidos no AOSP como bibliotecas do sistema para apps de terceiros que segmentam a API nível 24 ou superior, conforme forem reservados.
[C-0-11] PRECISA exportar todo o OpenGL ES 3.1 e o Pacote de extensões do Android (link em inglês) símbolos de função, conforme definido no NDK, usando a biblioteca
libGLESv3.so
. Embora todos os símbolos PRECISAM estar presentes, a seção 7.1.4.1 descreve em mais detalhes os requisitos de quando a implementação completa de cada as funções correspondentes são esperadas.[C-0-12] É NECESSÁRIO exportar os símbolos de função do principal
Vulkan 1.0. Função Vulkan 1.1 , bem como os símbolosVK_KHR_surface
,VK_KHR_android_surface
,VK_KHR_swapchain
,VK_KHR_maintenance1
eVK_KHR_get_physical_device_properties2
extensões por meio dalibvulkan.so
. Embora todos os símbolos PRECISAM estar presentes, seção 7.1.4.2 descreve com mais detalhes os requisitos de quando implementação de cada função correspondente são esperadas.DEVE ser construído usando o código-fonte e arquivos de cabeçalho disponíveis no o Android Open Source Project upstream.
Versões futuras do Android podem apresentar suporte a mais ABIs do Google Cloud.
3.3.2. Compatibilidade de código nativo ARM de 32 bits
Se as implementações de dispositivos informarem compatibilidade com a ABI armeabi
, elas:
- [C-3-1] também PRECISA oferecer suporte a
armeabi-v7a
e informar esse suporte, conforme Oarmeabi
serve apenas para compatibilidade com versões anteriores de apps mais antigos.
Se as implementações de dispositivos informarem compatibilidade com a ABI armeabi-v7a
, para apps
usando essa ABI, eles:
[C-2-1] PRECISA incluir as seguintes linhas em
/proc/cpuinfo
e NÃO DEVE alteram os valores no mesmo dispositivo, mesmo quando são lidos por outras ABIs.Features:
, seguido por uma lista de todos os recursos opcionais da CPU ARMv7. suportado pelo dispositivo.CPU architecture:
, seguido por um número inteiro que descreve o dispositivo arquitetura ARM com suporte mais alto (por exemplo, "8" para dispositivos ARMv8).
[C-2-2] PRECISA sempre manter as seguintes operações disponíveis, mesmo caso em que a ABI é implementada em uma arquitetura ARMv8, seja por meio de suporte nativo de CPU ou emulação de software:
- Instruções do SWP e do SWPB.
- CP15ISB, CP15DSB e CP15DMB
[C-2-3] PRECISA incluir suporte para o SIMD avançado. (conhecido como NEON).
3,4 Compatibilidade com a Web
3.4.1. Compatibilidade com WebView
Se as implementações de dispositivos fornecerem uma implementação completa do
API android.webkit.Webview
, eles:
- [C-1-1] PRECISA informar
android.software.webview
. - [C-1-2] PRECISA usar o build do projeto Chromium.
do Android Open Source Project upstream no Android
14 ramificação para a implementação da
android.webkit.WebView
API. [C-1-3] A string do user agent informada pelo WebView PRECISA estar neste formato:
Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, como Gecko) Versão/4.0 $(CHROMIUM_VER) Celular Safari/537.36
- O valor da string $(VERSION) PRECISA ser igual ao valor de android.os.Build.VERSION.RELEASE para
- A string $(MODEL) PODE estar vazia, mas se não estiver vazia, PRECISA ter o mesmo valor que android.os.Build.MODEL.
- "Versão/$(BUILD)" PODE ser omitido, mas se estiver presente, $(BUILD) string PRECISA ser igual ao valor de android.os.Build.ID.
- O valor da string $(CHROMIUM_VER) PRECISA ser a versão do Chromium. no Android Open Source Project.
- As implementações de dispositivos podem omitir dispositivos móveis na string do user agent.
O componente WebView DEVE incluir suporte para o máximo possível de recursos HTML5 possível e, se for compatível com o recurso, DEVE estar em conformidade com especificação HTML5.
[C-1-4] PRECISA renderizar o conteúdo fornecido ou o conteúdo do URL remoto em um processo. diferente do aplicativo que instancia a WebView. Especificamente o processo separado do renderizador PRECISA conter privilégios menores, executar como um ID de usuário separado, não têm acesso ao diretório de dados do aplicativo, não têm acesso direto à rede e só têm acesso ao mínimo serviços do sistema pelo Binder. A implementação do WebView do AOSP atende esse requisito.
Se as implementações do dispositivo forem de 32 bits ou declararem a flag de recurso
android.hardware.ram.low
, eles estão isentos de C-1-3.
3.4.2. Compatibilidade de navegadores
Se as implementações de dispositivos incluem um aplicativo de navegador autônomo para fins gerais a navegação na Web, eles:
- [C-1-1] PRECISA oferecer suporte a cada uma dessas APIs associadas HTML5:
- [C-1-2] PRECISA ser compatível com HTML5/W3C. webstorage API e DEVE oferecer suporte às APIs HTML5/W3C API IndexedDB. Observe que, como o servidor órgãos de padronização de desenvolvimento estão em transição para favorecer o IndexedDB webstorage, o IndexedDB deve se tornar um componente obrigatório em versão futura do Android.
- PODE enviar uma string do user agent personalizado no aplicativo Navegador autônomo.
- DEVE implementar suporte para o máximo o HTML5 possível no Aplicativo de navegador (seja baseado no navegador WebKit upstream ou um substituto de terceiros).
No entanto, se as implementações de dispositivos não incluírem um navegador autônomo, do aplicativo, eles:
- [C-2-1] ainda PRECISA oferecer suporte aos padrões de intenção pública, conforme descrito em seção 3.2.3.1.
3,5 Compatibilidade comportamental de API
Implementações de dispositivos:
- [C-0-9] PRECISA garantir que a compatibilidade comportamental da API seja aplicada a todos apps instalados, a menos que eles sejam restritos conforme descrito em Seção 3.5.1.
- [C-0-10] NÃO PODE implementar a abordagem de lista de permissões que garante que a API compatibilidade comportamental somente para apps selecionados pelo dispositivo de implementação.
O comportamento de cada tipo de API (gerenciada, flexível, nativa e na Web) precisa ser consistente com a implementação preferencial do modelo Android Open Source Project. Algumas áreas específicas de compatibilidade são:
- [C-0-1] Os dispositivos NÃO PODEM mudar o comportamento ou a semântica de um intent padrão.
- [C-0-2] Os dispositivos NÃO PODEM mudar o ciclo de vida ou a semântica do ciclo de vida de um tipo específico de componente do sistema (como Serviço, Atividade, ContentProvider etc.).
- [C-0-3] Os dispositivos NÃO PODEM mudar a semântica de uma permissão padrão.
- Os dispositivos NÃO PODEM alterar as limitações aplicadas a aplicativos em segundo plano.
Mais especificamente, para aplicativos em segundo plano:
- [C-0-4] eles PRECISAM parar de executar callbacks registrados pelo
receba saídas do
GnssMeasurement
eGnssNavigationMessage
. - [C-0-5] Ele PRECISA limitar a frequência das atualizações
fornecidas ao app por meio do
LocationManager
a classe da API ou aWifiManager.startScan()
. - [C-0-6] Se o app for direcionado ao nível 25 da API ou mais recente, ele NÃO PODERÁ SER
permitem registrar receptores de transmissão para as transmissões implícitas de
intents padrão do Android no manifesto do app, a menos que a transmissão
requer uma
"signature"
ou"signatureOrSystem"
protectionLevel
permissão ou estão na lista de isenções. - [C-0-7] Se o app for direcionado ao nível 25 da API ou mais recente, ele PRECISA ser interrompido.
os serviços em segundo plano do app, como se ele tivesse chamado o
serviços
stopSelf()
a menos que o app seja colocado em uma lista de permissões temporária para processar um que fica visível para o usuário. - [C-0-8] Se o app for direcionado ao nível 25 da API ou mais recente, ele PRECISA libera os wakelocks que o app retém.
- [C-0-4] eles PRECISAM parar de executar callbacks registrados pelo
receba saídas do
- [C-0-11] Os dispositivos PRECISAM retornar os seguintes provedores de segurança como os primeiros
sete valores de matriz do
Security.getProviders()
, na ordem indicada e com os nomes informados (conforme retornado peloProvider.getName()
) e classes, a menos que o app tenha modificado a lista porinsertProviderAt()
ouremoveProvider()
. Dispositivos PODE retornar provedores adicionais depois da lista especificada de provedores a seguir.- AndroidNSSP:
android.security.net.config.NetworkSecurityConfigProvider
- AndroidOpenSSL:
com.android.org.conscrypt.OpenSSLProvider
- CertPathProvider:
sun.security.provider.CertPathProvider
- Alternativa AndroidKeyStoreBC:
android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
- BC –
com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
- HarmonyJSSE:
com.android.org.conscrypt.JSSEProvider
- AndroidKeyStore:
android.security.keystore.AndroidKeyStoreProvider
- AndroidNSSP:
A lista acima não está completa. Os testes do conjunto de teste de compatibilidade (CTS) partes significativas da plataforma para compatibilidade comportamental, mas não todas. É responsabilidade do implementador garantir a compatibilidade comportamental com o Android Open Source Project. Por isso, os implementadores de dispositivos DEVE usar o código-fonte disponível pelo Android Open Source Project, quando possível, em vez de reimplementar partes significativas do sistema.
3.5.1. Restrição de aplicativo
Se as implementações de dispositivos implementam um mecanismo reservado para restringir apps (por exemplo, mudar ou restringir comportamentos de APIs descritos no SDK) e se esse mecanismo for mais restritivo que o bucket restrito do App em espera, eles:
- [C-1-1] PRECISA permitir que o usuário confira a lista de apps restritos.
- [C-1-2] PRECISA oferecer recursos ao usuário para ativar / desativar todos esses recursos. restrições de propriedade a cada app.
[C-1-3] PRECISA não aplicar automaticamente essas restrições proprietárias sem evidências de mau comportamento de saúde do sistema, mas PODEM aplicar restrições nos apps após a detecção de mau comportamento de saúde do sistema, como wakelocks travados, serviços e outros critérios. Os critérios podem ser determinados pelo dispositivo. implementadores, mas PRECISA estar relacionado ao impacto do app na integridade do sistema. Outra opção que não são puramente relacionados à integridade do sistema, como falta de popularidade no mercado, NÃO PODE ser usada como critério.
[C-1-4] Não PRECISA aplicar automaticamente essas restrições de propriedade a apps. quando um usuário tiver desativado as restrições de apps manualmente e PODE sugerir que o usuário para aplicar essas restrições de propriedade.
[C-1-5] PRECISA informar os usuários se essas restrições proprietárias forem aplicadas a um app automaticamente. Essas informações DEVEM ser fornecidas no período de 24 horas anteriores à aplicação dessas restrições de propriedade.
[C-1-6] PRECISA retornar "true" para ActivityManager.isBackgroundRestricted(). para qualquer chamada de API de um app.
[C-1-7] NÃO PODE restringir o app em primeiro plano que é explicitamente usado por o usuário.
[C-1-8] PRECISA suspender essas restrições reservadas nos apps sempre que um o usuário começa a usar o app explicitamente, tornando-o o primeiro plano para o aplicativo.
[C-1-10] PRECISA fornecer um documento ou site público e claro que descreva como as restrições de propriedade são aplicadas. Este documento ou site PRECISA ser pode ser vinculado aos documentos do SDK do Android e PRECISA incluir:
- Condições de acionamento de restrições reservadas.
- O que e como um app pode ser restrito.
- Como um app pode ser isento dessas restrições.
- Como um app pode solicitar isenção de restrições reservadas, se oferecer suporte a essa isenção para apps que o usuário pode instalar.
Se um app estiver pré-instalado no dispositivo e nunca tiver sido usado explicitamente por um usuário por mais de 30 dias, [C-1-3] [C-1-5] são isentos.
Se as implementações do dispositivo estenderem as restrições do app implementadas no AOSP:
- [C-2-1]PRECISA seguir a implementação descrita neste documento.
3.5.2. Hibernação do aplicativo
Se as implementações do dispositivo incluem a hibernação do app incluída no AOSP ou estender o recurso incluído no AOSP, eles:
- [C-1-1] PRECISA atender a todos os requisitos da seção 3.5.1, exceto: [C-1-6] e [C-1-3].
- [C-1-2] Só é preciso aplicar a restrição no app para um usuário quando há evidências de que o usuário não usa o app há algum tempo. Isso é FORTEMENTE RECOMENDADO que seja de um mês ou mais. O uso PRECISA ser definida pela interação explícita do usuário pelo UsageStats#getLastTimeVisible() API ou qualquer item que faça com que um app saia do estado de fechamento forçado, incluindo vinculações de serviço, de provedor de conteúdo, transmissões explícitas etc., que será acompanhado por uma nova API UsageStats#getLastTimeAnyComponentUsed().
- [C-1-3] É PRECISO aplicar restrições que afetam todos os usuários de dispositivos quando há é uma evidência de que o pacote não foi usado por QUALQUER usuário por algum período de tempo de resposta. É RECOMENDADO que a duração seja de um mês ou mais.
- [C-1-4] NÃO PODE deixar o app incapaz de responder a intents de atividade, vinculações de serviço, solicitações de provedor de conteúdo ou transmissões explícitas.
A hibernação do app no AOSP atende aos requisitos acima.
3,6 Namespaces da API
O Android segue as convenções de namespace de pacote e classe definidas pela de programação centrada no usuário. Para garantir a compatibilidade com aplicativos de terceiros, os implementadores de dispositivos NÃO PODEM fazer nenhuma modificação proibida (veja abaixo) em esses namespaces de pacote:
java.*
javax.*
sun.*
android.*
androidx.*
com.android.*
Ou seja, eles:
- [C-0-1] NÃO PODE modificar as APIs expostas publicamente na plataforma Android mudando qualquer método ou assinatura de classe, ou removendo classes ou campos.
- [C-0-2] NÃO PODE adicionar elementos expostos publicamente (como classes ou interfaces, campos ou métodos para classes ou interfaces existentes) ou testar ou APIs do sistema às APIs nos namespaces acima. Um anúncio "publicamente exposto elemento" é qualquer construção que não esteja decorada com a palavra-chave "@hide". marcador como usada no código-fonte upstream do Android.
Os implementadores de dispositivos PODEM modificar a implementação subjacente das APIs, mas essas modificações:
- [C-0-3] NÃO PODE afetar o comportamento declarado e a assinatura na linguagem Java do as APIs expostas publicamente.
- [C-0-4] NÃO PODE ser anunciado nem exposto a desenvolvedores.
No entanto, os implementadores de dispositivos PODEM adicionar APIs personalizadas fora do Android padrão mas as APIs personalizadas:
- [C-0-5] NÃO PODE estar em um namespace pertencente ou se referir a outra
organização. Por exemplo, os implementadores de dispositivos NÃO PODEM adicionar APIs à
com.google.*
ou namespace semelhante: somente o Google pode fazer isso. Da mesma forma, O Google NÃO PODE adicionar APIs às contas de os namespaces. - [C-0-6] PRECISA ser empacotado em uma biblioteca compartilhada do Android para que apenas os apps que os usam explicitamente (por meio do mecanismo <uses-library>) são ser afetados pelo aumento do uso de memória dessas APIs.
Os implementadores de dispositivos podem adicionar APIs personalizadas em idiomas nativos, fora do NDK Mas as APIs personalizadas:
- [C-1-1] NÃO PODE estar em uma biblioteca do NDK ou de propriedade de outra pessoa da sua organização, conforme descrito aqui.
Se um implementador de dispositivos propuser a melhoria de um dos namespaces de pacote acima Por exemplo, adicionando uma nova funcionalidade útil a uma API existente API), o implementador DEVIA acessar source.android.com. e iniciar o processo de contribuição de mudanças e de acordo com as informações no site.
Observe que as restrições acima correspondem às convenções padrão de nomenclatura APIs na linguagem de programação Java; seção tem como objetivo reforçar e torná-las vinculativas por meio da inclusão nesta Compatibilidade Definição.
3,7 Compatibilidade de ambiente de execução
Implementações de dispositivos:
[C-0-1] PRECISA oferecer suporte ao formato completo Dalvik Executable (DEX) e especificação e semântica de bytecode Dalvik.
[C-0-2] É NECESSÁRIO configurar os ambientes de execução do Dalvik para alocar memória de acordo com a plataforma Android upstream e conforme especificado pelo na tabela a seguir. Consulte a seção 7.1.1 para definições de tamanho e densidade da tela).
DEVE usar o Android RunTime (ART), a referência upstream implementação do Dalvik Executable Format e a referência no sistema de gerenciamento de pacotes da implementação.
Realize testes de fuzz em vários modos de execução e as arquiteturas de destino para garantir a estabilidade do ambiente de execução. Consulte JFuzz (link em inglês) e DexFuzz no site do Android Open Source Project.
Os valores de memória especificados abaixo são considerados valores mínimos e as implementações de dispositivos podem alocar mais memória por aplicativo.
Layout da tela | Densidade da tela | Memória mínima do aplicativo |
---|---|---|
Relógio Android | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | ||
160 dpi (mdpi) | ||
180 dpi (180dpi) | ||
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | 36MB | |
240 dpi (hdpi) | ||
280 dpi (280dpi) | ||
320 dpi (xhdpi) | 48MB | |
360 dpi (360dpi) | ||
400 dpi (400dpi) | 56MB | |
420 dpi (420dpi) | 64MB | |
480 dpi (xxhdpi) | 88MB | |
560 dpi (560dpi) | 112MB | |
640 dpi (xxxhdpi) | 154MB | |
pequeno/normal | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | ||
160 dpi (mdpi) | ||
180 dpi (180dpi) | 48MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | ||
320 dpi (xhdpi) | 80MB | |
360 dpi (360dpi) | ||
400 dpi (400dpi) | 96MB | |
420 dpi (420dpi) | 112MB | |
480 dpi (xxhdpi) | 128MB | |
560 dpi (560dpi) | 192MB | |
640 dpi (xxxhdpi) | 256MB | |
grande | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | 48MB | |
160 dpi (mdpi) | ||
180 dpi (180dpi) | 80MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | 96MB | |
320 dpi (xhdpi) | 128MB | |
360 dpi (360dpi) | 160MB | |
400 dpi (400dpi) | 192MB | |
420 dpi (420dpi) | 228MB | |
480 dpi (xxhdpi) | 256MB | |
560 dpi (560dpi) | 384MB | |
640 dpi (xxxhdpi) | 512 MB | |
extra grande | 120 dpi (ldpi) | 48MB |
140 dpi (140dpi) | 80MB | |
160 dpi (mdpi) | ||
180 dpi (180dpi) | 96MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | 144MB | |
320 dpi (xhdpi) | 192MB | |
360 dpi (360dpi) | 240MB | |
400 dpi (400dpi) | 288MB | |
420 dpi (420dpi) | 336MB | |
480 dpi (xxhdpi) | 384MB | |
560 dpi (560dpi) | 576MB | |
640 dpi (xxxhdpi) | 768MB |
3,8. Compatibilidade da interface do usuário
3.8.1. Tela de início (tela inicial)
O Android inclui um aplicativo de inicialização (tela inicial) e suporte para aplicativos de terceiros para substituir o inicializador do dispositivo (tela inicial).
Se as implementações de dispositivos permitirem que aplicativos de terceiros substituam o dispositivo tela inicial, eles:
- [C-1-1] PRECISA declarar o recurso da plataforma
android.software.home_screen
. - [C-1-2] PRECISA retornar
AdaptiveIconDrawable
. quando o aplicativo de terceiros usa a tag<adaptive-icon>
para fornecer o ícone e oPackageManager
para recuperar ícones são chamados.
Se as implementações do dispositivo incluem uma tela de início padrão compatível com aplicativos fixação de atalhos, eles:
- [C-2-1] PRECISA informar
true
paraShortcutManager.isRequestPinShortcutSupported()
. - [C-2-2] PRECISA ter affordance do usuário antes de adicionar um atalho solicitado.
por apps usando o
ShortcutManager.requestPinShortcut()
Método de API. - [C-2-3] PRECISA oferecer suporte a atalhos fixados e a atalhos dinâmicos e estáticos conforme documentado na página Atalhos de apps.
Por outro lado, se as implementações de dispositivos não oferecerem suporte à fixação no aplicativo de atalhos, eles:
- [C-3-1] PRECISA informar
false
paraShortcutManager.isRequestPinShortcutSupported()
.
Se as implementações de dispositivos implementam uma tela de início padrão que fornece acesso a atalhos adicionais fornecidos por aplicativos de terceiros através do Atalhos do Gerenciador API, eles:
- [C-4-1] PRECISA oferecer suporte a todos os recursos de atalho documentados (por exemplo, estático e
atalhos dinâmicos, fixação de atalhos) e implementar totalmente as APIs do
ShortcutManager
Classe da API.
Se as implementações do dispositivo incluem um app de tela de início padrão que mostra selos para os ícones do app, eles:
- [C-5-1] PRECISA respeitar os
NotificationChannel.setShowBadge()
. Método de API. Em outras palavras, mostre uma affordance visual associada ao ícone do app se o valor definido comotrue
e não mostra nenhum esquema de selos de ícones do app quando todos dos canais de notificação do app definiram o valor comofalse
. - PODE substituir os selos de ícones do app pelo esquema de selos reservado quando
os aplicativos de terceiros são compatíveis com o esquema de selos reservado
com o uso de APIs proprietárias, mas DEVE usar os recursos e valores
fornecidos pelas APIs de selos de notificação descritas no SDK
, como o
Notification.Builder.setNumber()
e oNotification.Builder.setBadgeIconType()
API.
Se as implementações de dispositivos forem compatíveis monocromático , estes ícones:
- [C-6-1] PRECISA ser usada apenas quando o usuário ativar esse recurso explicitamente (por exemplo, via menu do seletor de configurações ou plano de fundo).
3.8.2. Widgets
O Android oferece suporte a widgets de apps de terceiros definindo um tipo de componente e API e ciclo de vida correspondentes que permite que os aplicativos exponham uma "AppWidget" para o usuário final.
Se as implementações de dispositivos forem compatíveis com widgets de apps de terceiros, elas:
- [C-1-1] PRECISA declarar suporte ao recurso da plataforma
android.software.app_widgets
: [C-1-2] PRECISA incluir suporte integrado para AppWidgets e expor funcionalidades da interface do usuário para adicionar, configurar, exibir e remover AppWidgets
[C-1-3] PRECISA renderizar widgets de tamanho 4 x 4. no tamanho padrão da grade. Veja as Diretrizes de design para widgets de apps na documentação do SDK do Android para mais detalhes.
PODE oferecer suporte a widgets de aplicativos na tela de bloqueio.
Se as implementações de dispositivos forem compatíveis com widgets de apps de terceiros e itens no app fixação de atalhos, eles:
- [C-2-1] PRECISA informar
true
paraAppWidgetManager.html.isRequestPinAppWidgetSupported()
. - [C-2-2] PRECISA ter affordance do usuário antes de adicionar um atalho solicitado.
por apps usando o
AppWidgetManager.requestPinAppWidget()
Método de API.
3.8.3. Notificações
O Android inclui Notification
e
NotificationManager
APIs que permitem que desenvolvedores de apps de terceiros notifiquem os usuários sobre eventos importantes e
atrair usuários atenção usando os componentes de hardware (por exemplo, som, vibração
e luz) e os recursos de software (por exemplo, aba de notificações, barra do sistema) do
dispositivo.
3.8.3.1. Apresentação de notificações
Se as implementações de dispositivos permitirem que apps de terceiros notifiquem usuários sobre eventos importantes, elas:
- [C-1-1] PRECISA ser compatível com notificações que usam recursos de hardware, conforme descrito em na documentação do SDK e, na medida do possível, com a implementação do dispositivo ao hardware. Por exemplo, se uma implementação de dispositivo inclui uma vibração, ela PRECISA implementar corretamente as APIs de vibração. Se a implementação de um dispositivo não tiver as APIs correspondentes PRECISAM ser implementadas como ambiente autônomo. Esse comportamento é detalhado na seção 7.
- [C-1-2] PRECISA renderizar corretamente todos os recursos. (ícones, arquivos de animação etc.) fornecidos nas APIs ou na Guia de estilo de ícone da barra de status/sistema, embora possam oferecer uma experiência alternativa ao usuário para notificações do que o fornecido pela implementação de referência do Android Open Source.
- [C-1-3] PRECISA respeitar e implementar corretamente os comportamentos descritos as APIs para atualizar, remover e agrupar notificações.
- [C-1-4] PRECISA fornecer o comportamento completo do NotificationChannel. A API é documentada no SDK.
- [C-1-5] PRECISA fornecer uma funcionalidade do usuário para bloquear e modificar uma determinada notificações de apps de terceiros por canal e pacote de app.
- [C-1-6] Também PRECISA fornecer uma funcionalidade de usuário para exibir notificações excluídas. canais.
[C-1-7] PRECISA renderizar corretamente todos os recursos (imagens, adesivos, ícones etc.) fornecido por Notification.MessagingStyle. ao lado do texto da notificação sem precisar de interação adicional do usuário. Para exemplo, PRECISA mostrar todos os recursos, incluindo os ícones fornecidos por android.app.Person (link em inglês) em uma conversa em grupo definida pelo setGroupConversation.
[C-SR-1] É FORTEMENTE RECOMENDADO fornecer uma affordance para o usuário controlar as notificações que são expostas a apps que receberam a permissão Permissão do listener de notificações. A granularidade PRECISA ser de modo que o usuário possa controlar quais tipos de notificação são selecionados para cada listener interligados a esse ouvinte. Os tipos PRECISAM incluir "conversas", "alertas", "silencioso" e "importante em andamento" notificações.
[C-SR-2] São FORTEMENTE RECOMENDADOS fornecem uma affordance para os usuários especificarem a serem excluídos da notificação de um listener de notificações específico.
[C-SR-3] É FORTEMENTE RECOMENDADO para mostrar automaticamente uma funcionalidade do usuário para bloquear notificações de apps de terceiros em cada canal e app no nível do pacote depois que o usuário dispensa essa notificação várias vezes.
DEVE ser compatível com notificações avançadas.
DEVE apresentar algumas notificações de prioridade mais alta como notificações de alerta.
DEVE ter um recurso do usuário para adiar notificações.
PODE gerenciar apenas a visibilidade e o momento em que os apps de terceiros podem notificar usuários de eventos importantes para reduzir problemas de segurança, como distração do motorista.
O Android 11 introduz o suporte a notificações de conversa, que são notificações que usam MessagingStyle e fornece um ID de atalho para Pessoas publicado.
Implementações de dispositivos:
- [C-SR-4] É FORTEMENTE RECOMENDADO para agrupar e mostrar
conversation notifications
antes de notificações não relacionadas a conversas, com exceção de notificações de serviços em primeiro plano em andamento eimportance:high
notificações.
Se as implementações de dispositivos oferecem suporte a conversation notifications
e o app fornece os dados necessários para
bubbles
, eles:
- [C-SR-5] É MUITO RECOMENDADO mostrar esta conversa como um balão. A implementação do AOSP atende a esses requisitos com a interface padrão do sistema. Configurações e acesso rápido.
Se as implementações de dispositivos forem compatíveis com notificações avançadas, elas:
- [C-2-1] PRECISA usar os recursos exatos que
fornecido pelo
Notification.Style
Classe de API e subclasses para os elementos de recurso apresentados. - DEVE apresentar todos os elementos do recurso (por exemplo,
ícone, título e texto do resumo) definidos no
Notification.Style
A classe da API e as subclasses dela.
As notificações de alerta são apresentadas ao usuário à medida que chegam, independentemente da superfície em que Se as implementações de dispositivos forem compatíveis com avisos notificações, eles podem fazer o seguinte:
- [C-3-1] PRECISA usar a visualização e os recursos das notificações de informações básicas
conforme descrito nos
Notification.Builder
Classe da API quando as notificações de alerta são apresentadas. - [C-3-2] PRECISA exibir as ações fornecidas pelo
Notification.Builder.addAction()
com o conteúdo da notificação sem interação adicional do usuário conforme descrito no SDK.
3.8.3.2. Serviço de listener de notificações
O Android inclui NotificationListenerService
.
APIs que permitem que os aplicativos (uma vez ativados explicitamente pelo usuário) recebam uma cópia dos
todas as notificações à medida que são postadas ou atualizadas.
Implementações de dispositivos:
- [C-0-1] PRECISA atualizar todas as notificações de forma correta e imediata a todos os serviços de listener instalados e ativados pelo usuário, incluindo todos os serviços todos os metadados anexados ao objeto de notificação.
- [C-0-2] PRECISA respeitar os
snoozeNotification()
. chamada de API, dispensar a notificação e fazer um callback após o adiamento que é definida na chamada de API.
Se as implementações de dispositivos tiverem uma funcionalidade de usuário para adiar notificações, elas:
- [C-1-1] PRECISA refletir o status de notificações adiadas corretamente
por meio das APIs padrão, como
NotificationListenerService.getSnoozedNotifications()
- [C-1-2] PRECISA disponibilizar essa funcionalidade do usuário para adiar notificações. de cada app de terceiros instalado, a menos que sejam de persistentes/em primeiro plano.
3.8.3.3. Não perturbe (Não perturbe) / Modo de prioridade
Se as implementações de dispositivos forem compatíveis com o recurso Não perturbe (também chamado de modo de prioridade), eles:
- [C-1-1] PRECISA, para quando a implementação do dispositivo fornece um meio para o usuário para dar ou negar o acesso de apps de terceiros à configuração da política de Não perturbe exibir Regras automáticas de NP criados pelos aplicativos junto com as regras predefinidas e criadas pelo usuário.
- [C-1-3] PRECISA respeitar o
suppressedVisualEffects
. transmitidos pela classeNotificationManager.Policy
e se um app tiver configurado uma das opções BIGPRESSED_EF_SCREEN_ON, ele DEVE indicar ao usuário que o os efeitos visuais são suprimidos no menu de configurações do modo Não perturbe.
3.8.4. APIs Assist
O Android inclui as APIs Assist para permitir que os aplicativos escolham a quantidade de informações do contexto atual compartilhado com o assistente no dispositivo.
Se as implementações de dispositivos forem compatíveis com a ação de assistência, elas:
- [C-2-1] PRECISA indicar claramente para o usuário final quando o contexto é compartilhado.
de uma destas formas:
- Sempre que o app assistivo acessa o contexto, uma tela branca luz nas bordas da tela que atingem ou excedem a duração e Brilho da implementação do Android Open Source Project.
- Para o app assistivo pré-instalado, fornecer uma funcionalidade do usuário menos de duas navegações para fora o menu de configurações padrão da entrada de texto por voz e do app Google Assistente, e só compartilha o contexto quando o app assistivo é invocado explicitamente pelo ao usuário por meio de uma hotword ou entrada de tecla de navegação de assistência.
- [C-2-2] A interação designada para iniciar o app assistivo, conforme descrito.
na seção 7.2.3 PRECISA iniciar o cluster
ou seja, o app que implementa
VoiceInteractionService
, ou uma atividade que processa a intentACTION_ASSIST
.
3.8.5. Alertas e avisos
Os aplicativos podem usar o Toast
API para exibir ao usuário final strings não modais curtas que desaparecem após uma
um breve período e use o TYPE_APPLICATION_OVERLAY
API do tipo janela para mostrar janelas de alerta como uma sobreposição sobre outros apps.
Se as implementações de dispositivos incluírem uma saída de tela ou vídeo, elas:
[C-1-1] PRECISA fornecer recursos do usuário para impedir que um app mostre alertas. Janelas que usam a classe
TYPE_APPLICATION_OVERLAY
, A implementação do AOSP atende a esse requisito porque tem controles na aba de notificações.[C-1-2] PRECISA respeitar a API Toast e exibir avisos de aplicativos para usuários finais em algumas visível.
3.8.6. Temas
O Android fornece “temas” como mecanismo para os aplicativos aplicarem estilos toda uma atividade ou aplicativo.
O Android inclui um "Holo" e um "Material" família de temas como um conjunto de estilos definidos que os desenvolvedores de aplicativos usem se quiserem corresponder Aparência do tema Holo conforme definido pelo SDK do Android.
Se as implementações de dispositivos incluírem uma saída de tela ou vídeo, elas:
- [C-1-1] NÃO PODE alterar nenhum dos atributos do tema Holo expostos a aplicativos conteinerizados.
- [C-1-2] PRECISA oferecer suporte à família de temas "Material" e NÃO PODE alterar nenhum deles Atributos de tema do Material Design ou os ativos delas expostos a aplicativos.
[C-1-3] PRECISA definir "sans-serif" família de fontes para Roboto versão 2.x para os idiomas que a Roboto suporta ou fornecer uma affordance de usuário para alterar a fonte usada para o "sans-serif" família de fontes para Roboto versão 2.x para as linguagens com suporte da Roboto.
[C-1-4] PRECISA gerar paletas de tons de cores dinâmicas conforme especificado no AOSP documentação de
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
(consulteandroid.theme.customization.system_palette
eandroid.theme.customization.theme_style
).[C-1-5] PRECISA gerar paletas de tons de cores dinâmicas usando estilos de tema de cores. numerada na
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
documentação (consulteandroid.theme.customization.theme_styles
), ou seja,TONAL_SPOT
,VIBRANT
,EXPRESSIVE
,SPRITZ
,RAINBOW
,FRUIT_SALAD
, eMONOCHROMATIC
."Cor da origem" usada para gerar paletas de tons de cores dinâmicas quando enviada com
android.theme.customization.system_palette
(conforme documentado emSettings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
).[C-1-6] PRECISA ter um valor de chroma
CAM16
de 5 ou maior.DEVE ser derivado do plano de fundo via
com.android.systemui.monet.ColorScheme#getSeedColors
, que fornece múltiplas cores de origem válidas para escolher uma.DEVE usar o valor
0xFF1B6EF3
, se nenhuma das cores fornecidas atender o requisito de cor de origem acima.
O Android também inclui uma família de temas “Padrão do dispositivo” como um conjunto de estilos definidos que os desenvolvedores de aplicativos podem usar se quiserem combinar com a aparência do device, conforme definido pelo implementador do dispositivo.
- As implementações de dispositivos podem modificar os atributos de tema padrão do dispositivo expostos a aplicativos conteinerizados.
O Android oferece suporte a um tema variante com barras de sistema translúcidas, o que permite desenvolvedores de aplicativos para preencher a área atrás da barra de status e navegação com o conteúdo do app. Para que o desenvolvedor tenha uma experiência consistente do navegador, é importante que o estilo do ícone da barra de status seja diferentes implementações de dispositivos.
Se as implementações de dispositivos incluírem uma barra de status do sistema, elas:
- [C-2-1] PRECISA usar branco para ícones de status do sistema (como intensidade do sinal e nível de bateria) e as notificações emitidas pelo sistema, a menos que o ícone seja que indicam um status problemático ou um aplicativo solicita uma barra de status clara usando o valor WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS .
- [C-2-2] Implementações de dispositivos Android PRECISAM mudar a cor do sistema ícones de status para preto (para mais detalhes, consulte R.style) quando um app solicita uma barra de status clara.
3.8.7. Planos fundo interativos
O Android define um tipo de componente e a API e o ciclo de vida correspondentes que permitem aplicativos para expor um ou mais "Planos de fundo interativos" para o usuário final. Planos de fundo interativos são animações, padrões ou imagens semelhantes com recursos de entrada limitados que são exibidos como um plano de fundo, atrás de outros aplicativos conteinerizados.
O hardware é considerado capaz de executar planos de fundo interativos de forma confiável se puder ser executado todos os planos de fundo interativos, sem limitações de funcionalidade, com um frame razoável sem efeitos adversos nas outras aplicações. Se as limitações no fazer com que planos de fundo e/ou aplicativos travem, mau funcionamento, consumam excesso de energia da CPU ou da bateria ou execução em frame rates inaceitavelmente baixos, o hardware é considerado incapaz de executar o plano de fundo interativo. Por exemplo, algumas planos de fundo interativos podem usar um contexto OpenGL 2.0 ou 3.x para renderizar seu conteúdo. O plano de fundo interativo não será executado de maneira confiável em hardware não compatível com várias Contextos do OpenGL porque o uso do plano de fundo interativo de um contexto do OpenGL pode entrar em conflito com outros aplicativos que também usam um contexto OpenGL.
- Implementações de dispositivos capazes de executar planos de fundo interativos de forma confiável, conforme descrito acima DEVEM implementar planos de fundo interativos.
Se as implementações de dispositivos implementam planos de fundo interativos, elas:
- [C-1-1] PRECISA informar a flag de recurso da plataforma android.software.live_wallpaper.
3.8.8. Troca de atividades
O código-fonte upstream do Android inclui as tela de visão geral, interface do usuário de nível de sistema para alternar tarefas e exibir os acessos recentes atividades e tarefas usando uma imagem em miniatura da interface gráfica do aplicativo no momento em que o usuário saiu do aplicativo pela última vez.
Implementações de dispositivos incluindo a tecla de navegação da função Recentes, conforme detalhado em A seção 7.2.3 PODE alterar a interface.
Se as implementações do dispositivo, incluindo a tecla de navegação da função Recentes, conforme detalhado em seção 7.2.3 alterar a interface, eles:
- [C-1-1] PRECISA oferecer suporte a pelo menos até sete atividades exibidas.
- DEVE exibir pelo menos o título de quatro atividades por vez.
- [C-1-2] PRECISA implementar o comportamento de fixação da tela. e forneça ao usuário um menu de configurações para ativar ou desativar o recurso.
- DEVE exibir a cor de destaque, o ícone e o título da tela em "Recentes".
- DEVE exibir uma affordance de fechamento ("x"), mas PODE postergar isso até que o usuário interaja com as telas.
- DEVE implementar um atalho para alternar facilmente para a atividade anterior.
- DEVE acionar a ação de alternância rápida entre as duas usadas mais recentemente quando a tecla de função Recentes é tocada duas vezes.
- DEVE acionar o modo de várias janelas de tela dividida, se compatível, quando o Manter a tecla de funções recentes pressionada.
- PODE exibir recentes afiliadas como um grupo que é movido em conjunto.
- [C-SR-1] É FORTEMENTE RECOMENDADO usar o usuário Android upstream (ou uma interface semelhante baseada em miniatura) para a tela de visão geral.
3.8.9. Gerenciamento de entradas
O Android inclui suporte a Gerenciamento de entradas e suporte a editores de método de entrada de terceiros.
Se as implementações de dispositivos permitirem que os usuários usem métodos de entrada de terceiros no dispositivo, eles:
- [C-1-1] PRECISA declarar o recurso de plataforma android.software.input_methods e oferecem suporte a APIs do IME, conforme definido na documentação do SDK do Android.
3.8.10. Controle de mídia da tela de bloqueio
A API Remote Control Client foi descontinuada do Android 5.0 e substituída pela Modelo de notificação de mídia que permite que aplicativos de mídia se integrem a controles de mídia que são exibidos na tela de bloqueio.
3.8.11. Protetores de tela (antigo Dreams)
Consulte as configurações na seção 3.2.3.5. de configurar protetores de tela.
3.8.12. Local
Se as implementações do dispositivo incluírem um sensor de hardware (por exemplo, GPS) capaz de de fornecer as coordenadas do local,
- [C-1-2] PRECISA mostrar o status atual do local. no menu "Local" em "Configurações".
- [C-1-3] NÃO PODE mostrar os modos de localização no menu "Local" em "Configurações".
3.8.13. Unicode e fonte
O Android inclui suporte para os caracteres de emoji definidos em Unicode 10.0 (link em inglês).
Se as implementações de dispositivos incluírem uma saída de tela ou vídeo, elas:
- [C-1-1] PRECISA renderizar esses caracteres de emoji em um glifo de cor.
- [C-1-2] PRECISA incluir suporte para:
- Fonte Roboto 2 com pesos diferentes — Sans Serif-thin, sans-serif-light, Sans Serif-medium, sans-serif-preto, sans-serif condensado, Sans Serif-condensed light nos idiomas disponíveis no dispositivo.
- Cobertura completa em Unicode 7.0 para idiomas latinos, gregos e cirílicos, incluindo os Intervalos latinos estendidos A, B, C e D, e todos os glifos na moeda bloco de símbolos do Unicode 7.0.
- [C-1-3] NÃO PODE remover nem modificar NotoColorEmoji.tff na imagem do sistema. (É aceitável adicionar uma nova fonte de emoji para substituir o emoji em NotoColorEmoji.tff).
- DEVE apoiar o tom de pele e os diversos emojis de família, conforme especificado nos Relatório técnico do Unicode no 51.
Se as implementações de dispositivos incluírem um IME, elas:
- DEVEM fornecer um método de entrada ao usuário para esses caracteres de emoji.
O Android inclui suporte para renderizar fontes de Mianmar. Mianmar tem várias fontes não compatíveis com Unicode, conhecidas como "Zawgyi", para renderizar Mianmar idiomas.
Se as implementações de dispositivos forem compatíveis com o birmanês, elas:
- [C-2-1] PRECISA renderizar texto com fonte compatível com Unicode como padrão. uma fonte não compatível com Unicode NÃO PODE ser definida como padrão, a menos que o usuário escolhe no seletor de idioma.
- [C-2-2] PRECISA ser compatível com uma fonte Unicode e uma fonte não compatível com Unicode se um fonte não compatível com Unicode é compatível com o dispositivo. Não Unicode fonte compatível NÃO PODE remover ou substituir a fonte Unicode.
- [C-2-3] PRECISA renderizar texto com fonte não compatível com Unicode SOMENTE SE uma código de idioma com código de script Qaag (link em inglês) é especificado (por exemplo, my-Qaag). Nenhum outro código ISO de idioma ou região (seja atribuído, não atribuído ou reservado) pode ser usado para se referir a códigos não Unicode fonte compatível com Mianmar. Os desenvolvedores de apps e os autores de páginas da Web podem especificar my-Qaag como o código de idioma designado, como faria para qualquer outro idioma.
3.8.14. Várias janelas
Se as implementações de dispositivos puderem exibir várias atividades em ao mesmo tempo, eles:
- [C-1-1] PRECISA implementar esses modos de várias janelas de acordo com a comportamentos de aplicativos e APIs descritos no SDK do Android documentação de suporte do modo de várias janelas e conheça os seguintes requisitos:
- [C-1-2] PRECISA respeitar
android:resizeableActivity
. definido por um app no arquivoAndroidManifest.xml
, conforme descrito em deste SDK. - [C-1-3] NÃO PODE oferecer o modo de tela dividida ou formato livre se a altura da tela é inferior a 440 dp e a largura da tela é inferior a 440 dp.
- [C-1-4] Uma atividade NÃO PODE ser redimensionada para um tamanho menor que 220 dp em modos de várias janelas diferentes de picture-in-picture.
- As implementações de dispositivos com tamanho de tela
xlarge
DEVEM ser compatíveis com formato livre modo
Se as implementações de dispositivos oferecem suporte aos modos de várias janelas e à tela dividida , eles:
- [C-2-2] PRECISA cortar a atividade na base de uma tela dividida em várias janelas, mas DEVE mostrar algum conteúdo dela se o app de acesso rápido for a janela em foco.
- [C-2-3] PRECISA respeitar o
AndroidManifestLayout_minWidth
declarado. eAndroidManifestLayout_minHeight
valores do aplicativo de inicialização de terceiros e não substituem esses valores ao mostrar conteúdo da atividade ancorada.
Se as implementações de dispositivos oferecem suporte ao(s) modo(s) de várias janelas e ao picture-in-picture no modo de várias janelas, eles:
- [C-3-1] PRECISA iniciar atividades no modo picture-in-picture de várias janelas.
quando o app é:
* Segmentar o nível 26 da API ou mais recente e declarar
android:supportsPictureInPicture
* Segmenta a API de nível 25 ou anterior e declara ambosandroid:resizeableActivity
eandroid:supportsPictureInPicture
. - [C-3-2] PRECISA expor as ações na SystemUI como
especificado pela atividade do PIP atual com o
setActions()
API. - [C-3-3] PRECISA oferecer suporte a proporções maiores ou iguais a
1:2,39 e menor ou igual a 2,39:1, conforme especificado pela atividade PIP por
setAspectRatio()
API. - [C-3-4] PRECISA usar
KeyEvent.KEYCODE_WINDOW
. para controlar a janela PIP; se o modo PIP não estiver implementado, a chave DEVE ser disponível para a atividade em primeiro plano. - [C-3-5] PRECISA fornecer recursos do usuário para bloquear a exibição de um app Modo PIP; a implementação do AOSP atende a esse requisito controles na aba de notificações.
[C-3-6] PRECISA alocar a largura e a altura mínimas a seguir para o PIP quando um aplicativo não declarar nenhum valor para
AndroidManifestLayout_minWidth
eAndroidManifestLayout_minHeight
:- Dispositivos com o Configuration.uiMode definido diferente de
UI_MODE_TYPE_TELEVISION
PRECISA alocar 108 dp de largura e altura. - Dispositivos com o Configuration.uiMode definido como
UI_MODE_TYPE_TELEVISION
PRECISA alocar uma largura mínima de 240 dp e uma altura mínima de 135 dp.
- Dispositivos com o Configuration.uiMode definido diferente de
3.8.15. Recorte da tela
O Android oferece suporte a um recorte da tela, conforme descrito
no documento do SDK. A API DisplayCutout
define
uma área na borda da tela que pode não funcionar para um aplicativo
devido a um corte da tela ou uma tela curva nas bordas.
Se as implementações de dispositivos incluírem cortes de tela, elas:
- [C-1-5] NÃO PODE ter cortes se a proporção do dispositivo for de 1,0 (1:1).
- [C-1-2] NÃO PODE ter mais de um corte por borda.
- [C-1-3] PRECISA respeitar as flags de corte da tela definidas pelo app com o
WindowManager.LayoutParams
conforme descrito no SDK. - [C-1-4] PRECISA informar os valores corretos para todas as métricas de corte definidas no
API
DisplayCutout
.
3.8.16. Controles do dispositivo
O Android inclui ControlsProviderService
e Control
APIs que permitem que aplicativos de terceiros publiquem controles do dispositivo para
status e ação dos usuários.
Consulte a Seção 2_2_3 para ver os requisitos específicos dos dispositivos.
3.8.17. Área de transferência
Implementações de dispositivos:
- [C-0-1] NÃO É POSSÍVEL enviar dados da área de transferência para nenhum componente, atividade, serviço ou em qualquer conexão de rede, sem ação explícita do usuário (por exemplo, pressionar um na sobreposição), exceto para os serviços mencionados no 9.8.6 Captura de Conteúdo e Pesquisa no App.
Se as implementações do dispositivo gerarem uma visualização visível para o usuário quando o conteúdo for copiado
para a área de transferência de qualquer item ClipData
em que
ClipData.getDescription().getExtras()
contém
android.content.extra.IS_SENSITIVE
, ele:
- [C-1-1] PRECISA encobrir a visualização visível para o usuário.
A implementação de referência do AOSP atende a esses requisitos da área de transferência.
3,9. Administração do dispositivo
O Android inclui recursos que permitem que aplicativos com reconhecimento de segurança executem funções de administração de dispositivos no nível do sistema, como aplicação de senha políticas ou realizar a limpeza remota, por meio do API Android Device Administration.
Se as implementações de dispositivos implementam toda a variedade de administrações de dispositivos definidas na documentação do SDK do Android, elas:
- [C-1-1] PRECISA declarar
android.software.device_admin
. - [C-1-2] PRECISA oferecer suporte ao provisionamento do proprietário do dispositivo, conforme descrito em seção 3.9.1 e seção 3.9.1.1.
3.9.1 Provisionamento de dispositivos
3.9.1.1 Provisionamento do proprietário do dispositivo
Se as implementações de dispositivo declararem android.software.device_admin
, elas:
- [C-1-1] PRECISA ser compatível com o registro de um cliente do Device Policy (DPC) como um
App proprietário do dispositivo
conforme descrito abaixo:
- Quando a implementação do dispositivo tiver
nem os usuários nem
dados do usuário configurados, ele:
- [C-1-5] PRECISA registrar o aplicativo DPC como o app Proprietário do dispositivo
ou ativar o app DPC para escolher
se tornar Proprietário do Dispositivo ou do Perfil,
se o dispositivo declarar suporte para comunicação a curta distância (NFC, na sigla em inglês) por meio de
a flag de recurso
android.hardware.nfc
e recebe uma mensagem NFC que contêm um registro com tipo MIMEMIME_TYPE_PROVISIONING_NFC
. - [C-1-8] É NECESSÁRIO enviar o ACTION_GET_PROVISIONING_MODE.
após o provisionamento do proprietário do dispositivo ser acionado para que o
O app de DPC pode escolher se quer se tornar um Proprietário do Dispositivo ou um Perfil
proprietário, dependendo dos valores
android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES
, a menos que possa ser determinado a partir contexto de que há apenas uma opção válida. - [C-1-9] PRECISA enviar o ACTION_ADMIN_POLICY_COMPLIANCE (link em inglês) para o aplicativo Proprietário do dispositivo se um Proprietário do dispositivo for estabelecido durante o provisionamento, independentemente do método usado. O o usuário não poderá continuar no assistente de configuração até que Proprietário do dispositivo concluído.
- [C-1-5] PRECISA registrar o aplicativo DPC como o app Proprietário do dispositivo
ou ativar o app DPC para escolher
se tornar Proprietário do Dispositivo ou do Perfil,
se o dispositivo declarar suporte para comunicação a curta distância (NFC, na sigla em inglês) por meio de
a flag de recurso
- Quando a implementação do dispositivo tiver
usuários ou
os dados do usuário, ela:
- [C-1-7] Não é NECESSÁRIO registrar nenhum aplicativo de DPC como o app proprietário do dispositivo mais.
- Quando a implementação do dispositivo tiver
nem os usuários nem
dados do usuário configurados, ele:
[C-1-2] PRECISA mostrar um aviso de divulgação adequado (conforme mencionado no AOSP) e receba o consentimento afirmativo do usuário final antes de abrir o app. definido como proprietário do dispositivo, a menos que o dispositivo seja configurado de forma programática para Modo de demonstração na loja antes da interação do usuário final na tela. Se as implementações de dispositivos declararem
android.software.device_admin
, mas também incluem um modelo de gerenciamento de dispositivos móveis e fornecer um mecanismo promover um aplicativo configurado na solução como "Proprietário do dispositivo" equivalente" para "Proprietário do dispositivo" padrão, reconhecida pela norma Android DevicePolicyManager (link em inglês) APIs, eles:[C-2-1] PRECISA ter um processo para verificar se um determinado app promovida pertence a um sistema legítimo de gerenciamento e tenha sido configurado na solução proprietária ter os direitos equivalentes como "Proprietário do dispositivo".
[C-2-2] PRECISA mostrar a mesma declaração de consentimento do proprietário do dispositivo AOSP que a fluxo iniciado por
android.app.action.PROVISION_MANAGED_DEVICE
antes de registrar o aplicativo DPC como "Proprietário do dispositivo".[C-2-3] NÃO PODE codificar o consentimento nem impedir o uso de outros apps do proprietário do dispositivo.
3.9.1.2 Provisionamento de perfil gerenciado
Se as implementações de dispositivo declararem android.software.managed_users
, elas:
[C-1-1] PRECISA implementar as APIs. permitindo que um aplicativo controlador de política de dispositivo (DPC) se torne o proprietário de um novo Perfil gerenciado.
[C-1-2] O processo de provisionamento de perfil gerenciado (o fluxo iniciado pelo DPC usando o método android.app.action.PROVISION_MANAGED_PROFILE) ou pela plataforma), a tela de consentimento e a experiência do usuário DEVEM estar alinhadas com a implementação do AOSP.
[C-1-3] PRECISA fornecer as seguintes affordances do usuário nas configurações para indicar ao usuário quando uma função específica do sistema foi desativada pelo o controlador de política de dispositivo (DPC):
- Um ícone consistente ou outra funcionalidade do usuário (por exemplo, o upstream ícone de informações do AOSP) para representar quando uma configuração específica é restrita por um administrador de dispositivo.
- Uma breve mensagem de explicação, fornecida pelo administrador do dispositivo por meio do
setShortSupportMessage
- O ícone do aplicativo DPC.
[C-1-4] PRECISA iniciar o gerenciador de ACTION_PROVISIONING_SUCCESSFUL. no perfil de trabalho se um Proprietário do perfil for estabelecido ao o provisionamento é iniciado por android.app.action.PROVISION_MANAGED_PROFILE. e o DPC implementou o gerenciador.
[C-1-5] PRECISA enviar ACTION_PROFILE_PROVISIONING_COMPLETE são transmitidos para o DPC do perfil de trabalho quando o provisionamento é iniciado pelo android.app.action.PROVISION_MANAGED_PROFILE intenção.
[C-1-6] É NECESSÁRIO enviar o ACTION_GET_PROVISIONING_MODE. após o provisionamento do proprietário do perfil ser acionado para que o app DPC pode optar por se tornar Proprietário do dispositivo ou Proprietário do perfil, exceto quando o provisionamento é acionado pela intent android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-7] PRECISA enviar ACTION_ADMIN_POLICY_COMPLIANCE intenção para o perfil de trabalho quando um Proprietário do perfil é estabelecido durante independentemente do método usado, exceto quando o provisionamento é acionado pela intent android.app.action.PROVISION_MANAGED_PROFILE. O usuário não poderá continuar no assistente de configuração até que o perfil Conclusão do app do proprietário.
[C-1-8] PRECISA enviar ACTION_MANAGED_PROFILE_PROVISIONED transmitidos ao DPC do perfil pessoal quando um Proprietário do perfil é estabelecido, seja qual for o método de provisionamento usado.
3.9.2 Suporte de perfil gerenciado
Se as implementações de dispositivo declararem android.software.managed_users
, elas:
- [C-1-1] PRECISA oferecer suporte aos perfis gerenciados pelo
android.app.admin.DevicePolicyManager
. APIs de terceiros. - [C-1-2] PRECISA permitir a criação de apenas um perfil gerenciado.
- [C-1-3] PRECISA usar um selo de ícone (semelhante ao de trabalho upstream do AOSP) para representar os aplicativos e widgets gerenciados e outros elementos de interface com selo como Recentes & Notificações.
- [C-1-4] PRECISA exibir um ícone de notificação (semelhante ao trabalho upstream do AOSP) ) para indicar quando o usuário está em um aplicativo de perfil gerenciado.
- [C-1-5] PRECISA exibir um aviso indicando que o usuário está no grupo se e quando o dispositivo for ativado (ACTION_USER_PRESENT), e o aplicativo em primeiro plano está dentro do perfil gerenciado.
- [C-1-6] Onde existe um perfil gerenciado, PRECISA mostrar uma affordance visual na Intent "Seletor" para permitir que o usuário encaminhe a intent para o usuário principal ou vice-versa, se ativado pelo Device Policy Controlador.
- [C-1-7] Onde houver um perfil gerenciado, será NECESSÁRIO expor o seguinte usuário
affordances para o usuário principal e o perfil gerenciado:
- Contabilização separada para uso de bateria, localização, dados móveis e armazenamento para o usuário principal e o perfil gerenciado.
- Gerenciamento independente de apps de VPN instalados na rede principal usuário ou perfil gerenciado.
- Gerenciamento independente de aplicativos instalados no usuário principal ou perfil gerenciado.
- Gerenciamento independente de contas do usuário principal ou gerenciadas perfil.
- [C-1-8] PRECISA garantir que o discador, os contatos e as mensagens estejam pré-instalados os aplicativos podem pesquisar e procurar informações do autor da chamada no (se houver) ao lado dos do perfil principal, se o É permitido pelo Device Policy Controller.
- [C-1-9] PRECISA garantir que ela atenda a todos os requisitos de segurança. aplicável a um dispositivo com vários usuários ativados (consulte a seção 9.5), embora o perfil gerenciado não é contado como outro usuário além do usuário principal.
Iniciar novos requisitos
- [C-1-10] PRECISA garantir que os dados da captura de tela estejam salvos no perfil de trabalho.
quando uma captura de tela é feita com um
topActivity
janela com foco (aquele com o qual o usuário interagiu por último entre todas as atividades) e ao qual pertence um app do perfil de trabalho. - [C-1-11] NÃO PODE capturar nenhum outro conteúdo da tela (barra do sistema, notificações ou qualquer conteúdo de perfil pessoal), exceto para o perfil de trabalho janelas/janelas do aplicativo ao salvar uma captura de tela no perfil de trabalho (para garantir que os dados os dados do perfil não são salvos no perfil de trabalho).
Encerrar novos requisitos
Se as implementações de dispositivo declararem android.software.managed_users
e
android.software.secure_lock_screen
, eles:
- [C-2-1] PRECISA ser compatível com a capacidade de especificar uma reunião separada da tela de bloqueio
os seguintes requisitos para conceder acesso a apps em execução em um
somente por perfil.
- As implementações de dispositivos DEVEM respeitar as
DevicePolicyManager.ACTION_SET_NEW_PASSWORD
e mostrar uma interface para configurar uma tela de bloqueio separada para o perfil gerenciado. - As credenciais da tela de bloqueio do perfil gerenciado PRECISAM usar as mesmas informações armazenamento de credenciais e mecanismos de gerenciamento como o perfil pai, conforme documentado no Site do projeto de código aberto do Android.
- As políticas de senha do DPC
PRECISA ser aplicada apenas às credenciais da tela de bloqueio do perfil gerenciado, a menos que
será chamado para a instância
DevicePolicyManager
retornada pelo getParentProfileInstance.
- As implementações de dispositivos DEVEM respeitar as
- Quando os contatos do perfil gerenciado são exibidos No registro de chamadas pré-instalado, interface na chamada, em andamento e na chamada perdida de notificações, contatos e mensagens, eles DEVEM receber o selo o mesmo selo usado para indicar aplicativos de perfil gerenciado.
3.9.3 Suporte gerenciado ao usuário
Se as implementações de dispositivo declararem android.software.managed_users
, elas:
- [C-1-1] PRECISA fornecer recursos para que o usuário faça logout e
volte para o usuário principal em uma sessão multiusuário quando
isLogoutEnabled
retornatrue
. A funcionalidade do usuário PRECISA estar acessível na tela de bloqueio. sem desbloquear o dispositivo.
Se as implementações de dispositivos declararem android.software.device_admin
e fornecerem
uma funcionalidade de usuário no dispositivo para adicionar mais usuários secundários, ele:
- [C-SR-1] É FORTEMENTE RECOMENDADO mostrar o mesmo consentimento do proprietário do dispositivo AOSP de divulgação que foram mostradas no fluxo iniciado por android.app.action.PROVISION_MANAGED_DEVICE, antes de permitir a adição de contas no novo usuário secundário, para que os usuários entendam que o dispositivo é gerenciado.
3.9.4 Requisitos do papel de gerenciamento de políticas do dispositivo
Se as implementações de dispositivos informarem android.software.device_admin
ou
android.software.managed_users
, ele poderá fazer o seguinte:
- [C-1-1] PRECISA ser compatível com o papel de gerenciamento de políticas do dispositivo, conforme definido em
seção 9.1. O aplicativo que detém o papel de gerenciamento de políticas do dispositivo
PODE ser definido definindo
config_devicePolicyManagement
como o nome do pacote. O nome do pacote PRECISA ser seguido por:
e pelo certificado de assinatura, a menos que o aplicativo seja pré-carregado.
Se um nome de pacote não for definido para config_devicePolicyManagement
como
descritas acima:
- [C-2-1] As implementações de dispositivos PRECISAM ser compatíveis com o provisionamento sem um dispositivo aplicativo detentor da função de gerenciamento de políticas O AOSP oferece uma implementação de referência.
Se um nome de pacote for definido para config_devicePolicyManagement
, conforme descrito
acima:
- [C-3-1] O aplicativo PRECISA estar instalado em todos perfis para um usuário.
- [C-3-2] Implementações de dispositivos PODEM definir um aplicativo que atualiza o
proprietário do papel de gerenciamento de políticas do dispositivo antes do provisionamento
config_devicePolicyManagementUpdater
:
Se um nome de pacote for definido para config_devicePolicyManagementUpdater
como
descritas acima:
- [C-4-1] O aplicativo PRECISA estar pré-instalado no dispositivo.
- [C-4-2] O aplicativo PRECISA implementar um filtro de intent que resolva
android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER
:
Iniciar novos requisitos
3.9.5 Estrutura de resolução de políticas do dispositivo
Se as implementações de dispositivos informarem android.software.device_admin
ou
android.software.managed_users
, ele poderá fazer o seguinte:
- [C-1-1] PRECISA resolver os conflitos de políticas do dispositivo, conforme documentado em Framework de resolução de políticas do dispositivo.
Encerrar novos requisitos
3,10 Acessibilidade
O Android oferece uma camada de acessibilidade que ajuda usuários com deficiências a a navegar pelos dispositivos com mais facilidade. Além disso, o Android fornece APIs de plataforma que permitem que as implementações de serviços de acessibilidade recebam callbacks para o usuário e eventos do sistema e gerar mecanismos de feedback alternativos, como conversão de texto em voz, retorno tátil e navegação com trackball/botão direcional.
Se as implementações de dispositivos oferecerem suporte a serviços de acessibilidade de terceiros, elas:
- [C-1-1] PRECISA fornecer uma implementação da acessibilidade do Android. conforme descrito nas APIs de acessibilidade na documentação do SDK.
- [C-1-2] PRECISA gerar eventos de acessibilidade e entregar os eventos
AccessibilityEvent
para todos os registradosAccessibilityService
implementações conforme documentado no SDK. - [C-1-4] PRECISA fornecer recursos para o usuário controlar a acessibilidade. serviços que declaram AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_Button. Para implementações de dispositivos com uma barra de navegação do sistema, elas DEVE permitir que o usuário tenha a opção de usar um botão no sistema barra de navegação para controlar esses serviços.
Se as implementações de dispositivos incluírem serviços de acessibilidade pré-instalados, elas:
- [C-2-1] PRECISA implementar esses serviços de acessibilidade pré-instalados Reconhecimento de inicialização direta quando o armazenamento de dados é criptografado com a criptografia baseada em arquivos (FBE, na sigla em inglês).
- DEVE fornecer um mecanismo no fluxo de configuração pronto para que os usuários ativem serviços de acessibilidade relevantes, bem como opções para ajustar o tamanho da fonte, tamanho de exibição e gestos de ampliação.
3,11. Conversão de texto em voz
O Android inclui APIs que permitem que aplicativos usem a conversão de texto em voz (TTS) e permite que os provedores de serviços forneçam implementações de TTS serviços.
Se implementações de dispositivo relatam o recurso android.hardware.audio.output, eles:
- [C-1-1] PRECISA oferecer suporte à Framework de TTS do Android APIs de terceiros.
Se as implementações de dispositivos forem compatíveis com a instalação de mecanismos TTS de terceiros, elas:
- [C-2-1] PRECISA fornecer recursos para que o usuário possa selecionar uma TTS Engine para uso no sistema.
3,12. TV Input Framework
O Android Television Input Framework (TIF) simplifica o envio de imagens conteúdo para dispositivos Android Television. O TIF fornece uma API padrão para criar módulos de entrada que controlam dispositivos Android Television.
Se as implementações de dispositivos oferecerem suporte a TIF, elas:
- [C-1-1] PRECISA declarar o recurso da plataforma
android.software.live_tv
. - [C-1-2] PRECISA oferecer suporte a todas as APIs TIF, como um aplicativo que usa essas APIs e as entradas de terceiros baseadas em TIF serviço pode ser instalado e usado no dispositivo.
3,13 Configurações rápidas
O Android fornece um componente de interface de configurações rápidas que permite acesso rápido a usadas com frequência ou ações urgentes.
Se as implementações de dispositivos incluírem um componente de interface para Configurações rápidas e oferecer suporte a terceiros Em "Configurações rápidas", eles:
- [C-1-1] PRECISA permitir que o usuário adicione ou remova os blocos fornecidos pelo
quicksettings
APIs de um app de terceiros. - [C-1-2] NÃO PODE adicionar automaticamente um bloco de um app de terceiros de forma automática para acessar as "Configurações rápidas".
- [C-1-3] PRECISA mostrar todos os blocos adicionados pelo usuário de apps de terceiros. junto com os blocos de configuração rápida fornecidos pelo sistema.
3,14 Interface de mídia
Se as implementações de dispositivos incluírem aplicativos não ativados por voz (os Aplicativos) que interagem com
aplicativos de terceiros no MediaBrowser
ou MediaSession
,
os aplicativos:
[C-1-2] PRECISA mostrar claramente os ícones acessados por
getIconBitmap()
ougetIconUri()
, além dos títulos. recebido viagetTitle()
, conforme descrito emMediaDescription
. Pode encurtar títulos para cumprir regulamentações de segurança (por exemplo, distração do motorista).[C-1-3] PRECISA mostrar o ícone do aplicativo de terceiros sempre que o conteúdo fornecido por esse aplicativo de terceiros.
[C-1-4] PRECISA permitir que o usuário interaja com todo o
MediaBrowser
hierarquia. PODE restringir o acesso a parte da hierarquia para cumprir as regulamentações de segurança (por exemplo, distração do motorista), mas NÃO PODEM dar tratamento preferencial com base no conteúdo ou provedor de conteúdo.[C-1-5] PRECISA considerar o toque duplo de
KEYCODE_HEADSETHOOK
ouKEYCODE_MEDIA_PLAY_PAUSE
comoKEYCODE_MEDIA_NEXT
paraMediaSession.Callback#onMediaButtonEvent
.
3,15 Instant Apps
Se as implementações de dispositivos forem compatíveis com Instant Apps, elas PRECISAM atender aos seguintes requisitos: requisitos:
- [C-1-1] Os apps instantâneos só PRECISAM receber permissões com o
android:protectionLevel
Defina como"instant"
. - [C-1-2] Os apps instantâneos NÃO PODEM interagir com apps instalados por intents implícitas
a menos que uma das seguintes condições seja verdadeira:
- O filtro de padrão de intent do componente está exposto e tem CATEGORY_BROWSABLE
- A ação é ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
- O destino é explicitamente exposto com android:visibleToInstantApps
- [C-1-3] Os Instant Apps NÃO PODEM interagir explicitamente com apps instalados, a menos que a o componente é exposto por android:visibleToInstantApps.
- [C-1-4] Os apps instalados NÃO PODEM ver detalhes sobre os Instant Apps no dispositivo, a menos que o app instantâneo se conecte explicitamente aplicativo instalado.
As implementações de dispositivos PRECISAM fornecer as seguintes affordances do usuário para ao interagir com os Instant Apps. O AOSP atende aos requisitos das interface padrão do sistema, Configurações e Tela de início. Implementações de dispositivos:
- [C-1-5] PRECISA fornecer recursos de usuário para visualizar e excluir Instant Apps armazenada localmente em cache para cada pacote de app.
- [C-1-6] PRECISA fornecer uma notificação persistente ao usuário, que pode ser
recolhido enquanto um Instant App está em execução em primeiro plano. Este usuário
a notificação PRECISA incluir que os Instant Apps não exigem instalação.
e fornecem uma affordance de usuário que o direcione ao aplicativo
tela de informações em Configurações. Para Apps instantâneos iniciados por intents da Web, como
definida usando uma intent com a ação definida como
Intent.ACTION_VIEW
e com um esquema de "http" ou "https", uma funcionalidade de usuário adicional, DEVE permitir que o usuário não inicie o app instantâneo e iniciar o link associado com o navegador da Web configurado, se um navegador está disponível no dispositivo. - [C-1-7] PRECISA permitir que os Instant Apps em execução sejam acessados em "Recentes" se a função Recentes estiver disponível no dispositivo.
[C-1-8] É NECESSÁRIO pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents para as intents listadas no SDK aqui. e tornar as intents visíveis para os Apps instantâneos.
3,16 Pareamento de dispositivo complementar
O Android inclui suporte para pareamento de dispositivos complementares para um gerenciamento mais eficaz
associação com dispositivos complementares e fornece a CompanionDeviceManager
API para que os apps acessem este recurso.
Se as implementações de dispositivos forem compatíveis com o recurso de pareamento de dispositivo complementar, elas:
- [C-1-1] PRECISA declarar a flag de recurso
FEATURE_COMPANION_DEVICE_SETUP
. , - [C-1-2] PRECISA garantir que as APIs no
android.companion
totalmente implementado. - [C-1-3] PRECISA fornecer recursos do usuário para que ele selecione/confirme um companion dispositivo está presente e funcionando.
3.17. Apps pesados
Se as implementações de dispositivos declararem o recurso FEATURE_CANT_SAVE_STATE
,
então eles:
- [C-1-1] PRECISA ter apenas um app instalado que especifique
cantSaveState
em execução no sistema por vez. Se o usuário sai de um aplicativo desse tipo sem sair dele explicitamente (por exemplo, pressionando em casa e deixa uma atividade ativa no sistema, em vez de pressionar "Voltar" sem atividades ativas restantes no sistema), as implementações de dispositivos PRECISAM priorizar esse aplicativo na RAM da mesma forma que fazem com outros aplicativos. que devem permanecer em execução, como serviços em primeiro plano. Enquanto esse app está em segundo plano, o sistema ainda pode usar energia recursos de gerenciamento, como limitar o acesso à CPU e à rede. - [C-1-2] PRECISA fornecer uma funcionalidade de interface para escolher o app que não vai:
participam do mecanismo normal de salvar/restaurar o estado quando o usuário
inicia um segundo app declarado com
cantSaveState
. . - [C-1-3] NÃO É POSSÍVEL aplicar outras mudanças na política a apps que especifiquem
cantSaveState
, como alterações no desempenho da CPU ou na priorização da programação.
Se as implementações do dispositivo não declararem o recurso
FEATURE_CANT_SAVE_STATE
,
então eles:
- [C-1-1] PRECISA ignorar
cantSaveState
. definido por apps e NÃO PODE mudar o comportamento do app com base nisso .
3,18. Contatos
O Android inclui
Contacts Provider
APIs para permitir que os aplicativos gerenciem informações de contato armazenadas no dispositivo.
Os dados de contato inseridos diretamente no dispositivo geralmente são sincronizados.
com um serviço da Web, mas os dados PODEM residir apenas localmente no dispositivo.
Os contatos armazenados apenas no dispositivo são chamados de locais
contatos.
RawContacts
estão "associados a" ou "armazenado em" um
Conta
quando
ACCOUNT_NAME
,
e
ACCOUNT_TYPE
,
as colunas dos contatos brutos correspondem às
Account.name
e
Account.type
da conta.
Conta local padrão: uma conta para contatos brutos armazenados apenas em
dispositivo e não associados a uma conta no
Gerente de contas,
que são criados com valores null para o
ACCOUNT_NAME
,
e
ACCOUNT_TYPE
,
colunas.
Conta local personalizada: uma conta para contatos brutos que são armazenados apenas no
dispositivo do usuário e não associados a uma conta no AccountManager, que são
criado com pelo menos um valor não nulo para o
ACCOUNT_NAME
,
e
ACCOUNT_TYPE
,
colunas.
Implementações de dispositivos:
- [C-SR-1] É MUITO RECOMENDADO não criar contas locais personalizadas.
Se as implementações de dispositivos usarem uma conta local personalizada, faça o seguinte:
- [C-1-1] A
ACCOUNT_NAME
, da conta local personalizada PRECISA ser retornada peloContactsContract.RawContacts.getLocalAccountName
- [C-1-2] A
ACCOUNT_TYPE
, da conta local personalizada PRECISA ser retornada peloContactsContract.RawContacts.getLocalAccountType
- [C-1-3] Contatos brutos inseridos por aplicativos de terceiros com
a conta local padrão (ou seja, definindo valores nulos para
ACCOUNT_NAME
eACCOUNT_TYPE
) PRECISAM ser inseridos no local personalizado padrão. - [C-1-4] Os contatos brutos inseridos na conta local personalizada não PODEM ser removidas quando contas são adicionadas ou removidas.
- [C-1-5] Operações de exclusão realizadas na conta local personalizada
DEVE resultar na limpeza imediata dos contatos brutos (como se os
CALLER_IS_SYNCADAPTER
parâmetro foi definido como verdadeiro), mesmo que o parâmetroCALLER\_IS\_SYNCADAPTER
fosse definido como falso ou não especificado.
4. Compatibilidade do empacotamento de aplicativos
Implementações de dispositivos:
[C-0-1] PRECISA ser capaz de instalar e executar o arquivo ".apk" do Android como gerado pelo "aapt" inclusa no SDK oficial do Android.
- Como o requisito acima pode ser desafiador, as implementações de dispositivos são RECOMENDADO usar o gerenciamento de pacotes da implementação de referência do AOSP sistema.
[C-0-2] PRECISA ser compatível com a verificação de ".apk" usando o Esquema de assinatura de APK v3.1 Esquema de assinatura de APK v3 Esquema de assinatura de APK v2 e assinatura JAR.
[C-0-3] NÃO PODE estender o .apk Manifesto do Android, Bytecode Dalvik ou Formatos de bytecode do RenderScript de modo a impedir que esses arquivos sejam sendo instalado e executado corretamente em outros dispositivos compatíveis.
[C-0-4] NÃO É POSSÍVEL permitir outros apps além do atual "instalador do registro" para que o pacote desinstale o app silenciosamente sem confirmação do usuário, conforme documentado no SDK para o
DELETE_PACKAGE
permissão. As únicas exceções são o processamento do app do verificador de pacotes do sistema PACKAGE_NEEDS_VERIFICATION (em inglês) e o processamento de apps do gerenciador de armazenamento ACTION_MANAGE_STORAGE (em inglês) intenção.[C-0-5] PRECISA ter uma atividade que gerencie
android.settings.MANAGE_UNKNOWN_APP_SOURCES
intenção.[C-0-6] NÃO É POSSÍVEL instalar pacotes de aplicativos desconhecidos fontes, a menos que o app que solicite a instalação atenda a todos os requisitos a seguir:
- Ela PRECISA declarar a
REQUEST_INSTALL_PACKAGES
. permissão ou definirandroid:targetSdkVersion
como 24 ou inferior. - Ele PRECISA ter recebido permissão do usuário para instalar apps fontes desconhecidas.
- Ela PRECISA declarar a
DEVE fornecer uma funcionalidade ao usuário para conceder/revogar a permissão para instalar aplicativos de fontes desconhecidas por aplicativo, mas PODEM optar por implementar como um ambiente autônomo e retorna
RESULT_CANCELED
parastartActivityForResult()
, se a implementação do dispositivo não permitir que os usuários tenham essa opção. No entanto, mesmo nesses casos, eles DEVEM indicar ao usuário por que não há essa escolha apresentada.[C-0-7] PRECISA exibir uma caixa de diálogo de aviso com a string de aviso que é fornecido pela API do sistema
PackageManager.setHarmfulAppWarning
para o usuário antes de iniciar uma atividade em um aplicativo que foi marcado pela mesma API do sistemaPackageManager.setHarmfulAppWarning
que possivelmente prejudiciais.DEVE fornecer funcionalidade ao usuário para optar por desinstalar ou iniciar um aplicativo na caixa de diálogo de aviso.
[C-0-8] PRECISA implementar o suporte para o sistema de arquivos incremental, conforme documentado aqui.
[C-0-9] PRECISA oferecer suporte à verificação de arquivos .apk usando o Esquema de assinatura de APK v4 e Esquema de assinatura de APK v4.1.
5. Compatibilidade multimídia
Implementações de dispositivos:
- [C-0-1] PRECISA oferecer suporte aos formatos de mídia, codificadores, decodificadores, tipos de arquivo
e formatos de contêiner definidos na seção 5.1
para todos os codecs declarados por
MediaCodecList
. - [C-0-2] PRECISA declarar e informar o suporte dos codificadores e decodificadores disponíveis
para aplicativos de terceiros
MediaCodecList
- [C-0-3] PRECISA ser capaz de decodificar e disponibilizar para terceiros
apps em todos os formatos que ele pode codificar. Isso inclui todos os bitstreams que seu
de rede e os perfis informados nos
CamcorderProfile
Implementações de dispositivos:
- DEVE visar a latência mínima do codec, ou seja,
- NÃO DEVE consumir e armazenar buffers de entrada e retornar apenas buffers de entrada depois do processamento.
- NÃO DEVE manter os buffers decodificados por mais tempo do que o especificado pelo padrão (por exemplo, SPS).
- NÃO DEVE manter buffers codificados por mais tempo do que o exigido pelo GOP na estrutura dos preços.
Todos os codecs listados na seção abaixo são fornecidos como softwares. na implementação preferencial do Android do projeto de origem.
O Google e a Open Handset Alliance não fazem representação de que esses codecs não têm patentes de terceiros. Aqueles a intenção de usar esse código-fonte em produtos de hardware ou software é aconselhável que as implementações desse código, incluindo em softwares de código aberto ou o shareware, pode exigir licenças de patentes dos respectivos titulares das patentes.
5.1. Codecs de mídia
5.1.1. Codificação de áudio
Veja mais detalhes em 5.1.3. Detalhes dos codecs de áudio.
Se as implementações de dispositivos declararem android.hardware.microphone
,
eles DEVEM ser compatíveis com a codificação dos formatos de áudio a seguir e disponibilizá-los
para apps de terceiros:
- [C-1-1] PCM/WAVE
- [C-1-2] FLAC
- [C-1-3] Opus
Todos os codificadores de áudio PRECISAM ser compatíveis com:
- [C-3-1] Frames de áudio PCM de 16 bits em ordem nativa de bytes por meio do
android.media.MediaCodec
API.
5.1.2. Decodificação de áudio
Veja mais detalhes em 5.1.3. Detalhes dos codecs de áudio.
Se as implementações de dispositivo declararem suporte ao
android.hardware.audio.output
, eles precisam oferecer suporte à decodificação do
seguintes formatos de áudio:
- [C-1-1] Perfil AAC MPEG-4 (AAC LC)
- [C-1-2] Perfil MPEG-4 HE AAC (AAC+)
- [C-1-3] Perfil MPEG-4 HE AACv2 (AAC+ aprimorado)
- [C-1-4] AAC ELD (AAC aprimorado com atraso baixo)
- [C-1-11] xHE-AAC (perfil ISO/IEC 23003-3 estendido HE AAC, que inclui o perfil de referência USAC e o intervalo dinâmico ISO/IEC 23003-4 perfil de controle)
- [C-1-5] FLAC
- [C-1-6] MP3
- [C-1-7] MIDI
- [C-1-8] Vórbis
- [C-1-9] PCM/WAVE, incluindo áudio de alta resolução formatos de até 24 bits, taxa de amostragem de 192 kHz e 8 canais. Esse requisito serve apenas para decodificação, e um dispositivo tem permissão para downsample e downmix durante a fase de reprodução.
- [C-1-10] Opus
Se as implementações do dispositivo forem compatíveis com a decodificação de buffers de entrada AAC de
streams multicanais (ou seja, mais de dois canais) para PCM por meio do padrão
Decodificador de áudio AAC na API android.media.MediaCodec
, o seguinte PRECISA ser
suportado:
- [C-2-1] A decodificação PRECISA ser feita sem downmixing (por exemplo, um AAC de 5.0 o stream precisa ser decodificado para cinco canais de PCM, um stream AAC 5.1 precisa ser decodificado a seis canais de PCM).
- [C-2-2] Os metadados de intervalo dinâmico PRECISAM ser conforme definidos em "Controle de intervalo dinâmico
(RDC)" na norma ISO/IEC 14496-3 e as chaves
android.media.MediaFormat
DRC para configurar os comportamentos relacionados ao intervalo dinâmico do decodificador de áudio. O As chaves AAC DRC foram introduzidas na API 21 e são:KEY_AAC_DRC_ATTENUATION_FACTOR
,KEY_AAC_DRC_BOOST_FACTOR
.KEY_AAC_DRC_HEAVY_COMPRESSION
,KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
eKEY_AAC_ENCODED_TARGET_LEVEL
. - [C-SR-1] É FORTEMENTE RECOMENDADO que os requisitos C-2-1 e C-2-2 acima sejam por todos os decodificadores de áudio AAC.
Ao decodificar o áudio USAC, MPEG-D (ISO/IEC 23003-4):
- [C-3-1] O volume e os metadados da DRC PRECISAM ser interpretados e aplicados de acordo com o nível 1 do perfil de controle de intervalo dinâmico da MPEG-D DRC.
- [C-3-2] O decodificador PRECISA se comportar de acordo com a configuração
definido com as seguintes chaves
android.media.MediaFormat
:KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
eKEY_AAC_DRC_EFFECT_TYPE
.
Decodificadores de perfil MPEG-4 AAC, HE AAC e HE AACv2:
- Pode ser compatível com o controle de volume e de intervalo dinâmico usando ISO/IEC 23003-4 Perfil de controle de intervalo dinâmico.
Se a norma ISO/IEC 23003-4 e as normas ISO/IEC 23003-4 e Os metadados ISO/IEC 14496-3 estão presentes em um bitstream decodificado, então:
- Os metadados ISO/IEC 23003-4 DEVEM ter precedência.
Todos os decodificadores de áudio PRECISAM oferecer suporte à saída de:
- [C-6-1] Frames de áudio PCM de 16 bits em ordem nativa de bytes por meio do
android.media.MediaCodec
API.
Se as implementações do dispositivo forem compatíveis com a decodificação de buffers de entrada AAC de
streams multicanais (ou seja, mais de dois canais) para PCM por meio do padrão
Decodificador de áudio AAC na API android.media.MediaCodec
, o seguinte PRECISA
ter suporte:
- [C-7-1] PRECISA ser configurado pelo aplicativo usando a função de decodificação.
com a chave
KEY_MAX_OUTPUT_CHANNEL_COUNT
para controlar se o conteúdo é reduzido para estéreo (ao usar o valor 2) ou se a saída for pelo número nativo de canais (ao usar um valor igual ou maior que esse número). Por exemplo, um valor de 6 ou mais configuraria um decodificador para produzir 6 canais quando alimentado com conteúdo 5.1. - [C-7-2] Ao decodificar, o decodificador PRECISA anunciar a máscara de canal que está sendo usada
no formato de saída com o
KEY_CHANNEL_MASK
usando as constantesandroid.media.AudioFormat
(exemplo:CHANNEL_OUT_5POINT1
).
Se as implementações de dispositivos oferecem suporte a decodificadores de áudio diferentes do AAC padrão e são capazes de produzir áudio multicanal (ou seja, mais de 2 canais) quando alimentado com conteúdo multicanal compactado, então:
- [C-SR-2] O decodificador é FORTEMENTE RECOMENDADO para ser configurado pelo
aplicativo usando a função de decodificação com a chave
KEY_MAX_OUTPUT_CHANNEL_COUNT
para controlar se o conteúdo é reduzido para estéreo (ao usar o valor 2) ou se a saída for pelo número nativo de canais (ao usar um valor igual ou maior que esse número). Por exemplo, um valor de 6 ou mais configuraria um decodificador para produzir 6 canais quando alimentado com conteúdo 5.1. - [C-SR-3] Ao decodificar, o decodificador é FORTEMENTE RECOMENDADO para anunciar o
máscara de canal usada no formato de saída com o
KEY_CHANNEL_MASK
usando as constantes android.media.AudioFormat (exemplo:CHANNEL_OUT_5POINT1
).
5.1.3. Detalhes dos codecs de áudio
Formato/Codec | Detalhes | Tipos de arquivos/formatos de contêiner aceitos |
---|---|---|
Perfil AAC MPEG-4 (AAC LC) |
Suporte a conteúdo mono/estéreo/5.0/5.1 com de 8 a 48 kHz. |
|
Perfil MPEG-4 HE AAC (AAC+) | Suporte a conteúdo mono/estéreo/5.0/5.1 com de 16 a 48 kHz. |
|
MPEG-4 HE AACv2 Perfil (AAC+ otimizado) |
Suporte a conteúdo mono/estéreo/5.0/5.1 com de 16 a 48 kHz. |
|
AAC ELD (AAC aprimorado com atraso baixo) | Suporte para conteúdo mono/estéreo com taxas de amostragem padrão de 16 a 48 kHz. |
|
USAC | Compatibilidade com conteúdo mono/estéreo com taxas de amostragem padrão de 7,35 para 48 kHz. | MPEG-4 (.mp4, .m4a) |
AMR-NB | 4,75 a 12,2 kbps com amostragem a 8 kHz. | 3GPP (.3gp) |
AMR-WB | 9 taxas de 6,60 kbit/s a 23,85 kbit/s com amostragem a 16 kHz, conforme definido em AMR-WB, multitaxa adaptável – Codec de fala de banda larga | 3GPP (.3gp) |
FLAC | Para codificador e decodificador: pelo menos os modos mono e estéreo PRECISAM ser suporte. Taxas de amostragem de até 192 kHz PRECISAM ser compatíveis. 16 e 24 bits a resolução PRECISA ser suportada. O processamento de dados de áudio FLAC de 24 bits PRECISA ser disponível com a configuração de áudio de ponto flutuante. |
|
MP3 | Taxa de bits mono/estéreo constante (CBR) ou variável (VBR) de 8 a 320 Kbps |
|
MIDI | MIDI tipos 0 e 1. DLS versões 1 e 2. XMF e XMF para celular. Suporte para formatos de toque RTTTL/RTX, OTA e iMelody |
|
Vorbis | Decodificação: suporte a conteúdo mono, estéreo, 5.0 e 5.1 com 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, 16.000, 24.000 e 48.000 Hz. |
|
PCM/WAVE | O codec PCM PRECISA ser compatível com PCM linear de 16 bits e flutuante de 16 bits. ONDA o extrator precisa oferecer suporte a PCM linear de 16, 24 e 32 bits e a flutuação de 32 bits (taxas até o limite de hardware). As taxas de amostragem PRECISAM ser compatíveis com 8 kHz a 192 kHz. | WAVE (.wav) |
Opus | Decodificação: compatibilidade com 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, 16.000, 24.000 e 48.000 Hz. |
|
5.1.4. Codificação de imagem
Veja mais detalhes em 5.1.6. Detalhes dos codecs de imagem.
As implementações de dispositivos PRECISAM ser compatíveis com a seguinte codificação de imagem:
- [C-0-1] JPEG
- [C-0-2] PNG
- [C-0-3] WebP
Iniciar novos requisitos
- [C-0-4] AVIF
- Os dispositivos precisam oferecer suporte a
BITRATE_MODE_CQ
e ao perfil de referência.
- Os dispositivos precisam oferecer suporte a
Encerrar novos requisitos
Se as implementações de dispositivos forem compatíveis com a codificação HEIC via android.media.MediaCodec
para o tipo de mídia MIMETYPE_IMAGE_ANDROID_HEIC
,
eles:
- [C-1-1] PRECISA fornecer um codec de codificador HEVC acelerado por hardware que
oferece suporte para
BITRATE_MODE_CQ
modo de controle de taxa de bits,HEVCProfileMainStill
perfil e frame de 512 x 512 px.
5.1.5 Decodificação de imagem
Veja mais detalhes em 5.1.6. Detalhes dos codecs de imagem.
As implementações de dispositivos PRECISAM oferecer suporte à decodificação da seguinte codificação de imagem:
- [C-0-1] JPEG
- [C-0-2] GIF
- [C-0-3] PNG
- [C-0-4] BMP
- [C-0-5] WebP
- [C-0-6] Bruto
- [C-0-7] AVIF (perfil de referência)
Se as implementações de dispositivos forem compatíveis com a decodificação de vídeo HEVC, elas: * [C-1-1] PRECISA oferecer suporte à decodificação de imagem HEIF (HEIC).
Decodificadores de imagem compatíveis com um formato de alta profundidade de bits (mais de 9 bits por canal):
- [C-2-1] PRECISA oferecer suporte à saída de um formato equivalente de 8 bits, se solicitado pelo
aplicativo, por exemplo, pela classe
ARGB_8888
deandroid.graphics.Bitmap
.
5.1.6. Detalhes dos codecs de imagem
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) | |
bruto | 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) |
Codificadores e decodificadores de imagens expostos na API MediaCodec
[C-1-1] É NECESSÁRIO oferecer suporte para a cor flexível YUV420 8:8:8 formato (
COLOR_FormatYUV420Flexible
) atéCodecCapabilities
.[C-SR-1] É MUITO RECOMENDADO para oferecer suporte ao formato de cores RGB888 para a superfície de entrada modo
[C-1-3] PRECISA suportar pelo menos um plano ou semiplanar Formato de cor YUV420 8:8:8:
COLOR_FormatYUV420PackedPlanar
(equivalente aCOLOR_FormatYUV420Planar
) ouCOLOR_FormatYUV420PackedSemiPlanar
(equivalente) paraCOLOR_FormatYUV420SemiPlanar
). Eles são FORTEMENTE RECOMENDADOS para oferecer suporte os dois.
5.1.7. Codecs de vídeo
- Para qualidade aceitável de streaming de vídeo e videoconferência na Web. serviços, as implementações de dispositivos DEVEM usar um codec VP8 de hardware que atenda aos requisitos.
Se as implementações de dispositivos incluírem um decodificador ou codificador de vídeo:
[C-1-1] Os codecs de vídeo PRECISAM oferecer suporte a tamanhos de buffer de bytes de entrada e saída que acomodar o maior frame compactado viável e descompactado conforme ditado de acordo com o padrão e a configuração, mas sem superalocar.
[C-1-2] Codificadores e decodificadores de vídeo PRECISAM oferecer suporte à cor flexível YUV420 de 8:8:8. formatos (
COLOR_FormatYUV420Flexible
) atéCodecCapabilities
.[C-1-3] Codificadores e decodificadores de vídeo PRECISAM oferecer suporte a pelo menos um Formato de cor semiplanar YUV420 8:8:8:
COLOR_FormatYUV420PackedPlanar
(equivalente aCOLOR_FormatYUV420Planar
) ouCOLOR_FormatYUV420PackedSemiPlanar
(equivalente aCOLOR_FormatYUV420SemiPlanar
). Eles são FORTEMENTE RECOMENDADOS para oferecer suporte a ambos.[C-SR-1] Codificadores e decodificadores de vídeo são FORTEMENTE RECOMENDADOS para oferecer suporte pelo menos uma cor plana ou semiplanar YUV420 8:8:8 otimizada por hardware formato (YV12, NV12, NV21 ou formato otimizado de fornecedor equivalente).
[C-1-5] Decodificadores de vídeo com suporte a um formato com alta profundidade de bits (mais de 9 bits por canal) PRECISA oferecer suporte à saída de um formato equivalente a 8 bits se solicitado pelo aplicativo. Isso DEVE ser refletido no suporte a uma YUV420 8:8:8 no formato de cor via
android.media.MediaCodecInfo
.
Se as implementações de dispositivos anunciarem suporte ao perfil HDR por meio do
Display.HdrCapabilities
,
eles:
- [C-2-1] PRECISA oferecer suporte à análise e processamento de metadados estáticos HDR.
Se as implementações de dispositivos anunciarem suporte a atualizações intra
FEATURE_IntraRefresh
no MediaCodecInfo.CodecCapabilities
, ela:
- [C-3-1] PRECISA oferecer suporte aos períodos de atualização no intervalo de 10 a 60 quadros e operar com precisão dentro de 20% do período de atualização configurado.
A menos que o aplicativo especifique o contrário usando o KEY_COLOR_FORMAT
chave de formato, implementações do decodificador de vídeo:
- [C-4-1] O padrão é o formato de cor otimizado para exibição de hardware se configurado usando a saída Surface.
- [C-4-2] O padrão é um formato de cores YUV420 8:8:8 otimizado para CPU leitura se configurado para não usar a saída Surface.
5.1.8. Lista de codecs de vídeo
Formato/Codec | Detalhes | Tipos de arquivos/formatos de contêiner aceitos |
---|---|---|
H.263 |
|
|
H.264 AVC | Consulte a seção 5.2 e 5.3 para mais detalhes |
|
H.265 HEVC | Consulte detalhes na seção 5.3 |
|
MPEG-2 | Perfil principal |
|
MPEG-4 SP |
|
|
VP8 | Consulte a seção 5.2 e 5.3 para mais detalhes |
|
VP9 | Consulte detalhes na seção 5.3 |
|
AV1 | Consulte as seções 5.2 e 5.3 para mais detalhes |
|
5.1.9. Segurança do codec de mídia
As implementações de dispositivos PRECISAM garantir compliance com os recursos de segurança do codec de mídia conforme descrito abaixo.
O Android inclui suporte para OMX, uma API de aceleração multimídia multiplataforma, bem como o Codec 2.0, uma API de aceleração de multimídia com baixa sobrecarga.
Se as implementações de dispositivos oferecerem suporte a multimídia, elas:
- [C-1-1] PRECISA oferecer suporte a codecs de mídia via OMX ou Codec 2.0 APIs (ou ambas), como no Android Open Source Project, e não desativar ou burlar as proteções de segurança. Especificamente, isso não significa codec PRECISA usar a API OMX ou o Codec 2.0, somente esse suporte por pelo menos uma dessas APIs PRECISA estar disponível, e o suporte para as APIs disponíveis PRECISA estar disponível. incluem as proteções de segurança presentes.
- [C-SR-1] É FORTEMENTE RECOMENDADO a inclusão de suporte para a API Codec 2.0.
Se as implementações de dispositivos não oferecerem suporte à API Codec 2.0, elas:
- [C-2-1] PRECISA incluir o codec de software OMX correspondente do Android Projeto de código aberto (se disponível) para cada formato e tipo de mídia (codificador ou decodificador) suportado pelo dispositivo.
- [C-2-2] Codecs que têm nomes que começam com "OMX.google". PRECISA se basear no código-fonte do Android Open Source Project.
- [C-SR-2] É FORTEMENTE RECOMENDADO que os codecs do software OMX sejam executados em um codec processo que não tem acesso a drivers de hardware além de mapeadores de memória.
Se as implementações de dispositivos oferecerem suporte à API Codec 2.0, elas:
- [C-3-1] PRECISA incluir o codec de software do Codec 2.0 correspondente Android Open Source Project (se disponível) para cada formato e tipo de mídia (codificador ou decodificador) suportado pelo dispositivo.
- [C-3-2] PRECISA hospedar os codecs de software Codec 2.0 no codec de software. conforme fornecido no Android Open Source Project para possibilitar para conceder acesso mais restrito aos codecs de software.
- [C-3-3] Codecs que têm nomes que começam com "c2.android". PRECISA se basear no código-fonte do Android Open Source Project.
5.1.10 Caracterização do codec de mídia
Se as implementações de dispositivos forem compatíveis com codecs de mídia, elas:
- [C-1-1] PRECISA retornar valores corretos de caracterização do codec de mídia por meio do
MediaCodecInfo
API.
Especificamente, as seguintes:
- [C-1-2] Codecs com nomes que começam com "OMX". É NECESSÁRIO usar as APIs OMX e que tenham nomes que estejam em conformidade com as diretrizes de nomenclatura OMX IL.
- [C-1-3] Codecs com nomes que começam com "c2". PRECISA usar a API Codec 2.0 e têm nomes que estejam em conformidade com as diretrizes de nomenclatura Codec 2.0 para Android.
- [C-1-4] Codecs com nomes que começam com "OMX.google". ou "c2.android". OBRIGATÓRIO NÃO ser caracterizada como fornecedora ou acelerada por hardware.
- [C-1-5] Codecs que são executados em um processo de codec (fornecedor ou sistema) que tenham acesso a drivers de hardware que não sejam alocadores de memória e mapeadores NÃO PODEM ser caracterizada como somente software.
- [C-1-6] Codecs ausentes ou não baseados no Android Open Source Project no código-fonte desse projeto PRECISA ser caracterizado como fornecedor.
- [C-1-7] Codecs que utilizam aceleração de hardware PRECISAM ser caracterizados como acelerado por hardware.
- [C-1-8] Os nomes de codecs NÃO PODEM ser enganosos. Por exemplo, codecs chamados "decodificadores" PRECISA oferecer suporte à decodificação, e os chamados "codificadores" DEVE oferecer suporte e codificação. Codecs com nomes que contêm formatos de mídia PRECISAM ser compatíveis com esses formatos.
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 de frame rate possíveis para o 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 |
|
|
|
1920 x 1080 px (exceto MPEG4, AV1) | 3.840 x 2.160 px (HEVC, VP9, AV1) |
- [C-2-2] Codecs de vídeo caracterizados como acelerados por hardware PRECISAM
publicar as informações dos pontos de desempenho. Eles PRECISAM listar todos os compatíveis
pontos de desempenho padrão (listados em
PerformancePoint
) API), a menos que tenham cobertura de outro ponto de desempenho padrão compatível. - Além disso, DEVEM publicar pontos de desempenho estendidos se oferecer suporte a desempenho contínuo de vídeo, diferente dos padrão listados.
5,2. Codificação de vídeo
- Em duas janelas deslizantes, NÃO DEVE ser mais de 15% acima da taxa de bits entre os intervalos intraframe (I-frame).
- O valor NÃO DEVE estar acima de 100% da taxa de bits em uma janela deslizante de 1 segundo.
Iniciar novos requisitos
Se as implementações de dispositivos forem compatíveis com qualquer codificador de vídeo e o disponibilizar apps de terceiros, e defina aMediaFormat.KEY_BITRATE_MODE
para
BITRATE_MODE_VBR
para que o codificador opere no modo de taxa de bits variável.
desde que isso não afete o valor mínimo de qualidade,
a taxa de bits codificada :
[C-5-1] PRECISANÃO DEVE ser, mais de um janela deslizante, mais de 15% acima da taxa de bits entre os intraframes (I-frame) em intervalos de tempo real.[C-5-2] PRECISANÃO DEVE ser maior que 100% acima da taxa de bits em uma janela deslizante de um segundo.
Se as implementações de dispositivos forem compatíveis com qualquer codificador de vídeo e o disponibilizar
apps de terceiros e definir
MediaFormat.KEY_BITRATE_MODE
para
BITRATE_MODE_CBR
Assim, o codificador opera em modo de taxa de bits constante e, em seguida, a taxa de bits codificada:
[C-6-1] PRECISA[C-SR-2] é FORTEMENTE RECOMENDADO para NÃO pode ser superior a 15% acima da taxa de bits desejada em uma janela deslizante de 1 segundo.
Encerrar novos requisitos
Se as implementações de dispositivos incluírem uma exibição de tela incorporada com o
comprimento diagonal de pelo menos 2,5 polegadas ou inclua uma porta de saída de vídeo ou
Declarar o suporte de uma câmera usando a android.hardware.camera.any
sinalização de recurso, elas:
- [C-1-1] PRECISA incluir suporte a pelo menos um dos formatos de vídeo VP8 ou H.264 codificadores e disponibilizá-los para aplicativos de terceiros.
- DEVE oferecer suporte a codificadores de vídeo VP8 e H.264 e disponibilizá-los para aplicativos de terceiros.
Se as implementações de dispositivos forem compatíveis com vídeos H.264, VP8, VP9 ou HEVC codificadores e disponibilizá-los para aplicativos de terceiros, ela:
- [C-2-1] PRECISA oferecer suporte a taxas de bits configuráveis dinamicamente.
- DEVE oferecer suporte a frame rates variáveis, em que o codificador de vídeo DEVE determinar duração instantânea do frame com base nos carimbos de data/hora dos buffers de entrada e aloca o próprio bucket de bits com base na duração do frame.
Se as implementações de dispositivos forem compatíveis com o codificador de vídeo MPEG-4 SP, para apps de terceiros, eles:
- DEVE oferecer suporte a taxas de bits configuráveis dinamicamente para o codificador compatível.
Se as implementações de dispositivos fornecerem codificadores de vídeo ou imagem com aceleração de hardware,
e oferecer suporte a uma ou mais câmeras de hardware conectadas ou conectáveis expostas por
as APIs android.camera
:
- [C-4-1] Todos os codificadores de vídeo e imagem com aceleração de hardware PRECISAM ser compatíveis com codificando frames da(s) câmera(s) de hardware.
- DEVE oferecer suporte à codificação de frames da(s) câmera(s) de hardware em todos os vídeos ou codificadores de imagem.
Se as implementações de dispositivos fornecerem codificação HDR, elas:
- [C-SR-1] é FORTEMENTE RECOMENDADO que forneça um plug-in para a API de transcodificação contínua para converter de HDR para SDR.
5.2.1. H.263
Se as implementações de dispositivos oferecerem suporte a codificadores H.263 a apps de terceiros, ela:
- [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 no codificador compatível.
5.2.2. H.264
Se as implementações de dispositivos oferecerem suporte ao codec H.264, elas:
- [C-1-1] PRECISA oferecer suporte ao perfil de referência de nível 3. No entanto, o suporte para ASO (Ordem Arbitrária de Frações), FMO (Flexível) Ordenação de Macroblocks) e RS (Slices Redundantes) são OPCIONAL. Além disso, para mantêm a compatibilidade com outros dispositivos Android, é RECOMENDADO que ASO, FMO e RS não são usados para o perfil de referência por codificadores.
- [C-1-2] PRECISA oferecer suporte aos perfis de codificação de vídeo SD (Definição padrão) na tabela a seguir.
- DEVE oferecer suporte ao nível 4 do perfil principal.
- DEVE oferecer suporte aos perfis de codificação de vídeo HD (alta definição) como indicados na tabela a seguir.
Se as implementações de dispositivos informarem suporte à codificação H.264 para 720p ou 1080p e resolução de vídeos através das APIs de mídia, eles:
- [C-2-1] PRECISA oferecer suporte aos perfis de codificação na tabela a seguir.
SD (baixa qualidade) | SD (alta qualidade) | HD 720p | HD 1080p | |
---|---|---|---|---|
Resolução do vídeo | 320 x 240 px | 720 x 480 px | 1.280 x 720 px | 1.920 x 1.080 px |
Frame rate do vídeo | 20 qps | 30 fps | 30 fps | 30 fps |
Taxa de bits do vídeo | 384 Kbps | 2 Mbps | 4 Mbps | 10 Mbps |
5.2.3. VP8
Se as implementações de dispositivos forem compatíveis com o codec VP8, elas:
- [C-1-1] PRECISA oferecer suporte aos perfis de codificação de vídeo SD.
- DEVE oferecer suporte aos seguintes perfis de codificação de vídeo em HD (alta definição).
- [C-1-2] PRECISA oferecer suporte à gravação de arquivos Matroska WebM.
- DEVE fornecer um codec VP8 de hardware que atenda às Requisitos de codificação de hardware RTC do projeto WebM, para garantir qualidade aceitável dos serviços de streaming e videoconferência na Web.
Se as implementações do dispositivo relatarem compatibilidade com a codificação VP8 para 720p ou 1080p e resolução de vídeos através das APIs de mídia, eles:
- [C-2-1] PRECISA oferecer suporte aos perfis de codificação na tabela a seguir.
SD (baixa qualidade) | SD (alta qualidade) | HD 720p | HD 1080p | |
---|---|---|---|---|
Resolução do vídeo | 320 x 180 px | 640 x 360 px | 1.280 x 720 px | 1.920 x 1.080 px |
Frame rate do vídeo | 30 fps | 30 fps | 30 fps | 30 fps |
Taxa de bits do vídeo | 800 Kbps | 2 Mbps | 4 Mbps | 10 Mbps |
5.2.4. VP9
Se as implementações de dispositivos forem compatíveis com o codec VP9, elas:
- [C-1-2] PRECISA oferecer suporte ao Perfil 0 de Nível 3.
- [C-1-1] PRECISA oferecer suporte à gravação de arquivos Matroska WebM.
- [C-1-3] PRECISA gerar dados do CodecPrivate.
- DEVE oferecer suporte aos perfis de decodificação de HD conforme indicado na tabela a seguir.
- [C-SR-1] é FORTEMENTE RECOMENDADO para oferecer suporte aos perfis de decodificação de HD como indicado na tabela a seguir se houver um codificador de hardware.
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 | 1,6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
Se as implementações de dispositivos alegarem ser compatíveis com os perfis 2 ou 3 nas APIs Media:
- O suporte para o formato de 12 bits é OPCIONAL.
5.2.5. H.265
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 até resolução de 512 x 512
DEVE oferecer suporte aos perfis de codificação de alta definição conforme indicado na tabela a seguir.- [C-SR-1] é FORTEMENTE RECOMENDADO para dar suporte à o perfil SD 720 x 480 e o de codificação em HD conforme indicado na tabela a seguir, se houver um codificador de hardware.
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 | 1,6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
Iniciar novos requisitos
5.2.6. AV1
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 performance, ou seja, informar os dados de performance pelo
getSupportedFrameRatesFor()
ougetSupportedPerformancePoints()
APIs para resoluções com suporte 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 suportar, e até mesmo, o perfil de codificação HD1080p da na tabela abaixo:
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 |
Encerrar novos requisitos
5,3 Decodificação de vídeo
Se as implementações de dispositivos oferecerem suporte aos codecs VP8, VP9, H.264 ou H.265, elas:
- [C-1-1] PRECISA ser compatível com a resolução dinâmica de vídeo e a troca de frame rate. usando as APIs padrão do Android no mesmo fluxo para todos os pacotes VP8, VP9, Codecs H.264 e H.265 em tempo real e até a resolução máxima suportada de cada codec do dispositivo.
5.3.1. MPEG-2
Se as implementações de dispositivos oferecerem suporte a decodificadores MPEG-2, elas:
- [C-1-1] PRECISA oferecer suporte ao nível alto do perfil principal.
5.3.2. H.263
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 384kbps) e nível 45 (Resoluções QCIF e SQCIF a 30 fps 128kbps).
5.3.3. MPEG-4
Se implementações de dispositivos com decodificadores MPEG-4, elas:
- [C-1-1] PRECISA oferecer suporte ao perfil simples de nível 3.
5.3.4. H.264
Se as implementações de dispositivos oferecerem suporte a decodificadores H.264, elas:
- [C-1-1] PRECISA oferecer suporte ao perfil principal de nível 3.1 e ao perfil de referência. Suporte para ASO (Ordem Arbitrária de Frações), FMO (Ordem Flexível de Macrobloco) e RS (Slices redundantes) é OPCIONAL.
- [C-1-2] PRECISA ser capaz de decodificar vídeos com SD (definição padrão) perfis listados na tabela a seguir e codificados com o perfil de referência e o nível 3.1 do perfil principal (incluindo 720p30).
- DEVE SER capaz de decodificar vídeos com os perfis HD (alta definição) conforme indicado na tabela a seguir.
Se a altura informada pelo método Display.getSupportedModes()
for
igual ou maior que a resolução do vídeo, implementações de dispositivo:
- [C-2-1] PRECISA oferecer suporte aos perfis de decodificação de vídeo HD de 720p nos seguintes tabela.
- [C-2-2] PRECISA oferecer suporte aos perfis de decodificação de vídeo HD 1080p nos seguintes tabela.
SD (baixa qualidade) | SD (alta qualidade) | HD 720p | HD 1080p | |
---|---|---|---|---|
Resolução do vídeo | 320 x 240 px | 720 x 480 px | 1.280 x 720 px | 1.920 x 1.080 px |
Frame rate do vídeo | 30 fps | 30 fps | 60 qps | 30 fps (60 fpsTelevisão) |
Taxa de bits do vídeo | 800 Kbps | 2 Mbps | 8 Mbps | 20 Mbps |
5.3.5. H.265 (HEVC)
Se as implementações de dispositivos oferecerem suporte ao codec H.265, elas:
- [C-1-1] PRECISA ser compatível com o nível 3 do perfil principal e com o vídeo SD e decodificando perfis conforme indicado na tabela a seguir.
- DEVE oferecer suporte aos perfis de decodificação de HD conforme indicado na tabela a seguir.
- [C-1-2] PRECISA oferecer suporte aos perfis de decodificação de HD, conforme indicado no se houver um decodificador de hardware.
Se a altura informada pelo método Display.getSupportedModes()
for
igual ou maior que a resolução do vídeo, então:
- [C-2-1] As implementações de dispositivos PRECISAM ser compatíveis com pelo menos H.265 ou VP9 decodificação de 720, 1080 perfis e Ultra HD.
SD (baixa qualidade) | SD (alta qualidade) | HD 720p | HD 1080p | Ultra HD | |
---|---|---|---|---|---|
Resolução do vídeo | 352 x 288 pixels | 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/60 fps (60 fpsTelevisão com decodificação de hardware H.265) | 60 qps |
Taxa de bits do vídeo | 600 Kbps | 1,6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
Se as implementações de dispositivos alegarem compatibilidade com um perfil HDR pela mídia APIs:
- [C-3-1] As implementações de dispositivos PRECISAM aceitar os metadados HDR obrigatórios de do aplicativo, além de oferecer suporte à extração e saída do HDR necessário metadados do bitstream e/ou contêiner.
- [C-3-2] As implementações de dispositivos PRECISAM exibir corretamente o conteúdo HDR na na tela do dispositivo ou em uma porta de saída de vídeo padrão (por exemplo, HDMI.
5.3.6. VP8
Se as implementações de dispositivos forem compatíveis com o codec VP8, elas:
- [C-1-1] PRECISA oferecer suporte aos perfis de decodificação de SD na tabela a seguir.
- DEVE usar um codec VP8 de hardware que atenda às requisitos.
- DEVE oferecer suporte aos perfis de decodificação de HD na tabela a seguir.
Se a altura informada pelo método Display.getSupportedModes()
for igual
ou maior que a resolução do vídeo, então:
- [C-2-1] As implementações de dispositivos PRECISAM oferecer suporte a perfis de 720p no tabela a seguir.
- [C-2-2] As implementações de dispositivos PRECISAM oferecer suporte a perfis de 1080p no tabela a seguir.
SD (baixa qualidade) | SD (alta qualidade) | HD 720p | HD 1080p | |
---|---|---|---|---|
Resolução do vídeo | 320 x 180 px | 640 x 360 px | 1.280 x 720 px | 1.920 x 1.080 px |
Frame rate do vídeo | 30 fps | 30 fps | 30 fps (60 fpsTelevisão) | 30 (60 fpsTelevisão) |
Taxa de bits do vídeo | 800 Kbps | 2 Mbps | 8 Mbps | 20 Mbps |
5.3.7. VP9
Se as implementações de dispositivos forem compatíveis com o codec VP9, elas:
- [C-1-1] PRECISA oferecer suporte aos perfis de decodificação de vídeo SD, conforme indicado no tabela a seguir.
- DEVE oferecer suporte aos perfis de decodificação de HD conforme indicado na tabela a seguir.
Se as implementações de dispositivos forem compatíveis com o codec VP9 e um decodificador de hardware:
- [C-2-1] PRECISA oferecer suporte aos perfis de decodificação de HD, conforme indicado no tabela.
Se a altura informada pelo método Display.getSupportedModes()
for
igual ou maior que a resolução do vídeo, então:
- [C-3-1] As implementações de dispositivos PRECISAM oferecer suporte a pelo menos um VP9 ou H.265. e decodificação dos perfis 720, 1080 e Ultra HD.
SD (baixa qualidade) | SD (alta qualidade) | HD 720p | HD 1080p | Ultra HD | |
---|---|---|---|---|---|
Resolução do vídeo | 320 x 180 px | 640 x 360 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 (60 fpsTelevisão com decodificação de hardware VP9) | 60 qps |
Taxa de bits do vídeo | 600 Kbps | 1,6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
Se as implementações de dispositivos alegam oferecer suporte a VP9Profile2
ou VP9Profile3
por meio do elemento 'CodecProfileLevel'
APIs de mídia:
- O suporte para o formato de 12 bits é OPCIONAL.
Se as implementações de dispositivos alegarem compatibilidade com um perfil HDR (VP9Profile2HDR
,
VP9Profile2HDR10Plus
, VP9Profile3HDR
, VP9Profile3HDR10Plus
) pelo
APIs de mídia:
- [C-4-1] As implementações de dispositivos PRECISAM aceitar os metadados HDR obrigatórios
(
KEY_HDR_STATIC_INFO
) para todos os perfis HDR e "KEY_HDR10_PLUS_INFO" para perfis HDR10Plus) do aplicativo. Eles também PRECISAM oferecer suporte à extração e saída do metadados HDR exigidos do bitstream e/ou contêiner. - [C-4-2] As implementações de dispositivos PRECISAM exibir corretamente o conteúdo HDR na tela na tela do dispositivo ou em uma porta de saída de vídeo padrão (por exemplo, HDMI.
5.3.8. Dolby Vision
Se as implementações de dispositivos declararem suporte para o decodificador Dolby Vision usando
HDR_TYPE_DOLBY_VISION
, eles:
- [C-1-1] PRECISA fornecer um extrator compatível com Dolby Vision.
- [C-1-2] PRECISA mostrar corretamente o conteúdo do Dolby Vision na tela do dispositivo ou em uma porta de saída de vídeo padrão (por exemplo, HDMI.
- [C-1-3] É NECESSÁRIO definir o ID da faixa de camadas de base compatíveis com versões anteriores (se houver) sejam iguais combinou o ID de faixa da camada Dolby Vision.
5.3.9. AV1
- [C-1-1] PRECISA oferecer suporte ao Perfil 0, incluindo conteúdo de 10 bits.
Iniciar novos requisitos
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 hardware decodificador acelerado:
- [C-2-1] PRECISA ser capaz de decodificar pelo menos os perfis de decodificação de vídeo HD de 720p
na tabela abaixo quando a altura relatada por
Display.getSupportedModes()
é igual ou maior que 720p. - [C-2-2] É NECESSÁRIO decodificar pelo menos os perfis de decodificação de vídeo HD de 1080p
na tabela abaixo quando a altura informada por
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 por meio das APIs de mídia, então: eles:
- [C-3-1] PRECISA oferecer suporte à extração e saída de metadados HDR do bitstream e/ou contêiner.
- [C-3-2] PRECISA exibir corretamente o conteúdo HDR na tela do dispositivo ou em um porta de saída de vídeo padrão (por exemplo, HDMI).
Encerrar novos requisitos
5,4. Gravação em áudio
Embora alguns dos requisitos descritos nesta seção estejam listados como DEVE desde o Android 4.3, a definição de compatibilidade para versões futuras está planejada para mudar para OBRIGATÓRIO. Dispositivos Android novos e já existentes são MAIS IMPORTANTES RECOMENDADO para atender aos requisitos listados como DEVE ou não serão compatíveis com Android quando o upgrade for feito no futuro. para a versão anterior.
5.4.1. Captura de áudio bruta e informações do microfone
Se as implementações de dispositivo declararem android.hardware.microphone
, elas:
[C-1-1] PRECISA permitir a captura de conteúdo de áudio bruto para qualquer stream INPUT
AudioRecord
ouAAudio
que esteja aberto com sucesso. No mínimo, as seguintes características PRECISAM ser compatíveis:- Formato:PCM linear de 16 bits
- Taxas de amostragem:8000, 11025, 16.000, 44.100, 48.000 Hz
- Canais:mono
- Fontes de áudio:
DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
, ouVOICE_PERFORMANCE
. Isso também se aplica às predefinições de entrada equivalentes emAAudio
, para exemplo:AAUDIO_INPUT_PRESET_CAMCORDER
.
DEVE permitir a captura de conteúdo de áudio bruto com as seguintes características:
- Formato: PCM linear de 16 e 24 bits
- Taxas de amostragem: 8000, 11025, 16000, 22050, 24000, 32000, 44100 48.000 Hz
- Canais: o número de canais que o número de microfones no dispositivo
[C-1-2] PRECISA capturar taxas de amostragem acima da média sem aumento de amostragem.
[C-1-3] PRECISA incluir um filtro anti-aliasing adequado quando o as taxas de amostragem fornecidas acima são capturadas com a redução de amostragem.
DEVE permitir captura de conteúdo de áudio bruto com qualidade de rádio AM e DVD, o que significa as seguintes características:
- Formato: PCM linear, 16 bits
- Taxas de amostragem: 22.050, 48.000 Hz
- Canais: estéreo
[C-1-4] PRECISA respeitar a API
MicrophoneInfo
. e preencher adequadamente as informações dos microfones disponíveis no dispositivo pode ser acessado pelos aplicativos de terceirosAudioManager.getMicrophones()
para AudioRecord ativo usandoMediaRecorder.AudioSources DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
ouVOICE_PERFORMANCE
. Se as implementações de dispositivos permitirem captura de áudio bruto com qualidade de rádio AM e DVD eles:[C-2-1] PRECISA capturar sem aumento de amostragem a qualquer proporção maior que 16000:22050 ou 44100:48000.
[C-2-2] PRECISA incluir um filtro anti-aliasing adequado para todos os aumentos na amostragem ou down-amostragem.
5.4.2. Captura para reconhecimento de voz
Se as implementações de dispositivo declararem android.hardware.microphone
, elas:
- [C-1-1] PRECISA capturar
Fonte de áudio
android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION
em uma das taxas de amostragem, 44100 e 48000. - [C-1-2] PRECISA, por padrão, desativar o processamento de áudio com redução de ruído ao
gravando um stream de áudio do
AudioSource.VOICE_RECOGNITION
fonte. [C-1-3] PRECISA, por padrão, desativar qualquer controle automático de ganho ao gravar um stream de áudio da fonte de áudio
AudioSource.VOICE_RECOGNITION
.DEVE exibir características de amplitude em relação à frequência aproximadas planas no intervalo de frequência média: especificamente ±3 dB de 100 Hz a 4.000 Hz para cada e cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.
[C-SR-1] é MUITO RECOMENDADO a exibir níveis de amplitude em baixos da faixa de frequência específica: de ±20 dB de 30 Hz a 100 Hz, em comparação intervalo de frequência média para cada microfone usado para gravar a voz fonte de áudio de reconhecimento de marca.
[C-SR-2] é MUITO RECOMENDADO a exibir níveis de amplitude nos valores da faixa de frequência específica: de ±30 dB de 4.000 Hz a 22 KHz, em comparação com o intervalo de média da frequência de cada microfone usado para gravar a voz fonte de áudio de reconhecimento de marca.
DEVE configurar a sensibilidade da entrada de áudio de forma que uma fonte de tom senoidal de 1.000 Hz tocado a 90 dB de Nível de Pressão do Som (SPL) (medido
a uma distância de 30 cm desse localao lado do microfone) produz uma resposta ideal de RMS 2500 dentro de um intervalo de 1770 e 3530 para 16 bit-samples (ou -22,35 db ±3dB escala total para ponto flutuante/precisão dupla) amostras) para cada microfone usado para gravar o reconhecimento de voz fonte de áudio.DEVE gravar o stream de áudio de reconhecimento de voz para que a amplitude de PCM os níveis rastreiam linearmente as mudanças de SPL de entrada em um intervalo de pelo menos 30 dB, de -18 De dB a +12 dB re 90 dB SPL no microfone.
DEVE gravar o stream de áudio de reconhecimento de voz com harmônico total distorção (THD) menor que 1% para 1 kHz em um nível de entrada de SPL de 90 dB em ao microfone do meu dispositivo.
Se as implementações do dispositivo declararem android.hardware.microphone
e ruído
tecnologias de supressão (redução) ajustadas para o reconhecimento de fala, elas:
- [C-2-1] PRECISA permitir que esse efeito de áudio seja controlável com o
API
android.media.audiofx.NoiseSuppressor
. - [C-2-2] PRECISA identificar cada tecnologia de supressão de ruído de forma exclusiva.
implementação usando o campo
AudioEffect.Descriptor.uuid
.
5.4.3. Capturar para traçar novo trajeto de reprodução
A classe android.media.MediaRecorder.AudioSource
inclui o REMOTE_SUBMIX
fonte de áudio.
Se as implementações de dispositivos declararem android.hardware.audio.output
e
android.hardware.microphone
, eles:
[C-1-1] PRECISA implementar corretamente a fonte de áudio
REMOTE_SUBMIX
para que quando um aplicativo usa a APIandroid.media.AudioRecord
para gravar usando fonte de áudio, ela captura uma combinação de todos os streams de áudio, exceto:AudioManager.STREAM_RING
AudioManager.STREAM_ALARM
AudioManager.STREAM_NOTIFICATION
5.4.4. Cancelador de eco acústico
Se as implementações de dispositivo declararem android.hardware.microphone
, elas:
- DEVE implementar um cancelador de eco acústico
(AEC, na sigla em inglês) ajustada para comunicação por voz e aplicada ao caminho de captura
ao capturar usando
AudioSource.VOICE_COMMUNICATION
.
Se as implementações do dispositivo fornecerem um cancelador de eco acústico, que é
inserido no caminho de áudio de captura quando AudioSource.VOICE_COMMUNICATION
for selecionada, eles:
- [C-SR-1] precisa STRONGLY_RECOMMENDED para declarar isso pelo AcousticEchoCanceler Método de API AcousticEchoCanceler.isAvailable()
- [C-SR-2] estão STRONGLY_RECOMMENDED para permitir que este efeito de áudio seja controlável com o método AcousticEchoCanceler API.
- [C-SR-3] são STRONGLY_RECOMMENDED para identificar exclusivamente cada tecnologia AEC implementação por meio do objeto AudioEffect.Descriptor.uuid .
5.4.5. Captura simultânea
Se as implementações de dispositivos declararem android.hardware.microphone
,elas PRECISAM
implementar a captura simultânea, conforme descrito neste documento. Especificamente:
- [C-1-1] PRECISA permitir o acesso simultâneo ao microfone por um dispositivo de acessibilidade
captura de serviço com
AudioSource.VOICE_RECOGNITION
e pelo menos um captura de aplicativos com qualquerAudioSource
. - [C-1-2] PRECISA permitir o acesso simultâneo ao microfone por um dispositivo
aplicativo com uma função de assistente e pelo menos um aplicativo
capturando com qualquer
AudioSource
, excetoAudioSource.VOICE_COMMUNICATION
ouAudioSource.CAMCORDER
. - [C-1-3] PRECISA silenciar a captura de áudio de qualquer outro aplicativo, exceto
um serviço de acessibilidade, enquanto um aplicativo está capturando com
AudioSource.VOICE_COMMUNICATION
ouAudioSource.CAMCORDER
. No entanto, quando Um app está capturando viaAudioSource.VOICE_COMMUNICATION
e depois outro app pode capturar a ligação se for um aplicativo privilegiado (pré-instalado) com permissãoCAPTURE_AUDIO_OUTPUT
. - [C-1-4] Se dois ou mais aplicativos estiverem capturando simultaneamente nenhum dos aplicativos tem uma interface na parte superior, aquela que iniciou a captura mais recentemente recebe áudio.
5,5. Reprodução de áudio
O Android inclui suporte para permitir que apps reproduzam áudio pela própria como um periférico, conforme definido na seção 7.8.2.
5.5.1. Reprodução de áudio bruto
Se as implementações de dispositivo declararem android.hardware.audio.output
, elas:
[C-1-1] PRECISA permitir a reprodução de conteúdo de áudio bruto com as seguintes características:
- Formatos de origem: PCM linear, 16 bits, 8 bits, flutuante
- Canais: mono, estéreo, configurações multicanal válidas com até 8 canais
- Taxas de amostragem (em Hz):
- 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 no canal configurações listadas acima
- 96.000 em mono e estéreo
5.5.2. Efeitos de áudio
O Android oferece uma API para efeitos de áudio. para implementações de dispositivos.
Se as implementações de dispositivos declararem o recurso android.hardware.audio.output
,
eles:
- [C-1-1] PRECISA oferecer suporte às APIs
EFFECT_TYPE_EQUALIZER
e ImplementaçõesEFFECT_TYPE_LOUDNESS_ENHANCER
controláveis pelo Subclasses de AudioEffectEqualizer
eLoudnessEnhancer
. - [C-1-2] PRECISA oferecer suporte à implementação da API do visualizador, controlável pelo
a classe
Visualizer
. - [C-1-3] PRECISA oferecer suporte à implementação de
EFFECT_TYPE_DYNAMICS_PROCESSING
. controlável pela subclasse AudioEffectDynamicsProcessing
.
Iniciar novos requisitos
- [C-1-4] PRECISA oferecer suporte a efeitos de áudio com na entrada e na saída de pontos flutuantes.
- [C-1-5] PRECISA garantir que os efeitos de áudio ofereçam suporte a vários canais, até a contagem de canais de mixer, também conhecida como FCC_LIMIT.
Encerrar novos requisitos
- DEVE oferecer suporte a
EFFECT_TYPE_BASS_BOOST
,EFFECT_TYPE_ENV_REVERB
, implementações deEFFECT_TYPE_PRESET_REVERB
eEFFECT_TYPE_VIRTUALIZER
controlável pelas subclassesAudioEffect
BassBoost
,EnvironmentalReverb
,PresetReverb
eVirtualizer
. - [C-SR-1] É FORTEMENTE RECOMENDADO para oferecer suporte a efeitos em pontos flutuantes e multicanal.
5.5.3. Volume de saída de áudio
Implementações de dispositivos automotivos:
- DEVE permitir o ajuste do volume do áudio
separadamente por stream de áudio com base no tipo ou uso de conteúdo, conforme definido
por AudioAttributes
e uso de áudio do carro, conforme definido publicamente em
android.car.CarAudioManager
.
5.5.4. Descarregamento de áudio
Se as implementações de dispositivos forem compatíveis com a reprodução de descarregamento de áudio, elas:
- [C-SR-1] É FORTEMENTE RECOMENDADO para cortar o conteúdo de áudio reproduzido sem lacunas entre dois clipes com o mesmo formato quando especificado pelo API AudioTrack sem lacunas e o contêiner de mídia do MediaPlayer.
5,6. Latência de áudio
A latência de áudio é o atraso no tempo em que um sinal de áudio passa por um sistema. Muitas classes de aplicativos dependem de latências curtas para atingir efeitos sonoros.
Para os fins desta seção, use as seguintes definições:
- latência de saída. O intervalo entre o momento em que um aplicativo grava um frame de dados codificados em PCM e quando o som correspondente é apresentado ao em um transdutor no dispositivo ou o sinal sai do dispositivo por uma e podem ser observados externamente.
- latência de saída a frio. O tempo entre o início de um stream de saída e o a hora de apresentação do primeiro frame com base em carimbos de data/hora, quando a saída de áudio sistema esteve inativo e desligado antes da solicitação.
- latência de saída contínua. A latência de saída para frames subsequentes, depois que o dispositivo estiver reproduzindo áudio.
- latência de entrada. É o intervalo entre o momento em que um som é apresentado entre o dispositivo e um transdutor ou a entrada de sinal no dispositivo via uma porta e quando um aplicativo lê o frame correspondente de dados codificados em PCM.
- entrada perdida. A parte inicial de um sinal de entrada que é inutilizável ou indisponível.
- latência de entrada a frio. O tempo entre o início da transmissão e quando o primeiro frame válido, quando o sistema de entrada de áudio está ocioso, e desligados antes da solicitação.
latência de entrada contínua. a latência de entrada para frames subsequentes; enquanto o dispositivo está capturando áudio.
latência de ida e volta contínua. A soma da latência de entrada contínua mais latência de saída contínua mais um período de buffer. O período de buffer permite tempo para o app processar o sinal e tempo para a mitigação do app a diferença entre os fluxos de entrada e saída.
API OpenSL ES PCM da fila de buffer. O conjunto de dados de PCM OpenSL ES (link em inglês) APIs no Android NDK.
API Native Audio da AAudio. O conjunto de APIs AAudio no Android NDK.
Carimbo de data/hora. Um par que consiste em uma posição relativa do frame em um e o tempo estimado quando esse frame entra ou sai do de processamento de áudio no endpoint associado. Consulte também AudioTimestamp.
glitch. Uma interrupção temporária ou um valor de amostra incorreto no sinal de áudio normalmente é causado por buffer underrun para saída, estouro de buffer para entrada ou qualquer outra fonte de ruído digital ou analógico.
desvio médio absoluto. A média do valor absoluto do desvios da média de um conjunto de valores.
latência do toque para tom. O tempo entre o toque na tela e o momento em que um som gerado como resultado desse toque é ouvido no alto-falante.
Se as implementações de dispositivos declararem android.hardware.audio.output
, elas
PRECISA atender ou exceder os seguintes requisitos:
- [C-1-1] O carimbo de data/hora da saída retornado por
AudioTrack.getTimestamp (link em inglês)
e
AAudioStream_getTimestamp
tem precisão de +/- 2 ms. [C-1-2] Latência de saída frio de 500 milissegundos ou menos.
[C-1-3] É NECESSÁRIO abrir um stream de saída usando
AAudioStreamBuilder_openStream()
levar menos de 1.000 milissegundos.
Se as implementações de dispositivos declararem android.hardware.audio.output
, elas serão
É RECOMENDADO atender ou superar os seguintes requisitos:
- [C-SR-1] Latência de saída fria de 100 milissegundos ou menos nos dados dos alto-falantes caminho.
- [C-SR-2] Latência de toque para tom de 80 milissegundos ou menos.
- [C-SR-4] O carimbo de data/hora de saída retornado por
AudioTrack.getTimestamp (link em inglês)
e
AAudioStream_getTimestamp
tem precisão de +/- 1 ms.
Iniciar novos requisitos
- [C-SR-4] As latências de ida e volta calculadas com base na entrada e na saída
os carimbos de data/hora retornados por
AAudioStream_getTimestamp
são FORTEMENTE RECOMENDADOS esteja dentro de 30 ms da latência de ida e volta medida paraAAUDIO_PERFORMANCE_MODE_NONE
eAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
para alto-falantes, fones de ouvido com e sem fio.
Encerrar novos requisitos
Se as implementações de dispositivos atenderem aos requisitos acima, após qualquer calibração, ao usar a API de áudio nativo da AAudio, para saída contínua e a latência de saída fria em pelo menos um áudio com suporte dispositivo de saída, eles são:
- [C-SR-5] É FORTEMENTE RECOMENDADO que você informe áudio de baixa latência ao declarar
Sinalização de recurso
android.hardware.audio.low_latency
. - [C-SR-6] É MUITO RECOMENDADO para atender aos requisitos de baixa latência áudio pela API AAudio.
- [C-SR-7] É MUITO RECOMENDADO para garantir que os streams que retornam
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
deAAudioStream_getPerformanceMode()
, o valor retornado porAAudioStream_getFramesPerBurst()
é menor ou igual ao valor retornado porandroid.media.AudioManager.getProperty(String)
para a chave de propriedadeAudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER
.
Se as implementações do dispositivo não atenderem aos requisitos de áudio de baixa latência via API de áudio nativa da AAudio, eles:
- [C-2-1] NÃO É POSSÍVEL informar suporte para áudio de baixa latência.
Se as implementações de dispositivos incluírem android.hardware.microphone
, elas
PRECISA atender a estes requisitos de áudio de entrada:
- [C-3-1] Limite o erro nos carimbos de data/hora de entrada, conforme retornado por
AudioRecord.getTimestamp (link em inglês)
ou
AAudioStream_getTimestamp
, para +/- 2 ms. "Erro" aqui significa o desvio do valor correto. - [C-3-2] Latência de entrada a frio de 500 milissegundos ou menos.
- [C-3-3] É NECESSÁRIO abrir um stream de entrada usando
AAudioStreamBuilder_openStream()
levar menos de 1.000 milissegundos.
Se as implementações de dispositivos incluírem android.hardware.microphone
, elas serão
É RECOMENDADO atender a estes requisitos de entrada de áudio:
[C-SR-8] Latência de entrada a frio de 100 milissegundos ou menos pelo microfone caminho dos dados.
[C-SR-11] Limite o erro nos carimbos de data/hora de entrada, conforme retornado por AudioRecord.getTimestamp (link em inglês) ou
AAudioStream_getTimestamp
, para +/- 1 ms.
Se as implementações de dispositivo declararem android.hardware.audio.output
e
android.hardware.microphone
, eles:
- [C-SR-12] É FORTEMENTE RECOMENDADO ter uma latência média contínua de ida e volta de 50 milissegundos ou menos em 5 medições, com um Desvio médio absoluto menos de 10 ms em pelo menos um caminho compatível.
5,7. Protocolos de rede
As implementações de dispositivos PRECISAM oferecer suporte à protocolos de rede de mídia para reprodução de áudio e vídeo, conforme especificado na documentação do SDK do Android.
Para cada codec e formato de contêiner que é necessária uma implementação de dispositivo suporte, a implementação do dispositivo:
[C-1-1] PRECISA oferecer suporte a esse codec ou contêiner por HTTP e HTTPS.
[C-1-2] PRECISA oferecer suporte aos formatos de segmento de mídia correspondentes, conforme mostrado em a tabela de formatos de segmento de mídia abaixo Protocolo de rascunho HTTP Live Streaming, versão 7.
[C-1-3] PRECISA oferecer suporte aos formatos de payload do RTSP correspondentes, como mostrado no tabela RTSP abaixo. Para exceções, consulte as notas de rodapé da tabela em seção 5.1.
Formatos de segmento de mídia
Formatos de segmentos | Referências | Compatibilidade necessária com o codec |
---|---|---|
Stream de transporte MPEG-2 | ISO 13818 (link em inglês) |
Codecs de vídeo:
e MPEG-2. Codecs de áudio:
|
AAC com enquadramento ADTS e tags ID3 | ISO 13818-7 (link em inglês) | Consulte a seção 5.1.1 para mais detalhes sobre o AAC e as variantes dele. |
WebVTT | WebVTT |
RTSP (RTP, SDP)
Nome do perfil | Referências | Compatibilidade necessária com o codec |
---|---|---|
H264 AVC | RFC 6184 (link em inglês) | Consulte a seção 5.1.8 para detalhes sobre o H264 AVC |
MP4A-LATM | RFC 6416 (em inglês) | Consulte a seção 5.1.3 para mais detalhes sobre o AAC e as variantes dele. |
H263-1998 |
RFC 3551 (link em inglês) RFC 4629 (link em inglês) RFC 2190 |
Consulte a seção 5.1.8 para saber mais sobre o H263 |
T263-2000 | RFC 4629 (link em inglês) | Consulte a seção 5.1.8 para saber mais sobre o H263 |
AMR | RFC 4867 (link em inglês) | Consulte a seção 5.1.3 para detalhes sobre o AMR-NB |
AMR-WB | RFC 4867 (link em inglês) | Consulte a seção 5.1.3 para mais detalhes sobre o AMR-WB. |
MP4V-ES | RFC 6416 (em inglês) | Consulte a seção 5.1.8 para mais detalhes sobre o MPEG-4 SP, |
mpeg4-genérico | RFC 3640 (em inglês) | Consulte a seção 5.1.3 para mais detalhes sobre o AAC e as variantes dele. |
MP2T | RFC 2250 (link em inglês) | Consulte a seção Fluxo de transporte MPEG-2 abaixo da HTTP Live Streaming para mais detalhes. |
5,8. Mídia segura
Se as implementações de dispositivos oferecerem suporte a saída de vídeo segura e forem capazes de oferecendo suporte a superfícies seguras, elas:
- [C-1-1] PRECISA declarar compatibilidade com
Display.FLAG_SECURE
.
Se as implementações de dispositivos declararem suporte a Display.FLAG_SECURE
e suporte
protocolo de display sem fio, elas:
- [C-2-1] PRECISA proteger o link com um mecanismo com criptografia forte, como como HDCP 2.x ou superior para telas conectadas por meio de protocolos sem fio. como o Miracast.
Se as implementações de dispositivos declararem suporte a Display.FLAG_SECURE
e
oferecem suporte a uma tela externa com fio, eles:
- [C-3-1] PRECISA oferecer suporte a HDCP 1.2 ou mais recente para todas as telas externas conectadas. por uma porta com fio acessível ao usuário.
5,9. Interface digital para instrumentos musicais (MIDI)
Se as implementações de dispositivos relatarem compatibilidade com o recurso android.software.midi
por meio do
android.content.pm.PackageManager
, ela:
[C-1-1] PRECISA oferecer suporte a MIDI em todos os transportes de hardware compatíveis com MIDI para que fornecem conectividade genérica não MIDI, em que esses transportes são:
- Modo host USB, seção 7.7
- MIDI sobre Bluetooth LE atuando em função central, seção 7.4.3
[C-1-2] PRECISA oferecer suporte ao transporte de software MIDI entre apps. (dispositivos MIDI virtuais)
[C-1-3] PRECISA incluir libamidi.so (suporte a MIDI nativo)
DEVE oferecer suporte a MIDI sobre o modo de periférico USB, seção 7.7
5,10 Áudio profissional
Se as implementações de dispositivos relatarem compatibilidade com o recurso
android.hardware.audio.pro
pelo
android.content.pm.PackageManager
, ela:
- [C-1-1] PRECISA relatar a compatibilidade com o recurso.
android.hardware.audio.low_latency
: - [C-1-2] PRECISA ter a latência de ida e volta contínua do áudio, conforme definido em seção 5.6 Latência de áudio de 25 milissegundos ou menos em pelo menos um caminho compatível.
- [C-1-3] PRECISA incluir portas USB compatíveis com o modo host USB e USB modo periférico.
- [C-1-4] PRECISA relatar a compatibilidade com o recurso
android.software.midi
. - [C-1-5] PRECISA atender aos requisitos de latência e áudio USB usando o
Áudio nativo AAudio
API e
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
. - [C-1-6] PRECISA ter latência de saída de frio de 200 milissegundos ou menos.
- [C-1-7] PRECISA ter latência de entrada a frio de 200 milissegundos ou menos.
[C-1-8] PRECISA ter uma latência média entre toques e tons de 80 milissegundos ou menos. em pelo menos cinco medições do alto-falante para o caminho de dados do microfone.
[C-SR-1] É FORTEMENTE RECOMENDADO para atender às latências definidas na seção 5,6 Latência de áudio, de 20 milissegundos ou menor que 5 medições com desvio absoluto médio menor que 5 milésimos de segundo entre o alto-falante e o microfone.
[C-SR-2] É FORTEMENTE RECOMENDADO a atender aos requisitos de áudio profissional para: latência de áudio de ida e volta contínua, latência de entrada a frio e saída de frio latência e requisitos de áudio USB usando a API de áudio nativo da AAudio no caminho do MMAP.
[C-SR-3] É FORTEMENTE RECOMENDADO para fornecer um nível consistente de CPU desempenho enquanto o áudio está ativo e a carga da CPU varia. Isso deve ser testado usando o app Android SynthMark. O SynthMark usa um sintetizador de software executado em um framework de áudio simulado que mede o desempenho do sistema. Consulte a Documentação do SynthMark para conferir uma explicação sobre os comparativos de mercado. SynthMark precisa ser executado usando o a opção de "Teste automatizado" e obter os seguintes resultados:
- Voicemark.90 >= 32 vozes
- latênciamark.Fixed.little <= 15 ms
- latênciamark.dynamic.little <= 50 ms
DEVE minimizar a imprecisão e o desvio do relógio de áudio em relação ao horário padrão.
DEVE minimizar a variação do relógio de áudio em relação à CPU
CLOCK_MONOTONIC
quando ambos estão ativos.DEVE minimizar a latência de áudio em transdutores no dispositivo.
DEVE minimizar a latência de áudio no áudio digital USB.
DEVE documentar as medições de latência de áudio em todos os caminhos.
DEVE minimizar a instabilidade nos tempos de entrada de callback para conclusão do buffer de áudio, já que esse afeta a porcentagem utilizável da largura de banda total da CPU pelo callback.
DEVE fornecer zero falhas de áudio em condições normais de uso na latência relatada.
DEVE fornecer zero diferença de latência entre os canais.
DEVE minimizar a latência média de MIDI em todos os transportes.
DEVE minimizar a variabilidade de latência MIDI sob carga (instabilidade) em todos os transportes.
DEVE fornecer carimbos de data/hora MIDI precisos em todos os transportes.
DEVE minimizar o ruído do sinal de áudio em transdutores do dispositivo, incluindo os imediatamente após a inicialização a frio.
DEVE fornecer zero diferença de relógio de áudio entre os lados de entrada e saída do endpoints correspondentes, quando ambos estão ativos. Exemplos de respostas os endpoints incluem o microfone e o alto-falante do dispositivo ou a entrada de entrada de áudio e saída.
DEVE lidar com callbacks de conclusão do buffer de áudio para os lados de entrada e saída de endpoints correspondentes no mesmo encadeamento quando ambos estiverem ativos, e inserir o callback de saída imediatamente após o retorno do callback de entrada. Ou se não for viável lidar com os retornos de chamada no mesmo thread, insira o de saída logo após inserir o retorno de chamada para permitir que o tenha um tempo consistente entre os lados de entrada e saída.
DEVE minimizar a diferença de fase entre o buffer de áudio HAL para a entrada e lados de saída dos endpoints correspondentes.
DEVE minimizar a latência de toque.
DEVE minimizar a variabilidade da latência de toque sob carga (instabilidade).
Se as implementações de dispositivos atenderem a todos os requisitos acima, elas:
- [C-SR-4] É MUITO RECOMENDADO para informar o suporte para o recurso
android.hardware.audio.pro
peloandroid.content.pm.PackageManager
.
Se as implementações do dispositivo incluírem uma entrada para fone de ouvido de 3,5 mm com quatro condutores, elas:
[C-2-1] PRECISA ter uma latência média contínua de áudio de ida e volta, conforme definido em seção 5.6 Latência de áudio, de 20 milissegundos ou menos, mais de 5 medições com desvio absoluto médio inferior a 5 milissegundos o caminho da entrada de áudio usando uma Dongle de loopback de áudio.
[C-SR-5] MUITO RECOMENDADO para obedecer à seção Especificações para dispositivos móveis (jack) da Especificação de fone de ouvido de áudio com fio (v1.1).
Se as implementações do dispositivo omitirem uma entrada de áudio de 3,5 mm com 4 condutores e incluem portas USB compatíveis com o modo host USB, elas:
- [C-3-1] PRECISA implementar a classe de áudio USB.
- [C-3-2] PRECISA ter uma latência média contínua de áudio de ida e volta de 25 milissegundos ou menos, mais de 5 medições com desvio absoluto médio menos de 5 milissegundos pela porta do modo host USB usando a classe de áudio USB. (Isso pode ser medido com o uso de um adaptador USB-3,5 mm e um loopback de áudio ou uma interface de áudio USB com cabos patch para conectar entradas para saídas).
- [C-SR-6] É FORTEMENTE RECOMENDADO para oferecer suporte a E/S simultâneas com até oito canais em cada direção, taxa de amostragem de 96 kHz e profundidade de 24 ou 32 bits, quando usadas com periféricos de áudio USB que também atendem a esses requisitos.
- [C-SR-7] É FORTEMENTE RECOMENDADO para atender a esse grupo de requisitos usando a API de áudio nativa da AAudio no caminho do MMAP.
Se as implementações de dispositivos incluírem uma porta HDMI, elas:
- DEVE oferecer suporte à saída em estéreo e oito canais em 20 bits ou 24 bits de profundidade e 192 kHz sem perda ou reamostragem de profundidade de bits em pelo menos uma configuração.
5,11. Capturar para não processados
O Android inclui suporte à gravação de áudio não processado pelo
Fonte de áudio android.media.MediaRecorder.AudioSource.UNPROCESSED
. Em
OpenSL ES, pode ser acessado com a predefinição de gravação
SL_ANDROID_RECORDING_PRESET_UNPROCESSED
:
Se o dispositivo tiver a intenção de oferecer suporte a fontes de áudio não processadas e tornar para que ele seja disponibilizado para apps de terceiros, eles:
[C-1-1] PRECISA informar o suporte pelo
android.media.AudioManager
. propriedade PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.[C-1-2] PRECISA exibir aproximadamente amplitude em relação à frequência plana características na faixa média de frequência: especificamente ±10 dB do 100 Hz a 7.000 Hz para cada microfone usado para gravar os áudios não processados fonte de áudio.
[C-1-3] PRECISA exibir níveis de amplitude na frequência baixa. especificamente de ±20 dB de 5 z a 100 Hz em comparação com o dos intervalos de frequência média de cada microfone usado para gravar uma fonte de áudio não processada.
[C-1-4] PRECISA exibir níveis de amplitude nas faixas de alta frequência. especificamente de ±30 dB de 7.000 Hz a 22 KHz em comparação com a dos intervalos de frequência média de cada microfone usado para gravar uma fonte de áudio não processada.
[C-1-5] PRECISA definir a sensibilidade da entrada de áudio de forma que uma frequência sinusoidal de 1.000 Hz fonte de tons reproduzida a um nível de pressão sonora (SPL, na sigla em inglês) de 94 dB gera uma resposta com RMS de 520 para amostras de 16 bits (ou escala total de -36 dB para ponto flutuante/duplo amostras de precisão) para cada microfone usado para gravar os fonte de áudio.
[C-1-6] PRECISA ter uma relação sinal-ruído (SNR, na sigla em inglês) em 60 dB ou maior por de cada microfone usado para gravar a fonte de áudio não processada. (enquanto o SNR é medido como a diferença entre SPL de 94 dB e equivalente SPL do ruído próprio, ponderado por A).
[C-1-7] PRECISA ter uma distorção harmônica total (THD) menor que 1% para 1 kHZ a 90 dB de nível de entrada SPL em cada microfone usado para gravar a fonte de áudio não processada.
[C-1-8] NÃO PODE ter nenhum outro processamento de sinal (por exemplo, ganho automático) Controle, filtro de passagem alta ou cancelamento de eco) no caminho que não seja um multiplicador de nível para alcançar o intervalo desejado. Resumindo:
- [C-1-9] Se houver algum processamento de sinal na arquitetura motivo, ele PRECISA ser desativado e introduzir efetivamente nenhum atraso ou latência extra para o caminho do indicador.
- [C-1-10] O multiplicador de nível, embora esteja no caminho, NÃO PODE SER introduzir atraso ou latência no caminho do sinal.
Todas as medições de SPL são feitas diretamente ao lado do microfone em teste. No caso de várias configurações de microfone, estes requisitos se aplicam a: cada microfone.
Se as implementações de dispositivo declararem android.hardware.microphone
, mas não
dão suporte a fontes de áudio não processadas, elas:
- [C-2-1] PRECISA retornar
null
paraAudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED)
. método da API, para indicar corretamente a falta de suporte. - [C-SR-1] ainda é FORTEMENTE RECOMENDADO para atender ao maior número possível dos requisitos para o caminho do sinal da origem de gravação não processada.
5,12. Vídeo HDR
O Android 13 é compatível com as tecnologias HDR, conforme descrito em um documento a seguir.
Formato pixel
Se um decodificador de vídeo anunciar compatibilidade com COLOR_FormatYUVP010:
[C-1-1] PRECISA oferecer suporte ao formato P010 para leitura de CPU (ImageReader, MediaImage, ByteBuffer). No Android 13, o P010 é relaxado para permitir uma passada arbitrária para o Y. e UVs.
[C-1-2] O buffer de saída P010 PRECISA poder ser amostrado pela GPU (quando alocada com uso de GPU_SAMPLING). Isso permite a composição de GPUs e a personalização e o mapeamento de tons por apps.
Se um decodificador de vídeo anunciar compatibilidade com COLOR_Format32bitABGR2101010, ele:
- [C-2-1] PRECISA oferecer suporte ao formato RGBA_1010102 para a superfície de saída e Legível pela CPU (saída do ByteBuffer).
Se um codificador de vídeo anunciar compatibilidade com COLOR_FormatYUVP010, ele:
- [C-3-1] PRECISA oferecer suporte ao formato P010 para superfície de entrada e gravação de CPU. (ImageWriter, MediaImage, ByteBuffer).
Se um codificador de vídeo anunciar compatibilidade com COLOR_Format32bitABGR2101010, ele:
- [C-4-1] PRECISA oferecer suporte ao formato RGBA_1010102 para a superfície de entrada e a capacidade de gravação da CPU. (ImageWriter, ByteBuffer). Observação: a conversão entre várias curvas NÃO são necessárias para codificadores.
Requisitos de captura HDR
Para todos os codificadores de vídeo compatíveis com perfis HDR, as implementações de dispositivos:
[C-5-1] NÃO PODE presumir que os metadados HDR são precisos. Por exemplo, o um frame codificado pode ter pixels além do nível máximo de luminância, ou histograma pode não ser representativo do frame.
DEVE agregar metadados dinâmicos em HDR para gerar estática HDR apropriada metadados para streams codificados, que devem ser gerados no final de cada de codificador-decodificador.
Se as implementações de dispositivos oferecerem suporte à captura HDR usando as APIs CamcorderProfile então eles:
[C-6-1] também PRECISA oferecer suporte à captura HDR com as APIs Camera2.
[C-6-2] PRECISA oferecer suporte a pelo menos um codificador de vídeo acelerado por hardware nos todas as tecnologias HDR com suporte.
[C-6-3] PRECISA oferecer suporte, no mínimo, à captura de HLG.
[C-6-4] PRECISA oferecer suporte à gravação de metadados HDR (se aplicável para HDR no arquivo de vídeo capturado. Para AV1, HEVC e DolbyVision isso significa incluir os metadados no bitstream codificado.
[C-6-5] PRECISA oferecer suporte a P010 e COLOR_FormatYUVP010.
[C-6-6] PRECISA oferecer suporte ao mapeamento de tons HDR para SDR por padrão com aceleração de hardware para o perfil capturado. Em outras palavras, Se um dispositivo puder capturar HDR10+ HEVC, o decodificador HEVC padrão DEVE ser capaz de para decodificar o stream capturado em SDR.
Requisitos de edição de HDR
Se as implementações de dispositivos incluírem codificadores de vídeo compatíveis com a edição HDR, eles:
- DEVE usar latência mínima para gerar os metadados HDR quando ausentes, e DEVEM lidar com situações em que os metadados estão presentes para alguns e não para outros. Esses metadados DEVEM ser precisos (por exemplo, representam o pico de luminância real e o histograma do quadro).
Se a implementação do dispositivo incluir codecs compatíveis com FEATURE_HdrEditing
,
codecs:
[C-7-1] PRECISA oferecer suporte a pelo menos um perfil HDR.
[C-7-2] PRECISA oferecer suporte a
FEATURE_HdrEditing
em todos os perfis HDR anunciados por esse codec. Em outras palavras, eles PRECISAM oferecer suporte à geração de metadados HDR quando não está presente em todos os perfis HDR com suporte e que usam metadados HDR.[C-7-3] PRECISA oferecer suporte aos seguintes formatos de entrada do codificador de vídeo que completam preservar o sinal decodificado em HDR:
- RGBA_1010102 (já está na curva de transferência de destino) para as duas entradas e o ByteBuffer e PRECISA anunciar o suporte para COLOR_Format32bitABGR2101010.
Se a implementação do dispositivo incluir codecs compatíveis com FEATURE_HdrEditing, dispositivo:
- [C-7-4] É NECESSÁRIO anunciar o suporte à extensão OpenGL EXT_YUV_target.
6. Compatibilidade de opções e ferramentas para desenvolvedores
6.1. Ferramentas para desenvolvedores
Implementações de dispositivos:
- [C-0-1] PRECISA ser compatível com as Ferramentas para Desenvolvedores do Android fornecidas na SDK do Vertex AI Pipelines.
-
- [C-0-2] PRECISA oferecer suporte ao adb, conforme documentado no SDK do Android e no shell
fornecidos no AOSP, que podem ser usados por desenvolvedores de apps,
incluindo
dumpsys
cmd stats
- [C-0-11] PRECISA oferecer suporte ao comando shell
cmd testharness
. Fazendo upgrade implementações de dispositivos de uma versão anterior do Android sem uma um bloco de dados persistente pode ser isento de C-0-11. - [C-0-3] NÃO PODE alterar o formato ou o conteúdo do sistema do dispositivo eventos (bateriastats , discostats, impressão digital, Graphstats, netstats, notificação, procstats) registrados pelo comando dumpsys.
- [C-0-10] PRECISA gravar, sem omissão, e fazer os seguintes eventos
acessível e disponível para o comando shell do
cmd stats
e oStatsManager
Classe da API do sistema.- ActivityForegroundStateChanged
- Anomalia detectada
- AppBreadcrumbReported
- Ocorreram AppCrash
- O AppStart ocorreu
- BatteryLevelChanged
- BatterySaverModeStateChanged
- BleScanResultReceived
- BleScanStateChanged
- CobrançaStateChanged
- DeviceIdleModeStateChanged:
- ForegroundServiceStateChanged
- GpsScanStateChanged
- JobStateChanged
- PluggedStateChanged
- ScheduledJobStateChanged
- ScreenStateChanged
- SyncStateChanged
- SystemElapsedRealtime
- UidProcessStateChanged
- WakelockStateChanged
- Alarme de ativação ocorreu
- WifiLockStateChanged
- WifiMulticastLockStateChanged
- WifiScanStateChanged
- [C-0-4] PRECISA fazer com que o daemon do adb do lado do dispositivo fique inativo por padrão e É NECESSÁRIO haver um mecanismo acessível ao usuário para ativar o Android Debug Ponte
- [C-0-5] PRECISA oferecer suporte ao adb seguro. O Android inclui suporte a chamadas adb: O adb seguro permite o uso do adb em hosts autenticados conhecidos.
- [C-0-6] PRECISA fornecer um mecanismo que permita a conexão do adb de uma máquina host. Especificamente:
Se as implementações de dispositivos sem porta USB forem compatíveis com o modo periférico, elas:
- [C-3-1] PRECISA implementar o adb via rede de área local (como ou Wi-Fi).
- [C-3-2] PRECISA fornecer drivers para Windows 7, 8 e 10, permitindo que os desenvolvedores se conectem ao dispositivo usando o protocolo adb.
Se as implementações de dispositivos oferecerem suporte a conexões adb com uma máquina host via Wi-Fi ou Ethernet, eles:
- [C-4-1] PRECISA ter o método
AdbManager#isAdbWifiSupported()
. retornartrue
.
Se as implementações de dispositivos oferecerem suporte a conexões adb com uma máquina host via Wi-Fi ou Ethernet inclui pelo menos uma câmera, eles:
- [C-5-1] PRECISA ter o método
AdbManager#isAdbWifiQrSupported()
. retornartrue
.
- [C-0-2] PRECISA oferecer suporte ao adb, conforme documentado no SDK do Android e no shell
fornecidos no AOSP, que podem ser usados por desenvolvedores de apps,
incluindo
Serviço de monitoramento de depuração Dalvik (ddms)
- [C-0-7] PRECISA oferecer suporte a todos os recursos de ddms, conforme documentado no SDK do Android. Como o ddms usa adb, o suporte para ddms DEVE estar inativo por padrão, mas DEVE ser suportado sempre que o usuário ativar o Android Debug Bridge. acima.
SysTrace (em inglês)
- [C-0-9] PRECISA oferecer suporte à ferramenta Systrace, conforme documentado no SDK do Android. O Systrace precisa estar inativo por padrão e PRECISA haver uma instância acessível ao usuário para ativar o Systrace.
Perfetto (link em inglês)
- [C-SR-1] É FORTEMENTE RECOMENDADO expor um
/system/bin/perfetto
binário para o usuário do shell com o qual o cmdline obedece a documentação do perfetto (link em inglês). - [C-SR-2] O binário do perfetto é FORTEMENTE RECOMENDADO para aceitar como entrada uma protobuf que está em conformidade com o esquema definido em a documentação do perfetto (em inglês).
- [C-SR-3] O binário do perfetto é MUITO RECOMENDADO para escrever como saída uma rastro protobuf que esteja em conformidade com o esquema definido em a documentação do perfetto (em inglês).
- [C-SR-4] É MUITO RECOMENDADO fornecer, pelo binário perfetto, Pelo menos as fontes de dados descritas na documentação do Perfeito.
- [C-SR-1] É FORTEMENTE RECOMENDADO expor um
-
- [C-0-12] É NECESSÁRIO gravar um Atom
LMK_KILL_OCCURRED_FIELD_NUMBER
no Status do registro quando um app é encerrado pelo Low Memory Killer.
- [C-0-12] É NECESSÁRIO gravar um Atom
Modo arcabouço de testes Se as implementações de dispositivos oferecerem suporte ao comando shell
cmd testharness
e executarcmd testharness enable
, eles:- [C-2-1] PRECISA retornar
true
paraActivityManager.isRunningInUserTestHarness()
- [C-2-2] PRECISA implementar o modo de arcabouço de testes, conforme descrito em Documentação do modo de arcabouço de testes.
- [C-2-1] PRECISA retornar
Informações de trabalho da GPU
Implementações de dispositivos:
- [C-0-13] É NECESSÁRIO implementar o comando shell
dumpsys gpu --gpuwork
para exibir os dados de trabalho agregados da GPU retornados pelo kernelpower/gpu_work_period
tracepoint ou não exibirá dados se o tracepoint não for compatível. O AOSP implementação éframeworks/native/services/gpuservice/gpuwork/
.
- [C-0-13] É NECESSÁRIO implementar o comando shell
Se as implementações do dispositivo informarem o suporte ao Vulkan 1.0 ou mais recente pelo
android.hardware.vulkan.version
:
- [C-1-1] PRECISA fornecer uma affordance para o desenvolvedor do app ativar/desativar. Camadas de depuração da GPU.
- [C-1-2] PRECISA, quando as camadas de depuração de GPU estiverem ativadas, enumerar as camadas bibliotecas fornecidas por ferramentas externas (ou seja, não fazem parte da plataforma ou pacote de aplicativos) encontrados nos aplicativos depuráveis diretório base para Suporte a vkEnumerateInstanceLayerProperties() e vkCreateInstance() métodos da API.
6.2. Opções do desenvolvedor
O Android inclui suporte para que os desenvolvedores configurem configurações relacionadas ao desenvolvimento.
As implementações de dispositivos PRECISAM fornecer uma experiência consistente para As opções do desenvolvedor:
- [C-0-1] PRECISA respeitar android.settings.APPLICATION_DEVELOPMENT_CONFIG para mostrar as configurações relacionadas ao desenvolvimento de aplicativos. O sistema upstream do Android oculta o menu "Opções do desenvolvedor" por padrão e permite que os usuários Abra as "Opções do desenvolvedor" depois de pressionar sete (7) vezes em Configurações > Sobre o dispositivo > Número da versão.
- [C-0-2] É NECESSÁRIO ocultar as Opções do desenvolvedor por padrão.
- [C-0-3] PRECISA fornecer um mecanismo claro que não dê prioridade tratamento a um app de terceiros em vez de outro para permitir que o desenvolvedor Opções. PRECISA fornecer um documento ou site público visível que descreva como ativar as Opções do desenvolvedor. Este documento ou site PRECISA estar disponível para um link documentos do SDK do Android.
- DEVE manter uma notificação visual contínua para o usuário quando o Desenvolvedor As opções estão ativadas, e a segurança do usuário é uma preocupação.
- PODE limitar temporariamente o acesso ao menu Developer Options, visualmente ocultar ou desativar o menu, para evitar distrações em cenários em que o a segurança do usuário é uma preocupação.
7. Compatibilidade de hardware
Se um dispositivo incluir um componente de hardware específico que tenha um API para desenvolvedores terceirizados:
- [C-0-1] A implementação do dispositivo PRECISA implementar isso. conforme descrito na documentação do SDK do Android.
Se uma API no SDK interage com um componente de hardware declarado como opcional e o A implementação de dispositivo não tem esse componente:
- [C-0-2] Definições de classe completas (conforme documentado pelo SDK) para o componente As APIs PRECISAM ser apresentadas.
- [C-0-3] Os comportamentos da API PRECISAM ser implementados como ambiente autônomo em alguns casos de maneira
- [C-0-4] Os métodos da API PRECISAM retornar valores nulos quando permitido pelo SDK na documentação do Google Cloud.
- [C-0-5] Os métodos da API PRECISAM retornar implementações de ambiente autônomo de classes em que valores nulos não são permitidos pela documentação do SDK.
- [C-0-6] Os métodos da API NÃO PODEM gerar exceções não documentadas pelo SDK na documentação do Google Cloud.
- [C-0-7] As implementações de dispositivos PRECISAM informar de forma consistente o hardware preciso
de configuração do Terraform com as APIs
getSystemAvailableFeatures()
e métodoshasSystemFeature(String)
no android.content.pm.PackageManager (link em inglês) para a mesma impressão digital do build.
Um exemplo típico de cenário em que esses requisitos se aplicam é a API: mesmo em aparelhos que não sejam telefones, essas APIs devem ser implementadas o quanto antes ambiente autônomo.
7.1. Tela e gráficos
O Android inclui instalações que ajustam automaticamente os recursos do aplicativo e da interface
layouts adequados para o dispositivo, a fim de garantir que os aplicativos de terceiros
funcionam bem em várias configurações de hardware.
diversas configurações e telas de hardware. Um
Uma tela compatível com Android é uma tela que implementa todos os
comportamentos e APIs descritos em Desenvolvedores Android - Compatibilidade de tela
geral, este
(7.1) e suas subseções, assim como qualquer tipo de dispositivo adicional
comportamentos específicos documentados na seção 2 deste
CDD.
Nas telas compatíveis com Android em que todos os dispositivos de terceiros compatíveis
aplicativos possam ser executados, as implementações de dispositivos PRECISAM implementar essas APIs corretamente
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 Android.
Encerrar novos requisitos
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 opostos. cantos da parte iluminada da tela.
pontos por polegada (dpi)densidade. O número de pixels abrangidos por uma linha extensão horizontal ou vertical de 1”, expresso em pixels por polegada (ppi ou dpi). Em quedpios valores ppi e dpi estão listados, os dpi horizontal e vertical precisam estar entre listados do intervalo 10.240.0.0/16.- proporção. A proporção entre os pixels da dimensão maior e a menor dimensão da tela. Por exemplo, uma tela de 480 x 854 pixels ser 854/480 = 1,779, ou aproximadamente “16:9”.
- pixel de densidade independente (dp, na sigla em inglês).
OUma unidade de pixel virtual normalizado para umatela de 160 dpidensidade de tela de 160. Para alguns d de densidade 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. Configuração da tela
7.1.1.1 Tamanho e forma da tela
O framework de interface do Android é compatível com diversos layouts de tela lógicos diferentes.
e permite que os aplicativos consultem a tela da configuração atual
tamanho do layout usando Configuration.screenLayout
com o SCREENLAYOUT_SIZE_MASK
e Configuration.smallestScreenWidthDp
.
Implementações de dispositivos:
[C-0-1] PRECISA informar o tamanho correto do layout do
Configuration.screenLayout
, conforme definido na documentação do SDK do Android. Especificamente, as implementações de dispositivos PRECISAM informar a lógica correta dimensões da tela em pixels de densidade independente (dp, na sigla em inglês), conforme abaixo:- Dispositivos com o
Configuration.uiMode
definido como qualquer valor diferente UI_MODE_TYPE_WATCH, e informar um tamanho desmall
para oConfiguration.screenLayout
PRECISA ter pelo menos 426 dp x 320 dp. - Dispositivos informando um tamanho de
normal
para o dispositivoConfiguration.screenLayout
, PRECISA ter pelo menos 480 dp x 320 dp. - Dispositivos informando um tamanho de
large
para o dispositivoConfiguration.screenLayout
, PRECISA ter pelo menos 640 dp x 480 dp. - Dispositivos informando um tamanho de
xlarge
para o dispositivoConfiguration.screenLayout
, PRECISA ter pelo menos 960 dp x 720 dp.
- Dispositivos com o
[C-0-2] PRECISA respeitar as inscrições corretamente. afirmaram suporte a tamanhos de tela por meio do <
supports-screens
> no AndroidManifest.xml, conforme descrito na documentação do SDK do Android.PODE ter telas compatíveis com Android com cantos arredondados.
Se as implementações de dispositivos oferecem suporte a telas com a função
Configuração do tamanho UI_MODE_TYPE_NORMAL
e incluem compatíveis com Android
usar telas físicas com
cantos arredondados para renderizar essas telas,
eles:
[C-1-1] PRECISA garantir que pelo menos um dos requisitos a seguir for atendida para cada uma dessas telas:
- O raio dos cantos arredondados será menor ou igual a 38 dp.
- Quando
15e 18 dp por1518 a caixa 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 o cantos retangulares.
Iniciar novos requisitos
Se as implementações de dispositivos só puderem usar a configuração de teclado NO_KEYS
,
e pretende relatar a compatibilidade com o modo de interface UI_MODE_TYPE_NORMAL
da configuração, eles:
- [C-4-1] PRECISA ter um tamanho de layout de pelo menos os cortes da tela, excluindo os cortes da tela 596 dp x 384 dp ou superior.
Encerrar novos requisitos
Se as implementações do dispositivo incluírem telas compatíveis com Android que sejam dobrável, ou inclui uma articulação dobrável entre vários painéis de tela e faz para renderizar apps de terceiros, elas:
- [C-2-1] PRECISA implementar a versão estável mais recente disponível do API de extensões ou a versão estável da API secundária que será usada pela biblioteca do Window Manager Jetpack.
Se as implementações do dispositivo incluírem telas compatíveis com Android que sejam dobrável, ou inclui uma articulação dobrável entre vários painéis de tela e, se a articulação ou dobra cruzar uma janela de aplicativo em tela cheia, elas:
- [C-3-1] PRECISA informar a posição, os limites e o estado da articulação ou dobra ou APIs de arquivo secundário ao aplicativo.
Para detalhes sobre como implementar corretamente o arquivo secundário ou as APIs de extensão, consulte à documentação pública do Gerenciador de janelas do Jetpack.
Iniciar novos requisitos
Se as implementações de dispositivos incluem uma ou mais áreas de exibição compatíveis com o Android que sejam dobráveis ou que incluam uma articulação dobrável entre várias áreas de painel de exibição compatíveis com Android e disponibilize essas áreas para aplicativos, elas:
- [C-4-1] PRECISA implementar a versão correta das extensões do Windows Manager. Nível da API, conforme descrito em Extensões do WindowManager.
Encerrar novos requisitos
7.1.1.2 Proporção da tela
Embora não haja restrições à proporção da tela física para
Telas compatíveis com Android, a proporção da tela lógica
em que apps de terceiros são renderizados, os quais podem ser derivados da altura e
valores de largura informados por meio do view.Display
APIs e configuração
APIs, PRECISAM atender aos seguintes requisitos:
[C-0-1] Implementações de dispositivos com
Configuration.uiMode
definido comoUI_MODE_TYPE_NORMAL
PRECISA ter um valor de proporção menor ou igual a a 1,86 (aproximadamente 16:9), a menos que o app atenda a um dos seguintes condições:- O app declarou que oferece suporte a uma proporção de tela maior
por meio do
android.max_aspect
do valor dos metadados. - O app declara que é redimensionável usando a classe android:resizeableActivity. .
- O app é direcionado ao nível 24 da API ou mais recente e não declara uma
android:maxAspectRatio
restringiria a proporção permitida.
- O app declarou que oferece suporte a uma proporção de tela maior
por meio do
[C-0-3] Implementações de dispositivos com o
Configuration.uiMode
definido como O valor de proporção doUI_MODE_TYPE_WATCH
PRECISA ter o valor 1,0 (1:1) definido.
7.1.1.3 Densidade da tela
O framework da interface do Android define um conjunto de densidades lógicas padrão para ajudar desenvolvedores de aplicativos visam recursos de aplicativos.
Implementações de dispositivos:
- [C-0-1]
Por padrão, implementações de dispositivosPRECISA informarapenasum dos As densidades de framework do Android que estão listadas emDisplayMetrics
pela APIDENSITY_DEVICE_STABLE
e esse valor precisa ser um valor estático para cada tela física.NÃO PODE ser alterado em momento algum; No entanto,No entanto, o dispositivo PODE informar umadensidade arbitráriadiferenteDisplayMetrics.density
de acordo com as alterações de configuração da tela feitas pelo usuário (por exemplo, tamanho de exibição) definido após a primeira inicialização.
- As implementações de dispositivos DEVEM definir a densidade padrão do framework do Android que seja numericamente mais próximo da densidade física da tela, a menos que a densidade lógica coloca 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 a densidade física resulta em um tamanho de tela menor que tamanho de tela compatível com suporte (320 dp de largura), as implementações de dispositivos DEVEM informar a próxima densidade padrão mais baixa de framework do Android.
Iniciar novos requisitos
- DEVE definir a densidade padrão da estrutura Android que é numericamente mais próximo da densidade física da tela, ou um valor que seria mapeado para mesmas medidas equivalentes de campo de visão angular de um dispositivo portátil.
Encerrar novos requisitos
Se as implementações de dispositivos fornecerem
há uma affordance para
alterar o tamanho de exibição do dispositivo , eles:
- [C-1-1]
O tamanho de exibição NÃO PODE ser dimensionadoNÃO PODE dimensionar a tela maior que 1,5 vezDENSITY_DEVICE_STABLE
densidade nativaou produzir uma dimensão mínima efetiva da tela menor que 320 dp (equivalente para o qualificador de recurso sw320dp), o que ocorrer primeiro. - [C-1-2]
O tamanho da tela NÃO PODE ser dimensionadoNÃO PODE dimensionar a tela menor que 0,85 vezes adensidade nativadoDENSITY_DEVICE_STABLE
. - Para garantir uma boa usabilidade e tamanhos de fonte consistentes, é RECOMENDADO que o
seguinte escala de opções de exibição nativa (em conformidade com os limites
especificado acima)
- Pequeno: 0,85x
- Padrão: 1x (escala de display nativa)
- Grande: 1,15x
- Maior: 1,3x
- Maior 1,45x
7.1.2. Métricas de display
Se as implementações do dispositivo incluem telas compatíveis com Android ou de vídeo para as telas compatíveis com o Android, eles:
- [C-1-1] É NECESSÁRIO informar os valores corretos para todas as telas compatíveis com o Android
métricas definidas no
API
android.util.DisplayMetrics
.
Se as implementações de dispositivos não incluírem uma tela incorporada ou saída de vídeo, eles:
- [C-2-1] PRECISA informar os valores corretos de tela compatível com Android
conforme definido na API
android.util.DisplayMetrics
. para oview.Display
padrão emulado.
7.1.3. Orientação da tela
Implementações de dispositivos:
- [C-0-1] PRECISA informar quais orientações de tela são compatíveis
(
android.hardware.screen.portrait
e/ouandroid.hardware.screen.landscape
) e PRECISA informar pelo menos um orientação. Por exemplo, um dispositivo com orientação de paisagem fixa telas, como uma televisão ou um laptop, só DEVE denunciarandroid.hardware.screen.landscape
. - [C-0-2] PRECISA informar o valor correto da configuração atual do dispositivo
orientação sempre que consultado pelo
android.content.res.Configuration.orientation
,android.view.Display.getOrientation()
ou outras APIs.
Se as implementações de dispositivos forem compatíveis com as duas orientações de tela, elas:
- [C-1-1] PRECISA oferecer suporte à orientação dinâmica dos aplicativos nas telas retrato ou paisagem. orientação. Ou seja, o dispositivo precisa respeitar a solicitação do aplicativo para uma tela específica. orientação.
- [C-1-2] NÃO PODE mudar o tamanho ou a densidade da tela informada ao mudar a orientação.
- PODE selecionar a orientação retrato ou paisagem como padrão.
7.1.4. Aceleração gráfica 2D e 3D
OpenGL ES 7.1.4.1
Implementações de dispositivos:
- [C-0-1] PRECISA identificar corretamente as versões compatíveis do OpenGL ES (1.1, 2.0,
3.0, 3.1, 3.2) por meio das APIs gerenciadas (como pela
GLES10.getString()
) e as APIs nativas. - [C-0-2] PRECISA incluir suporte para todas as APIs gerenciadas correspondentes. APIs nativas para cada versão do OpenGL ES que ela identificou ter suporte.
Se as implementações de dispositivos incluírem uma saída de tela ou vídeo, elas:
- [C-1-1] PRECISA oferecer suporte ao OpenGL ES 1.1 e 2.0, conforme incorporado e detalhado. na documentação do SDK do Android.
- [C-SR-1] É FORTEMENTE RECOMENDADO para oferecer suporte ao OpenGL ES 3.1.
- DEVE oferecer suporte a OpenGL ES 3.2.
Os testes dEQP do OpenGL ES são particionados em várias listas de teste, cada uma com
um número de data/versão associado. Eles estão na árvore de origem do Android em
external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt
: Um dispositivo que
oferece suporte ao OpenGL ES em um nível autoinformado indica que pode passar o dEQP
testes em todas as listas de teste deste nível e anteriores.
Se as implementações de dispositivos forem compatíveis com qualquer uma das versões do OpenGL ES, elas:
- [C-2-1] PRECISA gerar relatórios pelas APIs gerenciadas do OpenGL ES e APIs nativas outras extensões do OpenGL ES que tenham implementado e, por outro lado, PRECISAM NOT as strings de extensão de relatório incompatíveis.
- [C-2-2] PRECISA oferecer suporte a
EGL_KHR_image
,EGL_KHR_image_base
,EGL_ANDROID_image_native_buffer
,EGL_ANDROID_get_native_client_buffer
,EGL_KHR_wait_sync
,EGL_KHR_get_all_proc_addresses
,EGL_ANDROID_presentation_time
,EGL_KHR_swap_buffers_with_damage
,EGL_ANDROID_recordable
eEGL_ANDROID_GLES_layers
. - [C-2-3] PRECISA informar a versão máxima dos testes de dEQP do OpenGL ES
com suporte pela flag de recurso
android.software.opengles.deqp.level
. - [C-2-4] PRECISA ser compatível pelo menos com a versão 132383489 (a partir de 1o de março de 2020), como
informados na flag de recurso
android.software.opengles.deqp.level
. - [C-2-5] PRECISA passar em todos os testes dEQP do OpenGL ES nas listas de teste entre as versões
132383489 e a versão especificada no
Sinalização de recurso
android.software.opengles.deqp.level
, para cada com suporte Versão do OpenGL ES. - [C-SR-2] É FORTEMENTE RECOMENDADO para oferecer suporte a
EGL_KHR_partial_update
eOES_EGL_image_external
extensão. DEVE informar com precisão usando o método
getString()
, qualquer textura formato de compactação compatível, que costuma ser específico do fornecedor.DEVE oferecer suporte aos
EGL_IMG_context_priority
eEGL_EXT_protected_content
extensão.
Se as implementações de dispositivos declararem suporte ao OpenGL ES 3.0, 3.1 ou 3.2, elas:
- [C-3-1] PRECISA exportar os símbolos de função correspondentes para essa versão além dos símbolos de função do OpenGL ES 2.0 na biblioteca libGLESv2.so.
- [C-SR-3] É FORTEMENTE RECOMENDADO para oferecer suporte a
OES_EGL_image_external_essl3
.
Se as implementações de dispositivos forem compatíveis com o OpenGL ES 3.2, elas:
- [C-4-1] PRECISA ser compatível com o pacote de extensão OpenGL ES para Android na íntegra.
Se as implementações de dispositivos oferecerem suporte ao Pacote de extensões para Android (link em inglês) do OpenGL ES na própria integralmente, eles:
- [C-5-1] PRECISA identificar o suporte pelo
android.hardware.opengles.aep
. flag de recurso.
Se as implementações do dispositivo exporem suporte para EGL_KHR_mutable_render_buffer
, eles:
- [C-6-1] também PRECISA oferecer suporte a
EGL_ANDROID_front_buffer_auto_refresh
. .
7.1.4.2 Vulkan
O Android inclui suporte ao Vulkan , uma API multiplataforma de baixa sobrecarga para gráficos 3D de alto desempenho.
Se as implementações de dispositivos forem compatíveis com o OpenGL ES 3.1, elas:
- [C-SR-1] É FORTEMENTE RECOMENDADO a inclusão de suporte para Vulkan 1.3
- [C-4-1] NÃO PODE oferecer suporte a uma versão de variante do Vulkan (ou seja, a variante parte da versão principal do Vulkan PRECISA ser zero).
Se as implementações de dispositivos incluírem uma saída de tela ou vídeo, elas:
- [C-SR-2] É FORTEMENTE RECOMENDADO a inclusão de suporte para Vulkan 1.3
Os testes dEQP do Vulkan são particionados em várias listas de teste, cada uma com um
a data/versão associada. Eles estão na árvore de origem do Android em
external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt
: Um dispositivo que
oferece suporte ao Vulkan em um nível autoinformado indica que ele pode passar o dEQP
testes em todas as listas de teste deste nível e anteriores.
Se as implementações de dispositivos incluírem suporte ao Vulkan
1.0 ou superior, eles:
- [C-1-1] PRECISA informar o valor inteiro correto com a
android.hardware.vulkan.level
eandroid.hardware.vulkan.version
flags de recursos. - [C-1-2] PRECISA enumerar pelo menos um
VkPhysicalDevice
para o Vulkan. API nativavkEnumeratePhysicalDevices()
. - [C-1-3] PRECISA implementar totalmente o
Vulkan 1.0. APIs Vulkan 1.1 para cada tipo enumeradoVkPhysicalDevice
. - [C-1-4] PRECISA enumerar as camadas, contidas em bibliotecas nativas chamadas como
libVkLayer*.so
no diretório da biblioteca nativa do pacote do app. usando as APIs nativas do VulkanvkEnumerateInstanceLayerProperties()
evkEnumerateDeviceLayerProperties()
. - [C-1-5] NÃO PODE enumerar as camadas fornecidas por bibliotecas fora do
pacote de aplicativos da Web ou fornecer outras formas de rastrear ou interceptar os
API do Vulkan, a menos que o aplicativo tenha o atributo
android:debuggable
definido comotrue
ou os metadadoscom.android.graphics.injectLayers.enable
Defina comotrue
. - [C-1-6] PRECISA informar todas as strings de extensão com suporte pelo método APIs nativas do Vulkan e, por outro lado, NÃO PODEM informar strings de extensão que não são compatíveis.
- [C-1-7] PRECISA oferecer suporte a VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, e VK_KHR_incremental_present.
- [C-1-8] PRECISA informar a versão máxima dos testes de dEQP do Vulkan
com suporte pela flag de recurso
android.software.vulkan.deqp.level
. - [C-1-9] PRECISA ser compatível com a versão
132317953
(a partir de 1o de março de 2019) como relatados na flag de recursoandroid.software.vulkan.deqp.level
. - [C-1-10] PRECISA passar em todos os testes de dEQP do Vulkan nas listas de teste entre
versão
132317953
e a versão especificada noandroid.software.vulkan.deqp.level
. - [C-1-11] NÃO PODE enumerar o suporte para VK_KHR_video_queue, VK_KHR_video_decode_queue ou VK_KHR_video_encode_queue.
- [C-SR-3] É FORTEMENTE RECOMENDADO para oferecer suporte a
VK_KHR_driver_properties
e extensõesVK_GOOGLE_display_timing
.
- DEVE oferecer suporte a
VkPhysicalDeviceProtectedMemoryFeatures
eVK_EXT_global_priority
.
- [C-1-12] NÃO PODE enumerar o suporte para a extensão VK_KHR_performance_query.
- [C-1-13] PRECISA atender aos requisitos especificados pelo perfil de referência do Android 2021.
- [C-SR-4] É FORTEMENTE RECOMENDADO para atender aos requisitos especificados por o perfil de referência do Android 2022;
Iniciar novos requisitos
[C-SR-5] É FORTEMENTE RECOMENDADO para oferecer suporte a
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
eVK_EXT_global_priority
.[C-SR-6] É FORTEMENTE RECOMENDADO usar o
SkiaVk
com HWUI.
Encerrar novos requisitos
Se as implementações de dispositivos não incluírem suporte para o Vulkan 1.0, elas:
- [C-2-1] NÃO PODE declarar nenhuma das flags de recurso do Vulkan (por exemplo,
android.hardware.vulkan.level
,android.hardware.vulkan.version
). - [C-2-2] NÃO PODE enumerar nenhum
VkPhysicalDevice
para a API nativa do VulkanvkEnumeratePhysicalDevices()
.
Se as implementações de dispositivos incluírem suporte ao Vulkan 1.1 e declararem qualquer um dos Sinalizações de recursos do Vulkan descritas aqui , eles:
- [C-3-1] PRECISA expor o suporte ao semáforo e ao identificador externos do
SYNC_FD
e a extensãoVK_ANDROID_external_memory_android_hardware_buffer
.
Iniciar novos requisitos
- [C-SR-7] É MUITO RECOMENDADO para fazer a
VK_KHR_external_fence_fd
extensão disponível para aplicativos de terceiros e ativar o aplicativo para exportar o payload de limite e importar o payload de cerca do arquivo POSIX descritores conforme descrito aqui.
Encerrar novos requisitos
7.1.4.3 RenderScript
- [C-0-1] As implementações de dispositivos PRECISAM ser compatíveis com o Android RenderScript, conforme detalhado. na documentação do SDK do Android.
7.1.4.4 Aceleração gráfica 2D
O Android inclui um mecanismo para os aplicativos declararem que querem ativar a aceleração de hardware para gráficos 2D nos níveis de aplicativo, atividade Janela ou visualização com o uso de uma tag de manifesto android:hardwareAccelerated (em inglês) ou chamadas de API diretas.
Implementações de dispositivos:
- [C-0-1] PRECISA ativar a aceleração de hardware por padrão e PRECISA desativar a aceleração de hardware, se o desenvolvedor solicitar, definindo android:hardwareAccelerated="false" ou desativar a aceleração de hardware diretamente pelas APIs View do Android.
- [C-0-2] PRECISA exibir um comportamento consistente com a Documentação do SDK do Android sobre aceleração de hardware.
O Android inclui um objeto TextureView que permite aos desenvolvedores integrar diretamente texturas do OpenGL ES com aceleração de hardware como destinos de renderização em uma hierarquia de interface.
Implementações de dispositivos:
- [C-0-3] PRECISA oferecer suporte à API TextureView e exibir comportamento consistente com a implementação upstream do Android.
Telas de ampla gama 7.1.4.5
Se as implementações de dispositivos alegarem suporte a telas de ampla gama por meio de
Configuration.isScreenWideColorGamut()
, eles:
- [C-1-1] PRECISA ter uma tela calibrada por cores.
- [C-1-2] PRECISA ter uma tela cuja gama cubra a gama de cores sRGB inteiramente no espaço xyY da CIE 1931.
- [C-1-3] PRECISA ter uma tela com uma área de gama de pelo menos 90% do DCI-P3 no espaço xyY CIE 1931.
- [C-1-4] PRECISA oferecer suporte ao OpenGL ES 3.1 ou 3.2 e informá-lo corretamente.
- [C-1-5] PRECISA anunciar o suporte para
EGL_KHR_no_config_context
.EGL_EXT_pixel_format_float
,EGL_KHR_gl_colorspace
EGL_EXT_gl_colorspace_scrgb
,EGL_EXT_gl_colorspace_scrgb_linear
.EGL_EXT_gl_colorspace_display_p3
,EGL_EXT_gl_colorspace_display_p3_linear
, eEGL_EXT_gl_colorspace_display_p3_passthrough
extensões. - [C-SR-1] É FORTEMENTE RECOMENDADO para oferecer suporte a
GL_EXT_sRGB
.
Por outro lado, se as implementações de dispositivos não forem compatíveis com telas de ampla gama, elas:
- [C-2-1] DEVE cobrir 100% ou mais de sRGB no espaço xyY da CIE 1931, embora a gama de cores da tela é indefinida.
7.1.5. Modo de compatibilidade de aplicativo legado
O Android especifica um "modo de compatibilidade" em que o framework opera em uma "normal" Modo de tamanho de tela equivalente (320 dp de largura) para usar o modelo aplicativos não desenvolvidos para versões antigas do Android independência do tamanho da tela.
7.1.6. Tecnologia da tela
A plataforma Android inclui APIs que permitem que aplicativos renderizem gráficos para uma tela compatível com Android. Os dispositivos PRECISAM ser compatíveis com todas as opções a seguir. APIs definidas pelo SDK do Android, a menos que especificamente permitido neste documento.
Todas as telas compatíveis com a implementação do dispositivo:
- [C-0-1] PRECISA renderizar gráficos coloridos de 16 bits.
- DEVE oferecer suporte a telas com gráficos coloridos de 24 bits.
- [C-0-2] PRECISA ser capaz de renderizar animações.
- [C-0-3] PRECISA ter uma proporção de pixels (PAR) entre 0,9 e 1,15. Ou seja, a proporção de pixels PRECISA estar próxima ao quadrado. (1,0) com tolerância de 10% a 15%.
7.1.7. Telas secundárias
O Android inclui suporte a telas secundárias compatíveis com o Android para ativar recursos de compartilhamento de mídia e APIs de desenvolvedor para acessar telas externas.
Se as implementações de dispositivos forem compatíveis com uma tela externa, seja por um cabo sem fio ou uma conexão de tela adicional incorporada, eles:
- [C-1-1] PRECISA implementar o
DisplayManager
. serviço do sistema e API, conforme descrito na documentação do SDK do Android.
7.2. Dispositivos de entrada
Implementações de dispositivos:
- [C-0-1] PRECISA incluir um mecanismo de entrada, como tela touch ou navegação sem toque para navegar entre os elementos da interface.
7.2.1. Teclado
Caso as implementações de dispositivos incluam suporte a aplicativos os aplicativos Editor de método de entrada (IME), eles:
- [C-1-1] PRECISA declarar o
android.software.input_methods
flag de recurso. - [C-1-2] PRECISA implementar totalmente
Input Management Framework
- [C-1-3] PRECISA ter um teclado de software pré-instalado.
Implementações de dispositivos:
- [C-0-1] NÃO PODE incluir um teclado físico que não corresponda a um dos formatos especificados em android.content.res.Configuration.tela (em inglês) (QWERTY ou 12 teclas).
- DEVEM incluir implementações adicionais de teclado de software.
- PODE incluir um teclado físico.
7.2.2. Navegação sem toque
O Android inclui suporte para botão direcional, trackball e wheel como mecanismos para navegação sem toque.
Implementações de dispositivos:
- [C-0-1] PRECISA informar o valor correto para android.content.res.Configuration.navigation.
Se as implementações de dispositivos não tiverem navegações sem toque, elas:
- [C-1-1] PRECISA fornecer um mecanismo de interface do usuário alternativo razoável para o seleção e edição de texto, compatível com os Mecanismos de Gerenciamento de Entradas. O a implementação de código aberto upstream do Android inclui um mecanismo de seleção adequado para uso com dispositivos que não tenham entradas de navegação sem toque.
7.2.3. Teclas de navegação
As guias Home, Recentes, e Voltar funções normalmente fornecidas por meio de uma interação com um botão físico dedicado ou uma parte distinta da tela sensível ao toque, são essenciais para o funcionamento paradigma de navegação e, portanto, implementações de dispositivos:
- [C-0-1] PRECISA fornecer recursos de usuário para iniciar aplicativos instalados.
que têm uma atividade com o
<intent-filter>
definido comACTION=MAIN
eCATEGORY=LAUNCHER
ouCATEGORY=LEANBACK_LAUNCHER
para dispositivo de televisão e implementações. A função Home DEVE ser o mecanismo para essa affordance do usuário. - DEVE fornecer botões para as funções Recentes e Voltar.
Se as funções Home, Recents ou Back forem fornecidas, elas:
- [C-1-1] PRECISA ser acessível com uma única ação (por exemplo, tocar, clicar duas vezes ou gesto) quando qualquer um deles estiver acessível.
- [C-1-2] PRECISA fornecer uma indicação clara de qual ação seria acionada cada função. Ter um ícone visível impresso no botão, mostrando um software ícone na parte da barra de navegação da tela, ou orientar o usuário através de um o fluxo de demonstração passo a passo guiado durante a experiência de configuração pronta para uso são exemplos de tal indicação.
Implementações de dispositivos:
[C-SR-1] é FORTEMENTE RECOMENDADO para não fornecer o mecanismo de entrada para o Função do menu já que foi descontinuada e substituída pela barra de ações a partir do Android 4.0.
[C-SR-2] É FORTEMENTE RECOMENDADO que forneça todas as funções de navegação cancelável. "Cancelável" é definida como a capacidade do usuário de impedir a função de navegação seja executada (por exemplo, indo para casa, voltando etc.) se o o deslizamento não é solto além de um determinado limite.
Se as implementações de dispositivos fornecerem a função de menu, elas:
- [C-2-1] PRECISA exibir o botão flutuante de ação sempre que a ação O pop-up do menu flutuante não está vazio e a barra de ações está visível.
- [C-2-2] NÃO É POSSÍVEL modificar a posição do pop-up flutuante de ação exibido selecionando o botão flutuante na barra de ações, mas PODE SER renderizado o pop-up flutuante de ação em uma posição modificada na tela quando estiver exibido selecionando a função Menu.
Se as implementações de dispositivos não fornecerem a função Menu, para inverso compatibilidade, elas:
- [C-3-1] PRECISA disponibilizar a função Menu aos aplicativos quando
targetSdkVersion
for menor que 10, seja por um botão físico ou uma chave de software, ou gestos. Essa função de menu deve ser acessível, a menos que esteja oculta junto com outras funções de navegação.
Se as implementações de dispositivos fornecerem a função de assistência, eles:
- [C-4-1] PRECISA tornar a função Assistente acessível com uma única ação (por exemplo, tocar, clicar duas vezes ou fazer um gesto) quando outras teclas de navegação estiverem acessíveis.
- [C-SR-3] É MUITO RECOMENDADO usar a função HOME, manter pressionada uma interação designada.
Se as implementações de dispositivo usarem uma parte distinta da tela para exibir o teclas de navegação, eles:
- [C-5-1] As teclas de navegação PRECISAM usar uma parte distinta da tela, não disponíveis para os aplicativos e NÃO PODEM obscurecer ou interferir de outra forma na a parte da tela disponível para os aplicativos.
- [C-5-2] PRECISA disponibilizar uma parte da tela para aplicativos que atenda aos requisitos definidos na seção 7.1.1.
- [C-5-3] PRECISA respeitar as flags definidas pelo app usando o
View.setSystemUiVisibility()
. método da API, de modo que essa parte distinta da tela (ou seja, a barra de navegação) está adequadamente escondida, conforme documentado em pelo SDK.
Se a função de navegação for fornecida como uma ação na tela baseada em gestos:
- [C-6-1]
WindowInsets#getMandatorySystemGestureInsets()
DEVE ser usado apenas para informar a área de reconhecimento de gestos para casa. - [C-6-2] Gestos que começam dentro de um retângulo de exclusão, conforme fornecido pelo
aplicativo em primeiro plano com o
View#setSystemGestureExclusionRects()
, mas foraWindowInsets#getMandatorySystemGestureInsets()
, NÃO PODE ser interceptado para a função de navegação, desde que a exclusão retângulo é permitido dentro do limite máximo de exclusão conforme especificado no documentação sobreView#setSystemGestureExclusionRects()
. - [C-6-3] PRECISA enviar ao app em primeiro plano uma
MotionEvent.ACTION_CANCEL
quando os toques começam a ser interceptados para um gesto do sistema, se o aplicativo em primeiro plano já tiver recebido umaMotionEvent.ACTION_DOWN
evento. - [C-6-4] PRECISA fornecer affordance para o usuário alternar para uma tela navegação baseada em botões (por exemplo, em Configurações).
- DEVE fornecer a função "Início" deslizando para cima a partir da borda inferior da orientação atual da tela.
- DEVE fornecer a função "Recentes" deslizando para cima e pressionado antes da liberação, desde na mesma área do gesto de casa.
- Gestos que começam dentro
WindowInsets#getMandatorySystemGestureInsets()
NÃO DEVE ser afetado por retângulos de exclusão fornecidos pelo primeiro plano aplicativo porView#setSystemGestureExclusionRects()
Se uma função de navegação é fornecida a partir de qualquer lugar das bordas esquerda e direita da orientação atual da tela:
- [C-7-1] A função de navegação PRECISA ser Voltar e ser fornecida como um deslize das extremidades esquerda e direita da orientação atual do tela.
- [C-7-2] Se painéis de sistema deslizantes personalizados forem fornecidos à esquerda ou cantos direito, eles DEVEM ser colocados dentro do 1/3 de cima da tela com uma indicação visual clara e persistente de que arrastar invocaria e não "Voltar". Um painel de sistema PODE ser configurado por um usuário de modo que ele fique abaixo do 1/3 da parte superior da tela borda(s), mas o painel do sistema NÃO PODE usar mais do que 1/3 da(s) borda(ões).
- [C-7-3] Quando o app em primeiro plano tem View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT ou os sinalizadores WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE definidos, O deslizamento das bordas PRECISA se comportar como implementado no AOSP, que é documentados no SDK.
- [C-7-4] Quando o app em primeiro plano tem View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT ou os sinalizadores WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE definidos, Os painéis de sistema deslizantes personalizados PRECISAM ficar ocultos até que o usuário insira ou Ativa o brilho das barras do sistema (também chamadas de barra de navegação e status) conforme implementadas no AOSP.
Se a função de navegação de retorno for fornecida e o usuário cancelar a ação de voltar um gesto e:
- [C-8-1]
OnBackInvokedCallback.onBackCancelled()
PRECISA ser chamado. - [C-8-2] O
OnBackInvokedCallback.onBackInvoked()
NÃO PODE ser chamado. - [C-8-3] O evento KEYCODE_BACK NÃO PODE ser enviado.
Se a função de navegação de retorno for fornecida, mas o aplicativo em primeiro plano oferecer
NÃO ter um OnBackInvokedCallback
registrado, então:
- O sistema DEVE fornecer uma animação para o aplicativo em primeiro plano que sugere que o usuário está voltando, conforme fornecido no AOSP.
Se as implementações de dispositivos oferecerem suporte à API setNavBarMode
do sistema para
permita que qualquer app do sistema com a permissão android.permission.STATUS_BAR
defina o
modo da barra de navegação, eles:
- [C-9-1] PRECISA oferecer suporte a ícones adequados para crianças ou baseados em botões a navegação fornecida pelo código do AOSP.
7.2.4. Entrada por tela touch
O Android inclui suporte para uma variedade de sistemas de entrada de ponteiro, como touchscreens, touchpads e dispositivos de entrada por toque falsos. Implementações de dispositivos touchscreen sejam associados a uma tela de forma que o usuário tenha a impressão de diretamente manipular itens na tela. Como o usuário está tocando diretamente na tela, o sistema não requer affordances adicionais para indicar os objetos sendo manipuladas.
Implementações de dispositivos:
- DEVE ter algum tipo de sistema de entrada de ponteiro (semelhante ao mouse ou ao toque).
- DEVE dar suporte a ponteiros totalmente rastreados de forma independente.
Se as implementações do dispositivo incluem uma tela sensível ao toque (de toque único ou melhor) em um tela principal compatível com Android, eles:
- [C-1-1] PRECISA informar
TOUCHSCREEN_FINGER
paraConfiguration.touchscreen
API. - [C-1-2] PRECISA informar
android.hardware.touchscreen
eandroid.hardware.faketouch
.
Se as implementações de dispositivos incluem uma tela tátil que pode rastrear mais de um único toque em uma tela principal compatível com Android, eles:
- [C-2-1] PRECISA informar as flags de recursos apropriadas
android.hardware.touchscreen.multitouch
,android.hardware.touchscreen.multitouch.distinct
eandroid.hardware.touchscreen.multitouch.jazzhand
correspondente ao tipo de touchscreen específica do dispositivo.
Se as implementações de dispositivos dependerem de um dispositivo de entrada externa, como mouse ou trackball (ou seja, sem tocar diretamente na tela) para entrada em um tela compatível com Android e atender aos requisitos de toque simulado em seção 7.2.5, eles:
- [C-3-1] NÃO É POSSÍVEL reportar uma flag de recurso que comece com
android.hardware.touchscreen
: - [C-3-2] PRECISA informar apenas
android.hardware.faketouch
. - [C-3-3] PRECISA informar
TOUCHSCREEN_NOTOUCH
para oConfiguration.touchscreen
API.
7.2.5. Entrada de toque falsa
A interface de toque simulada fornece um sistema de entrada do usuário que se aproxima de um subconjunto recursos de tela touchscreen. Por exemplo, um mouse ou controle remoto que direcione um cursor na tela aproxima o toque, mas exige que o usuário primeiro aponte ou focar e clicar. vários dispositivos de entrada, como mouse, trackpad e giroscópio; Air mouse, ponteiro com giroscópio, joystick e trackpad multitoque podem oferecer suporte a para interações de toque. O Android inclui a constante de recurso android.hardware.faketouch, que corresponde a um dispositivo sem toque de alta fidelidade (baseado em ponteiro), como um mouse ou trackpad que possa emular entradas baseadas em toque (incluindo suporte básico a gestos) e indica que o dispositivo suporta um subconjunto emulado de funcionalidade de tela sensível ao toque.
Se as implementações de dispositivos não incluírem uma tela tátil, mas incluir outra sistema de entrada por ponteiro que querem disponibilizar, ele:
- DEVE declarar suporte à flag de recurso
android.hardware.faketouch
.
Se as implementações de dispositivos declararem suporte a android.hardware.faketouch
:
eles:
- [C-1-1] PRECISA informar as posições absolutas de X e Y da tela da localização do cursor e exibir um ponteiro visual na tela.
- [C-1-2] PRECISA informar o evento de toque com o código de ação que especifica a mudança de estado que ocorre no ponteiro descer ou subir na tela.
- [C-1-3] PRECISA oferecer suporte ao ponteiro para cima e para baixo em um objeto na tela, o que permite que os usuários emulem o toque em um objeto na tela.
- [C-1-4] PRECISA oferecer suporte ao ponteiro para baixo, para cima, para baixo e para cima. no mesmo lugar em um objeto na tela dentro de um limite de tempo, que Permite que os usuários emulem o toque duplo em um objeto na tela.
- [C-1-5] PRECISA oferecer suporte ao ponteiro para baixo em um ponto arbitrário na tela. o ponteiro se move para qualquer outro ponto arbitrário na tela, seguido por um ponteiro para cima, o que permite aos usuários emular uma ação de arrastar por toque.
- [C-1-6] PRECISA oferecer suporte ao ponteiro para baixo e permitir que os usuários movam rapidamente o objeto para uma posição diferente na tela e, em seguida, aponta para cima na tela, que permite aos usuários arremessar um objeto na tela.
Se as implementações de dispositivo declararem suporte para
android.hardware.faketouch.multitouch.distinct
, eles:
- [C-2-1] PRECISA declarar compatibilidade com
android.hardware.faketouch
. - [C-2-2] PRECISA oferecer suporte ao rastreamento distinto de dois ou mais ponteiros independentes de entrada.
Se as implementações de dispositivo declararem suporte para
android.hardware.faketouch.multitouch.jazzhand
, eles:
- [C-3-1] PRECISA declarar compatibilidade com
android.hardware.faketouch
. - [C-3-2] PRECISA oferecer suporte ao rastreamento distinto de cinco dedos (rastreamento de uma mão) ou mais entradas de ponteiro de maneira totalmente independente.
7.2.6. Suporte a controles de jogos
7.2.6.1. Mapeamentos de botões
Implementações de dispositivos:
- [C-1-1] PRECISA ser capaz de mapear eventos HID para as constantes
InputEvent
correspondentes, conforme listado nas tabelas abaixo. A implementação upstream do Android atende a esse requisito.
Se as implementações de dispositivo incorporarem um controlador ou enviarem com um controlador separado na caixa, que forneça meios de inserir todos os eventos listados nas tabelas abaixo, elas:
- [C-2-1] PRECISA declarar a flag de recurso
android.hardware.gamepad
.
Botão | Uso de HID2 | Botão do Android |
---|---|---|
R1 | 0x09 0x0001 | KEYCODE_BOT_A (96) |
B1 | 0x09 0x0002 | KEYCODE_BOT_B (97) |
X1 | 0x09 0x0004 | KEYCODE_BOT_X (99) |
A1 | 0x09 0x0005 | KEYCODE_BOT_Y (100) |
Botão direcional para cima1 Botão direcional para baixo1 |
0x01 0x00393 | Eixo_HAT_Y4 |
Botão direcional esquerdo1 Botão direcional para a direita1 |
0x01 0x00393 | Eixo_HAT_X4 |
Botão do ombro esquerdo1 | 0x09 0x0007 | KEYCODE_Button_L1 (102) |
Botão do ombro direito1 | 0x09 0x0008 | KEYCODE_Botão_R1 (103) |
Clique com o botão esquerdo do mouse1 | 0x09 0x000E | KEYCODE_BOT_THUMBL (106) |
Clique com o botão direito do mouse1 | 0x09 0x000F | KEYCODE_Button_THUMBR (107) |
Voltar1 | 0x0c 0x0224 | KEYCODE_BACK (4) |
1 KeyEvent
2 Os usos de HID acima precisam ser declarados em um jogo pad CA (0x01 0x0005).
3 Esse uso deve ter um mínimo lógico de 0, um Máximo lógico de 7, Mínimo físico de 0, Máximo físico de 315, Unidades em graus e um Tamanho de relatório de 4. O valor lógico é definido como o rotação no sentido horário na direção oposta do eixo vertical por exemplo, um valor lógico de 0 representa nenhuma rotação e o botão para cima está sendo pressionado, enquanto um valor lógico de 1 representa uma rotação de 45 graus e as teclas para cima e para a esquerda sendo pressionado.
Controles analógicos1 | Uso de HID | Botão do Android |
---|---|---|
Gatilho esquerdo | 0x02 0x00C5 | AXIS_LTRIGGER |
Gatilho correto | 0x02 0x00C4 | EIXO_RTRIGGER |
Joystick esquerdo | 0x01 0x0030 0x01 0x0031 |
Eixo X Eixo_Y |
Joystick direito | 0x01 0x0032 0x01 0x0035 |
Eixo Z AXIS_RZ |
7.2.7. Controle remoto
Consulte a Seção 2.3.1 para ver os requisitos específicos dos dispositivos.
7,3 Sensores
Se as implementações do dispositivo incluem um tipo específico de sensor que tem um a API correspondente para desenvolvedores terceirizados, a implementação de dispositivos PRECISA implementar essa API conforme descrito na documentação do SDK do Android e a documentação do Android Open Source sobre sensores.
Implementações de dispositivos:
- [C-0-1] PRECISA informar com precisão a presença ou ausência de sensores, de acordo com o
android.content.pm.PackageManager
. - [C-0-2] PRECISA retornar uma lista precisa de sensores compatíveis pelo
SensorManager.getSensorList()
e métodos semelhantes. - [C-0-3] PRECISA se comportar de maneira razoável com todas as outras APIs de sensores (por exemplo,
retornando
true
oufalse
, conforme apropriado, quando os aplicativos tentam registrar ouvintes, sem chamar listeners de sensores quando os sensores correspondentes não estiverem presente etc.).
Se as implementações do dispositivo incluem um tipo específico de sensor que tem um API correspondente para desenvolvedores terceirizados, eles:
- [C-1-1] PRECISA informar todas as medições do sensor. usando os valores relevantes do Sistema Internacional de Unidades (métrica) para cada tipo de sensor definido na documentação do SDK do Android.
- [C-1-2] PRECISA informar dados do sensor com latência máxima de 100 milissegundos + 2 * sample_time para o caso de um fluxo do sensor com um latência máxima solicitada de 0 ms quando o processador do aplicativo está ativo. Esse atraso não inclui atrasos de filtragem.
- [C-1-3] PRECISA informar a primeira amostra do sensor em até 400 milissegundos + 2 * sample_time do sensor que está sendo ativado. É aceitável que esta amostra têm uma precisão de 0.
- [C-1-4] Para qualquer API indicada pela documentação do SDK do Android como um sensor contínuo as implementações de dispositivos PRECISAM fornecer continuamente amostras periódicas de dados que DEVEM ter uma instabilidade abaixo de 3%, em que a instabilidade é definida como o desvio padrão da diferença do valores de carimbo de data/hora informados entre eventos consecutivos.
- [C-1-5] PRECISA garantir que o fluxo de eventos do sensor NÃO PODE impedir que a CPU do dispositivo entre em um estado de suspensão ou seja ativada. de um estado de suspensão.
- [C-1-6] PRECISA informar o horário do evento. em nanossegundos, conforme definido na documentação do SDK do Android, representando hora em que o evento aconteceu e sincronizado com o SystemClock.elapsedRealtimeNano().
- [C-SR-1] É FORTEMENTE RECOMENDADO que tenham erros de sincronização de carimbo de data/hora abaixo de 100 milissegundos, e DEVE ter erro de sincronização de carimbo de data/hora inferior a 1 milissegundos.
- Quando vários sensores estiverem ativados, o consumo de energia NÃO DEVE exceder a soma do consumo de energia relatado de cada sensor individual.
A lista acima não é abrangente. o comportamento documentado do SDK do Android e as documentações de código aberto do Android sensores serão considerados autoritativo.
Se as implementações do dispositivo incluem um tipo específico de sensor que tem um API correspondente para desenvolvedores terceirizados, eles:
- [C-1-6] PRECISA definir uma resolução diferente de zero para todos os sensores e informar o valor.
pelo
Sensor.getResolution()
Método de API.
Alguns tipos de sensores são compostos, o que significa que podem ser derivados de dados fornecidos por um ou mais sensores. (Os exemplos incluem o sensor de orientação e o ou sensor de aceleração linear.
Implementações de dispositivos:
- DEVEM implementar esses tipos de sensor, quando eles incluir os pré-requisitos de sensores físicos, conforme descrito em tipos de sensor.
Se as implementações de dispositivos incluírem um sensor composto, elas:
- [C-2-1] PRECISA implementar o sensor conforme descrito no Código aberto do Android documentação sobre sensores compostos.
Se as implementações do dispositivo incluem um tipo específico de sensor que tem um API correspondente para desenvolvedores de terceiros, e o sensor informa apenas um e as implementações de dispositivos:
- [C-3-1] PRECISA definir a resolução como 1 para o sensor e informar o valor
pelo
Sensor.getResolution()
Método de API.
Se as implementações do dispositivo incluem um tipo específico de sensor que oferece suporte SensorAdditionalInfo#TYPE_VEC3_CALIBRATION (link em inglês) e o sensor for exposto a desenvolvedores terceirizados, eles:
- [C-4-1] NÃO PODE incluir nenhuma calibragem fixa e determinada pela fábrica de parâmetros nos dados fornecidos.
Se as implementações de dispositivos incluírem uma combinação de acelerômetro de três eixos, um Um sensor de giroscópio de três eixos ou um sensor magnetômetro são:
- [C-SR-2] É MUITO RECOMENDADO para garantir que o acelerômetro, o giroscópio e têm uma posição relativa fixa, de modo que, se o dispositivo transformáveis (por exemplo, dobráveis), os eixos do sensor permanecem alinhados e consistentes com o sistema de coordenadas do sensor em todos os dispositivos possíveis estados de transformação.
7.3.1. Acelerômetro
Implementações de dispositivos:
- [C-SR-1] É MUITO RECOMENDADO incluir um acelerômetro de três eixos.
Se as implementações de dispositivos incluírem um acelerômetro, elas:
- [C-1-1] PRECISA relatar eventos com uma frequência de pelo menos 50 Hz.
- [C-1-3] PRECISA estar em conformidade com Sistema de coordenadas do sensor do Android conforme detalhado nas APIs do Android.
- [C-1-4] PRECISA ser capaz de medir a queda livre até quatro vezes a gravity(4g) ou mais em qualquer eixo.
- [C-1-5] PRECISA ter uma resolução de pelo menos 12 bits.
- [C-1-6] PRECISA ter um desvio padrão não superior a 0,05 m/s^, em que o desvio padrão deve ser calculado por eixo em amostras coletadas durante um período de pelo menos 3 segundos com a taxa de amostragem mais rápida.
- DEVE relatar eventos de até pelo menos 200 Hz.
- DEVE ter uma resolução de pelo menos 16 bits.
- DEVE ser calibrado durante o uso se as características mudarem em no ciclo de vida e compensados, e preservam os parâmetros de compensação entre as reinicializações do dispositivo.
- DEVE ser compensado por temperatura.
Se as implementações de dispositivos incluírem um acelerômetro de três eixos, elas:
- [C-2-1] PRECISA implementar e informar o sensor
TYPE_ACCELEROMETER
. - [C-SR-4] É FORTEMENTE RECOMENDADO para implementar a
TYPE_SIGNIFICANT_MOTION
sensor composto. - [C-SR-5] É FORTEMENTE RECOMENDADO para implementar e informar
Sensor
TYPE_ACCELEROMETER_UNCALIBRATED
. Os dispositivos Android são É RECOMENDADO atender a esse requisito para que possam fazer upgrade para a em uma próxima versão, em que pode se tornar OBRIGATÓRIO. - Implemente as APIs
TYPE_SIGNIFICANT_MOTION
,TYPE_TILT_DETECTOR
TYPE_STEP_DETECTOR
deTYPE_STEP_COUNTER
sensores compostos, conforme descrito no documento do SDK do Android.
Se as implementações de dispositivos incluírem um acelerômetro com menos de três eixos, elas:
- [C-3-1] PRECISA implementar e informar o sensor
TYPE_ACCELEROMETER_LIMITED_AXES
. - [C-SR-6] São STRONGLY_RECOMMENDED para implementar e informar
Sensor
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
.
Se as implementações de dispositivos incluírem um acelerômetro de três eixos e qualquer um dos
TYPE_SIGNIFICANT_MOTION
, TYPE_TILT_DETECTOR
e TYPE_STEP_DETECTOR
.
TYPE_STEP_COUNTER
sensores compostos foram implementados:
- [C-4-1] A soma o consumo de energia PRECISA ser sempre menor que 4 mW.
- Cada um DEVE ter menos de 2 mW e 0,5 mW quando o dispositivo estiver em um modo dinâmico ou uma condição estática.
Se as implementações de dispositivos incluírem um acelerômetro de três eixos e um sensor de giroscópio de três eixos, eles:
- [C-5-1] PRECISA implementar
TYPE_GRAVITY
eTYPE_LINEAR_ACCELERATION
. com sensores compostos. - [C-SR-7] É FORTEMENTE RECOMENDADO para implementar a
Sensor composto
TYPE_GAME_ROTATION_VECTOR
.
Se as implementações de dispositivos incluírem um acelerômetro de três eixos e um sensor de giroscópio de três eixos, e um sensor de magnetômetro, eles:
- [C-6-1] PRECISA implementar um sensor composto
TYPE_ROTATION_VECTOR
.
7.3.2. Magnetômetro
Implementações de dispositivos:
- [C-SR-1] É RECOMENDADO incluir um magnetômetro de três eixos (bússola).
Se as implementações de dispositivos incluírem um magnetômetro de três eixos, elas:
- [C-1-1] PRECISA implementar o sensor
TYPE_MAGNETIC_FIELD
. - [C-1-2] PRECISA relatar eventos com uma frequência de pelo menos 10 Hz e DEVEM relatar eventos de até 50 Hz.
- [C-1-3] PRECISA estar em conformidade com o Sistema de coordenadas do sensor do Android conforme detalhado nos APIs do Android.
- [C-1-4] PRECISA ser capaz de medir entre -900 μT e +900 μT em cada do módulo antes da saturação.
- [C-1-5] PRECISA ter um valor de compensação de hardware inferior a 700 μT e DEVE ter abaixo de 200 μT, afastando o magnetômetro do campos magnéticos dinâmicos (induzidos por corrente) e estáticos (induzidos por ímãs).
- [C-1-6] PRECISA ter uma resolução igual ou mais densa que 0,6 μT.
- [C-1-7] PRECISA oferecer suporte à calibragem on-line e à compensação do hardware e preservar os parâmetros de compensação entre as reinicializações do dispositivo.
- [C-1-8] PRECISA ter a compensação de ferro suave aplicada. A calibragem pode ser feitas durante o uso ou durante a produção do dispositivo.
- [C-1-9] PRECISA ter um desvio padrão, calculado por eixo com base amostras coletadas durante um período de pelo menos 3 segundos com a amostragem mais rápida não superior a 1, 5 μT; DEVE ter um desvio padrão não superior a 0,5 μT.
- [C-1-10] PRECISA implementar o
TYPE_MAGNETIC_FIELD_UNCALIBRATED
sensor
Se as implementações do dispositivo incluírem um magnetômetro de três eixos, um acelerômetro e um giroscópio de três eixos, eles:
- [C-2-1] PRECISA implementar um sensor composto
TYPE_ROTATION_VECTOR
.
Se as implementações de dispositivos incluírem um magnetômetro de três eixos e um acelerômetro, elas:
- PODE implementar o sensor
TYPE_GEOMAGNETIC_ROTATION_VECTOR
.
Se as implementações do dispositivo incluem um magnetômetro de três eixos, um acelerômetro e
TYPE_GEOMAGNETIC_ROTATION_VECTOR
, eles:
- [C-3-1] PRECISA consumir menos de 10 mW.
- DEVE consumir menos de 3 mW quando o sensor estiver registrado no modo de lote a 10 Hz.
7.3.3. GPS
Implementações de dispositivos:
- [C-SR-1] É FORTEMENTE RECOMENDADO a inclusão de um receptor GPS/GNSS.
Se as implementações do dispositivo incluírem um receptor GPS/GNSS e informarem a capacidade
aos aplicativos pela flag de recurso android.hardware.location.gps
, eles:
- [C-1-1] PRECISA oferecer suporte a saídas de localização a uma taxa de pelo menos 1 Hz quando
solicitada via
LocationManager#requestLocationUpdate
. - [C-1-2] PRECISA determinar o local em condições de céu aberto.
(Sinais fortes, multicaminho insignificante, HDOP < 2) dentro de 10 segundos (rápido)
tempo até a primeira correção), quando conectado a uma velocidade de dados de 0,5 Mbps ou superior
conexão com a Internet. Esse requisito normalmente é atendido pelo uso de alguns
forma de técnica de GPS/GNSS assistido ou previsto
para minimizar o tempo de bloqueio por GPS/GNSS (os dados de assistência incluem o Tempo de referência,
local de referência e efêmeras/relógio do satélite).
- [C-1-6] Depois de fazer esse cálculo de local, o dispositivo implementações PRECISAM determinar sua localização, em céu aberto, dentro de Cinco segundos, até uma hora após as solicitações de localização serem reiniciadas do cálculo de localização inicial, mesmo quando a solicitação subsequente é feitas sem uma conexão de dados e/ou após uma reinicialização.
Em condições de céu aberto após determinar o local, enquanto estiver parado ou movimento com menos de 1 metro por segundo ao quadrado de aceleração:
- [C-1-3] PRECISA determinar o local a até 20 metros e a velocidade em 0,5 metro por segundo, pelo menos 95% do tempo.
- [C-1-4] PRECISA acompanhar e relatar simultaneamente por meio de
GnssStatus.Callback
a pelo menos oito satélites de uma constelação. - DEVE ser capaz de rastrear simultaneamente 24 satélites, de múltiplas constelações (ex.: GPS + pelo menos uma entre Glonass, Beidou, Galileu).
[C-SR-2] É FORTEMENTE RECOMENDADO para continuar a fornecer GPS/GNSS normal saídas de localização por meio da API GNSS Location Provider durante uma chamada de emergência a chamada.
[C-SR-3] É FORTEMENTE RECOMENDADO para informar medições GNSS de todos constelações rastreadas (conforme relatado em mensagens GnssStatus), com exceção da SBAS.
[C-SR-4] É FORTEMENTE RECOMENDADO a informar o AGC e a frequência do GNSS de medida.
[C-SR-5] É FORTEMENTE RECOMENDADO para informar todas as estimativas de precisão (incluindo rolamento, velocidade e vertical) como parte de cada localização GPS/GNSS.
[C-SR-6] É FORTEMENTE RECOMENDADO para informar medições GNSS assim que eles serão encontrados, mesmo que uma localização calculada com base em GPS/GNSS ainda não tenha sido relatadas.
[C-SR-7] É FORTEMENTE RECOMENDADO para informar pseudodistâncias do GNSS e taxas de pseudodistâncias, que, em condições de céu aberto, após determinar a localização, enquanto está parado ou em movimento com menos de 0,2 metro por segundo ao quadrado de são suficientes para calcular uma posição dentro de 20 metros, e a velocidade em 0,2 metro por segundo, pelo menos 95% do tempo.
7.3.4. Giroscópio
Implementações de dispositivos:
- [C-SR-1] É MUITO RECOMENDADO incluir um sensor de giroscópio.
Se as implementações de dispositivos incluírem um giroscópio, elas:
- [C-1-1] PRECISA relatar eventos com uma frequência de pelo menos 50 Hz.
- [C-1-4] PRECISA ter uma resolução de 12 bits ou mais.
- [C-1-5] PRECISA ser compensado pela temperatura.
- [C-1-6] PRECISA ser calibrado e compensado durante o uso e preservar o parâmetros de compensação entre as reinicializações do dispositivo.
- [C-1-7] PRECISA ter uma variação não maior que 1e-7 rad^2 / s^2 por Hz. (variância por Hz ou rad^2 / s). A variância pode variar com o taxa de amostragem, mas PRECISA ser limitado por esse valor. Em outras palavras, se você medir a variância do giroscópio a uma taxa de amostragem de 1 Hz, ele NÃO DEVE ser maior de 1e a 7 rad^2/s^2.
- [C-SR-2] O erro de calibração é FORTEMENTE RECOMENDADO ser menor que 0,01 rad/s quando o dispositivo está parado em temperatura ambiente.
- [C-SR-3] É FORTEMENTE RECOMENDADO ter uma resolução de 16 bits ou mais.
- DEVE relatar eventos de até pelo menos 200 Hz.
Se as implementações de dispositivos incluírem um giroscópio de três eixos, elas:
- [C-2-1] PRECISA implementar o sensor
TYPE_GYROSCOPE
. - [C-SR-4] É altamente recomendável implementar
TYPE_GYROSCOPE_UNCALIBRATED
sensor
Se as implementações de dispositivos incluírem um giroscópio com menos de três eixos, elas:
- [C-3-1] PRECISA implementar e informar o sensor
TYPE_GYROSCOPE_LIMITED_AXES
. - [C-SR-5] São STRONGLY_RECOMMENDED para implementar e informar
Sensor
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
.
Se as implementações do dispositivo incluírem um giroscópio de três eixos, um sensor de acelerômetro e um sensor de magnetômetro, eles:
- [C-4-1] PRECISA implementar um sensor composto
TYPE_ROTATION_VECTOR
.
Se as implementações do dispositivo incluem um acelerômetro de três eixos e um giroscópio de três eixos sensor, eles:
- [C-5-1] PRECISA implementar
TYPE_GRAVITY
eTYPE_LINEAR_ACCELERATION
. com sensores compostos. - [C-SR-6] É FORTEMENTE RECOMENDADO para implementar a
TYPE_GAME_ROTATION_VECTOR
sensor composto.
7.3.5. Barômetro
Implementações de dispositivos:
- [C-SR-1] É FORTEMENTE RECOMENDADO incluir um barômetro (pressão do ar ambiente sensor).
Se as implementações de dispositivos incluírem um barômetro, elas:
- [C-1-1] PRECISA implementar e informar o sensor
TYPE_PRESSURE
. - [C-1-2] PRECISA entregar eventos com frequência de 5 Hz ou mais.
- [C-1-3] PRECISA ser compensado pela temperatura.
- [C-SR-2] É MUITO RECOMENDADO para informar as medições de pressão na varia de 300 hPa a 1.100 hPa.
- DEVE ter uma precisão absoluta de 1hPa.
- DEVE ter uma precisão relativa de 0,12 hPa em um intervalo de 20 hPa (equivalente a uma precisão de ~1 m em uma mudança de aproximadamente 200 m no nível do mar).
7.3.6. Termômetro
Se as implementações do dispositivo incluírem um termômetro ambiente (sensor de temperatura), eles:
- [C-1-1] PRECISA definir
SENSOR_TYPE_AMBIENT_TEMPERATURE
. do sensor de temperatura ambiente e o sensor PRECISA medir a temperatura ambiente temperatura (sala/cabine do veículo) em que o usuário está interagindo com o o dispositivo em graus Celsius.
Se as implementações do dispositivo incluírem um sensor de termômetro que mede uma diferente da temperatura ambiente, como a temperatura da CPU, eles:
- [C-2-1] NÃO PODE definir
SENSOR_TYPE_AMBIENT_TEMPERATURE
para o sensor de temperatura.
Se as implementações de dispositivos incluírem um sensor para monitorar a temperatura da pele, então eles:
- [C-SR-1] É FORTEMENTE RECOMENDADO para oferecer suporte à PowerManager.getThermalHeadroom (em inglês) API.
7.3.7. Fotômetro
- As implementações de dispositivos PODEM incluir um fotômetro (sensor de luz ambiente).
7.3.8. Sensor de proximidade
- As implementações de dispositivos podem incluir um sensor de proximidade.
Se as implementações do dispositivo incluem um sensor de proximidade e informam apenas um leitura binária "perto" ou "longe", eles:
- [C-1-1] PRECISA medir a proximidade de um objeto na mesma direção que o tela. Ou seja, o sensor de proximidade PRECISA estar orientado para detectar objetos. próximo à tela, já que a intenção principal desse tipo de sensor é detectar um smartphone em uso pelo usuário. Se as implementações de dispositivos incluírem uma sensor de proximidade com qualquer outra orientação, ele NÃO PODE ser acessível por meio dessa API.
- [C-1-2] PRECISA ter 1 bit de precisão ou mais.
- [C-1-3] PRECISA usar 0 centímetros como a leitura próxima e 5 centímetros como que você está lendo.
- [C-1-4] PRECISA informar um alcance e uma resolução máximos de 5.
7.3.9. Sensores de alta fidelidade
Se as implementações do dispositivo incluírem um conjunto de sensores de qualidade mais alta, conforme definido nesta seção e disponibilizá-los para apps de terceiros, eles:
- [C-1-1] PRECISA identificar a capacidade pela
Sinalização de recurso
android.hardware.sensor.hifi_sensors
.
Se as implementações de dispositivos declararem android.hardware.sensor.hifi_sensors
,
eles:
[C-2-1] PRECISA ter um sensor
TYPE_ACCELEROMETER
que:- PRECISA ter um intervalo de medição entre pelo menos -8 g e +8 g e é É RECOMENDADO manter um intervalo de medição entre pelo menos -16 g e +16 g.
- PRECISA ter uma resolução de medição de pelo menos 2.048 LSB/g.
- PRECISA ter uma frequência de medição mínima de 12,5 Hz ou menos.
- PRECISA ter uma frequência de medição máxima de 400 Hz ou mais. DEVE
oferecem suporte ao SensorDirectChannel
RATE_VERY_FAST
. - PRECISA ter um ruído de medição menor ou igual a 400 μg/✓Hz.
- PRECISA implementar uma forma sem ativação desse sensor com um buffer de pelo menos 3.000 eventos de sensor.
- PRECISA ter um consumo de energia em lote não inferior a 3 mW.
- [C-SR-1] É FORTEMENTE RECOMENDADO que tenha uma largura de banda de medição de 3 dB de no pelo menos 80% da frequência de Nyquist e do espectro de ruído branco largura de banda larga.
- DEVE ter uma aceleração aleatória de caminhada com menos de 30 μg ≧Hz testada em temperatura ambiente.
- DEVE ter uma mudança de viés x temperatura de ≤ +/- 1 mg/°C.
- DEVE ter uma não linearidade de linha de melhor ajuste ≤ 0,5%, e a mudança de sensibilidade x temperatura ≤ 0,5% 0,03%/C°
- DEVE ter sensibilidade entre eixos de < 2,5 % e variação de sensibilidade entre eixos < Faixa de temperatura de funcionamento do dispositivo de 0,2%.
[C-2-2] PRECISA ter um
TYPE_ACCELEROMETER_UNCALIBRATED
com o mesmo requisitos de qualidade comoTYPE_ACCELEROMETER
.[C-2-3] PRECISA ter um sensor
TYPE_GYROSCOPE
que:- PRECISA ter um intervalo de medição entre -1.000 e +1.000 dps.
- PRECISA ter uma resolução de medida de pelo menos 16 LSB/dps.
- PRECISA ter uma frequência de medição mínima de 12,5 Hz ou menos.
- PRECISA ter uma frequência de medição máxima de 400 Hz ou mais. DEVE
oferecem suporte ao SensorDirectChannel
RATE_VERY_FAST
. - PRECISA ter um ruído de medição não superior a 0,014°/s/concordate.
- [C-SR-2] É FORTEMENTE RECOMENDADO que tenha uma largura de banda de medição de 3 dB de no pelo menos 80% da frequência de Nyquist e do espectro de ruído branco largura de banda larga.
- DEVE ter uma taxa de caminhada aleatória inferior a 0,001 °/s cione Hz testada na sala temperatura
- DEVE ter uma mudança de viés x temperatura ≤ +/- 0,05 °/ s / °C.
- DEVE ter uma mudança de sensibilidade x temperatura de ≤ 0,02% / °C.
- DEVE ter uma não linearidade de linha de melhor ajuste de ≤ 0,2%.
- DEVE ter uma densidade de ruído menor ou igual a 0,007 °/s/shaped Hz.
- DEVE ter erros de calibração inferiores a 0,002 rad/s em faixa de temperatura entre 10 e 40 °C quando o dispositivo está parado.
- DEVE ter sensibilidade à g menor que 0,1°/s/g.
- DEVE ter sensibilidade entre eixos de < 4 % e sensibilidade entre eixos variação < Faixa de temperatura de funcionamento do dispositivo de 0,3%.
[C-2-4] PRECISA ter um
TYPE_GYROSCOPE_UNCALIBRATED
com a mesma qualidade requisitos comoTYPE_GYROSCOPE
.[C-2-5] PRECISA ter um sensor
TYPE_GEOMAGNETIC_FIELD
que:- PRECISA ter um intervalo de medição entre -900 e +900 μT.
- PRECISA ter uma resolução de medida de pelo menos 5 LSB/uT.
- PRECISA ter uma frequência de medição mínima de 5 Hz ou menos.
- PRECISA ter uma frequência de medição máxima de 50 Hz ou mais.
- PRECISA ter um ruído de medição menor que 0,5 uT.
[C-2-6] PRECISA ter um
TYPE_MAGNETIC_FIELD_UNCALIBRATED
com a mesma qualidade comoTYPE_GEOMAGNETIC_FIELD
e além disso:- PRECISA implementar uma forma sem ativação desse sensor com um buffer de pelo menos 600 eventos de sensor.
- [C-SR-3] É FORTEMENTE RECOMENDADO ter o espectro de ruído branco de 1 Hz a pelo menos 10 Hz quando a taxa do relatório for 50 Hz ou superior.
[C-2-7] PRECISA ter um sensor
TYPE_PRESSURE
que:- PRECISA ter um intervalo de medição entre 300 e 1.100 hPa.
- PRECISA ter uma resolução de medida de pelo menos 80 LSB/hPa.
- PRECISA ter uma frequência de medição mínima de 1 Hz ou menos.
- PRECISA ter uma frequência de medição máxima de 10 Hz ou mais.
- PRECISA ter um ruído de medição não superior a 2 Pa/cioneHz.
- PRECISA implementar uma forma sem ativação desse sensor com um buffer de pelo menos 300 eventos de sensor.
- PRECISA ter um consumo de energia em lote não inferior a 2 mW.
[C-2-8] PRECISA ter um sensor
TYPE_GAME_ROTATION_VECTOR
.[C-2-9] PRECISA ter um sensor
TYPE_SIGNIFICANT_MOTION
que:- PRECISA ter um consumo de energia não inferior a 0,5 mW quando o dispositivo estiver estática e 1,5 mW quando o dispositivo está em movimento.
[C-2-10] PRECISA ter um sensor
TYPE_STEP_DETECTOR
que:- PRECISA implementar uma forma sem ativação desse sensor com um buffer de pelo menos 100 eventos de sensor.
- PRECISA ter um consumo de energia não inferior a 0,5 mW quando o dispositivo estiver estática e 1,5 mW quando o dispositivo está em movimento.
- PRECISA ter um consumo de energia em lote não inferior a 4 mW.
[C-2-11] PRECISA ter um sensor
TYPE_STEP_COUNTER
que:- PRECISA ter um consumo de energia não inferior a 0,5 mW quando o dispositivo estiver estática e 1,5 mW quando o dispositivo está em movimento.
[C-2-12] PRECISA ter um sensor
TILT_DETECTOR
que:- PRECISA ter um consumo de energia não inferior a 0,5 mW quando o dispositivo estiver estática e 1,5 mW quando o dispositivo está em movimento.
[C-2-13] O carimbo de data/hora do mesmo evento físico relatado pelo O acelerômetro, o giroscópio e o magnetômetro PRECISAM estar dentro de 2, 5 milissegundos e se relacionam entre si. O carimbo de data/hora do mesmo evento físico informado por o acelerômetro e o giroscópio DEVEM estar a até 0,25 milissegundo de cada entre si.
[C-2-14] PRECISA ter carimbos de data/hora do evento do sensor do giroscópio ao mesmo tempo como subsistema da câmera e em 1 milissegundo de erro.
[C-2-15] PRECISA entregar amostras aos aplicativos em até 5 milissegundos a partir a hora em que os dados estão disponíveis em qualquer um dos sensores físicos acima ao aplicativo.
[C-2-16] NÃO PODE ter um consumo de energia superior a 0,5 mW quando o dispositivo está estático e 2 mW quando ele está em movimento quando qualquer combinação dos seguintes sensores estiver ativada:
SENSOR_TYPE_SIGNIFICANT_MOTION
SENSOR_TYPE_STEP_DETECTOR
SENSOR_TYPE_STEP_COUNTER
SENSOR_TILT_DETECTORS
[C-2-17] PODE ter um sensor
TYPE_PROXIMITY
, mas, se presente, PRECISA ter com capacidade mínima de buffer de 100 eventos de sensor.
Observe que os requisitos de consumo de energia nesta seção não incluem os consumo de energia do processador do aplicativo. Ela inclui o poder por toda a cadeia: o sensor, os circuitos de suporte, sistema de processamento de sensores dedicado etc.
Se as implementações do dispositivo incluírem suporte direto a sensores, elas:
- [C-3-1] PRECISA declarar corretamente o suporte aos tipos de canal direto e direto.
informar o nível das taxas usando o
isDirectChannelTypeSupported
egetHighestDirectReportRateLevel
API. - [C-3-2] PRECISA oferecer suporte a pelo menos um dos dois tipos de canal direto do sensor. para todos os sensores que declaram suporte ao canal direto do sensor.
- DEVE oferecer suporte aos relatórios de eventos pelo canal direto do sensor para campanhas primárias
sensor (variante sem ativação) dos seguintes tipos:
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED
7.3.10. Sensores biométricos
Para mais informações sobre a medição da segurança do desbloqueio biométrico, consulte Como medir a segurança biométrica (em inglês).
Se as implementações de dispositivos incluírem uma tela de bloqueio segura, elas:
- DEVE incluir um sensor biométrico
Os sensores biométricos podem ser classificados como Classe 3 (anteriormente Forte), Classe 2 (anteriormente fraca) ou Classe 1 (anteriormente Conveniência) com base em suas taxas de aceitação de spoofing e impostores e na segurança da pipeline biométrico. Essa classificação determina as capacidades o sensor biométrico precisa interagir com a plataforma e com dispositivos aplicativos conteinerizados. Os sensores precisam atender a requisitos adicionais, conforme detalhado abaixo, se eles querem ser classificados como Classe 1, Classe 2 ou Classe 3. As biometrias de Classe 2 e Classe 3 recebem recursos adicionais como detalhadas abaixo.
Se as implementações do dispositivo disponibilizarem um sensor biométrico a terceiros aplicativos por android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt, e android.provider.Settings.ACTION_BIOMETRIC_ENROLL, eles:
- [C-4-1] PRECISA atender aos requisitos de biometria de Classe 3 ou Classe 2 conforme definido neste documento.
- [C-4-2] PRECISA reconhecer e respeitar cada nome de parâmetro definido como uma constante da seção Authenticators e as combinações delas. Por outro lado, NÃO PODE honrar ou reconhecer constantes inteiras passadas para a classe canAuthenticate(int) e setAllowedAuthenticators(int) métodos diferentes daqueles documentados como constantes públicas Autenticadores e as combinações deles.
- [C-4-3] PRECISA implementar a instrução ACTION_BIOMETRIC_ENROLL. ações em dispositivos que têm biometria de Classe 3 ou de Classe 2. Esta ação PRECISA apresentar apenas os pontos de entrada de registro para a Classe 3. ou Classe 2.
Se as implementações de dispositivos forem compatíveis com biometria passiva, elas:
- [C-5-1] PRECISA, por padrão, exigir uma etapa de confirmação adicional (por exemplo, o pressionamento de um botão).
- [C-SR-1] É FORTEMENTE RECOMENDADO ter uma configuração para permitir que os usuários substituem a preferência do aplicativo e sempre exigem acompanhamento etapa de confirmação.
- [C-SR-2] É FORTEMENTE RECOMENDADO que a ação de confirmação seja garantida. de modo que o comprometimento de um sistema operacional ou kernel não consiga fazer spoofing. Por exemplo, isso significa que a ação de confirmação com base em um botão físico é roteado por um pino de entrada/saída de uso geral (GPIO, na sigla em inglês) somente de entrada de um elemento de segurança (SE) que não pode ser conduzido por nenhum outro meio que não um pressionar um botão físico.
- [C-5-2] PRECISA implementar também um fluxo de autenticação implícito (sem etapa de confirmação) correspondente a setConfirmationRequired(boolean), que os aplicativos podem configurar para utilizar nos fluxos de login.
Se as implementações de dispositivos tiverem vários sensores biométricos, elas:
Iniciar novos requisitos
[C-7-1] PRECISA, quando a biometria está bloqueada (ou seja, ela está desativada) até que o usuário desbloqueie com a autenticação primária) ou bloqueio com limite de tempo Ou seja, a biometria é desativada temporariamente até que o usuário aguarde um pouco em um intervalo de tempo) devido a muitas tentativas com falha, também bloqueie todos os outros biometria de uma classe mais baixa. No caso de bloqueio por tempo limitado, o tempo de espera para a verificação biométrica PRECISA ser o tempo máximo de espera. de todas as biometrias em bloqueios com limite de tempo.
[C-SR-12] São RECOMENDADOS FORTEMENTE quando uma biometria está bloqueada (por exemplo, o a biometria ficará desativada até que o usuário faça o desbloqueio com a autenticação principal) ou bloqueio com limite de tempo (ou seja, a biometria é desativada temporariamente até que o usuário espera por um intervalo de tempo) devido a muitas tentativas com falha, para também bloquear todas as outras biometrias da mesma classe biométrica. 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 com limite de tempo bloqueio.
[C-7-2] PRECISA desafiar 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ão sendo bloqueados. A biometria de classe 3 PODE ser permitida para redefinir o bloqueio para uma biometria bloqueada da mesma classe ou de classe inferior. Classe 2 ou A biometria de classe 1 NÃO PODE ser permitida para concluir um bloqueio de redefinição para qualquer biometria.
Encerrar novos requisitos
- [C-SR-3] É FORTEMENTE RECOMENDADO exigir que apenas uma biometria seja confirmada por autenticação (por exemplo, se a impressão digital e os sensores faciais estiverem disponíveis no dispositivo, onAuthenticationSucceeded. deve ser enviada depois que qualquer um deles for confirmado).
Para que as implementações de dispositivos permitam o acesso a chaves de armazenamento de chaves para aplicativos de terceiros, ela:
- [C-6-1] PRECISA atender aos requisitos da Classe 3, conforme definido neste seção abaixo.
- [C-6-2] PRECISA apresentar somente biometrias de Classe 3 quando a autenticação requer BIOMETRIC_STRONG, ou a autenticação for invocada com um CryptoObject.
Se as implementações de dispositivos quiserem tratar um sensor biométrico como Classe 1 (anteriormente Conveniência), eles:
- [C-1-1] PRECISA ter uma taxa de aceitação falsa menor que 0,002%.
- [C-1-2] PRECISA divulgar que esse modo pode ser menos seguro que um PIN forte. padrão ou senha e enumerar claramente os riscos de ativá-lo, se o as taxas de aceitação de spoofing e impostores são maiores que 7%, conforme medido pelo Protocolos de teste de biometria do Android.
- [C-1-9] PRECISA contestar o usuário quanto à autenticação principal recomendada. (por exemplo, PIN, padrão, senha) após no máximo 20 tentativas falsas e nenhum tempo de espera inferior a 90 segundos para a verificação biométrica, teste falso é aquele com uma qualidade de captura adequada (BIOMETRIC_ACQUIRED_GOOD) que não corresponde a uma biometria registrada.
- [C-SR-4] É FORTEMENTE RECOMENDADO para reduzir o número total de falsos testes para a verificação biométrica especificada em [C-1-9] se o spoofing e o impostor as taxas de aceitação são superiores a 7%, conforme medido pela Android Biometrics. Protocolos de teste.
- [C-1-3] Tentativas de limite de taxa PRECISA para a verificação biométrica, em que um
teste falso é aquele com uma qualidade de captura adequada
(
BIOMETRIC_ACQUIRED_GOOD
) que não corresponda a uma biometria registrada. - [C-SR-5] É FORTEMENTE RECOMENDADO para tentativas de limite de taxa por pelo menos 30 segundos após cinco tentativas falsas para a verificação biométrica do número máximo de testes falsos por [C-1-9] - onde um teste falso é aquele com uma qualidade de captura adequada (BIOMETRIC_ACQUIRED_GOOD) que não corresponde a biometria registrada.
- [C-SR-6] É FORTEMENTE RECOMENDADO ter toda a lógica de limitação de taxa no TEE.
[C-1-10] PRECISA desativar a biometria quando a espera para autenticação primária for acionado pela primeira vez, conforme descrito em [C-0-2] da seção 9.11.
[C-1-11] PRECISA ter uma taxa de aceitação de impostor e de spoofing não superior a 30%. com (1) uma taxa de aceitação de impostor e spoofing para a apresentação de Nível A espécies com instrumento de ataque (PAI) não superior a 30%, e (2) um spoof e taxa de aceitação de impostores de espécies PAI de nível B não superior a 40%, como medidas pelos protocolos de teste de biometria do Android.
[C-1-4] PRECISA evitar a adição de novas biometrias sem antes estabelecer uma cadeia de confiança pedindo que o usuário confirme a existência ou adicione um novo dispositivo credencial (PIN/padrão/senha) protegida pelo TEE; o Android Open A implementação do projeto de origem fornece o mecanismo no framework para fazer assim.
[C-1-5] PRECISA remover completamente todos os dados biométricos identificáveis de um usuário. quando a conta do usuário é removida, inclusive por meio de uma redefinição para a configuração original.
[C-1-6] PRECISA respeitar a sinalização individual dessa biometria (ou seja,
DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT
,DevicePolicymanager.KEYGUARD_DISABLE_FACE
ouDevicePolicymanager.KEYGUARD_DISABLE_IRIS
).[C-1-7] PRECISA desafiar o usuário quanto à autenticação principal recomendada. (por exemplo, PIN, padrão, senha) uma vez a cada 24 horas ou menos. Observação: o upgrade de dispositivos lançados com o Android 9 ou versões anteriores PRECISA contestar o usuário quanto à autenticação principal recomendada (por exemplo, PIN, padrão, senha) uma vez a cada 72 horas ou menos.
[C-1-8] PRECISA desafiar o usuário na pergunta principal recomendada. Autenticação (por exemplo: PIN, padrão, senha) ou biometria de Classe 3 (STRONG) depois de uma das seguintes opções:
- um tempo limite de inatividade de 4 horas OU
- 3 tentativas de autenticação biométrica falharam.
- O tempo limite de inatividade e a contagem de autenticação com falha são redefinidos após qualquer confirmação das credenciais do dispositivo. Observação: o upgrade de dispositivos lançados com o Android 9 ou versões anteriores pode ser isentos de C-1-8.
[C-SR-7] É FORTEMENTE RECOMENDADO usar a lógica na estrutura fornecida pelo Android Open Source Project para aplicar as restrições especificadas em [C-1-7] e [C-1-8] para novos dispositivos.
[C-SR-8] É FORTEMENTE RECOMENDADO que tenham uma taxa de rejeição falsa menor que 10%, conforme medido no dispositivo.
[C-SR-9] É FORTEMENTE RECOMENDADO que tenham uma latência inferior a 1 segundo, medida desde a detecção da biometria até o desbloqueio da tela, para cada biometria registrada.
Iniciar novos requisitos
[C-1-12] PRECISA ter uma taxa de aceitação de spoofing e impostor não superior a 40% por apresentação de instrumento de ataque (PAI, na sigla em inglês), conforme medido pelo Protocolos de teste de biometria do Android.
[C-SR-13] É FORTEMENTE RECOMENDADO que aceite falsificações e falsificações. taxa 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.
[C-SR-14] É FORTEMENTE RECOMENDADO a divulgar a classe biométrica do sensor biométrico e os riscos correspondentes de ativá-lo.
[C-SR-17] É FORTEMENTE RECOMENDADO para implementar as novas interfaces AIDL (como
IFace.aidl
eIFingerprint.aidl
).
Encerrar novos requisitos
Se as implementações de dispositivos quiserem tratar um sensor biométrico como Classe 2 (link em inglês) (anteriormente fraco), eles:
[C-2-1] PRECISA atender a todos os requisitos da Classe 1 acima.
[C-2-2] PRECISA ter uma taxa de aceitação de impostor e de spoofing não superior a 20%. com (1) uma taxa de aceitação de spoof e impostor para Espécies de instrumento de ataque de apresentação (PAI) de nível A não superior a 20%, e (2) uma taxa de aceitação de spoof e impostor de espécies PAI de nível B não maior que 30%, conforme medido pelo Protocolos de teste de biometria do Android.
Iniciar novos requisitos
- [C-SR-15] É FORTEMENTE RECOMENDADO que aceite falsificações e falsificações. taxa não superior a 20% por instrumento de ataque de apresentação (PAI) espécie, conforme medido pelo Protocolos de teste de biometria do Android.
Encerrar novos requisitos
- [C-2-3] PRECISA realizar a
correspondência biométrica em um ambiente de execução isolado fora do Android
do usuário ou do kernel, como o ambiente de execução confiável (TEE),
ouem um chip com um canal seguro para o ambiente de execução isolado ou em uma Máquina Virtual Protegida que atenda aos requisitos da Seção 9.17. - [C-2-4] PRECISA ter todos os dados identificáveis criptografados e criptograficamente autenticados para que não possam ser adquiridos, lidos ou alterados fora o ambiente de execução isolado ou um chip com um canal seguro para o ambiente de execução isolado, conforme documentado na implementação diretrizes 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, mas com autenticação biométrica
ou a inscrição está acontecendo:
- PRECISA operar a câmera de uma forma que impeça que os frames sejam 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 ou uma Máquina Virtual Protegida controlada por hipervisor que atenda aos requisitos da Seção 9.17.
- Para soluções RGB de uma câmera, os frames podem ser legível fora do ambiente de execução isolado para dar suporte a operações como a visualização da inscrição, mas NÃO PODERÁ ser alterável.
- [C-2-6] NÃO PODE permitir que aplicativos de terceiros façam a distinção entre registros biométricos individuais.
- [C-2-7] NÃO PODE permitir acesso não criptografado a dados biométricos identificáveis nem quaisquer dados derivados dele (como embeddings) para o Processador de aplicativos fora do contexto do TEE ou a Máquina Virtual Protegida controlada por um hipervisor que atenda aos requisitos da Seção 9.17. O upgrade de dispositivos lançados com o Android 9 ou versões anteriores não está isento de C-2-7.
[C-2-8] PRECISA ter um pipeline de processamento seguro, de modo que um sistema o comprometimento do sistema ou kernel não pode permitir a injeção direta de dados se autenticar falsamente como usuário. Observação: se as implementações de dispositivos já tiverem sido lançadas no Android 9. ou anterior e não possa atender ao requisito C-2-8 por meio de um software de sistema eles poderão ser isentos dessa exigência.
[C-SR-10] É FORTEMENTE RECOMENDADO a inclusão da detecção de atividade para todos modalidades biométricas e detecção de atenção para a biometria facial.
[C-2-9] PRECISA disponibilizar o sensor biométrico para terceiros aplicativos conteinerizados.
Se as implementações de dispositivos quiserem tratar um sensor biométrico como Classe 3 (link em inglês) (anteriormente Forte), eles:
- [C-3-1] PRECISA atender a todos os requisitos da Classe 2 acima, exceto [C-1-7] e [C-1-8].
- [C-3-2] PRECISA ter uma implementação de keystore suportada por hardware.
- [C-3-3] PRECISA ter uma taxa de aceitação de impostor e de spoofing não superior a 7%. com (1) uma taxa de aceitação de spoof e impostor para Espécies de instrumento de ataque de apresentação (PAI) de nível A não superior a 7% e (2) uma taxa de aceitação de impostor e de spoofing de espécies PAI de nível B não for maior que 20%, conforme medido pelo Protocolos de teste de biometria do Android.
- [C-3-4] PRECISA desafiar o usuário na pergunta principal recomendada. autenticação (por exemplo, PIN, padrão, senha) uma vez a cada 72 horas ou menos.
- [C-3-5] PRECISA gerar novamente o ID do autenticador. para todas as biometrias de Classe 3 com suporte no dispositivo, se alguma delas for reinscreveu-se.
- [C-3-6] É necessário ativar chaves de keystore com biometria para terceiros aplicativos conteinerizados.
Iniciar novos requisitos
- [C-SR-16] É FORTEMENTE RECOMENDADO que aceite falsificações e falsificações. taxa 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.
Encerrar novos requisitos
Se as implementações de dispositivos contiverem um sensor de impressão digital sob a tela (UDFPS, na sigla em inglês), eles:
- [C-SR-11] É FORTEMENTE RECOMENDADO para evitar a área de toque do UDFPS interfira na navegação com três botões( que alguns usuários podem exigir para para fins de acessibilidade).
7.3.11. Sensor de posição
Implementações de dispositivos:
- PODE suportar o sensor de pose com 6 graus de liberdade.
Se as implementações de dispositivos oferecerem suporte ao sensor de pose com 6 graus de liberdade, elas:
- [C-1-1] PRECISA implementar e informar
TYPE_POSE_6DOF
sensor - [C-1-2] PRECISA ser mais preciso do que apenas o vetor de rotação.
7.3.12. Sensor de ângulo de dobradiça
Se as implementações de dispositivos oferecerem suporte a um sensor de ângulo de dobradiça, elas:
- [C-1-1] PRECISA implementar e informar
TYPE_HINGLE_ANGLE
. - [C-1-2] PRECISA oferecer suporte a pelo menos duas leituras entre 0 e 360 graus. (inclusive, por exemplo, incluindo 0 e 360 graus).
- [C-1-3] PRECISA retornar uma ativação.
sensor para
getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE)
.
7.3.13. IEEE 802.1.15.4 (UWB)
Se as implementações de dispositivos incluírem suporte para 802.1.15.4 e exporem a a um aplicativo de terceiros, elas:
Iniciar novos requisitos
- [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 a seguir (predefinidos)
combinações de parâmetros de FIRA UCI)
definido na implementação do AOSP.
CONFIG_ID_1
: alcance deSTATIC STS DS-TWR
unicast definido pela FiRa. modo adiado, com intervalo de 240 ms.CONFIG_ID_2
: intervalo deSTATIC STS DS-TWR
de um para muitos definido pela FiRa. modo adiado, intervalo de 200 ms. Caso de uso típico: smartphone interage com muitos dispositivos inteligentes.CONFIG_ID_3
: igual aCONFIG_ID_1
, exceto ângulo de chegada (AoA) os dados não são informados.CONFIG_ID_4
: igual aCONFIG_ID_1
, exceto pelo modo de segurança do P-STS. ativado.CONFIG_ID_5
: igual aCONFIG_ID_2
, exceto pelo modo de segurança do P-STS. ativado.CONFIG_ID_6
: igual aCONFIG_ID_3
, exceto pelo modo de segurança do P-STS. ativado.CONFIG_ID_7
: igual aCONFIG_ID_2
, exceto pelo controle individual do P-STS. está ativado.
- [C-1-4] PRECISA fornecer uma funcionalidade de usuário para permitir que ele alterne a UWB. ativado/desativado do rádio.
- [C-1-5] PRECISA impor que os apps que usam a rádio UWB mantenham a
UWB_RANGING
. (no grupo de permissõesNEARBY_DEVICES
).
Ser aprovado nos testes de conformidade e certificação relevantes definidos pelo organizações, incluindo a FIRA, CCC e O CSA ajuda a garantir que o 802.1.15.4 funcione corretamente.
Encerrar novos requisitos
7,4. Conectividade de dados
7.4.1. Telefonia
A "Telefonia", conforme usada pelas APIs do Android, e este documento se refere especificamente a 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 ligações, mensagens e dados, conforme a necessidade do produto.
via rede GSM ou CDMA. Embora essas chamadas de voz possam ou não ter comutação por pacote,elas são para fins do Android consideradas independentes de qualquer conectividade de dados que possa ser implementada usando a mesma rede. Em outras palavras,a funcionalidade de “telefonia” do Android e as APIs referem-se especificamente a chamadas de voz e SMS. Por exemplo, implementações de dispositivos que não podem fazer chamadas ou enviar/receber mensagens SMS não são consideradas dispositivos de telefonia, mesmo que usem uma rede celular para conectividade de dados.
- O Android PODE ser usado em dispositivos que não incluem hardware de telefonia. Isso é que o Android é compatível com dispositivos que não são smartphones.
Se as implementações de dispositivos incluírem telefonia GSM ou CDMA, elas:
- [C-1-1] PRECISA declarar a flag de recurso
android.hardware.telephony
e outras sinalizações de sub-recursos de acordo com a tecnologia. - [C-1-2] PRECISA implementar o suporte completo da API para essa tecnologia.
- DEVE permitir todos os tipos de serviço de celular disponíveis (2G, 3G, 4G, 5G etc.)
durante chamadas de emergência (independentemente dos tipos de rede definidos pelo
SetAllowedNetworkTypeBitmap()
).
Se as implementações de dispositivos não incluírem hardware de telefonia, elas:
- [C-2-1] PRECISA implementar as APIs completas como ambiente autônomo.
Se as implementações de dispositivos oferecerem suporte a eUICCs ou eSIMs/chips incorporados e incluírem um mecanismo reservado para disponibilizar a funcionalidade de eSIM a terceiros desenvolvedores, ela:
- [C-3-1] PRECISA declarar os
android.hardware.telephony.euicc
flag de recurso.
Se as implementações de dispositivos não definirem a propriedade do sistema ro.telephony.iwlan\_operation\_mode
como "legada", elas:
- [C-4-1] NÃO É POSSÍVEL informar "NETWORK_TYPE_IWLAN" por NetworkRegistrationInfo#getAccessNetworkTechnology() quando NetworkRegistrationInfo#getTransportType() é relatado como "TRANSPORT_TYPE_WWAN" para a mesma instância NetworkRegistrationInfo.
Se as implementações de dispositivos oferecerem suporte a um único Subsistema multimídia IP (IMS, na sigla em inglês) nos serviços de telefonia multimídia (MMTEL) e recursos de Serviços de Comunicação Avançada (RCS) e precisam estar em conformidade com requisitos das operadoras de celular quanto ao uso de uma única registro IMS para todo o tráfego de sinalização IMS, eles:
- [C-5-1] PRECISA declarar o
android.hardware.telephony.ims
flag de recurso e fornecer uma implementação completa do API ImsService para MMTEL e RCS User Capabilities Exchange API. - [C-5-2] PRECISA declarar o
android.hardware.telephony.ims.singlereg
e fornecem uma implementação completa da API SipTransport, a API GbaService, indicações do portador dedicado usando a HAL IRadio 1.6 e o provisionamento via servidor de configuração automática (ACS) ou outro provisionamento proprietário usando a API de configuração IMS.
Se as implementações de dispositivos informarem o recurso android.hardware.telephony
:
- [C-6-1] O
SmsManager#sendTextMessage
eSmsManager#sendMultipartTextMessage
PRECISA resultar em chamadas correspondentes paraCarrierMessagingService
por fornecer a funcionalidade de mensagens de texto.SmsManager#sendMultimediaMessage
eSmsManager#downloadMultimediaMessage
PRECISA resultar em chamadas correspondentes paraCarrierMessagingService
para fornecer funcionalidade de mensagens multimídia. - [C-6-2] O aplicativo designado por
android.provider.Telephony.Sms#getDefaultSmsPackage
OBRIGATÓRIO usar SmsManager (link em inglês) ao enviar e receber mensagens SMS e MMS. A referência do AOSP a implementação em pacotes/apps/mensagens atende a esse requisito. - [C-6-3] O aplicativo que responde
Intent#ACTION_DIAL
PRECISA ser compatível com a entrada de códigos de discador arbitrários formatados como*#*#CODE#*#*
e acionar um modeloTelephonyManager#ACTION_SECRET_CODE
transmissão. - [C-6-4] O aplicativo que responde
Intent#ACTION_DIAL
OBRIGATÓRIO usarVoicemailContract.Voicemails#TRANSCRIPTION
para exibir a transcrição do correio de voz visual aos usuários, caso seja compatível com transcrições do correio de voz. - [C-6-5] PRECISA representar todas as SubscriptionInfo com equivalentes
agrupar UUIDs
como uma única assinatura em todas as affordances visíveis ao usuário que exibem e
controlar as informações do chip. Exemplos dessas affordances incluem configurações
as interfaces correspondentes
Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS
ouEuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
- [C-6-6] NÃO PODE exibir ou permitir o controle de nenhum SubscriptionInfo com um UUID de grupo não nulo e oportunista em quaisquer affordances visíveis ao usuário permitir a configuração ou o controle das configurações do chip.
Se as implementações do dispositivo informarem o recurso android.hardware.telephony
e fornecer uma barra de status do sistema. Em seguida:
- [C-7-1] É NECESSÁRIO selecionar uma assinatura ativa representativa para um determinado UUID de grupo para exibir ao usuário em recursos que forneçam status de chip informações imprecisas ou inadequadas. Exemplos de tais affordances incluem a barra de status celular, no ícone de indicador ou no bloco "Configurações rápidas".
- [C-SR-1] É FORTEMENTE RECOMENDADO que a assinatura de representante seja escolhido para ser o assinatura de dados ativa a menos que o dispositivo tenha uma voz , durante o qual é FORTEMENTE RECOMENDADO que o representante é a assinatura do Voice ativo.
Se as implementações de dispositivos informarem o recurso android.hardware.telephony
:
- [C-6-7] PRECISA ser capaz de abrir e utilizar simultaneamente o máximo número de canais lógicos (20 no total) para cada UICC de acordo com o ETSI TS 102 221.
- [C-6-8] NÃO É POSSÍVEL aplicar nenhum dos seguintes comportamentos a apps de operadoras ativos
(conforme designado por
TelephonyManager#getCarrierServicePackageName
) automática ou sem confirmação explícita do usuário:- Revogar ou limitar o acesso à rede
- Revogar permissões
- Restringir a execução de apps em segundo ou primeiro plano além dos recursos de gerenciamento de energia atuais incluídos no AOSP
- Desativar ou desinstalar o app
Se as implementações de dispositivos informarem o recurso android.hardware.telephony
e
todas ativas,
inscrições não oportunistas
que compartilham um UUID de grupo são desativados,
removido fisicamente do dispositivo ou marcado como oportunista, faça o seguinte:
- [C-8-1] É NECESSÁRIO desativar automaticamente todos os recursos ativos restantes oportunista no mesmo grupo.
Se as implementações de dispositivos incluírem a telefonia GSM, mas não a telefonia CDMA, elas:
- [C-9-1] NÃO PODE declarar
PackageManager#FEATURE_TELEPHONY_CDMA
. - [C-9-2] PRECISA gerar uma
IllegalArgumentException
nas tentativas de definir Tipos de rede 3GPP2 em bitmasks de tipo de rede preferencial ou permitido. - [C-9-3] PRECISA retornar uma string vazia de
TelephonyManager#getMeid
Se as implementações do dispositivo oferecerem suporte a eUICCs com várias portas e perfis:
- [C-10-1] PRECISA declarar os
android.hardware.telephony.euicc.mep
flag de recurso.
7.4.1.1 Compatibilidade com bloqueio de número
Se as implementações de dispositivos informarem o recurso android.hardware.telephony.calling
, elas:
- [C-1-1] PRECISA incluir suporte para bloqueio de número
- [C-1-2] PRECISA implementar totalmente o
BlockedNumberContract
. e a API correspondente, conforme descrito na documentação do SDK. [C-1-3] PRECISA bloquear todas as ligações e mensagens de um número de telefone "BlockedNumberProvider" sem interação com apps. A única exceção ocorre quando o bloqueio de número é temporariamente suspenso, conforme descrito no SDK na documentação do Google Cloud.
[C-1-4] PRECISA gravar no provedor de registro de chamadas da plataforma. para uma chamada bloqueada e PRECISA filtrar chamadas com
BLOCKED_TYPE
de visualização padrão do registro de chamadas no app discador pré-instalado.[C-1-5] NÃO PODE fazer gravações no provedor de telefonia de uma mensagem bloqueada.
[C-1-6] PRECISA implementar uma interface de gerenciamento de números bloqueados, que é aberta com a intent retornada por
TelecomManager.createManageBlockedNumbersIntent()
. .[C-1-7] NÃO PODE permitir que usuários secundários vejam ou editem os números bloqueados no dispositivo, já que a plataforma Android pressupõe que o usuário principal dos serviços de telefonia, em uma única instância, no dispositivo. Todos o bloqueio de interface relacionada PRECISA estar oculta para usuários secundários e a lista bloqueada PRECISA estar oculta para usuários secundários. sejam respeitadas.
DEVE migrar os números bloqueados para o provedor quando um dispositivo for atualizado para o Android 7.0.
DEVE fornecer uma funcionalidade de usuário para mostrar chamadas bloqueadas no de telefone.
7.4.1.2 API Telecom
Se as implementações de dispositivos informarem android.hardware.telephony.calling
, elas:
- [C-1-1] PRECISA oferecer suporte às APIs
ConnectionService
descritas no SDK. - [C-1-2] PRECISA exibir uma nova chamada recebida e fornecer funcionalidade ao usuário para
Aceitar ou rejeitar a ligação recebida quando o usuário estiver em uma ligação
por um app de terceiros sem suporte ao recurso de retenção
especificado por
CAPABILITY_SUPPORT_HOLD
- [C-1-3] PRECISA ter um aplicativo que implemente InCallService (ambos em inglês).
[C-SR-1] É FORTEMENTE RECOMENDADO notificar o usuário de que responder a uma a ligação recebida vai encerrar a chamada em andamento.
A implementação do AOSP atende a esses requisitos por uma notificação de alerta. que indica ao usuário que atender a uma chamada fará com que o outra chamada seja eliminada.
[C-SR-2] É FORTEMENTE RECOMENDADO pré-carregar o app discador padrão que mostra uma entrada do registro de chamadas e o nome de um app de terceiros no registro de chamadas quando o app de terceiros define
EXTRA_LOG_SELF_MANAGED_CALLS
tecla extras noPhoneAccount
paratrue
.[C-SR-3] É FORTEMENTE RECOMENDADO para lidar com os Eventos
KEYCODE_MEDIA_PLAY_PAUSE
eKEYCODE_HEADSETHOOK
para oandroid.telecom
APIs, conforme abaixo:- Chamar
Connection.onDisconnect()
quando um pressionamento breve do evento de tecla é detectado durante uma chamada em andamento. - Chamar
Connection.onAnswer()
quando um pressionamento breve do evento de tecla é detectado durante uma ligação recebida. - Chamar
Connection.onReject()
quando um evento de tecla é pressionado durante uma ligação recebida. - Alterne o status de silenciamento da
CallAudioState
.
- Chamar
7.4.1.3 Descarregamento de sinal de atividade NAT-T da rede celular
Implementações de dispositivos:
- DEVE incluir suporte para descarga de sinal de atividade de celular.
Se as implementações de dispositivos incluírem suporte para descarga de sinal de atividade celular e expõe a funcionalidade a apps de terceiros, elas:
- [C-1-1] PRECISA oferecer suporte à API SocketKeepAlive.
- [C-1-2] PRECISA oferecer suporte a pelo menos um slot de sinal de atividade simultâneo na rede celular.
- [C-1-3] PRECISA oferecer suporte ao maior número possível de slots de sinal de atividade móveis simultâneos. compatíveis com a HAL de rádio celular.
- [C-SR-1] É FORTEMENTE RECOMENDADO para oferecer suporte a pelo menos três sinais de atividade de celular por instância de rádio.
Se as implementações de dispositivos não incluírem suporte para descarga de sinal de atividade celular, eles:
- [C-2-1] PRECISA retornar ERROR_UNSUPPORTED.
7.4.2. IEEE 802.11 (Wi-Fi)
Implementações de dispositivos:
- DEVE incluir suporte para uma ou mais formas de 802.11.
Se as implementações de dispositivos incluírem suporte para 802.11 e expõem a a um aplicativo de terceiros, elas:
- [C-1-1] PRECISA implementar a API do Android correspondente.
- [C-1-2] PRECISA informar a flag de recurso de hardware
android.hardware.wifi
. - [C-1-3] PRECISA implementar a API multicast. conforme descrito na documentação do SDK.
- [C-1-4] PRECISA oferecer suporte a multicast DNS (mDNS) e NÃO PODE filtrar pacotes mDNS
(224.0.0.251 ou ff02::fb).
a qualquer momento de operação, incluindo quando a tela
não está em um estado ativo, a menos que você descarte ou filtre esses pacotes
necessário para se manter dentro das faixas de consumo de energia exigidas pelas
requisitos aplicáveis ao mercado-alvo.
Para implementações de dispositivos Android Television, mesmo em estados de energia em espera. - [C-1-5] NÃO PODE tratar
WifiManager.enableNetwork()
chamada de método da API como indicação suficiente para alternar a atividadeNetwork
, que é usado por padrão para o tráfego do aplicativo e é retornado. porConnectivityManager
Métodos de API, comogetActiveNetwork
eregisterDefaultNetworkCallback
. Em outras palavras, eles só PODEM desativar o acesso à Internet fornecido por qualquer outro provedor de rede (por exemplo, dados móveis) se for validado se a rede Wi-Fi está fornecendo acesso à Internet. - [C-1-6] São FORTEMENTE RECOMENDADOS quando
ConnectivityManager.reportNetworkConnectivity()
o método da API for chamado, reavaliar o acesso à Internet noNetwork
e quando a avaliação determina que oNetwork
atual não fornece mais Acesso à Internet, mude para qualquer outra rede disponível (por exemplo, rede móvel) dados) que oferece acesso à Internet. - [C-1-7] PRECISA randomizar o endereço MAC de origem e o número da sequência da sondagem frames de solicitação, uma vez no início de cada verificação, enquanto o STA está desconectado.
- [C-1-8] PRECISA usar um endereço MAC consistente (NÃO DEVE randomizar o MAC) na metade de uma verificação).
- [C-1-9] PRECISA iterar o número da sequência da solicitação de sondagem normalmente (sequencialmente) entre as solicitações de sondagem em uma verificação.
- [C-1-10] PRECISA randomizar o número da sequência da solicitação da sondagem entre a última sondagem solicitação de uma verificação e a primeira solicitação de sondagem da próxima verificação.
- [C-SR-1] É FORTEMENTE RECOMENDADO para randomizar o endereço MAC de origem usado para
toda a comunicação do STA a um ponto de acesso (AP) enquanto associa e
associadas.
- O dispositivo PRECISA usar um endereço MAC aleatório diferente para cada SSID. (FQDN para Passpoint) com que ele se comunica.
- O dispositivo PRECISA oferecer ao usuário a opção de controlar o randomização por SSID (FQDN para Passpoint) com modelos aleatórias e PRECISA definir o modo padrão para as novas redes Wi-Fi. configurações sejam aleatórias.
- [C-SR-2] É FORTEMENTE RECOMENDADO usar um BSSID aleatório para qualquer AP que
criar.
- O endereço MAC PRECISA ser aleatório e mantido de acordo com o SSID usado pelo AP.
- O DISPOSITIVO PODE fornecer ao usuário a opção de desativar esse recurso. Se essa opção for fornecida, a ordem aleatória PRECISA estar ativada por padrão.
Se as implementações do dispositivo permitirem o modo de economia de energia Wi-Fi, conforme definido no padrão IEEE 802.11, eles:
- DEVE desativar o modo de economia de energia Wi-Fi sempre que um app tiver
Fechadura
WIFI_MODE_FULL_HIGH_PERF
ouWIFI_MODE_FULL_LOW_LATENCY
fechadura porWifiManager.createWifiLock()
eWifiManager.WifiLock.acquire()
APIs e o bloqueio está ativo. - [C-3-2] A latência média de ida e volta entre o dispositivo
e um ponto de acesso enquanto o dispositivo está em um bloqueio de baixa latência do Wi-Fi
(
WIFI_MODE_FULL_LOW_LATENCY
) PRECISA ser menor que latência durante o modo Wi-Fi High Perf Lock (WIFI_MODE_FULL_HIGH_PERF
). - [C-SR-3] É FORTEMENTE RECOMENDADO para minimizar a latência de ida e volta do Wi-Fi
sempre que um bloqueio de baixa latência (
WIFI_MODE_FULL_LOW_LATENCY
) for adquirido e entra em vigor.
Se as implementações de dispositivos forem compatíveis com Wi-Fi e usarem Wi-Fi para buscar a localização, eles:
- [C-2-1] PRECISA fornecer uma funcionalidade do usuário para ativar/desativar a leitura de valor.
por meio do
WifiManager.isScanAlwaysAvailable
Método de API.
7.4.2.1. Wi-Fi Direct
Implementações de dispositivos:
- DEVE incluir suporte para Wi-Fi Direct (Wi-Fi ponto a ponto).
Se as implementações de dispositivos forem compatíveis com Wi-Fi Direct, elas:
- [C-1-1] PRECISA implementar a API Android correspondente. conforme descrito na documentação do SDK.
- [C-1-2] PRECISA informar o recurso de hardware
android.hardware.wifi.direct
. - [C-1-3] PRECISA permitir o funcionamento normal do Wi-Fi.
- [C-1-4] PRECISA oferecer suporte a operações com Wi-Fi e Wi-Fi Direct simultaneamente.
- [C-SR-1] É FORTEMENTE RECOMENDADO para randomizar o endereço MAC de origem para todos conexões Wi-Fi Direct recém-criadas.
7.4.2.2. Configuração de link direto encapsulado Wi-Fi
Implementações de dispositivos:
- DEVE incluir suporte para Configuração de link direto encapsulado por Wi-Fi (TDLS, na sigla em inglês) conforme descrito na Documentação do SDK do Android.
Se as implementações de dispositivos incluírem suporte para TDLS e TDLS for ativado pelo API WiFiManager, eles:
- [C-1-1] PRECISA declarar suporte a TDLS por meio de
WifiManager.isTdlsSupported
. - DEVE usar TDLS apenas quando for possível E benéfico.
- DEVE ter alguma heurística e NÃO usar TDLS quando seu desempenho puder ser pior do que passar pelo ponto de acesso Wi-Fi.
7.4.2.3. Wi-Fi Aware
Implementações de dispositivos:
- DEVE incluir compatibilidade com o Wi-Fi Aware.
Caso as implementações do dispositivo incluam suporte ao Wi-Fi Aware e exponha a aplicativos de terceiros, elas:
- [C-1-1] PRECISA implementar as APIs
WifiAwareManager
, conforme descrito nos Documentação do SDK. - [C-1-2] PRECISA declarar a flag de recurso
android.hardware.wifi.aware
. - [C-1-3] PRECISA oferecer suporte às operações Wi-Fi e Wi-Fi Aware simultaneamente.
- [C-1-4] PRECISA randomizar o endereço da interface de gerenciamento do Wi-Fi Aware em intervalos de no máximo 30 minutos e sempre que o Wi-Fi Aware estiver ativado, a menos que o a operação de alcance está em andamento ou um caminho de dados do Aware está ativo (a ordem aleatória não está esperado, enquanto o caminho de dados estiver ativo).
Caso as implementações de dispositivos incluam suporte a Wi-Fi Aware e local do Wi-Fi, conforme descrito na Seção 7.4.2.5 e exponha essas funcionalidades a apps de terceiros, então elas:
- [C-2-1] PRECISA implementar as APIs de descoberta com reconhecimento de local: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm e onServiceDiscoveredWithinRange.
7.4.2.4. Passpoint do Wi-Fi
Se as implementações de dispositivos forem compatíveis com 802.11 (Wi-Fi), elas:
- [C-1-1] PRECISA incluir suporte ao Passpoint de Wi-Fi.
- [C-1-2] PRECISA implementar as APIs
WifiManager
relacionadas ao Passpoint como descritos na documentação do SDK. - [C-1-3] PRECISA oferecer suporte ao padrão IEEE 802.11u, especificamente relacionados para descoberta e seleção de rede, como o anúncio genérico. (GAS) e Access Network Query Protocol (ANQP).
- [C-1-4] PRECISA declarar a flag de recurso
android.hardware.wifi.passpoint
. - [C-1-5] PRECISA seguir a implementação do AOSP para descobrir, associar e associar a redes Passpoint.
- [C-1-6] PRECISA oferecer suporte pelo menos ao seguinte subconjunto de provisionamento de dispositivos protocolos definidos no Passpoint R2 da Wi-Fi Alliance: EAP-TTLS. e SOAP-XML.
- [C-1-7] PRECISA processar o certificado do servidor AAA conforme descrito em Especificação Hotspot 2.0 R3.
- [C-1-8] PRECISA permitir o controle do usuário do provisionamento pelo seletor de Wi-Fi.
- [C-1-9] PRECISA manter as configurações do Passpoint persistentes nas reinicializações.
- [C-SR-1] É FORTEMENTE RECOMENDADO para aceitar os Termos e Condições recurso de aceitação.
- [C-SR-2] É RECOMENDADO para oferecer suporte ao recurso de informações de locais.
Se um controle de desativação do usuário global do Passpoint for fornecido, as implementações:
- [C-3-1] PRECISA ativar o Passpoint por padrão.
7.4.2.5 Local do Wi-Fi (tempo de retorno do Wi-Fi - RTT)
Implementações de dispositivos:
- DEVE incluir suporte para Localização de Wi-Fi.
Se as implementações do dispositivo incluem suporte à localização por Wi-Fi e expõem a a aplicativos de terceiros, elas:
- [C-1-1] PRECISA implementar as APIs
WifiRttManager
, conforme descrito nos Documentação do SDK. - [C-1-2] PRECISA declarar a flag de recurso
android.hardware.wifi.rtt
. - [C-1-3] PRECISA randomizar o endereço MAC de origem para cada burst de RTT que é executado enquanto a interface Wi-Fi na qual o RTT é sendo executado não está associado a um ponto de acesso.
- [C-1-4] PRECISA ter precisão de até 2 metros na largura de banda de 80 MHz no 68o percentil (conforme calculado com a função de distribuição cumulativa).
- [C-SR-1] É FORTEMENTE RECOMENDADO que você informe com precisão a uma distância de até 1,5 metro com largura de banda de 80 MHz no 68o percentil (conforme calculado com a função de distribuição cumulativa).
7.4.2.6. Descarregamento de sinal de atividade Wi-Fi
Implementações de dispositivos:
- DEVE incluir suporte para descarga de sinal de atividade Wi-Fi.
Se as implementações de dispositivos incluírem suporte para descarga de sinal de atividade Wi-Fi e expõe a funcionalidade a apps de terceiros, eles:
- [C-1-1] PRECISA oferecer suporte à API SocketKeepAlive.
- [C-1-2] PRECISA aceitar pelo menos três slots de sinal de atividade simultâneos por Wi-Fi
Se as implementações de dispositivos não incluírem suporte para descarga de sinal de atividade Wi-Fi, eles:
- [C-2-1] PRECISA retornar
ERROR_UNSUPPORTED
.
7.4.2.7. Wi-Fi Easy Connect (protocolo de provisionamento de dispositivo)
Implementações de dispositivos:
- DEVE incluir suporte ao Wi-Fi Easy Connect (DPP).
Caso as implementações do dispositivo incluam suporte ao Wi-Fi Easy Connect e exponham a a aplicativos de terceiros, elas:
- [C-1-1] PRECISA ter o WifiManager#isEasyConnectSupported()
retornam
true
.
7.4.2.8. Validação do certificado do servidor Wi-Fi empresarial
Se o certificado do servidor Wi-Fi não for validado ou o servidor Wi-Fi nome de domínio não está definido, implementações de dispositivos:
- [C-SR-1] É FORTEMENTE RECOMENDADO não fornecer ao usuário a opção de adicione manualmente a rede Wi-Fi empresarial no app Configurações.
7.4.2.9. Confiança no primeiro uso (TOFU)
Se as implementações de dispositivos forem compatíveis com a Confiança no primeiro uso (TOFU) e permitem que o usuário defina configurações WPA/WPA2/WPA3-Enterprise, então eles:
- [C-4-1] PRECISA oferecer ao usuário a opção de usar o TOFU.
7.4.3. Bluetooth
Se as implementações de dispositivos oferecerem suporte ao perfil de áudio Bluetooth, elas:
- DEVE oferecer suporte a codecs de áudio avançados e codecs de áudio Bluetooth (por exemplo, LDAC)
Se as implementações de dispositivos forem compatíveis com HFP, A2DP e AVRCP, elas:
- DEVE oferecer suporte a pelo menos cinco dispositivos conectados no total.
Se as implementações do dispositivo declararem android.hardware.vr.high_performance
eles:
- [C-1-1] PRECISA oferecer suporte a Bluetooth 4.2 e à extensão de comprimento de dados Bluetooth LE.
O Android inclui suporte para Bluetooth e Bluetooth de baixa energia.
Se as implementações de dispositivos incluem suporte a Bluetooth e Bluetooth de baixa energia, eles:
- [C-2-1] PRECISA declarar os recursos relevantes da plataforma
(
android.hardware.bluetooth
eandroid.hardware.bluetooth_le
respectivamente) e implementar as APIs da plataforma. - DEVE implementar perfis Bluetooth relevantes como A2DP, AVRCP, OBEX, HFP etc., conforme apropriado para o dispositivo.
Se as implementações de dispositivos incluírem suporte ao Bluetooth de baixa energia (BLE), elas:
- [C-3-1] PRECISA declarar o recurso de hardware
android.hardware.bluetooth_le
. - [C-3-2] PRECISA ativar o Bluetooth baseado em GATT (perfil de atributo genérico). conforme descrito na documentação do SDK e android.bluetooth.
- [C-3-3] PRECISA informar o valor correto para
BluetoothAdapter.isOffloadedFilteringSupported()
para indicar se o lógica de filtragem do ScanFilter, As classes de API são implementadas. - [C-3-4] PRECISA informar o valor correto para
BluetoothAdapter.isMultipleAdvertisementSupported()
para indicar se a publicidade de baixa energia é compatível. [C-3-5] PRECISA implementar um tempo limite de endereço particular solucionável (RPA, na sigla em inglês) de 15 minutos e alternar o endereço no tempo limite para proteger a privacidade do usuário quando o dispositivo está usando BLE ativamente para verificação ou publicidade. Para evitar ataques de temporização, os intervalos de tempo limite também PRECISAM ser aleatórios. entre 5 e 15 minutos.
DEVE oferecer suporte ao descarregamento da lógica de filtragem para o chipset Bluetooth ao implementar a API ScanFilter.
DEVE oferecer suporte ao descarregamento da leitura em lote para o chipset Bluetooth.
DEVE ser compatível com vários anúncios com pelo menos quatro espaços.
Se as implementações de dispositivos forem compatíveis com Bluetooth LE e usarem Bluetooth LE para verificação de local, eles:
- [C-4-1] PRECISA fornecer uma funcionalidade do usuário para ativar/desativar a leitura de valor.
pela API do sistema
BluetoothAdapter.isBleScanAlwaysAvailable()
.
Se as implementações de dispositivos incluem suporte a Bluetooth LE e aparelhos auditivos do seu perfil, conforme descrito em Suporte para áudio de aparelho auditivo usando Bluetooth LE, eles:
- [C-5-1] PRECISA retornar
true
para BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).
Se as implementações de dispositivos incluírem suporte a Bluetooth ou Bluetooth de baixa energia (BLE), eles:
- [C-6-1] PRECISA restringir o acesso a metadados Bluetooth (como leitura
resultados) que podem ser usados para obter a localização do dispositivo, a menos que
O app solicitante transmite um
android.permission.ACCESS_FINE_LOCATION
verificação de permissão com base no estado atual em primeiro/segundo plano.
Se as implementações do dispositivo incluem suporte a Bluetooth ou Bluetooth de baixa energia (BLE) e o manifesto do app não incluir uma declaração do desenvolvedor informando se não estão derivando a localização por Bluetooth, então, eles:
- [C-6-2] PRECISA bloquear o acesso ao Bluetooth atrás do
android.permission.ACCESS_FINE_LOCATION
.
Se as implementações de dispositivos retornarem true
para o
API BluetoothAdapter.isLeAudioSupported()
, eles:
- [C-7-1] PRECISA oferecer suporte ao cliente unicast.
- [C-7-2] PRECISA oferecer suporte a 2 milhões de PHY.
- [C-7-3] PRECISA oferecer suporte à publicidade estendida de LE.
- [C-7-4] PRECISA oferecer suporte a pelo menos duas conexões CIS em um CIG.
- [C-7-5] É NECESSÁRIO habilitar o cliente BAP unicast, o coordenador de conjunto CSIP, o servidor MCP Controlador VCP e servidor CCP simultaneamente.
- [C-SR-1] É FORTEMENTE RECOMENDADO para ativar o cliente unicast HAP.
Se as implementações de dispositivos retornarem true
para o
API BluetoothAdapter.isLeAudioBroadcastSourceSupported()
, eles:
- [C-8-1] PRECISA oferecer suporte a pelo menos dois links BIS em uma GRANDE.
- [C-8-2] É NECESSÁRIO ativar a fonte de transmissão BAP e o assistente de transmissão BAP ao mesmo tempo.
- [C-8-3] PRECISA oferecer suporte à publicidade LE Periodic.
Se as implementações de dispositivos retornarem true
para o
API BluetoothAdapter.isLeAudioBroadcastAssistantSupported()
, eles:
- [C-9-1] PRECISA oferecer suporte a PAST (Transferência periódica de sincronização de publicidade).
- [C-9-2] PRECISA oferecer suporte à publicidade LE Periodic.
Se as implementações de dispositivo declararem FEATURE_BLUETOOTH_LE
, elas:
- [C-10-1] PRECISA ter medições de RSSI dentro de +/-9 dB para 95% dos
medidas a 1 m de distância de um dispositivo de referência que transmite a
ADVERTISE_TX_POWER_HIGH
no ambiente de linha de visão. [C-10-2] PRECISA incluir correções de Rx/Tx para reduzir os desvios por canal. para que as medidas em cada um dos três canais, em cada uma das antenas (se forem usados vários), estão dentro de +/-3 dB entre si por 95% do medições.
[C-SR-2] É FORTEMENTE RECOMENDADO para medir e compensar o deslocamento de Rx para garantir que o RSSI médio do BLE seja -60 dBm +/-10 dB a 1 m de distância de um transmissão de dispositivo de referência em
ADVERTISE_TX_POWER_HIGH
, onde os dispositivos são são orientados de forma que estejam em "planos paralelos" com telas voltadas para o mesmo direção[C-SR-3] É FORTEMENTE RECOMENDADO para medir e compensar o deslocamento de transação para garantir que o RSSI do BLE médio seja de -60 dBm +/-10 dB ao verificar uma referência dispositivo posicionado a 1 m de distância e transmitindo a
ADVERTISE_TX_POWER_HIGH
, em que os dispositivos são orientados de modo que estejam "planos paralelos" com telas voltadas para a mesma direçã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 de Rx para
garantir que o RSSI do BLE médio seja -55 dBm +/-10 dB a 1 m de distância de um
dispositivo de referência de transmissão 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 de -55 dBm +/-10 dB ao verificar uma referência
dispositivo posicionado a 1 m de distância e transmitindo a
ADVERTISE_TX_POWER_HIGH
:
É RECOMENDADO seguir as etapas de configuração de medição especificadas no Requisitos para a calibragem de presença.
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 e papéis de topologia de conexão.
- Privacidade da camada de links do LE
- Uma "lista de resolução" de pelo menos oito entradas
7.4.4. Comunicação a curta distância (NFC, na sigla em inglês)
Implementações de dispositivos:
- DEVE incluir um transceptor e hardware relacionado para o recurso Near-Field Comunicações (NFC, na sigla em inglês).
- [C-0-1] PRECISA implementar
android.nfc.NdefMessage
e APIs doandroid.nfc.NdefRecord
mesmo que não incluam suporte para NFC ou declarar o recursoandroid.hardware.nfc
, já que as classes representam formato de representação de dados independente de protocolo.
Se as implementações de dispositivos incluem hardware NFC e planeja disponibilizá-lo para apps de terceiros, ela:
- [C-1-1] PRECISA informar o recurso
android.hardware.nfc
da métodoandroid.content.pm.PackageManager.hasSystemFeature()
. - PRECISA ser capaz de ler e gravar mensagens NDEF usando as seguintes tecnologias NFC padrão, conforme abaixo:
- [C-1-2] PRECISA atuar como leitor/gravador do Fórum NFC
(conforme definido pelas especificações técnicas do NFC Forum
NFCForum-TS-Digital Protocol-1.0) por meio dos seguintes padrões NFC:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6.319-4)
- IsoDep (ISO 14443-4)
- Tipos de tags do fórum NFC 1, 2, 3, 4, 5 (definidos pelo fórum NFC)
[C-SR-1] É FORTEMENTE RECOMENDADO que precisa ler e gravar NDEF mensagens, bem como dados brutos por meio dos seguintes padrões NFC. Observe que enquanto os padrões NFC forem indicados como FORTEMENTE RECOMENDADOS, os A definição de compatibilidade para uma versão futura está planejada para alterar estas como PRECISA. Esses padrões são opcionais nesta versão, mas serão obrigatórios em versões futuras. Dispositivos novos e existentes que executam esta versão do Recomendamos que o Android atenda a esses requisitos. poderão fazer upgrade para as próximas versões da plataforma.
[C-1-13] PRECISA pesquisar todas as tecnologias compatíveis durante a descoberta NFC modo
DEVE estar no modo de descoberta NFC enquanto o dispositivo estiver ativado com o tela ativa e a tela de bloqueio desbloqueada.
DEVE ser capaz de ler o código de barras e o URL (se codificado) de Código de barras NFC Thinfilm produtos.
Observe que links disponíveis publicamente não estão disponíveis para as especificações JIS, ISO e NFC Especificações do fórum citadas acima.
O Android inclui suporte ao modo de emulação de cartão host de NFC (HCE, na sigla em inglês).
Se as implementações de dispositivos incluírem um chipset controlador NFC capaz de HCE (por NfcA e/ou NfcB) e que aceitam roteamento de ID do aplicativo (AID), elas:
- [C-2-1] PRECISA informar a constante de recurso
android.hardware.nfc.hce
. - [C-2-2] PRECISA oferecer suporte a APIs NFC HCE como definido no SDK do Android.
Se as implementações de dispositivos incluírem um chipset controlador NFC compatível com HCE para NfcF e implementar o recurso para aplicativos de terceiros, eles:
- [C-3-1] PRECISA informar a constante de recurso
android.hardware.nfc.hcef
. - [C-3-2] PRECISA implementar as APIs de emulação de cartão NFC conforme definido no SDK do Android.
Caso as implementações de dispositivos incluam suporte geral a NFC, conforme descrito neste e oferecer suporte a tecnologias MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF no MIFARE Classic) na função de leitor/gravador, eles:
- [C-4-1] PRECISA implementar as APIs do Android correspondentes, conforme documentado por SDK do Android.
- [C-4-2] PRECISA informar o recurso
com.nxp.mifare
daandroid.content.pm.PackageManager.hasSystemFeature
() . Esse não é um recurso padrão do Android e, portanto, não aparecem como uma constante na classeandroid.content.pm.PackageManager
.
7.4.5. APIs e protocolos de rede
7.4.5.1. Capacidade mínima de rede
Implementações de dispositivos:
- [C-0-1] PRECISA incluir suporte para uma ou mais formas de nas redes de dados. Especificamente, as implementações de dispositivos PRECISAM incluir suporte para pelo menos um padrão de dados com capacidade de 200 Kbit/s ou mais. Exemplos de tecnologias que atendem a esse requisito incluem EDGE, HSPA, EV-DO, 802.11g, Ethernet e PAN com Bluetooth.
- Também DEVE incluir suporte para pelo menos um sistema de dados sem fio como o 802.11 (Wi-Fi), quando um padrão de rede física Ethernet) é a principal conexão de dados.
- PODE implementar mais de uma forma de conectividade de dados.
7.4.5.2. IPv6
Implementações de dispositivos:
- [C-0-2] PRECISA incluir uma pilha de rede IPv6 e oferecer suporte a IPv6
comunicação usando as APIs gerenciadas, como
java.net.Socket
ejava.net.URLConnection
, além das APIs nativas, comoAF_INET6
soquetes. - [C-0-3] PRECISA ativar o IPv6 por padrão.
- PRECISA garantir que a comunicação do IPv6 seja tão confiável quanto do IPv4, por exemplo:
- [C-0-4] PRECISA manter a conectividade IPv6 no modo Soneca.
- [C-0-5] A limitação de taxa NÃO PODE fazer com que o dispositivo perca o IPv6 conectividade em qualquer rede compatível com IPv6 que use ciclos de vida de RA de de pelo menos 180 segundos.
- PRECISA garantir que a comunicação do IPv6 seja tão confiável quanto do IPv4, por exemplo:
- [C-0-6] PRECISA fornecer aplicativos de terceiros com conectividade IPv6 direta
à rede quando conectado a uma rede IPv6, sem qualquer forma de endereço ou
a conversão de portas ocorre localmente no dispositivo. As duas APIs gerenciadas, como
Socket#getLocalAddress
ouSocket#getLocalPort
) e as APIs do NDK, comogetsockname()
ouIPV6_PKTINFO
, PRECISAM retornar o IP e porta que é realmente usado para enviar e receber pacotes na e visível como o IP de origem e a porta para servidores de Internet (Web).
O nível necessário de suporte a IPv6 depende do tipo de rede, como mostrado no os requisitos a seguir.
Se as implementações de dispositivos forem compatíveis com Wi-Fi, elas:
- [C-1-1] PRECISA oferecer suporte à operação de pilha dupla e somente IPv6 no Wi-Fi.
Se as implementações de dispositivos forem compatíveis com Ethernet, elas:
- [C-2-1] PRECISA oferecer suporte à operação de pilha dupla e somente IPv6 Ethernet.
Se as implementações de dispositivos forem compatíveis com dados móveis, elas:
- [C-3-1] PRECISA oferecer suporte à operação IPv6 (somente IPv6 e possivelmente de pilha dupla) ativada rede celular.
Se as implementações de dispositivos oferecem suporte a mais de um tipo de rede (por exemplo, Wi-Fi e dados móveis), eles:
- [C-4-1] PRECISA cumprir simultaneamente os requisitos acima em cada rede quando o dispositivo está conectado simultaneamente a mais de um tipo de rede.
7.4.5.3. Portais cativos
Um portal cativo se refere a uma rede que exige login para ter acesso à Internet.
Se as implementações de dispositivos fornecerem uma implementação completa do
android.webkit.Webview API
,
eles:
- [C-1-1] PRECISA fornecer um aplicativo de portal cativo para lidar com a intent
ACTION_CAPTIVE_PORTAL_SIGN_IN
e exibir a página de login do portal cativo enviando essa intent chamada para a API do sistemaConnectivityManager#startCaptivePortalApp(Network, Bundle)
. - [C-1-2] É NECESSÁRIO detectar os portais cativos e fazer login de suporte pelo aplicativo de portal cativo quando o dispositivo estiver conectado a qualquer tipo de rede, incluindo celular/móvel, Wi-Fi, Ethernet ou Bluetooth.
- [C-1-3] PRECISA oferecer suporte ao login em portais cativos usando DNS de texto não criptografado quando o dispositivo está configurado para usar o modo restrito de DNS particular.
- [C-1-4] PRECISA usar DNS criptografado, de acordo com a documentação do SDK,
android.net.LinkProperties.getPrivateDnsServerName
eandroid.net.LinkProperties.isPrivateDnsActive
todo o tráfego de rede que não está se comunicando explicitamente com o portal cativo. - [C-1-5] PRECISA garantir que, enquanto o usuário fizer login em um
do portal, a rede padrão usada por aplicativos (conforme retornado pelo
ConnectivityManager.getActiveNetwork
,ConnectivityManager.registerDefaultNetworkCallback
, e usada por padrão por APIs de rede Java, como java.net.Socket, e APIs nativas, como connect()) é qualquer outra rede disponível que fornece acesso à Internet, se disponível.
7.4.6. Configurações de sincronização
Implementações de dispositivos:
- [C-0-1] PRECISA manter a configuração de sincronização automática principal ativada por padrão para que
o método
getMasterSyncAutomatically()
retorna "true".
7.4.7. Economia de dados
Se as implementações de dispositivos incluírem uma conexão limitada, elas serão:
- [C-SR-1] É MUITO RECOMENDADO fornecer o modo de economia de dados.
Se as implementações de dispositivos oferecerem o modo de economia de dados, elas:
- [C-1-1] PRECISA oferecer suporte a todas as APIs do
ConnectivityManager
. conforme descrito na documentação do SDK
Se as implementações de dispositivos não oferecerem o modo de economia de dados, elas:
- [C-2-1] PRECISA retornar o valor
RESTRICT_BACKGROUND_STATUS_DISABLED
paraConnectivityManager.getRestrictBackgroundStatus()
- [C-2-2] NÃO PODE transmitir
ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED
:
7.4.8. Elementos de segurança
Se as implementações de dispositivos forem compatíveis com a API Open Mobile elementos de segurança e disponibilizá-los para aplicativos de terceiros, eles:
[C-1-1] PRECISA enumerar os leitores de elementos de segurança disponíveis usando API
android.se.omapi.SEService.getReaders()
.[C-1-2] PRECISA declarar as flags de recurso corretas usando o
android.hardware.se.omapi.uicc
para o dispositivo com elementos de segurança baseados em UICC,android.hardware.se.omapi.ese
para o dispositivo com elementos de segurança baseados em eSE eandroid.hardware.se.omapi.sd
para o dispositivo com elementos de segurança baseados em SD.
7.4.9. UWB
Se as implementações de dispositivos tiverem suporte para 802.1.15.4 e expor a funcionalidade a um aplicativo de terceiros, então eles:
- [C-1-1] PRECISA implementar a API do Android correspondente no android.uwb.
- [C-1-2] PRECISA informar a flag de recurso de hardware android.hardware.uwb.
- [C-1-3] PRECISA oferecer suporte a todos os perfis de UWB relevantes definidos no Android. implementação.
- [C-1-4] PRECISA fornecer uma funcionalidade de usuário para permitir que ele alterne a UWB. ativado/desativado do rádio.
- [C-1-5] PRECISA exigir que os apps que usam o recurso UWB mantenham a permissão UWB_RANGING (no grupo de permissões NEARBY_DEVICE).
- [C-SR-1] É FORTEMENTE RECOMENDADO para passar na conformidade e de certificação definidos por organizações padrão, incluindo FIRA e CCC e CSA.
- [C-1-6] PRECISA garantir que as medidas de distância estejam dentro de +/-15 cm para 95% das medidas no ambiente da linha de visão a 1 m de distância em um câmara não reflexiva.
- [C-1-7] PRECISA garantir que a mediana das medidas de distância a 1 m
do dispositivo de referência está dentro de [0,75 m, 1,25 m], onde as informações empíricas
a distância é medida a partir da borda superior do DUT.
Com a face voltada para cima e inclinada 45 graus. - [C-SR-2] É FORTEMENTE RECOMENDADO seguir as etapas de configuração da medição especificado em Requisitos para a calibragem de presença.
7,5. Cameras
Se as implementações de dispositivos incluírem pelo menos uma câmera, elas:
- [C-1-1] PRECISA declarar a flag de recurso
android.hardware.camera.any
. - [C-1-2] PRECISA ser possível para um aplicativo alocar simultaneamente 3 bitmaps RGBA_8888 iguais ao tamanho das imagens produzidas pelo com a maior resolução do dispositivo, enquanto a câmera está aberta para o finalidade da visualização básica e ainda capturar.
- [C-1-3] PRECISA garantir que o aplicativo padrão de câmera pré-instalado
como processar intents
MediaStore.ACTION_IMAGE_CAPTURE
;MediaStore.ACTION_IMAGE_CAPTURE_SECURE
, ouMediaStore.ACTION_VIDEO_CAPTURE
, é responsável por remover a localização do usuário nos metadados da imagem antes enviá-lo para o aplicativo receptor quando o aplicativo receptor têmACCESS_FINE_LOCATION
.
Se as implementações de dispositivos forem compatíveis com a capacidade de saída HDR de 10 bits, elas:
- [C-2-1] PRECISA oferecer suporte pelo menos ao perfil HDR HLG em todos os dispositivos de câmera. com suporte a saída de 10 bits.
- [C-2-2] PRECISA oferecer suporte à saída de 10 bits para a interface traseira principal ou pela câmera frontal principal.
- [C-SR-1] É FORTEMENTE RECOMENDADO oferecer suporte à saída de 10 bits para o primário câmeras.
- [C-2-3] PRECISA oferecer suporte aos mesmos perfis HDR para todos BACKWARD_COMPATIBLE subcâmeras físicas de uma câmera lógica e a própria câmera lógica.
Para dispositivos de câmera lógica com suporte a HDR de 10 bits que implementam
API android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO
, eles:
- [C-3-1] PRECISA oferecer suporte à alternância entre todas as redes físicas compatíveis com versões anteriores
câmeras pelo controle
CONTROL_ZOOM_RATIO
na câmera lógica.
7.5.1. Câmera traseira
Uma câmera traseira é uma câmera localizada na lateral de o dispositivo em frente à tela; ou seja, ela retrata cenas do outro lado no dispositivo, como uma câmera tradicional.
Iniciar novos requisitos
Uma câmera traseira é uma câmera voltada para o mundo que captura cenas do outro lado do dispositivo, como uma câmera tradicional; em dispositivos portáteis, localizado na lateral do dispositivo em frente à tela.
Encerrar novos requisitos
Implementações de dispositivos:
- DEVE incluir uma câmera traseira.
Se as implementações de dispositivos incluírem pelo menos uma câmera traseira, elas:
- [C-1-1] PRECISA informar a flag de recurso
android.hardware.camera
eandroid.hardware.camera.any
. - [C-1-2] PRECISA ter uma resolução de pelo menos 2 megapixels.
- DEVE ter o foco automático em hardware ou em software implementado no driver da câmera (transparente ao software do aplicativo).
- PODE ter hardware de foco fixo ou EDOF (profundidade de campo estendida).
- PODE incluir um flash.
Se a câmera tiver flash:
- [C-2-1] a lâmpada do flash NÃO PODE estar acesa enquanto um
android.hardware.Camera.PreviewCallback
instância foi registrada em uma superfície de visualização da Câmera, a menos que o aplicativo tenha ativado o flash ativando os atributosFLASH_MODE_AUTO
ouFLASH_MODE_ON
de um objetoCamera.Parameters
. Essa restrição não se aplica ao aplicativo integrado de câmera do sistema do dispositivo, mas somente aplicativos usandoCamera.PreviewCallback
.
7.5.2. Câmera frontal
Uma câmera frontal é aquela localizada no mesmo lado do dispositivo como a tela, ou seja, uma câmera normalmente usada para imagens do usuário, como videoconferência e outros aplicativos semelhantes.
Iniciar novos requisitos
Uma câmera frontal é uma câmera voltada ao usuário que normalmente é usada para imagens o usuário, como para videoconferências e aplicativos semelhantes; no portátil dispositivos, que é uma câmera localizada no mesmo lado do dispositivo que a tela.
Encerrar novos requisitos
Implementações de dispositivos:
- PODE incluir uma câmera frontal.
Se as implementações de dispositivos incluírem pelo menos uma câmera frontal, elas:
- [C-1-1] PRECISA informar a flag de recurso
android.hardware.camera.any
eandroid.hardware.camera.front
. - [C-1-2] PRECISA ter uma resolução de pelo menos VGA (640 x 480 pixels).
- [C-1-3] NÃO PODE usar uma câmera frontal como padrão para o Camera e NÃO PODE configurar a API para tratar uma câmera frontal como a câmera traseira padrão, mesmo que ela seja a única do dispositivo.
- [C-1-4] A visualização da câmera PRECISA ser espelhada horizontalmente em relação à
orientação especificada pelo aplicativo quando o aplicativo atual tem
solicitou explicitamente que a câmera
ser girada por meio de uma chamada para o
android.hardware.Camera.setDisplayOrientation()
. Por outro lado, a prévia PRECISA ser espelhada na imagem padrão do dispositivo. eixo horizontal quando o aplicativo atual não solicita explicitamente que o visor da câmera seja girado por meio de uma chamada aoandroid.hardware.Camera.setDisplayOrientation()
. - [C-1-5] NÃO É POSSÍVEL espelhar a imagem estática final ou os streams de vídeo capturados retornados aos callbacks de aplicativos ou confirmados com o armazenamento de mídia.
- [C-1-6] PRECISA espelhar a imagem exibida pelo pós-visualização da mesma maneira como o stream de imagem de visualização da câmera.
- PODE incluir recursos (como autofoco, flash etc.) disponíveis para câmeras traseiras, conforme descrito na seção 7.5.1.
Se as implementações do dispositivo puderem ser rotacionadas pelo usuário (como automaticamente por meio de um acelerômetro ou manualmente por entrada do usuário):
- [C-2-1] A visualização da câmera PRECISA ser espelhada horizontalmente em relação à a orientação atual do dispositivo.
7.5.3. Câmera externa
Iniciar novos requisitos
Uma câmera externa pode ser conectada ou desconectada fisicamente a implementação do dispositivo a qualquer momento e pode estar voltada para qualquer direção; como USB câmeras.
Encerrar novos requisitos
Implementações de dispositivos:
- PODE incluir suporte para uma câmera externa que não seja necessariamente sempre conectados.
Se as implementações de dispositivos forem compatíveis com uma câmera externa, elas:
- [C-1-1] PRECISA declarar a flag de recurso da plataforma
android.hardware.camera.external
eandroid.hardware camera.any
. - [C-1-2] DEVE oferecer suporte à classe de vídeo USB (UVC 1.0 ou superior) se o a câmera se conecta pela porta do host USB.
- [C-1-3] PRECISA passar nos testes de CTS da câmera com um dispositivo físico externo de câmera conectados. Detalhes dos testes CTS da câmera estão disponíveis em source.android.com.
- DEVE oferecer suporte a compactação de vídeo, como MJPEG, para permitir a transferência de transmissões não codificadas de alta qualidade (por exemplo, imagens brutas ou com compactação independente córregos).
- PODE oferecer suporte a várias câmeras.
- PODE oferecer suporte à codificação de vídeo baseada em câmera.
Se a codificação de vídeo baseada na câmera for compatível:
- [C-2-1] Uma simultaneidade uma transmissão não codificada / MJPEG (QVGA ou resolução superior) PRECISA estar acessível a a implementação do dispositivo.
7.5.4. Comportamento da API Camera
O Android inclui dois pacotes de API para acessar a câmera, a mais recente A API android.hardware.camera2 expõe o controle da câmera de nível inferior ao app, incluindo fluxos de burst/streaming de cópia zero eficientes e controles por frame do exposição, ganho, ganhos de balanço de branco, conversão de cor, remoção de ruído, nitidez, e muito mais.
O pacote de API mais antigo,android.hardware.Camera
, está marcado como descontinuado em
Android 5.0, mas ainda deve estar disponível para uso dos apps. Dispositivo Android
implementações PRECISAM garantir o suporte contínuo da API, conforme descrito em
nesta seção e no SDK do Android.
Todos os recursos comuns entre a classe descontinuada android.hardware.Camera e o pacote android.hardware.camera2 mais recente PRECISA ter desempenho equivalente e qualidade nas duas APIs. Por exemplo, com configurações equivalentes, a velocidade e a precisão do autofoco devem ser idênticas, e a qualidade das imagens capturadas devem ser iguais. Recursos que dependem da semântica diferente das duas APIs não precisam ter velocidade ou qualidade correspondentes, mas DEVEM ser o mais possível.
As implementações de dispositivos PRECISAM implementar os seguintes comportamentos para os APIs relacionadas à câmera para todas as câmeras disponíveis. Implementações de dispositivos:
- [C-0-1] É NECESSÁRIO usar
android.hardware.PixelFormat.YCbCr_420_SP
para visualização dados fornecidos aos callbacks de aplicativo quando um aplicativo nunca chamouandroid.hardware.Camera.Parameters.setPreviewFormat(int)
. - [C-0-2] PRECISA estar no formato de codificação NV21 quando um aplicativo
registra um
android.hardware.Camera.PreviewCallback
instância e o sistema chama o métodoonPreviewFrame()
, e o comando formato for YCbCr_420_SP, os dados no byte[] transmitidos paraonPreviewFrame()
. Ou seja, NV21 PRECISA ser o padrão. - [C-0-3] PRECISA oferecer suporte ao formato YV12 (conforme indicado pelo
android.graphics.ImageFormat.YV12
) para visualizações de câmera para ambos. câmeras frontal e traseira paraandroid.hardware.Camera
. (O hardware o codificador de vídeo e a câmera podem usar qualquer formato de pixel nativo, mas o dispositivo implementação PRECISA ser compatível com a conversão para YV12.) - [C-0-4] PRECISA oferecer suporte às APIs
android.hardware.ImageFormat.YUV_420_888
eandroid.hardware.ImageFormat.JPEG
formata como saídas usando o APIandroid.media.ImageReader
para dispositivosandroid.hardware.camera2
que anunciarREQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE
emandroid.request.availableCapabilities
. - [C-0-5] Ainda PRECISA implementar a API Camera completa.
estão incluídos na documentação do SDK do Android, mesmo que o dispositivo
inclui autofoco em hardware ou outros recursos. Por exemplo, câmeras que
sem o autofoco PRECISA chamar as campanhas
android.hardware.Camera.AutoFocusCallback
instâncias (mesmo que não tenham relevância para uma câmera sem foco automático. Isso se aplica a casos de uso câmeras; por exemplo, embora a maioria das câmeras frontal não suportem autofoco, os callbacks de API ainda precisam ser "falsos", conforme descrito. - [C-0-6] PRECISA reconhecer e respeitar os nomes de cada parâmetro.
definida como uma constante
android.hardware.Camera.Parameters
e a classeandroid.hardware.camera2.CaptureRequest
. Por outro lado, as implementações de dispositivos NÃO PODEM respeitar ou reconhecer constantes de string transmitidos para o métodoandroid.hardware.Camera.setParameters()
diferentes dos documentadas como constantes noandroid.hardware.Camera.Parameters
. Ou seja, as implementações de dispositivos PRECISAM oferecer suporte a todos os parâmetros padrão de câmera se o o hardware permite e NÃO PODE oferecer suporte a tipos personalizados de parâmetros de câmera. Por exemplo, implementações de dispositivos compatíveis com a captura de imagem que usam técnicas de geração de imagens de High Dynamic Range (HDR) PRECISAM oferecer suporte ao parâmetro de câmera.Camera.SCENE_MODE_HDR
: - [C-0-7] PRECISA informar o nível adequado de suporte com o
android.info.supportedHardwareLevel
, conforme descrito no SDK do Android e informe a propriedade sinalizações de recursos do framework. - [C-0-8] PRECISA declarar também as capacidades individuais da câmera de
android.hardware.camera2
peloandroid.request.availableCapabilities
propriedade e declarar as flags de recurso adequadas. PRECISA definir a flag de recurso se alguma câmera estiver conectada oferece suporte ao recurso. - [C-0-9] PRECISA transmitir o
Camera.ACTION_NEW_PICTURE
. intenção sempre que uma nova foto é tirada pela câmera e a entrada do imagem foi adicionada ao armazenamento de mídia. - [C-0-10] PRECISA transmitir o
Camera.ACTION_NEW_VIDEO
. intenção sempre que um novo vídeo for gravado pela câmera e a entrada do imagem foi adicionada ao armazenamento de mídia. - [C-0-11] PRECISA ter todas as câmeras acessíveis com a versão descontinuada
android.hardware.Camera
API também acessível viaandroid.hardware.camera2
API. - [C-0-12] PRECISA garantir que a aparência facial NÃO seja alterada, incluindo
a alteração da geometria facial, do tom de pele facial
suavização de pele para qualquer
android.hardware.camera2
ouandroid.hardware.Camera
API. - [C-SR-1] Para dispositivos com várias câmeras RGB no
perto e virados na mesma direção,
é FORTEMENTE RECOMENDADO oferecer suporte a um dispositivo de câmera lógico que liste
capacidade
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
, e consiste em todas as câmeras RGB voltadas para essa direção como subdispositivos físicos.
Se as implementações do dispositivo fornecerem uma API de câmera reservada para apps de terceiros, eles:
- [C-1-1] PRECISA implementar essa API de câmera usando
android.hardware.camera2
. API. - PODE fornecer tags e/ou extensões do fornecedor para
android.hardware.camera2
API.
7.5.5. Orientação da câmera
Se as implementações do dispositivo tiverem uma câmera frontal ou traseira, tais câmeras:
- [C-1-1] PRECISA estar orientada de modo que a dimensão longa da câmera se alinhe com a dimensão longa da tela. Ou seja, quando o dispositivo é mantido no modo paisagem as câmeras PRECISAM capturar imagens na orientação paisagem. Isso se aplica independentemente da orientação natural do dispositivo; ou seja, ela se aplica dispositivos principais no modo paisagem e dispositivos principais no modo retrato.
Os dispositivos que atenderem a todos os critérios a seguir estão isentos do requisito acima:
- O dispositivo implementa telas de geometria variável, como dobráveis ou articuladas. é exibido.
- Quando o estado da dobra ou articulação do dispositivo muda, ele alterna entre orientação retrato principal para paisagem principal (ou vice-versa).
Iniciar novos requisitos
- Implementações de dispositivo que não podem ser rotacionadas pelo usuário, como como dispositivos automotivos.
Encerrar novos requisitos
7,6. Memória e armazenamento
7.6.1. Mínimo de memória e armazenamento
Implementações de dispositivos:
- [C-0-1] PRECISA incluir um Gerenciador de downloads que os aplicativos PODEM usar para baixar arquivos de dados e DEVEM ser capazes de o download de arquivos individuais de pelo menos 100 MB para o padrão "cache" o local.
7.6.2. Armazenamento compartilhado do aplicativo
Implementações de dispositivos:
- [C-0-1] PRECISA oferecer armazenamento para ser compartilhado por aplicativos, também conhecidos como como "armazenamento externo compartilhado", "armazenamento compartilhado do app" ou pelo serviço Linux Caminho "/sdcard" em que ele é montado.
- [C-0-2] PRECISA ser configurado com armazenamento compartilhado montado por padrão, em outros "pronto para uso", independentemente de o armazenamento ter sido implementado um componente de armazenamento interno ou uma mídia de armazenamento removível (por exemplo, Secure slot para cartão digital).
- [C-0-3] É NECESSÁRIO montar o armazenamento compartilhado do aplicativo diretamente no caminho do Linux
sdcard
ou inclua um link simbólico do Linux desdcard
para a montagem real. ponto - [C-0-4] É NECESSÁRIO ativar
armazenamento com escopo
por padrão para todas
Aplicativos direcionados ao nível de API 29 ou superior, exceto nas seguintes situações:
- Quando o app solicitar
android:requestLegacyExternalStorage="true"
no manifesto.
- Quando o app solicitar
- [C-0-5] PRECISA encobrir os metadados de local, como as tags GPS Exif, armazenados em
arquivos de mídia quando esses arquivos forem acessados pelo
MediaStore
, exceto quando o app de chamada tem a permissãoACCESS_MEDIA_LOCATION
.
As implementações de dispositivos PODEM atender aos requisitos acima usando um dos seguintes:
- Armazenamento removível acessível pelo usuário, como um slot para cartão SD.
- Uma parte do armazenamento interno (não removível) conforme implementado no Android Open Source Project (AOSP).
Se as implementações do dispositivo usarem armazenamento removível para atender aos requisitos acima requisitos, eles:
- [C-1-1] PRECISA implementar um aviso ou uma interface pop-up que avisa o usuário quando não há mídia de armazenamento inserida no slot.
- [C-1-2] PRECISA incluir um programa ou mídia de armazenamento com formato FAT (por exemplo, cartão SD) na caixa e em outros materiais disponíveis no momento da compra que o armazenamento mídia deve ser adquirida separadamente.
Se as implementações de dispositivos usarem uma parte do armazenamento não removível para atender os requisitos acima, eles:
- DEVE usar a implementação do AOSP do app interno compartilhado armazenamento.
- PODE compartilhar o espaço de armazenamento com os dados privados do aplicativo.
Se as implementações de dispositivos tiverem uma porta USB com suporte ao modo de periférico USB, eles:
- [C-3-1] PRECISA fornecer um mecanismo para acessar os dados no aplicativo o armazenamento compartilhado em um computador host.
- DEVE expor o conteúdo de ambos os caminhos de armazenamento de forma transparente por meio de
Serviço de verificação de mídia do Android e
android.provider.MediaStore
. - PODE usar armazenamento USB em massa, mas DEVE usar Media Transfer Protocol para satisfazer esse requisito.
Se as implementações de dispositivos tiverem uma porta USB com suporte e modo de periférico USB Media Transfer Protocol, eles:
- DEVE ser compatível com o host do Android MTP de referência, Transferência de arquivos do Android.
- DEVE informar uma classe de dispositivo USB de 0x00.
- DEVE informar um nome de interface USB de "MTP".
7.6.3. Armazenamento adotável
Se se espera que o dispositivo seja móvel por natureza, diferentemente da televisão, implementações de dispositivos são:
- [C-SR-1] É MUITO RECOMENDADO implementar o armazenamento adotável na um local estável de longo prazo, já que desconectá-los acidentalmente pode causar perda/corrupção de dados.
Se a porta do dispositivo de armazenamento removível estiver em um local estável de longo prazo, como no compartimento da bateria ou em outra tampa de proteção, implementações de dispositivos são:
- [C-SR-2] MUITO RECOMENDADO para implementar armazenamento adotável.
7,7. USB
Se as implementações de dispositivos tiverem uma porta USB, elas:
- DEVE oferecer suporte ao modo de periférico USB e DEVE oferecer suporte ao modo host USB.
- DEVE ser compatível com a desativação da sinalização de dados por USB.
7.7.1. Modo USB periférico
Se as implementações de dispositivos incluírem uma porta USB compatível com o modo de periféricos:
- [C-1-1] A porta PRECISA estar conectada a um host USB com padrão uma porta USB tipo A ou C.
- [C-1-2] PRECISA informar o valor correto de
iSerialNumber
no padrão USB. descritor do dispositivo usandoandroid.os.Build.SERIAL
. - [C-1-3] PRECISA detectar carregadores de 1,5 A e 3,0 A pelo resistor tipo C. padrão e PRECISA detectar as alterações no anúncio, caso sejam compatíveis USB-C.
- [C-SR-1] A porta DEVE usar o formato USB micro-B, micro-AB ou tipo C. É altamente RECOMENDADO dispositivos Android novos e já existentes para atender a esses requisitos requisitos para que possam fazer upgrade para as versões futuras da plataforma.
- [C-SR-2] A porta DEVE estar localizada na parte de baixo do dispositivo (de acordo com a orientação natural) ou ativar a rotação da tela do software para todos os apps (incluindo a tela inicial), para que a tela desenhe corretamente quando o dispositivo está orientado com a porta na parte inferior. Android atual e novo dispositivos são AVALIMENTE RECOMENDADOS para atender a esses requisitos para que atualizar para futuras versões da plataforma.
- [C-SR-3] DEVE implementar suporte para puxar corrente de 1,5 A durante o sinal de HS e o tráfego, conforme especificado na Especificação de carregamento de bateria USB, revisão 1.2. É altamente RECOMENDADO dispositivos Android novos e já existentes para atender a esses requisitos requisitos para que possam fazer upgrade para as versões futuras da plataforma.
- [C-SR-4] É FORTEMENTE RECOMENDADO não oferecer suporte a proprietários que modificam a tensão Vbus além dos níveis padrão ou alteram de coletor/origem, dessa forma, podem causar problemas de interoperabilidade com o carregadores ou dispositivos que oferecem suporte aos métodos padrão de fornecimento de energia USB. isso é chamado de " FORTEMENTE RECOMENDADO". Em versões futuras do Android, pode EXIGIR todos os dispositivos tipo C para oferecer suporte à interoperabilidade total com carregadores tipo C.
- [C-SR-5] É MUITO RECOMENDADO oferecer suporte ao Power Delivery para dados e troca de função de energia quando eles forem compatíveis com os modos de host USB e USB Type-C.
- DEVE oferecer suporte ao Power Delivery para carregamento de alta tensão e suporte para Modos alternativos, como exibição externa.
- DEVE implementar a API e a especificação do Android Open Accessory (AOA) na documentação do SDK do Android.
Se as implementações de dispositivos incluem uma porta USB e implementam a AOA especificação, eles:
- [C-2-1] PRECISA declarar suporte ao recurso de hardware
android.hardware.usb.accessory
- [C-2-2] A classe de armazenamento em massa USB PRECISA incluir a string "android" no
fim da string de descrição da interface
iInterface
do armazenamento USB em massa
7.7.2. Modo host USB
Se as implementações de dispositivos incluírem uma porta USB compatível com o modo host, elas:
- [C-1-1] PRECISA implementar a API de host USB do Android, conforme documentado nas
SDK do Android e PRECISA declarar suporte para o recurso de hardware
android.hardware.usb.host
- [C-1-2] É NECESSÁRIO implementar suporte para conectar periféricos USB padrão
Em outras palavras, eles PRECISAM:
- Ter uma porta tipo C no dispositivo ou enviar com cabos que se adaptam a um dispositivo para uma porta USB-C padrão (dispositivo USB-C).
- Ter um dispositivo tipo A ou enviar com cabos adaptados a um dispositivo para uma porta USB-A padrão.
- Ter uma porta micro-AB no dispositivo, que DEVE ser enviada com um cabo adaptativo para uma porta padrão tipo A.
- [C-1-3] NÃO PODE enviar com um adaptador que converta de USB tipo A ou Portas micro-AB para uma porta tipo C (receptáculo).
- [C-SR-1] É FORTEMENTE RECOMENDADO para implementar a Classe de áudio USB conforme documentado na documentação do SDK do Android.
- DEVE oferecer suporte ao carregamento do dispositivo periférico USB conectado enquanto estiver no host modo anunciando uma fonte atual de pelo menos 1,5 A, conforme especificado Parâmetros de rescisão do Revisão 1.2 das especificações do cabo e do conector USB-C para USB-C de saída ou usar a porta de encaminhamento de carregamento (CDP, na sigla em inglês) de saída da faixa atual conforme especificado no Especificações de carregamento de bateria USB, revisão 1.2 para conectores Micro-AB.
- DEVE implementar e oferecer suporte aos padrões USB-C.
Se as implementações de dispositivos incluírem uma porta USB compatível com o modo host e o USB classe de áudio, eles:
- [C-2-1] PRECISA oferecer suporte à classe HID USB.
- [C-2-2] PRECISA oferecer suporte à detecção e ao mapeamento dos seguintes dados HID.
campos especificados nas Tabelas de uso de HID USB
e a Solicitação de uso do Voice Command
para o
KeyEvent
da seguinte forma:- ID de uso da página de uso (0xC) (0x0CD):
KEYCODE_MEDIA_PLAY_PAUSE
- ID de uso da página de uso (0xC) (0x0E9):
KEYCODE_VOLUME_UP
- ID de uso da página de uso (0xC) (0x0EA):
KEYCODE_VOLUME_DOWN
- ID de uso da página de uso (0xC) (0x0CF):
KEYCODE_VOICE_ASSIST
- ID de uso da página de uso (0xC) (0x0CD):
Se as implementações de dispositivos incluem uma porta USB compatível com o modo host e Framework de acesso ao armazenamento (SAF, na sigla em inglês), eles:
- [C-3-1] PRECISA reconhecer qualquer MTP (protocolo de transferência de mídia) conectado remotamente
dispositivos e tornar o conteúdo deles acessível pela
ACTION_GET_CONTENT
,ACTION_OPEN_DOCUMENT
eACTION_CREATE_DOCUMENT
. .
Se as implementações de dispositivos incluírem uma porta USB compatível com o modo host e USB Digite C, eles:
- [C-4-1] PRECISA implementar a funcionalidade de porta de função dupla, conforme definido pelo USB. Especificação Tipo C (seção 4.5.1.3.3). Para duplo Portas de função, em dispositivos que incluem entrada para fone de ouvido de 3,5 mm, o coletor USB (modo host) PODE estar desativada por padrão, mas DEVE ser possível para o para ativá-lo.
- [C-SR-2] É RECOMENDADO O EXEMPLO DE Compatibilidade com DisplayPort (deve ser compatível com USB) Taxas de dados SuperSpeed e é MUITO RECOMENDADO para oferecer suporte ao Power Delivery para a troca de papéis de dados e poder.
- [C-SR-3] É RECOMENDADO NÃO oferecer suporte ao modo de acessório do adaptador de áudio como descritos no Apêndice A Revisão 1.2 das especificações do cabo e do conector USB-C.
- DEVE implementar o modelo Try.* mais apropriado para o formato do dispositivo. Por exemplo, um dispositivo portátil DEVE implementar a Modelo Try.SNK.
7,8. Áudio
7.8.1. Microfone
Se as implementações de dispositivos incluírem um microfone, elas:
- [C-1-1] PRECISA informar a constante de recurso
android.hardware.microphone
. - [C-1-2] PRECISA atender aos requisitos de gravação de áudio em seção 5.4.
- [C-1-3] PRECISA atender aos requisitos de latência de áudio seção 5.6.
- [C-SR-1] É FORTEMENTE RECOMENDADO para oferecer suporte à gravação quase ultrassônica, conforme descrito na seção 7.8.3.
Se as implementações de dispositivos omitirem um microfone, elas:
- [C-2-1] NÃO PODE informar a constante de recurso
android.hardware.microphone
. - [C-2-2] PRECISA implementar a API de gravação de áudio pelo menos como ambiente autônomo, seção 7.
7.8.2. Saída de áudio
Se as implementações do dispositivo incluírem um alto-falante ou uma saída de áudio/multimídia para um periférico de saída de áudio, como uma entrada para fone de ouvido de 4 condutores de 3,5 mm ou Porta do modo host USB usando a classe de áudio USB, eles:
- [C-1-1] PRECISA informar a constante de recurso
android.hardware.audio.output
. - [C-1-2] PRECISA atender aos requisitos de reprodução de áudio em seção 5.5.
- [C-1-3] PRECISA atender aos requisitos de latência de áudio seção 5.6.
- [C-SR-1] É MUITO RECOMENDADO para oferecer suporte à reprodução quase ultrassônica, conforme descrito na seção 7.8.3.
Se as implementações de dispositivos não incluírem uma porta de saída de áudio ou alto-falante, elas:
- [C-2-1] NÃO É POSSÍVEL informar o recurso
android.hardware.audio.output
. - [C-2-2] PRECISA implementar as APIs relacionadas à saída de áudio como um ambiente autônomo.
Para os fins desta seção, uma "porta de saída" é um interface física como entrada de áudio de 3, 5 mm, HDMI ou porta de modo host USB com classe de áudio USB. Suporte para saída de áudio por protocolos baseados em rádio, como Bluetooth, Uma rede Wi-Fi ou celular não inclui uma "porta de saída".
7.8.2.1. Portas de áudio analógico
Para ser compatível com o fones de ouvido e outros acessórios de áudio usando o plugue de áudio de 3,5 mm em todo o ecossistema Android, se o dispositivo incluem uma ou mais portas de áudio analógico. São elas:
- [C-SR-1] É FORTEMENTE RECOMENDADO a inclusão de pelo menos um dos uma ou mais portas de áudio precisam ser uma entrada para fone de ouvido de 3,5 mm com 4 condutores.
Se as implementações do dispositivo tiverem uma entrada para fone de ouvido de 3,5 mm com quatro condutores, elas:
- [C-1-1] É NECESSÁRIO oferecer suporte à reprodução de áudio para fones de ouvido estéreo ou estéreo. com um microfone.
- [C-1-2] PRECISA oferecer suporte a plugues de áudio TRRS com a ordem de pinagem CTIA.
- [C-1-3] PRECISA oferecer suporte à detecção e ao mapeamento dos códigos de tecla da
seguindo três intervalos de impedância equivalentes entre o microfone e o solo
condutores no plugue de áudio:
- 70 ohm ou menos:
KEYCODE_HEADSETHOOK
- 210–290 ohm:
KEYCODE_VOLUME_UP
- 360-680 ohm:
KEYCODE_VOLUME_DOWN
- 70 ohm ou menos:
- [C-1-4] PRECISA acionar
ACTION_HEADSET_PLUG
na inserção de um plugue, mas somente depois que todos os contatos no plugue estiverem tocando nos segmentos relevantes na entrada. - [C-1-5] PRECISA ser capaz de operar com pelo menos 150 mV ± 10% da tensão de saída uma impedância de alto-falante de 32 ohm.
- [C-1-6] PRECISA ter uma tensão de polarização de microfone entre 1,8 V e 2,9 V.
- [C-1-7] PRECISA detectar e mapear para o código de tecla das seguintes
intervalo de impedância equivalente entre o microfone e os condutores de terra
no plugue de áudio:
- 110-180 ohm:
KEYCODE_VOICE_ASSIST
- 110-180 ohm:
- [C-SR-2] É FORTEMENTE RECOMENDADO a compatibilidade com plugues de áudio com o OMTP de descarte.
- [C-SR-3] É FORTEMENTE RECOMENDADO para oferecer suporte à gravação de áudio estéreo fones de ouvido com microfone.
Se as implementações do dispositivo tiverem uma entrada para fone de ouvido de 3,5 mm com quatro condutores e forem compatíveis com uma
microfone e transmitir android.intent.action.HEADSET_PLUG
com o
de valor extra definido como 1, ele:
- [C-2-1] PRECISA oferecer suporte à detecção de microfone no áudio conectado. acessório.
7.8.2.2. Portas digitais de áudio
Consulte a Seção 2.2.1 para ver os requisitos específicos dos dispositivos.
7.8.3. Quase ultrassom
O áudio quase ultrassom é a banda de 18,5 kHz a 20 kHz.
Implementações de dispositivos:
- PRECISA relatar corretamente o suporte dos de áudio quase ultrassom AudioManager.getProperty (link em inglês) API da seguinte maneira:
Se PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND
for "true", os seguintes requisitos PRECISAM ser atendidos pelo
Fontes de áudio VOICE_RECOGNITION
e UNPROCESSED
:
- [C-1-1] A resposta de potência média do microfone na faixa de 18,5 kHz a 20 kHz PRECISA estar no máximo 15 dB abaixo da resposta a 2 kHz.
- [C-1-2] O sinal não ponderado do microfone para a proporção de ruído acima de 18,5 kHz a 20 kHz para um tom de 19 kHz a -26 dBFS PRECISA ser no máximo 50 dB.
Se PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND
é "true":
- [C-2-1] A resposta média do alto-falante em 18,5 kHz a 20 kHz PRECISA ser inferior a 40 dB abaixo da resposta a 2 kHz.
7.8.4. Integridade do sinal
Implementações de dispositivos:
- DEVE fornecer um caminho de sinal de áudio sem falhas para as entradas e streams de saída em dispositivos portáteis, conforme definido por zero falhas medido durante um teste de um minuto por caminho. Testar usando o OboeTester "Teste de falhas automatizado".
O teste requer um dongle de loopback de áudio. usado diretamente em uma entrada de 3,5 mm e/ou em combinação com um adaptador de USB-C para 3,5 mm. Todas as portas de saída de áudio DEVEM ser testadas.
O OboeTester atualmente oferece suporte a caminhos AAudio, portanto, as seguintes combinações DEVEM ser testadas em busca de falhas usando a AAudio:
Modo de desempenho | Compartilhamento | Taxa de amostragem de saída | Em Poss | Out Poss |
---|---|---|---|---|
BAIXO_LATÊNCIA | EXCLUSIVO | NÃO ESPECIFICADO | 1 | 2 |
BAIXO_LATÊNCIA | EXCLUSIVO | NÃO ESPECIFICADO | 2 | 1 |
BAIXO_LATÊNCIA | COMPARTILHADO | NÃO ESPECIFICADO | 1 | 2 |
BAIXO_LATÊNCIA | COMPARTILHADO | NÃO ESPECIFICADO | 2 | 1 |
NENHUMA | COMPARTILHADO | 48000 | 1 | 2 |
NENHUMA | COMPARTILHADO | 48000 | 2 | 1 |
NENHUMA | COMPARTILHADO | 44100 | 1 | 2 |
NENHUMA | COMPARTILHADO | 44100 | 2 | 1 |
NENHUMA | COMPARTILHADO | 16000 | 1 | 2 |
NENHUMA | COMPARTILHADO | 16000 | 2 | 1 |
Um stream confiável DEVE atender aos seguintes critérios de sinal para ruído Proporção (SNR, na sigla em inglês) e Distorção harmônica total (THD) para 2.000 Hz seno.
Transdutor | THD | SNR |
---|---|---|
Alto-falante integrado principal, medido com um microfone de referência externo | < 3,0% | >= 50 dB |
microfone integrado principal, medido com um alto-falante de referência externo | < 3,0% | >= 50 dB |
Entradas de 3,5 mm analógicas integradas, testadas com o adaptador de loopback | Menos de 1% | >= 60 dB |
Adaptadores USB fornecidos com o telefone, testados com o adaptador de loopback | < 1,0% | >= 60 dB |
7,9. Realidade virtual
O Android inclui APIs e instalações para criar a "Realidade virtual" (RV) aplicativos, incluindo experiências de RV com alta qualidade para dispositivos móveis. Dispositivo implementações DEVEM implementar corretamente essas APIs e esses comportamentos, conforme detalhado nesta seção.
7.9.1. Modo de realidade virtual
O Android inclui suporte a Modo RV, um recurso que lida com a renderização estereoscópica de notificações e desativa componentes da interface do sistema monocular enquanto um aplicativo de RV tem o foco do usuário.
7.9.2. Modo de realidade virtual: alto desempenho
Se as implementações de dispositivos oferecerem suporte ao modo RV, elas:
- [C-1-1] PRECISA ter pelo menos dois núcleos físicos.
- [C-1-2] PRECISA declarar o recurso
android.hardware.vr.high_performance
. - [C-1-3] PRECISA oferecer suporte ao modo de desempenho sustentado.
- [C-1-4] PRECISA oferecer suporte ao OpenGL ES 3.2.
- [C-1-5] PRECISA oferecer suporte a
android.hardware.vulkan.level
0. - DEVE oferecer suporte a
android.hardware.vulkan.level
1 ou mais recente. - [C-1-6] PRECISA implementar
EGL_KHR_mutable_render_buffer
,EGL_ANDROID_front_buffer_auto_refresh
,EGL_ANDROID_get_native_client_buffer
,EGL_KHR_fence_sync
,EGL_KHR_wait_sync
,EGL_IMG_context_priority
,EGL_EXT_protected_content
,EGL_EXT_image_gl_colorspace
, e expor as extensões na lista de extensões EGL disponíveis. - [C-1-8] PRECISA implementar
GL_EXT_multisampled_render_to_texture2
,GL_OVR_multiview
,GL_OVR_multiview2
,GL_EXT_protected_textures
, e expor as extensões na lista de extensões GL disponíveis. - [C-SR-1] É FORTEMENTE RECOMENDADO a implementação
GL_EXT_external_buffer
,GL_EXT_EGL_image_array
,GL_OVR_multiview_multisampled_render_to_texture
, e expor as extensões na lista de extensões GL disponíveis. - [C-SR-2] É FORTEMENTE RECOMENDADO para oferecer suporte ao Vulkan 1.1.
- [C-SR-3] É FORTEMENTE RECOMENDADO a implementação
VK_ANDROID_external_memory_android_hardware_buffer
,VK_GOOGLE_display_timing
,VK_KHR_shared_presentable_image
, e a exponha na lista de extensões do Vulkan disponíveis. - [C-SR-4] É FORTEMENTE RECOMENDADO expor pelo menos uma família de filas do Vulkan em que
flags
contêmVK_QUEUE_GRAPHICS_BIT
eVK_QUEUE_COMPUTE_BIT
, equeueCount
é pelo menos 2. - [C-1-7] A GPU e a tela PRECISAM sincronizar o acesso ao buffer frontal, de modo que a renderização de olhos alternados do conteúdo de RV a 60 fps com dois contextos de renderização serão exibidos sem artefatos de ruptura visíveis.
- [C-1-9] PRECISA implementar o suporte para
AHardwareBuffer
. sinalizaçõesAHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER
,AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA
eAHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
conforme descrito no NDK. - [C-1-10] PRECISA implementar suporte para
AHardwareBuffer
s com qualquer combinação das flags de usoAHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT
,AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE
,AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
para pelo menos os seguintes formatos:AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM
,AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM
,AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM
,AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT
. - [C-SR-5] É FORTEMENTE RECOMENDADO para oferecer suporte à alocação de
AHardwareBuffer
s com mais de uma camada e flags e formatos especificados em C-1-10. - [C-1-11] PRECISA oferecer suporte à decodificação H.264 de pelo menos 3.840 x 2.160 a 30 fps, compactado a uma média de 40 Mbps (equivalente a 4 instâncias de 1.920 x 1.080 a 30 fps a 10 Mbps ou duas instâncias de 1.920 x 1.080 a 60 fps a 20 Mbps).
- [C-1-12] PRECISA oferecer suporte a HEVC e VP9. Precisa ser capaz de decodificar pelo menos 1920 x 1080 a 30 fps, comprimido a uma média de 10 Mbps e DEVE ser capaz de decodificar 3.840 x 2.160 a 30 fps a 20 Mbps (equivalente a 4 instâncias de 1.920 x 1.080 a 30 fps a 5 Mbps).
- [C-1-13] PRECISA oferecer suporte à API
HardwarePropertiesManager.getDeviceTemperatures
. e retornar valores precisos para a temperatura da pele. - [C-1-14] PRECISA ter uma tela incorporada, e a resolução PRECISA ser de pelo menos 1.920 x 1.080.
- [C-SR-6] É RECOMENDADO que você tenha uma resolução de tela de pelo menos 2.560 x 1.440.
- [C-1-15] A tela PRECISA ser atualizada para pelo menos 60 Hz no modo RV.
- [C-1-17] A tela PRECISA ser compatível com um modo de baixa persistência com ≤ 5 milissegundos persistência, sendo definida como a quantidade de tempo quais pixels estão emitindo luz.
- [C-1-18] PRECISA oferecer suporte a Bluetooth 4.2 e à extensão de comprimento de dados Bluetooth LE. seção 7.4.3.
- [C-1-19] PRECISA oferecer suporte e relatar adequadamente
Tipo de canal direto
para todos os seguintes tipos de sensor padrão:
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED
- [C-SR-7] É FORTEMENTE RECOMENDADO para oferecer suporte à
TYPE_HARDWARE_BUFFER
tipo de canal direto para todos os tipos listados acima. - [C-1-21] PRECISA atender aos requisitos relacionados ao giroscópio, acelerômetro e magnetômetro.
requisitos para
android.hardware.hifi_sensors
, conforme especificado em seção 7.3.9. - [C-SR-8] É FORTEMENTE RECOMENDADO para oferecer suporte à
android.hardware.sensor.hifi_sensors
. - [C-1-22] PRECISA ter latência de movimento de ponta a ponta para fótons não superior a 28 milissegundos.
- [C-SR-9] É FORTEMENTE RECOMENDADO que tenham movimento de ponta a ponta para latência de fótons não pode ser superior a 20 milissegundos.
- [C-1-23] PRECISA ter a proporção do primeiro frame, que é a proporção entre brilho de pixels no primeiro quadro após uma transição de preto para branco e o brilho dos pixels brancos em estado estável de pelo menos 85%.
- [C-SR-10] É RECOMENDADO que a proporção do primeiro frame seja de pelo menos 90%.
- PODE oferecer um núcleo exclusivo para o primeiro plano
e PODE oferecer suporte à API
Process.getExclusiveCores
para retornar os números dos núcleos de CPU exclusivos do primeiro plano superior para o aplicativo.
Se houver suporte ao núcleo exclusivo, então o núcleo:
- [C-2-1] NÃO PODE permitir que nenhum outro processo do espaço do usuário seja executado nele. (exceto drivers de dispositivo usados pelo aplicativo), mas PODE permitir parte do kernel que os processos sejam executados conforme necessário.
7,10. Retorno tátil
Iniciar novos requisitos
Dispositivos destinados a serem manuais ou usados podem incluir um retorno tátil para uso geral atuador, disponível para aplicativos com finalidades que incluem a chamada de atenção por meio de toques, alarmes, notificações e feedback geral por toque.
Se as implementações de dispositivos NÃO incluírem esse atuador tátil de uso geral, eles:
- [7.10/C] PRECISA retornar "false" para
Vibrator.hasVibrator()
.
Se as implementações do dispositivo ENVOLVEREM pelo menos um retorno tátil de uso geral atuador, eles:
- [C-1-1] PRECISA retornar "true" para
Vibrator.hasVibrator()
. - NÃO DEVE usar um atuador tátil (vibrador) de massa giratória excêntrica (ERM).
- DEVE implementar todas as constantes públicas para retorno tátil claro.
em
android.view.HapticFeedbackConstants
ou seja (CLOCK_TICK
,CONTEXT_CLICK
,KEYBOARD_PRESS
,KEYBOARD_RELEASE
,KEYBOARD_TAP
,LONG_PRESS
,TEXT_HANDLE_MOVE
,VIRTUAL_KEY
,VIRTUAL_KEY_RELEASE
,CONFIRM
,REJECT
,GESTURE_START
eGESTURE_END
). - DEVE implementar todas as constantes públicas para retorno tátil claro.
em
android.os.VibrationEffect
ou seja (EFFECT_TICK
,EFFECT_CLICK
,EFFECT_HEAVY_CLICK
eEFFECT_DOUBLE_CLICK
) e todas as constantes públicas viáveis dePRIMITIVE_*
para retorno tátil avançado emandroid.os.VibrationEffect.Composition
ou seja (CLICK
,TICK
,LOW_TICK
,QUICK_FALL
,QUICK_RISE
,SLOW_RISE
,SPIN
eTHUD
). Alguns desses primitivos, comoLOW_TICK
eSPIN
só será viável se a vibração oferecer suporte a níveis relativamente baixos e frequências diferentes. - DEVE seguir as orientações para mapeamento de constantes públicas
em
android.view.HapticFeedbackConstants
para oandroid.os.VibrationEffect
recomendado com as relações de amplitude correspondentes. - DEVE usar estes mapeamentos de constantes táteis vinculados.
- DEVE seguir a avaliação de qualidade
para
createOneShot()
ecreateWaveform()
APIs de terceiros. - DEVE confirmar se o resultado das
android.os.Vibrator.hasAmplitudeControl()
públicas A API reflete corretamente os recursos da vibração. - DEVE verificar os recursos de escalonabilidade de amplitude executando
android.os.Vibrator.hasAmplitudeControl()
.
Se as implementações de dispositivos seguirem o mapeamento de constantes táteis, elas:
- DEVE verificar o status da implementação executando
android.os.Vibrator.areAllEffectsSupported()
eandroid.os.Vibrator.arePrimitivesSupported()
APIs de terceiros. - DEVEM fazer uma avaliação de qualidade para constantes táteis.
- DEVE verificar e atualizar, se necessário, a configuração de fallback primitivos não compatíveis, conforme descrito nas orientações de implementação para constantes.
- DEVE fornecer suporte substituto para reduzir o risco de falha, conforme descrito aqui.
Encerrar novos requisitos
Consulte a Seção 2.2.1 para ver os requisitos específicos dos dispositivos.
7,11. Classe de desempenho de mídia
A classe de desempenho de mídia da implementação do dispositivo pode ser obtida em
a API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
. Requisitos
da classe de desempenho de mídia são definidos para cada versão do Android que começa com
R (versão 30). O valor especial de 0 designa que o dispositivo não é
classe de desempenho de mídia.
Se as implementações de dispositivo retornarem um valor diferente de zero para
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, eles:
[C-1-1] PRECISA retornar pelo menos um valor de
android.os.Build.VERSION_CODES.R
.[C-1-2] PRECISA ser uma implementação de dispositivo portátil.
[C-1-3] PRECISA atender a todos os requisitos de "Classe de desempenho de mídia" descreveu na seção 2.2.7.
Em outras palavras, a classe de desempenho de mídia no Android T é definida apenas para dispositivos portáteis nas versões T, S ou R.
Consulte a seção 2.2.7 para informações específicas do dispositivo e cumprimento de requisitos regulatórios.
8. Desempenho e potência
Alguns critérios mínimos de desempenho e potência são essenciais para a experiência do usuário. e afetar as suposições básicas que os desenvolvedores teriam ao desenvolver app.
8.1. Consistência da experiência do usuário
Uma interface de usuário tranquila pode ser fornecida ao usuário final se houver certos requisitos mínimos para garantir um frame rate e tempos de resposta consistentes para aplicativos e jogos. Implementações de dispositivos, dependendo do tipo, podem ter requisitos mensuráveis de latência da interface do usuário e como descrito na seção 2.
8.2. Desempenho do acesso a E/S de arquivos
O fornecimento de um valor de referência comum para um desempenho consistente de acesso a arquivos no
O armazenamento de dados particulares do aplicativo (partição /data
) permite que os desenvolvedores de apps
definir uma expectativa adequada
para ajudar no design do software. Dispositivo
implementações, dependendo do tipo de dispositivo, PODEM ter determinados requisitos
descritos na seção 2 para o seguinte
e operações de gravação:
- Desempenho de gravação sequencial. Medida pela gravação de um arquivo de 256 MB usando 10 MB de gravação.
- Desempenho de gravação aleatória. Medida por meio da gravação de um arquivo de 256 MB usando 4 KB de gravação de dados.
- Desempenho de leitura sequencial. Medida pela leitura de um arquivo de 256 MB com o 10 MB de gravação.
- Desempenho de leitura aleatória. Medida pela leitura de um arquivo de 256 MB usando 4 KB de gravação de dados.
8.3. Modos de economia de energia
Se as implementações de dispositivos incluírem recursos para melhorar o gerenciamento de energia do dispositivo incluídos no AOSP (por exemplo, App em espera, Soneca) ou que estendam os recursos para aplicar restrições mais fortes do que o bucket RESTRITO do App em espera, eles:
- [C-1-1] NÃO PODE se desviar da implementação do AOSP para o acionamento. algoritmos de ativação e uso de configurações globais do sistema ou DeviceConfig (em inglês) dos modos de economia de energia "App em espera" e "Soneca".
- [C-1-2] NÃO PODE se desviar da implementação do AOSP para usar ou DeviceConfig para gerenciar a limitação de jobs, para apps em cada bucket para o App em espera.
- [C-1-3] NÃO PODE se desviar da implementação do AOSP para o número de Buckets do App em espera usados para o App em espera.
- [C-1-4] PRECISA implementar os buckets do App em espera e "Soneca", conforme descrito em Gerenciamento de energia.
- [C-1-5] PRECISA retornar
true
paraPowerManager.isPowerSaveMode()
quando o dispositivo está no modo de economia de energia. - [C-1-6] PRECISA fornecer recursos do usuário para mostrar todos os apps isentos. dos modos de economia de energia App em espera e Soneca ou qualquer otimização de bateria e PRECISA implementar a configuração ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS de solicitar que o usuário permita que um app ignore a bateria. e otimizações.
- [C-SR-1] É FORTEMENTE RECOMENDADO para fornecer recursos ao usuário para ativar e desativar o recurso de economia de bateria.
- [C-SR-2] É FORTEMENTE RECOMENDADO para fornecer recursos ao usuário para exibir todos apps isentos dos modos de economia de energia "App em espera" e "Soneca".
Se as implementações de dispositivos estenderem os recursos de gerenciamento de energia incluídos no AOSP, e essa extensão aplica restrições mais rigorosas o bucket "Rare App Standby", consulte a seção 3.5.1.
Além dos modos de economia de energia, as implementações de dispositivos Android podem implementar qualquer um ou todos os quatro estados de suspensão conforme definido pelo interface de configuração e energia (ACPI, na sigla em inglês).
Se as implementações de dispositivos implementam estados de energia S4 conforme definido pelas ACPI:
- [C-1-1] PRECISA inserir esse estado somente depois que o usuário tiver realizado uma ação explícita. Colocar o dispositivo em um estado inativo (por exemplo, fechando uma tampa que esteja fisicamente do dispositivo ou desligar um veículo ou televisão) e antes do o usuário ativa novamente o dispositivo (por exemplo, abrindo a tampa ou girando o veículo) ou a televisão ligada).
Se as implementações de dispositivos implementam estados de energia S3 conforme definido pelas ACPI:
[C-2-1] PRECISA estar em conformidade com C-1-1 acima ou PRECISA inserir o estado S3 somente quando terceiros os aplicativos não precisam dos recursos do sistema (por exemplo, a tela, CPU).
Por outro lado, PRECISA sair do estado S3 quando aplicativos de terceiros precisarem da do sistema, conforme descrito neste SDK.
Por exemplo, enquanto os aplicativos de terceiros pedem para manter a tela por meio de
FLAG_KEEP_SCREEN_ON
ou manter a CPU em execuçãoPARTIAL_WAKE_LOCK
, o dispositivo NÃO PODE entrar no estado S3, a menos que, conforme descrito em C-1-1, o usuário tomou medidas explícitas para colocar o dispositivo inativo. Por outro lado, em uma tarefa em que apps de terceiros implementar pelo JobScheduler é acionado ou o Firebase Cloud Messaging é entregue a apps de terceiros, o dispositivo PRECISA sair do estado S3, a menos que o o usuário colocou o dispositivo em um estado inativo. Elas não estão completas e o AOSP implementa amplos sinais de ativação que acionam uma ativação a partir desse estado.
8.4. Contabilidade de consumo de energia
Uma contabilidade e relatórios mais precisos do consumo de energia proporciona ao desenvolvedor de aplicativos os incentivos e as ferramentas para otimizar o uso de energia padrão do aplicativo.
Implementações de dispositivos:
- [C-SR-1] É MUITO RECOMENDADO fornecer um perfil de energia por componente que define o valor atual de consumo para cada componente de hardware e o consumo aproximado da bateria causado pelo ao longo do tempo, conforme documentado no site do Android Open Source Project.
- [C-SR-2] É MUITO RECOMENDADO informar todos os valores de consumo de energia em milímetros horas (mAh).
- [C-SR-3] É MUITO RECOMENDADO informar o consumo de energia da CPU por UID de cada processo.
O Android Open Source Project atende ao requisito por meio do
Implementação do módulo do kernel
uid_cputime
. - [C-SR-4] É MUITO RECOMENDADO disponibilizar esse uso de energia pela
adb shell dumpsys batterystats
shell para o desenvolvedor do app. - DEVE ser atribuído ao componente de hardware se não for possível atribui o consumo de energia do componente de hardware a um aplicativo.
8.5. Desempenho consistente
O desempenho pode variar drasticamente para apps de alto desempenho e longa duração, seja por conta de outros apps em execução em segundo plano ou da limitação de CPU devido aos limites de temperatura. O Android inclui interfaces programáticas para que, quando o dispositivo é capaz, o aplicativo de primeiro plano superior pode solicitar que o sistema otimizar a alocação de recursos para lidar com essas flutuações.
Implementações de dispositivos:
[C-0-1] PRECISA informar o suporte ao Modo de desempenho sustentado com precisão através do
PowerManager.isSustainedPerformanceModeSupported()
Método de API.DEVE oferecer suporte ao modo de desempenho sustentado.
Se as implementações de dispositivos relatarem suporte ao modo de desempenho sustentado, elas:
- [C-1-1] PRECISA fornecer ao aplicativo em primeiro plano um nível consistente de performance por pelo menos 30 minutos, quando o app solicitar.
- [C-1-2] PRECISA respeitar
Window.setSustainedPerformanceMode()
e outras APIs relacionadas.
Se as implementações de dispositivos incluírem dois ou mais núcleos de CPU, elas:
- DEVE fornecer pelo menos um núcleo exclusivo que possa ser reservado pelas principais aplicativo em primeiro plano.
Se as implementações de dispositivos oferecerem suporte à reserva de um núcleo exclusivo para o aplicativo em primeiro plano, eles:
- [C-2-1] PRECISA gerar relatórios pela
Process.getExclusiveCores()
Método de API com os números de ID dos núcleos exclusivos que podem ser reservados pelo aplicativo principal em primeiro plano. - [C-2-2] Não pode permitir processos do espaço do usuário, exceto os drivers do dispositivo pelo aplicativo para execução nos núcleos exclusivos, mas PODE permitir que alguns que os processos do kernel sejam executados conforme necessário.
Se as implementações de dispositivos não oferecerem suporte a um núcleo exclusivo, elas:
- [C-3-1] PRECISA retornar uma lista vazia usando o
Process.getExclusiveCores()
Método de API.
9. Compatibilidade do modelo de segurança
Implementações de dispositivos:
[C-0-1] PRECISA implementar um modelo de segurança consistente com o modelo de segurança da plataforma Android, conforme definido Documento de referência de segurança e permissões nas APIs na documentação do desenvolvedor Android.
[C-0-2] PRECISA ser compatível com a instalação de modelos de aplicativos sem a necessidade de permissões/certificados adicionais de qualquer terceiros/autoridades.
Se as implementações do dispositivo declararem o android.hardware.security.model.compatible
eles:
- [C-1-1] PRECISA ser compatível com os requisitos listados nas subseções a seguir.
9,1. Permissões
Implementações de dispositivos:
[C-0-1] PRECISA oferecer suporte ao modelo de permissões do Android e o Modelo de papéis do Android conforme definido na documentação do desenvolvedor Android. Especificamente, eles PRECISA aplicar cada permissão e papel definidos conforme descrito nos Documentação do SDK. permissões e papéis não podem ser omitidos, alterados ou ignoradas.
PODE adicionar outras permissões, desde que as novas strings de ID de permissão não estão no namespace
android.\*
.[C-0-2] Permissões com
protectionLevel
dePROTECTION_FLAG_PRIVILEGED
Só PRECISA ser concedido a apps pré-instalados nos caminhos privilegiados do imagem do sistema (bem como arquivos APEX) e no subconjunto de permissões explicitamente permitidas para cada app. A implementação do AOSP atende a esse requisito, lendo e respeitando a permissões de cada app dos arquivos naetc/permissions/
e usando o caminhosystem/priv-app
como o caminho privilegiado.
Permissões com um nível de proteção perigoso são as permissões de execução.
Aplicativos com targetSdkVersion
> 22 solicitá-las no ambiente de execução.
Implementações de dispositivos:
- [C-0-3] PRECISA mostrar uma interface dedicada para o usuário decidir se concede ou não as permissões de execução solicitadas e também fornece uma interface para o usuário gerenciar as permissões de execução.
- [C-0-4] PRECISA ter apenas uma implementação do usuário do Google Cloud.
[C-0-5] NÃO PODE conceder permissões de execução a apps, a menos que:
- forem instalados no momento do envio do dispositivo;
O consentimento do usuário pode ser obtido antes que o aplicativo usa a permissão,
OU
As permissões de execução são concedidas pela política de concessão de permissão padrão ou para ter um papel de plataforma.
[C-0-6] PRECISA conceder a permissão
android.permission.RECOVER_KEYSTORE
. somente a apps do sistema que registram um Agente de recuperação protegido. Um o Agente de recuperação bem protegido é definido como um agente de software no dispositivo sincronizado com um armazenamento remoto fora do dispositivo, equipado com um hardware seguro com proteção equivalente ou mais forte descritos em Serviço Google Cloud Key Vault para evitar ataques de força bruta no fator de conhecimento da tela de bloqueio.
Implementações de dispositivos:
[C-0-7] PRECISA aderir às propriedades de permissão de localização do Android quando um app solicita os dados de local ou atividade física por meio da API Android padrão ou mecanismo reservado. Esses dados incluem, entre outros:
- Localização do dispositivo (por exemplo, latitude e longitude), conforme descrito em seção 9.8.8.
- Informações que podem ser usadas para determinar ou estimar o local (por exemplo, SSID, BSSID, ID do celular ou local da rede em que a dispositivo está conectado).
- Atividade física do usuário ou classificação da atividade física.
Mais especificamente, implementações de dispositivos:
- [C-0-8] PRECISA ter o consentimento do usuário para permitir que o app acesse a dados de local ou atividade física.
- [C-0-9] PRECISA conceder uma permissão de execução APENAS ao app que contém
permissão suficiente, conforme descrito no SDK.
Por exemplo:
TelephonyManager#getServiceState
requer
android.permission.ACCESS_FINE_LOCATION
).
As únicas exceções às propriedades de permissão de localização do Android acima são para Apps que não acessam a Localização para obter ou identificar a localização do usuário. especificamente:
- Quando os apps têm a permissão
RADIO_SCAN_WITHOUT_LOCATION
. - Para fins de configuração e configuração do dispositivo, quando os apps do sistema mantêm o
Permissão
NETWORK_SETTINGS
ouNETWORK_SETUP_WIZARD
.
As permissões podem ser marcadas como restritas, alterando o comportamento delas.
[C-0-10] As permissões marcadas com a sinalização
hardRestricted
NÃO PODEM ser concedidas a um app, a menos que:- Um arquivo APK do app está na partição do sistema.
- O usuário atribui um papel associado a
hardRestricted
. permissões de acesso a um app. - O instalador concede a
hardRestricted
a um app. - Um app recebe o
hardRestricted
em uma versão anterior do Android.
[C-0-11] Os apps com uma permissão
softRestricted
PRECISAM ser limitados. acesso e NÃO PODE ter acesso total até que esteja na lista de permissões, conforme descrito nas SDK, em que o acesso total e limitado é definido para cadasoftRestricted
permissão (por exemplo,READ_EXTERNAL_STORAGE
).[C-0-12] NÃO PODE fornecer nenhuma função personalizada ou API para ignorar a restrições de permissão definidas em setPermissionPolicy e setPermissionGrantState APIs de terceiros.
[C-0-13] PRECISA usar as APIs AppOpsManager para registrar e rastrear cada uma todo acesso programático a dados protegidos por permissões perigosas Atividades e serviços do Android.
[C-0-14] PRECISA atribuir funções apenas a aplicativos com funcionalidades que atendem aos requisitos da função.
[C-0-15] PRECISA não definir papéis que sejam cópias ou funcionalidades superconjunto. de papéis definidos pela plataforma.
Se os dispositivos informarem android.software.managed_users
, eles:
- [C-1-1] NÃO PODE ter as seguintes permissões concedidas silenciosamente pelo
Administrador:
- Local (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
- Câmera (CAMERA)
- Microfone (RECORD_AUDIO)
- Sensor corporal (BODY_SENSORS)
- Atividade física (ACTIVITY_RECOGNITION)
Se as implementações de dispositivos fornecerem funcionalidade ao usuário para escolher quais aplicativos podem
se sobrepõe a outros aplicativos com uma atividade que lida com
ACTION_MANAGE_OVERLAY_PERMISSION
intenção, eles:
- [C-2-1] PRECISA garantir que todas as atividades com filtros de intents para
ACTION_MANAGE_OVERLAY_PERMISSION
têm a mesma tela de interface, independentemente do app inicial ou de qualquer informações que ela fornece.
Se as implementações de dispositivo informarem android.software.device_admin, elas:
- [C-3-1] É NECESSÁRIO mostrar uma exoneração de responsabilidade durante a configuração do dispositivo totalmente gerenciado (configuração do proprietário do dispositivo) informando que o administrador de TI poderá permite que os apps controlem as configurações do telefone, incluindo microfone, câmera e local, com opções para o usuário continuar a configuração ou sair dela, A MENOS QUE a administrador desativou o controle das permissões no dispositivo.
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 cumprir todos os requisitos descritos para implementações de dispositivos em
seções
"9.8.6 Captura de Conteúdo""9.8.6 Dados ambientes e do SO 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 rigorosas do que as opções FORTEMENTE RECOMENDADAS listadas 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 as APIs da Internet. Este é mais restrito do que o FORTEMENTE RECOMENDADO listado em seção 9.8.6.
Iniciar novos requisitos
Se as implementações de dispositivos incluem um aplicativo padrão para dar suporte ao
VoiceInteractionService
eles:
- [C-5-1] NÃO PODE conceder
ACCESS_FINE_LOCATION
como padrão para isso para o aplicativo.
Encerrar novos requisitos
9,2. UID e isolamento de processos
Implementações de dispositivos:
- [C-0-1] PRECISA ser compatível com o app Android. em que cada aplicativo é executado como um UID exclusivo de estilo Unix e em um processo separado.
- [C-0-2] PRECISA oferecer suporte à execução de vários aplicativos. como o mesmo ID de usuário do Linux, desde que os aplicativos sejam assinados e construído, conforme definido nas Referência de segurança e permissões.
9,3 Permissões do sistema de arquivos
Implementações de dispositivos:
- [C-0-1] PRECISA oferecer suporte ao acesso a arquivos do Android. de permissões do usuário, conforme definido Referência de segurança e permissões.
9,4. Ambientes de execução alternativos
As implementações de dispositivos PRECISAM manter a consistência da segurança do Android de permissão de acesso, mesmo que incluam ambientes de execução que executam aplicativos que usam algum outro software ou tecnologia que não o Dalvik Executable Formato ou código nativo. Resumindo:
[C-0-1] Os tempos de execução alternativos PRECISAM ser aplicativos Android, e respeitar o modelo de segurança padrão do Android, conforme descrito em outros locais. na seção 9.
[C-0-2] Ambientes de execução alternativos NÃO PODEM ter acesso aos recursos protegido por permissões não solicitadas no
AndroidManifest.xml
do ambiente de execução pelo <uses-permission
> mecanismo de atenção.[C-0-3] Tempos de execução alternativos NÃO PODEM permitir que aplicativos usem recursos protegidos por permissões do Android restritas a aplicativos do sistema.
[C-0-4] Tempos de execução alternativos PRECISAM respeitar o modelo de sandbox do Android e aplicativos instalados usando um tempo de execução alternativo NÃO PODEM reutilizar o sandbox de qualquer outro aplicativo instalado no dispositivo, exceto por meio de os mecanismos Android padrão do ID de usuário compartilhado e do certificado de assinatura.
[C-0-5] Ambientes de execução alternativos NÃO PODEM ser iniciados, concedidos ou concedidos acesso às sandboxes correspondentes a outros aplicativos Android.
[C-0-6] Ambientes de execução alternativos NÃO PODEM ser iniciados, concedidos ou concedidos a outros aplicativos qualquer privilégio do superusuário (raiz) ou de qualquer outro ID do usuário.
[C-0-7] Quando os arquivos
.apk
de ambientes de execução alternativos são incluídos no imagem do sistema de implementações de dispositivos, ele PRECISA ser assinado com uma chave diferente da chave usada para assinar outros apps incluídos no dispositivo e implementações.[C-0-8] Ao instalar aplicativos, os ambientes de execução alternativos PRECISAM ter o consentimento do usuário para as permissões do Android usadas pelo aplicativo.
[C-0-9] Quando um aplicativo precisa usar um recurso de dispositivo para que há uma permissão correspondente do Android (como Câmera, GPS etc.), o ambiente de execução alternativo PRECISA informar ao usuário que o aplicativo vai poder para acessar esse recurso.
[C-0-10] Quando o ambiente de execução não grava o aplicativo dessa maneira, o ambiente de execução PRECISA listar todas as permissões mantidos pelo próprio ambiente de execução ao instalar qualquer aplicativo que use esse ambiente de execução.
Ambientes de execução alternativos DEVEM instalar apps pelo
PackageManager
nos sandboxes do Android separados (IDs de usuário do Linux etc.).Tempos de execução alternativos PODEM fornecer um único sandbox do Android compartilhado por todos aplicativos usando o ambiente de execução alternativo.
9,5 Suporte a multiusuário
O Android inclui suporte para vários usuários
e oferece suporte para isolamento total e clone perfis de usuário com
isolamento parcial(ou seja, um único perfil de usuário adicional do tipo
android.os.usertype.profile.CLONE
).
- As implementações de dispositivos PODEM, mas NÃO DEVEM habilitar o grupo multiusuário se usarem mídia removível para o armazenamento externo principal.
Se as implementações de dispositivos tiverem suporte para vários usuários, elas:
- [C-1-2] PRECISA, para cada usuário, implementar uma política consistente com o modelo de segurança da plataforma Android, conforme definido Documento de referência de segurança e permissões nas APIs.
- [C-1-3] PRECISA ter armazenamento compartilhado separado e isolado para apps
(conhecidos como
/sdcard
) para cada instância de usuário. - [C-1-4] PRECISA garantir que os aplicativos pertencentes e executados em nome de um determinado usuário não pode listar, ler ou gravar nos arquivos de outro usuário; mesmo que os dados dos dois usuários estejam armazenados no mesmo volume ou sistema de arquivos.
- [C-1-5] É NECESSÁRIO criptografar o conteúdo do cartão SD quando o recurso multiusuário está ativado usando uma chave armazenada apenas em mídia não removível, que só pode ser acessada pelo sistema se as implementações de dispositivos usam mídia removível para as APIs de armazenamento externo. Como isso torna a mídia ilegível para um PC host, as implementações de dispositivos será necessário mudar para o MTP ou um sistema similar para fornecer aos PCs host acesso aos dados do usuário atual.
Se as implementações de dispositivos incluírem suporte para vários usuários, para Todos os usuários, exceto aqueles criados especificamente para executar instâncias duplas do mesmo app, elas:
- [C-2-1] PRECISA ter armazenamento compartilhado para aplicativos separado e isolado diretórios (conhecidos como /sdcard) para cada instância de usuário.
- [C-2-2] PRECISA garantir que os aplicativos de propriedade da nome de um determinado usuário não pode listar, ler ou gravar nos arquivos de propriedade por qualquer outro usuário, mesmo que os dados de ambos os usuários estejam armazenados no mesmo volume ou sistema de arquivos.
As implementações de dispositivos PODEM criar um único perfil de usuário adicional do tipo
android.os.usertype.profile.CLONE
em relação ao usuário principal (e somente contra
o usuário principal) com a finalidade de executar instâncias duplas do mesmo app.
Essas instâncias duplas compartilham armazenamento parcialmente isolado e são apresentadas ao
usuário final no acesso rápido ao mesmo tempo e aparecem na mesma visualização Recentes.
Por exemplo, isso pode ser usado para ajudar o usuário a instalar dois dispositivos
instâncias de um único app em um dispositivo dual chip.
Se as implementações de dispositivos criarem o perfil de usuário adicional discutido acima, então eles:
- [C-3-1] PRECISA fornecer acesso apenas ao armazenamento ou aos dados que já estão pode ser acessado pelo perfil do usuário pai ou pertence diretamente a ele perfil de usuário adicional.
- [C-3-2] NÃO PODE ter este perfil de trabalho.
- [C-3-3] PRECISA ter diretórios de dados particulares do app isolados do pai. conta de usuário.
- [C-3-4] NÃO PODE permitir a criação do perfil de usuário adicional se houver é um proprietário do dispositivo aprovisionado (consulte a seção 3.9.1) ou permite que um proprietário de dispositivo seja provisionado sem remover o perfil de usuário adicional primeiro.
Iniciar novos requisitos
Se as implementações de dispositivos criarem o perfil de usuário adicional discutido acima, então eles:
- [C-4-5] PRECISA distinguir visualmente os ícones de aplicativo de instância dupla ao 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 clone e excluir os dados particulares deles diretórios e seu conteúdo e excluir Clonar dados de perfil, quando o usuário opta por excluir todos os dados do perfil Clonado.
- DEVE solicitar que o usuário exclua todos os dados do perfil clone quando o último para clonar o app é excluído.
- [C-4-8] PRECISA informar ao usuário que os dados do app serão excluídos quando o clone um app for desinstalado ou ofereça uma opção para os usuários manterem os dados do app quando o aplicativo é desinstalado do dispositivo.
- [C-4-9] PRECISA excluir os diretórios de dados particulares e o conteúdo deles, quando o usuário optar por excluir os dados durante a desinstalação.
[C-4-1] PRECISA permitir as intents abaixo, originárias das outras perfil seja gerenciado pelos aplicativos do usuário principal no dispositivo:
Intent.ACTION_VIEW
Intent.ACTION_SENDTO
Intent.ACTION_SEND
Intent.ACTION_EDIT
Intent.ACTION_INSERT
Intent.ACTION_INSERT_OR_EDIT
Intent.ACTION_SEND_MULTIPLE
Intent.ACTION_PICK
Intent.ACTION_GET_CONTENT
MediaStore.ACTION_IMAGE_CAPTURE
MediaStore.ACTION_VIDEO_CAPTURE
[C-4-2] PRECISA herdar todas as restrições de usuário da política do dispositivo e selecionar restrições de não usuários(lista abaixo) aplicadas ao usuário principal do dispositivo para esse perfil de usuário adicional.
[C-4-3] PRECISA permitir a gravação de contatos deste perfil adicional apenas pelo estas intents:
[C-4-4] NÃO PODE ter sincronizações de contatos em execução para aplicativos em execução esse perfil de usuário adicional.
- [C-4-14] PRECISA ter permissões e gerenciamento de armazenamento separados para os aplicativos em execução nesse perfil adicional
- [C-4-5] PRECISA permitir somente aplicativos no perfil adicional que tenham um do inicializador para acessar os contatos que já estão acessíveis ao perfil de usuário principal.
Encerrar novos requisitos
9,6. Aviso de SMS premium
O Android inclui suporte para alertar os usuários sobre quaisquer mensagem SMS premium. SMS premium as mensagens de texto são mensagens de texto enviadas a um serviço registrado com uma operadora que pode gerar uma cobrança para o usuário.
Se as implementações de dispositivos declararem suporte a android.hardware.telephony
:
eles:
- [C-1-1] PRECISA avisar os usuários antes de enviar mensagens SMS para números.
identificados por expressões regulares definidas em
/data/misc/sms/codes.xml
no dispositivo. O Android Open Source Project upstream fornece uma implementação que atenda a esse requisito.
9,7. Recursos de segurança
As implementações de dispositivos PRECISAM garantir a conformidade com os recursos de segurança nos dois kernel e plataforma, conforme descrito abaixo.
O Android Sandbox inclui recursos que usam a biblioteca Security-Enhanced Linux (SELinux), o sistema de controle de acesso obrigatório (MAC), o seccomp sandboxing e outros recursos de segurança no kernel do Linux. Implementações de dispositivos:
- [C-0-1] PRECISA manter a compatibilidade com os aplicativos atuais, mesmo quando O SELinux ou qualquer outro recurso de segurança seja implementado abaixo da de análise de dados em nuvem.
- [C-0-2] NÃO PODE ter uma interface do usuário visível quando um sistema a violação é detectada e bloqueada pelo recurso de segurança implementados abaixo da estrutura do Android, mas PODEM ter uma interface do usuário visível quando ocorre uma violação de segurança desbloqueada que resulta em uma exploração bem-sucedida.
- [C-0-3] NÃO PODE implementar o SELinux ou qualquer outro recurso de segurança abaixo do framework do Android, configurável pelo usuário ou desenvolvedor do aplicativo.
- [C-0-4] NÃO PODE permitir um aplicativo que possa afetar outro aplicativo usando uma API (como uma API Device Administration) para configurar uma política que invalide a compatibilidade.
- [C-0-5] PRECISA dividir o framework de mídia em vários processos para que é possível conceder acesso mais restrito a cada processo conforme descrito no site do Android Open Source Project.
- [C-0-6] PRECISA implementar um mecanismo de sandbox do aplicativo do kernel que permite filtrar chamadas do sistema usando uma política configurável de programas com várias linhas de execução. O Android Open Source Project upstream atende a esse ao ativar o seccomp-BPF com o grupo de linhas de execução (TSYNC), conforme descrito na seção "Configuração do kernel" em source.android.com.
A integridade do kernel e os recursos de autoproteção são essenciais para o Android segurança dos dados. Implementações de dispositivos:
- [C-0-7] PRECISA implementar mecanismos de proteção contra estouro do buffer da pilha do kernel.
Exemplos desses mecanismos são
CC_STACKPROTECTOR_REGULAR
eCONFIG_CC_STACKPROTECTOR_STRONG
. - [C-0-8] PRECISA implementar proteções rigorosas de memória do kernel quando executável
o código é somente leitura, os dados somente leitura não são executáveis nem graváveis
os dados graváveis não são executáveis (por exemplo,
CONFIG_DEBUG_RODATA
ouCONFIG_STRICT_KERNEL_RWX
). - [C-0-9] PRECISA implementar tamanhos de objetos estáticos e dinâmicos
verificação de limites de cópias entre o espaço do usuário e o espaço do kernel
(por exemplo,
CONFIG_HARDENED_USERCOPY
) em dispositivos originalmente enviados com o nível da API. 28 ou superior. - [C-0-10] NÃO PODE executar a memória do espaço do usuário ao executar
no modo kernel (por exemplo, PXN de hardware ou emulado via
CONFIG_CPU_SW_DOMAIN_PAN
ouCONFIG_ARM64_SW_TTBR0_PAN
) nos dispositivos enviado originalmente com o nível de API 28 ou superior. - [C-0-11] NÃO PODE ler nem gravar a memória do espaço do usuário na
fora das APIs normais de acesso à cópia do usuário (por exemplo, PAN de hardware ou
emulado via
CONFIG_CPU_SW_DOMAIN_PAN
ouCONFIG_ARM64_SW_TTBR0_PAN
) em dispositivos originalmente fornecidos com o nível 28 da API ou mais recente. - [C-0-12] PRECISA implementar o isolamento da tabela da página do kernel se o hardware estiver
vulnerável à CVE-2017-5754 em todos os dispositivos originalmente enviados com nível de API
28 ou mais recente (por exemplo,
CONFIG_PAGE_TABLE_ISOLATION
ouCONFIG_UNMAP_KERNEL_AT_EL0
). [C-0-13] PRECISA implementar o aumento da proteção de previsão da ramificação se o hardware estiver vulnerável à CVE-2017-5715 em todos os dispositivos originalmente enviados com nível de API 28 ou mais recente (por exemplo,
CONFIG_HARDEN_BRANCH_PREDICTOR
).[C-SR-1] É MUITO RECOMENDADO manter os dados do kernel que é gravado apenas durante a inicialização marcado como somente leitura após inicialização (por exemplo,
__ro_after_init
).[C-SR-2] São RECOMENDADOS ALTAMENTE para randomizar o layout do código do kernel e da memória e para evitar exposições que comprometam a randomização Por exemplo,
CONFIG_RANDOMIZE_BASE
com entropia do carregador de inicialização pela/chosen/kaslr-seed Device Tree node
ouEFI_RNG_PROTOCOL
).[C-SR-3] É FORTEMENTE RECOMENDADO para ativar a integridade do fluxo de controle (CFI) em o kernel para fornecer mais proteção contra ataques de reutilização de código (por exemplo,
CONFIG_CFI_CLANG
eCONFIG_SHADOW_CALL_STACK
).[C-SR-4] É FORTEMENTE RECOMENDADO não desativar a integridade do fluxo de controle (CFI), O Shadow Call Stack (SCS) ou a limpeza de estouro de números inteiros (IntSan) estão ativados componentes em que ele está ativado.
[C-SR-5] É MUITO RECOMENDADO ativar CFI, SCS e IntSan para componentes adicionais do espaço do usuário sensíveis à segurança, conforme explicado em CFI e IntSan (links em inglês).
[C-SR-6] É FORTEMENTE RECOMENDADO para permitir a inicialização de pilha no kernel para evitar o uso de variáveis locais não inicializadas (
CONFIG_INIT_STACK_ALL
ouCONFIG_INIT_STACK_ALL_ZERO
). Além disso, as implementações de dispositivos NÃO DEVEM assumir o valor usado pelo compilador para e inicializar os locais.[C-SR-7] É FORTEMENTE RECOMENDADO para ativar a inicialização de heap no kernel para evitar o uso de alocações de heap não inicializadas (
CONFIG_INIT_ON_ALLOC_DEFAULT_ON
) e NÃO DEVEM assumir o valor usado por ao kernel para inicializar essas alocações.
Se as implementações de dispositivos usam um kernel do Linux capaz de dar suporte SELinux, eles:
- [C-1-1] PRECISA implementar o SELinux.
- [C-1-2] PRECISA configurar o SELinux para o modo de aplicação global.
- [C-1-3] PRECISA configurar todos os domínios no modo de aplicação. Sem modo permissivo domínios são permitidos, incluindo domínios específicos de um dispositivo/fornecedor.
- [C-1-4] NÃO PODE modificar, omitir ou substituir as regras de nunca permitir presentes na pasta system/sepolicy fornecida no código aberto upstream do Android o Project (AOSP) e a política PRECISAM ser compilados com todas as regras de bloqueio presentes, para domínios SELinux do AOSP, bem como domínios específicos do dispositivo/fornecedor.
- [C-1-5] É NECESSÁRIO executar aplicativos de terceiros direcionados ao nível 28 da API ou mais recente. em sandboxes SELinux por aplicativo com restrições de SELinux por aplicativo em cada ao diretório de dados privados do seu aplicativo.
- DEVE manter a política SELinux padrão fornecida na política de SELinux do Android Open Source Project upstream e só adicionar a essa pasta política para a própria configuração específica do dispositivo.
Se as implementações de dispositivos usarem kernel diferente do Linux ou do Linux sem SELinux, eles:
- [C-2-1] PRECISA usar um sistema de controle de acesso obrigatório que seja equivalente ao SELinux.
Se as implementações de dispositivos usarem dispositivos de E/S compatíveis com DMA, elas:
- [C-SR-9] É FORTEMENTE RECOMENDADO para isolar cada dispositivo de E/S capaz de DMA, usando uma IOMMU (por exemplo, ARM SMMU).
O Android tem vários recursos de defesa em profundidade que são essenciais para o dispositivo segurança dos dados. Além disso, o Android se concentra em reduzir as classes principais de bugs comuns que contribuem para a segurança e qualidade insatisfatória.
Para reduzir bugs de memória, as implementações de dispositivos:
- [C-SR-10] É RECOMENDADO que eles sejam testados usando o erro de memória do espaço do usuário ferramentas de detecção como MTE para dispositivos ARMv9, HWASan para dispositivos ARMv8+ ou ASan para outros tipos de dispositivos.
- [C-SR-11] É RECOMENDADO que eles sejam testados usando o erro de memória do kernel ferramentas de detecção como KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS para Dispositivos ARMv9, CONFIG_KASAN_SW_TAGS para dispositivos ARMv8 ou CONFIG_KASAN_GENERIC para outros tipos de dispositivos).
- [C-SR-12] É FORTEMENTE RECOMENDADO usar ferramentas de detecção de erros de memória produção, como MTE, GWP-ASan e KFENCE.
Se as implementações de dispositivos usarem um TEE baseado em Arm TrustZone, elas:
- [C-SR-13] É FORTEMENTE RECOMENDADO usar um protocolo padrão para memória entre o Android e o TEE, como o Arm Firmware Framework para Armv8-A (FF-A).
- [C-SR-14] É FORTEMENTE RECOMENDADO restringir os aplicativos confiáveis apenas a acessar a memória que foi compartilhada explicitamente com eles por meio do comando protocolo. Se o dispositivo tiver suporte para o nível de exceção Arm S-EL2, devem ser aplicadas pelo gerenciador de partições seguras. Caso contrário, ele deve ser aplicada pelo SO TEE.
Iniciar novos requisitos
Uma tecnologia de segurança de memória é uma tecnologia que mitiga pelo menos os seguintes
classes de bugs com alta probabilidade (> 90%) em aplicativos que usam a
android:memtagMode
opção do manifesto:
- 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] É MUITO RECOMENDADO de configurar
ro.arm64.memtag.bootctl_supported
:
Se as implementações do dispositivo definirem a propriedade do sistema
ro.arm64.memtag.bootctl_supported
como verdadeiro, eles:
[C-3-1] PRECISA permitir que a propriedade do sistema
arm64.memtag.bootctl
aceite uma lista separada por vírgulas dos valores a seguir, com o efeito desejado aplicada na próxima reinicialização seguinte:memtag
: uma tecnologia de segurança de memória, conforme definido acima, está ativadamemtag-once
: uma tecnologia de segurança de memória, conforme definido acima, é ativada temporariamente e desativada automaticamente na próxima reiniciarmemtag-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 no momento na inicialização, ele PRECISA também atualizar a propriedade, se a implementação do dispositivo permite modificar o estado sem alterar a propriedade do sistema.[C-SR-16] É FORTEMENTE RECOMENDADO mostrar uma configuração do desenvolvedor que defina "memtag-uma" e reinicializa o dispositivo. Com um carregador de inicialização compatível, o O Android Open Source Project atende aos requisitos acima por meio do protocolo do carregador de inicialização da MTE.
- [C-SR-17] É FORTEMENTE RECOMENDADO para mostrar uma configuração no painel de segurança
Menu de configurações que permite ao usuário ativar
memtag
.
Encerrar novos requisitos
9,8. Privacidade
9.8.1. Histórico de uso
O Android armazena o histórico de escolhas do usuário e o gerencia UsageStatsManager.
Implementações de dispositivos:
- [C-0-1] PRECISA manter um período de retenção razoável desse histórico do usuário.
- [C-SR-1] É FORTEMENTE RECOMENDADO manter o período de retenção de 14 dias como configurado por padrão na implementação do AOSP.
O Android armazena os eventos do sistema usando o StatsLog
.
identificadores e gerencia esse histórico por meio do StatsManager
e do
API do sistema IncidentManager
.
Implementações de dispositivos:
- [C-0-2] É PRECISO incluir apenas os campos marcados com
DEST_AUTOMATIC
no relatório de incidentes criado pela classeIncidentManager
da API do sistema. - [C-0-3] NÃO É NECESSÁRIO usar os identificadores de eventos do sistema para registrar outros eventos.
do que o descrito nos
StatsLog
documentos do SDK. Se eventos adicionais do sistema forem registrados, eles PODEM usar uma identificador atômico diferente no intervalo entre 100.000 e 200.000.
9.8.2. Gravações
Implementações de dispositivos:
- [C-0-1] NÃO PODE pré-carregar nem distribuir componentes de software prontos para uso que enviar informações particulares do usuário (por exemplo, pressionamentos de teclas, texto exibido no tela, relatório de bug) para fora do dispositivo sem o consentimento do usuário ou claro notificações em andamento.
- [C-0-2] PRECISA exibir um aviso do usuário e obter o consentimento explícito do usuário permitindo que todas as informações sensíveis exibidas na tela do usuário sejam capturadas
ativada, incluindo exatamente a mesma mensagem do AOSPsemprecada vez que uma sessão for capturada na telatransmissão ou gravação de telaestáativadoiniciado peloMediaProjection.createVirtualDisplay()
,VirtualDeviceManager.createVirtualDisplay()
, ou APIs proprietárias.NÃO PODE fornecer aos usuários um funcionalidade para desativar a exibição futura do consentimento do usuário. - [C-0-3] O usuário PRECISA ter uma notificação contínua para o usuário durante a transmissão de tela. ou a gravação de tela está ativada. O AOSP atende a esse requisito mostrando uma ícone de notificação em andamento na barra de status.
Iniciar novos requisitos
[C-SR-1] É RECOMENDADO para mostrar um aviso ao usuário exatamente a mesma mensagem implementada no AOSP, mas PODE ser alterado, desde que a mensagem informe claramente ao usuário que todas as informações sensíveis na tela foram capturadas.
[C-0-4] NÃO PODE fornecer aos usuários uma affordance para desativar futuros prompts de o 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 permitiu
associate()
com oandroid.app.role.COMPANION_DEVICE_APP_STREAMING
ou oandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING
do dispositivo.Encerrar novos requisitos
Se as implementações de dispositivos incluem funcionalidades no sistema que
Captura o conteúdo exibido na tela e/ou grava o stream de áudio
reproduzido no dispositivo que não seja pela API do sistema ContentCaptureService
ou
outros meios reservados descritos em
Seção 9.8.6 Dados do ambiente e do SO, são:
- [C-1-1] O usuário PRECISA ter uma notificação em andamento ao usuário esteja ativada e esteja ativamente capturando/gravando.
Se as implementações do dispositivo incluem um componente habilitado para uso, capaz de gravar o áudio do ambiente e/ou gravar o áudio tocado no dispositivo para inferir informações úteis sobre o contexto do usuário, eles:
- [C-2-1] NÃO PODE armazenar no armazenamento persistente no dispositivo nem transmitir o o áudio bruto gravado ou qualquer formato que possa ser convertido de volta o áudio original ou um fax, exceto com o consentimento explícito do usuário.
Um "indicador de microfone" se refere a uma visualização na tela, que fica constantemente visível para o usuário, que não pode ser ocultada, o que os usuários entendem como um microfone usar(por meio de texto, cor, ícone ou alguma combinação exclusiva).
Um "indicador da câmera" se refere a uma visualização na tela, que fica constantemente visível para o usuário e não pode ser ocultada, o que os usuários entendem como uma câmera está em uso (por meio de texto, cor, ícone ou alguma combinação exclusiva).
Após o primeiro segundo exibido, um indicador pode mudar visualmente, como ficando menor e não precisa aparecer como apresentado originalmente e entendido.
O indicador de microfone pode ser mesclado com uma câmera exibida ativamente indicador, desde que o texto, os ícones ou as cores indiquem ao usuário que o uso do microfone tiver começado.
O indicador da câmera pode ser mesclado com um microfone ativo indicador, desde que o texto, os ícones ou as cores indiquem ao usuário que o a câmera começou.
Se as implementações de dispositivo declararem android.hardware.microphone
, elas:
- [C-SR-1] É FORTEMENTE RECOMENDADO mostrar o indicador de microfone quando um app
está acessando dados de áudio do microfone, mas não quando ele está
acessado apenas por
HotwordDetectionService
,SOURCE_HOTWORD
ContentCaptureService
ou apps com os papéis destacados na seção 9.1 Permissões com identificador CDD [C-3-X]. . - [C-SR-2] É FORTEMENTE RECOMENDADO a exibição da lista de itens recentes e ativos
Apps que usam o microfone como retornado
PermissionManager.getIndicatorAppOpUsageData()
, com qualquer atribuição mensagens associadas a elas. - [C-SR-3] É FORTEMENTE RECOMENDADO não ocultar o indicador de microfone para apps do sistema com interfaces do usuário visíveis ou interação direta com o usuário.
Se as implementações de dispositivo declararem android.hardware.camera.any
, elas:
- [C-SR-4] É FORTEMENTE RECOMENDADO a exibição do indicador da câmera quando um app for acessar dados da câmera em tempo real, mas não quando ela só estiver sendo acessada por aplicativos com as funções mencionadas na Seção 9.1 Permissões com CDD identificador [C-3-X].
- [C-SR-5] É FORTEMENTE RECOMENDADO a exibição de apps recentes e ativos usando
câmera conforme retornado de
PermissionManager.getIndicatorAppOpUsageData()
, além de mensagens de atribuição associadas. - [C-SR-6] É FORTEMENTE RECOMENDADO para não ocultar o indicador da câmera para o sistema apps com interfaces do usuário visíveis ou interação direta com o usuário.
9.8.3. Conectividade
Se as implementações de dispositivos tiverem uma porta USB com suporte ao modo de periférico USB, eles:
- [C-1-1] PRECISA apresentar uma interface do usuário solicitando o consentimento antes de permitindo acesso ao conteúdo do armazenamento compartilhado pela porta USB.
9.8.4. Tráfego de rede
Implementações de dispositivos:
- [C-0-1] É NECESSÁRIO pré-instalar os mesmos certificados raiz para os certificados raiz confiáveis pelo sistema Repositório da autoridade certificadora (CA) conforme fornecido no Android Open Source Project.
- [C-0-2] PRECISA enviar com um repositório de CAs raiz de usuário vazio.
- [C-0-3] PRECISA mostrar um aviso ao usuário indicando o tráfego de rede. pode ser monitorada quando uma CA raiz do usuário é adicionada.
Se o tráfego do dispositivo for roteado por uma VPN, as implementações do dispositivo:
- [C-1-1] PRECISA exibir um aviso ao usuário indicando:
- Esse tráfego de rede pode ser monitorado.
- O tráfego de rede está sendo roteado pela VPN específica aplicativo que fornece a VPN.
Se as implementações do dispositivo tiverem um mecanismo ativado e pronto para uso por padrão,
roteia o tráfego de dados de rede por um servidor proxy ou gateway de VPN (por exemplo,
pré-carregando um serviço de VPN com android.permission.CONTROL_VPN
concedido), eles:
- [C-2-1] PRECISA solicitar o consentimento do usuário antes de ativar esse mecanismo.
a menos que a VPN seja ativada pelo controlador de política de dispositivo por meio do
DevicePolicyManager.setAlwaysOnVpnPackage()
. Nesse caso, o usuário não precisa dar um consentimento separado, mas PRECISA ser notificado apenas.
Se as implementações de dispositivo implementam uma affordance do usuário para alternar na "VPN sempre ativa" de um app de VPN de terceiros, elas:
- [C-3-1] PRECISA desativar essa funcionalidade do usuário para apps incompatíveis.
serviço de VPN sempre ativa no arquivo
AndroidManifest.xml
pela configuração doSERVICE_META_DATA_SUPPORTS_ALWAYS_ON
parafalse
.
9.8.5. Identificadores de dispositivo
Implementações de dispositivos:
- [C-0-1] PRECISA impedir o acesso ao número de série do dispositivo. Quando
aplicável, IMEI/MEID, número de série do chip e número de celular internacional
Identidade do assinante (IMSI, na sigla em inglês) de um app, a menos que atenda a uma das seguintes condições
requisitos:
- é um app de operadora assinado verificado pelos fabricantes de dispositivos.
- recebeu a permissão
READ_PRIVILEGED_PHONE_STATE
. - tem privilégios de operadora, conforme definido nos Privilégios de operadora do UICC.
- é um proprietário de dispositivo ou perfil que recebeu o
READ_PHONE_STATE
. - (somente para o número de série do chip/ICCID) tem o requisito de regulamentações locais. que o app detecte alterações na identidade do assinante.
9.8.6. Captura de conteúdo e Pesquisa de appsDados ambientes e do SO
o Android, por meio das APIs do sistema , apoia um mecanismo para que o dispositivo
implementações para capturar as seguintes ContentCaptureService
,
AugmentedAutofillService
, AppSearchGlobalManager.query
ou por outro
meios reservadosinterações de dados entre os aplicativos e
o usuário
dados sensíveis:
- Texto e gráficos renderizados na tela, incluindo, entre outros,
notificações e dados de assistência pelo
AssistStructure
API. - Dados de mídia, como áudio ou vídeo, gravados ou reproduzidos pelo dispositivo.
- Eventos de entrada (por exemplo, tecla, mouse, gesto, voz, vídeo e acessibilidade).
Iniciar novos requisitos
- Qualquer tela ou outros dados enviados pelo
AugmentedAutofillService
para o sistema. - Qualquer tela ou outros dados acessíveis via
Content Capture
API. - Qualquer tela ou outros dados acessíveis pela API
FieldClassificationService
- Todos os dados do aplicativo transmitidos ao sistema pela API
AppSearchManager
e acessível viaAppSearchGlobalManager.query
.
Encerrar novos requisitos
- Quaisquer outros eventos que um aplicativo fornece ao sistema por meio do
Content Capture
ouAppSearchManager
uma API Android e API proprietária.
- Qualquer texto ou outro dado enviado por meio do
TextClassifier API
ao TextClassifier do sistema, ou seja, ao serviço do sistema para entender o significado do texto, além de gerar as próximas ações previstas com base no o texto. - Dados indexados pela implementação da plataforma AppSearch, incluindo, mas não Limitado a texto, gráficos, dados de mídia ou outros dados semelhantes.
Iniciar novos requisitos
- Dados de áudio como resultado do uso
SpeechRecognizer#onDeviceSpeechRecognizer()
pelo reconhecedor de fala Implementação. - Dados de áudio recebidos em segundo plano (continuamente) por
AudioRecord
.SoundTrigger
ou outras APIs de áudio que não resultem em um indicador - Dados da câmera obtidos em segundo plano (continuamente) pelo CameraManager ou outras APIs de câmera e não resulta em um indicador visível para o usuário
Encerrar novos requisitos
Se as implementações de dispositivo capturarem qualquer um dos dados acima, elas:
- [C-1-1] PRECISA criptografar todos esses dados quando armazenados no dispositivo. Isso pode ser realizada com a criptografia baseada em arquivos do Android ou qualquer das criptografias listadas como API versão 26+ descritas em Cipher SDK.
- [C-1-2] NÃO PODE fazer backup de dados brutos ou criptografados usando o Métodos de backup do Android ou qualquer outro .
- [C-1-3] PRECISA enviar apenas esses dados.
e o registrodo dispositivo usando um mecanismo de preservação de privacidade, exceto com o consentimento explícito do usuário sempre que os dados compartilhado. O mecanismo de preservação da privacidade é definida como “aqueles que permitem somente análises agregadas e evitam correspondência de eventos registrados ou resultados derivados para usuários individuais” a evitar que dados por usuário sejam introspectáveis (por exemplo, implementados usando uma tecnologia de privacidade diferencial, comoRAPPOR
). - [C-1-4] NÃO PODE associar esses dados a nenhuma identidade do usuário (como
como
Account
) no dispositivo, exceto com o consentimento explícito do usuário sempre que os dados forem associadas. - [C-1-5] NÃO PODE compartilhar esses dados com outros componentes do SO que não
siga os requisitos descritos na seção atual.
(9.8.6
Captura de ConteúdoNível do SO e ambiente ), exceto com o consentimento explícito do usuário a cada o horário em que é compartilhado. A menos que essa funcionalidade seja criado como uma API do SDK do Android (AmbientContext
,HotwordDetectionService
). - [C-1-6] PRECISA fornecer recursos ao usuário para apagar dados que
as
implementação ou meios reservados coletamContentCaptureService
sequando os dados são armazenados de qualquer forma no dispositivo. Se o usuário optar por apagar os dados, PRECISA remover todos os dados históricos dados. - [C-1-7] PRECISA fornecer recursos para o usuário recusar os dados coletados. via AppSearch ou meios reservados para exibição na plataforma Android Por exemplo: acesso rápido.
- [C-SR-1] É RECOMENDADO NÃO solicitar a permissão de INTERNET.
- [C-SR-2] É FORTEMENTE RECOMENDADO que você só acesse a Internet usando o APIs estruturadas baseadas em implementações de código aberto disponíveis publicamente.
Iniciar novos requisitos
- [C-SR-4] É FORTEMENTE RECOMENDADO que sejam implementadas com a API do SDK do Android ou um repositório de código aberto semelhante de propriedade do OEM; e / ou ser realizado em uma Implementação no modo sandbox (consulte 9.8.15 Implementações da API no modo sandbox).
Encerrar novos requisitos
Se as implementações de dispositivos incluem um serviço que implementa a API do sistema
ContentCaptureService
, AppSearchManager.index
ou qualquer serviço reservado
que captura os dados conforme descrito acima, eles:
- [C-2-1] NÃO PODE permitir que os usuários substituam os serviços por um aplicativo ou serviço instalável pelo usuário e PRECISA permitir somente o serviços pré-instalados para capturar esses dados.
- [C-2-2] NÃO PODE permitir outros apps além dos serviços pré-instalados mecanismo de pesquisa para coletar esses dados.
- [C-2-3] PRECISA fornecer recursos do usuário para desativar os serviços.
- [C-2-4] NÃO PODE omitir affordance do usuário para gerenciar permissões do Android que são mantidos pelos serviços e seguem as permissões do Android conforme descrito na Seção 9.1. Permissão.
[C-SR-3] É FORTEMENTE RECOMENDADO para manter os serviços separados dos outros componentes do sistema(por exemplo, não vincular os IDs de processos de serviço ou compartilhamento) exceto:
- Telefonia, Contatos, interface do sistema e mídia
O Android, pelo SpeechRecognizer#onDeviceSpeechRecognizer()
, permite
para realizar o reconhecimento de fala no dispositivo sem envolver a rede.
Qualquer implementação do SpeechReconhecedor no dispositivo PRECISA seguir as políticas
descritos nesta seção.
9.8.7. Acesso à área de transferência
Implementações de dispositivos:
[C-0-1] NÃO PODE retornar dados recortados da área de transferência (por exemplo, por meio do método
ClipboardManager
a menos que o terceiro app é o IME padrão ou é o app em foco no momento.[C-0-2] PRECISA limpar os dados da área de transferência no máximo 60 minutos após a última vez. colocado em uma área de transferência ou lido de uma área de transferência.
9.8.8. Local
O local inclui informações na classe Location do Android( como Latitude, Longitude, Altitude), bem como identificadores que podem ser convertidos para "Location". A localização pode ser tão adequada quanto DGPS (Sistema de Posicionamento Global Diferencial) ou aproximada quanto aos locais no nível do país (como o local do código do país - MCC - Celular código do país).
Veja a seguir uma lista de tipos de local que derivam diretamente o valor da local ou podem ser convertidos à localização de um usuário. Esta não é uma lista completa mas deve ser usado como um exemplo de qual local pode ou não ser derivados indiretamente de:
- GPS/GNSS/DGPS/PPP
- Solução de Posicionamento Global ou Sistema Global de Navegação por Satélite ou Solução de posicionamento global diferencial
- Isso também inclui medições brutas de GNSS e o status de GNSS
- O local preciso pode ser derivado das medições GNSS brutas
- Tecnologias sem fio com identificadores exclusivos, como:
- Pontos de acesso Wi-Fi (MAC, BSSID, Nome ou SSID)
- Bluetooth/BLE (MAC, BSSID, nome ou SSID)
- UWB (MAC, BSSID, nome ou SSID)
- ID de torre de celular (3G, 4G, 5G... incluindo todos os modems celulares futuros) tecnologias que têm identificadores exclusivos)
Como ponto de referência principal, consulte as APIs do Android que exigem ACCESS_FINE_Location ou ACCESS_COARSE_Location.
Implementações de dispositivos:
- [C-0-1] NÃO É POSSÍVEL ativar/desativar a configuração de localização do dispositivo nem o Wi-Fi/Bluetooth configurações de verificação sem o consentimento explícito do usuário ou a iniciação dele.
- [C-0-2] PRECISA fornecer recursos para o usuário acessar a localização. informações, incluindo solicitações de localização recentes, uso e permissões no nível do app de busca por Wi-Fi/Bluetooth para determinar a localização.
- [C-0-3] PRECISA garantir que o app use a API Emergency Location Bypass [LocationRequest.setLocationSettingsIgnored()] é uma emergência iniciada pelo usuário sessão (por exemplo, disque 911 ou envie uma mensagem de texto para 190). Para o setor automotivo, no entanto, um veículo pode iniciar uma sessão de emergência sem interação do usuário ativo no caso um acidente/acidente é detectado (por exemplo, para atender aos requisitos de chamada telefônica);
- [C-0-4] PRECISA preservar a capacidade da API Emergency Location Bypass de ignorar as configurações de localização do dispositivo sem mudar as configurações.
- [C-0-5] PRECISA programar uma notificação para lembrar o usuário depois de abrir o app
o segundo plano acessou a localização dela usando o
Permissão [
ACCESS_BACKGROUND_LOCATION
].
9.8.9. Apps instalados
Os apps Android destinados ao nível 30 da API ou mais recente não podem ver detalhes sobre outros apps instalados por padrão. Consulte Visibilidade do pacote na documentação do SDK).
Implementações de dispositivos:
- [C-0-1] NÃO É POSSÍVEL expor a nenhum app direcionado aos detalhes da API de nível 30 ou mais recente. sobre qualquer outro aplicativo instalado, a menos que o aplicativo já possa ver detalhes sobre o outro app instalado pelas APIs gerenciadas. Isso inclui, mas não não se limitam aos detalhes expostos por quaisquer APIs personalizadas adicionadas pelo dispositivo ou pode ser acessado pelo sistema de arquivos.
- [C-0-2] NÃO PODE conceder a qualquer aplicativo acesso de leitura ou gravação a arquivos de qualquer outro
diretório dedicado e específico ao app
no armazenamento externo. As únicas exceções são as seguintes:
- A autoridade do provedor de armazenamento externo (por exemplo, apps como DocumentsUI).
- "Download Provider", que usa a autoridade do provedor "downloads" para fazer o download de arquivos para o armazenamento do app.
- Aplicativos de protocolo de transferência de mídia (MTP, na sigla em inglês) assinados pela plataforma que usam o permissão privilegiada ACCESS_MTP para permitir a transferência de arquivos para em outro dispositivo.
- Apps que instalam outros apps e têm permissão INSTALL_PACKAGES só podem acessar diretórios "obb" para gerenciar Arquivos de expansão APK
9.8.10. Relatório de bugs de conectividade
Se as implementações de dispositivos declararem a flag de recurso android.hardware.telephony
,
eles:
- [C-1-1] PRECISA oferecer suporte à geração de relatórios de bugs de conectividade por
BUGREPORT_MODE_TELEPHONY
com BugreportManager. - [C-1-2] PRECISA ter o consentimento do usuário sempre que
BUGREPORT_MODE_TELEPHONY
for usados para gerar um relatório e NÃO PODEM solicitar que o usuário autorize todos os futuras solicitações do aplicativo. - [C-1-3] NÃO PODE retornar o relatório gerado ao aplicativo solicitante sem o consentimento explícito do usuário.
- [C-1-4] Os relatórios gerados usando
BUGREPORT_MODE_TELEPHONY
PRECISAM conter pelo menos as seguintes informações:TelephonyDebugService
despejadosTelephonyRegistry
despejadosWifiService
despejadosConnectivityService
despejados- Um despejo da instância
CarrierService
do pacote de chamada (se vinculado). - Buffer de registro de rádio
- Despejo
SubscriptionManagerService
- [C-1-5] NÃO PODE incluir o seguinte nos relatórios gerados:
- Qualquer tipo de informação que não esteja diretamente relacionada à conectividade depuração.
- Qualquer tipo de registros de tráfego de aplicativos instalados pelo usuário ou perfis detalhados de aplicativos/pacotes instalados pelo usuário (UIDs são aceitáveis, nomes de pacotes são não).
- PODE incluir informações adicionais que não estão associadas a nenhum usuário identidade. (por exemplo, registros do fornecedor).
Se as implementações de dispositivos incluírem informações adicionais (por exemplo, registros do fornecedor) no relatórios de bugs e se as informações têm privacidade/segurança/bateria/armazenamento/memória impacto, eles:
- [C-SR-1] É ALTAMENTE RECOMENDADO ter uma configuração de desenvolvedor definida como padrão
desativado. A implementação de referência do AOSP atende a isso, fornecendo o
Enable verbose vendor logging
opção nas configurações do desenvolvedor para incluir mais registros de fornecedores específicos do dispositivo nos relatórios de bugs.
9.8.11. Compartilhamento de blobs de dados
Android, por meio do BlobStoreManager permite que apps contribuam com blobs de dados para que o sistema seja compartilhado com um completo de aplicativos.
Se as implementações de dispositivos forem compatíveis com blobs de dados compartilhados, conforme descrito nas Documentação do SDK, eles:
- [C-1-1] NÃO PODE compartilhar blobs de dados pertencentes a apps além do que eles para permitir (ou seja, o escopo do acesso padrão e as outras que podem ser especificados usando BlobStoreManager.session#allowPackageAccess(); BlobStoreManager.session#allowSameSignatureAccess(), ou BlobStoreManager.session#allowPublicAccess() NÃO PODE ser modificado). A implementação de referência do AOSP atende a essas e cumprimento de requisitos regulatórios.
- [C-1-2] NÃO É POSSÍVEL enviar os hashes seguros para fora do dispositivo nem compartilhar com outros apps os hashes seguros de blobs de dados usados para controlar o acesso.
9.8.12. Identificação de música
O Android, por meio da API MusicRecognitionManager do sistema, oferece suporte a um mecanismo para implementações de dispositivos para solicitar reconhecimento de música, com base em uma gravação de áudio e delegar o reconhecimento de música a um app privilegiado que implementa o API MusicRecognitionService.
Se as implementações de dispositivos incluem um serviço que implementa a API do sistema MusicRecognitionManager ou qualquer serviço reservado que transmita dados de áudio como descritos acima, eles:
- [C-1-1] PRECISA garantir que o autor da chamada do MusicRecognitionManager mantenha o
Permissão para
MANAGE_MUSIC_RECOGNITION
- [C-1-2] PRECISA impor que um único sistema de reconhecimento de música aplicativo implementa MusicRecognitionService.
- [C-1-3] NÃO PODE permitir que os usuários substituam o MusicRecognitionManagerService ou MusicRecognitionService com um aplicativo ou serviço instalável pelo usuário.
- [C-1-4] PRECISA garantir que, quando o MusicRecognitionManagerService acessa o gravação de áudio e o encaminha para o aplicativo implementando a MusicRecognitionService, o acesso ao áudio é rastreado por meio de invocações de AppOpsManager.noteOp / startOp
Se as implementações do dispositivo MusicRecognitionManagerService ou O MusicRecognitionService armazena todos os dados de áudio capturados. Eles:
- [C-2-1] NÃO É POSSÍVEL armazenar impressões digitais de áudio ou áudio brutas em disco de nenhuma forma, ou na memória por mais de 14 dias.
- [C-2-2] NÃO PODE compartilhar esses dados além do MusicRecognitionService, exceto com o consentimento explícito do usuário sempre que é compartilhado.
9.8.13. SensorPrivacyManager
Se as implementações de dispositivos fornecerem ao usuário uma funcionalidade de software para desativar a entrada de câmera e/ou microfone para a implementação do dispositivo, eles:
- [C-1-1] PRECISA retornar "true" com precisão. nos formatos supportsSensorToggle() Método de API.
- [C-1-2] PRECISA, quando um app tenta acessar uma câmera ou um microfone bloqueado. apresentar ao usuário uma funcionalidade de usuário não dispensável que claramente indica que o sensor está bloqueado e requer uma escolha para continuar bloquear ou desbloquear de acordo com a implementação do AOSP que atenda a requisito fundamental.
- [C-1-3] PRECISA transmitir apenas dados de áudio e câmera em branco (ou falsos) para apps e não informa um código de erro porque o usuário não ligou a câmera. nem microfone pela affordance do usuário apresentada de acordo com [C-1-2] acima.
Iniciar novos requisitos
9.8.14. Credential Manager
Removido.
9.8.15. Implementações da API no modo sandbox
O Android, por meio de um conjunto de APIs delegadas, fornece um mecanismo para processar dados Dados do SO e do ambiente. Esse processamento pode ser delegado com acesso privilegiado e capacidades de comunicação reduzidas, conhecido como Implementação da 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 em implementações de código aberto públicas que preservam a privacidade ou indiretamente por meio de APIs do SDK do Android. O papel que preserva a privacidade mecanismo é definido como "aqueles que permitem apenas análises agregadas e impedir a correspondência de eventos registrados ou resultados derivados a usuários individuais", para evitar que dados por usuário sejam introspectáveis (por exemplo, implementados usando uma tecnologia de privacidade diferencial, RAPPOR).
- [C-0-3] PRECISA manter os serviços separados de outros componentes do sistema
(por exemplo, não vincule os IDs de processo de serviço ou compartilhamento), exceto pelas
seguintes:
- 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 do Assistente).
- [C-0-6] NÃO PODE permitir outros apps além dos serviços pré-instalados mecanismo de pesquisa para coletar esses dados. A menos que esse recurso de captura é implementado com uma API Android SDK.
- [C-0-7] PRECISA fornecer recursos do usuário para desativar os serviços.
- [C-0-8] NÃO PODE omitir affordance do usuário para gerenciar permissões do Android que são mantidos pelos serviços e seguem o modelo de permissões do Android. descritos em Seção 9.1. Permissão.
9.8.16. Áudio contínuo e dados da câmera
Além dos requisitos descritos em 9.8.2 Gravação, 9.8.6 Níveis de SO e dados ambientes e implementações da API sandbox 9.8.15, implementações que usar dados de áudio recebidos em segundo plano (continuamente) por meio de AudioRecord, SoundTrigger ou outras APIs de áudio OU dados de câmera obtidos em segundo plano (continuamente) pelo CameraManager ou outras APIs Camera:
- [C-0-1] PRECISA aplicar um indicador correspondente (câmera e/ou microfone como
de acordo com a seção 9.8.2 Gravação), a menos que:
- Esse acesso é realizado em uma implementação no modo sandbox (consulte 9.8.15 Implementação de API no modo sandbox), por meio de um pacote contendo um ou mais dos seguintes papéis: Inteligência de interface do sistema, Inteligência de áudio ambiente do sistema, Inteligência de áudio do sistema, Inteligência de notificações do sistema, Inteligência de texto do sistema, ou Inteligência visual do sistema.
- O acesso é realizado por meio de um sandbox, implementado e
aplicada por mecanismos no AOSP (
HotwordDetectionService
,WearableSensingService
eVisualQueryDetector
). - O acesso ao áudio é realizado para fins de assistência pelo
App do Assistente, fornecendo
SOURCE_HOTWORD
como fonte de áudio. - O acesso é realizado pelo sistema e implementado com com código-fonte aberto.
- [C-SR-1] É FORTEMENTE RECOMENDADO exigir o consentimento do usuário para cada que utilizam esses dados e ficam desativados por padrão.
- [C-SR-2] RECOMENDOU FORTEMENTE a aplicar o mesmo tratamento (por exemplo, seguir as restrições descritas em 9.8.2 Gravação, 9.8.6 Dados do ambiente e do SO 9.8.15 Implementações da API no modo sandbox e 9.8.16 Áudio e câmera contínuos para 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 uma
não criptografado fora do SO Android, implementação em sandbox ou um sandbox
funcionalidade criada por WearableSensingManager
, faça o seguinte:
- [C-1-1] PRECISA indicar ao dispositivo wearable remoto que exibir um indicador adicional lá.
Se os dispositivos oferecerem a capacidade de interagir com um aplicativo de assistente digital sem a palavra-chave atribuída (tratando consultas genéricas do usuário ou analisando presença do usuário pela câmera):
- [C-2-1] PRECISA garantir que essa implementação seja fornecida por um pacote contendo a
android.app.role.ASSISTANT
. - [C-2-2] PRECISA garantir que essa implementação use
HotwordDetectionService
. e/ouVisualQueryDetectionService
APIs do Android.
9.8.17. Telemetry
O Android armazena registros do sistema e do app usando as APIs StatsLog. Esses registros são gerenciados via APIs do StatsManager, que podem ser usadas por aplicativos de sistema com privilégios.
O StatsManager também oferece uma maneira de coletar dados categorizados como dados de privacidade
sensíveis de dispositivos com um mecanismo de preservação da privacidade. Especificamente,
A API StatsManager::query
possibilita consultar métricas restritas
categorias definidas
no StatsLog.
As consultas de implementação e a coleta de métricas restritas Gerenciador de estatísticas:
- [C-0-1] PRECISA ser o único aplicativo/implementação no dispositivo e manter
a permissão
READ_RESTRICTED_STATS
. - [C-0-2] PRECISA enviar somente dados de telemetria e o registro do dispositivo usando um mecanismo de preservação da privacidade. O mecanismo de preservação de privacidade é definido como "aqueles que permitem somente análise agregada e impedem a correspondência de eventos registrados ou resultados derivados para usuários individuais", a fim de evitar que qualquer dados por usuário sendo introspectivos (por exemplo, implementados usando um diferencial tecnologia de privacidade, como RAPPOR).
- [C-0-3] NÃO PODE associar esses dados a nenhuma identidade do usuário (como Account) no dispositivo.
- [C-0-4] NÃO PODE compartilhar esses dados com outros componentes do SO que não seguem. requisitos descritos na seção atual (9.8.17 Preservação da privacidade telemetria).
- [C-0-5] PRECISA fornecer recursos do usuário para ativar/desativar a preservação da privacidade. a coleta, o uso e o compartilhamento de telemetria.
- [C-0-6] PRECISA fornecer recursos ao usuário para apagar dados que coleta se os dados estão armazenados de alguma forma no dispositivo. Se o usuário optou por apagar os dados, PRECISA remover todos os dados atualmente armazenados no o dispositivo.
- [C-0-7] PRECISA divulgar a implementação do protocolo que preserva a privacidade em um repositório de código aberto.
- [C-0-8 ]É NECESSÁRIO aplicar as políticas de saída de dados nesta seção para bloquear a coleta de dados em categorias de métricas restritas definidas em StatsLog.
Encerrar novos requisitos
9,9. Criptografia do armazenamento de dados
Todos os dispositivos PRECISAM atender aos requisitos da seção 9.9.1. Os dispositivos iniciados em um nível de API anterior ao deste documento não isento dos requisitos das seções 9.9.2 e 9.9.3; em vez disso, eles PRECISA atender aos requisitos da seção 9.9 da Política de compatibilidade do Android Documento de definição correspondente ao nível da API em que o dispositivo foi iniciado.
9.9.1. Inicialização direta
Implementações de dispositivos:
[C-0-1] PRECISA implementar as APIs do modo de inicialização direta, mesmo que ela não é compatível com a criptografia de armazenamento.
[C-0-2] O
ACTION_LOCKED_BOOT_COMPLETED
eACTION_USER_UNLOCKED
As intents ainda DEVEM ser transmitidas para sinalizar aplicativos cientes do Direct Boot que Os locais de armazenamento criptografado pelo dispositivo (DE) e criptografado por credencial (CE, na sigla em inglês) são disponíveis para o usuário.
9.9.2. Requisitos de criptografia
Implementações de dispositivos:
- [C-0-1] PRECISA criptografar o aplicativo como privado
dados (partição
/data
), bem como a partição de armazenamento compartilhado do aplicativo (partição/sdcard
) se for uma parte permanente e não removível do dispositivo. - [C-0-2] PRECISA ativar a criptografia do armazenamento de dados por padrão no momento o usuário tiver concluído a experiência de configuração pronta para uso.
[C-0-3] PRECISA atender à criptografia de armazenamento de dados acima. requisito implementando um dos dois métodos de criptografia a seguir:
- Criptografia baseada em arquivos (FBE) e Criptografia de metadados conforme descrito na seção 9.9.3.1.
- Criptografia em nível de bloco por usuário, conforme descrito na seção 9.9.3.2.
9.9.3. Métodos de criptografia
Se as implementações de dispositivos forem criptografadas, elas:
- [C-1-1] PRECISA inicializar sem desafiar o usuário quanto a credenciais e
permitir que apps com reconhecimento de inicialização direta acessem o armazenamento criptografado do dispositivo (DE)
depois que a mensagem
ACTION_LOCKED_BOOT_COMPLETED
é transmitida. - [C-1-2] PRECISA permitir o acesso ao armazenamento criptografado por credencial (CE, na sigla em inglês) apenas após
o usuário desbloqueou o dispositivo informando as credenciais
(por exemplo, senha, PIN, padrão ou impressão digital) e o
ACTION_USER_UNLOCKED
é transmitida. - [C-1-13] NÃO PODE oferecer nenhum método para desbloquear o armazenamento protegido CE sem as credenciais fornecidas pelo usuário, uma chave de garantia registrada ou retomar a implementação na reinicialização atendendo aos requisitos em seção 9.9.4.
- [C-1-4] PRECISA usar a Inicialização verificada.
9.9.3.1. Criptografia baseada em arquivos e metadados
Se as implementações de dispositivos usam criptografia baseada em arquivos com criptografia de metadados, eles:
- [C-1-5] PRECISA criptografar conteúdos de arquivos e metadados do sistema de arquivos usando AES-256-XTS ou Adiantum. O AES-256-XTS se refere ao Padrão de criptografia avançada com comprimento de chave de criptografia de 256 bits, operada no modo XTS; toda a extensão é de 512 bits. Adiantum refere-se a Adiantum-XChaCha12-AES, conforme especificado em https://github.com/google/adiantum Os metadados do sistema de arquivos são dados como tamanhos, propriedade, modos e atributos estendidos (xattrs).
- [C-1-6] PRECISA criptografar nomes de arquivos usando AES-256-CBC-CTS, AES-256-HCTR2; ou Adiantum.
- [C-1-12] Se o dispositivo tiver o Padrão de criptografia avançada (AES) (como extensões de criptografia ARMv8 em dispositivos baseados em ARM ou AES-NI em dispositivos baseados em x86), depois as opções baseadas em AES acima para nome do arquivo. conteúdos do arquivo e a criptografia de metadados do sistema de arquivos PRECISA ser usada, não Adiantum.
- [C-1-13] PRECISA usar uma chave com criptografia forte e irreversível função de derivação (por exemplo, HKDF-SHA512) para derivar qualquer subchave necessária (por exemplo, por arquivo) das chaves CE e DE. "Criptograficamente forte e irreversível" significa que a função de derivação de chaves tem força de segurança de pelo menos 256 bits e se comporta como uma função pseudoaleatória família sobre as entradas.
- [C-1-14] NÃO PODE usar as mesmas chaves ou subchaves de criptografia baseada em arquivos (FBE, na sigla em inglês) para diferentes propósitos criptográficos (por exemplo, para criptografia e chaves ou para dois algoritmos de criptografia diferentes).
- [C-1-15] PRECISA garantir que todos os blocos não excluídos do conteúdo dos arquivos criptografados no armazenamento permanente foram criptografadas usando combinações de chaves de criptografia vetor de inicialização (IV) que dependem do arquivo e do deslocamento dentro o arquivo. Além disso, todas essas combinações PRECISAM ser distintas, exceto quando a criptografia é feita com hardware em linha que suporta apenas uma Comprimento de IV de 32 bits.
- [C-1-16] PRECISA garantir que todos os nomes de arquivo criptografados não excluídos nos arquivos armazenamento em diretórios diferentes era criptografado usando combinações distintas de chave de criptografia e vetor de inicialização (IV, na sigla em inglês).
[C-1-17] PRECISA garantir que todos os blocos de metadados do sistema de arquivos criptografados o armazenamento permanente foram criptografados com combinações distintas de chaves de criptografia e vetor de inicialização (IV).
Chaves que protegem as áreas de armazenamento CE e DE e os metadados do sistema de arquivos:
- [C-1-7] PRECISA estar vinculado criptograficamente a um Keystore protegido por hardware. Este keystore PRECISA estar vinculado à Inicialização verificada e ao hardware do dispositivo. raiz de confiança.
- [C-1-8] As chaves CE PRECISAM estar vinculadas às credenciais da tela de bloqueio de um usuário.
- [C-1-9] As chaves CE PRECISAM ser vinculadas a uma senha padrão quando