הגדרת CTS

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

סביבה פיזית

איתותי Bluetooth LE

אם המכשיר שנבדק (DUT) תומך ב-Bluetooth LE, צריך למקם לפחות שלושה משואות Bluetooth LE בטווח של 5 מטרים מה-DUT לצורך בדיקת סריקה של Bluetooth LE. אין צורך להגדיר את הסמנים האלה או לגרום להם לשדר משהו ספציפי, והם יכולים להיות מכל סוג, כולל iBeacon,‏ Eddystone או אפילו מכשירים שמחקים סמנים של BLE.

Ultra Wideband (UWB)

אם ה-DUT תומך ב-Ultra Wideband‏ (UWB), צריך למקם מכשיר נוסף שתומך ב-UWB קרוב מספיק, כך שלא יהיו אנטנות ואזורים מתים ברדיו. לבדיקות של דיוק המרחק יש דרישות ספציפיות לגבי מיקום וכיוון. פרטי ההגדרה מפורטים במאמר דרישות UWB. צריך להריץ את בדיקת ה-UWB באופן ידני, ולציין בשורת הפקודה אילו שני מכשירים נמצאים במרחק של מטר אחד זה מזה. פרטים על חלוקה לפלחים, שנדרשת לבדיקה הזו, זמינים במאמר חלוקה לפלחים מקומית.

מצלמות

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

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

אם ה-DUT תומך במצלמות חיצוניות, כמו מצלמות רשת USB, צריך לחבר מצלמה חיצונית כשמריצים את CTS. אחרת, בדיקות CTS נכשלות.

GPS/‏GNSS

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

Wi-Fi ו-IPv6

כדי לבצע בדיקות CTS נדרשת רשת Wi-Fi שתומכת ב-IPv4 וב-IPv6, עם חיבור לאינטרנט עם DNS פעיל ל-IPv4 ול-IPv6, שתומכת ב-IP multicast ויכולה להתייחס ל-DUT כאל לקוח מבודד. לקוח מבודד הוא הגדרה שבה ל-DUT אין גישה להודעות השידור או להודעות ברשתות מרובות ברשת המשנה הזו. המצב הזה מתרחש כשמגדירים נקודת גישה (AP) ל-Wi-Fi או כשמריצים את ה-DUT ברשת משנה מבודדת ללא חיבור של מכשירים אחרים.

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

כדי לעבור את הבדיקה CTS, הדגימה לבדיקה (DUT) צריכה להגדיר את הדגלים UP,‏ BROADCAST ו-MULTICAST בממשק ה-Wi-Fi. צריך להקצות כתובות IPv4 ו-IPv6 לממשק ה-Wi-Fi. בודקים את מאפייני ממשק ה-Wi-Fi באמצעות adb shell ifconfig.

במכשירים שתומכים בפעילות בו-זמנית של STA/STA ב-Wi-Fi, נדרשות כמה רשתות Wi-Fi (לפחות 2). כדי לעבור את הבדיקה, רשתות ה-Wi-Fi צריכות לפעול בתדרים שונים עם מזהי SSID שונים, או באותו מזהה SSID עם מזהי BSSID שונים.

זמן נסיעות משוער (RTT) ב-Wi-Fi

מערכת Android כוללת את Wi-Fi RTT API כדי לאפשר מדידת זמן הנסיעה הלוך ושוב (RTT) ב-Wi-Fi. כך המכשירים יכולים למדוד את המרחק שלהם מנקודות גישה ברמת דיוק של 1-2 מטרים, וכך לשפר באופן משמעותי את דיוק המיקום בתוך מבנים. שני מכשירים מומלצים שתומכים ב-Wi-Fi RTT הם Google Wifi ונקודת הגישה fitlet2 של Compulab (מוגדרת לרוחב פס של 40MHz ב-5GHz).

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

הגדרת מחשב

זהירות: ‏CTS תומך במכונות Linux של 64 ביט. אין תמיכה ב-CTS ב-Windows OS או ב-MacOS.

FFMPEG

מתקינים את חבילת ffmpeg בגרסה 5.1.3 (או גרסה מתקדמת יותר) במכונה המארחת.

דרישות למחשב המארח

