از سال ۲۰۲۶، برای هماهنگی با مدل توسعه پایدار اصلی خود و اطمینان از پایداری پلاتفرم برای بوم‌سازگان، کد منبع را در سه‌ماهه دوم و چهارم در AOSP منتشر خواهیم کرد. برای ساختن و همیاری در AOSP، از android-latest-release استفاده کنید. شاخه مانیفست android-latest-release همیشه به جدیدترین نسخه منتشرشده که به AOSP ارسال شده است ارجاع می‌دهد. برای اطلاعات بیشتر، تغییرات در AOSP را ببینید.

‫Google برای ترجمه محتوا به زبان ترجیحی شما از فناوری هوشواره استفاده می‌کند. ترجمه‌های هوشواره‌ای ممکن است اشتباه داشته باشند.

چرخه حیات FCM

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

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

اصطلاحات

ماتریس سازگاری چارچوب (FCM): فایل XML که الزامات چارچوب را در پیاده‌سازی‌های فروشنده سازگار مشخص می‌کند. ماتریس سازگاری نسخه‌بندی شده است و نسخه جدید برای هر انتشار چارچوب ثابت است. هر نسخه پخش چارچوب شامل چندین FCM است.
نسخه‌های پلاتفرم FCM (S_F): مجموعه همه نسخه‌های FCM در انتشار چارچوب. این چارچوب می‌تواند با هر پیاده‌سازی فروشنده‌ای که یکی از این FCMها را برآورده می‌کند کار کند.
نسخه FCM‏ (F): بالاترین نسخه در میان همه FCMها در نسخه پخش چارچوب.
نسخه هدف FCM (V): نسخه FCM هدف (از S_F)، که به‌طور صریح در مانیفست دستگاه اعلام شده است و پیاده‌سازی فروشنده آن را برآورده می‌کند. پیاده‌سازی فروشنده باید درمقابل FCM منتشرشده تولید شود، هرچند ممکن است نسخه‌های HAL جدیدتری را در «مانیفست دستگاه» خود اعلام کند.
نسخه HAL: «نسخه لایه انتزاع سخت‌افزار» قالب foo@x.y دارد، که در آن foo نام «لایه انتزاع سخت‌افزار» و x.y نسخه خاص است؛ برای مثال nfc@1.0، keymaster@3.0 (پیشوند ریشه، برای مثال android.hardware، در سراسر این سند حذف شده است.)
مانیفست دستگاه: فایل‌های XML که مشخص می‌کنند طرف دستگاه رابط فروشنده، ازجمله تصاویر فروشنده و ODM، کدام نسخه‌های HAL را ارائه می‌دهد. محتویات مانیفست دستگاه توسط نسخه FCM هدف دستگاه محدود می‌شود، اما می‌تواند HALهایی را فهرست کند که نسبت‌به FC مربوط به V کاملاً جدیدتر هستند.
دستگاه HAL: HALهایی که در مانیفست دستگاه فهرست شده‌اند (ارائه شده‌اند) و در ماتریس سازگاری چارچوب (FCM) فهرست شده‌اند.
ماتریس سازگاری دستگاه (DCM): فایل XML که الزامات فروشنده را در پیاده‌سازی‌های چارچوب سازگار مشخص می‌کند. هر دستگاه حاوی یک DCM است.
مانیفست چارچوب: فایل XML که مشخص می‌کند کدام نسخه‌های HAL را سمت چارچوب میانای فروشنده، ازجمله تصاویر سیستم، system_ext، و محصول، ارائه می‌دهد. «لایه‌های انتزاع سخت‌افزار» در مانیفست چارچوب براساس نسخه «هدف FCM» دستگاه به‌صورت پویا غیرفعال می‌شوند.
Framework HALs: «لایه‌های انتزاع سخت‌افزار» که در مانیفست چارچوب به‌عنوان ارائه‌شده فهرست شده‌اند و در ماتریس سازگاری دستگاه (DCM) فهرست شده‌اند.

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

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

انتظار می‌رود دستگاهی که نسخه انتشار Android مربوطه را ارائه می‌دهد مقدار FCM آن بزرگ‌تر یا مساوی سطح معادل باشد. برای مثال، دستگاهی که با Android 12 عرضه می‌شود معمولاً سطح FCM 6 دارد، اما می‌تواند سطح FCM 7 یا بالاتر را پیاده‌سازی کند که رفتار Android را تغییر می‌دهد و باعث می‌شود از APIهای فروشنده جدیدتر که در ماتریس‌های سازگاری مشخص شده است استفاده شود. سطوح پشتیبانی‌شده برای Android 16 عبارت‌اند از:

FCM	نسخهٔ Android
6	‫Android 12/S
7	Android 13/T
8	Android 14/U
202404	‫Android 15/V
202504	‫Android 16/B

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

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

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

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

‫Android نسخه FCM را برای هر نسخه چارچوب (مثل Android نسخه ۸ و ۸.۱) افزایش می‌دهد. درطول توسعه، 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 را به compatibility_matrix.F.xml اضافه کنید.

