توسعه مانیفست دستگاه

هنگام توسعه و انتشار دستگاه‌های جدید، فروشندگان می‌توانند نسخه FCM هدف را در مانیفست دستگاه (DM) تعریف و اعلام کنند. هنگام ارتقای تصویر فروشنده برای دستگاه‌های قدیمی، فروشندگان می‌توانند نسخه‌های جدید HAL را پیاده‌سازی کنند و نسخه FCM هدف را افزایش دهند.

در حال توسعه دستگاه های جدید

هنگام تعریف دستگاه Target FCM Version برای دستگاه های جدید:

  1. DEVICE_MANIFEST_FILE و PRODUCT_ENFORCE_VINTF_MANIFEST تعریف نشده رها کنید.
  2. HAL ها را برای نسخه Target FCM اجرا کنید.
  3. فایل مانیفست دستگاه صحیح را بنویسید.
  4. نسخه Target FCM Version را در فایل مانیفست دستگاه بنویسید.
  5. DEVICE_MANIFEST_FILE را تنظیم کنید.
  6. PRODUCT_ENFORCE_VINTF_MANIFEST را روی true تنظیم کنید.

عرضه دستگاه های جدید

هنگامی که یک دستگاه جدید منتشر می‌شود، نسخه اولیه هدف FCM آن باید تعیین و در مانیفست دستگاه به‌عنوان ویژگی " target-level " در عنصر سطح بالای <manifest> اعلام شود.

برای مثال، دستگاه‌هایی که با Android 9 راه‌اندازی می‌شوند باید نسخه Target FCM برابر با 3 (نسخه بالاتر موجود در این زمان) داشته باشند. برای اعلام این مورد در مانیفست دستگاه:

<manifest version="1.0" type="device" target-level="3">
    <!-- ... -->
</manifest>

ارتقا تصویر فروشنده

هنگام ارتقای تصویر فروشنده برای یک دستگاه قدیمی، فروشندگان می توانند نسخه های جدید HAL را پیاده سازی کنند و نسخه FCM هدف را افزایش دهند.

ارتقاء HAL ها

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

  • دستگاه‌های Google Pixel 2 و Pixel 2 XL با Target FCM نسخه 2 منتشر شدند که صدای مورد نیاز 2.0 HAL android.hardware.audio@2.0::IDeviceFactory/default پیاده‌سازی می‌کرد.
  • برای HAL صوتی 4.0 که با Android 9 منتشر شد، دستگاه‌های Google Pixel 2 و Pixel 2 XL می‌توانند از OTA کامل برای ارتقا به HAL 4.0 استفاده کنند که android.hardware.audio@4.0::IDeviceFactory/default را پیاده‌سازی می‌کند.
  • حتی اگر compatibility_matrix.2.xml فقط audio 2.0 را مشخص می کند، نیاز به تصویر فروشنده با Target FCM نسخه 2 کاهش یافته است زیرا چارچوب Android 9 (FCM نسخه 3) از نظر عملکرد، audio 4.0 را جایگزین audio 2.0 HAL می داند. .

به طور خلاصه، با توجه به اینکه compatibility_matrix.2.xml به audio 2.0 و compatibility_matrix.3.xml به audio 4.0 نیاز دارد، الزامات به شرح زیر است:

نسخه FCM (سیستم) نسخه FCM هدف (فروشنده) الزامات
2 (8.1) 2 (8.1) صوتی 2.0
3 (9) 2 (8.1) صوتی 2.0 یا 4.0
3 (9) 3 (9) صوتی 4.0

ارتقاء نسخه FCM هدف

در طول ارتقای تصویر فروشنده، فروشندگان همچنین می توانند نسخه FCM هدف را افزایش دهند تا نسخه FCM هدفمندی را که تصویر فروشنده ارتقا یافته می تواند با آن کار کند، مشخص کند. برای دستیابی به نسخه هدف FCM یک دستگاه، فروشندگان باید:

  1. تمام نسخه های جدید HAL مورد نیاز را برای نسخه FCM هدف پیاده سازی کنید.
  2. نسخه های HAL را در فایل مانیفست دستگاه تغییر دهید.
  3. نسخه Target FCM را در فایل مانیفست دستگاه تغییر دهید.
  4. نسخه های منسوخ HAL را حذف کنید.

