שאלות נפוצות בנושא 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 מקצה באופן סטטי מקרי בדיקה למכשירים בבדיקה (DUTs) באופן הבא:

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

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

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

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

ראו CDD 3.3.1. ממשקי Application Binary לדרישות 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 עם חלוקת אסימונים.