چرخه عمر FCM

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

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

اصطلاحات

ماتریس سازگاری چارچوب (FCM)

یک فایل XML که الزامات چارچوب را در مورد پیاده‌سازی‌های منطبق با فروشندگان مشخص می‌کند. ماتریس سازگاری نسخه‌بندی شده است و برای هر نسخه چارچوب، نسخه جدیدی ثابت می‌شود. هر نسخه چارچوب شامل چندین FCM است.

نسخه‌های FCM پلتفرم ( _SF )

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

نسخه FCM (F)

بالاترین نسخه در بین تمام FCMها در یک نسخه فریم‌ورک.

نسخه FCM هدف (V)

نسخه FCM مورد نظر (از S _F )، که به صراحت در مانیفست دستگاه اعلام شده است، که پیاده‌سازی فروشنده آن را برآورده می‌کند. پیاده‌سازی فروشنده باید بر اساس یک FCM منتشر شده تولید شود، اگرچه ممکن است نسخه‌های جدیدتر 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_matrices/compatibility_matrix.<FCM>.xml مراجعه کنید، جایی که FCM را می‌توان در system/libvintf/include/vintf/Level.h یافت.

انتظار می‌رود دستگاهی که نسخه اندروید مربوطه را ارائه می‌دهد، مقدار FCM بزرگتر یا مساوی سطح معادل داشته باشد. به عنوان مثال، دستگاهی که با اندروید ۱۲ عرضه می‌شود، معمولاً FCM سطح ۶ خواهد داشت، اما می‌تواند FCM سطح ۷ یا بالاتر را نیز پیاده‌سازی کند که رفتار اندروید را تغییر می‌دهد و APIهای جدیدتر فروشندگان را مجبور می‌کند طبق آنچه در ماتریس‌های سازگاری مشخص شده است، استفاده شوند. سطوح پشتیبانی شده برای اندروید ۱۶ عبارتند از:

سطح FCM برابر یا جدیدتر از سطح API فروشنده است.

وقتی پروژه Treble اعلام شد، ایمیج‌های سیستم اندروید طوری ساخته شدند که با سه نسخه قبلی پیاده‌سازی‌های فروشندگان (در مجموع چهار نسخه) سازگار باشند. برای پشتیبانی از طول عمر بیشتر دستگاه، این بازه زمانی افزایش یافته است تا از نسخه فعلی و شش نسخه قبلی FCM (در مجموع هفت نسخه) برای 202404 و پس از آن پشتیبانی کند.

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

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

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

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

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

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

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

برای مثال، اندروید ۸.۱، cas@1.0 را معرفی کرد. دستگاه‌هایی که با اندروید ۸.۱ عرضه می‌شوند می‌توانند این HAL را پیاده‌سازی کنند، بنابراین ورودی زیر به compatibility_matrix.F.xml اضافه شد (که قبلاً در طول توسعه آن نسخه، به طور موقت compatibility_matrix.current.xml نامگذاری شده بود):

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

ارتقاء HAL (جزئی)

نسخه‌های AIDL HAL به عنوان نسخه‌های فرعی HAL محسوب می‌شوند. نسخه‌های رابط HIDL دارای major . minor مانند 1.2 هستند.

در طول توسعه، هنگامی که یک AIDL HAL در FCM نسخه F فعلی از 2 به 3 ارتقا می‌یابد، نسخه جدید به ورودی HAL در compatibility_matrix.F.xml اضافه می‌شود. فیلد نسخه یک ورودی HAL محدوده‌هایی مانند 2-3 را می‌پذیرد.

برای مثال، اندروید FCM F foo@3 را به عنوان یک نسخه ارتقا یافته جزئی از HAL معرفی کرد. نسخه قدیمی‌تر، foo@2 ، برای دستگاه‌هایی که FCMهای قدیمی‌تر را هدف قرار می‌دهند استفاده می‌شود در حالی که نسخه جدیدتر، foo@3 ، می‌تواند برای دستگاه‌هایی که FCMهای اندروید F را هدف قرار می‌دهند، استفاده شود. ورودی در FCMهای قدیمی‌تر قبل از نسخه 2 به این شکل است:

