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

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

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

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

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

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

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

   • התאורה בסצנה צריכה להיות מספקת כדי לאפשר לחיישנים שנבדקים להגיע לקצב הפריימים המקסימלי שהוגדר (FPS) ולשמור עליו, כפי שמפורט במסמך CONTROL_AE_TARGET_FPS_RANGE.
   • ההגדרה הזו חלה על כל חיישני המצלמה שמדווחים על ידי getCameraIdList, כי הבדיקה חוזרת על עצמה במכשירים הרשומים ומודדת את הביצועים בנפרד.
   • אם ה-DUT תומך במצלמות חיצוניות, כמו מצלמות אינטרנט בחיבור 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 שמותנה בייחוס 3.0.

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

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

הכנת ה-DUT

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

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

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

1. מוודאים שבמכשיר DUT פועלת קובץ אימג' של המערכת שמבוססת על גרסת משתמש ידועה ותואמת (Android 4.0 ומעלה) מתוך שמות קוד, תגים ומספרי Build, ושהוא משתמש בוריאנט build 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. מידע נוסף על 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 שתומך באפיק במהירות גבוהה במיוחד (UHS) עם קיבולת SDHC או SDXC, או בכרטיס עם סיווג מהירות 10 ומעלה.

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

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

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

כדי להגדיר את המכשיר הנבדק לשימוש עם 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 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 אוטומטיות.