הדרישות המינימליות למכונה המארחת של CTS הן 32GB של זיכרון RAM ו-256GB של קיבולת דיסק. הצורך הזה נובע מהעלייה במספר תרחישים הבדיקה של CTS ומהעלייה בהזמנת שטח ב-heap של Java ב-Tradefed.

ADB ו-AAPT2

לפני שמפעילים את ה-CTS, צריך לוודא שמותקנות הגרסאות העדכניות של Android Debug Bridge‏ (adb) ושל Android Asset Packaging Tool‏ (AAPT2), ולהוסיף את המיקום של הכלים האלה לנתיב המערכת של המחשב.

כדי להתקין את ADB ואת AAPT2, מורידים את Android SDK Platform Tools ואת Android SDK Build Tools מהגרסה האחרונה של SDK Manager ב-Android Studio, או באמצעות הכלי sdkmanager בשורת הפקודה.

מוודאים ש-adb ו-aapt2 נמצאים בנתיב המערכת. הפקודה הבאה מבוססת על ההנחה שהורדתם את הארכיונים של החבילות לתיקיית משנה בשם android-sdk בספריית הבית:

export PATH=$PATH:$HOME/android-sdk/platform-tools:$HOME/android-sdk/build-tools/<tools version number>

ערכת כלים לפיתוח Java ל-Ubuntu

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

• ב-Android 11, מתקינים את OpenJDK11.
• ב-Android 9 וב-Android 10, מתקינים את OpenJDK9.
• ב-Android מגרסה 7.0, 7.1, 8.0 ו-8.1, מתקינים את OpenJDK8.

פרטים נוספים זמינים בדרישות ל-JDK.

הגדרה לתמיכה ב-Python

מתקינים את virtualenv לפלטפורמה שלכם לפי הוראות ההתקנה.

כדי לוודא שההתקנה בוצעה בהצלחה, אפשר להפעיל את הפקודה virtualenv -h.

קובצי CTS

מורידים את חבילות ה-CTS מCompatibility Test Suite Downloads שמתאימות לגרסה של Android במכשירים ולכל ממשקי ה-ABI (Application Binary Interface) שבהם המכשירים תומכים, ופותחים אותן.

מורידים את הגרסה האחרונה של קובצי המדיה של CTS ופותחים אותה.

מורידים קבצי CTS שקשורים ל-Mainline (אופציונלי)

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

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

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

   adb shell getprop ro.build.version.sdk
   

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

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

זיהוי מכשירים

פועלים לפי השלבים כדי להגדיר את המערכת לזיהוי המכשיר.

מגבלת זיכרון

כדאי להגדיל את נפח הזיכרון המקסימלי שזמין במהלך הרצה של הבדיקה בסקריפט cts-tradefed. מידע נוסף זמין בCL לדוגמה.

הגדרת מכשיר Android

גרסאות build של משתמשים

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

מאפיין ה-build הראשון ברמת ה-API

דרישות מסוימות של CTS תלויות בגרסה (build) שבה המכשיר נשלח במקור. לדוגמה, יכול להיות שמכשירים שסופקו במקור עם גרסאות build מוקדמות יותר לא ייכללו בדרישות המערכת שחלות על מכשירים שסופקו עם גרסאות build מאוחרות יותר.

כדי שהמידע הזה יהיה זמין ל-CTS, יצרני המכשירים יכלו להגדיר את המאפיין ro.product.first_api_level בזמן ה-build. הערך של המאפיין הזה הוא רמת ה-API הראשונה שבה המכשיר הושק באופן מסחרי.

יצרני המכשירים יכולים לעשות שימוש חוזר בהטמעה הבסיסית המשותפת כדי להשיק מוצר חדש בתור שדרוג של מוצר קיים באותה קבוצת מכשירים. יצרני המכשירים יכולים להגדיר את רמת ה-API של המוצר הקיים ל-ro.product.first_api_level, כדי שדרישות השדרוג יחולו על CTS ועל Treble/VTS.

יצרני המכשירים יכולים להגדיר את PRODUCT_SHIPPING_API_LEVEL בקובץ device.mk כדי להגדיר את המאפיין הזה, כפי שמתואר בדוגמה הבאה:

