تصویر سیستم هم‌رسانی‌شده

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

پس‌زمینه

چارچوب «پروژه منبع باز Android»‏ (AOSP) از معماری Mainline پیروی می‌کند تا سازگاری با پیاده‌سازی‌های قدیمی‌تر فروشنده را حفظ کند. برای مثال، «تصویر سیستم عمومی» (GSI) که از منابع Android 10 AOSP ساخته شده است می‌تواند روی هر دستگاه سازگار با Treble که Android 8 یا بالاتر را اجرا می‌کند اجرا شود.

‫Mainline این کار را با تقسیم Android به دو بخش مجزا انجام می‌دهد: پیاده‌سازی فروشنده مختص سخت‌افزار و چارچوب سیستم‌عامل Android عمومی. هر مؤلفه در پارتیشن جداگانه‌ای نصب می‌شود—پارتیشن فروشنده برای نرم‌افزار مختص سخت‌افزار و پارتیشن سیستم برای سیستم‌عامل عمومی. یک میانای نسخه‌دار، به‌نام میانای فروشنده (VINTF)، بین آن‌ها اجرا می‌شود. این سیستم پارتیشن‌بندی به «تولیدکنندگان تجهیزات اصلی» اجازه می‌دهد پارتیشن سیستم را بدون دست زدن به پارتیشن فروشنده اصلاح کنند و بالعکس.

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

این صفحه نحوه ساختن تصویر سیستم مشترک (SSI) توسط فروشندگان SoC و OEM را شرح می‌دهد. «تصویر چارچوب یکپارچه» (SSI) تصویر چارچوب یکپارچه‌ای است که از منابع سیستم‌عامل Android ساخته شده است و می‌تواند در چندین دستگاه استفاده مجدد شود. با حفظ سازگاری معکوس پاک با پیاده‌سازی‌های فروشنده ازطریق این معماری پارتیشن‌بندی‌شده، یک SSI به‌طور قابل‌توجهی هزینه و پیچیدگی ارتقاهای سیستم عامل Android را کاهش می‌دهد.

برای جزئیات پیاده‌سازی، به مراحل پیشنهادی برای SSI مبتنی بر GSI مراجعه کنید. مراحل مدولار هستند؛ بسته به معماری‌تان، می‌توانید به‌جای همه مراحل، مراحل خاصی را برای پیاده‌سازی انتخاب کنید (مانند مرحله ۱: به‌ارث بردن generic_system.mk برای تصویر سیستم OEM‏ (OEM GSI)).

نمای کلی SSI

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

سازندگان تجهیزات اصلی و فروشندگان «سیستم روی تراشه» می‌توانند «تصویر سیستم عمومی» بسازند که شامل ویژگی‌های سفارشی و اصلاحات باشد. سازوکارها و روال‌های مطلوب ارائه‌شده در این صفحه برای استفاده «تولیدکنندگان تجهیزات اصلی» به‌منظور دستیابی به این اهداف کلیدی درنظر گرفته شده است:

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

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

بخش‌های اطراف SSI

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

شکل ۱. پارتیشن‌ها و میاناهای مربوط به SSI.

تصاویر و بخش‌ها

اطلاعات این بخش تفاوت بین اصطلاحات image (تصویر) و partition (پارتیشن) را مشخص می‌کند.

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

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

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

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

• تصویر فروشنده: مجموعه‌ای از عناصر مختص SoC.

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

پارتیشن /system_ext

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

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

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

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

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

میاناهای بین تصاویر

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

• Vendor Interface (VINTF): VINTF is the interface to the components that reside in the vendor and the ODM images. عناصر موجود در تصاویر محصول و سیستم فقط می‌توانند ازطریق این واسط با تصاویر فروشنده و ODM تعامل داشته باشند. برای مثال، تصویر فروشنده نمی‌تواند به بخش خصوصی تصویر سیستم وابسته باشد و برعکس. این موضوع در معماری Treble (اکنون بخشی از معماری گسترده‌تر Mainline) تعریف شده است که تصاویر را به پارتیشن‌های سیستم و فروشنده تقسیم می‌کند. میانای کاربری بااستفاده از سازوکارهای زیر توصیف می‌شود:

  • HIDL (HAL گذری فقط برای ماژول‌های system و system_ext دردسترس است)
  • ‫AIDL پایدار
  • پیکربندی‌ها
    • System properties API
    • میانای برنامه‌سازی کاربردی طرحواره فایل پیکربندی
  • VNDK
  • میاناهای برنامه کاربردی کیت توسعه نرم‌افزار Android
  • کتابخانه کیت توسعه نرم‌افزار جاوا

