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

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

שאלות כלליות

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

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

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

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

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

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

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

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

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

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

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

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

מה מצופה ממכשיר שתומך בכמה ממשקי 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 של המכשיר.

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

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

בגרסאות הקודמות, מודולים של 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 שמוודאות שחבילת ה-API‏ android.se.omapi שנוספה ב-Android 9 פועלת. מומלץ גם לבצע בדיקות נוספות באופן עצמאי, כי כיסוי הבדיקה של CTS הוא מינימלי.

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

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

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

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