Przeprowadzanie testów CTS Verifier po stronie hosta

Na tej stronie znajdziesz instrukcje konfigurowania i uruchamiania testów CTS Verifier (CTS-V) po stronie hosta na Androidzie 16 QPR2 i Androidzie 17. Istnieją 2 rodzaje testów po stronie hosta: testy na wielu urządzeniach (wprowadzone przed Androidem 17) i testy interaktywne (nowość w Androidzie 17):

  • Testy na wielu urządzeniach to w pełni zautomatyzowane testy.
  • Testy interaktywne to testy półautomatyczne, które wymagają wykonania pewnych czynności ręcznych na testowanym urządzeniu.

Oprócz nowych testów interaktywnych przekształciliśmy testy dokładności pomiaru ręcznego i testy telekomunikacyjne w testy wielourządzeniowe po stronie hosta, a testy połączenia Wi-Fi są teraz wymagane.

Konfigurowanie testów po stronie hosta

Aby skonfigurować testy po stronie hosta (testy na wielu urządzeniach wymagają dodatkowej konfiguracji):

  1. Sprawdź, czy komputer stacjonarny spełnia wymagania systemowe CTS.
  2. Wykonaj kroki 2 i 5 z sekcji Instalowanie oprogramowania na komputerze, aby zainstalować i sprawdzić, czy adb, AAPT2 i Python są prawidłowo zainstalowane na komputerze.
    • Wersja Pythona powinna być 3.11 lub nowsza. Aby sprawdzić wersję Pythona, uruchom polecenie python3 --version. Jeśli wersja jest niższa niż 3.11, zainstaluj najnowszą oficjalną wersję Pythona. Więcej informacji znajdziesz w sekcji pobierania na stronie python.org.
    • Niektóre testy wymagają, aby host miał moduł Pythona venv. W systemach Debian i Ubuntu ten moduł może nie być domyślnie zainstalowany. Aby sprawdzić, czy Twoja wersja Pythona ma moduł venv, uruchom polecenie python3 -m venv venv. Jeśli to polecenie się nie powiedzie, pojawi się komunikat o błędzie. Postępuj zgodnie z wyświetlanymi instrukcjami, aby zainstalować pakiet python3.x-venv.

Jeśli uruchamiasz tylko interaktywne testy po stronie hosta, przejdź do sekcji Uruchamianie testów po stronie hosta. Jeśli jednak chcesz przeprowadzić testy na wielu urządzeniach, przejdź do sekcji Konfigurowanie testów na wielu urządzeniach po stronie hosta.

Konfigurowanie testów na wielu urządzeniach po stronie hosta

Aby skonfigurować testy na wielu urządzeniach po stronie hosta, wykonaj te czynności:

  1. Sprawdź, czy komputer stacjonarny spełnia wymagania systemowe CTS.

  2. Wykonaj kroki 2 i 5 z sekcji Instalowanie oprogramowania na komputerze, aby zainstalować i sprawdzić, czy adb, AAPT2 i Python są prawidłowo zainstalowane na komputerze.

    • Wersja Pythona powinna być 3.11 lub nowsza. Aby sprawdzić wersję Pythona, uruchom polecenie python3 --version. Jeśli wersja jest niższa niż 3.11, zainstaluj najnowszą oficjalną wersję Pythona. Więcej informacji znajdziesz w sekcji pobierania na stronie python.org.
    • Niektóre testy wymagają, aby host miał moduł Pythona venv. W systemach Debian i Ubuntu ten moduł może nie być domyślnie zainstalowany. Aby sprawdzić, czy Twoja wersja Pythona ma moduł venv, uruchom polecenie python3 -m venv venv. Jeśli to polecenie się nie powiedzie, pojawi się komunikat o błędzie. Postępuj zgodnie z wyświetlanymi instrukcjami, aby zainstalować pakiet python3.x-venv.

  3. Przygotuj 2 pasujące urządzenia DUT, na których skonfigurowano CTS-V.

  4. Otwórz sekcję konfiguracji dla wybranego typu testu:

