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

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. קובצי Flash יוצרים ארטיפקטים (מהמכשיר) ואת GSI (מ-AOSP) מכשירים מחוברים.
  3. הכלי מפעיל בדיקות VTS באמצעות TradeFed מקומי או TradeFed בענן.
  4. דיווח על תוצאות הבדיקה בלוח הבקרה של VTS

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

ספקי המשאבים

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

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

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

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

גרסת Android Build של שותף

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

הגדרת גישה

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

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

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

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

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

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

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

כדי להימנע מזיוף בקשות במספר אתרים, ה-RPC buildsvc דורש אסימון XSRF שיפורסם עם הפרמטרים האחרים. אמנם האסימון הזה הופך את היא גם מקשה מאוד על הגישה הפרוגרמטית, (הזמין רק ב-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 המובנה Google for Education)
    • fastboot flash (אחד בכל פעם)

הרצת בדיקות

ב-Android 9, הבדיקה האוטומטית של VTS התשתית תומכת רק במסגרת הבדיקה של TradeFed, אבל ניתן להרחיב אותה כדי לתמוך ברתמות אחרות בעתיד.

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

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

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

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

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