הרצת בדיקות בצד המארח של CTS Verifier

בדף הזה מוסבר איך להגדיר ולהריץ בדיקות CTS Verifier‏ (CTS-V) מצד המארח ב-Android 16 QPR2 וב-Android 17. יש שני סוגים של בדיקות מצד המארח: בדיקות בכמה מכשירים (הוצגו לפני Android 17) ובדיקות אינטראקטיביות (חדשות ב-Android 17):

  • בדיקות בכמה מכשירים הן בדיקות אוטומטיות לחלוטין.
  • בדיקות אינטראקטיביות הן בדיקות חצי אוטומטיות, שבהן צריך לבצע כמה שלבים ידניים במכשיר שנבדק (DUT).

בנוסף לבדיקות האינטראקטיביות החדשות, בדיקות ידניות של דיוק הטווח ובדיקות טלקום הן עכשיו בדיקות מצד המארח בכמה מכשירים, ונדרשות בדיקות של חיבור Wi-Fi.

הגדרת בדיקות מצד המארח

כדי להגדיר בדיקות מצד המארח (בדיקות בכמה מכשירים דורשות הגדרה נוספת), פועלים לפי השלבים הבאים:

  1. מוודאים שהמחשב עומד בדרישות מערכת ההפעלה של CTS.

  2. כדי להתקין את adb, ‏ AAPT2 ו-Python במחשב ולוודא שהם הותקנו כמו שצריך, פועלים לפי שלבים 2 ו-5 במאמר התקנת תוכנה למחשב.

    • גרסת Python למחשב צריכה להיות 3.11 ומעלה. כדי לדעת איזו גרסה של Python משמשת את gsutil, אפשר להריץ את python3 --version. אם הגרסה נמוכה מ-3.11, צריך להתקין את הגרסה הרשמית האחרונה של Python. לפרטים נוספים, ראו את הקטע Downloads של python.org.

    • בחלק מהבדיקות, המארח צריך את המודול venv של Python. במערכות Debian ו-Ubuntu, יכול להיות שהמודול הזה לא מותקן כברירת מחדל. כדי לבדוק אם גרסת ה-Python במחשב כוללת את המודול venv, מריצים את הפקודה python3 -m venv venv. אם הפקודה נכשלת, מוצגת הודעת שגיאה. פועלים לפי ההנחיות כדי להתקין את החבילה python3.x-venv.

אם אתם מריצים רק את הבדיקות האינטראקטיביות מצד המארח, המשיכו לקטע הרצת בדיקות מצד המארח. עם זאת, אם אתם רוצים להריץ בדיקות בכמה מכשירים, עברו אל הגדרת בדיקות בכמה מכשירים מצד המארח.

הגדרת בדיקות בצד המארח בכמה מכשירים

כדי להגדיר בדיקות בצד המארח בכמה מכשירים, פועלים לפי השלבים הבאים:

  1. מוודאים שהמחשב עומד בדרישות של מערכת ההפעלה ל-CTS.

  2. פועלים לפי שלבים 2 ו-5 בקטע התקנת תוכנה למחשב כדי להתקין ולוודא ש-adb,‏ AAPT2 ו-Python מותקנים בצורה נכונה במחשב.

    • גרסת Python למחשב צריכה להיות 3.11 ומעלה. כדי לדעת איזו גרסה של Python משמשת את gsutil, אפשר להריץ את python3 --version. אם הגרסה נמוכה מ-3.11, צריך להתקין את הגרסה הרשמית האחרונה של Python. לפרטים נוספים, ראו את הקטע Downloads של python.org.

      • בחלק מהבדיקות, המארח צריך את המודול venv של Python. במערכות Debian ו-Ubuntu, יכול להיות שהמודול הזה לא מותקן כברירת מחדל. כדי לבדוק אם גרסת ה-Python במחשב כוללת את המודול venv, מריצים את הפקודה python3 -m venv venv. אם הפקודה נכשלת, מוצגת הודעת שגיאה. פועלים לפי ההנחיות כדי להתקין את החבילה python3.x-venv.

  3. מכינים שני מכשירים תואמים לבדיקה, שבכל אחד מהם מוגדר CTS-V.

  4. עוברים לקטע ההגדרה של סוג הבדיקה:

אם הבדיקה לא מופיעה ברשימה הזו, צריך להמשיך אל הגדרת בדיקות רגילות בשני מכשירים.

הגדרת בדיקות NFC

בבדיקות NFC משתמשים במכשיר אחד (DUT) ובשבב NFC אחד מסוג PN532.

