تصویر سیستم مشترک

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

پیشینه

چارچوب پروژه متن‌باز اندروید (AOSP) با معماری Mainline مطابقت دارد تا سازگاری با پیاده‌سازی‌های قدیمی‌تر فروشندگان را حفظ کند. به عنوان مثال، یک تصویر سیستم عمومی (GSI) که از منابع AOSP اندروید ۱۰ ساخته شده است، می‌تواند روی هر دستگاه سازگار با Treble که اندروید ۸ یا بالاتر را اجرا می‌کند، اجرا شود.

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

از نظر تاریخی، فروشندگان SoC و تولیدکنندگان اصلی تجهیزات (OEM) نسخه چارچوب اندروید عرضه شده روی دستگاه‌های مصرف‌کننده را به شدت اصلاح می‌کردند (برای جزئیات بیشتر، به بخش «زندگی یک نسخه اندروید » مراجعه کنید). از آنجا که این افزونه‌های چارچوب به ندرت با در نظر گرفتن سازگاری با نسخه‌های قبلی طراحی می‌شدند، اصلاحات مختص دستگاه به طور چشمگیری پیچیدگی و هزینه مالی ارتقاءهای بعدی سیستم عامل را افزایش می‌داد. در اندروید ۱۰ (سطح API ۲۹) و پایین‌تر، اکوسیستم فاقد یک معماری استاندارد و واضح بود که به شرکا اجازه دهد افزونه‌های ماژولار را برای چارچوب اندروید بسازند.

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

برای جزئیات پیاده‌سازی، به مراحل پیشنهادی برای SSI مبتنی بر GSI مراجعه کنید. مراحل ماژولار هستند؛ بسته به معماری شما، می‌توانید به جای همه مراحل، مراحل خاصی را پیاده‌سازی کنید (مانند مرحله 1: Inherit generic_system.mk for OEM system image (OEM GSI) ).

مرور کلی SSI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

پارتیشن /system_ext

پارتیشن /system_ext اختیاری است. از این پارتیشن برای هرگونه ویژگی و افزونه سفارشی که به طور تنگاتنگی با اجزای مبتنی بر AOSP جفت شده‌اند، استفاده کنید. این پارتیشن به عنوان افزونه مخصوص 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 متمرکز کنید.

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

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

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

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

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

فعال کردن SSI

این بخش نحوه پشتیبانی از SSI در اندروید ۱۱ و بالاتر را توضیح می‌دهد.

اجزای جدا شده

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

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

رابط‌های محصول را تقویت کنید

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

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

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

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

تولیدکنندگان اصلی تجهیزات (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 GSI) به ارث ببرید.

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

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

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

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

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

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

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

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

شکل ۵. تعریف allowlist برای کاهش فهرست فایل‌های اصلاح‌شده در OEM GSI.

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

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

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

تعریف SSI

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

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

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

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

پارتیشن /system_ext را به صورت عمومی (common) درآورید.

پارتیشن /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) می‌توانند در تعریف APIهای سیستمی جدید برای دستگاه‌های خود به AOSP کمک کنند.

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

غیرفعال کردن برنامه خاص SKU را جایگزین کنید

اندروید ۱۶ مکانیزم قدیمی غیرفعال کردن انتخابی APKها بر اساس SKU سخت‌افزاری با استفاده از همپوشانی‌های منابع چارچوب ( config_disableApksUnlessMatchedSku_apk_list و config_disableApkUnlessMatchedSku_skus_list ) را منسوخ و حذف کرد. برای جزئیات بیشتر، به aosp/3444399 مراجعه کنید.

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

1. تمام APKها (مجموعه‌ای از تمام برنامه‌های بالقوه برای تمام SKUهای موجود در ایمیج سیستم شما) را در ایمیج، معمولاً در پارتیشن /product ، قرار دهید.

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

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

4. پیکربندی جلوگیری از نصب برنامه. در داخل دایرکتوری مخصوص SKU، یک فایل پیکربندی 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>

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

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

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

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

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

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

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

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

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

سوالات متداول در مورد SSI به شرح زیر است.

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

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

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

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