چرخه حیات FCM

با مجموعه‌ها، منظم بمانید ذخیره و دسته‌بندی محتوا براساس اولویت‌های شما.

یک نسخه فریم ورک اندروید دارای چندین ماتریس سازگاری چارچوب (FCM) است - یکی برای هر نسخه Target FCM قابل ارتقا - که مشخص می کند چارچوب ممکن است از چه چیزی استفاده کند و مورد نیاز نسخه FCM هدف. به عنوان بخشی از چرخه حیات FCM، Android HIDL HAL ها را منسوخ و حذف می کند، سپس فایل های FCM را تغییر می دهد تا وضعیت نسخه HAL را منعکس کند.

برای فعال کردن OTA های فقط چارچوب در اکوسیستم های خود، شرکای که رابط های فروشنده را گسترش می دهند نیز باید HIDL HAL ها را با استفاده از همان روش ها منسوخ و حذف کنند.

واژه شناسی

ماتریس سازگاری چارچوب (FCM) یک فایل XML که الزامات چارچوب را در مورد پیاده سازی فروشنده مطابقت مشخص می کند. ماتریس سازگاری نسخه شده است و یک نسخه جدید برای هر نسخه فریمورک ثابت می شود. هر نسخه فریم ورک حاوی چندین FCM است.
نسخه‌های FCM پلتفرم (S F ) مجموعه ای از تمام نسخه های FCM در یک نسخه فریمورک. این چارچوب می تواند با هر پیاده سازی فروشنده ای که یکی از این FCM ها را برآورده کند، کار کند.
نسخه FCM (F) بالاترین نسخه در بین تمام FCM ها در یک نسخه فریمورک.
نسخه FCM هدف (V) نسخه FCM هدفمند (از S F ) که به صراحت در مانیفست دستگاه اعلام شده است که اجرای یک فروشنده آن را برآورده می کند. یک پیاده سازی فروشنده باید در برابر یک FCM منتشر شده ایجاد شود، اگرچه ممکن است نسخه های جدیدتر HAL را در مانیفست دستگاه خود اعلام کند.
نسخه HAL یک نسخه HAL دارای فرمت foo@xy است که foo نام HAL و xy نسخه خاص است. به عنوان مثال nfc@1.0 ، keymaster@3.0 (پیشوند ریشه، به عنوان مثال android.hardware ، در سراسر این سند حذف شده است.)
مانیفست دستگاه فایل‌های XML که مشخص می‌کنند کدام نسخه‌های HAL را در سمت دستگاه رابط فروشنده، از جمله فروشنده و تصاویر ODM، ارائه می‌دهد. محتویات مانیفست دستگاه توسط نسخه Target FCM دستگاه محدود شده است، اما می‌تواند HAL‌هایی را فهرست کند که نسبت به FCM مربوط به V کاملاً جدیدتر هستند.
HAL های دستگاه HAL هایی که در مانیفست دستگاه فهرست شده (ارائه شده) و در ماتریس سازگاری چارچوب (FCM) (الزامی یا اختیاری) فهرست شده اند.
ماتریس سازگاری دستگاه (DCM) یک فایل XML که الزامات فروشنده را در مورد پیاده سازی چارچوب منطبق مشخص می کند. هر دستگاه حاوی یک DCM است.
مانیفست چارچوب یک فایل XML که مشخص می‌کند کدام نسخه‌های HAL در سمت چارچوب رابط فروشنده، شامل system، system_ext و تصاویر محصول ارائه می‌شود. HAL ها در مانیفست چارچوب به صورت پویا با توجه به نسخه Target FCM دستگاه غیرفعال می شوند.
HAL های چارچوب HAL هایی که در مانیفست فریمورک ارائه شده و به عنوان الزامی یا اختیاری در ماتریس سازگاری دستگاه (DCM) فهرست شده اند.

در حال توسعه در نسخه جدید FCM

اندروید نسخه FCM را برای هر نسخه فریم ورک (مانند اندروید 8، 8.1 و غیره) افزایش می دهد. در طول توسعه، compatibility_matrix.current.xml جدید ایجاد می‌شود ( F ) و compatibility_matrix.f.xml موجود (جایی که f < F ) دیگر تغییر نمی‌کند.

برای شروع توسعه در FCM نسخه F جدید:

  1. آخرین compatibility_matrix.<F-1>.xml را در compatibility_matrix.current.xml کپی کنید.
  2. ویژگی level فایل را به F به روز کنید.
  3. قوانین ساخت مربوطه را برای نصب این ماتریس سازگاری در دستگاه اضافه کنید.

معرفی HAL جدید

