A partir de 27 de março de 2025, recomendamos usar android-latest-release em vez de aosp-main para criar e contribuir com o AOSP. Para mais informações, consulte Mudanças no AOSP.

Esta página foi traduzida pela API Cloud Translation.

Módulo auxiliar de interação com o dispositivo do CTS

No Android 11 ou versões mais recentes, os módulos auxiliares de interação com dispositivos do Teste de compatibilidade (CTS) permitem personalizar como determinados testes do CTS interagem com a interface do usuário (UI) em um dispositivo específico. Isso significa que ações, como substituir um elemento da interface que não está coberto pelo Documento de definição de compatibilidade do Android (CDD) ou pela documentação da API, podem ser feitas sem reprovar no CTS.

Os OEMs que querem personalizar a interface do Android durante o desenvolvimento do produto e precisam passar no CTS podem implementar módulos auxiliares. Se você usa a implementação padrão do Android, não é necessário fazer mais nada.

Implementar módulos auxiliares

Requisitos para personalizar a interface

Verifique os módulos CDD ou Mainline para conferir os requisitos de interface. Se a interface desejada for coberta pelos módulos CDD ou Mainline, ela não poderá ser personalizada.

Se os testes do CTS que interagem com a interface desejada não usarem o framework auxiliar, essa interface não poderá ser personalizada. Trabalhe com o proprietário do teste para converter o módulo de teste antes que a interface possa ser alterada.

Caso contrário, personalize a interface.

Fluxo de trabalho de implementação

Personalize a interface conforme necessário para seu produto específico.
Designar os módulos auxiliares do AOSP atuais como subclasses para os módulos de teste do CTS que precisam interagir com a interface. Substitua as interações necessárias de acordo com a interface personalizada. As substituições variam de acordo com o tipo de mudança.
- As subclasses de OEM estão em um pacote de OEM, como com.[oem].cts.helpers.
- Cada subclasse de OEM tem um prefixo comum que a distingue da implementação do AOSP, que tem o prefixo Default.
Crie os helpers em um APK seguindo estas convenções de execução de testes.
- Android.bp precisa declarar android_test_helper_app com o mesmo nome do pacote contido.
- AndroidManifest.xml para o APK precisa declarar uma propriedade de metadados chamada interaction-helpers-prefix com o valor do prefixo de classe escolhido no item anterior.
- O app precisa depender de cts-helpers-core, cts-helpers-interfaces e com.android.cts.helpers.aosp. Se os helpers do OEM implementarem todas as interfaces relevantes, com.android.cts.helpers.aosp será opcional.
Defina a propriedade ro.vendor.cts_interaction_helper_packages na imagem do dispositivo para incluir o nome do APK. Se você precisar separar as implementações de assistente em vários APKs, essa propriedade poderá conter uma lista de pacotes separados por dois-pontos.
Verifique se o APK está disponível no diretório testcases ao executar o Tradefed para CTS. Se necessário, confirme se a classe de implementação de helper esperada foi escolhida examinando as mensagens do logcat.
Opcional, mas altamente recomendado: envie sua implementação de helper para o AOSP ou disponibilize para testes de terceiros.

Exemplo de implementação de helper

Por exemplo, CtsPrintTestCases espera um auxiliar com a interface definida em ICtsPrintHelper. A implementação do AOSP é chamada de com.android.cts.helpers.aosp.DefaultCtsPrintHelper.

Se você personalizar a interface de impressão, poderá criar com.oem.cts.helpers.OemCtsPrintHelper que cria subclasses de DefaultCtsPrintHelper. android_test_helper_app em Android.bp é chamado de com.oem.cts.helpers, que produz com.oem.cts.helpers.apk, e declara interaction-helpers-prefix como Oem em AndroidManifest.xml.

A propriedade do dispositivo ro.vendor.cts_interaction_helper_packages está definida como com.oem.cts.helpers.

Implementações de referência

As implementações de referência incluem interfaces em cts/libs/helpers e os helpers padrão do AOSP em cts/helpers. A interface de nível superior está documentada em cts/libs/helpers/core/src/com/android/cts/helpers/ICtsDeviceInteractionHelper.java.

Para conectar o teste do CTS aos respectivos helpers, os proprietários do teste podem usar a definição @Rule documentada em cts/libs/helpers/core/src/com/android/cts/helpers/DeviceInteractionHelperRule.java.

Cada módulo do CTS que usa o framework e o comportamento esperado do helper é documentado em uma interface definida em cts/libs/helpers/core/src/com/android/cts/helpers.

Como executar testes do CTS

Testar sem helpers

Além de uma propriedade, a opção de testar sem helpers não existe em tempo de execução no dispositivo, mas modifica opcionalmente como os testes do CTS interagem com o dispositivo. Se você precisar executar o CTS sem as implementações de helper, terá duas opções:

Remova a propriedade ro.vendor.cts_interaction_helper_packages do dispositivo. Isso impede que os helpers sejam usados completamente nessa build.
Remova o APK auxiliar do diretório testcases antes de executar o CTS. Isso impede que os helpers sejam usados por qualquer execução até que o APK seja restaurado para testcases.

É possível alterar as configurações padrão com argumentos do Tradefed e o controle de propriedade ro.vendor.cts_interaction_helper_packages, que é de onde o APK auxiliar é carregado.

Confira a seguir os valores ou intervalos esperados para cada uma das configurações disponíveis.

ro.vendor.cts_interaction_helper_packages é uma string separada por dois-pontos que contém nomes de pacotes. Ele pode ter qualquer valor que seja uma opção de pacote válida para a implementação de helper do OEM.
cts-tradefed aceita um argumento device-interaction-helper:property-name que muda temporariamente a propriedade esperada para uma execução de teste, como --module-arg 'CtsPrintTestCases:{device-interaction-helper}property-name:debug.cts.hlp'. O valor do nome da propriedade pode ser qualquer propriedade definida no dispositivo. O valor da propriedade segue as mesmas restrições da propriedade ro.vendor.cts_interaction_helper_packages descrita acima.

Como testar com personalizações

Por padrão, as implementações de referência passam no CTS no Android padrão. Verifique se as implementações de parceiros passam no CTS com personalizações de UI. Execute os módulos do CTS que cobrem a interface ou os recursos personalizados.

Alguns módulos ou helpers do CTS ainda não são compatíveis com algumas personalizações.

Um módulo do CTS que interage com a interface do usuário que você quer personalizar pode não usar a estrutura auxiliar. Espera-se que os módulos do CTS sejam convertidos para a estrutura auxiliar com base na demanda e nas prioridades do proprietário do teste. Faça solicitações de conversão de arquivos no início do processo para garantir que a conversão seja programada, assim como as solicitações de mudanças no CTS para oferecer suporte aos recursos planejados.
As funções fornecidas por um helper atual podem não atender totalmente às personalizações que você quer fazer. As funções auxiliares precisam abstrair as dependências da interface. Se uma função auxiliar tiver uma dependência de UI indiretamente, isso poderá ser tratado de maneira semelhante a bugs no CTS.

Módulo auxiliar de interação com o dispositivo do CTS Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.