# PRODUCT_SHIPPING_API_LEVEL sets ro.product.first_api_level to indicate
# the first api level that the device has been commercially launched on.
PRODUCT_SHIPPING_API_LEVEL := 21

רמת ה-API הראשונה ל-Android מגרסה 9 ואילך

במכשירים שהושקו עם Android מגרסה 9 ואילך, מגדירים את המאפיין ro.product.first_api_level לערך תקין מתוך שמות קוד, תגים ומספרי build.

רמת ה-API הראשונה ל-Android מגרסה 8.x ומטה

במכשירים שהושקו עם Android 8.x ואילך, צריך לבטל את ההגדרה (להסיר) של המאפיין ro.product.first_api_level בגרסה הראשונה של המוצר. בכל גרסאות ה-build הבאות, צריך להגדיר את ro.product.first_api_level לערך הנכון ברמת ה-API. כך המערכת תזהה בצורה נכונה מוצר חדש, ותישמר מידע על רמת ה-API הראשונה של המוצר. אם הדגל לא מוגדר, Android מקצה את Build.VERSION.SDK_INT ל-ro.product.first_api_level.

חבילות CTS shim

Android מגרסה 10 ואילך כולל פורמט חבילה שנקרא APEX. כדי להריץ בדיקות CTS לממשקי API לניהול של APEX (כמו עדכון לגרסה חדשה או דיווח על APEXes פעילים), צריך להתקין מראש את החבילה CtsShimApex במחיצה /system.

בדיקת האימות של שכבת הביניים של APEX מאמתת את ההטמעה של CtsShimApex.

הדרישות של ro.apex.updatable

• אם המאפיין ro.apex.updatable מוגדר כ-true, המאפיין CtsShimApex נדרש לכל המכשירים שתומכים בניהול חבילות APEX.

• אם המאפיין ro.apex.updatable חסר או לא מוגדר, לא חובה להתקין מראש את CtsShimApex במכשיר.

בדיקת האימות של שכבת הביניים של APEX מאמתת את ההטמעה של CtsShimApex.

התקנה מראש של CtsShim וטעינת נתונים מראש

החל מ-Android 11, CtsShimApex מכיל שתי אפליקציות מוכנות מראש (שנבנו ממקור build), שלא מכילות קוד מלבד המניפסט. מערכת CTS משתמשת באפליקציות האלה כדי לבדוק את ההרשאות וההיתרים.

אם המכשיר לא תומך בניהול חבילות APEX (כלומר, המאפיין ro.apex.updatable חסר או לא מוגדר), או אם המכשיר פועל בגרסה 10 ואילך, צריך להתקין מראש את שתי האפליקציות המובנות בנפרד במערכת.

אם יש תמיכה ב-APEX, צריך להציב את ההתקנות מראש של הגרסה המתאימה בתור /system/apex/com.android.apex.cts.shim.apex.

אם משתמשים באפליקציות רגילות שנוצרו מראש, צריך להציב את CtsShim ו-CtsShimPriv של הגרסה המתאימה בתור /system/app/CtsShimPrebuilt.apk ו-/system/priv-app/CtsShimPrivPrebuilt.apk, בהתאמה.

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

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

יישומון לדוגמה

ב-Android 9 הושק Open Mobile APIs. במכשירים שמדווחים על יותר מרכיב מאובטח אחד, מערכת CTS מוסיפה תרחישי בדיקה כדי לאמת את ההתנהגות של ממשקי ה-Open Mobile API. תרחישי הבדיקה האלה דורשים התקנה חד-פעמית של אפליקציה לדוגמה ברכיב האבטחה המוטמע (eSE) של ה-DUT או בכרטיס ה-SIM שבו ה-DUT משתמש. אפשר למצוא את אפליקציית ה-eSE לדוגמה ואת אפליקציית ה-SIM לדוגמה ב-AOSP.

למידע מפורט יותר על תרחישי בדיקה של Open Mobile API ותרחישי בדיקה של בקרת גישה, אפשר לעיין במאמר בדיקת CTS לרכיב מאובטח.

דרישות אחסון

כדי לבצע את בדיקות הלחץ של המדיה ב-CTS, סרטוני הווידאו צריכים להיות באחסון חיצוני (/sdcard). רוב הסרטונים מגיעים מ-Big Buck Bunny, שזכויות היוצרים שלו שייכות ל-Blender Foundation במסגרת רישיון Creative Commons Attribution 3.0.

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

