یک تصویر سیستم عمومی (GSI) یک تصویر سیستم با پیکربندی های تنظیم شده برای دستگاه های Android است. این یک پیاده سازی اندروید خالص با کد پروژه منبع باز اندروید (AOSP) اصلاح نشده در نظر گرفته می شود که هر دستگاه اندرویدی دارای اندروید 9 یا بالاتر می تواند با موفقیت اجرا کند.
GSI ها برای اجرای تست های VTS و CTS-on-GSI استفاده می شوند. تصویر سیستم یک دستگاه Android با یک GSI جایگزین میشود و سپس با مجموعه تست فروشنده (VTS) و مجموعه تست سازگاری (CTS) آزمایش میشود تا اطمینان حاصل شود که دستگاه رابطهای فروشنده را به درستی با آخرین نسخه Android پیادهسازی میکند.
برای شروع کار با GSI، بخشهای زیر را برای جزئیات بیشتر در مورد پیکربندیهای GSI (و واریانسهای مجاز) و انواع مرور کنید. وقتی برای استفاده از GSI آماده شدید، GSI را برای هدف دستگاه خود دانلود و بسازید ، سپس GSI را به دستگاه اندرویدی فلش کنید .
پیکربندی و واریانس GSI
Android GSI فعلی دارای پیکربندی زیر است:
- سه گانه. GSI شامل پشتیبانی کامل از تغییرات معماری مبتنی بر AIDL/HIDL (همچنین به عنوان Treble شناخته می شود)، از جمله پشتیبانی از رابط های AIDL و رابط های HIDL . می توانید از GSI در هر دستگاه اندرویدی که از رابط های فروشنده AIDL/HIDL استفاده می کند استفاده کنید. (برای جزئیات بیشتر، به منابع معماری مراجعه کنید.)
- سیستم فایل. GSI از سیستم فایل ext4 استفاده می کند.
Android GSI فعلی شامل تغییرات عمده زیر است:
- معماری CPU پشتیبانی از دستورالعمل های مختلف CPU (ARM، x86، و غیره) و بیت CPU (32 بیت یا 64 بیت).
اهداف GSI برای آزمایشهای انطباق سهگانه
GSI مورد استفاده برای تست انطباق با نسخه اندرویدی که دستگاه با آن راه اندازی می شود تعیین می شود.
نوع دستگاه | هدف را بسازید |
---|---|
دستگاه هایی که با اندروید 15 راه اندازی می شوند | gsi_$arch-user (امضا شده) |
دستگاه هایی که با اندروید 14 راه اندازی می شوند | gsi_$arch-user (امضا شده) |
دستگاه هایی که با اندروید 13 راه اندازی می شوند | gsi_$arch-user (امضا شده) |
دستگاه هایی که با اندروید 12L راه اندازی می شوند | gsi_$arch-user (امضا شده) |
دستگاه هایی که با اندروید 12 راه اندازی می شوند | gsi_$arch-user (امضا شده) |
دستگاه هایی که با اندروید 11 راه اندازی می شوند | gsi_$arch-user (امضا شده) |
همه GSI ها از پایه کد Android 12 ساخته شده اند و هر معماری CPU دارای یک باینری GSI مربوطه است (لیست اهداف ساخت را در Building GSIs ببینید).
اندروید 12 GSI تغییر می کند
دستگاههایی که با Android 12 راهاندازی میشوند یا بهروزرسانی میشوند باید از Android 12 GSI برای آزمایش انطباق استفاده کنند. این شامل تغییرات عمده زیر نسبت به GSI های قبلی است:
- نام هدف نام هدف GSI برای آزمایشهای انطباق به
gsi_$arch
تغییر یافته است. GSI با نام هدفaosp_$arch
برای توسعه دهندگان برنامه اندروید نگهداری می شود. طرح آزمایشیCTS-on-GSI
نیز برای آزمایش رابط فروشنده کاهش یافته است. - GSI قدیمی حذف شده است. GSI 12 راهحلهای مربوط به دستگاههای Android 8.0 یا 8.1 را که به طور کامل Treblized نیستند، حذف میکند.
- Userdebug SEPolicy. GSI
gsi_$arch
حاویuserdebug_plat_sepolicy.cil
است. هنگام فلش کردنvendor_boot-debug.img
یاboot-debug.img
خاص OEM،/system/bin/init
userdebug_plat_sepolicy.cil
از GSIsystem.img
بارگیری می کند. برای جزئیات، به تست VTS با Debug Ramdisk مراجعه کنید.
اندروید 11 GSI تغییر می کند
دستگاههایی که با Android 11 راهاندازی میشوند یا بهروزرسانی میشوند باید از Android 11 GSI برای آزمایش انطباق استفاده کنند. این شامل تغییرات عمده زیر نسبت به GSI های قبلی است:
- محتویات system_ext اندروید 11 یک پارتیشن جدید
system_ext
تعریف می کند. GSI محتویات پسوند سیستم را در پوشهsystem/system_ext
قرار می دهد. - APEX ها GSI شامل هر دو APEX های مسطح و فشرده است. اینکه کدام یک از آنها استفاده شود توسط ویژگی سیستم
ro.apex.updatable
در پارتیشن فروشنده در زمان اجرا تعیین می شود. سیستم پیکربندی مرجع برای پشتیبانی از بهروزرسانیهای APEX برای جزئیات.
اندروید 10 GSI تغییر کرد
دستگاههایی که با Android 10 راهاندازی میشوند یا بهروزرسانی میشوند باید از Android 10 GSI برای آزمایش انطباق استفاده کنند. این شامل تغییرات عمده زیر نسبت به GSI های قبلی است:
- ساخت کاربر. GSI دارای ساخت کاربر از اندروید 10 است. در اندروید 10، کاربر ساخت GSI را می توان در تست انطباق CTS-on-GSI/VTS استفاده کرد. برای جزئیات به تست VTS با Debug Ramdisk مراجعه کنید.
- قالب بدون شک. GSI با هدفهای
aosp_$arch
با فرمت پراکنده ساخته شدهاند. در صورت لزوم میتوانید ازimg2simg
برای تبدیل یک GSI پراکنده به فرمت پراکنده استفاده کنید. - سیستم به عنوان ریشه هدف ساخت GSI قدیمی به نام
aosp_$arch_a
به تدریج حذف شده بود. برای دستگاههایی که از Android 8 یا 8.1 به Android 10 با ramdisk و non-system-as-root ارتقا یافتهاند، از GSI قدیمیaosp_$arch_ab
استفاده کنید.init
ارتقا یافته در ramdisk از OEM system.img با طرحبندی system-as-root پشتیبانی میکند. - بوت را تأیید کنید. با استفاده از GSI فقط باید قفل دستگاه را باز کنید. لازم نیست تأیید بوت را غیرفعال کنید.
اندروید 9 GSI تغییر می کند
دستگاههایی که با Android 9 راهاندازی میشوند یا بهروزرسانی میشوند باید از GSI Android 9 برای آزمایش انطباق استفاده کنند. این شامل تغییرات عمده زیر نسبت به GSI های قبلی است:
- GSI و شبیه ساز را ادغام می کند. GSI ها از تصاویر سیستم محصولات شبیه ساز، به عنوان مثال،
aosp_arm64
وaosp_x86
ساخته شده اند. - سیستم به عنوان ریشه در نسخههای قبلی اندروید، دستگاههایی که از بهروزرسانیهای A/B پشتیبانی نمیکردند، میتوانستند تصویر سیستم را در پوشه
/system
نصب کنند. در اندروید 9، روت تصویر سیستم به عنوان روت دستگاه نصب می شود. - رابط کلاسور 64 بیتی. در اندروید 8.x، GSI های 32 بیتی از رابط بایندر 32 بیتی استفاده می کردند. اندروید 9 از رابط 32 بیتی بایندر پشتیبانی نمی کند، بنابراین هم GSI های 32 بیتی و هم GSI های 64 بیتی از رابط بایندر 64 بیتی استفاده می کنند.
- اجرای VNDK در اندروید 8.1، VNDK اختیاری بود. از Android 9، VNDK اجباری است، بنابراین
BOARD_VNDK_VERSION
باید تنظیم شود. - ویژگی سیستم سازگار Android 9 بررسی دسترسی یک ویژگی سیستم سازگار را فعال میکند (
PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true
).
Android 9 Keymaster تغییراتی دارد
در نسخههای قبلی Android، دستگاههایی که Keymaster 3 یا پایینتر را پیادهسازی میکنند، باید تأیید کنند که اطلاعات نسخه ( ro.build.version.release
و ro.build.version.security_patch
) که توسط سیستم در حال اجرا گزارش میشود، با اطلاعات نسخه گزارششده توسط بوتلودر مطابقت دارد. چنین اطلاعاتی معمولاً از هدر تصویر بوت به دست می آمد.
در اندروید 9 و بالاتر، این الزام تغییر کرده است تا فروشندگان بتوانند یک GSI را بوت کنند. به طور خاص، Keymaster نباید تأیید را انجام دهد زیرا اطلاعات نسخه گزارش شده توسط GSI ممکن است با اطلاعات نسخه گزارش شده توسط بوت لودر فروشنده مطابقت نداشته باشد. برای دستگاههایی که Keymaster 3 یا پایینتر را اجرا میکنند، فروشندگان باید پیادهسازی Keymaster را تغییر دهند تا از تأیید صحت عبور کنند (یا به Keymaster 4 ارتقا دهند). برای جزئیات در مورد Keymaster، به فروشگاه Keystore با پشتیبانی سخت افزار مراجعه کنید.
GSI ها را دانلود کنید
می توانید GSI های از پیش ساخته شده را از وب سایت ادغام پیوسته AOSP (CI) در ci.android.com دانلود کنید. اگر نوع GSI برای پلتفرم سخت افزاری شما برای دانلود در دسترس نیست، برای جزئیات در مورد ساخت GSI برای اهداف خاص به بخش زیر مراجعه کنید.
ساخت GSI
با شروع اندروید 9، هر نسخه اندروید دارای یک شاخه GSI به نام DESSERT -gsi
در AOSP است (به عنوان مثال، android12-gsi
شعبه GSI در اندروید 12 است). شاخه های GSI شامل محتوای اندروید با تمام وصله های امنیتی و وصله های GSI اعمال شده است.
برای ایجاد یک GSI، درخت منبع Android را با دانلود از یک شاخه GSI و انتخاب هدف ساخت GSI تنظیم کنید. از جداول هدف ساخت زیر برای تعیین نسخه صحیح GSI برای دستگاه خود استفاده کنید. پس از تکمیل ساخت، GSI تصویر سیستم است (یعنی system.img
) و در پوشه خروجی out/target/product/ generic_arm64
ظاهر می شود.
به عنوان مثال، برای ساخت هدف ساخت 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
اهداف ساخت اندروید GSI
اهداف ساخت GSI زیر برای دستگاههایی است که با اندروید 9 یا بالاتر راهاندازی میشوند.
نام GSI | قوس پردازنده | بیت رابط بایندر | سیستم به عنوان ریشه | هدف را بسازید |
---|---|---|---|---|
gsi_arm | 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
دستگاههای اندرویدی میتوانند طراحیهای متفاوتی داشته باشند، بنابراین هیچ دستور عمومی یا مجموعهای از دستورالعملها برای فلش کردن یک 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
در این مثال.به GSI ها کمک کنید
Android از مشارکت شما در توسعه GSI استقبال می کند. شما می توانید با این موارد درگیر شوید و به بهبود GSI کمک کنید:
- ایجاد پچ GSI
DESSERT -gsi
یک شاخه توسعه نیست و فقط cherrypicks را از شاخه اصلی 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
و غیره باشد.