در طول توسعه، هنگام معرفی یک HAL جدید (Wi-Fi، NFC، و غیره) به Android در نسخه F فعلی FCM، HAL را با تنظیمات optional زیر به compatibility_matrix.current.xml اضافه کنید:

  • optional="false" اگر دستگاه هایی که با V = F ارسال می شوند باید با این HAL راه اندازی شوند،

    یا
  • optional="true" اگر دستگاه هایی که با V = F ارسال می شوند می توانند بدون این HAL راه اندازی شوند.

به عنوان مثال، اندروید 8.1 cas@1.0 را به عنوان یک HAL اختیاری معرفی کرد. دستگاه‌هایی که با Android 8.1 راه‌اندازی می‌شوند برای اجرای این HAL مورد نیاز نیستند، بنابراین ورودی زیر به compatibility_matrix.current.xml اضافه شد (پس از انتشار Android 8.1 به compatibility_matrix.2.xml تغییر نام داد):

<hal format="hidl" optional="true">
    <name>android.hardware.cas</name>
    <version>1.0</version>
    <interface>
        <name>IMediaCasService</name>
        <instance>default</instance>
    </interface>
</hal>

ارتقاء HAL (کوچک)

در طول توسعه، هنگامی که یک HAL دارای یک ارتقاء نسخه جزئی از xz به x.(z+1) در نسخه فعلی FCM F است، اگر آن نسخه:

  • در دستگاه‌هایی که با V = F راه‌اندازی می‌شوند، compatibility_matrix.current.xml باید x.(z+1) و optional="false" را ذکر کند.
  • در دستگاه‌هایی که با V = F راه‌اندازی می‌شوند لازم نیست، compatibility_matrix.current.xml باید xy-z و اختیاری را از compatibility_matrix.<F-1>.xml و نسخه را به xw-(z+1) تغییر دهد (جایی که w >= y ).

به عنوان مثال، Android 8.1 broadcastradio@1.1 به عنوان یک ارتقاء جزئی نسخه 1.0 HAL معرفی کرد. نسخه قدیمی تر، broadcastradio@1.0 ، برای دستگاه هایی که با Android 8.0 راه اندازی می شوند اختیاری است، در حالی که نسخه جدیدتر، broadcastradio@1.1 ، برای دستگاه هایی که با Android 8.1 راه اندازی می شوند اختیاری است. در compatibility_matrix.1.xml :

<hal format="hidl" optional="true">
    <name>android.hardware.broadcastradio</name>
    <version>1.0</version>
    <interface>
        <name>IBroadcastRadioFactory</name>
        <instance>default</instance>
    </interface>
</hal>

این ورودی در compatibility_matrix.2.xml (پس از انتشار اندروید 8.1 به compatibility_matrix.current.xml تغییر نام داد) کپی شد و به شرح زیر اصلاح شد:

<hal format="hidl" optional="true">
    <name>android.hardware.broadcastradio</name>
    <version>1.0-1</version>
    <interface>
        <name>IBroadcastRadioFactory</name>
        <instance>default</instance>
    </interface>
</hal>

ارتقاء یک HAL (عمده)

در طول توسعه، هنگامی که یک HAL دارای یک ارتقاء نسخه اصلی در FCM نسخه F فعلی است، نسخه اصلی جدید x.0 با تنظیمات optional زیر به compatibility_matrix.current.xml اضافه می‌شود:

  • optional="false" فقط با نسخه x.0 ، اگر دستگاه هایی که با V = F عرضه می شوند باید با x.0 راه اندازی شوند.
  • optional="false" اما همراه با نسخه های اصلی قدیمی در همان تگ <hal> ، اگر دستگاه هایی که با V = F عرضه می شوند باید با این HAL راه اندازی شوند، اما می توانند با نسخه اصلی قدیمی تر راه اندازی شوند.
  • optional="true" اگر دستگاه هایی که با V = F ارسال می شوند مجبور نباشند HAL را راه اندازی کنند.

به عنوان مثال، Android 9 health@2.0 را به عنوان نسخه اصلی ارتقاء 1.0 HAL معرفی می کند و 1.0 HAL را منسوخ می کند. نسخه قدیمی‌تر health@1.0 ، برای دستگاه‌هایی که با Android 8.0 و Android 8.1 راه‌اندازی می‌شوند اختیاری است. دستگاه‌هایی که با Android 9 راه‌اندازی می‌شوند نباید HAL 1.0 منسوخ را ارائه کنند و در عوض باید نسخه جدید 2.0 را ارائه کنند. در compatibility_matrix.legacy.xml ، compatibility_matrix.1.xml ، و compatibility_matrix.2.xml :