Jeśli testu nie ma na tej liście, przejdź do sekcji Konfigurowanie standardowych testów na 2 urządzeniach.

Konfigurowanie testów NFC

Testy NFC wykorzystują jedno urządzenie DUT i jeden chip NFC PN532.

Aby skonfigurować testy NFC:

  1. Kup chip NFC PN532. Zalecamy użycie czytnika All-In-One PN532.
  2. Na testowanym urządzeniu otwórz aplikację Ustawienia.
  3. Włącz NFC.

  4. Umieść chip NFC:

    • W przypadku telefonów umieść czytnik NFC urządzenia DUT w sposób pokazany na rysunku 1:

      Położenie chipa NFC

      Rysunek 1. Położenie chipa NFC.

    • W przypadku innych typów urządzeń umieść chip obok anteny NFC urządzenia.

  5. Podłącz chip NFC PN532 do stacji testowej za pomocą kabla USB.

Konfigurowanie testów połączenia z punktem dostępu Wi-Fi

Testy połączenia z punktem dostępu Wi-Fi (CtsWifiConnectionTests) sprawdzają łączność między testowanym urządzeniem a punktem dostępu. Te testy możesz skonfigurować na 2 sposoby:

  • Opcja 1. Użyj istniejącej sieci Wi-Fi skonfigurowanej dla CTS-V.
  • Opcja 2. Skonfiguruj programowalny punkt dostępu.

W przypadku Androida 17 zdecydowanie zalecamy opcję 2, ale nie jest ona wymagana. W dwóch sekcjach poniżej znajdziesz opis każdej z tych opcji.

Opcja 1. Użyj istniejącej sieci Wi-Fi skonfigurowanej na potrzeby CTS-V

Opcja 1 wymaga jednego urządzenia z Androidem w zasięgu sieci Wi-Fi. Jeśli DUT znajduje się w obudowie ekranującej i nie może połączyć się z siecią Wi-Fi, wyjmij go z niej.

Opcja 2. Skonfiguruj programowalny punkt dostępu

Aby skonfigurować programowalny punkt dostępu do testów połączenia Wi-Fi:

  1. Kup i skonfiguruj Banana Pi R3 AP. Informacje o zakupie i konfigurowaniu punktu dostępu Banana Pi R3 znajdziesz w artykule Konfigurowanie punktu dostępu Banana Pi BPI-R3.

  2. Opcjonalnie: jeśli nie masz skrzynki ekranującej, zalecamy skrzynkę ekranującą JTP-SR101. Kup to pudełko, korzystając z tych informacji:

    Dong Guan Zheng Sheng Electronics Technology Co., LTD
    Bohui Industrial Park, Panlong Road, Liaobu Town, Dongguan City, Guangdong Province, Chiny
    Osoba kontaktowa: Forest Pan
    E-mail: forest.pan@jtpmak.cn
    Telefon (Chiny): +86 18676993556

  3. Podłącz DUT i AP do hosta i umieść je w osłonie RF. Urządzenie i punkt dostępu powinny być oddalone od siebie o co najmniej 10 cm. Na rysunku 2 widać tę konfigurację:

    Urządzenie testowane i punkt dostępu w ekranowanej obudowie

    Rysunek 2. DUT i AP w pudełku ekranowanym.

  4. Użyj SSH, aby sprawdzić, czy punkt dostępu jest dostępny z hosta.

Konfigurowanie testów dokładności pomiaru odległości

Aby skonfigurować testy dokładności pomiaru odległości:

  1. Umieść 2 pasujące urządzenia z Androidem w odległości 1 metra od siebie, na tej samej wysokości, w bezpośrednim polu widzenia i tyłami do siebie. Ilustracja 3 przedstawia tę orientację:

    Orientacja urządzenia

    Rysunek 3. Orientacja urządzenia.

  2. Połącz oba urządzenia z komputerem stacjonarnym za pomocą kabli USB.

