שאלות נפוצות בנושא CTS

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

שאלות כלליות

בקטע הזה מפורטות שאלות נפוצות בנושא CTS באופן כללי.

אילו דברים נבדקים ב-CTS?

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

איך מקבלים רישיון ל-CTS?

ל-CTS יש רישיון לפי אותו רישיון תוכנה של Apache 2.0 שבו נעשה שימוש ברוב רכיבי Android.

האם הקודקים מאומתים על ידי CTS?

כן. כל הקודקים הנדרשים מאומתים על ידי CTS.

שאלות ספציפיות למבחן

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

מה ההבדל בין חלוקה לקטעים ב-CTS לבין חלוקה לקטעים ב-TF?

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

חלוקת TF מקצה באופן דינמי מקרי בדיקה למכשירי DUT זמינים באופן הבא:

מה צפוי ממכשיר שתומך במספר ממשקי ABI?

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

  • ל-CTS ול-CTS Verifier יש גרסאות ARM ו-x86 לכל ארכיטקטורה. כל אחד מהם יכול לתמוך במצב 32 או 64 ביט.
  • בבדיקות CTS, אם מכשיר תומך גם ב-ARM וגם ב-x86, הוא צריך להריץ את שתי בדיקות ה-CTS של ARM ושל x86 ולהצליח בהן.

ראו CDD 3.3.1. ממשקי Application Binary Interface לדרישות CDD ב-ABI.

האם מספיק להריץ בדיקה רק ב-ABI הראשי (לדוגמה, 64 ביט) כדי לקצר את זמן ביצוע הבדיקה?

לא. אפליקציית Android פועלת בסביבות זמן ריצה משלה של 32 ביט או 64 ביט. קוד המכונה, נתיב הקוד והמצב בפועל שונים בין 32 ל-64. אם מדלגים על מצב אחד, מכסים רק 50% מ-ABI של המכשיר.

למה יש כל כך הרבה תרחישי בדיקה שמדווחים כ'לא בוצעו'?

צריך לבדוק את המספר Module Done במקום את המספר Not Executed.

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

אם מודול הושלם, יופיע בדוח הערך Module Not Done בקריאה האחרונה (done="false") במהלך:

  • הרצת הבדיקה של המודול הופסקה בגלל בעיה בחיבור של המכשיר.
  • לא בוצעו כל הרצות הבדיקה הצפויות של המודול.

  • ניסיון חוזר (באמצעות האפשרות -r/--retry) עם אפשרויות סינון נוספות, כמו:

    • --include-filter
    • --exclude-filter
    • -t/--test (האפשרות הזו עדיין לא נתמכת בניסיון חוזר)
    • --retry-type failed
    • ‎--subplan

כדי לקבל את הסטטוס Module Done (done="true") עבור המודולים האלה, צריך לנסות שוב את הפעולות הבאות עבור ההפעלה האחרונה:

run retry --retry <session_id> for Android 9 and later versions
run cts --retry <session_id> for Android 8.1 and previous versions

מודול שבוצע ללא אף אחת מהבעיות שצוינו למעלה (גם אם לא נותרו בדיקות) מסומן בדיווח החדש בתור Module Done.

חריגים

  • ב-CtsNNAPITestCases יש בעיה ידועה עקב מגבלת args ב-Linux/OS. אפשר להריץ מחדש את המודול בנפרד דרך run cts -m CtsNNAPITestCases ישירות.

איך אפשר למנוע כשל בהכנת הבדיקה מאחורי חומת האש הארגונית?

כל חבילות הבדיקה האוטומטיות מנסו להוריד את קובצי המדיה של CTS או את קובצי הלוגיקה העסקית במהלך זמן הריצה. בסביבות ארגוניות רבות, שרתי חומת אש ושרתי proxy הם סטנדרטיים, ולכן ההכנה לבדיקה נכשלת. מריצים את השורה הבאה או מוסיפים אותה לקובץ profile .‎ (ב-Ubuntu).

export JAVA_TOOL_OPTIONS='-Djava.net.useSystemProxies=true'

האם צריך כרטיס SIM ל-CTS לרכיב מאובטח?

הצורך בכרטיס SIM לבדיקה תלוי בכך אם התכונה נתמכת במכשיר הבדיקה.

  • אם המכשיר לא צריך לתמוך באפליקציות ל-Android שמקבלות גישה לאלמנטים מאובטחים – ב-UICC (למשל, כרטיס SIM) שמופץ על ידי מפעילי הרשתות הסלולריות (ספקים) או מוטמע במכשיר – אפשר להגדיר את המניפסט של HIDL כך שלא יכלול את אלמנט ה-HAL‏ android.hardware.secure_element. במקרה כזה, ה-API‏ android.se.omapi.SEService.getReaders()‎ מדווח על רשימה ריקה, ובדיקה CTS עוברת באופן אוטומטי ומדווחת על אישור ב-CTS.
  • אם המכשיר צריך לתמוך באפליקציות ל-Android שמקבלות גישה לרכיבים מאובטחים – ב-UICC (למשל, כרטיס SIM) שמופץ על ידי מפעילי הרשתות הסלולריות (ספקים) או מוטמע במכשיר – צריך להטמיע את הרכיב המאובטח בצורה נכונה ולבדוק אותו באופן פנימי. במאמר בדיקת CTS לרכיב מאובטח מוסבר איך להתכונן להרצת בדיקות CTS כדי לוודא שחבילת ה-API android.se.omapi שנוספה ב-Android 9 תקינה. מומלץ גם לבצע בדיקות נוספות בעצמכם, כי הכיסוי של בדיקות CTS הוא מינימלי.

איפה אפשר לקבל את כרטיסי ה-SIM ל-CTS לרכיב מאובטח?

אתם יכולים לפנות לספק ה-SIM המועדף עליכם.

למה כרטיס SIM של Orange מופיע במסך הנעילה במהלך ביצוע CTS עם חלוקת אסימונים?

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