הרצת בדיקות במכשירים מרובים באמצעות CTS Verifier

בדף הזה מוסבר איך להשתמש בבדיקות Better Together CTS Verifier ‏ (CTS-V) ב-Android 16 QPR2 או בגרסה מתקדמת יותר.

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

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

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.

   • מידע על הגדרת DUT זמין במאמר הגדרת DUT.
   • הוראות להגדרת 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.

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

בדיקות החיבור לנקודת הגישה (AP) ל-Wi-Fi‏ (CtsWifiConnectionTests) בודקות את הקישוריות בין המכשיר הנבדק לבין נקודת הגישה. מומלץ מאוד להריץ את הבדיקות האלה, אבל הן לא נדרשות ב-CTS-V Android 16 16 QPR2.

כדי להריץ את הבדיקות האלה, צריך מכשיר DUT ונקודת גישה OpenWrt Banana Pi R3.

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

1. רוכשים את Banana Pi R3 AP ואת האביזרים שמפורטים בטבלה הזו:

   פריט	כמות
   לוח BPi-R3, בדומה ל-Banana Pi BPI-R3 Router Board with MediaTek MT7986 chip design support Wi-Fi 6 ,2G DDR RAM ,8G eMMC flash onboard	1
   מארז אלומיניום BPi-R3, דומה למארז הברזל BPI-R3	1
   צלעות קירור מאלומיניום BPi-R3 (מאוורר קירור), בדומה לצלעות קירור מאלומיניום BPI-R3 עם מאוורר	1
   אנטנה של 2 ו-5 GHz עם כבל, בדומה לאנטנת 5DB בחנות BPI	8
   מתאם מתח, בדומה לספק מתח DC‏ 12V/2A	1

   כדי לבצע את הרכישה, אפשר לעיין בקטע תהליך רכישה נוח בדף של Banana Pi BPI-R3.

2. מגדירים את נקודת הגישה. מידע על הגדרת נקודת הגישה זמין במאמר הגדרת נקודת הגישה Banana Pi BPI-R3.

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

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

   

   איור 2. ‫DUT ו-AP בתיבת מגן.

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

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

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

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

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

3. אופציונלי: מגדירים כלי לניטור תעבורה (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 חודשים. אל תשתמשו בגרסה שגיל שלה הוא יותר משנה

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

הרצת בדיקות מרובות מכשירים בצד המארח (AOSP 16 ואילך)

ב-CTS Verifier 16 נוספה תמיכה בבדיקות מרובות מכשירים בצד המארח. אפשר להריץ את הבדיקות האלה באמצעות סקריפטים אוטומטיים במארח, במקום לבצע את הבדיקה באופן ידני במכשיר. אחרי שכל בדיקה מסתיימת, התוצאות מועלות אוטומטית אל ה-DUT ומוצגות באפליקציית CTS Verifier.

בקטע הזה מוסבר איך מריצים את הבדיקות מרובות המכשירים בצד המארח.

הרצת בדיקות במספר מכשירים

כדי להריץ בדיקה בכמה מכשירים:

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

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

2. באפליקציית CTS Verifier ב-DUT, לוחצים על Host-side Tests (בדיקות בצד המארח). באיור 3 מוצגים הבדיקות בצד המארח באפליקציית CTS Verifier:

   

   איור 3. בדיקות של כמה מכשירים בצד המארח באפליקציית CTS Verifier.

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

3. מזהים את השם של מודול הבדיקה שרוצים להריץ. לדוגמה, המודול CompanionDeviceManager מופיע בתור CtsCompanionDeviceManagerMultiDeviceTestCases.

4. במסוף של cts-v-host, מריצים את הפקודה הבאה:

   run cts-v-host -m test_module_name
   

   לדוגמה:

   run cts-v-host -m CtsCompanionDeviceManagerMultiDeviceTestCases
   

   אחרי שהבדיקות מסתיימות במסוף xTS, התוצאות מופיעות באפליקציית CTS Verifier. בדיקות שמסומנות בירוק עברו בהצלחה. הבדיקות שמסומנות באדום נכשלו. איור 4 מציג תוצאות לדוגמה של הבדיקות CtsCompanionDeviceManager:

   

   איור 4. תוצאות בדיקה של כמה מכשירים בצד המארח באפליקציית CTS Verifier.

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

כדי להריץ בדיקות חיבור לנקודת גישה ל-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 בקובץ WifiConnectionTestbed.yaml:

   TestBeds:
   - Name: WifiConnectionTestbed
     Controllers:
       # Specify settings for the AP.
       OpenWrtDevice:
       - hostname: AP-IP
         skip_init_reboot: True
   

3. במסוף של cts-v-host, מריצים את הפקודה הבאה:

   run everything -m CtsWifiConnectionTests
   

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

בקטע הזה אנחנו מציעים עזרה בפתרון בעיות אפשריות.

פתרון הבעיה 'אין תגובה לפונקציה 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 מהמארח.

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

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