Desde o Android 5.0, a operação adequada da pilha de rede do Android no Linux os kernels exigem várias confirmações enviadas há pouco tempo ou ainda não o fizeram upstream. Não é fácil verificar manualmente a funcionalidade necessária do kernel ou rastrear os commits ausentes, de modo que a equipe do Android está compartilhando os testes usados para garantir que o kernel se comporte como esperado.
Motivos para executar os testes
Esses testes existem para três motivos:
- A versão exata do kernel do Linux usado em um dispositivo é são específicos do dispositivo, e é difícil saber se um kernel funciona corretamente sem executar os testes.
- O encaminhamento de portas e backport de patches do kernel para diferentes versões do kernel ou as árvores de dispositivos podem introduzir problemas sutis que são impossíveis de detectar sem para executar os testes.
- Novos recursos de rede podem exigir uma nova funcionalidade do kernel ou bug do kernel e correções.
Em caso de reprovação, a pilha de rede do dispositivo comporta-se de maneira incorreta, causando bugs de conectividade visíveis ao usuário (como falhas redes Wi-Fi). É provável que o dispositivo também falhe no Teste de compatibilidade do Android Suite (CTS).
Usar os testes
Os testes usam o User-Mode Linux para inicializar o como um processo em uma máquina host Linux. Consulte Como estabelecer um ambiente de build para as versões adequadas do sistema operacional. O framework de teste de unidade inicializa o kernel com uma imagem de disco apropriada e executa os testes a partir da do sistema de arquivos do host. Os testes são escritos em Python e usam interfaces TAP para sobre o comportamento do kernel e a API do soquete.
Compile o kernel para ARCH=um
Para que os testes sejam executados,
o kernel precisa ser compilado para ARCH=um SUBARCH=x86_64. Esta é uma
com suporte tanto upstream quanto nas árvores comuns do kernel do Android
(como android-4.4). Mas às vezes o dispositivo
os kernels não são compilados nesse modo porque as árvores de dispositivos contêm
específico do dispositivo ou do hardware em arquivos comuns (por exemplo,
sys/exit.c).
Em muitos casos, é suficiente garantir que
o código específico de hardware está por trás de uma #ifdef. Normalmente, isso deve
ser uma #ifdef em uma opção de configuração que controle
recurso relevante para o código. Se não houver essa opção de configuração, coloque
código específico de hardware dentro de blocos #ifndef CONFIG_UML.
Em
geral, corrigir isso deve ser responsabilidade do provedor da árvore de kernel
por exemplo, o chipset ou o fornecedor do SoC. Estamos trabalhando com OEMs e fornecedores para garantir
que os kernels atuais e futuros compilam para ARCH=um
SUBARCH=x86_64 sem exigir nenhuma mudança.
Executar os testes
Os testes estão em kernel/tests/net/test.
Recomendamos que os testes sejam executados no AOSP principal porque eles
são os mais atualizados. em alguns casos, recursos do kernel que são necessários para
a operação adequada em determinada versão do Android ainda não têm cobertura total de teste
da versão em questão. Para mais informações sobre como executar os testes, consulte a documentação do kernel
arquivo README de teste de rede. Basicamente, na parte superior da sua árvore de kernel, execute:
ANDROID_TREE/kernel/tests/net/test/run_net_test.sh all_tests.sh
Passar nos testes
O teste de rede do kernel Python
os arquivos de origem contêm comentários que especificam confirmações do kernel conhecidas como
necessárias para passar nos testes. Os testes devem passar nas árvores de kernel comuns - todas
ramificações comuns do kernel android-4.4 e superiores na
kernel/common
no AOSP. Portanto, passar nos testes em um kernel é apenas uma questão de
fusão contínua da ramificação comum do kernel correspondente.
Contribuições
Relatar problemas
Informe qualquer problema com os testes de rede do kernel na Central de Ajuda do Issue Tracker com a ferramenta Component-Networking rótulo.
Confirmação de documentos e adição de testes
Informe os problemas conforme descrito acima e, se possível, faça upload de uma mudança para corrigi-los. se:
- Os testes não passam nas árvores de kernel comuns
- Você encontrar um commit necessário que não seja mencionado nos comentários da origem;
- Fazer com que os testes passem nos kernels upstream requer grandes mudanças
- Você acredita que os testes foram superespecificados ou que o teste falhou no futuro grãos
- Você quer adicionar mais testes ou mais cobertura a provas.