<hal format="aidl">
    <name>foo</name>
    <version>2</version>
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

این ورودی در compatibility_matrix.F.xml کپی شده و برای پشتیبانی از نسخه 3 به شرح زیر اصلاح شده است:

<hal format="aidl">
    <name>foo</name>
    <version>2-3</version>
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

ارتقاء HAL (رشته‌ای)

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

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

برای مثال، FCM نسخه F foo@2.0 را به عنوان یک ارتقاء نسخه اصلی از HAL نسخه 1.0 معرفی می‌کند و HAL نسخه 1.0 را منسوخ می‌کند. نسخه قدیمی‌تر، foo@1.0 ، برای دستگاه‌هایی که نسخه‌های قبلی FCM را هدف قرار می‌دهند، استفاده می‌شود. دستگاه‌هایی که FCM نسخه F را هدف قرار می‌دهند، در صورت ارائه HAL، باید نسخه جدید 2.0 را نیز ارائه دهند. در این مثال، نسخه‌های قبلی FCM شامل این ورودی هستند:

<hal format="hidl">
    <name>foo</name>
    <version>1.0</version>;
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

این ورودی را در compatibility_matrix.F.xml کپی کنید و به صورت زیر تغییر دهید:

<hal format="hidl">
    <name>foo</name>
    <version>2.0</version>
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

محدودیت‌ها:

• از آنجا که HAL نسخه ۱.۰ در compatibility_matrix.F.xml وجود ندارد، دستگاه‌هایی که FCM نسخه F را هدف قرار می‌دهند، نباید HAL نسخه ۱.۰ را ارائه دهند (زیرا این HAL منسوخ شده در نظر گرفته می‌شود).
• از آنجا که HAL نسخه ۱.۰ در نسخه‌های قدیمی‌تر FCM وجود دارد، این چارچوب همچنان می‌تواند با HAL نسخه ۱.۰ کار کند، بنابراین با دستگاه‌های قدیمی که نسخه‌های قدیمی‌تر FCM را هدف قرار می‌دهند، سازگار است.

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

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

1. مطمئن شوید که فایل compatibility_matrix.F.xml دارای ویژگی level="F" باشد.
2. مطمئن شوید که همه دستگاه‌ها ساخته و بوت می‌شوند.
3. تست‌های VTS را به‌روزرسانی کنید تا مطمئن شوید دستگاه‌هایی که با جدیدترین فریم‌ورک (بر اساس سطح API ارسال) راه‌اندازی می‌شوند، دارای نسخه Target FCM V >= F هستند.
4. انتشار فایل در AOSP

برای مثال، تست‌های VTS تضمین می‌کنند که دستگاه‌هایی که با اندروید ۹ عرضه می‌شوند، نسخه Target FCM >= 3 داشته باشند.

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

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

منسوخ کردن یک نسخه HAL یک تصمیم توسعه‌دهنده است (یعنی برای HALهای AOSP، گوگل تصمیم می‌گیرد). این اتفاق می‌تواند زمانی رخ دهد که یک نسخه 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 نیاز ندارد.

برای مثال، در اندروید ۹، health@2.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 یا بالاتر راه‌اندازی می‌شود، نباید انتظار داشته باشد که چارچوب، foo را در نسخه xy یا هر نسخه قدیمی‌تر از xy ارائه دهد. یک نسخه HAL منسوخ شده هنوز توسط چارچوب برای ارتقاء دستگاه‌ها ارائه می‌شود.

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

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

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

