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

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

הגדרת הסביבה הפיזית

חלק מבדיקות ה-CTS דורשות שימוש במכשירים חיצוניים שצריך להגדיר אותם בקרבת המכשיר שנבדק (DUT). כדי להגדיר את הסביבה הפיזית:

1. (אופציונלי) אם ה-DUT תומך ב-Bluetooth LE, מציבים לפחות שלושה משואות Bluetooth LE במרחק של עד 5 מטרים מה-DUT לצורך בדיקת סריקת Bluetooth LE. בנוסף:

   • אין צורך להגדיר את משדרי ה-Beacon או לשדר משהו ספציפי.
   • המשואות יכולות להיות מכל סוג, כולל iBeacon,‏ Eddystone או אפילו מכשירים שמדמים משואות BLE.

2. ממקמים את הטלפון מול סצנה, כמו קיר או תקרה, במרחק ששווה למרחק המיקוד המינימלי של המכשיר הנבדק. בנוסף:

   • התאורה בסצנה צריכה להיות מספיק טובה כדי לאפשר לחיישנים שנבדקים להגיע לקצב הפריימים המקסימלי שהוגדר (FPS) ולשמור עליו, כפי שמפורט במאמר CONTROL_AE_TARGET_FPS_RANGE.
   • ההגדרה הזו חלה על כל חיישני המצלמה שמדווחים על ידי getCameraIdList, כי הבדיקה חוזרת על עצמה במכשירים הרשומים ומודדת את הביצועים בנפרד.
   • אם ה-DUT תומך במצלמות חיצוניות, כמו מצלמות רשת בחיבור USB, צריך לחבר מצלמה חיצונית כשמריצים את CTS. אחרת, בדיקות ה-CTS ייכשלו.

3. (אופציונלי) אם ה-DUT תומך במערכת מיקום גלובלית (GPS) או במערכת לוויינים גלובלית אחרת לניווט (GNSS), צריך לספק אות GNSS ל-DUT ברמת אות מתאימה לקליטה ולחישוב המיקום. בנוסף:

   • ה-GPS צריך לעמוד בדרישות של ICD-GPS-200C.
   • אות ה-GNSS יכול להיות מכל סוג, כולל סימולטור של לוויין או משחזר של אותות בחוץ.
   • אפשר למקם את המכשיר קרוב לחלון כדי שיוכל לקבל ישירות אות GNSS חזק מספיק מלוויין.

4. מוודאים שרשת ה-Wi-Fi תומכת ב-IPv4 וב-IPv6, שיש לה חיבור לאינטרנט עם DNS ל-IPv4 ול-IPv6, שהיא תומכת בשידור מרובה של IP ושניתן להתייחס למכשיר הנבדק כאל לקוח מבודד.

   אם אין לכם גישה לרשת IPv6 מקומית, לרשת סלולרית IPv6 או ל-VPN כדי לעבור בדיקות IPv6, אתם יכולים להשתמש בנקודת גישה ל-Wi-Fi ובמנהרת IPv6.

5. מוודאים שהדגלים UP, BROADCAST ו-MULTICAST מוגדרים בממשק ה-Wi-Fi של ה-DUT.

6. מוודאים שהוקצו לכם כתובות IPv4 ו-IPv6 בממשק ה-Wi-Fi. כדי לבדוק את מאפייני ממשק ה-Wi-Fi, מריצים את הפקודה adb shell ifconfig.

7. (אופציונלי) אם ה-DUT תומך ב-Wi-Fi STA או ב-STA concurrency, צריך להגדיר לפחות שתי רשתות Wi-Fi. רשתות ה-Wi-Fi האלה צריכות לפעול בתדרים שונים עם מספרי SSID שונים, או באותו מספר SSID עם מספרי BSSID שונים.

8. (אופציונלי) אם ה-DUT תומך בזמן הלוך ושוב (RTT) של Wi-Fi, צריך להגדיר מכשיר שתומך ב-Wi-Fi RTT:

   1. ממקמים את מכשיר ה-Wi-Fi RTT במרחק של עד 12 מטרים מהמכשיר הנבדק.
   2. מפעילים את מכשיר ה-Wi-Fi RTT.

   הנה שני מכשירים מומלצים שתומכים ב-Wi-Fi RTT: - Google Wifi - נקודת הגישה fitlet2 של Compulab (מוגדרת לרוחב פס של ‎40 MHz בתדר ‎5 GHz).

הגדרת המחשב

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

דרישות לציוד ל-Meet

המחשב שלכם שבו מותקן CTS צריך לעמוד בדרישות החומרה הבאות או להיות טוב יותר:

• מערכת x86 בגרסת 64 ביט