<hal format="hidl" optional="true">
    <name>android.hardware.health</name>
    <version>1.0</version>
    <interface>
        <name>IHealth</name>
        <instance>default</instance>
    </interface>
</hal>

این ورودی در compatibility_matrix.3.xml (با نسخه اندروید 9 به compatibility_matrix.current.xml تغییر نام داده) کپی شده و به شرح زیر اصلاح شده است:

<hal format="hidl" optional="false">
    <name>android.hardware.health</name>
    <version>2.0</version>
    <interface>
        <name>IHealth</name>
        <instance>default</instance>
    </interface>
</hal>

محدودیت های:

  • از آنجایی که 2.0 HAL در compatibility_matrix.3.xml با optional="false" است، دستگاه هایی که با Android 9 راه اندازی می شوند باید با 2.0 HAL عرضه شوند.
  • از آنجایی که 1.0 HAL در compatibility_matrix.3.xml نیست، دستگاه‌هایی که با Android 9 راه‌اندازی می‌شوند نباید 1.0 HAL را ارائه کنند (زیرا این HAL منسوخ شده در نظر گرفته می‌شود).
  • از آنجایی که 1.0 HAL در legacy/1/2.xml (نسخه‌های قدیمی‌تر FCM که Android 9 می‌تواند با آن کار کند) به‌عنوان یک HAL اختیاری وجود دارد، چارچوب Android 9 همچنان می‌تواند با 1.0 HAL (که نسخه HAL حذف شده در نظر گرفته نمی‌شود) کار کند. ).

نسخه های جدید FCM

فرآیند انتشار نسخه FCM در پارتیشن سیستم صرفاً توسط Google به عنوان بخشی از نسخه AOSP انجام می شود و شامل مراحل زیر است:

  1. نام compatibility_matrix.current.xml را به compatibility_matrix.F.xml تغییر دهید.
  2. مطمئن شوید که فایل دارای ویژگی level="F" است.
  3. قوانین ساخت مربوطه را ویرایش کنید تا تغییر نام فایل را منعکس کند.
  4. اطمینان حاصل کنید که همه دستگاه ها ساخته و راه اندازی می شوند.
  5. تست‌های VTS را به‌روزرسانی کنید تا مطمئن شوید دستگاه‌هایی که با آخرین چارچوب راه‌اندازی می‌شوند (بر اساس سطح API حمل‌ونقل) دارای Target FCM نسخه V >= F هستند.
  6. فایل را در AOSP منتشر کنید.

این فایل پس از تغییر نام و انتشار قابل تغییر نیست . به عنوان مثال، در طول توسعه اندروید 9، فایل‌های زیر برای hardware/interfaces/compatibility_matrices/ ساخته می‌شوند:

  • compatibility_matrix.legacy.xml
  • compatibility_matrix.1.xml
  • compatibility_matrix.2.xml
  • compatibility_matrix.current.xml

وقتی Android 9 منتشر شد، compatibility_matrix.current.xml به compatibility_matrix.3.xml تغییر نام داد و فایل‌های زیر برای hardware/interfaces/compatibility_matrices/ ساخته می‌شوند:

  • compatibility_matrix.legacy.xml
  • compatibility_matrix.1.xml
  • compatibility_matrix.2.xml
  • compatibility_matrix.3.xml

تست‌های VTS اطمینان می‌دهند که دستگاه‌هایی که با Android 9 راه‌اندازی می‌شوند دارای Target FCM نسخه >= 3 هستند.

علاوه بر این، FCMهای product و system_ext ممکن است الزامات هر نسخه FCM پلتفرمی را فهرست کنند. انتشار نسخه های FCM بر روی پارتیشن های product و system_ext به ترتیب توسط صاحب این تصاویر انجام می شود. شماره‌های نسخه FCM روی پارتیشن‌های product و system_ext باید با پارتیشن‌های سیستم هماهنگ باشند. مشابه نسخه‌های FCM در پارتیشن سیستم، ماتریس سازگاری در FCM نسخه F در پارتیشن‌های product و system_ext نیازمندی‌های دستگاهی با هدف FCM نسخه F را منعکس می‌کند.

منسوخ شدن نسخه HAL

منسوخ کردن نسخه HAL یک تصمیم توسعه دهنده است (یعنی برای HAL های AOSP، Google تصمیم می گیرد). این ممکن است زمانی اتفاق بیفتد که یک نسخه HAL بالاتر (چه جزئی یا اصلی) منتشر شود.

یک دستگاه HAL را منسوخ کنید