כדי להגדיר בדיקות NFC:

  1. קונים שבב NFC מסוג PN532. אנחנו ממליצים על All-In-One PN532.
  2. במכשיר שנבדק, עוברים לאפליקציית ההגדרות.
  3. מפעילים את ה-NFC.

  4. ממקמים את שבב ה-NFC:

    • בטלפונים, ממקמים את קורא ה-NFC של המכשיר הנבדק כמו שמוצג באיור 1:

      מיקום שבב ה-NFC

      איור 1. מיקום שבב ה-NFC.

    • בסוגי מכשירים אחרים, צריך להצמיד את השבב לאנטנת ה-NFC של המכשיר.

  5. מחברים את שבב ה-NFC מדגם PN532 לתחנת העבודה לבדיקה באמצעות כבל USB.

הגדרת בדיקות חיבור לנקודת גישה ל-Wi-Fi

בדיקות החיבור לנקודת הגישה (AP) ל-Wi-Fi‏ (CtsWifiConnectionTests) בודקות את הקישוריות בין המכשיר הנבדק לבין נקודת הגישה. אפשר להגדיר את הבדיקות האלה בשתי דרכים:

  • אפשרות 1: משתמשים ברשת Wi-Fi קיימת שהגדרתם ל-CTS-V.
  • אפשרות 2: הגדרת נקודת גישה (AP) ניתנת לתכנות.

ב-Android 17, מומלץ מאוד להשתמש באפשרות השנייה, אבל זו לא חובה. בשני הקטעים הבאים מוסבר על כל אחת מהאפשרויות.

אפשרות 1: שימוש ברשת Wi-Fi קיימת שהגדרתם ל-CTS-V

באפשרות 1 נדרש מכשיר Android אחד שנבדק (DUT) באזור הכיסוי של רשת ה-Wi-Fi. אם המכשיר נמצא בקופסת מגן ולא מצליח להתחבר לרשת Wi-Fi, צריך להוציא אותו מהקופסה.

אפשרות 2: הגדרת נקודת גישה ניתנת לתכנות

כדי להגדיר נקודת גישה ניתנת לתכנות לבדיקות של חיבור ה-Wi-Fi:

  1. קונים את Banana Pi R3 AP ומגדירים אותו. במאמר הגדרת Banana Pi BPI-R3 AP מוסבר איך רוכשים ומגדירים את Banana Pi R3 AP.

  2. (אופציונלי) אם אין לכם קופסת מיגון, אנחנו ממליצים על קופסת המיגון JTP-SR101. כדי לרכוש את החבילה הזו, צריך להשתמש בפרטים הבאים:

    Dong Guan Zheng Sheng Electronics Technology Co., LTD

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

    איש קשר: Forest Pan

    אימייל: forest.pan@jtpmak.cn

    טלפון (סין): ‎+86 18676993556

  3. מחברים את ה-DUT וה-AP למארח ומניחים אותם בקופסת מגן RF. המרחק בין ה-DUT ל-AP צריך להיות לפחות 10 ס"מ. באיור 2 מוצגת ההגדרה הזו:

    DUT ו-AP בקופסת מגן

    איור 2. DUT ו-AP בקופסת מגן.

  4. משתמשים ב-SSH כדי לוודא שאפשר לגשת ל-AP מהמארח.

הגדרת בדיקות לדיוק של מדידת הטווח

כדי להגדיר בדיקות של דיוק המדידה:

  1. מציבים שני מכשירי Android לבדיקה במרחק של מטר אחד זה מזה, באותו גובה, עם קו ראייה ישיר, כשהחלק האחורי של כל מכשיר פונה אל המכשיר השני. איור 3 מציג את הכיוון הזה:

    הכיוון שאליו פונה המכשיר

    איור 3. כיוון המכשיר.

  2. מחברים את שני המכשירים למחשב באמצעות כבלי USB.

הגדרת בדיקות רגילות עם שני מכשירים

להגדרה של שני מכשירים כברירת מחדל:

  1. מניחים שני מכשירי Android תואמים לבדיקה במרחק של כ-20 ס"מ זה מזה.

  2. מומלץ מאוד: הניחו את שני המכשירים בקופסה מוגנת. הקופסה המבודדת משפרת את יציבות הבדיקה ומקלה על ניפוי הבאגים של שגיאות הבדיקה.

  3. בבדיקות של תקשורת, לכל מכשיר DUT צריך להיות כרטיס SIM ואות סלולרי. אם המכשירים לבדיקה נמצאים בקופסת מגן, צריך לחבר את האות הסלולרי לקופסה. אם לא, מוציאים את המכשירים מהקופסה.

  4. אופציונלי: מגדירים רחרחן OTA לניפוי באגים ב-Wi-Fi.