רזולוציית ההפעלה המקסימלית של הסרטון קובעת את דרישות האחסון:

• 480x360: ‏ 98MB
• 720x480: ‏ 193MB
• 1280x720: ‏ 606MB
• 1920x1080: ‏ 1,863MB

מסך ואחסון

• כל מכשיר שאין לו מסך מובנה צריך להיות מחובר למסך.

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

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

Developer UICC

כדי להריץ בדיקות של CTS Carrier API, צריך להשתמש במכשיר עם כרטיס SIM עם הרשאות CTS Carrier שתואמות לדרישות שמפורטות בקטע הכנת ה-UICC.

הגדרת מכשיר Android

1. איפוס המכשיר לנתוני היצרן: הגדרות > גיבוי ואיפוס > איפוס לנתוני היצרן.

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

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

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

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

6. מוודאים שלא הוגדרו במכשיר קו ביטול נעילה או סיסמה: הגדרות > אבטחה > נעילת מסך > ללא.

7. מפעילים את ניפוי הבאגים ב-USB במכשיר: הגדרות > אפשרויות למפתחים > ניפוי באגים ב-USB.

8. מגדירים את השעה בפורמט של 12 שעות: הגדרות > תאריך ושעה > שימוש בפורמט של 24 שעות > מושבת.

9. מגדירים את המכשיר למצב 'ער': הגדרות > אפשרויות למפתחים > מצב 'ער' > מופעל.

10. ב-Android 5.x ו-4.4.x בלבד, מגדירים את המכשיר כך שיאפשר מיקומים מדומים: הגדרות > אפשרויות למפתחים > מתן הרשאה למיקומים מדומים > מופעל.

11. ב-Android מגרסה 4.2 ואילך, משביתים את אימות האפליקציות באמצעות USB: הגדרות > אפשרויות למפתחים > אימות אפליקציות באמצעות USB > מושבת.

12. ב-Android מגרסה 13 ואילך, מגדירים את המכשיר כך שיאפשר שימוש במכשיר מודום מדומה: הגדרות > אפשרויות למפתחים > מתן הרשאה למכשיר מודום מדומה > מופעל.

13. פותחים את הדפדפן ומבטלים את כל מסך ההפעלה/ההגדרה.

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

15. לפני שמפעילים את CTS, מגדירים את Roboto2 כגופן ללא Serif באמצעות הגדרה שזמינה למשתמשים (לא מוסתרת).

התקנת קבצים

התקנה והגדרה של אפליקציות עזר במכשיר.

1. מגדירים את המכשיר בהתאם לגרסת CTS:

   • גרסאות CTS 2.1 R2 עד 4.2 R4: מגדירים את המכשיר (או את הסימולטור) כך שיפעיל את בדיקות הנגישות באמצעות: adb install -r android-cts/repository/testcases/CtsDelegatingAccessibilityService.apk

     במכשיר, מפעילים את הענקת הגישה: הגדרות > נגישות > נגישות > הענקת גישה לשירות נגישות.

   • גרסאות CTS 6.x ואילך: במכשירים שמצהירים על android.software.device_admin, מגדירים את המכשיר להרצת הבדיקה של ניהול המכשיר באמצעות: adb install -r android-cts/repository/testcases/CtsDeviceAdmin.apk`

     בקטע הגדרות > אבטחה > בחירת אדמינים של מכשירים, מפעילים את שני האדמינים של המכשיר android.deviceadmin.cts.CtsDeviceAdminReceiver*. מוודאים ש-android.deviceadmin.cts.CtsDeviceAdminDeactivatedReceiver ואדמינים אחרים שמוגדרים מראש במכשיר נותרים מושבתים.

2. מעתיקים את קובצי המדיה של CTS למכשיר באופן הבא:

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

   2. משנים את הרשאות הקובץ: chmod u+x copy_media.sh

   3. מעתיקים את הקבצים הנדרשים:

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

        ./copy_media.sh 720x480

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

        ./copy_media.sh all

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

        ./copy_media.sh 720x480 -s 1234567