این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

چرخه عمر 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‌هایی را فهرست کند که نسبت به FC مربوط به V کاملاً جدیدتر هستند.
HAL های دستگاه: HALهایی که در مانیفست دستگاه فهرست شده (ارائه شده) و در ماتریس سازگاری چارچوب (FCM) (الزامی یا اختیاری) فهرست شده اند.
ماتریس سازگاری دستگاه (DCM): یک فایل XML که الزامات فروشنده را در مورد پیاده سازی چارچوب منطبق مشخص می کند. هر دستگاه حاوی یک DCM است.
مانیفست چارچوب: یک فایل XML که مشخص می‌کند کدام نسخه‌های HAL در سمت چارچوب رابط فروشنده، شامل system، system_ext و تصاویر محصول ارائه می‌شود. HAL ها در مانیفست چارچوب به صورت پویا با توجه به نسخه Target FCM دستگاه غیرفعال می شوند.
HAL های چارچوب: HALهایی که در مانیفست فریمورک ارائه شده و به عنوان الزامی یا اختیاری در ماتریس سازگاری دستگاه (DCM) فهرست شده‌اند.

چرخه حیات FCM در پایگاه کد

این سند چرخه حیات FCM را به صورت انتزاعی توصیف می کند. برای دیدن مانیفست های پشتیبانی شده، به hardware/interfaces/compatibility_matrix.<FCM>.xml که در آن FCM را می توان در system/libvintf/include/vintf/Level.h پیدا کرد.

انتظار می‌رود دستگاهی که نسخه منتشرشده Android مربوطه را ارسال می‌کند دارای مقدار FCM بزرگتر یا مساوی با سطح معادل باشد. به عنوان مثال، دستگاهی که با Android 11 ارسال می‌شود، عموماً دارای سطح FCM 5 است، اما سطح FCM 6 یا بالاتر را پیاده‌سازی می‌کند، که با الزامات اضافی مختلف مشخص شده در ماتریس‌های سازگاری همراه است. سطوح پشتیبانی شده عبارتند از:

FCM	نسخه اندروید
4	Android 10/Q
5	اندروید 11/R
6	اندروید 12/S
7	اندروید 13/T
8	اندروید 14/U
202404	اندروید 15/V

سطح FCM برابر یا جدیدتر از سطح API Vendor است.

وقتی Android سطح FCM را منسوخ می‌کند، همچنان برای دستگاه‌های موجود پشتیبانی می‌شود. دستگاه هایی که سطوح پایین تر FCM را هدف قرار می دهند به طور ضمنی مجاز به استفاده از HAL های فهرست شده در سطوح جدیدتر FCM هستند، تا زمانی که در شعبه موجود باشند.

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

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

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

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

یک HAL جدید معرفی کنید

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

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

