تصویر سیستم مشترک اندروید

این صفحه مکانیسم‌های متعددی را ارائه می‌کند که OEM‌های دستگاه‌های Android می‌توانند از آنها برای داشتن تصویر سیستم مشترک (SSI) خود در خطوط تولید استفاده کنند. همچنین روشی را برای پایه گذاری یک SSI متعلق به OEM بر روی یک تصویر سیستم عمومی (GSI) ساخته شده توسط AOSP پیشنهاد می کند.

پس زمینه

با Project Treble ، اندروید یکپارچه به دو بخش تقسیم شد: بخش مخصوص سخت افزار (اجرای فروشنده) و بخش سیستم عامل عمومی (فریم ورک سیستم عامل اندروید). نرم افزار هر کدام در یک پارتیشن جداگانه نصب می شود: پارتیشن فروشنده برای نرم افزار مخصوص سخت افزار و پارتیشن سیستم برای نرم افزار سیستم عامل عمومی. یک رابط نسخه‌سازی شده، به نام رابط فروشنده ( VINTF )، تعریف شده و در دو پارتیشن اجرا می‌شود. با استفاده از این سیستم پارتیشن بندی می توانید پارتیشن سیستم را بدون تغییر پارتیشن فروشنده تغییر دهید و بالعکس.

انگیزه

کد فریمورک منتشر شده در AOSP با معماری Treble سازگار بوده و با پیاده سازی های فروشنده قدیمی تر سازگاری دارد. برای مثال، یک تصویر سیستم عمومی که از منابع AOSP Android 10 ساخته شده است، می‌تواند روی هر دستگاه سازگار با Treble که روی Android 8 یا بالاتر اجرا می‌شود، اجرا شود. نسخه اندرویدی که بر روی دستگاه های مصرف کننده ارسال می شود توسط فروشندگان SoC و OEM ها اصلاح شده است. (به Life of an Android Release مراجعه کنید.) این تغییرات و افزونه‌هایی که در چارچوب ایجاد شده‌اند برای حفظ سازگاری به عقب، که منجر به افزایش پیچیدگی و هزینه بالاتر در ارتقاء سیستم‌عامل می‌شود، نوشته نشده‌اند. تغییرات و اصلاحات خاص دستگاه بر هزینه و پیچیدگی ارتقاء نسخه سیستم عامل اندروید می افزاید.

قبل از اندروید 11، هیچ معماری واضحی وجود نداشت که شرکای خود را قادر به ساخت افزونه های مدولار برای چارچوب سیستم عامل اندروید کند. این سند مراحلی را که فروشندگان SoC و OEM می توانند برای ایجاد یک SSI بردارند، شرح می دهد. این به معنی یک تصویر است که از منابع چارچوب سیستم عامل اندروید برای استفاده مجدد در چندین دستگاه، برای حفظ سازگاری با پیاده سازی های فروشنده، و کاهش قابل توجهی در پیچیدگی و هزینه ارتقاء سیستم عامل اندروید ساخته شده است. برای مراحل خاصی که برای ایجاد SSI نیاز دارید، به بخش Suggested Steps for GSI-based SSI مراجعه کنید و توجه داشته باشید که لازم نیست از هر چهار مرحله استفاده کنید. اینکه کدام مراحل را انتخاب می کنید (مثلاً فقط مرحله 1) به اجرای شما بستگی دارد.

نمای کلی SSI

با SSI، اجزای نرم افزاری خاص محصول و پسوندهای OEM در یک پارتیشن /product جدید قرار می گیرند. اجزای پارتیشن /product از یک رابط کاملاً تعریف شده و پایدار برای تعامل با اجزای پارتیشن /system استفاده می کنند. OEM ها می توانند انتخاب کنند که یک SSI بسازند یا تعداد کمی SSI برای استفاده در SKU های چند دستگاه داشته باشند. هنگامی که نسخه جدیدی از سیستم عامل اندروید منتشر می شود، OEM ها فقط یک بار برای به روز رسانی SSI خود به آخرین نسخه اندروید سرمایه گذاری می کنند. آنها می توانند از SSI ها برای به روز رسانی چندین دستگاه بدون به روز رسانی پارتیشن /product استفاده مجدد کنند.

