یک نسخه فریم ورک اندروید دارای چندین ماتریس سازگاری چارچوب (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 |
وقتی Android سطح 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
مراجعه کنید.