• میاناهای محصول: میانای محصول، میانای بین SSI و تصویر محصول است. تعریف یک میانای پایدار، اجزای محصول را از اجزای سیستم در SSI جدا می‌کند.

فعال کردن SSI

این بخش توضیح می‌دهد که چگونه از SSI در Android 11 و بالاتر پشتیبانی کنید.

جدا کردن اجزا

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

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

اجرای رابط‌های محصول

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

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

شکل ۲. بخش‌های پیشنهادی برای «هویت خودگردان» مبتنی بر GSI.

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

تولیدکنندگان تجهیزات اصلی (OEM) نیز می‌توانند از GSI برای ساختن SSI خود استفاده کنند. همان‌طور که در تصاویر و پارتیشن‌ها توضیح داده شده است، SSI شامل تصویر سیستم برای مؤلفه‌های تعریف‌شده توسط AOSP و تصویر system_ext برای مؤلفه‌های تعریف‌شده توسط OEM است. وقتی از GSI به‌عنوان تصویر system استفاده می‌شود، OEM می‌تواند برای ارتقا روی تصویر system_ext تمرکز کند.

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

مرحله ۱: به ارث بردن generic_system.mk برای تصویر سیستم OEM (تصویر سیستم عمومی OEM)

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

شکل ۳. ‫generic_system.mk را برای تصویر سیستم سازنده اصلی تجهیزات به ارث ببرید.

مرحله ۲: فهرست فایل‌های GSI سازنده تجهیزات اصلی را با فهرست فایل‌های GSI پروژه متن‌باز Android یکسان کنید

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

شکل ۴. فایل‌های اضافه‌شده را از OEM GSI خارج کنید.

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

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

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

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

مرحله ۴: کاری کنید که OEM GSI همان دودویی‌های AOSP GSI را داشته باشد

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

شکل ۶. ‫OEM GSI را طوری بسازید که باینری‌های آن با AOSP GSI یکسان باشد.

تعریف SSI

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

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

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

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

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

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

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

نمایش میاناهای برنامه‌سازی کاربردی پنهان در پارتیشن سیستم

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

روش ترجیحی برای برداشتن میاناهای برنامه‌سازی کاربردی پنهان از برنامه‌ها این است که میاناهای برنامه‌سازی کاربردی عمومی یا سیستم جایگزین برای آن‌ها پیدا کنید. اگر هیچ «میانای برنامه‌سازی کاربردی» برای جایگزینی میاناهای برنامه‌سازی کاربردی پنهان وجود نداشته باشد، «تولیدکنندگان تجهیزات اصلی» می‌توانند در AOSP همیاری کنند تا میاناهای برنامه‌سازی کاربردی سیستم جدید را برای دستگاه‌هایشان تعریف کنند.

همچنین، «تولیدکنندگان تجهیزات اصلی» می‌توانند با ایجاد کتابخانه Java SDK خودشان در پارتیشن /system_ext، میاناهای برنامه‌سازی کاربردی سفارشی تعریف کنند. این کتابخانه می‌تواند از میاناهای برنامه‌سازی کاربردی پنهان در پارتیشن سیستم استفاده کند و می‌تواند میاناهای برنامه‌سازی کاربردی را برای برنامه‌ها در پارتیشن محصول یا فروشنده ارائه دهد. تولیدکنندگان اصلی سخت‌افزار باید میاناهای برنامه‌سازی کاربردی محصول‌نما را برای سازگاری با نسخه قدیمی ثابت نگه دارند.

جایگزین کردن غیرفعال‌سازی برنامه مختص «واحد نگهداری موجودی»

