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 są w pełni zautomatyzowane.
• Testy interaktywne to testy częściowo zautomatyzowane, które wymagają wykonania pewnych czynności ręcznych na testowanym urządzeniu.

Oprócz nowych testów interaktywnych testy dokładności ręcznego określania zakresu i testy telekomunikacyjne są teraz testami na wielu urządzeniach po stronie hosta. Wymagane są też testy połączenia Wi-Fi.

Konfigurowanie testów po stronie hosta

Aby skonfigurować testy po stronie hosta, wykonaj te czynności (testy na wielu urządzeniach wymagają dodatkowej konfiguracji):

1. Sprawdź, czy Twój komputer spełnia wymagania dotyczące systemu operacyjnego dla CTS.

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

   • Wersja Pythona na komputerze powinna być w wersji 3.11 lub nowszej. Aby sprawdzić wersję Pythona, uruchom python3 --version. Jeśli wersja jest niższa niż 3.11, zainstaluj najnowszą oficjalną wersję Pythona. Więcej informacji znajdziesz w sekcji Pobieranie w 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 wersja Pythona na komputerze ma moduł venv, uruchom python3 -m venv venv. Jeśli to polecenie się nie powiedzie, pojawi się komunikat o błędzie. Postępuj zgodnie z instrukcjami, aby zainstalować pakiet python3.x-venv.

Jeśli przeprowadzasz tylko testy interaktywne 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 Twój komputer spełnia wymagania dotyczące systemu operacyjnego dla CTS.

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

   • Wersja Pythona na komputerze powinna być w wersji 3.11 lub nowszej. Aby sprawdzić wersję Pythona, uruchom python3 --version. Jeśli wersja jest niższa niż 3.11, zainstaluj najnowszą oficjalną wersję Pythona. Więcej informacji znajdziesz w sekcji Pobieranie w 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 wersja Pythona na komputerze ma moduł venv, uruchom python3 -m venv venv. Jeśli to polecenie się nie powiedzie, pojawi się komunikat o błędzie. Postępuj zgodnie z instrukcjami, aby zainstalować pakiet python3.x-venv.

3. Przygotuj 2 pasujące testowane urządzenia, każde ze skonfigurowanym CTS-V.

   • Szczegółowe informacje o konfigurowaniu testowanego urządzenia znajdziesz w artykule Konfigurowanie testowanego urządzenia.
   • Szczegółowe informacje o konfigurowaniu CTS-V znajdziesz w sekcji Konfiguracja.

4. Przejdź do sekcji konfiguracji odpowiedniej dla typu testu:

   • Informacje o testach NFC znajdziesz w artykule Konfigurowanie testów NFC.
   • Informacje o testach połączenia z punktem dostępu Wi-Fi znajdziesz w artykule Konfigurowanie testów połączenia z punktem dostępu Wi-Fi.
   • Informacje o testach dokładności pomiaru odległości znajdziesz w artykule Konfigurowanie testów dokładności pomiaru odległości.
   • Aby przetestować moduł CDM, zapoznaj się z sekcją Konfigurowanie standardowych testów na 2 urządzeniach, a następnie Konfigurowanie testów CDM.

Jeśli Twojego 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ą 1 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. Ustaw chip NFC:

   • W przypadku telefonów ustaw czytnik NFC testowanego urządzenia, jak pokazano na rysunku 1:

     

     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 (AP) (CtsWifiConnectionTests) sprawdzają połączenie między testowanym urządzeniem a punktem dostępu. Możesz skonfigurować te testy 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 kolejnych sekcjach opisujemy obie opcje.

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

Opcja 1 wymaga jednego testowanego urządzenia z Androidem w obszarze zasięgu sieci Wi-Fi. Jeśli testowane urządzenie znajduje się w ekranowanej obudowie i nie może połączyć się z siecią Wi-Fi, wyjmij je z obudowy.

Opcja 2. Skonfiguruj programowalny punkt dostępu

Aby skonfigurować programowalny punkt dostępu na potrzeby 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 model JTP-SR101. Kup to pudełko, korzystając z tych informacji:

   Dong Guan Zheng Sheng Electronics Technology Co., ograniczone wyświetlanie reklam

   Bohui Industrial Park, Panlong Road, Liaobu Town, Dongguan City, Guangdong Province, Chiny

   Kontakt: Forest Pan

   E-mail: [e-mail]

   Telefon (Chiny): [phone]

   Uwaga: ekranowana komora umożliwia izolację sygnału zewnętrznego i pozwala na umieszczenie testowanego urządzenia i punktu dostępu w odległości 10 cm od siebie.