توجه داشته باشید که OEM ها و فروشندگان SoC SSI هایی می سازند که شامل تمام ویژگی ها و تغییرات سفارشی مورد نیاز یک OEM است. مکانیسم ها و بهترین شیوه های ارائه شده در این صفحه برای OEM ها در نظر گرفته شده است تا از آنها برای دستیابی به این اهداف کلیدی استفاده کنند:

  • استفاده مجدد از SSI در چندین SKU دستگاه.
  • سیستم اندروید را با افزونه های مدولار به روز کنید تا ارتقای سیستم عامل آسان تر شود.

ایده اصلی جداسازی اجزای محصول خاص در پارتیشن محصول مشابه ایده Treble در جداسازی اجزای خاص SoC در پارتیشن فروشنده است. یک رابط محصول (شبیه به VINTF ) امکان ارتباط بین SSI و پارتیشن محصول را فراهم می کند. توجه داشته باشید که با توجه به SSI، اصطلاح "کامپوننت ها" تمام منابع، باینری ها، متون، کتابخانه ها و غیره را توصیف می کند که روی تصاویر نصب شده اند، که اساسا به پارتیشن تبدیل می شوند.

پارتیشن های اطراف SSI

شکل 1 پارتیشن‌های اطراف SSI و رابط‌های نسخه‌سازی شده در پارتیشن‌ها و سیاست‌های روی اینترفیس‌ها را نشان می‌دهد. در این بخش هر یک از پارتیشن ها و اینترفیس ها به تفصیل توضیح داده می شود.

Partitions and interfaces around SSI block diagram

شکل 1. پارتیشن ها و رابط های اطراف SSI

تصاویر و پارتیشن ها

اطلاعات این بخش بین عبارات تصویر و پارتیشن تمایز قائل می شود.

  • تصویر یک نرم افزار مفهومی است که می تواند به طور مستقل به روز شود.
  • پارتیشن یک مکان ذخیره سازی فیزیکی است که می تواند به طور مستقل به روز شود.

بخش های شکل 1 به صورت زیر تعریف شده اند:

  • SSI: SSI تصویری است که برای یک OEM مشترک است و می تواند در چندین دستگاه وجود داشته باشد. هیچ مولفه مخصوص سخت افزار یا محصول خاصی ندارد. همه چیز در یک SSI معین، طبق تعریف، در بین همه دستگاه‌هایی که از آن SSI استفاده می‌کنند به اشتراک گذاشته می‌شود. همانطور که در شکل 1 مشاهده می شود، SSI از یک تصویر /system یا /system و پارتیشن های /system_ext تشکیل شده است.

    • پارتیشن /system شامل مولفه‌های مبتنی بر AOSP است، در حالی که /system_ext ، هنگامی که پیاده‌سازی می‌شود، شامل پسوندهای فروشنده OEM و SoC و مؤلفه‌هایی است که به شدت با مؤلفه‌های AOSP همراه هستند. به عنوان مثال، یک کتابخانه چارچوب OEM جاوا که APIهای سفارشی را برای برنامه های خود OEM ارائه می دهد، در پارتیشن /system_ext بهتر جا می گیرد تا در پارتیشن /system . محتوای هر دو پارتیشن /system و /system_ext از منابع Android اصلاح شده OEM ساخته شده است.

    • پارتیشن /system_ext اختیاری است، اما استفاده از آن برای هر ویژگی سفارشی و افزونه‌ای که به‌طور محکم با مؤلفه‌های مبتنی بر AOSP همراه است، مفید است. این تمایز به شما کمک می کند تا تغییراتی را که باید انجام دهید را شناسایی کنید تا بتوانید چنین مولفه هایی را از پارتیشن /system_ext به پارتیشن /product در یک دوره زمانی منتقل کنید.

  • محصول: مجموعه ای از اجزای خاص محصول یا دستگاه که نشان دهنده سفارشی سازی ها و برنامه های افزودنی OEM برای سیستم عامل Android است. اجزای مخصوص SoC را در پارتیشن /vendor قرار دهید. فروشندگان SoC همچنین می توانند از پارتیشن /product برای اجزای مناسب مانند قطعات مستقل از SoC استفاده کنند. به عنوان مثال، اگر یک فروشنده SoC یک جزء مستقل از SoC را برای مشتریان OEM خود فراهم کند (که برای ارسال با محصول اختیاری است)، فروشنده SoC می تواند آن جزء را در تصویر محصول قرار دهد. مکان یک جزء توسط مالکیت آن تعیین نمی شود، بلکه توسط هدف آن تعیین می شود.

  • Vendor: مجموعه ای از اجزای SoC خاص.

  • ODM: مجموعه ای از اجزای مخصوص برد که توسط SoC ارائه نشده اند. معمولاً فروشنده SoC مالک تصویر فروشنده است، در حالی که سازنده دستگاه مالک تصویر ODM است. هنگامی که پارتیشن /odm جداگانه وجود ندارد، هر دو تصویر فروشنده SoC و ODM در پارتیشن /vendor با هم ادغام می شوند.