• לפחות 256 GB של מקום פנוי בכונן כדי להכיל את המספר הגדל של תרחישי בדיקה של CTS ואת הגידול בהקצאת מקום ב-Java heap ב-Tradefed

• זיכרון RAM בנפח 32GB לפחות

עמידה בדרישות של מערכת ההפעלה

• במחשב הפיתוח צריך להיות מותקן Linux מ-64 ביט עם GNU C Library‏ (glibc) מגרסה 2.17 ואילך.

• כדי ש-CTS יוכל לפתור את הנתיב בצורה נכונה, צריך להגדיר את השפה של מערכת ההפעלה ל'אנגלית'.

התקנת תוכנה במחשב

כדי להתקין את תוכנת שולחן העבודה המתאימה ל-CTS:

1. מתקינים את חבילת FFmpeg בגרסה 5.1.3 ומעלה.

2. מתקינים את הגרסאות העדכניות ביותר של Android Debug Bridge (ADB) ושל Android Asset Packaging Tool (AAPT2) ומוסיפים את המיקום של הכלים האלה לנתיב המערכת של המחשב:

   1. כדי להתקין את כלי שורת הפקודה sdkmanager, פועלים לפי ההוראות שבתחילת התיעוד של SDK Manager. הקישור להורדת כלי שורת הפקודה נמצא בקטע Command line tools only (כלים לשורת הפקודה בלבד) בתחתית דף ההורדה של Android Studio.
   2. מעדכנים את נתיב המערכת כך שיכלול את המיקום של sdkmanager שהותקן לאחרונה.
   3. באמצעות sdkmanager, מתקינים את החבילות העדכניות של platform-tools ושל build-tools. החבילות האלה מכילות את adb ואת AAPT2. מידע על התקנת חבילות זמין במאמר התקנת חבילות.
   4. מעדכנים את הנתיב כך שיכלול את המיקום של כלי ה-adb ו-AAPT2 שהותקנו לאחרונה.
   5. מוודאים ש-adb ו-AAPT2 נמצאים בנתיב.

3. מתקינים את הגרסה המתאימה של Java Development Kit (JDK):

   • ב-Android מגרסה 11 ואילך, צריך להתקין JDK 11.
   • ל-Android מגרסה 10 ומטה, אפשר לעיין במאמר הגדרת CTS (AOSP מגרסה 10 ומטה).

4. (אופציונלי) ב-Android 13 וב-Android 14, מתקינים את virtualenv. הכלי virtualenv נדרש לבדיקות במכשירים מרובים.

5. כדי לוודא ש-Python מותקן, מקלידים python3. צריכות להופיע גרסת Python והתאריך, כדי לציין ש-Python מותקן בצורה תקינה.

6. מורידים ופותחים את חבילות ה-CTS מתוך הורדות של חבילות בדיקת תאימות שתואמות לגרסת Android במכשירים ולכל ממשקי ה-ABI שהמכשירים תומכים בהם.

7. מורידים ופותחים את הגרסה האחרונה של קובצי המדיה של CTS. קבצי המדיה כוללים קליפים מהסרט Big Buck Bunny, שמוגן בזכויות יוצרים של Blender Foundation במסגרת רישיון Creative Commons Attribution 3.0.

8. (אופציונלי) כשמריצים את CTS בפעם הראשונה, המערכת מורידה באופן דינמי קובצי CTS שקשורים ל-Mainline. בהתאם למהירות הרשת, ההורדה הזו מוסיפה 10 דקות או יותר לזמן הריצה של CTS.

   כדי להימנע מזמן הריצה הנוסף של CTS, אפשר להוריד את קובצי ה-CTS שקשורים ל-Mainline לפני שמריצים את CTS. מידע על הורדה של קובצי CTS שקשורים ל-Mainline זמין במאמר הורדה של קובצי CTS שקשורים ל-Mainline.

הכנת ה-DUT

אחרי שמגדירים את המחשב, צריך להגדיר את ה-DUT.

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

כדי להגדיר את ה-DUT:

1. מוודאים שבמכשיר הנבדק פועל קובץ אימג' של מערכת שמבוסס על גרסת משתמש ידועה ותואמת (Android 4.0 ומעלה) מתוך שמות קוד, תגים ומספרי גרסה, ושהוא משתמש בגרסת build‏ user. מידע נוסף על וריאציות של build זמין במאמר בחירת יעד.

