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

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

ארכיטקטורה

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

ארכיטקטורה של בדיקות אוטומטיות

איור 1. ארכיטקטורה של תשתית בדיקות אוטומטיות של VTS

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

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

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

ספקי משאבים

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

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

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

כדי להשתמש בהם בהמשך להפעלת המכשירים, המשאבים כוללים ספקי בנייה לשתי האפשרויות, החל מ-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 מתקבלת על ידי method ‏downloadBuildArtifact של buildsvc RPC, שמחזירה כתובת URL שאפשר להשתמש בה כדי לגשת למשאב.

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

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

כדי למנוע זיוף בקשות באתרים שונים, ב-buildsvc RPC צריך להשתמש בטוקן XSRF בבקשת POST עם הפרמטרים האחרים. הטוקן הזה משפר את האבטחה של התהליך, אבל גם מקשה מאוד על גישה באמצעות תוכנה, כי עכשיו נדרש גם הטוקן (שזמין רק ב-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, על סמך נתיבי הקבצים הזמניים שמאוחסנים על ידי ספקי ה-build.

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

  • התקנת 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.