رابط بین تصاویر

دو رابط اصلی برای تصاویر فروشنده و محصول در اطراف SSI وجود دارد:

  • رابط فروشنده (VINTF) : VINTF رابطی است با اجزایی که در فروشنده و تصاویر ODM قرار دارند. اجزای موجود در تصاویر محصول و سیستم فقط از طریق این رابط می توانند با فروشنده و تصاویر ODM تعامل داشته باشند. به عنوان مثال، یک تصویر فروشنده نمی تواند به قسمت خصوصی تصویر سیستم وابسته باشد و بالعکس. این در اصل در Project Treble تعریف شده است که تصاویر را به پارتیشن های سیستم و فروشنده تقسیم می کند. رابط کاربری با استفاده از مکانیسم های زیر توصیف می شود:

    • HIDL (HAL عبور فقط برای system و ماژول های system_ext موجود است)
    • AIDL پایدار
    • تنظیمات
      • API مشخصات سیستم
      • API طرحواره فایل پیکربندی
    • VNDK
    • APIهای Android SDK
    • کتابخانه Java SDK

  • رابط های محصول: رابط محصول رابط بین SSI و تصویر محصول است. تعریف یک رابط پایدار، اجزای محصول را از اجزای سیستم در یک SSI جدا می کند. رابط محصول به همان واسط های پایدار VINTF نیاز دارد. با این حال، فقط VNDK و Android SDK API برای دستگاه‌هایی که با Android 11 (و بالاتر) راه‌اندازی می‌شوند، اجرا می‌شوند.

SSI را در اندروید 11 فعال کنید

این بخش نحوه استفاده از ویژگی های جدید را برای پشتیبانی از SSI در اندروید 11 توضیح می دهد.

پارتیشن /system_ext

پارتیشن /system_ext در اندروید 11 به عنوان یک پارتیشن اختیاری معرفی شد. (این مکان برای اجزای غیر AOSP است که با مولفه های تعریف شده توسط AOSP در پارتیشن /system جفت می شوند.) پارتیشن /system_ext به عنوان پسوند اختصاصی OEM برای پارتیشن /system فرض می شود، بدون اینکه یک رابط تعریف شده در سراسر آن تعریف شده باشد. دو پارتیشن اجزای پارتیشن /system_ext می‌توانند فراخوانی‌های خصوصی API را به پارتیشن /system برقرار کنند و اجزای پارتیشن /system می‌توانند فراخوانی‌های خصوصی API را به پارتیشن /system_ext برقرار کنند.

از آنجایی که این دو پارتیشن کاملاً به هم متصل شده اند، هر دو پارتیشن با هم ارتقا می یابند زمانی که نسخه جدید اندروید منتشر می شود. پارتیشن /system_ext ایجاد شده برای نسخه قبلی اندروید نیازی به سازگاری با پارتیشن /system در نسخه بعدی اندروید ندارد.

