תשתית לבדיקות אוטומטיות

‫Android 9 כולל תשתית של חבילת בדיקות לספקים (VTS) לבדיקה אוטומטית של VTS,‏ CTS או בדיקות אחרות במכשירי שותפים שמופעלת בהם תמונת מערכת כללית (GSI) של AOSP. בעבר, הפעלת הבדיקות האלה הייתה פעולה ידנית מאוד. תשתית הבדיקות החדשה של VTS נועדה לתמוך בבדיקות אוטומטיות כמה פעמים ביום בכמה מכשירים.

ארכיטקטורה

תשתית הבדיקות האוטומטיות של VTS מבוססת על הארכיטקטורה הבאה:

כשמופעלת בדיקה, תשתית הבדיקות האוטומטית של VTS מבצעת את המשימות הבאות:

1. מאחזר פריטי בנייה ומשאבי בדיקה ממיקומים שונים:
   • Partner Android Build (PAB). ל-GSI, למסגרת VTS ולחלק מהגרסאות האחרות.
   • מערכת קבצים מקומית, Google Cloud Storage או מערכת בנייה אחרת שספציפית לספק. לשותפים שלא מאחסנים את הגרסאות ב-Google Cloud.
2. הכלי מציג חפצי בנייה (מהמכשיר) ו-GSI (מ-AOSP) במכשירים המחוברים.
3. מריצים בדיקות VTS באמצעות TradeFed מקומי או TradeFed בענן.
4. העברת תוצאות הבדיקה למרכז הבקרה של VTS

התהליך מתואם על ידי בקר המארח (HC) של VTS, מכונה במעבדה שמכוונת את ההתנהגות של כל המכשירים המחוברים שנבדקים. ה-HC אחראי לאחזור הגרסאות העדכניות, להעברתן למכשירים ולהפעלת בדיקות (באופן מקומי או דרך מפקד). הוא גם מתקשר עם מתזמן בענן ומנתב תנועה בין המתזמן לבין מופע TradeFed (או רכיב אחר) שפועל ב-HC. פרטים על בקר המארח מופיעים במאמר בנושא ארכיטקטורת בקר המארח.

ספקי משאבים

בדיקות אוטומטיות דורשות משאבים כמו גרסאות build של המערכת, קובצי בדיקה וארטיפקטים של VTS. אפשר ליצור אותם מהמקור, אבל קל יותר ליצור אותם באופן קבוע מגרסת הפיתוח העדכנית ביותר ואז לפרסם את הארטיפקטים להורדה.

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

• Partner Android Build. הגישה הפרוגרמטית ניתנת על בסיס כל חשבון בנפרד.
• מערכת קבצים מקומית (או דומה). לשותפים שלא משתמשים בגרסת ה-Build של Android לשותפים.

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

Partner Android Build

