הגדרת 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.

למכשירים שתומכים ב-Wi-Fi STA/STA בו-זמני, צריך להשתמש בכמה רשתות 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).

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

הגדרת מחשב

זהירות: ‏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 Development Kit ל-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 מההורדות של חבילת בדיקת התאימות (בהתאמה לגרסת Android במכשיר שלכם) ולכל הממשקים הבינאריים של האפליקציות (ABI) שנתמכים במכשירים שלכם.

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

הורדת קובצי CTS הקשורים לחלק הראשי (אופציונלי)

כשמריצים גרסה של 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 לערך תקין מ-Codenames, Tags, and Build Numbers.

רמת 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 ריק. משתמשים בכרטיס SD שתומך באוטובוס במהירות גבוהה במיוחד (UHS) עם קיבולת SDHC או SDXC, או כרטיס עם סיווג מהירות 10 ומעלה לפחות כדי לוודא שהוא יכול לעבור את ה-CTS.

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

UICC למפתחים

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

הגדרת מכשיר Android

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

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

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

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