برای نصب یک ماژول در پارتیشن /system_ext ، system_ext_specific: true را به فایل Android.bp اضافه کنید. برای دستگاه هایی که پارتیشن /system_ext ندارند، چنین ماژول هایی را در زیر شاخه ./system_ext در پارتیشن /system نصب کنید.

تاریخچه

در اینجا تاریخچه ای در مورد پارتیشن /system_ext آورده شده است. هدف طراحی، قرار دادن تمام اجزای خاص OEM، صرف نظر از رایج بودن آنها، در پارتیشن /product بود. با این حال، جابجایی همه آنها به یکباره امکان پذیر نبود، به خصوص زمانی که برخی از اجزای یک جفت محکم با پارتیشن /system داشتند. برای انتقال یک جزء محکم به پارتیشن /product ، رابط محصول باید گسترش یابد. این اغلب مستلزم این است که خود جزء به طور گسترده بازسازی شود که زمان و تلاش زیادی را صرف می کند. پارتیشن /system_ext به عنوان مکانی برای میزبانی موقت اجزایی که آماده انتقال به پارتیشن /product نیستند شروع شد. هدف SSI این بود که در نهایت پارتیشن /system_ext را حذف کند.

با این حال، پارتیشن /system_ext برای نزدیک نگه داشتن پارتیشن /system تا حد امکان به AOSP مفید است. با SSI، بیشتر تلاش برای ارتقا بر روی اجزای /system و پارتیشن های /system_ext صرف می شود. وقتی تصویر سیستم از منابعی ساخته می‌شود که تا حد امکان شبیه به منابع موجود در AOSP هستند، می‌توانید تلاش‌های ارتقا را روی تصویر system_ext متمرکز کنید.

کامپوننت ها را از پارتیشن های /system و /system_ext در پارتیشن /product جدا کنید

اندروید 9 یک پارتیشن /product را معرفی کرد که با پارتیشن /system همراه شده است. ماژول های موجود در پارتیشن /product از منابع سیستم بدون هیچ محدودیتی استفاده می کنند و بالعکس. برای امکان پذیر کردن SSI در اندروید 10، اجزای محصول به پارتیشن های /system_ext و /product تقسیم می شوند. پارتیشن /system_ext نیازی به محدودیت‌های استفاده از اجزای سیستم ندارد که پارتیشن /product در اندروید 9 انجام داد. از اندروید 10، پارتیشن /product باید از پارتیشن /system جدا شود و باید از رابط‌های پایدار استفاده کند. پارتیشن های /system و /system_ext .

هدف اصلی پارتیشن /system_ext گسترش ویژگی‌های سیستم است، به جای نصب ماژول‌های محصول همراه، همانطور که در بخش /system_ext partition توضیح داده شد. برای انجام این کار، ماژول های محصول خاص را جدا کرده و آنها را به پارتیشن /product منتقل کنید. جداسازی ماژول های محصول خاص باعث می شود /system_ext برای دستگاه ها مشترک باشد. (برای جزئیات بیشتر، به رایج کردن پارتیشن /system_ext مراجعه کنید.)

برای جداسازی پارتیشن /product از اجزای سیستم، پارتیشن /product باید همان خط مشی اجرایی پارتیشن /vendor را داشته باشد که قبلاً با Project Treble جدا شده بود.

با شروع در Android 11، رابط‌های بومی و جاوا برای پارتیشن /product به شرح زیر اعمال می‌شوند. برای اطلاعات بیشتر، به اجرای رابط های پارتیشن محصول مراجعه کنید.

  • رابط های بومی: ماژول های بومی در پارتیشن /product باید از پارتیشن های دیگر جدا شوند. تنها وابستگی‌های مجاز از ماژول‌های محصول، برخی از کتابخانه‌های VNDK (از جمله LLNDK) از پارتیشن /system هستند. کتابخانه‌های JNI که برنامه‌های محصول به آنها وابسته هستند باید کتابخانه‌های NDK باشند.
  • رابط های جاوا: ماژول های جاوا (برنامه) در پارتیشن /product نمی توانند از API های پنهان استفاده کنند، زیرا ناپایدار هستند. این ماژول‌ها فقط باید از APIهای عمومی و APIهای سیستم از پارتیشن /system و کتابخانه‌های Java SDK در پارتیشن /system یا /system_ext استفاده کنند. می توانید کتابخانه های Java SDK را برای API های سفارشی تعریف کنید.