2. אם מערכת ההפעלה של ה-DUT היא Android 13 או גרסה מתקדמת יותר, צריך לוודא ש-ro.product.first_api_level מוגדר ב-build לרמת ה-API שבה המכשיר הושק מסחרית. כדי להגדיר את הערך הזה, מבצעים את השינוי הבא בקובץ device.mk:

   PRODUCT_SHIPPING_API_LEVEL := 21
   

   חלק מהדרישות של CTS תלויות בגרסת ה-Build שבה נשלח המכשיר במקור. לדוגמה, יכול להיות שמכשירים שנשלחים במקור עם גרסאות build מוקדמות יותר לא ייכללו בדרישות המערכת שחלות על מכשירים שנשלחים עם גרסאות build מאוחרות יותר. ערכים תקינים של רמת API מפורטים במאמר Codenames, Tags, and Build Numbers. מידע נוסף על ro.product.first_api_level זמין במאמר בנושא רמת Vendor API.

   ל-Android מגרסה 10 ומטה, אפשר לעיין במאמר בנושא הגדרת CTS (AOSP מגרסה 10 ומטה).

3. אם המכשיר תומך בניהול חבילות APEX:

   1. מורידים את חבילת ה-shim של APEX לגרסת Android ולסוג הארכיטקטורה של החומרה הספציפיים שלכם. שתי העמודות הימניות בטבלה חבילות shim מספקות קישורים לחבילה להורדה.
   2. מעתיקים את החבילה שהורדתם אל /system/apex.
   3. משנים את שם הקובץ ל-com.android.apex.cts.shim.apex.

4. אם המכשיר לא תומך בניהול חבילות APEX:

   1. מורידים את חבילות ה-shim של APEX לגרסת Android ולסוג הארכיטקטורה של החומרה הספציפיים שלכם. שתי העמודות השמאליות בטבלה shim packages מספקות קישורים לחבילות להורדה.
   2. העתקת CtsShim.apk אל /system/app/
   3. שינוי השם של CtsShim.apk ל-CtsShimPrebuilt.apk
   4. העתקת CtsShimPriv.apk אל /system/priv-app/
   5. שינוי השם של CtsShimPriv.apk ל-CtsShimPrivPrebuilt.apk

5. אם המכשיר מדווח על יותר מרכיב מאובטח אחד:

   1. מורידים את google-cardlet.cap.
   2. מעתיקים את הקובץ שהורד אל /data/uicc/cardlets/.

6. אם המכשיר מדווח על יותר מרכיב מאובטח אחד, צריך להתקין את האפלט לדוגמה ברכיב המאובטח המוטמע (eSE) של המכשיר הנבדק או בכרטיס ה-SIM שבו המכשיר הנבדק משתמש. מידע נוסף זמין במאמר בנושא בדיקת CTS של רכיב מאובטח.

7. אם למכשיר אין מסך מובנה, מחברים מסך למכשיר.

8. אם במכשיר יש חריץ לכרטיס זיכרון, מחברים כרטיס SD ריק. כדי לוודא שהכרטיס יעבור את בדיקת התאימות (CTS), צריך להשתמש בכרטיס SD שתומך באפיק (bus) במהירות גבוהה במיוחד (UHS) עם קיבולת SDHC או SDXC, או בכרטיס עם סיווג מהירות 10 ומעלה.

9. אם במכשיר יש חריצים לכרטיסי SIM, מכניסים כרטיס SIM פעיל לכל חריץ. אם המכשיר תומך ב-SMS, צריך למלא את שדה המספר של כל כרטיס SIM. במכשירים עם Android 12 ואילך, כל כרטיסי ה-SIM צריכים לתמוך באחסון של מספרי חיוג מקוצרים (ADN). כרטיסי GSM ו-USIM עם קובץ ייעודי לטלקום (DF_Telecom) עומדים בדרישה הזו.

10. מוודאים שבמכשיר יש כרטיס SIM עם הרשאות של ספק CTS שעומד בדרישות שמפורטות במאמר הכנת כרטיס ה-UICC.

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

כדי להגדיר את ה-DUT לשימוש עם CTS:

במכשיר הנבדק:

1. מאפסים את המכשיר לנתוני היצרן.

2. להגדיר את השפה במכשיר לאנגלית (ארצות הברית).

3. אם המכשיר תומך בהתאמה אישית של גופני ברירת המחדל, צריך לוודא שמשפחת הגופנים sans-serif מוגדרת כברירת מחדל ל-Roboto.

4. אם יש במכשיר GPS או תכונה של רשת Wi-Fi או רשת סלולרית, צריך להפעיל את הגדרת המיקום.

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

6. מוודאים שלא הוגדרו קו ביטול נעילה או סיסמה.