به عنوان مثال، اندروید 8.1 cas@1.0 به عنوان یک HAL اختیاری معرفی کرد. دستگاه‌هایی که با Android 8.1 راه‌اندازی می‌شوند برای اجرای این HAL مورد نیاز نیستند، بنابراین ورودی زیر به compatibility_matrix.F.xml اضافه شد (که قبلاً در طول توسعه آن نسخه به طور موقت compatibility_matrix.current.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.F.xml باید x.(z+1) و optional="false" را ذکر کند.
در دستگاه‌هایی که با V = F راه‌اندازی می‌شوند لازم نیست، compatibility_matrix.F.xml باید xy-z و اختیاری را از compatibility_matrix.<F-1>.xml و نسخه را به xw-(z+1) تغییر دهید (جایی که w >= y ).

به عنوان مثال، اندروید 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.F.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.F.xml اضافه می‌شود:

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

به عنوان مثال، اندروید 9 health@2.0 به عنوان نسخه اصلی ارتقاء 1.0 HAL معرفی می کند و 1.0 HAL را منسوخ می کند. نسخه قدیمی‌تر health@1.0 ، برای دستگاه‌هایی که با Android 8.0 و Android 8.1 راه‌اندازی می‌شوند اختیاری است. دستگاه هایی که با اندروید 9 راه اندازی می شوند باید نسخه 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.F.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 انجام می شود و شامل مراحل زیر است:

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

به عنوان مثال، آزمایش‌های 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 فهرست کند.

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

حذف پشتیبانی از نسخه های 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.F.xml هستند. مثال ها:

در طول توسعه Android 9 health@2.0 HAL یک HAL منتشر نشده در نظر گرفته شد و فقط در compatibility_matrix.3.xml وجود داشت.
teleportation@1.0 HAL در هیچ یک از ماتریس‌های سازگاری منتشر نشده وجود ندارد و همچنین یک HAL منتشر نشده در نظر گرفته می‌شود.

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

منتشر شده و جاری

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

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

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

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

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

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

مثال ها:

health@1.0 HAL در compatibility_matrix.legacy.xml ، compatibility_matrix.1.xml و compatibility_matrix.2.xml است، اما در compatibility_matrix.3.xml نیست. از این رو در اندروید 9 منسوخ تلقی می شود.
Power HAL دارای یک ارتقاء نسخه جزئی در Android 9 است، اما power@1.0 هنوز در compatibility_matrix.3.xml است.
power@1.0 compatibility_matrix.legacy.xml ، compatibility_matrix.1.xml ، و compatibility_matrix.2.xml .
compatibility_matrix.3.xml دارای power@1.0-1 است.

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

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

حذف شد

برای دستگاه‌های 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 مراجعه کنید.

اصطلاحات

ماتریس سازگاری چارچوب (FCM): یک فایل XML که الزامات چارچوب را در مورد پیاده سازی فروشنده مطابقت مشخص می کند. ماتریس سازگاری نسخه شده است و یک نسخه جدید برای هر نسخه فریمورک ثابت می شود. هر نسخه فریم ورک حاوی چندین FCM است.
نسخه های FCM Platform (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‌هایی را فهرست کند که نسبت به FC مربوط به V کاملاً جدیدتر هستند.
HAL های دستگاه: HALهایی که در مانیفست دستگاه فهرست شده (ارائه شده) و در ماتریس سازگاری چارچوب (FCM) (الزامی یا اختیاری) فهرست شده اند.
ماتریس سازگاری دستگاه (DCM): یک فایل XML که الزامات فروشنده را در مورد پیاده سازی چارچوب منطبق مشخص می کند. هر دستگاه حاوی یک DCM است.
مانیفست چارچوب: یک فایل XML که مشخص می‌کند کدام نسخه‌های HAL در سمت چارچوب رابط فروشنده، شامل system، system_ext و تصاویر محصول ارائه می‌شود. HAL ها در مانیفست چارچوب به صورت پویا با توجه به نسخه Target FCM دستگاه غیرفعال می شوند.
HAL های چارچوب: HALهایی که در مانیفست فریمورک ارائه شده و به عنوان الزامی یا اختیاری در ماتریس سازگاری دستگاه (DCM) فهرست شده‌اند.

چرخه حیات FCM در پایگاه کد

FCM	نسخه اندروید
4	Android 10/Q
5	اندروید 11/R
6	اندروید 12/S
7	اندروید 13/T
8	اندروید 14/U
202404	اندروید 15/V

سطح FCM برابر یا جدیدتر از سطح API Vendor است.

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

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

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

یک HAL جدید معرفی کنید

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

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

<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.F.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 (عمده)

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

<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.F.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

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

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

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

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

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

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

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

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

وضعیت نسخه HAL

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

منتشر نشده

در طول توسعه Android 9 health@2.0 HAL یک HAL منتشر نشده در نظر گرفته شد و فقط در compatibility_matrix.3.xml وجود داشت.
teleportation@1.0 HAL در هیچ یک از ماتریس‌های سازگاری منتشر نشده وجود ندارد و همچنین یک HAL منتشر نشده در نظر گرفته می‌شود.

منتشر شده و جاری

برای HAL های دستگاه، اگر نسخه HAL در هر ماتریس سازگاری عمومی و ثابت باشد، منتشر می شود. به عنوان مثال ، پس از اینکه FCM نسخه 3 منجمد شده و به AOSP منتشر می شود ، health@2.0 HAL یک نسخه HAL منتشر و فعلی در نظر گرفته می شود.

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

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

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

مثال ها:

health@1.0 HAL در compatibility_matrix.legacy.xml ، compatibility_matrix.1.xml و compatibility_matrix.2.xml است، اما در compatibility_matrix.3.xml نیست. از این رو در اندروید 9 منسوخ تلقی می شود.
Power HAL دارای یک ارتقاء نسخه جزئی در Android 9 است، اما power@1.0 هنوز در compatibility_matrix.3.xml است.
power@1.0 compatibility_matrix.legacy.xml ، compatibility_matrix.1.xml ، و compatibility_matrix.2.xml .
compatibility_matrix.3.xml دارای power@1.0-1 است.

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

حذف شد

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

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

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

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

FCM های قدیمی

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

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

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