مراحل پیشنهادی برای SSI مبتنی بر GSI

Suggested partitions for GSI-based SSI

شکل 2. پارتیشن های پیشنهادی برای SSI مبتنی بر GSI

یک تصویر سیستم عمومی (GSI) تصویر سیستمی است که مستقیماً از AOSP ساخته شده است. این برای تست‌های انطباق Treble (به عنوان مثال، CTS-on-GSI) و به‌عنوان یک پلتفرم مرجع استفاده می‌شود که توسعه‌دهندگان برنامه‌ها می‌توانند از آن برای آزمایش سازگاری برنامه‌های خود استفاده کنند، در صورتی که دستگاه واقعی دارای نسخه مورد نیاز Android نیست.

OEM ها همچنین می توانند از GSI برای ساخت SSI خود استفاده کنند. همانطور که در Images and Partitions توضیح داده شد، SSI شامل تصویر سیستم برای اجزای تعریف‌شده توسط AOSP و تصویر system_ext برای اجزای تعریف‌شده توسط OEM است. وقتی از GSI به عنوان تصویر system استفاده می‌شود، OEM می‌تواند روی تصویر system_ext برای ارتقا تمرکز کند.

این بخش راهنمایی برای OEM هایی ارائه می دهد که می خواهند سفارشی سازی های خود را در پارتیشن های /system_ext و /product در حین استفاده از تصویر سیستم AOSP یا نزدیک به AOSP مدولار کنند. اگر OEM ها تصویر سیستم را از منابع AOSP بسازند، می توانند تصویر سیستمی را که می سازند با GSI ارائه شده توسط AOSP جایگزین کنند. با این حال، OEM ها نیازی ندارند که به یکباره به مرحله نهایی (با استفاده از GSI همانطور که هست) برسند.

مرحله 1. generic_system.mk را برای تصویر سیستم OEM (OEM GSI) به ارث ببرید

با به ارث بردن generic_system.mk (که در اندروید 11 mainline_system.mk نامگذاری شد و در AOSP به generic_system.mk تغییر نام داد)، تصویر سیستم (OEM GSI) شامل تمام فایل هایی است که AOSP GSI دارد. این فایل ها را می توان توسط OEM ها تغییر داد، به طوری که OEM GSI می تواند علاوه بر فایل های AOSP GSI، حاوی فایل های اختصاصی OEM نیز باشد. با این حال، OEM ها مجاز به تغییر خود فایل generic_system.mk نیستند.

Inheriting `generic_system.mk` for OEM system image

شکل 3. به ارث بردن generic_system.mk برای تصویر سیستم OEM

مرحله 2. کاری کنید که OEM GSI فهرستی از فایل ها با AOSP GSI داشته باشد

OEM GSI در این مرحله نمی تواند فایل های اضافی داشته باشد. فایل های اختصاصی OEM باید به پارتیشن های system_ext یا product منتقل شوند.

Moving added files out of the OEM GSI

شکل 4. انتقال فایل های اضافه شده به خارج از OEM GSI

مرحله 3. یک لیست مجاز برای محدود کردن فایل های اصلاح شده در OEM GSI تعریف کنید

برای بررسی فایل های اصلاح شده، OEM ها می توانند از ابزار compare_images استفاده کنند و AOSP GSI را با OEM GSI مقایسه کنند. AOSP GSI را از هدف ناهار AOSP generic_system_* دریافت کنید.

