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

זהירות: כדי לבצע את בדיקת ה-GPS, הגדרת החיבור לאינטרנט לא יכולה לחסום חיבורים ליציאה supl.google.com 7276. היציאה הזו מאפשרת להוריד נתוני סיוע ל-GPS לצורך בדיקת חישוב המיקום במכשיר המקומי.

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

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

הגדרת מחשב

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

FFMPEG

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

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

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

ADB ו-AAPT2

הערה: ב-CTS 8.0, צריך להשתמש בגרסה 1.0.39 של adb.

לפני שמפעילים את ה-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 מוריד באופן דינמי חלק מקובצי CTS הקשורים לשורה הראשית, ומוסיף לפחות 10 דקות לזמן הריצה, בהתאם למהירות הרשת.

כדי להימנע מזמן הריצה הנוסף של CTS, אפשר להוריד את קובצי ה-CTS הקשורים לקטגוריה לפני הרצת גרסת ה-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.

זהירות: כשמשתמשים ב-CTS כדי לאשר את תאימות קובץ האימג' הסופי של המערכת ל-Android, צריך להריץ אותו במכשירים עם 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 (למשל, עדכון לגרסה חדשה או דיווח על 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), שלא מכילות קוד מלבד המניפסט. מערכת 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 15	android15-arm-release	android15-x86-publish	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
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 הושק 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 מפורטת גרסת הפלטפורמה של רזולוציות המסך הנדרשות.

הערה: יכולות ההפעלה של הסרטונים ב-DUT נבדקות באמצעות ממשקי ה-API של android.media.CamcorderProfile לגרסאות קודמות של Android וממשקי ה-API של android.media.MediaCodecInfo.CodecCapabilities מ-Android 5.0.

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

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

מסך ואחסון

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

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

  אזהרה: CTS עלול לשנות/למחוק נתונים בכרטיס ה-SD שמחובר למכשיר.

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

  אזהרה: יכול להיות ש-CTS ישנה או ימחק נתונים בכרטיסי ה-SIM שמחוברים למכשיר.

Developer UICC

כדי להריץ בדיקות CTS של ממשק API לספק, צריך להשתמש במכשיר עם כרטיס 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.

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

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

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

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

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

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

    הערה: ב-Android מגרסה 13 ואילך, נוספו ל-Telephony כמה בדיקות CTS שמשתמשות במודם מדומה במקום במודם אמיתי. צריך להפעיל את ההגדרה הזו בגרסאות build של משתמשים כדי לעבור את בדיקות CTS, כי הן דורשות מודם מדומה.

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

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

    הערה: כשמחברים למחשב מכשיר עם Android מגרסה 4.2.2 ואילך, המערכת מציגה תיבת דו-שיח שבה מופיעה בקשה לאשר מפתח RSA שמאפשר לנפות באגים באמצעות המחשב הזה. בוחרים באפשרות אישור ניפוי באגים ב-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 למכשיר באופן הבא:

   הערה: ב-CTS 2.3 R12 ואילך, אם המכשיר תומך בקודקים של וידאו, צריך להעתיק את קובצי המדיה של 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