שאלות נפוצות בנושא 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 Sharding ו-TF Sharding הם תוכניות בדיקה שונות לחלוטין שמבוססות על בסיס קוד שונה של תשתית בדיקה. פקודת ההפעלה זהה בכל הגרסאות, אבל התוצאה של הפיצול מתנהגת בצורה שונה. ב-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 (האפשרות עדיין לא נתמכת בניסיון חוזר)
    • האפשרות --retry-type נכשלה
    • ‫‎--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 שמוודאות שהחבילה android.se.omapi של ה-API שנוספה ב-Android 9 פועלת. מומלץ גם לבצע בדיקות נוספות באופן עצמאי, כי כיסוי הבדיקה של CTS הוא מינימלי.

איפה אפשר להשיג את כרטיסי ה-SIM ל-CTS עבור Secure Element?

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

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

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

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

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