با اجرای دوره‌ای ابزار compare_images با پارامتر allowlist ، می‌توانید تفاوت‌های خارج از لیست مجاز را کنترل کنید. این از نیاز به تغییرات اضافی در OEM GSI جلوگیری می کند.

Define an allowlist to reduce the list of modified files in OEM GSI

شکل 5. یک لیست مجاز برای کاهش لیست فایل های اصلاح شده در OEM GSI تعریف کنید

مرحله 4. کاری کنید که OEM GSI دارای باینری های مشابه با AOSP GSI باشد

پاک کردن لیست مجاز به OEM ها اجازه می دهد تا از AOSP GSI به عنوان تصویر سیستم برای محصولات خود استفاده کنند. برای پاک کردن لیست مجاز، OEM ها می توانند تغییرات خود را در OEM GSI رها کنند یا تغییرات خود را در AOSP به سمت بالا انجام دهند تا AOSP GSI شامل تغییرات آنها شود.

Make OEM GSI have the same binaries as AOSP GSI

شکل 6. ساختن OEM GSI دارای باینری های مشابه با AOSP GSI

SSI را برای OEM ها تعریف کنید

از پارتیشن سیستم / در زمان ساخت محافظت کنید

برای جلوگیری از هرگونه تغییر محصول خاص در پارتیشن /system و تعریف OEM GSI، OEM ها می توانند از یک ماکرو makefile به نام require-artifacts-in-path استفاده کنند تا از هرگونه اعلام ماژول های سیستم پس از فراخوانی ماکرو جلوگیری کنند. مثال بررسی مسیر ایجاد فایل ایجاد و فعال کردن مصنوع را ببینید.

OEM ها می توانند لیستی را تعریف کنند تا به ماژول های محصول خاص اجازه دهد تا به طور موقت در پارتیشن /system نصب شوند. با این حال، لیست باید خالی باشد تا OEM GSI برای همه محصولات OEM مشترک شود. این فرآیند برای تعریف OEM GSI است و می تواند مستقل از مراحل AOSP GSI باشد.

واسط های محصول را اعمال کنید

برای تضمین جداسازی پارتیشن /product ، OEM ها می توانند با تنظیم PRODUCT_PRODUCT_VNDK_VERSION:= current برای ماژول های بومی و PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE:= true برای ماژول های جاوا، اطمینان حاصل کنند که دستگاه هایشان رابط های محصول را اجرا می کنند. اگر PRODUCT_SHIPPING_API_LEVEL دستگاه بزرگتر یا مساوی 30 باشد، این متغیرها به طور خودکار تنظیم می شوند. برای اطلاعات دقیق، به اجرای رابط های پارتیشن محصول مراجعه کنید.

پارتیشن /system_ext را مشترک کنید

پارتیشن /system_ext ممکن است بین دستگاه‌ها متفاوت باشد، زیرا می‌تواند دارای ماژول‌های بسته‌بندی سیستمی خاص دستگاه باشد. از آنجا که SSI از پارتیشن های /system و /system_ext تشکیل شده است، تفاوت در پارتیشن /system_ext مانع از تعریف SSI توسط OEM ها می شود. OEM ها می توانند SSI خود را داشته باشند و می توانند با حذف هر گونه تفاوت و رایج کردن پارتیشن /system_ext ، آن SSI را بین چندین دستگاه به اشتراک بگذارند.

این بخش توصیه هایی برای رایج کردن پارتیشن /system_ext می دهد.

API های پنهان در پارتیشن سیستم را آشکار کنید

بسیاری از برنامه های خاص محصول را نمی توان در پارتیشن محصول نصب کرد زیرا از API های پنهان استفاده می کنند که در پارتیشن محصول ممنوع است. برای انتقال برنامه‌های خاص دستگاه به پارتیشن محصول، استفاده از APIهای پنهان را حذف کنید.

راه ترجیحی برای حذف APIهای پنهان از برنامه ها، یافتن APIهای عمومی یا سیستمی جایگزین برای جایگزینی آنهاست. اگر هیچ API برای جایگزینی API های پنهان وجود نداشته باشد، OEM ها می توانند به AOSP کمک کنند تا API های سیستم جدید را برای دستگاه های خود تعریف کنند.

