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

בדף הזה מוסבר איך להגדיר ולהריץ בדיקות של Android 16 QPR2 ו-Android 17 בצד המארח של CTS Verifier‏ (CTS-V). יש שני סוגים של בדיקות בצד המארח: בדיקות של כמה מכשירים (שהושקו לפני 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. כדי לבדוק אם גרסת ה-Python שלכם כוללת את המודול venv, מריצים את הפקודה 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. כדי לבדוק אם גרסת ה-Python שלכם כוללת את המודול venv, מריצים את הפקודה python3 -m venv venv. אם הפקודה הזו נכשלת, מוצגת הודעת שגיאה. פועלים לפי ההנחיות כדי להתקין את חבילת python3.x-venv.

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

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

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

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

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

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

בבדיקות NFC נעשה שימוש ב-DUT אחד ובשבב NFC PN532 אחד.

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

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

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

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

     

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

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

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

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

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

• אפשרות 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 שניתנות לניפוי באגים, ללא יוצא מן הכלל.

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

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

הערוץ המאובטח משתמש ב-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 ב-DUT, לוחצים על 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 בשתי דרכים:

• אפשרות 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: הפעלה עם נקודת גישה (AP) שניתנת לתכנות

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

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 כולל בדיקות USB CTS-V בצד המארח שנדרש adb כדי להריץ אותן דרך Wi-Fi.

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

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

• מטען USB-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 ולנתונים. יציאת USB-C במחשב נייד או במחשב היא כנראה CDP.
• יציאת טעינה ייעודית (DCP) בתקן USB BC 1.2. היציאות האלה יכולות לספק 1.5 אמפר ל-DUT ללא נתונים. המטען USB Type-C PD ברשימה הזו הוא כנראה DCP.

1. מחברים את ה-DUT באמצעות 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
   

אין תגובה מהשרת במהלך 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.

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

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

כדי לפתור את הבעיה, אפשר:

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

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

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

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