Google متعهد به پیشبرد برابری نژادی برای جوامع سیاه است. ببینید چگونه.
این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.
Switch to English

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

تصویر سیستم عمومی (GSI) یک تصویر سیستم با تنظیمات تنظیم شده برای دستگاه های Android است. این یک اجرای Android خالص با کد اصلاح نشده پروژه منبع باز (AOSP) Android است که هر دستگاه Android با Android 8.1 یا بالاتر می تواند با موفقیت اجرا شود.

GSI برای اجرای تستهای VTS و CTS-on-GSI استفاده می شود. تصویر سیستم یک دستگاه اندرویدی با یک GSI جایگزین شده و سپس با استفاده از تست فروشنده (VTS) و مجموعه سازگاری تست (CTS) آزمایش شده است تا اطمینان حاصل شود که دستگاه با رابط کاربری فروشنده به درستی با آخرین نسخه Android پیاده سازی کرده است.

برای شروع کار با GSI ، بخش های زیر را برای جزئیات بیشتر در مورد تنظیمات GSI (و واریانس مجاز) ، انواع (Android GSI و Legacy GSI) ، و باینری های فروشنده و وابستگی VNDK بررسی کنید . هنگامی که شما آماده استفاده از یک GSI هستید ، GSI را برای هدف دستگاه خود بارگیری و ایجاد کنید ، سپس GSI را به یک دستگاه Android وصل کنید.

پیکربندی GSI و واریانس

GSI فعلی Android دارای پیکربندی زیر است:

  • طوفان GSI شامل پشتیبانی کامل از تغییرات معماری مبتنی بر HIDL (همچنین به عنوان Treble شناخته می شود) معرفی شده در Android 8.0 ، از جمله پشتیبانی از رابط های HIDL است . شما می توانید از GSI در هر دستگاه Android که از رابط های فروشنده HIDL استفاده می کند استفاده کنید. (برای اطلاعات بیشتر ، به منابع معماری مراجعه کنید.)
  • چکمه را تأیید کنید. GSI شامل راه حل تأیید بوت (مانند vboot 1.0 یا AVB ) نیست. برای فشردن GSI به دستگاهی که در Android 9 یا پیش از آن راه اندازی شده است ، دستگاه باید روشی برای غیرفعال کردن تأیید بوت داشته باشد.
  • سیستم فایل GSI از سیستم فایل ext4 استفاده می کند.
  • طرح پارتیشن. GSI از طرح پارتیشن سیستم به عنوان ریشه استفاده می کند .

GSI Android فعلی انواع مختلفی از موارد زیر را شامل می شود:

  • معماری CPU. پشتیبانی از دستورالعمل های مختلف پردازنده (ARM ، x86 ، و غیره) و bitness CPU (32 بیتی یا 64 بیتی).

اهداف GSI برای آزمونهای سازگاری Treble

GSI مورد استفاده برای آزمایش انطباق با نسخه اندرویدی که دستگاه با آن راه اندازی می شود تعیین می شود.

نوع وسیله ساختن هدف
راه اندازی دستگاه ها با Android 10 aosp_$arch-user
راه اندازی دستگاه ها با Android 9 aosp_$arch-userdebug
راه اندازی دستگاه ها با Android 8.0 یا Android 8.1 aosp_$arch_ab-userdebug

همه GSI ها از پایه کد آندروید 10 ساخته شده اند ، و هر معماری CPU دارای یک باینری مربوط به GSI است (به لیست اهداف ساخت در ساختمان های GSI مراجعه کنید).

Android 10 GSI تغییر می کند

دستگاه های راه‌اندازی شده با Android 10 برای آزمایش انطباق باید از Android 10 GSI استفاده کنند. این شامل تغییرات عمده زیر از GSI های قبلی است:

  • کاربر ساخت. GSI دارای ساخت کاربر از اندروید 10 است. در Android 10 ، کاربر ساخت GSI می تواند در تست سازگاری CTS-on-GSI / VTS استفاده شود. مرجع VTS تست با اشکال زدایی Ramdisk برای جزئیات.
  • قالب بدون نسخه. GSI با اهداف aosp_$arch با قالب unsparsed ساخته شده است. در صورت لزوم می توانید از img2simg استفاده کنید تا در صورت لزوم تبدیل به یک GSI بدون پارس به فرم پراکنده تبدیل کنید.
  • ریشه سیستم. میراث هدف ساخت GSI با نام aosp_$arch_a به مرحله نهایی رسیده است. برای دستگاه های به روز شده از اندروید 8 یا 8.1 به اندروید 10 با ramdisk و غیر سیستمی مانند ، از میراث GSI aosp_$arch_ab . init روز شده در ramdisk از طرح نصب شده system.img با طرح سیستم به عنوان ریشه پشتیبانی می کند.

