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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   • פרטים על הגדרת המכשיר הנבדק זמינים במאמר הגדרת המכשיר הנבדק.
   • פרטים על הגדרת CTS-V מופיעים במאמר בנושא הגדרה.

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

   • למידע על בדיקות NFC, אפשר לעבור אל הגדרת בדיקות NFC.
   • למידע על בדיקות חיבור לנקודת גישה ל-Wi-Fi, אפשר לעבור אל הגדרה של בדיקות חיבור לנקודת גישה ל-Wi-Fi.
   • הוראות להגדרת בדיקות דיוק טווח מופיעות במאמר הגדרת בדיקות דיוק טווח.
   • כדי לבדוק את מודול ה-CDM, עוברים אל הגדרת בדיקות סטנדרטיות בשני מכשירים ואז אל הגדרת בדיקות CDM.

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

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

בבדיקות NFC נעשה שימוש במכשיר אחד לבדיקה ובשבב NFC אחד מסוג PN532.

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

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

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

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

     

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

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

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

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

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

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

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

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

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

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

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

1. רוכשים את Banana Pi R3 AP ומגדירים אותו. מידע על רכישה והגדרה של Banana Pi R3 AP זמין במאמר בנושא הגדרה של Banana Pi BPI-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 לבין נקודת הגישה צריך להיות לפחות 10 ס"מ. איור 2 מציג את ההגדרה הזו:

   

   איור 2. מכשיר DUT ונקודת גישה בתיבת מגן.

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

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

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

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

   

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

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

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

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

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

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

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

4. אופציונלי: מגדירים כלי לניתוח תעבורה (sniffer) של OTA לניפוי באגים ב-Wi-Fi.

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

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

פטור

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

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

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

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

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

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

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

• תוכנת האתחול של המכשיר נעולה. לפרטים נוספים, ראו נעילת טוען האתחול.

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

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

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

חלק מהבדיקות במכשירים מרובים, כמו בדיקות 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:

   

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

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

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

   run cts-v-host-multidevice-default
   

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

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

   

   איור 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 AP בשתי דרכים:

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

אפשרות 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: הפעלה עם AP שניתן לתכנות

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

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

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

2. משנים את הערך של hostname לכתובת ה-IP של נקודת הגישה, בהתאם להגדרות ה-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 כדי לגשת ל-SystemAPIs שיש להם הרשאות שאפליקציית CTS-V הרגילה לא יכולה לגשת אליהן. הבדיקות האלה לא קשורות למכשיר ספציפי, וצריך להשתמש ב-adb באמצעות Wi-Fi.

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

• מטען USB Type-C Power Delivery ‏ (PD)
• יציאת USB לטעינת סוללה 1.2 (BC 1.2) רגילה במורד הזרם (SDP). היציאות האלה מוגבלות לאספקת 500 mA או 900 mA ל-DUT, והן נמצאות בדרך כלל ביציאות ה-USB של רכזות חיצוניות.
• יציאת טעינה במורד הזרם (CDP) בתקן USB BC 1.2. היציאות האלה יכולות לספק 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, כמו שמוצג באיורים הבאים:

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

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

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

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

הפעולה לקבלת מספר טלפון במהלך CtsTelecomTest נכשלה

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

1. מוודאים שבכל DUT מותקן כרטיס 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
   

No response from server during CtsMultiDeviceGenericRangingAccuracyTests

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

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

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

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

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

כדי לפתור את הבעיה, צריך לזהות את הנתיב הטורי שבו נעשה שימוש בלוח PN532 NFC במארח, כמו 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 של ה-DUT לא יכול לזהות את PN532.

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

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

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

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

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

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