Konfigurowanie standardowych testów na 2 urządzeniach

W przypadku domyślnej konfiguracji z 2 urządzeniami:

  1. Umieść 2 pasujące urządzenia z Androidem w odległości około 20 cm od siebie.

  2. Zdecydowanie zalecane: umieść oba urządzenia w pudełku ekranowanym. Klatka ekranująca zwiększa stabilność testu i ułatwia debugowanie błędów.

  3. W przypadku testów telekomunikacyjnych każde urządzenie musi mieć kartę SIM i sygnał komórkowy. Jeśli DUT znajdują się w obudowie ekranowanej, sygnał komórkowy musi być do niej doprowadzony. W przeciwnym razie wyjmij urządzenia z pudełka ekranującego.

  4. Opcjonalnie: skonfiguruj sniffer OTA do debugowania Wi-Fi.

Konfigurowanie testów CDM

test_permissions_sync() element testowania ma inne zachowanie w zależności od rodzaju kompilacji urządzeń, na których jest wykonywany test. Konieczne jest, aby producenci OEM testowali zarówno kompilacje z możliwością debugowania (userdebug lub eng), jak i bez możliwości debugowania (user) oraz aby testy w obu przypadkach zakończyły się powodzeniem.

Zwolnienie

Klauzula CDD dotycząca implementacji interfejsu Permissions Sync API wymaga jedynie możliwości przesyłania danych między urządzeniami przez bezpieczny kanał. Implementacja bezpiecznego kanału nie jest wymagana w ramach zgodności z CDD, dlatego ten test można pominąć w przypadku kompilacji, których nie można debugować (użytkownika), ale tylko wtedy, gdy chcesz zrezygnować z obsługi funkcji synchronizacji uprawnień CDM.

Testy muszą być przeprowadzane na kompilacjach z możliwością debugowania bez wyjątku.

Wymagania wstępne dotyczące testowania na kompilacjach, których nie można debugować

Jeśli nie jesteś zwolniony(-a) z tego obowiązku, sprawdź, czy spełniasz te wymagania wstępne.

Bezpieczny kanał używa AVF (AttestationVerificationFramework) do weryfikacji wiarygodności sprzętu. Atesty generowane przez obie strony zawierają kilka informacji o nich samych, które pozwalają sprawdzić, czy w ich systemie nie doszło do nieautoryzowanych zmian. Podczas procesu weryfikacji AVF sprawdza te stany:

  • Urządzenie ma dostęp do internetu
  • Urządzenie korzysta z weryfikowanego rozruchu, a kompilacja musi być podpisana kluczem wersji, a nie kluczem deweloperskim.
  • Program rozruchowy urządzenia jest zablokowany. Szczegółowe instrukcje znajdziesz w artykule na temat blokowania programu rozruchowego.
  • Poziomy poprawek systemu operacyjnego, kluczowego rozruchu i dostawcy kluczy są aktualne w ciągu 12 miesięcy. Nie używaj kompilacji starszej niż rok.
  • Atest urządzenia jest oparty na jednym z zatwierdzonych przez dostawcę certyfikatów głównych. Określ zaufane główne certyfikaty w nakładce zasobu vendor_required_attestation_certificates.xml.

Przeprowadzanie testów po stronie hosta

