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 kroków ręcznych na testowanym urządzeniu.

Oprócz nowych testów interaktywnych testy dokładności pomiaru ręcznego i testy telekomunikacyjne są teraz testami wielourządzeniowymi po stronie hosta, a testy połączenia Wi-Fi są 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 w przypadku CTS.

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

    • Wersja Pythona na komputerze powinna być 3.11 lub nowsza. Aby określić wersję Pythona, uruchom python3 --version. Jeśli wersja jest niższa niż 3.11, zainstaluj najnowszą oficjalną wersję Pythona. Szczegółowe informacje znajdziesz w  sekcji Pobieraniepython.org na stronie.

    • Niektóre testy wymagają, aby host miał moduł Pythona venv. W systemach Debian i Ubuntu ten moduł może nie być zainstalowany domyślnie. Aby sprawdzić, czy wersja Pythona na komputerze zawiera moduł venv, uruchom python3 -m venv venv. Jeśli to polecenie się nie powiedzie, wyświetli się komunikat o błędzie. Postępuj zgodnie z instrukcjami, aby zainstalować python3.x-venvpakiet.

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 w przypadku CTS.

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

    • Wersja Pythona na komputerze powinna być 3.11 lub nowsza. Aby określić wersję Pythona, uruchom python3 --version. Jeśli wersja jest niższa niż 3.11, zainstaluj najnowszą oficjalną wersję Pythona. Szczegółowe informacje znajdziesz w  sekcji Pobieraniepython.org na stronie.

      • Niektóre testy wymagają, aby host miał moduł Pythona venv. W systemach Debian i Ubuntu ten moduł może nie być zainstalowany domyślnie. Aby sprawdzić, czy wersja Pythona na komputerze zawiera moduł venv, uruchom python3 -m venv venv. Jeśli to polecenie się nie powiedzie, wyświetli się komunikat o błędzie. Postępuj zgodnie z instrukcjami, aby zainstalować python3.x-venvpakiet.

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

    • Szczegółowe informacje o konfigurowaniu DUT znajdziesz w artykule Konfigurowanie DUT.
    • Szczegółowe informacje o konfigurowaniu CTS-V znajdziesz w sekcji Konfiguracja.

  4. Przejdź do sekcji konfiguracji odpowiedniej dla Twojego 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 testowane urządzenie i 1 chip NFC PN532.

Aby skonfigurować testy NFC:

  1. Kup chip NFC PN532. Zalecamy 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 roboczej 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 na potrzeby CTS-V.
  • Opcja 2. Skonfiguruj programowalny punkt dostępu.

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

Opcja 1. Użyj istniejącej sieci Wi-Fi skonfigurowanej dla 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 Banana Pi R3 AP i skonfiguruj go. 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ę JTP-SR101. Kup ten pakiet, 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

    Kontakt: 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 DUT i punkt dostępu powinny znajdować się w odległości co najmniej 10 cm od siebie. Na rysunku 2 widać tę konfigurację:

    Urządzenie testowe i punkt dostępu w ekranowanym pomieszczeniu

    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łem do siebie. Rysunek 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. Osłona poprawia 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 osłonie, 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 zachowuje się inaczej w zależności od rodzaju kompilacji urządzeń, na których jest wykonywany. Konieczne jest, aby producenci OEM testowali obie wersje – z możliwością debugowania (userdebug lub eng) i niedebugowalną (user) – i aby testy w obu przypadkach zakończyły się powodzeniem.

Zwolnienie

Klauzula CDD dotycząca implementacji interfejsu API synchronizacji uprawnień wymaga jedynie, aby interfejs API mógł przesyłać dane między urządzeniami przez bezpieczny kanał. Implementacja bezpiecznego kanału nie jest wymagana w ramach CDD, więc ten test można pominąć w przypadku kompilacji, których nie można debugować (użytkownik), ale tylko wtedy, gdy chcesz zrezygnować z obsługi funkcji synchronizacji uprawnień CDM.

Testy muszą być przeprowadzane bez wyjątku w przypadku kompilacji z możliwością debugowania.

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 potwierdzają, że w ich systemie nie doszło do żadnych nieautoryzowanych zmian. Podczas procesu weryfikacji AVF sprawdza te stany:

  • Urządzenie ma dostęp do internetu

  • Urządzenie korzysta z weryfikacji podczas uruchamiania, a kompilacja jest podpisana kluczem wersji (nie kluczem deweloperskim).

  • Program rozruchowy urządzenia jest zablokowany. Więcej informacji znajdziesz w artykule o blokowaniu bootloadera.

  • System operacyjny, klucz rozruchu i poprawki na poziomie dostawcy klucza są aktualne (nie starsze niż 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 certyfikaty główne w vendor_required_attestation_certificates.xml nakładce zasobów.

Uruchamianie testów po stronie hosta

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

  1. Na stacji roboczej testowej otwórz konsolę cts-v-host w 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 kliknij Host-side Tests (Testy po stronie hosta). Rysunek 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 na wielu urządzeniach po stronie hosta.

  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 pojawiają 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 wiele urządzeń po stronie hosta w aplikacji CTS-V

    Rysunek 5. Wyniki testów na wiele urządzeń po stronie hosta w aplikacji CTS-V.

  4. W konsoli hosta CTS-V uruchom testy interaktywne za pomocą tego polecenia:

    run cts-v-host-interactive

    Wyniki pojawiają 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 pojawiają 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 na potrzeby CTS-V.
  • Opcja 2. Skonfiguruj programowalny punkt dostępu.

Opcja 1. Użyj istniejącej sieci Wi-Fi skonfigurowanej dla 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. Uruchomienie z programowalnym AP

Aby przeprowadzić 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 znaleźć adres IP, zapoznaj się z artykułem Znajdowanie adresu IP punktu dostępu. W przykładzie poniżej pokazujemy, gdzie znajduje się ustawienie 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 USB, 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ą korzystania z 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 ze złączem typu C:

  • Ładowarka USB typu C z technologią Power Delivery (PD)
  • Standardowy port wyjściowy (SDP) zgodny ze standardem USB Battery Charging 1.2 (BC 1.2). Te porty mogą dostarczać do testowanego urządzenia maksymalnie 500 mA lub 900 mA i zwykle znajdują się na portach USB zewnętrznych hubów.
  • Port ładowania USB BC 1.2 (CDP). Te porty mogą dostarczać do DUT prąd o natężeniu 1,5 A i dane. Port typu 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 się z urządzeniem przez Wi-Fi.

  2. Odłącz urządzenie od wszystkich połączeń USB. Test nie powiedzie się, jeśli urządzenie jest podłączone do dowolnego hosta USB lub akcesorium podczas wykonywania polecenia testowego.

  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 tych ilustracjach:

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 DUT 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ę ten 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 dotyczące 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, zidentyfikuj ś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 testowanego urządzenia nie wykrywa modułu PN532.

Jeśli do hosta jest podłączonych kilka urządzeń, a na niektórych z nich nie ma czytnika PN532, może 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 jest ignorowany

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