برای مثال، Android 8.1‏ cas@1.0 را معرفی کرد. دستگاه‌هایی که با Android نسخه 8.1 عرضه می‌شوند می‌توانند این 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 از نسخه 2 به نسخه 3 در «نسخه FCM» فعلی F ارتقا می‌یابد، نسخه جدید به ورودی HAL در compatibility_matrix.F.xml اضافه می‌شود. فیلد نسخه ورودی HAL محدوده‌هایی مانند 2-3 را می‌پذیرد.

برای مثال، Android FCM F،‏ foo@3 را به‌عنوان ارتقای نسخه جزئی HAL معرفی کرد. نسخه قدیمی‌تر، foo@2، برای دستگاه‌هایی استفاده می‌شود که FCM قدیمی‌تر را هدف‌یابی می‌کنند، درحالی‌که نسخه جدیدتر، foo@3، می‌تواند برای دستگاه‌هایی استفاده شود که Android 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 در 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 را ارائه دهند، باید نسخه جدید ۲.۰ را ارائه دهند. در این مثال، نسخه‌های قبلی 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 وجود ندارد، دستگاه‌هایی که نسخه F «کنترل‌کننده دوربین» را هدف‌یابی می‌کنند نباید «کنترل‌کننده دوربین» نسخه ۱.۰ را ارائه دهند (زیرا این «کنترل‌کننده دوربین» منسوخ درنظر گرفته می‌شود).
ازآنجایی‌که ‎1.0 HAL در «نسخه‌های FCM» قدیمی‌تر وجود دارد، چارچوب همچنان می‌تواند با ‎1.0 HAL کار کند، بنابراین با دستگاه‌های قدیمی که نسخه‌های قدیمی‌تر FCM را هدف‌یابی می‌کنند سازگار است.

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

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

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

برای مثال، آزمایش‌های VTS تضمین می‌کند که دستگاه‌هایی که با Android 9 راه‌اندازی می‌شوند «نسخه هدف FCM» آن‌ها >= 3 باشد.

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

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

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

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

وقتی HAL foo@x.y دستگاهی در «نسخه FCM» F منسوخ می‌شود، یعنی هر دستگاهی که با «نسخه FCM هدف» V = F یا جدیدتر راه‌اندازی می‌شود نباید foo را در نسخه x.y یا هر نسخه قدیمی‌تر از x.y پیاده‌سازی کند. نسخه HAL منسوخ‌شده همچنان توسط چارچوب برای ارتقای دستگاه‌ها پشتیبانی می‌شود.

وقتی «نسخه FCM» F منتشر می‌شود، اگر «نسخه HAL» خاصی در جدیدترین FCM برای «نسخه FCM هدف» V = F به‌طور صریح ذکر نشده باشد، «نسخه HAL» foo@x.y منسوخ درنظر گرفته می‌شود. برای دستگاه‌هایی که با V = F عرضه می‌شوند، یکی از شرایط زیر برقرار است:

چارچوب به نسخه بالاتری (اصلی یا فرعی) نیاز دارد؛
این چارچوب دیگر به HAL نیاز ندارد.

برای مثال، در Android 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

When a given framework HAL foo@x.y is deprecated at FCM Version F, it means that any device launching with Target FCM Version V = F or later must not expect the framework to provide foo at version x.y, or at any version older than x.y. نسخه HAL منسوخ‌شده همچنان توسط چارچوب برای ارتقای دستگاه‌ها ارائه می‌شود.

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

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

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

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

وقتی نسخه هدف FCM را از مجموعه S_F نسخه بعدی چارچوب برمی‌داریم، هر دو مرحله زیر را انجام می‌دهیم:

compatibility_matrix.V.xml را از قوانین ساخت بردارید (تا روی تصویر سیستم نصب نشود)، و هر کدی را که قابلیت‌های برداشته‌شده را پیاده‌سازی کرده یا به آن‌ها وابسته است حذف کنید.
Remove framework HALs with max-level lower than or equal to V from the framework manifest, and deleting any code that implements the removed framework HALs.

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

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

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

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

برداشتن HALهای کاملاً منسوخ

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

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

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

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

وضعیت نسخه 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» ثابت شد و در AOSP منتشر شد، health@2.0 HAL به‌عنوان «نسخه HAL منتشرشده و فعلی» درنظر گرفته می‌شود.

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

For framework HALs, if a HAL version is in the framework manifest of the latest released branch without the max-level attribute or (unusually) a max-level equal to or higher than the FCM version released in this branch, it is considered a released and current HAL version. برای مثال، displayservice HAL در Android 12 منتشر شده و فعلی است، همان‌طور که توسط مانیفست چارچوب Android 12 مشخص شده است.

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

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

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

نمونه‌ها:

‫HAL health@1.0 در compatibility_matrix.legacy.xml، compatibility_matrix.1.xml، و compatibility_matrix.2.xml است، اما در compatibility_matrix.3.xml نیست. بنابراین در Android 9 منسوخ درنظر گرفته می‌شود.
HAL برق در Android نسخه ۹ ارتقای جزئی دارد، اما 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 هدف قدیمی یک مقدار ویژه برای همه دستگاه‌های غیرTreble است. FCM قدیمی، compatibility_matrix.legacy.xml، الزامات چارچوب را در دستگاه‌های قدیمی (یعنی دستگاه‌هایی که قبل‌از Android 8.0 عرضه شده‌اند) فهرست می‌کند.

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

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

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

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