هنگامی که یک دستگاه HAL foo@xy در FCM نسخه F منسوخ می شود، به این معنی است که هر دستگاهی که با Target FCM نسخه V = F یا جدیدتر راه اندازی می شود، نباید foo را در نسخه xy یا هر نسخه قدیمی تر از xy اجرا کند. یک نسخه HAL منسوخ شده همچنان توسط چارچوب برای ارتقاء دستگاه ها پشتیبانی می شود.

هنگامی که FCM نسخه F منتشر می شود، اگر نسخه HAL خاص به صراحت در آخرین FCM برای Target FCM نسخه V = F ذکر نشده باشد، یک نسخه HAL foo@xy منسوخ تلقی می شود. برای دستگاه هایی که با V = F راه اندازی می شوند، یکی از شرایط زیر صادق است:

  • چارچوب نیاز به یک نسخه بالاتر (مهم یا جزئی) دارد.
  • چارچوب دیگر به HAL نیاز ندارد.

به عنوان مثال، در اندروید 9، health@2.0 به عنوان نسخه اصلی ارتقاء 1.0 HAL معرفی شده است. health@1.0 از compatibility_matrix.3.xml حذف شده است اما در compatibility_matrix.legacy.xml ، compatibility_matrix.1.xml و compatibility_matrix.2.xml موجود است. بنابراین، health@1.0 منسوخ در نظر گرفته می شود.

یک چارچوب HAL را منسوخ کنید

هنگامی که یک چارچوب معین HAL foo@xy در FCM نسخه F منسوخ می شود، به این معنی است که هر دستگاهی که با Target FCM نسخه V = F یا جدیدتر راه اندازی می شود، نباید انتظار داشته باشد که چارچوب در نسخه xy یا هر نسخه قدیمی تر از xy ، foo را ارائه کند. یک نسخه HAL منسوخ شده هنوز توسط چارچوب برای ارتقاء دستگاه ها ارائه می شود.

هنگامی که نسخه F FCM منتشر می شود، اگر مانیفست چارچوب max-level=" F - 1 " را برای foo@xy مشخص کند، یک نسخه HAL foo@xy منسوخ در نظر گرفته می شود. برای دستگاه هایی که با V = F راه اندازی می شوند، چارچوب HAL foo@xy را ارائه نمی دهد. ماتریس سازگاری دستگاه در دستگاه‌هایی که با V = F راه‌اندازی می‌شوند نباید HAL‌های چارچوب را با max-level < V فهرست کند.

به عنوان مثال، در اندروید 12، schedulerservice@1.0 منسوخ شده است. ویژگی max-level آن روی 5 تنظیم شده است، نسخه FCM که در اندروید 11 معرفی شده است. به مانیفست چارچوب Android 12 مراجعه کنید.

حذف پشتیبانی از نسخه های Target FCM

هنگامی که دستگاه‌های فعال یک Target FCM نسخه V به زیر یک آستانه خاص می‌رسند، نسخه Target FCM از مجموعه S F نسخه بعدی چارچوب حذف می‌شود. این کار با هر دو مرحله زیر انجام می شود:

  • حذف compatibility_matrix.V.xml از قوانین ساخت (به طوری که روی تصویر سیستم نصب نشود)، و حذف هر کدی که اجرا شده یا به عملکرد حذف شده بستگی دارد.
  • حذف HAL ​​های چارچوب با max-level کمتر یا مساوی با V از مانیفست چارچوب، و حذف هر کدی که HAL های چارچوب حذف شده را پیاده سازی می کند.

دستگاه‌هایی با نسخه FCM هدف خارج از S F برای یک نسخه چارچوب معین، نمی‌توانند به آن نسخه ارتقا دهند.

وضعیت نسخه HAL

بخش‌های زیر (به ترتیب زمانی) وضعیت‌های احتمالی یک نسخه HAL را شرح می‌دهند.

منتشر نشده

برای HAL های دستگاه، اگر نسخه HAL در هیچ یک از ماتریس های سازگاری عمومی و ثابت نباشد، منتشر نشده و احتمالاً در حال توسعه در نظر گرفته می شود. این شامل نسخه‌های HAL است که فقط در compatibility_matrix.current.xml هستند. مثال ها:

  • در طول توسعه Android 9 (قبل از اینکه compatibiility_matrix.current.xml compatibility_matrix.3.xml نام دهد)، health@2.0 HAL یک HAL منتشرنشده در نظر گرفته شد.
  • teleportation@1.0 HAL در هیچ ماتریس سازگاری منتشر شده نیست و همچنین یک HAL منتشر نشده در نظر گرفته می شود.

برای چارچوب‌های HAL، اگر نسخه HAL فقط در مانیفست چارچوب یک شاخه توسعه نامرتبط باشد، منتشر نشده در نظر گرفته می‌شود.