3. Połącz DUT i AP z hostem i umieść je w ekranowanej obudowie RF. Odległość między testowanym urządzeniem a punktem dostępu powinna wynosić co najmniej 10 cm. Rysunek 2 przedstawia tę konfigurację:

   

   Rysunek 2. DUT i AP w ekranowanej obudowie.

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 takie same testowane urządzenia z Androidem w odległości 1 metra od siebie, na tej samej wysokości, w linii prostej i tyłem do siebie. Rysunek 3 przedstawia tę orientację:

   

   Rysunek 3. Orientacja urządzenia.

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

Konfigurowanie standardowych testów na 2 urządzeniach

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

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

2. Zdecydowanie zalecane: umieść oba urządzenia w pudełku ekranującym. Ekranowana komora poprawia stabilność testów i ułatwia debugowanie nieudanych testów.

   Uwaga: jeśli masz problemy z tymi testami i potrzebujesz pomocy, sprawdź, czy testy zostały przeprowadzone z użyciem obu urządzeń w skrzynce ekranującej.

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

   Uwaga: testy telekomunikacyjne są domyślnie uruchamiane, jeśli zainstalowane są karty SIM. Jeśli w obecnej konfiguracji nie ma kart SIM, możesz przeprowadzić inne testy, ale testy telekomunikacyjne musisz wykonać oddzielnie w konfiguracji z zainstalowaną kartą SIM.

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

Konfigurowanie testów CDM

Element testowania test_permissions_sync zachowuje się inaczej w zależności od typu kompilacji urządzeń, na których jest wykonywany test. Ważne jest, aby producenci OEM przetestowali zarówno kompilacje z możliwością debugowania (userdebug lub eng), jak i bez możliwości debugowania (user), i aby testy zakończyły się powodzeniem w obu przypadkach.

Zwolnienie

Klauzula CDD dotycząca implementacji interfejsu API synchronizacji uprawnień wymaga jedynie, aby umożliwiał on pomyślne przesyłanie danych między urządzeniami przez bezpieczny kanał. Ponieważ implementacja bezpiecznego kanału nie jest wymagana do zgodności z dokumentem CDD, ten test można pominąć w przypadku kompilacji bez możliwości debugowania (użytkownika), ale tylko wtedy, gdy chcesz zrezygnować z obsługi funkcji synchronizacji uprawnień CDM.

Testy muszą bez wyjątku zakończyć się powodzeniem w przypadku kompilacji z możliwością debugowania.

Wymagania wstępne dotyczące testowania w kompilacjach bez możliwości debugowania

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, które pozwalają sprawdzić, czy w ich systemie nie wprowadzono 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 dewelopera).

• Program rozruchowy urządzenia jest zablokowany. Więcej informacji znajdziesz w sekcji dotyczącej blokowania programu rozruchowego.

• Poziomy poprawek systemu operacyjnego, klucza rozruchu i klucza dostawcy są aktualne w ciągu 12 miesięcy. Nie używaj kompilacji starszej niż rok.

• Atestacja urządzenia jest obsługiwana przez jeden z certyfikatów głównych zatwierdzonych przez dostawcę. Określ zaufane certyfikaty główne w nakładce zasobów vendor_required_attestation_certificates.xml.

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 uruchamiany osobno. W przypadku testów, które nie wymagają dodatkowej konfiguracji, możesz je przeprowadzić w grupie.

