הגדרת 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 ויכולה להתייחס ל-DUT כלקוח מבודד. לקוח מבודד הוא הגדרה שבה ל-DUT אין הרשאות גישה להודעות שמשודרות או לרשת מרובת רשתות באותה רשת משנה. הפעולה הזו מתבצעת באמצעות הגדרה של נקודת גישה ל-Wi-Fi (AP) או על ידי הרצת ה-DUT ברשת משנה מבודדת, מבלי שמכשירים אחרים מחוברים אליה.

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

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

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

RTT ב-Wi-Fi

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

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

הגדרת מחשב

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

FFMPEG

להתקין את חבילת ה-ffmpeg גרסה 5.1.3 (ואילך) במחשב המארח.

שדרוג מכונה למארח

מומלץ מאוד לשדרג את זיכרון ה-RAM של המחשב המארח של CTS ל-128GB ואת HDD ל-256GB. הוא נדרש כדי להתמודד עם המספר המוגדל של מקרי הבדיקה של CTS ושל עלייה במספר שמירת השטחים בשביל ערימה (heap) ב-Java במסחר אלקטרוני.

ADB ו-AAPT2

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

כדי להתקין את ADB ו-AAPT2, צריך להוריד את הגרסה העדכנית ביותר של Android SDK Platform Tools ואת כלי הפיתוח ל-Android SDK ממנהל ה-SDK של 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 מההורדות של חבילת בדיקת התאימות (בהתאמה לגרסת Android במכשיר שלכם) ולכל הממשקים הבינאריים של האפליקציות (ABI) שנתמכים במכשירים שלכם.

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

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

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

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

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

    adb shell getprop ro.build.version.sdk
    
  2. פועלים לפי ההוראות בסקריפט download_mcts.sh כדי להוריד את קובצי ה-CTS של Mainline.

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

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

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

מגבלת זיכרון

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

הגדרת מכשיר Android

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

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

נכס build ראשון ברמת ה-API

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

כדי שהמידע הזה יהיה זמין ל-CTS, יכול להיות שיצרני המכשירים הגדירו את נכס זמן ה-build ro.product.first_api_level. הערך של המאפיין הזה הוא רמת ה-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 הראשונה של המוצר. בכל גרסאות ה-build הבאות, מגדירים את ro.product.first_api_level לערך הנכון ברמת ה-API. כך הנכס יכול לזהות מוצר חדש בצורה נכונה, ושומר מידע על רמת ה-API הראשונה של המוצר. אם הדגל לא מוגדר, Android מקצה את Build.VERSION.SDK_INT ל-ro.product.first_api_level.

חבילות ספריית CTS

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

בדיקת האימות של ספריית APEX מאמתת את ההטמעה של CtsShimApex.

דרישות לגבי ro.apex.updatable

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

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

בדיקת האימות של ספריית APEX מאמתת את ההטמעה של CtsShimApex.

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

החל מ-Android 11, CtsShimApex מכיל שתי אפליקציות מוכנות מראש (שנוצרו מ-build source) ואין בהן קוד מלבד המניפסט. 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 בהתאמה.

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

גרסת המכשיר התקנה מראש של
(אם יש תמיכה ב-APEX)
טעינה מראש
דריכה x86 דריכה x86
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-publish 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

10 Android 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

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

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

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

למידע מפורט יותר על מקרי הבדיקה של Open Mobile API ועל מקרי הבדיקה של בקרת גישה, ראו CTS Test for Secure Element.

דרישות לגבי נפח האחסון

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

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

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

  • 480x360: 98MB
  • 720x480: 193MB
  • 1280x720: 606 MB
  • 1,920x1,080: 1,863MB

מסך ואחסון

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

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

UICC למפתחים

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

תצורת מכשיר Android

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  15. לפני הרצת CTS, צריך להגדיר את Roboto2 כגופן Sans 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