הגדרת בדיקות CDM

מקרה הבדיקה test_permissions_sync מתנהג בצורה שונה בהתאם לסוג ה-build של המכשירים שבהם הבדיקה מופעלת. חשוב מאוד שיצרני ציוד מקורי (OEM) יבדקו גם גרסאות build שניתן לבצע בהן ניפוי באגים (userdebug או eng) וגם גרסאות build שלא ניתן לבצע בהן ניפוי באגים (user), ושהבדיקות יעברו בהצלחה בשני המקרים.

פטור

הסעיף ב-CDD לגבי הטמעת ה-API לסנכרון הרשאות דורש רק שהמכשיר יוכל להעביר נתונים בין מכשירים בערוץ מאובטח. מכיוון שהטמעת הערוץ המאובטח היא לא דרישה לתאימות ל-CDD, אפשר לדלג על הבדיקה הזו בגרסאות build שלא ניתן לנפות בהן באגים (משתמש), אבל רק אם רוצים לבטל את ההסכמה לתמיכה בתכונה "סנכרון הרשאות CDM".

הבדיקות חייבות לעבור בגרסאות build שניתן לבצע בהן ניפוי באגים, ללא יוצא מן הכלל.

דרישות מוקדמות לבדיקה בגרסאות build שלא ניתן לנפות בהן באגים

אם אתם לא פטורים, ודאו שאתם עומדים בדרישות המוקדמות הבאות.

הערוץ המאובטח משתמש ב-AVF (AttestationVerificationFramework) כדי לאמת את מהימנות החומרה. האישורים שנוצרים על ידי שני הצדדים מכילים כמה פריטי מידע על עצמם, כדי לוודא שלא בוצע שינוי לא מורשה במערכת שלהם. במהלך תהליך האימות, AVF בודק את המצבים הבאים:

  • למכשיר יש גישה לאינטרנט

  • במכשיר מוגדר אתחול מאומת וגרסת ה-build חתומה באמצעות מפתח הפצה (לא מפתח פיתוח)

  • תוכנת האתחול של המכשיר נעולה. למידע נוסף, ראו נעילת תוכנת האתחול.

  • רמות התיקון של מערכת ההפעלה, מפתח ההפעלה ומפתח הספק הן בטווח של 12 חודשים. אל תשתמשו בגרסה שנוצרה לפני יותר משנה.

  • אימות המכשיר מגובה באחד מאישורי הבסיס שאושרו על ידי הספק. מציינים את אישורי הבסיס המהימנים בשכבת-העל של המשאב vendor_required_attestation_certificates.xml.

הרצת בדיקות מצד המארח

בדיקות מסוימות של כמה מכשירים, כמו בדיקות NFC, דורשות הגדרה נוספת. בבדיקות שדורשות הגדרה נוספת, כל בדיקה מופעלת בנפרד. בבדיקות שלא דורשות הגדרה נוספת, אפשר להריץ את הבדיקות בקבוצה.

  1. בתחנת העבודה לבדיקה, מפעילים את מסוף cts-v-host מהספרייה שבה חבילת ה-ZIP של CTS-V נפתחה:

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

  2. באפליקציית CTS-V במכשיר הנבדק, לוחצים על Host-side Tests (בדיקות מצד המארח). באיור 4 מוצגות הבדיקות מצד המארח באפליקציית CTS-V:

    בדיקות מצד המארח באפליקציית CTS-V

    איור 4. בדיקות מצד המארח באפליקציית CTS-V.

    מוצגת רשימה של מודולים לבדיקה של מספר מכשירים מצד המארח.

  3. במסוף המארח של CTS-V, משתמשים בפקודה הבאה כדי להריץ בדיקות בכמה מכשירים שמשתמשות בהגדרה רגילה של שני מכשירים:

    run cts-v-host-multidevice-default

    התוצאות מופיעות מתחת לכל מודול בדיקה באפליקציית CTS-V במכשיר שנבדק. בדיקות שמסומנות בירוק עברו, ובדיקות שמסומנות באדום נכשלו.

    באיור 5 מוצגות תוצאות לדוגמה של בדיקות CtsCompanionDeviceManager:

    תוצאות הבדיקה של כמה מכשירים מצד המארח באפליקציית CTS-V

    איור 5. תוצאות הבדיקה של כמה מכשירים מצד המארח באפליקציית CTS-V.

  4. במסוף המארח של CTS-V, משתמשים בפקודה הבאה כדי להריץ את הבדיקות האינטראקטיביות:

    run cts-v-host-interactive

    התוצאות מופיעות מתחת לכל מודול בדיקה באפליקציית CTS-V במכשיר שנבדק. בדיקות שמסומנות בירוק עברו, ובדיקות שמסומנות באדום נכשלו.

  5. לכל בדיקה שנדרשת בה הגדרה נוספת, מריצים את הבדיקה בנפרד באמצעות הפקודה הבאה:

    run cts-v-host -m test_module_name

    לדוגמה, כדי להריץ את בדיקות ה-NFC, משתמשים בפקודה הזו:

    run cts-v-host -m CtsNfcHceMultiDeviceTestCases

    התוצאות מופיעות מתחת לכל מודול בדיקה באפליקציית CTS-V במכשיר שנבדק. בדיקות שמסומנות בירוק עברו, ובדיקות שמסומנות באדום נכשלו.