از طرف دیگر، OEM ها می توانند API های سفارشی را با ایجاد کتابخانه Java SDK خود در پارتیشن /system_ext تعریف کنند. می‌تواند از APIهای پنهان در پارتیشن سیستم استفاده کند و می‌تواند APIها را در اختیار برنامه‌های موجود در پارتیشن محصول یا فروشنده قرار دهد. OEM ها باید API های رو به محصول را برای سازگاری با عقب نگه دارند .

سوپرمجموعه همه فایل‌های APK را درج کنید و از نصب برخی بسته‌ها برای هر دستگاه صرفنظر کنید

بسته‌های خاصی که با سیستم همراه هستند در بین دستگاه‌ها رایج نیستند. جداسازی این ماژول‌های APK برای انتقال آنها به محصول یا پارتیشن فروشنده می‌تواند دشوار باشد. به عنوان یک راه حل موقت، OEM ها می توانند SSI را شامل همه ماژول ها کنند، سپس با استفاده از ویژگی SKU ( ro.boot.hardware.sku ) موارد ناخواسته را فیلتر کنند. برای استفاده از فیلتر، OEM ها منابع چارچوب config_disableApkUnlessMatchedSku_skus_list و config_disableApksUnlessMatchedSku_apk_list را پوشش می دهند.

برای تنظیمات دقیق تر، یک گیرنده پخش را اعلام کنید که بسته های غیر ضروری را غیرفعال می کند. گیرنده پخش setApplicationEnabledSetting تماس می گیرد تا بسته را با دریافت پیام ACTION_BOOT_COMPLETED غیرفعال کند.

به جای استفاده از همپوشانی منابع استاتیک، RRO را تعریف کنید

یک همپوشانی منبع ایستا بسته های همپوشانی را دستکاری می کند. با این حال، می تواند مانع از تعریف یک SSI شود، بنابراین مطمئن شوید که ویژگی های RRO به درستی روشن و تنظیم شده است. با تنظیم ویژگی ها به صورت زیر، OEM ها می توانند همه همپوشانی های تولید شده خودکار را به عنوان RRO داشته باشند.

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

اگر به پیکربندی دقیقی نیاز است، به جای تکیه بر پیکربندی خودکار، یک RRO را به صورت دستی تعریف کنید. برای اطلاعات دقیق، به Runtime Resource Overlays (RROs) مراجعه کنید. OEM ها همچنین می توانند RRO های شرطی را که به ویژگی های سیستم بستگی دارد با استفاده از ویژگی های android:requiredSystemPropertyName و android:requiredSystemPropertyValue تعریف کنند.

سوالات متداول (سؤالات متداول)

آیا می توانم چندین SSI تعریف کنم؟

این بستگی به مشترکات و ویژگی های دستگاه ها (یا گروه دستگاه) دارد. OEM ها می توانند سعی کنند پارتیشن system_ext را رایج کنند، همانطور که در ساختن پارتیشن system_ext مشترک توضیح داده شده است. اگر یک گروه دستگاه تفاوت های زیادی دارد، بهتر است چندین SSI تعریف کنید.

آیا می توانم generic_system.mk (mainline_system.mk) را برای یک OEM GSI تغییر دهم؟

خیر. اما OEM ها می توانند یک makefile جدید برای یک OEM GSI که فایل generic_system.mk را به ارث می برد تعریف کنند و به جای آن از makefile جدید استفاده کنند. برای مثال، به اجرای رابط های پارتیشن محصول مراجعه کنید.

آیا می توانم ماژول هایی را از generic_system.mk حذف کنم که با پیاده سازی من در تضاد هستند؟

خیر. GSI دارای حداقل مجموعه ای از ماژول های قابل بوت و آزمایش است. اگر فکر می‌کنید ماژول ضروری نیست، لطفاً یک اشکال برای به‌روزرسانی فایل generic_system.mk در AOSP ثبت کنید.