ما از یک فرآیند مبتنی بر زمان‌بندی برای تعیین حذف نسخه FCM هدف، حفظ سازگاری برای مدت زمان مورد نیاز و پشتیبانی از الزامات شرکا برای دستگاه‌های با عمر طولانی‌تر استفاده می‌کنیم.

وقتی یک نسخه FCM هدف را از مجموعه S _F نسخه بعدی فریم‌ورک حذف می‌کنیم، هر دو مرحله زیر را انجام می‌دهیم:

1. compatibility_matrix.V.xml از قوانین ساخت حذف کنید (به طوری که روی تصویر سیستم نصب نشود) و هر کدی را که قابلیت‌های حذف شده را پیاده‌سازی کرده یا به آنها وابسته بوده است، حذف کنید.

2. HAL های چارچوب با max-level کمتر یا مساوی V را از مانیفست چارچوب حذف کنید، و هر کدی را که HAL های چارچوب حذف شده را پیاده سازی می کند، حذف کنید.

منسوخ شدن تدریجی برای پیکربندی‌های انتشار

استراتژی شاخه‌بندی Trunk Stable، که در آن نسخه‌های پلتفرم فصلی (QPR) مستقیماً از git_main به جای شاخه‌های جداگانه release-dev گرفته می‌شوند، نیاز به یک فرآیند منسوخ‌سازی تدریجی دارد. یک نسخه FCM ممکن است برای سیگنال اولیه در ساخت‌های trunk_staging حذف شود، در حالی که در شاخه انتشار پشتیبانی می‌شود تا دستگاه‌هایی را که QPR را در طول سال دریافت می‌کنند، در خود جای دهد.

معمولاً یک نسخه از فریم‌ورک از شش FCM پشتیبانی می‌کند: یک نسخه فعلی، چهار نسخه قبلی و یک نسخه اضافی برای پشتیبانی از QPRها. این تعداد می‌تواند در صورتی افزایش یابد که نسخه‌های خاص FCM (مانند نسخه 202404 اندروید 15) پشتیبانی بیشتری برای طول عمر دستگاه داشته باشند.

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

حذف HAL ​​های کاملاً منسوخ شده

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

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

اگر هیچ HAL پشتیبانی‌شده‌ای از HAL حذف‌شده به ارث نبرده باشد، می‌توان خود تعریف HAL ​​را با چند مرحله اضافی حذف کرد.

1. تعریف رابط HAL را از کد منبع حذف کنید. این شامل فایل‌های *.aidl و ماژول Android.bp aidl_interface نیز می‌شود.
2. اگر HIDL است، HASH را از hardware/interfaces/current.txt حذف کنید.
3. اگر AIDL است، پوشه aidl_api را که حاوی فایل‌های AIDL مسدود شده است، حذف کنید.
4. رابط را از hardware/interfaces/compatibility_matrices/exclude/fcm_exclude.cpp حذف کنید.

وضعیت نسخه HAL

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

منتشر نشده

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

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

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

منتشر شده و در حال حاضر

برای HALهای دستگاه، اگر یک نسخه HAL در هر ماتریس سازگاری عمومی و ثابت باشد، منتشر می‌شود. برای مثال، پس از اینکه FCM نسخه ۳ ثابت و در 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 همانطور که در مانیفست چارچوب اندروید ۱۲ مشخص شده است، در اندروید ۱۲ منتشر شده و فعلی است.

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

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

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

مثال‌ها:

• فایل health@1.0 HAL در compatibility_matrix.legacy.xml ، compatibility_matrix.1.xml و compatibility_matrix.2.xml قرار دارد، اما در compatibility_matrix.3.xml وجود ندارد. از این رو، در اندروید ۹ منسوخ شده در نظر گرفته می‌شود.
• پاور HAL در اندروید ۹ به‌روزرسانی جزئی داشته است، اما 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 در اندروید ۹ فعلی است، اما منسوخ نشده است .

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

حذف شد

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

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

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

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

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

FCM های قدیمی

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

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

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

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

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