1. Na testowej stacji roboczej uruchom konsolę cts-v-host 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 testowanym urządzeniu kliknij Testy po stronie hosta. Rysunek 4 przedstawia 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 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 pojawiają się pod każdym modułem testowym w aplikacji CTS-V na testowanym urządzeniu. Testy oznaczone na zielono zakończyły się powodzeniem, a testy oznaczone na czerwono – niepowodzeniem.

   Rysunek 5 przedstawia przykładowe wyniki testów CtsCompanionDeviceManager:

   

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

   Uwaga: wyniki po stronie hosta są automatycznie dodawane do ogólnego raportu z testu CTS-V.

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

   run cts-v-host-interactive
   

   Wyniki pojawiają się pod każdym modułem testowym w aplikacji CTS-V na testowanym urządzeniu. Testy oznaczone na zielono zakończyły się powodzeniem, a testy oznaczone na czerwono – niepowodzeniem.

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
   

   Ostrzeżenie: jeśli uruchomisz polecenie cts-v-host bez określenia modułu lub planu testowego, spróbuje ono uruchomić wszystkie moduły testowe, ignorując różnice w wymaganiach dotyczących urządzeń i sprzętu, co spowoduje błędy.

   Wyniki pojawią się pod każdym modułem testowym w aplikacji CTS-V na testowanym urządzeniu. Testy oznaczone na zielono zakończyły się powodzeniem, a testy oznaczone na czerwono – niepowodzeniem.

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 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 środowiska testowego (WifiConnectionTestbed.yaml). Ten plik znajduje się w katalogu, w którym rozpakowano CTS-Verifier. Na 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. Poniższy przykład pokazuje lokalizację tych ustawień:

   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 przeprowadzić testy połączenia z programowalnym punktem dostępu Wi-Fi:

1. Zmodyfikuj plik konfiguracji środowiska testowego (WifiConnectionTestbed.yaml). Ten plik znajduje się w katalogu, w którym rozpakowano CTS-Verifier. Na 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. 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
   

Uruchamianie testów USB po stronie hosta

Android 17 zawiera testy CTS-V USB po stronie hosta, które do działania wymagają 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, do których zwykła aplikacja CTS-V nie ma dostępu. Te testy są przeprowadzane bez połączenia z komputerem i wymagają użycia adb przez Wi-Fi.

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

• ładowarki USB typu C Power Delivery (PD),
• Standardowy port downstream (SDP) USB Battery Charging 1.2 (BC 1.2). Te porty są ograniczone do dostarczania 500 mA lub 900 mA do testowanego urządzenia i są powszechnie spotykane w portach USB zewnętrznych koncentratorów.
• port USB BC 1.2 CDP (Charging Downstream Port). Te porty mogą dostarczać do testowanego urządzenia prąd o natężeniu 1,5 A oraz dane. Port typu C w laptopie lub komputerze jest prawdopodobnie portem CDP.
• Dedykowane gniazdo ładowania (DCP) USB BC 1.2. Te porty mogą dostarczać do testowanego urządzenia prąd o natężeniu 1,5 A bez danych. Ładowarka USB typu C PD na tej liście prawdopodobnie jest ładowarką DCP.

Uwaga: jeśli urządzenie nie obsługuje raportowania typu BC 1.2 portu partnera lub profili zasilania USB w UsbPort.java, testy zakończą się pomyślnie bez dodatkowej interwencji.

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

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

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 obrazach:

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

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

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

W tej sekcji znajdziesz informacje o rozwiązywaniu typowych problemów.

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 każde testowane urządzenie ma zainstalowaną kartę 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łącz do polecenia run cts-v-host 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 testów CtsMultiDeviceGenericRangingAccuracyTests

Jeśli pojawi się ten komunikat o błędzie, aplikacja testowa może zostać zawieszona lub zamknięta przez proces zarządzania procesami w tle 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

Naprawianie braku odpowiedzi na GetFirmwareVersion podczas testów NFC

Jeśli podczas 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 określ ją ręcznie 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 elementów testowania NFC otrzymasz komunikat Transaction failed, check device logs for more information., prawdopodobnie chip NFC testowanego urządzenia nie może wykryć PN532.

Jeśli do hosta jest podłączonych kilka urządzeń, a niektóre z nich nie mają na sobie PN532, możliwe, że wybrano nieprawidłowe testowane urządzenie. Więcej informacji znajdziesz w artykule Konfigurowanie testów NFC.

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

• Ustaw prawidłowy numer seryjny testowanego urządzenia w poleceniu testowym po stronie hosta, używając flagi -s.

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

Element testowania CDM test_permissions_sync jest ignorowany

Jeśli test jest przeprowadzany na urządzeniach bez możliwości debugowania, sprawdź, czy nie dotyczy Cię wyjątek. W przeciwnym razie sprawdź, czy oba urządzenia spełniają wymagania.