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

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

שאלות כלליות

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

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

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

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

ה-CTS מורשה במסגרת אותו Apache Software License 2.0 שבו מורשה רוב מערכת Android.

האם רכיבי codec מאומתים על ידי CTS?

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

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

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

מה ההבדל בין CTS Sharding לבין TF Sharding?

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

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

מה נדרש ממכשיר שתומך בכמה ממשקי ABI?

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

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

ראו CDD 3.3.1. Application Binary Interfaces לדרישות CDD בנושא ABI.

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

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

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

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

בגרסאות הקודמות, מודולים של CTS דווחו כModule Done (המודול הושלם) באופן מוקדם מדי, לפני שהם הושלמו. לכן, מספר המודולים שהושלמו דווח בלי שכל תרחישי הבדיקה הושלמו, גם אם היו בעיות במכשירים מסוימים. הכלי החדש לבדיקת תאימות הוא שמרני יותר, ומדווח על מספר גבוה יותר של בדיקות Not Executed כשמתרחשת בעיה.

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

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

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

    • ‫‎--include-filter
    • ‫--exclude-filter
    • ‫‎-t/--test (האפשרות עדיין לא נתמכת בניסיון חוזר)
    • הניסיון החוזר נכשל
    • ‫‎--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

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

חריגים

  • יש בעיה ידועה ב-CtsNNAPITestCases בגלל מגבלה של 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 עבור Secure Element?

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

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

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

הבדיקה מופעלת כשהדגלים של התכונות מושבתים במכשיר

לכל הדגלים בגרסאות ה-release, הערות ה-@RequiresFlagsEnabled או @RequiresFlagsDisabled משתמשות בערכי הדגלים מתוך קובץ ההגדרות של גרסת ה-release הבינארית של CTS, ולא מתוך קובץ ההגדרות של גרסת ה-release של המכשיר. השבתת הדגלים במכשיר לא משביתה את הבדיקה, כי קבוצת הבדיקות של CTS שמופעלות עבור גרסה מסוימת קבועה בהגדרת הפלטפורמה של AOSP שפורסמה.