Niektóre testy na wielu urządzeniach, np. testy NFC, wymagają dodatkowej konfiguracji. W przypadku testów wymagających dodatkowej konfiguracji każdy test jest przeprowadzany osobno. W przypadku testów, które nie wymagają dodatkowej konfiguracji, możesz uruchomić testy w grupie.

  1. Na testowej stacji roboczej uruchom cts-v-hostkonsolę z katalogu, w którym rozpakowano pakiet ZIP CTS-V:

    ./android-cts-verifier/android-cts-v-host/tools/cts-v-host-tradefed

  2. W aplikacji CTS-V na urządzeniu DUT kliknij Testy po stronie hosta. Ilustracja 4 przedstawia testy po stronie hosta w aplikacji CTS-V:

    Testy po stronie hosta w aplikacji CTS-V

    Rysunek 4. Testy po stronie hosta w aplikacji CTS-V.

    Wyświetli się lista modułów testowych po stronie hosta do testów na wielu urządzeniach.

  3. W konsoli hosta CTS-V użyj tego polecenia, aby uruchomić testy na wielu urządzeniach, które korzystają ze standardowej konfiguracji z 2 urządzeniami:

    run cts-v-host-multidevice-default

    Wyniki pojawią się w aplikacji CTS-V na DUT pod każdym modułem testowym. Testy oznaczone na zielono zostały zaliczone, a testy oznaczone na czerwono nie zostały zaliczone.

    Na rysunku 5 przedstawiono przykładowe wyniki testów CtsCompanionDeviceManager:

    Wyniki testów na wielu urządzeniach po stronie hosta w aplikacji CTS-V

    Rysunek 5. Wyniki testów na wielu urządzeniach po stronie hosta w aplikacji CTS-V.

  4. W konsoli hosta CTS-V użyj tego polecenia, aby uruchomić testy interaktywne:

    run cts-v-host-interactive

    Wyniki pojawią się w aplikacji CTS-V na DUT pod każdym modułem testowym. Testy oznaczone na zielono zostały zaliczone, a testy oznaczone na czerwono nie zostały zaliczone.

  5. W przypadku każdego testu, który wymagał dodatkowej konfiguracji, uruchom go osobno za pomocą tego polecenia:

    run cts-v-host -m test_module_name

    Aby na przykład uruchomić testy NFC, użyj tego polecenia:

    run cts-v-host -m CtsNfcHceMultiDeviceTestCases

    Wyniki pojawią się w aplikacji CTS-V na DUT pod każdym modułem testowym. Testy oznaczone na zielono zostały zaliczone, a testy oznaczone na czerwono nie zostały zaliczone.

Przeprowadzanie testów połączenia z punktem dostępu Wi-Fi

Testy połączenia z punktem dostępu Wi-Fi możesz przeprowadzić na 2 sposoby:

  • Opcja 1. Użyj istniejącej sieci Wi-Fi skonfigurowanej dla CTS-V.
  • Opcja 2. Skonfiguruj programowalny punkt dostępu.

Opcja 1. Użyj istniejącej sieci Wi-Fi skonfigurowanej na potrzeby CTS-V

Aby przeprowadzić testy połączenia z punktem dostępu Wi-Fi w istniejącej sieci Wi-Fi:

  1. Edytuj plik konfiguracji testbedu (WifiConnectionTestbed.yaml). Ten plik znajduje się w katalogu, w którym rozpakowano CTS-Verifier. Przykład:

    ./android-cts-verifier/android-cts-v-host/testcases/CtsWifiConnectionTests/x86_64/connection/WifiConnectionTestbed.yaml

  2. Zmień wartości pól wifi_ssid i wifi_password na identyfikator SSID i hasło sieci Wi-Fi. W przykładzie poniżej pokazujemy, gdzie znajdują się te ustawienia:

    TestBeds:
- Name: WifiConnectionTestbed
Controllers:
  AndroidDevice: '*'
TestParams:
  use_programmable_ap: False
  wifi_ssid: WIFI-SSID
  wifi_password: WIFI-PASSWORD

  3. W konsoli hosta CTS-V uruchom to polecenie:

    run cts-v-host -m CtsWifiConnectionTests

Opcja 2. Uruchamianie z programowalnym punktem dostępu

