הגדרת 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 חשיפה להודעות בשידור/ברשתות מרובות ברשת המשנה הזו. הזה מתבצעת באמצעות תצורת נקודת גישה (AP) ל-Wi-Fi או על ידי הרצת 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 של RTT ב-Wi-Fi לזמן נסיעה הלוך ושוב באמצעות Wi-Fi (RTT) ליכולות של בינה מלאכותית גנרטיבית. כך המכשירים יכולים למדוד את המרחק שלהם לנקודות גישה באמצעות דיוק של 1 עד 2 מטר, שיפור משמעותי של הדיוק של המיקום הפנימי. שני מכשירים מומלצים שתומכים ב-RTT ב-Wi-Fi הם Google Wifi וגם נקודת הגישה fitlet2 של Comppulab (מוגדר לרוחב פס של 40MHz ב-5 GHz).

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

הגדרת מחשב

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

FFMPEG

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

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

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

ADB ו-AAPT2

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

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

כדי שהמידע הזה יהיה זמין ל-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 לערך חוקי מ- שמות קוד, תגים ומספרי Build.

רמת 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 לניהול APEX ממשקי API (למשל עדכון לגרסה חדשה או דיווח על 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-publish גרסת Android14-x86 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- הוצגו גרסת Android12-x86 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-גרסה 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.

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

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

בדיקות העומס על המדיה של 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* שני ב-Google Workspace for Education. צריך לוודא 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