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

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

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

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

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

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

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

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

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

   • ה-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, צריך להגדיר לפחות שתי רשתות 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. פועלים לפי ההוראות שבתחילת התיעוד של SDK Manager כדי להתקין את כלי שורת הפקודה sdkmanager. הקישור להורדת כלי שורת הפקודה נמצא בקטע 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 ומגרסה 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.

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

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

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

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

   PRODUCT_SHIPPING_API_LEVEL := 21
   

   חלק מהדרישות של CTS תלויות בגרסת ה-Build שהמכשיר נשלח איתה במקור. לדוגמה, יכול להיות שמכשירים שנשלחים במקור עם גרסאות build מוקדמות יותר לא ייכללו בדרישות המערכת שחלות על מכשירים שנשלחים עם גרסאות build מאוחרות יותר. ערכים תקינים של רמת API מפורטים במאמר Codenames, Tags, and Build Numbers (שמות קוד, תגים ומספרי Build). מידע נוסף על 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. כדי לקבל את רמת ה-API של Android במכשיר, מריצים את הפקודה:

   adb shell getprop ro.build.version.sdk
   

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

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

חבילות Shim

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

גרסת המכשיר	חבילות (אם נתמך APEX)		חבילות (אם אין תמיכה ב-APEX)
	דריכה	x86	דריכה	x86
Android 16 QPR2	16-arm-release	android16-x86-release	android16-arm-CtsShim.apk android16-arm-CtsShimPriv.apk	android16-x86-CtsShim.apk android16-x86-CtsShimPriv.apk
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 אוטומטיות.