Aby uruchomić testy połączenia z punktem dostępu Wi-Fi na programowalnym punkcie dostępu:

  1. Edytuj plik konfiguracji testbedu (WifiConnectionTestbed.yaml). Ten plik znajduje się w katalogu, w którym rozpakowano CTS-Verifier. Przykład:

    ./android-cts-verifier/android-cts-v-host/testcases/CtsWifiConnectionTests/x86_64/connection/WifiConnectionTestbed.yaml

  2. Zmień wartość hostname na adres IP punktu dostępu na podstawie lokalnych ustawień SSH. Aby sprawdzić adres IP, przeczytaj artykuł Sprawdzanie adresu IP punktu dostępu. Poniższy przykład pokazuje lokalizację ustawienia hostname:

    TestBeds:
- Name: WifiConnectionTestbed
  Controllers:
    AndroidDevice: '*'
    # Specify settings for the AP.
    OpenWrtDevice:
    - hostname: AP-IP
      skip_init_reboot: True
  TestParams:
    use_programmable_ap: True

  3. W konsoli hosta CTS-V uruchom to polecenie:

    run cts-v-host -m CtsWifiConnectionTests

Przeprowadzanie testów po stronie hosta USB

Android 17 zawiera testy CTS-V po stronie hosta, które wymagają połączenia adb przez Wi-Fi.

Niektóre testy USB wymagają użycia hosta CTS-V, aby uzyskać dostęp do interfejsów SystemAPI, które mają uprawnienia niedostępne dla zwykłej aplikacji CTS-V. Te testy są przeprowadzane bezprzewodowo i wymagają użycia adb przez Wi-Fi.

Jeśli testowane urządzenie obsługuje raportowanie typu BC 1.2 portu partnerskiego lub profili zasilania USB w UsbPort.java, wymagane są te akcesoria typu C:

  • Ładowarka USB typu C z technologią Power Delivery (PD)
  • Port USB do ładowania baterii 1.2 (BC 1.2) w standardzie downstream port (SDP). Te porty mogą dostarczać do testowanego urządzenia 500 mA lub 900 mA. Zwykle znajdują się na portach USB zewnętrznych koncentratorów.
  • gniazdo ładowania USB BC 1.2 (CDP); Porty te mogą dostarczać do urządzenia testowanego prąd o natężeniu 1,5 A oraz dane. Port USB-C na laptopie lub komputerze prawdopodobnie jest portem CDP.
  • Dedykowane gniazdo ładowania USB BC 1.2 (DCP). Te porty mogą dostarczać do testowanego urządzenia prąd o natężeniu 1,5 A bez przesyłania danych. Ładowarka USB typu C PD na tej liście prawdopodobnie jest ładowarką DCP.

  1. Połącz urządzenie DUT za pomocą adb przez Wi-Fi. Szczegółowe informacje o konfiguracji znajdziesz w artykule Łączenie z urządzeniem przez Wi-Fi.

  2. Odłącz urządzenie od wszystkich połączeń USB. Test zakończy się niepowodzeniem, jeśli w momencie uruchomienia polecenia testowego urządzenie jest podłączone do hosta USB lub akcesorium.

  3. Uruchom to polecenie testowe:

    run cts-v-host -m CtsUsbTypecTestCases

Po zakończeniu testów wyniki pojawią się w aplikacji CTS-V w sekcji Testy po stronie hosta, jak pokazano na ilustracjach poniżej:

Testy USB po stronie hosta w aplikacji CTS-V

Rysunek 6. Testy USB po stronie hosta w aplikacji CTS-V.

Pakiet CtsUsbTypecTestCases w aplikacji CTS-V USB po stronie hosta

Rysunek 7. pakiet CtsUsbTypecTestCases w aplikacji CTS-V USB po stronie hosta.

Rozwiązywanie problemów z testami na wielu urządzeniach

W tej sekcji znajdziesz informacje, które pomogą Ci rozwiązać typowe problemy.