7. הפעלת ניפוי באגים ב-USB:

   1. עוברים אל הגדרות > מידע על הטלפון ומקישים על מספר Build שבע פעמים. האפשרות אפשרויות למפתחים מופיעה בקטגוריית ההגדרות מערכת.

   2. מקישים על ניפוי באגים ב-USB.

   כדי להפעיל ניפוי באגים ב-USB ב-Android גרסה 10 ומטה, אפשר לעיין במאמר הגדרה של CTS (AOSP גרסה 10 ומטה).

8. מגדירים את הזמן בפורמט של 12 שעות.

9. מפעילים את האפשרות אפשרויות למפתחים > המכשיר יישאר פעיל.

10. השבתת אימות אפליקציות ב-USB:

    1. עוברים אל אפשרויות למפתחים.

    2. מקישים על אימות אפליקציות דרך USB.

11. ב-Android 13 ואילך, מפעילים את ההגדרה 'מודם מדומה':

    1. עוברים אל אפשרויות למפתחים.

    2. מקישים על הרשאה לשימוש במודם מדומה.

    ההגדרה הזו נדרשת לבדיקות ספציפיות של טלפוניה.

במחשב:

1. מפעילים את הדפדפן וסוגרים את מסך ההגדרה או מסך ההפעלה.

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

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

4. הגדרת Roboto2 כגופן sans-serif באמצעות הגדרה נגישה למשתמש (לא מוסתרת).

5. מעתיקים את קובצי המדיה של CTS אל ה-DUT:

   1. עוברים (cd) לנתיב שבו קובצי המדיה מורדים ונפרסים.

   2. משנים את הרשאות הקובץ:

      chmod u+x copy_media.sh
      

   3. מעתיקים את הקבצים:

      • כדי להעתיק קליפים ברזולוציה של עד 720x480, מריצים את הפקודה:

        ./copy_media.sh 720x480

      • אם אתם לא בטוחים מה הרזולוציה המקסימלית, כדאי להעתיק את כל הקבצים:

        ./copy_media.sh all

      • אם יש כמה מכשירים בבדיקה, מוסיפים את האפשרות serial (מספר סידורי) (-s) של מכשיר ספציפי לסוף. לדוגמה, כדי להעתיק עד 720x480 למכשיר עם המספר הסידורי 1234567, מריצים את הפקודה:

        ./copy_media.sh 720x480 -s 1234567

הורדת קובצי CTS שקשורים ל-Mainline

כדי להוריד את קובצי ה-CTS שקשורים ל-Mainline:

1. כדי לקבל את רמת Android API במכשיר, מריצים את הפקודה:

   adb shell getprop ro.build.version.sdk
   

2. פועלים לפי ההוראות בסקריפט download_mcts.sh כדי להוריד את קובצי ה-CTS של Mainline.

   ההורדה נמשכת לפחות 10 דקות, בהתאם למהירות הרשת.

חבילות Shim

בטבלה הבאה מפורטים החבילות שזמינות לכל גרסה ולארכיטקטורה של מכשיר:

גרסת המכשיר	חבילות (אם נתמך APEX)		חבילות (אם אין תמיכה ב-APEX)
	דריכה	x86	דריכה	x86
Android 16	16-arm-release	android16-x86-release	android16-arm-CtsShim.apk android16-arm-CtsShimPriv.apk	android16-x86-CtsShim.apk android16-x86-CtsShimPriv.apk
Android 15	15-arm-release	android15-x86-release	android15-arm-CtsShim.apk android15-arm-CtsShimPriv.apk	android15-x86-CtsShim.apk android15-x86-CtsShimPriv.apk
Android 14	android14-arm-release	android14-x86-release	android14-arm-CtsShim.apk android14-arm-CtsShimPriv.apk	android14-x86-CtsShim.apk android14-x86-CtsShimPriv.apk
Android 13	android13-arm-release	android13-x86-release	android13-arm-CtsShim.apk android13-arm-CtsShimPriv.apk	android13-x86-CtsShim.apk android13-x86-CtsShimPriv.apk
12 ‏Android	android12-arm-release	android12-x86-release	android12-arm-CtsShim.apk android12-arm-CtsShimPriv.apk	android12-x86-CtsShim.apk android12-x86-CtsShimPriv.apk
Android 11	android11-arm-release	android11-x86-release	android11-arm-CtsShim.apk android11-arm-CtsShimPriv.apk	android11-x86-CtsShim.apk android11-x86-CtsShimPriv.apk
‫Android 10	android10-release		android10-arm-CtsShim.apk android10-arm-CtsShimPriv.apk	android10-x86-CtsShim.apk android10-x86-CtsShimPriv.apk
‫Android 9,‏ O ו-O-MR1	לא רלוונטי	לא רלוונטי	arm-CtsShim.apk arm-CtsShimPriv.apk	x86-CtsShim.apk x86-CtsShimPriv.apk

מה השלב הבא?

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