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

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

ארכיטקטורה

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

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

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

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

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

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

ספקי משאבים

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

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

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

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

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

אחזור כתובת ה-URL

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

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

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

כשנותנים ל-build provider ספרייה עם רשימה (או קובץ 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, אבל אפשר להרחיב אותה כך שתתמוך בערכות בדיקה אחרות בעתיד.

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

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

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

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

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