برای مثال، دستگاه‌های Google Pixel و Pixel XL با Android 7.0 راه‌اندازی شدند، بنابراین نسخه Target FCM آنها باید حداقل قدیمی باشد. با این حال، مانیفست دستگاه Target FCM نسخه 2 را اعلام می کند زیرا تصویر فروشنده برای مطابقت با compatibility_matrix.2.xml به روز شده است:

<manifest version="1.0" type="device" target-level="2">

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

برای مثال، دستگاه‌های Google Pixel 2 و Pixel 2 XL دارای Target FCM نسخه 2 هستند. در حالی که برخی از HAL‌های مورد نیاز compatibility_matrix.3.xml (مانند audio 4.0، health 2.0 و غیره) را پیاده‌سازی می‌کنند، اما android.hardware.radio.deprecated@1.0 حذف نمی‌کنند. android.hardware.radio.deprecated@1.0 ، که در FCM نسخه 3 (اندروید 9) منسوخ شده است. از این رو، این دستگاه ها نمی توانند نسخه Target FCM را به 3 ارتقا دهند.

الزامی کردن الزامات هسته در طول OTA

به‌روزرسانی دستگاه‌ها از اندروید 9 یا پایین‌تر

در دستگاه‌های دارای Android 9 یا پایین‌تر، مطمئن شوید که CL زیر انتخاب شده است:

این تغییرات پرچم ساخت PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS را معرفی می‌کند و پرچم را برای دستگاه‌هایی که با Android 9 یا پایین‌تر راه‌اندازی می‌شوند، تنظیم نمی‌کند.

  • هنگام به‌روزرسانی به Android 10، کلاینت‌های OTA در دستگاه‌های دارای Android 9 یا پایین‌تر، الزامات هسته در بسته OTA را به درستی بررسی نمی‌کنند. این تغییرات برای حذف الزامات هسته از بسته OTA تولید شده مورد نیاز است.
  • هنگام به‌روزرسانی به Android 11، تنظیم پرچم ساخت PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS برای بررسی سازگاری VINTF هنگام تولید بسته به‌روزرسانی اختیاری است.

برای اطلاعات بیشتر درباره این پرچم ساخت، به به‌روزرسانی دستگاه‌ها از Android 10 مراجعه کنید.

به روز رسانی دستگاه ها از اندروید 10

Android 10 پرچم ساخت جدیدی را معرفی می کند، PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS . برای دستگاه‌هایی که با Android 10 راه‌اندازی می‌شوند، این پرچم به‌طور خودکار روی true تنظیم می‌شود. هنگامی که پرچم روی true تنظیم می شود، یک اسکریپت نسخه هسته و تنظیمات هسته را از تصویر هسته نصب شده استخراج می کند.

  • هنگام به‌روزرسانی به اندروید 10، بسته به‌روزرسانی OTA حاوی نسخه هسته و پیکربندی است. مشتریان OTA در دستگاه‌های دارای Android 10 این اطلاعات را برای بررسی سازگاری می‌خوانند.
  • هنگام به‌روزرسانی به Android 11، نسل بسته OTA نسخه هسته و پیکربندی را برای بررسی سازگاری می‌خواند.

اگر اسکریپت نتوانست این اطلاعات را برای تصویر هسته شما استخراج کند، یکی از موارد زیر را انجام دهید:

  • اسکریپت را برای پشتیبانی از فرمت هسته خود ویرایش کنید و به AOSP کمک کنید.
  • BOARD_KERNEL_VERSION را روی نسخه هسته و BOARD_KERNEL_CONFIG_FILE را روی مسیر فایل پیکربندی هسته ساخته شده .config تنظیم کنید. هنگامی که تصویر هسته به روز می شود، هر دو متغیر باید به روز شوند.
  • از طرف دیگر، PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS را روی false تنظیم کنید تا از بررسی الزامات هسته رد شوید. این توصیه نمی شود زیرا هر گونه ناسازگاری پنهان است و فقط هنگام اجرای آزمایش های VTS پس از به روز رسانی کشف می شود.

می توانید کد منبع اسکریپت استخراج اطلاعات هسته را مشاهده کنید extract_kernel.py .