ב-Android מגרסה 8.1 ומטה, שותפי Android נדרשו להיכנס לאתר Partner Android Build ‏(https://partner.android.com/build), לנווט לחשבון שלהם ולאחזר את תמונות המערכת העדכניות דרך ממשק המשתמש. כדי לעזור לשותפים להימנע מהתהליך האיטי והמייגע הזה, Android 9 כולל תמיכה בהורדה אוטומטית של המשאבים האלה מ-PAB כשמספקים את פרטי הכניסה המתאימים.

קביעת גישה

גישה פרוגרמטית משתמשת ב-OAuth2 ב-Google APIs כדי לגשת ל-RPCs הנדרשים. בגישה הרגילה ליצירת פרטי כניסה ב-OAuth2, השותף צריך להגדיר ב-Google זוג של מזהה לקוח וסוד לקוח. כשמצביעים על הסוד הזה ב-PartnerAndroidBuildClient בפעם הראשונה, נפתח חלון דפדפן שבו המשתמש יכול להתחבר לחשבון Google שלו, וכך נוצרים פרטי הכניסה של OAuth2 שנדרשים כדי להמשיך. פרטי הכניסה (טוקן גישה וטוקן רענון) מאוחסנים באופן מקומי, כלומר השותפים צריכים להיכנס לחשבון רק פעם אחת.

בקשת POST לכתובת URL

לחיצה על קישור למשאב ב-PAB שולחת בקשת POST שכוללת את הנתונים הנדרשים למשאב הזה, כולל:

• מזהה build, יעד build
• שם המשאב
• ענף
• שם הגרסה המועמדת להפצה והאם הגרסה המועמדת היא גרסה פנימית

בקשת ה-POST מתקבלת על ידי שיטת downloadBuildArtifact של buildsvc RPC, שמחזירה כתובת URL שאפשר להשתמש בה כדי לגשת למשאב.

• לגבי משאבי APK של Clockwork Companion, כתובת ה-URL היא כתובת URL קריאה שמתארחת ב-PAB (שמוגן באמצעות אימות ונגיש עם פרטי הכניסה המתאימים של OAuth2).
• למשאבים אחרים, כתובת ה-URL היא ארוכה ולא מוגנת, מתוך ה-API הפנימי של Android Build (שתוקף שלה פג אחרי חמש דקות).

קבלת כתובת ה-URL

כדי למנוע זיוף בקשות באתרים שונים, בקשת ה-RPC‏ buildsvc מחייבת פרסום של טוקן XSRF עם הפרמטרים האחרים. האסימון הזה משפר את האבטחה של התהליך, אבל הוא גם מקשה מאוד על גישה באמצעות תוכנה, כי עכשיו נדרש גם האסימון (שזמין רק ב-JavaScript של דף ה-PAB) כדי לגשת.

כדי למנוע את הבעיה הזו, ב-Android 9 בוצע עיצוב מחדש של סכמת השמות של כתובות ה-URL לכל הקבצים (לא רק קובצי APK), כך שכתובות ה-URL יהיו צפויות לצורך גישה לרשימות של ארטיפקטים ולכתובות URL של ארטיפקטים. עכשיו, PAB משתמש בפורמט נוח של כתובות URL שמאפשר לשותפים להוריד משאבים. סקריפטים של HC יכולים להוריד את קובצי ה-APK האלה בקלות, כי פורמט כתובות ה-URL ידוע, ו-HC יכול לעקוף את בעיות ה-XSRF/cookie כי הוא לא צריך את ה-RPC.buildsvc

מערכת קבצים מקומית

אם נותנים לספק הבנייה ספרייה עם רשימה (או קובץ ZIP) של ארטיפקטים, הוא מגדיר את התמונות הרלוונטיות על סמך מה שיש בספרייה. אפשר להשתמש בכלי gsutil כדי להעתיק קבצים מ-Google Cloud Storage לספרייה מקומית.

גרסאות build של Flash

אחרי שמורידים את קובצי האימג' האחרונים של המכשירים למארח, צריך לצרוב את קובצי האימג' האלה למכשירים. הפעולה הזו מתבצעת באמצעות הפקודות הרגילות adb ו-fastboot ותהליכי משנה של Python, על סמך נתיבי הקבצים הזמניים שספקי הבנייה שומרים.

פעולות נתמכות:

• התקנת GSI בלבד
• הצגת תמונות בודדות מהמערכת הראשית (למשל, fastboot flash boot boot.img)
• הבזק של כל התמונות מהמערכת הראשית. דוגמה:
  • ‫fastboot flashall (באמצעות כלי השירות המובנה flashall )
  • fastboot flash (אחת בכל פעם)

הרצת בדיקות

ב-Android 9, תשתית הבדיקות האוטומטיות של VTS תומכת רק ב-TradeFed test harness, אבל אפשר להרחיב אותה כך שתתמוך ב-harnesses אחרים בעתיד.

אחרי שמכינים את המכשירים, אפשר להפעיל בדיקות באמצעות אחת מהאפשרויות הבאות:

• כשמשתמשים ב-TradeFed באופן מקומי, משתמשים בפקודה test בבקר המארח, שמקבלת את השם של תוכנית בדיקה של VTS (לדוגמה, vts-selftest) ומריצה את הבדיקה.
• כשמשתמשים ב-TradeFed Cluster (אפשרות נוספת היא חיבור ל-MTT), משתמשים בפקודה lease במסוף של בקר המארח, שמחפשת הפעלות של בדיקות שלא הושלמו.

אם משתמשים ב-TradeFedCluster, ‏ TradeFed פועל באופן מקומי כמנהל מרוחק. אם לא, ההפעלה של הבדיקות מתבצעת באמצעות תהליכי משנה של Python.

דיווח על תוצאות

תוצאות הבדיקות מדווחות באופן אוטומטי לכמה פרויקטים בלוח הבקרה של VTS על ידי VtsMultiDeviceTest.