הרצת בדיקות של חיבור לנקודת גישה ל-Wi-Fi

אפשר להריץ את בדיקות החיבור לנקודת הגישה ל-Wi-Fi בשתי דרכים:

  • אפשרות 1: משתמשים ברשת Wi-Fi קיימת שהגדרתם ל-CTS-V.
  • אפשרות 2: הגדרת נקודת גישה ניתנת לתכנות.

אפשרות 1: שימוש ברשת Wi-Fi קיימת שהגדרתם ל-CTS-V

כדי להריץ את בדיקות החיבור לנקודת הגישה של ה-Wi-Fi ברשת Wi-Fi קיימת:

  1. עורכים את קובץ התצורה של סביבת הבדיקה (WifiConnectionTestbed.yaml). הקובץ הזה נמצא בספרייה שבה חולץ CTS-Verifier. לדוגמה:

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

  2. משנים את הערך של השדות wifi_ssid ו-wifi_password ל-SSID ולסיסמה של רשת ה-Wi-Fi. בדוגמה הבאה אפשר לראות את המיקום של ההגדרות האלה:

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

  3. במסוף המארח של CTS-V, מריצים את הפקודה הבאה:

    run cts-v-host -m CtsWifiConnectionTests

אפשרות 2: הפעלה עם נקודת גישה ניתנת לתכנות

כדי להריץ את בדיקות החיבור לנקודת הגישה ל-Wi-Fi בנקודת גישה שניתנת לתכנות:

  1. עורכים את קובץ התצורה של סביבת הבדיקה (WifiConnectionTestbed.yaml). הקובץ הזה נמצא בספרייה שבה חולץ CTS-Verifier. לדוגמה:

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

  2. משנים את הערך של hostname לכתובת ה-IP של ה-AP, בהתאם להגדרות ה-SSH המקומיות. כדי לזהות את כתובת ה-IP, עיינו בקטע איתור כתובת ה-IP של נקודת הגישה. בדוגמה הבאה אפשר לראות את המיקום של ההגדרה 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. במסוף המארח של CTS-V, מריצים את הפקודה הבאה:

    run cts-v-host -m CtsWifiConnectionTests

הרצת בדיקות USB מצד המארח

ב-Android 17 יש בדיקות CTS-V מצד המארח של USB שצריך להפעיל באמצעות adb דרך Wi-Fi.

בחלק מבדיקות ה-USB צריך להשתמש במארח CTS-V כדי לגשת לממשקי SystemAPI שיש להם הרשאות שלאפליקציית CTS-V הרגילה אין גישה אליהן. הבדיקות האלה לא קשורות למכשיר אחר וצריך להשתמש ב-adb דרך Wi-Fi.

האביזרים הבאים מסוג Type-C נדרשים אם המכשיר הנבדק תומך בדיווח על סוג BC 1.2 של השותף ליציאה או על פרופילי מתח USB ב-UsbPort.java:

  • מטען USB Type-C עם אספקת מתח (PD)
  • יציאת USB לטעינת סוללה 1.2 (BC 1.2) עם תקן SDP. היציאות האלה מוגבלות לאספקת 500mA או 900mA ל-DUT, והן נמצאות בדרך כלל ביציאות ה-USB של רכזות חיצוניות.
  • יציאת USB BC 1.2 לטעינה במורד הזרם (CDP). היציאות האלה יכולות לספק זרם של 1.5 אמפר ל-DUT ולנתונים. יציאת Type-C במחשב נייד או במחשב שולחני היא בדרך כלל CDP.
  • יציאת טעינה ייעודית (DCP) בתקן USB BC 1.2. היציאות האלה יכולות לספק זרם של 1.5 אמפר ל-DUT ללא נתונים. סביר להניח שמטען USB Type-C PD ברשימה הזו הוא DCP.

  1. מחברים את המכשיר הנבדק באמצעות adb דרך Wi-Fi. פרטים על ההגדרה מופיעים במאמר התחברות למכשיר באמצעות Wi-Fi.

  2. נתקו פיזית את המכשיר מכל חיבורי ה-USB. הבדיקה תיכשל אם המכשיר מחובר למארח USB או לאביזר כלשהו בזמן הרצת פקודת הבדיקה.

  3. מריצים את פקודת הבדיקה הבאה:

    run cts-v-host -m CtsUsbTypecTestCases

