Android 9 כולל תשתית של חבילת בדיקות של ספקים (VTS) לבדיקות אוטומטיות של VTS, CTS או בדיקות אחרות במכשירי שותפים שפועלים בהם קובץ האימג' המערכת הכללי (GSI) של AOSP. בעבר, הפעלת הבדיקות האלה הייתה פעולה ידנית מאוד. תשתית הבדיקות החדשה של VTS תוכננה לתמוך בבדיקות אוטומטיות כמה פעמים ביום במספר מכשירים.
ארכיטקטורה
התשתית לבדיקות האוטומטיות של VTS מבוססת על הארכיטקטורה הבאה:
כשמפעילים בדיקה, תשתית הבדיקות האוטומטיות של VTS מבצעת את המשימות הבאות:
- מאחזרים ארטיפקטים של build ובודקים משאבים ממיקומים שונים:
- Partner Android Build (PAB) ל-GSI, למסגרת VTS ולגרסאות build מסוימות אחרות.
- מערכת קבצים מקומית, Google Cloud Storage או מערכת build אחרת ספציפית לספק. לשותפים שלא שומרים גרסאות build בענן של Google.
- איך מפעילים את ה-build artifacts (מהמכשיר) ואת ה-GSI (מ-AOSP) במכשירים המחוברים.
- הכלי מפעיל בדיקות VTS באמצעות TradeFed מקומי או TradeFed בענן.
- דיווח על תוצאות הבדיקה בלוח הבקרה של VTS
התהליך מתואם על ידי הבקר המארח של VTS (HC), מכונה שנמצאת בשיעור ה-Lab ומנהלת את ההתנהגות של כל המכשירים המחוברים בבדיקה. מרכז העזרה אחראי לאחזר את גרסאות ה-build האחרונות, לאתחל אותן במכשירים ולהפעיל בדיקות (באופן מקומי או דרך המפקד). הוא גם מתקשר עם מתזמנים בענן ומפנה את תעבורת הנתונים בין המתזמן לבין המכונה של TradeFed (או כל רתמה אחרת) שפועלת במרכז העזרה. פרטים על הבקר המארח מופיעים במאמר Host Controller Architecture.
ספקי משאבים
כדי לבצע בדיקות אוטומטיות נדרשים משאבים כמו גרסאות build של מערכות, קובצי בדיקה וארטיפקטים של VTS. אפשר ליצור אותם מהמקור, אבל קל יותר ליצור אותם באופן קבוע מ-tip-of-tree ולאחר מכן לפרסם את הארטיפקטים להורדה.
שותפים יכולים לגשת למשאבי האוטומציה באמצעות המיקומים הבאים:
- Partner Android Build. גישה פרוגרמטית ניתנת על בסיס חשבון.
- מערכת קבצים מקומית (או דומה). לשותפים שלא משתמשים ב-Partner Android Build.
כדי להשתמש בהם בהמשך כדי להריץ את הקושחה במכשירים, המשאבים כוללים ספקי גרסאות build לשתי האפשרויות, שמתרחבים מ-build_provider.py יחיד שמאחסן את הגרסאות הבנויות בספריות זמניות מקומיות.
גרסת 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.