برای آزمایش دستگاه های راه‌اندازی شده در Android 9 یا 10 با CTS-on-GSI ، از اهداف ساخت Android GSI استفاده کنید .

GSI میراث

Legacy _ab با پسوند _ab (به عنوان مثال aosp_arm64_ab ) aosp_arm64_ab . این GSI ها از درخت منبع Android 10 ساخته شده اند اما حاوی تنظیمات سازگار با عقب زیر برای دستگاه های به روز شده از Android 8 یا 8.1 هستند:

  • فضای کاربری 32 بیتی + رابط باند 32 بیتی. GSI های 32 بیتی می توانند همچنان از رابط باند 32 بیتی استفاده کنند.
  • 8.1 VNDK. دستگاه ها می توانند از 8.1 VNDK گنجانده شده استفاده کنند.
  • نصب دایرکتوری ها برخی از دستگاه های میراث از فهرست ها به عنوان نشانگرهای سوار استفاده می کنند (به عنوان مثال ، /bluetooth ، /firmware/radio ، و /persist ).

برای آزمایش دستگاه های پرتاب در Android 8 یا 8.1 با CTS-on-GSI ، از اهداف ساخت Legacy GSI استفاده کنید .

Android 9 GSI تغییر می کند

GSI های Android 9 شامل تغییرات عمده زیر از GSI های قبلی هستند:

  • ادغام GSI و شبیه ساز. GSI از تصاویر سیستم محصولات شبیه ساز ساخته شده است ، به عنوان مثال ، aosp_arm64 و aosp_x86 .
  • ریشه سیستم. در نسخه های قبلی Android ، دستگاه هایی که از به روزرسانی A / B پشتیبانی نمی کنند می توانند تصویر سیستم را در زیر فهرست /system سوار کنند. در اندروید 9 ، ریشه تصویر سیستم به عنوان ریشه دستگاه نصب می شود.
  • رابط باند 64 بیتی. در اندروید 8.x ، GSI های 32 بیتی از رابط باند 32 بیتی استفاده کردند. اندروید 9 از رابط باند 32 بیتی پشتیبانی نمی کند ، بنابراین هم GSI های 32 بیتی و هم GSI های 64 بیتی از رابط اتصال 64 بیتی استفاده می کنند.
  • اجرای VNDK. در Android 8.1 ، VNDK اختیاری بود. با شروع از Android 9 ، 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 ) گزارش شده توسط سیستم عامل مطابق با اطلاعات نسخه گزارش شده توسط bootloader است. چنین اطلاعاتی معمولاً از هدر تصویر بوت به دست می آید.

در Android 9 و بالاتر ، این شرط تغییر کرده است تا فروشندگان بتوانند GSI را بوت کنند. به طور خاص ، Keymaster نباید تأیید انجام دهد زیرا اطلاعات نسخه گزارش شده توسط GSI ممکن است با اطلاعات نسخه گزارش شده توسط bootloader فروشنده سازگار نباشد. برای دستگاههای پیاده سازی Keymaster 3 یا پایین تر ، فروشندگان باید عملکرد Keymaster را تغییر دهند تا از تأیید رد شوند (یا به Keymaster 4 ارتقاء پیدا کنند). برای جزئیات بیشتر در مورد Keymaster ، به Keystore با پشتیبانی سخت افزار مراجعه کنید .

باینری های فروشنده و وابستگی های VNDK

دستگاههای ارتقاء یافته به Android 10 بسته به نسخه باینریهای فروشنده در دستگاه و تنظیمات مربوط به VNDK که برای ساخت دستگاه مورد استفاده قرار می گیرند ، مسیرهای ارتقاء متفاوتی دارند. در جدول زیر میراث پشتیبانی GSI برای دستگاه های به روز شده خلاصه شده است.

استفاده از مورد فروشنده
دوتایی
نسخه
BOARD_VNDK_VERSION GSI میراث
نسخه دودویی سیستم
پشتیبانی GSI میراث
0 8.0 (هر) 10 نه
1 8.1 (خالی) 10 نه
2 8.1 current 10 آره
3 10 current 10 آره

بیشترین مورد استفاده مشترک حمایت # 2، که در آن میراث GSIs دستگاه های پشتیبانی در حال اجرا آندروید 8.1 که با ساخته شد BOARD_VNDK_VERSION مجموعه به current .