אחרי הבדיקות, התוצאות מופיעות באפליקציית CTS-V בקטע Host-side tests (בדיקות מצד המארח), כמו שמוצג בתמונות הבאות:

בדיקות USB מצד המארח באפליקציית CTS-V

איור 6. בדיקות USB מצד המארח באפליקציית CTS-V.

חבילת CtsUsbTypecTestCases באפליקציית CTS-V של USB מצד המארח

איור 7. חבילת CtsUsbTypecTestCases באפליקציית CTS-V ל-USB מצד המארח.

פתרון בעיות בבדיקות בכמה מכשירים

בקטע הזה מוסבר איך לפתור בעיות נפוצות.

לא ניתן לקבל את מספר הטלפון במהלך CtsTelecomTest

אם מופיעה הודעת השגיאה Failed to get phone number for <serial>, צריך לפעול לפי השלבים הבאים:

  1. מוודאים שבכל מכשיר לבדיקה מותקן כרטיס SIM.

  2. אם השגיאה נמשכת, יכול להיות שכרטיסי ה-SIM לא תומכים באחזור מספרים אוטומטי. במקרה כזה, צריך לציין במפורש את מספרי הטלפון בפקודה.

    לדוגמה, עבור DUT 1 (מספר סידורי 17011FDEE0002N, מספר טלפון 555-0000) ו-DUT 2 (מספר סידורי R3CN90YNAR, מספר טלפון 555-1111), מוסיפים את הארגומנטים הבאים לפקודה run cts-v-host:

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

אין תגובה מהשרת במהלך CtsMultiDeviceGenericRangingAccuracyTests

אם מופיעה הודעת השגיאה הבאה, יכול להיות שאפליקציית הבדיקה הוקפאה או נסגרה על ידי ניהול תהליכים ברקע שספציפי ל-OEM במכשירים מסוימים:

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

כדי לפתור את הבעיה, צריך להשבית את ההגבלות על פעילות ברקע או להוסיף לרשימת ההיתרים את החבילות הבאות:

חבילה שם לתצוגה
com.google.snippet.uwb CtsUwbSnippetApp
com.google.snippet.ranging CtsRangingSnippetApp
com.google.snippet.bluetooth CtsBluetoothMultiDeviceSnippetApp
com.google.android.mobly.snippet.bundled androidx.multidex.MultDexApplication

תיקון הבעיה "אין תגובה ל-GetFirmwareVersion במהלך בדיקות NFC"

אם אתם מקבלים את ההודעה verify_firmware_version RuntimeError: No response for GetFirmwareVersion בזמן הרצת הבדיקות בכמה מכשירים, לבדיקות אין גישה ללוח PN532 NFC.

כדי לפתור את הבעיה, צריך לזהות את הנתיב הטורי שבו משתמש לוח ה-NFC של PN532 במארח, למשל dev/ttyUSB1, ואז לציין אותו ידנית באמצעות הארגומנט --module-arg במסוף:

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

תיקון הודעת השגיאה "העסקה נכשלה" במהלך בדיקות NFC

אם אתם מקבלים את ההודעה Transaction failed, check device logs for more information. בכל מקרי הבדיקה של NFC, כנראה ששבב ה-NFC של המכשיר הנבדק לא יכול לזהות את ה-PN532.

אם יש לכם כמה מכשירים שמחוברים למארח, ובחלק מהם אין PN532 בחלק העליון, יכול להיות שנבחר ה-DUT הלא נכון. מידע נוסף זמין במאמר בנושא הגדרת בדיקות NFC.

כדי לפתור את הבעיה הזו, אתם יכולים לבצע אחת מהפעולות הבאות:

  • מגדירים את המספר הסידורי הנכון של ה-DUT בפקודת הבדיקה מצד המארח באמצעות הדגל -s.

  • מנתקים מהמארח את כל המכשירים שהם לא DUT.

המערכת מתעלמת ממקרה הבדיקה test_permissions_sync של CDM

אם הבדיקה פועלת במכשירים שלא ניתן לבצע בהם ניפוי באגים, צריך לבדוק אם יש לכם פטור. אם לא, ודאו ששני המכשירים עומדים בדרישות המוקדמות.