تصاویر سیستم عمومی

یک تصویر سیستم عمومی (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 مورد استفاده برای تست انطباق با نسخه اندرویدی که دستگاه با آن راه اندازی می شود تعیین می شود.

نوع وسیله هدف را بسازید
دستگاه هایی که با اندروید 12 راه اندازی می شوند gsi_$arch-user (امضا شده)
دستگاه هایی که با اندروید 11 راه اندازی می شوند gsi_$arch-user (امضا شده)
دستگاه هایی که با اندروید 10 راه اندازی می شوند gsi_$arch-user (امضا شده)
دستگاه هایی که با اندروید 9 راه اندازی می شوند gsi_$arch-userdebug

همه 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 ، /system/bin/init userdebug_plat_sepolicy.cil را از GSI system.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 و غیر سیستم به‌عنوان ریشه ارتقا یافته‌اند، از 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 با پشتیبانی سخت افزار مراجعه کنید.

دانلود GSIs

می توانید GSI های از پیش ساخته شده را از وب سایت ادغام پیوسته AOSP (CI) در ci.android.com دانلود کنید. اگر نوع GSI برای پلتفرم سخت افزاری شما برای دانلود در دسترس نیست، برای جزئیات در مورد ساخت GSI برای اهداف خاص به بخش زیر مراجعه کنید.

ساخت GSIs

با شروع اندروید 9، هر نسخه اندروید دارای یک شاخه GSI به نام DESSERT -gsi در AOSP است (به عنوان مثال، android12-gsi شعبه GSI در Android 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 64 Y gsi_arm-user
gsi_arm-userdebug
gsi_arm64 ARM64 64 Y gsi_arm64-user
gsi_arm64-userdebug
gsi_x86 x86 64 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 تماس بگیرید. از مراحل زیر به عنوان یک دستورالعمل کلی استفاده کنید:

  1. اطمینان حاصل کنید که دستگاه دارای موارد زیر است:
    • سه گانه شد
    • روشی برای باز کردن قفل دستگاه ها (بنابراین می توان آنها را با استفاده از fastboot فلش کرد)
    • یک حالت قفل برای قابل فلش کردن آن از طریق fastboot (برای اطمینان از اینکه آخرین نسخه fastboot را دارید، آن را از درخت منبع Android بسازید.)
  2. پارتیشن فعلی سیستم را پاک کنید، سپس GSI را به پارتیشن سیستم فلش کنید.
  3. داده های کاربر را پاک کنید و داده ها را از سایر پارتیشن های ضروری (به عنوان مثال، داده های کاربر و پارتیشن های سیستم) پاک کنید.
  4. دستگاه را راه اندازی مجدد کنید.

به عنوان مثال، برای فلش کردن یک GSI به هر دستگاه پیکسل:

  1. به حالت fastboot بوت کنید و بوت لودر را باز کنید .
  2. دستگاه هایی که از fastbootd پشتیبانی می کنند نیز باید توسط:
    $ fastboot reboot fastboot
    به fastbootd بوت بوت شوند.
  3. GSI را پاک کرده و در پارتیشن سیستم فلش کنید:
    $ fastboot erase system
$ fastboot flash system system.img
  4. داده های کاربر را پاک کنید و داده ها را از سایر پارتیشن های ضروری (به عنوان مثال، داده های کاربر و پارتیشن های سیستم) پاک کنید:
    $ fastboot -w
  5. راه اندازی مجدد:
    $ fastboot reboot
در دستگاه‌های Android 10 یا جدیدتر که پارتیشن‌های سیستم کوچک‌تری دارند، ممکن است هنگام فلش کردن GSI پیام خطای زیر ظاهر شود:
    Resizing 'system_a'    FAILED (remote: 'Not enough space to resize partition')
    fastboot: error: Command failed
از دستور زیر برای حذف پارتیشن محصول و آزاد کردن فضا برای پارتیشن سیستم استفاده کنید. این فضای اضافی برای فلش کردن GSI فراهم می کند:
$ fastboot delete-logical-partition product_a
postfix _a باید با شناسه اسلات پارتیشن سیستم مطابقت داشته باشد، مانند system_a در این مثال.

کمک به GSIs

Android از مشارکت شما در توسعه GSI استقبال می کند. شما می توانید با موارد زیر درگیر شوید و به بهبود GSI کمک کنید:

  • ایجاد پچ GSI DESSERT -gsi یک شاخه توسعه نیست و فقط cherrypicks را از شاخه اصلی AOSP می پذیرد، بنابراین برای ارسال یک پچ GSI، باید:
    1. پچ را به شعبه master AOSP ارسال کنید.
    2. گیلاس پچ را برای DESSERT -gsi کنید.
    3. برای بررسی cherrypick یک اشکال ثبت کنید.
  • گزارش اشکالات GSI یا ارائه پیشنهادات دیگر. دستورالعمل های گزارش اشکالات را مرور کنید، سپس اشکالات GSI را مرور یا فایل کنید.

نکات

تغییر حالت نوار ناوبری با استفاده از adb

هنگام راه‌اندازی با GSI، حالت نوار ناوبری با نادیده گرفتن فروشنده پیکربندی می‌شود. با اجرای دستور adb زیر در زمان اجرا می توانید حالت نوار ناوبری را تغییر دهید.

adb exec-out cmd overlay enable-exclusive com.android.internal.systemui.navbar.mode

که در آن mode می تواند threebutton ، twobutton ، gestural ای و غیره باشد.