مورد شماره 1 پشتیبانی نمی شود. در این حالت ، BOARD_VNDK_VERSION میراث از دستگاههای دارای Android 8.1 که در آن BOARD_VNDK_VERSION از ساخت خارج شده پشتیبانی نمی کند. این دستگاه ها پشتیبانی نمی شوند زیرا باینری های فروشنده آنها به کتابخانه های مشترک 8.1 غیر VNDK آندروید وابسته هستند ، که در GSI های میراث گنجانده نشده اند. برای سازگاری این دستگاه ها با GSI میراث ، باید یکی از موارد زیر را انجام دهید:

  • فعال کردن BOARD_VNDK_VERSION بدون BOARD_VNDK_RUNTIME_DISABLE (مورد استفاده # 2).

    یا

  • بندرها را به فروشگاههای جدید منتقل کنید تا به کتابخانه های مشترک از اندروید 10 وابسته شوید (از مورد شماره 3) استفاده کنید.

بارگیری GSI

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

ساخت GSI

با شروع Android 9 ، هر نسخه Android دارای شعبه GSI به نام DESSERT -gsi در AOSP است (برای مثال android10-gsi شاخه GSI در اندروید 10 است). شعبه‌های GSI شامل محتوای Android با کلیه نکات امنیتی و تکه های GSI اعمال شده است.

برای ساختن یک GSI ، با بارگیری از شاخه GSI و انتخاب یک هدف ساخت GSI ، منبع مبدأ Android را تنظیم کنید. از جدولهای هدف ساخت زیر استفاده کنید تا نسخه صحیح GSI را برای دستگاه خود تعیین کنید. پس از اتمام ساخت ، GSI تصویر سیستم (یعنی system.img ) است و در پوشه خروجی out/target/product/ generic_arm64 . این vbmeta.img همچنین از vbmeta.img خروجی می vbmeta.img ، که می توانید از آن برای غیرفعال کردن تأیید بوت در دستگاه ها با استفاده از Android Verified Boot استفاده کنید .

به عنوان مثال ، برای ساختن GSI ساخت هدف aosp_arm64-userdebug در شاخه GSI android10-gsi ، دستورات زیر را اجرا کنید.

$ repo init -u https://android.googlesource.com/platform/manifest -b android10-gsi
$ repo sync -cq
$ source build/envsetup.sh
$ lunch aosp_arm64-userdebug
$ make -j4

اهداف ساخت GSI Android

اهداف ساخت GSI زیر برای دستگاههای پرتاب در Android 9 یا بالاتر است. به دلیل کاهش واریانس بین معماری ، اندروید 10 تنها چهار محصول GSI را شامل می شود.

نام GSI قوس CPU بیت رابط باند ریشه سیستم ساختن هدف
aosp_arm ARM 64 Y aosp_arm-user
aosp_arm-userdebug
aosp_arm64 ARM64 64 Y aosp_arm64-user
aosp_arm64-userdebug
aosp_x86 x86 64 Y aosp_x86-user
aosp_x86-userdebug
aosp_x86_64 x86-64 64 Y aosp_x86_64-user
aosp_x86_64-userdebug

میراث GSI اهداف را ایجاد می کند

اهداف ایجاد GSI میراث زیر برای دستگاههایی است که از Android 8.0 یا 8.1 به Android نسخه 10 ارتقا دارند. Legacy GSI شامل پسوند _ab تا بتواند آنها را از نام های GSI اندروید 10 متمایز کند.

نام GSI قوس CPU بیت رابط باند ریشه سیستم ساختن هدف
aosp_arm_ab ARM 32 Y aosp_arm_ab-userdebug
aosp_arm_64b_ab ARM 64 Y aosp_arm_64b_ab-userdebug
aosp_arm64_ab ARM64 64 Y aosp_arm64_ab-userdebug
aosp_x86_ab x86 32 Y aosp_x86_ab-userdebug
aosp_x86_64_ab x86-64 64 Y aosp_x86_64_ab-userdebug

الزامات مربوط به چشمک زن GSI

دستگاه های Android می توانند طراحی های متفاوتی داشته باشند ، بنابراین هیچ دستور عمومی یا مجموعه ای از دستورالعمل ها برای چشمک زن کردن یک GSI برای استفاده در همه دستگاه ها وجود ندارد. با دستورالعملهای صریح چشمک زن با سازنده دستگاه Android همراه باشید. از مراحل زیر به عنوان یک راهنمای کلی استفاده کنید:

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

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

  1. بوت شدن به حالت fastboot و باز کردن قفل bootloader . دستگاه های حمایت از fastbootd نیز به بوت نیاز به fastbootd شده توسط:
    $ fastboot reboot fastboot
  2. غیرفعال کردن چکمه (AVB) با چشمک زدن vbmeta.img :
    $ fastboot --disable-verification flash vbmeta vbmeta.img
  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 باید با id شکاف پارتیشن سیستم مانند system_a در این مثال system_a باشد.

مشارکت در GSIs

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

  • ایجاد یک پچ GSI. DESSERT -gsi است شاخه توسعه و نمی پذیرد تنها cherrypicks از AOSP شعبه استاد، به طوری که به ارائه یک پچ GSI، شما باید:
    1. پچ را به شعبه master AOSP ارسال کنید .
    2. Cherrypick وصله را به 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 ، و غیره.