‫Android 16 سازوکار قدیمی را برای غیرفعال کردن انتخابی فایل‌های APK براساس واحد نگهداری کالا سخت‌افزار بااستفاده از رونهادهای منبع چارچوب (config_disableApksUnlessMatchedSku_apk_list و config_disableApkUnlessMatchedSku_skus_list) منسوخ و حذف کرد. برای جزئیات، به aosp/3444399 مراجعه کنید.

جایگزین توصیه‌شده استفاده از پیکربندی سیستم install-in-user-type در دایرکتوری‌های مختص واحد نگهداری کالا است. این رویکرد از نصب شدن بسته برای هر کاربری در SKU خاص جلوگیری می‌کند، به‌جای اینکه فقط آن را پس‌از نصب غیرفعال کند.

1. همه فایل‌های APK (مجموعه فرابالای همه برنامه‌های بالقوه برای همه واحدهای نگهداری کالا در تصویر سیستم) را در تصویر، معمولاً در پارتیشن /product، بگنجانید.

2. مطمئن شوید «واحد نگهداری موجودی» دستگاه در ro.boot.hardware.sku سیستم دارایی (که سیستم برای شناسایی «واحد نگهداری موجودی» دستگاه در زمان راه‌اندازی استفاده می‌کند) به‌درستی تنظیم شده باشد.

3. زیرفهرست‌های راهنمای sysconfig مختص SKU را در /product/etc/sysconfig/ بااستفاده از قرارداد نام‌گذاری sku_<SKU_NAME> ایجاد کنید. سیستم به‌طور خودکار پیکربندی‌ها را از دایرکتوری‌ای که با دارایی ro.boot.hardware.sku مطابقت دارد بار می‌کند. مسیر نمونه: /product/etc/sysconfig/sku_basic_model/.

4. پیکربندی جلوگیری از نصب برنامه. در فهرست راهنمای مختص «واحد نگهداری کالا»، فایل پیکربندی XML (برای مثال، disabled_apps.xml) ایجاد کنید و از برچسب <do-not-install-in> برای مستثنا کردن بسته‌های خاص استفاده کنید.

نمونه XML‏ (/product/etc/sysconfig/sku_basic_model/disabled_apps.xml):

<?xml version="1.0" encoding="utf-8"?>
<config>
    <!-- Prevents this package from being installed for ANY user on this SKU -->
    <install-in-user-type package="com.example.premium.feature.app" >
        <do-not-install-in user-type="FULL" />
        <do-not-install-in user-type="SYSTEM" />
    </install-in-user-type>
</config>

در اینجا مقایسه‌ای از این دو روش ارائه شده است:

برای مواردی که نیاز به کنترل دقیق‌تری دارند (یعنی غیرفعال کردن برنامه‌ای که معمولاً به‌طور پیش‌فرض در همه واحدهای نگهداری موجودی نصب می‌شود)، Android از برچسب‌های disabled-in-sku و enabled-in-sku-override در sysconfig نیز پشتیبانی می‌کند:

• ‫<disabled-in-sku package="com.example.app" /> برنامه را در سطح جهانی غیرفعال می‌کند.

• <enabled-in-sku-override package="com.example.app" /> وقتی در فهرست راهنمای sku_<name> مربوطه قرار می‌گیرد، برنامه را برای واحد نگهداری کالای خاصی دوباره فعال می‌کند.

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

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

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

اگر پیکربندی دقیق لازم است، به‌جای تکیه کردن بر RRO خودکار تولیدشده، آن را به‌صورت دستی تعریف کنید. برای اطلاعات دقیق، به تغییر مقدار منابع برنامه در زمان اجرا مراجعه کنید. تولیدکنندگان اصلی سخت‌افزار همچنین می‌توانند هم‌پوشانی‌های منبع زمان اجرای شرطی را که به ویژگی‌های سیستم بستگی دارند بااستفاده از مشخصه‌های android:requiredSystemPropertyName و android:requiredSystemPropertyValue تعریف کنند.

پرسشگان

در زیر پرسش‌های متداول درباره SSI آمده است.

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

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

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

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