החל משנת 2026, כדי להתאים את התהליך למודל הפיתוח היציב שלנו ולשמור על יציבות הפלטפורמה בסביבה העסקית, נפרסם קוד מקור ב-AOSP ברבעון השני וברבעון הרביעי. כדי ליצור תוספים ל-AOSP ולתרום לו, מומלץ להשתמש ב-android-latest-release במקום ב-aosp-main. ענף המניפסט android-latest-release תמיד יפנה לגרסה העדכנית ביותר שנדחפה ל-AOSP. מידע נוסף זמין במאמר שינויים ב-AOSP.

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

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

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

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

מוודאים שהמחשב שלכם עומד בדרישות מערכת ההפעלה של CTS.
פועלים לפי שלבים 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.
מכינים שני מכשירים זהים שנבדקים (DUT), שלכל אחד מהם מוגדר CTS-V.
- מידע על הגדרת DUT זמין במאמר הגדרת DUT.
- הוראות להגדרת CTS-V מופיעות במאמר הגדרה.
עוברים לקטע ההגדרה של סוג הבדיקה:
- למידע על בדיקות NFC, אפשר לעבור אל הגדרת בדיקות NFC.
- כדי לבצע בדיקות של חיבור לנקודת גישה ל-Wi-Fi, עוברים אל הגדרה של בדיקות חיבור לנקודת גישה ל-Wi-Fi.
- כדי לבדוק את מודול ה-CDM, עוברים אל הגדרת בדיקות סטנדרטיות בשני מכשירים ואז אל הגדרת בדיקות CDM.
אם הבדיקה שלכם לא מופיעה ברשימה הזו, צריך לעבור אל הגדרת בדיקות רגילות בשני מכשירים

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

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

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

רוכשים שבב NFC PN532. אנחנו ממליצים על All-In-One PN532.
ב-DUT, עוברים לאפליקציית ההגדרות.
מפעילים את NFC.
ממקמים את שבב ה-NFC:
- בטלפונים, ממקמים את קורא ה-NFC של ה-DUT כמו שמוצג באיור 1:
  
  איור 1. מיקום שבב ה-NFC.
- בסוגי מכשירים אחרים, ממקמים את הצ'יפ ליד אנטנת ה-NFC של המכשיר.
מחברים את שבב ה-NFC‏ PN532 לתחנת העבודה לבדיקה באמצעות כבל USB.

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

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

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

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

רוכשים ומגדירים את Banana Pi R3 AP. מידע נוסף זמין במאמר בנושא הגדרת Banana Pi BPI-R3 AP.
אופציונלי: אם אין לכם תיבת מיגון, מומלץ להשתמש בתיבת המיגון 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

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

איור 2. ‫DUT ו-AP בתיבת מגן.
משתמשים ב-SSH כדי לוודא שנקודת הגישה נגישה מהמארח.

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

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

ממקמים שני מכשירי DUT תואמים של Android במרחק של כ-20 ס"מ זה מזה.
כדי להגדיר סביבה נקייה, מניחים את שני המכשירים בתוך קופסת מיגון.

הערה: אם נתקלתם בבעיות בבדיקות האלה ואתם זקוקים לעזרה, ודאו שהבדיקות בוצעו כששני המכשירים נמצאים בתוך תיבת מיגון.
אופציונלי: מגדירים כלי לניתוח תעבורה (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.

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

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

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

בתחנת העבודה של הבדיקה, מפעילים את מסוף cts-v-host מהספרייה שבה בוצעה פריקה של חבילת ה-zip של CTS-V:
```
./android-cts-verifier/android-cts-v-host/tools/cts-v-host-tradefed
```
באפליקציית CTS Verifier ב-DUT, לוחצים על Host-side Tests (בדיקות בצד המארח). באיור 3 מוצגים הבדיקות בצד המארח באפליקציית CTS Verifier:

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

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

הערה: אם מקישים על מודול בצד המארח באפליקציית CTS Verifier, לא מוצגת רשימה של תרחישי בדיקה נפרדים. במקום זאת, ממשק המשתמש מתמלא אוטומטית בתוצאות של מקרה הבדיקה אחרי שהמודול מופעל במארח.
במסוף של cts-v-host, מריצים את הפקודה הבאה:
```
run cts-v-host -m test_module_name
```
לדוגמה:
```
run cts-v-host -m CtsCompanionDeviceManagerMultiDeviceTestCases
```
הערה: אם מריצים את cts-v-host בלי להשתמש ב--m test_module_name, הפקודה מנסה להריץ את כל מודולי הבדיקה, תוך התעלמות מחריגות בדרישות המכשיר והחומרה. במקום זאת, מריצים את הפקודה run cts-v-host-default-devices כדי להריץ את הבדיקות עם ההגדרה הרגילה כתוכנית משנה יחידה.
הערה: אפשר לציין את מכשירי ה-DUT הספציפיים לבדיקה באמצעות המספרים הסידוריים שלהם: run cts-v-host -m test_module_name -s\ device1_serial -s device2_serial ...

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

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

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

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

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

עורכים את קובץ התצורה של סביבת הבדיקה (WifiConnectionTestbed.yaml). הקובץ הזה נמצא בספרייה שבה חולץ CTS-Verifier:
```
./android-cts-verifier/android-cts-v-host/testcases/CtsWifiConnectionTests/x86_64/connection/WifiConnectionTestbed.yaml
```
משנים את הערך של השדה 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
```
במסוף של cts-v-host, מריצים את הפקודה הבאה:
```
run everything -m CtsWifiConnectionTests
```
הערה: מידע נוסף על מסוף cts-v-host זמין במאמר בנושא הרצת בדיקות במספר מכשירים.

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

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

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

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