منتشر شده و فعلی

برای HAL های دستگاه، اگر نسخه HAL در هر ماتریس سازگاری عمومی و ثابت باشد، منتشر می شود. به عنوان مثال، پس از مسدود شدن FCM نسخه 3 (زمانی که compatibiility_matrix.current.xml به compatibility_matrix.3.xml تغییر نام داد) و به AOSP منتشر شد، health@2.0 HAL نسخه HAL منتشر شده و فعلی در نظر گرفته می شود.

اگر یک نسخه HAL در یک ماتریس سازگاری عمومی و ثابت است که دارای بالاترین نسخه FCM است (به استثنای compatibility_matrix.current.xml )، نسخه HAL فعلی است (یعنی منسوخ نشده است). برای مثال، نسخه‌های HAL موجود (مانند nfc@1.0 معرفی‌شده در compatibility_matrix.legacy.xml ) که همچنان در compatibility_matrix.3.xml وجود دارند نیز به‌عنوان نسخه‌های HAL منتشر شده و فعلی در نظر گرفته می‌شوند.

برای HAL های چارچوب، اگر یک نسخه HAL در مانیفست چارچوب آخرین شعبه منتشر شده بدون ویژگی max-level یا (به طور غیرمعمول) max-level برابر یا بالاتر از نسخه FCM منتشر شده در این شاخه باشد، نسخه منتشر شده در نظر گرفته می شود. و نسخه فعلی HAL. به عنوان مثال، displayservice HAL در اندروید 12 منتشر شده و در حال حاضر مطابق با مشخص شده است Android 12framework manifest .

منتشر شد اما منسوخ شد

برای دستگاه‌های HAL، نسخه HAL منسوخ می‌شود اگر و فقط در صورتی که همه موارد زیر رعایت شود:

  • منتشر می شود.
  • در ماتریس سازگاری عمومی و منجمد نیست که بالاترین نسخه FCM را دارد.
  • این فریم ورک همچنان در یک ماتریس سازگاری عمومی و منجمد است.

مثال ها:

بنابراین power@1.0 در Android 9 فعلی است، اما منسوخ نشده است.

برای HAL های چارچوب، اگر یک نسخه HAL در مانیفست چارچوب آخرین شعبه منتشر شده با ویژگی max-level پایین تر از نسخه FCM منتشر شده در این شاخه باشد، نسخه HAL منتشر شده اما منسوخ شده در نظر گرفته می شود. به عنوان مثال، schedulerservice سرویس HAL منتشر شده است اما در Android 12 منسوخ شده است، همانطور که توسط Android 12framework manifest .

حذف شده

برای HAL های دستگاه، یک نسخه HAL حذف می شود اگر و فقط در صورتی که موارد زیر درست باشد:

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

ماتریس‌های سازگاری که عمومی هستند، ثابت هستند، اما توسط چارچوب پشتیبانی نمی‌شوند، در پایه کد نگهداری می‌شوند تا مجموعه نسخه‌های حذف‌شده HAL را تعریف کنند تا بتوان تست‌های VTS را نوشت تا مطمئن شود HAL‌های حذف‌شده در دستگاه‌های جدید نیستند.

برای HAL های چارچوب، یک نسخه HAL حذف می شود اگر و فقط در صورت رعایت موارد زیر:

  • قبلا منتشر شده بود.
  • این در هیچ چارچوبی از آخرین شعبه منتشر شده نیست.

FCM های قدیمی

میراث نسخه FCM هدف یک ارزش ویژه برای همه دستگاه‌های غیر تربل است. FCM قدیمی، compatibility_matrix.legacy.xml ، الزامات چارچوب را در دستگاه‌های قدیمی (یعنی دستگاه‌هایی که قبل از Android 8.0 راه‌اندازی شده‌اند) فهرست می‌کند.

اگر این فایل برای FCM با نسخه F وجود داشته باشد، هر دستگاه غیر Treble را می توان به F ارتقا داد، مشروط بر اینکه مانیفست دستگاه آن با این فایل سازگار باشد. حذف آن از همان روال FCM برای سایر نسخه‌های FCM هدف پیروی می‌کند (پس از کاهش تعداد دستگاه‌های فعال قبل از ۸.۰ به زیر یک آستانه خاص، حذف می‌شود).

نسخه های منتشر شده FCM

لیست نسخه‌های FCM منتشر شده را می‌توانید در بخش hardware/interfaces/compatibility_matrices پیدا کنید.

برای یافتن نسخه FCM منتشر شده با نسخه اندروید خاص، به Level.h مراجعه کنید.