קובץ אימג' מערכת גנרי (GSI) הוא קובץ אימג' מערכת עם הגדרות מותאמות למכשירי Android. היא נחשבת להטמעה של Android טהור עם קוד ללא שינוי של Android Open Source Project (AOSP), שכל מכשיר Android עם Android מגרסה 9 ואילך יכול להריץ.
GSIs משמשים להרצת בדיקות VTS ובדיקות CTS-on-GSI. תמונת המערכת של מכשיר Android מוחלפת ב-GSI ולאחר מכן נבדקת עם חבילת הבדיקה של הספק (VTS) ועם חבילת בדיקת התאימות (CTS) כדי להבטיח שהמכשיר מטמיע באופן תקין את ממשקי הספק עם הגרסה האחרונה של Android.
כדי להתחיל להשתמש ב-GSI, כדאי לעיין בקטעים הבאים כדי לקבל פרטים על הגדרות GSI (ועל השינויים המותרים) ועל הסוגים. כשתהיו מוכנים להשתמש ב-GSI, תוכלו להוריד ולבנות את ה-GSI למכשיר היעד, ואז לפלאש את ה-GSI למכשיר Android.
תצורה ושונות של GSI
הגדרת Android GSI הנוכחית היא:
- טרבל. GSI כולל תמיכה מלאה בשינויים הארכיטקטוניים מבוססי-AIDL/HIDL (שנקראים גם Treble), כולל תמיכה בממשקי AIDL ובממשקי HIDL. אפשר להשתמש ב-GSI בכל מכשיר Android שמשתמש בממשקי ספקים של AIDL/HIDL. (פרטים נוספים זמינים במאמר משאבי ארכיטקטורה).
- מערכת קבצים ב-GSI נעשה שימוש במערכת הקבצים ext4.
הגרסה הנוכחית של Android GSI כוללת את ההבדלים העיקריים הבאים:
- ארכיטקטורת המעבד (CPU). תמיכה בהוראות שונות של מעבדים (ARM, x86 וכו') ובמספר הביטים של המעבד (32 ביט או 64 ביט).
יעדי GSI לבדיקות תאימות ל-Treble
גרסת ה-GSI שמשמש לבדיקת התאימות נקבעת לפי גרסת Android שבה המכשיר מופעל.
סוג מכשיר | יעד build |
---|---|
מכשירים שמושקים עם Android 15 | gsi_$arch-user (חתימה) |
מכשירי Android 14 (במועד ההשקה) | gsi_$arch-user (חתימה) |
מכשירי Android 13 (במועד ההשקה) | gsi_$arch-user (נחתם) |
מכשירים שמושקים עם Android 12L | gsi_$arch-user (חתימה) |
מכשירים שמושקים עם Android 12 | gsi_$arch-user (נחתם) |
מכשירי Android 11 (במועד ההשקה) | gsi_$arch-user (חתימה) |
כל ה-GSI נוצרים מקוד המקור של Android 12, לכל ארכיטקטורת מעבד יש קובץ GSI בינארי תואם (ראו את רשימת יעדי ה-build בקטע יצירת GSI).
שינויים ב-Android 12 GSI
מכשירים שמושקים עם Android 12 או עודכנו ל-Android 12 חייבים להשתמש ב-Android 12 GSI לצורך בדיקות תאימות. השינויים העיקריים לעומת GSIs קודמים:
- שם היעד. שם היעד של GSI לבדיקות
התאימות השתנה ל-
gsi_$arch
. ה-GSI עם שם היעדaosp_$arch
נשמר למפתחי אפליקציות ל-Android. גם תוכנית הבדיקהCTS-on-GSI
מצטמצמת לצורך בדיקת ממשק הספק. - הדור הקודם של GSI יוצא משימוש. GSI 12 מסיר את הפתרונות לעקוף את מכשירי Android בגרסה 8.0 או 8.1 שלא עברו אופטימיזציה מלאה.
- Userdebug SEPolicy.
gsi_$arch
ב-GSI מכילuserdebug_plat_sepolicy.cil
. כשמבצעים שדרוג של ה-vendor_boot-debug.img
אוboot-debug.img
הספציפיים ל-OEM,/system/bin/init
יטען אתuserdebug_plat_sepolicy.cil
מ-GSIsystem.img
. לפרטים נוספים, אפשר לקרוא את המאמר בדיקת VTS with Debug Ramdisk.
שינויים ב-GSI ב-Android 11
במכשירים שהושקעו עם Android 11 או עודכנו ל-Android 11, צריך להשתמש ב-GSIs של Android 11 לצורך בדיקת תאימות. השינויים העיקריים לעומת GSIs קודמים:
- תוכן של system_ext. ב-Android 11 מוגדר מחיצה חדשה
system_ext
. GSI מעביר את תוכן התוספים למערכת לתיקייהsystem/system_ext
. - APEXes GSI מכיל גם קצוות APEX שטוחים וגם דחוסים.
המערכת קובעת באיזה מהם להשתמש לפי מאפיין המערכת
ro.apex.updatable
במחיצה של הספק בזמן הריצה. פרטים נוספים זמינים במאמר הגדרת המערכת לתמיכה בעדכוני APEX.
שינויים ב-GSI ב-Android 10
מכשירים שמושקים עם Android 10 או עודכנו ל-Android 10 חייבים להשתמש ב-Android 10 GSI לצורך בדיקות תאימות. השינויים העיקריים לעומת GSIs קודמים:
- גרסת build של משתמש ב-GSI יש גרסת build של משתמש מ-Android 10. ב-Android 10, אפשר להשתמש ב-GSI של build המשתמש לבדיקות תאימות של CTS-on-GSI/VTS. לפרטים נוספים, אפשר לעיין במאמר בדיקת VTS באמצעות Debug Ramdisk.
- פורמט ללא ניתוח. GSI עם מטרות
aosp_$arch
נוצרים בפורמט ללא ניתוח. אם צריך, אפשר להשתמש ב-img2simg
כדי להמיר GSI לא מפולח לפורמט דליל. - System-as-root היעד הקודם ל-build של GSI בשם
aosp_$arch_a
הוצא משימוש. במכשירים ששודרגו מ-Android 8 או 8.1 ל-Android 10 עם ramdisk ולא עם system-as-root, צריך להשתמש ב-GSI הקודםaosp_$arch_ab
.init
המשודרג ב-ramdisk תומך ב-OEM system.img עם פריסה של מערכת כ-root. - אימות האתחול באמצעות GSI צריך רק לבטל את נעילת המכשיר. אין צורך להשבית את אימות האתחול.
שינויים ב-Android 9 GSI
במכשירים שהושקעו עם Android 9 או עודכנו ל-Android 9, צריך להשתמש ב-GSIs של Android 9 לצורך בדיקת תאימות. השינויים העיקריים לעומת GSIs קודמים:
- ממזגת בין GSI לאמולטור. קובצי ה-GSI נוצרים מתמונות המערכת של מוצרי אמולטור, למשל
aosp_arm64
ו-aosp_x86
. - System-as-root בגרסאות קודמות של Android, מכשירים שלא תומכים בעדכוני A/B יכלו לטעון את קובץ האימג' של המערכת בתיקייה
/system
. ב-Android 9, שורש קובץ האימג' של המערכת מותקן כשורש של המכשיר. - ממשק של מחבר ב-64 ביט ב-Android מגרסה 8.x, GSI ב-32 ביט השתמש בממשק binder של 32 ביט. Android 9 לא תומך בממשק binder של 32 ביט, ולכן גם GSI ב-32 ביט וגם GSI של 64 ביט משתמשים בממשק של binder בגרסת 64 ביט.
- אכיפה של VNDK. ב-Android גרסה 8.1, VNDK היה אופציונלי.
החל מגרסה 9 של Android, VNDK הוא חובה, ולכן צריך להגדיר את
BOARD_VNDK_VERSION
. - מאפיין מערכת תואם. ב-Android 9 אפשר לבצע בדיקת גישה למאפיין מערכת תואם (
PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true
).
שינויים ב-Keymaster ב-Android 9
בגרסאות קודמות של Android, מכשירי Keymaster 3 וגרסאות ישנות יותר נדרשו לאמת שפרטי הגרסה (ro.build.version.release
ו-ro.build.version.security_patch
) שדווחו על ידי המערכת שפועלת תואמים לפרטי הגרסה שדווחו על ידי תוכנת האתחול. בדרך כלל המידע הזה הגיע מכותרת קובץ האימג' של האתחול.
ב-Android מגרסה 9 ואילך, הדרישה הזו השתנתה כדי לאפשר לספקים להפעיל GSI. באופן ספציפי, לא כדאי ל-Keymaster לבצע אימות כי ייתכן שפרטי הגרסה שדווחו על ידי ה-GSI לא יהיו זהים לפרטי הגרסה שדווחו על ידי מנהל האתחול של הספק. במכשירים שמטמיעים את Keymaster 3 ואילך, הספקים צריכים לשנות את הטמעת Keymaster כדי לדלג על האימות (או לשדרג ל-Keymaster 4). פרטים על Keymaster מופיעים במאמר Keystore שמבוסס על חומרה.
הורדת GSIs
אפשר להוריד GSIs מוכנים מראש מהאתר של AOSP ל-continuous integration (CI) בכתובת ci.android.com. אם סוג ה-GSI של פלטפורמת החומרה שלכם לא זמין להורדה, תוכלו לעיין בקטע הבא כדי לקבל פרטים על פיתוח GSIs ליעדים ספציפיים.
פיתוח של GSIs
החל מ-Android 9, לכל גרסת Android יש הסתעפות GSI בשם DESSERT-gsi
ב-AOSP (לדוגמה, android12-gsi
היא ההסתעפות GSI ב-Android 12). ההסתעפויות של GSI כוללות את התוכן של Android עם כל תיקוני האבטחה ותיקוני ה-GSI שהוחלו.
כדי ליצור GSI, צריך להגדיר את עץ המקור של Android על ידי הורדה מהסתעפות של GSI ובחירת יעד build של GSI. אפשר להיעזר בטבלאות היעד של ה-build שבהמשך כדי לקבוע את גרסת ה-GSI המתאימה למכשיר. בסיום ה-build, ה-GSI הוא קובץ האימג' של המערכת (כלומר system.img
) והוא מופיע בתיקיית הפלט out/target/product/generic_arm64
.
לדוגמה, כדי ליצור את היעד של build ב-GSI gsi_arm64-userdebug
בהסתעפות GSI android12-gsi
, מריצים את הפקודות הבאות.
$ repo init -u https://android.googlesource.com/platform/manifest -b android12-gsi $ repo sync -cq $ source build/envsetup.sh $ lunch gsi_arm64-userdebug $ make -j4
יעדי build של Android GSI
יעדי ה-build הבאים של GSI מיועדים למכשירים שמותקנת ב-Android מגרסה 9 ואילך.
שם GSI | ארכיטקטורת המעבד (CPU) | גודל הבייט של ממשק ה-Binder | System-as-root | יצירת יעד |
---|---|---|---|---|
gsi_arm |
דריכה | 32 | Y | gsi_arm-user gsi_arm-userdebug |
gsi_arm64 |
ARM64 | 64 | Y | gsi_arm64-user gsi_arm64-userdebug |
gsi_x86 |
x86 | 32 | Y | gsi_x86-user gsi_x86-userdebug |
gsi_x86_64 |
x86-64 | 64 | Y | gsi_x86_64-user gsi_x86_64-userdebug |
דרישות להבהוב GSI
למכשירי Android יכולים להיות עיצובים שונים, ולכן אין פקודה גנרית או קבוצת הוראות גנריות להצגת GSI לכל המכשירים. יש לפנות ליצרן מכשיר Android כדי לקבל הוראות מפורטות להצגת הפלאש. השלבים הבאים יכולים לשמש כמדריך כללי:
- מוודאים שהתנאים הבאים מתקיימים במכשיר:
- טרבליזציה
- שיטה לביטול הנעילה של מכשירים (כדי שאפשר יהיה להריץ בהם את
fastboot
) - במצב פתוח כדי שאפשר יהיה להריץ בו את
fastboot
(כדי לוודא שיש לכם את הגרסה האחרונה שלfastboot
, צריך ליצור אותה מעץ המקור של Android).
- מחיקה של מחיצת המערכת הנוכחית ואז הבהוב של ה-GSI למחיצת המערכת.
- מחיקה של נתוני המשתמש וניקוי הנתונים במחיצות נחוצות אחרות (לדוגמה, נתוני משתמשים ומחיצות מערכת).
- מפעילים מחדש את המכשיר.
לדוגמה, כדי להריץ גרסת GSI בכל מכשיר Pixel:
- מפעילים את המכשיר במצב
fastboot
ומבטלים את הנעילה של תוכנת האתחול. - במכשירים שתומכים ב-
fastbootd
צריך גם להפעיל אתfastbootd
באופן הבא:$ fastboot reboot fastboot
- מוחקים את ה-GSI ומעבירים אותו למחיצה של המערכת באמצעות הפלאש:
$ fastboot erase system $ fastboot flash system system.img
- מוחקים את נתוני המשתמש ומנקים את הנתונים מהמחיצות הנחוצות האחרות (למשל, נתוני משתמשים ומחיצות מערכת):
$ fastboot -w
- מפעילים מחדש את תוכנת האתחול:
$ fastboot reboot-bootloader
- משביתים את אימות האתחול המאומת בזמן שה-vbmeta שסופקה:
$ fastboot --disable-verification flash vbmeta vbmeta.img
- Reboot:
$ fastboot reboot
Resizing 'system_a' FAILED (remote: 'Not enough space to resize partition') fastboot: error: Command failed
$ fastboot delete-logical-partition product_a
_a
צריך להתאים למזהה המיקום של מחיצת המערכת, כמו system_a
בדוגמה הזו.
תרומה ל-GSIs
אנחנו ב-Android מקבלים בברכה את התרומות שלכם לפיתוח GSI. אפשר להיות מעורבים ולעזור בשיפור ה-GSI בדרכים הבאות:
- יצירת תיקון ל-GSI
DESSERT-gsi
הוא לא הסתעפות פיתוח, והוא מקבל רק בחירת קוד מתוך קוד מקור מתוך ההסתעפות הראשית של AOSP. לכן, כדי לשלוח תיקון GSI, צריך:- שולחים את התיקון להסתעפות
main
של AOSP. - בוחרים את התיקון הרצוי ומעבירים אותו אל
DESSERT-gsi
. - שולחים דוח באג כדי לבדוק את ה-cherrypick.
- שולחים את התיקון להסתעפות
- דיווח על באגים ב-GSI או שליחת הצעות אחרות. קוראים את ההוראות בקטע דיווח על באגים, ואז מעיינים בבאגים ב-GSI או מדווחים עליהם.
טיפים
שינוי המצב של סרגל הניווט באמצעות adb
כשמפעילים את המכשיר באמצעות GSI, מצב סרגל הניווט מוגדר על ידי שינוי מברירת המחדל של הספק. כדי לשנות את המצב של סרגל הניווט אפשר להריץ את פקודת adb הבאה בזמן הריצה.
adb exec-out cmd overlay enable-exclusive com.android.internal.systemui.navbar.mode
כאשר mode יכול להיות threebutton
, twobutton
, gestural
וכן הלאה.