Nie udało się uzyskać numeru telefonu podczas testu CtsTelecomTest

Jeśli pojawi się komunikat o błędzie Failed to get phone number for <serial>, wykonaj te czynności:

  1. Sprawdź, czy na każdym urządzeniu jest zainstalowana karta SIM.

  2. Jeśli błąd będzie się powtarzać, karty SIM mogą nie obsługiwać automatycznego pobierania numeru. W takim przypadku musisz wyraźnie podać numery telefonów w poleceniu.

    Na przykład w przypadku DUT 1 (numer seryjny 17011FDEE0002N, numer telefonu 555-0000) i DUT 2 (numer seryjny R3CN90YNAR, numer telefonu 555-1111) do polecenia run cts-v-host dodaj te argumenty:

    --module-arg CtsTelecomTest:dut_serial:17011FDEE0002N \
--module-arg CtsTelecomTest:dut_phone_number:555-0000 \
--module-arg CtsTelecomTest:ref_phone_number:555-1111

Brak odpowiedzi z serwera podczas testu CtsMultiDeviceGenericRangingAccuracyTests

Jeśli pojawi się poniższy komunikat o błędzie, aplikacja testowa może zostać zamrożona lub zamknięta przez proces zarządzania działający w tle, który jest specyficzny dla danego producenta OEM i występuje na niektórych urządzeniach:

mobly.snippet.errors.ProtocolError: <AndroidDevice|Initiator> No response from server. Check the device logcat for crashes.

Aby rozwiązać ten problem, wyłącz ograniczenia działania w tle lub dodaj do listy dozwolonych te pakiety:

Pakiet Wyświetlana nazwa
com.google.snippet.uwb CtsUwbSnippetApp
com.google.snippet.ranging CtsRangingSnippetApp
com.google.snippet.bluetooth CtsBluetoothMultiDeviceSnippetApp
com.google.android.mobly.snippet.bundled androidx.multidex.MultDexApplication

Rozwiązywanie problemu z brakiem odpowiedzi na żądanie GetFirmwareVersion podczas testów NFC

Jeśli podczas przeprowadzania testów na wielu urządzeniach pojawi się komunikat verify_firmware_version RuntimeError: No response for GetFirmwareVersion, oznacza to, że testy nie mają dostępu do płytki NFC PN532.

Aby rozwiązać ten problem, znajdź ścieżkę szeregową używaną przez płytkę NFC PN532 na hoście, np. dev/ttyUSB1, a następnie ręcznie określ ją za pomocą argumentu --module-arg w konsoli:

run cts-v-host -m CtsNfcHceMultiDeviceTestCases --module-arg CtsNfcHceMultiDeviceTestCases:pn532_serial_path:/dev/ttyUSB1

Rozwiązywanie problemów z komunikatem o błędzie „Transakcja nie powiodła się” podczas testów NFC

Jeśli w przypadku wszystkich testów NFC otrzymasz komunikat Transaction failed, check device logs for more information., prawdopodobnie oznacza to, że chip NFC DUT nie może wykryć PN532.

Jeśli do hosta jest podłączonych kilka urządzeń, a na niektórych z nich nie ma czytnika PN532, mogło zostać wybrane nieprawidłowe urządzenie DUT. Więcej informacji znajdziesz w artykule Konfigurowanie testów NFC.

Aby rozwiązać ten problem, wykonaj jedną z tych czynności:

  • W poleceniu testowym po stronie hosta ustaw prawidłowy numer seryjny testowanego urządzenia za pomocą flagi -s.

  • Odłącz od hosta wszystkie urządzenia inne niż DUT.

Test CDM test_permissions_sync został zignorowany

Jeśli test jest przeprowadzany na urządzeniach, na których nie można debugować aplikacji, sprawdź, czy nie obowiązuje Cię zwolnienie. W przeciwnym razie sprawdź, czy oba urządzenia spełniają wymagania wstępne.