การพัฒนาไฟล์ Manifest ของอุปกรณ์

เมื่อพัฒนาและเปิดตัวอุปกรณ์ใหม่ ผู้จำหน่ายสามารถกำหนดและประกาศ เวอร์ชัน FCM เป้าหมายในไฟล์ Manifest ของอุปกรณ์ (DM) ได้ เมื่ออัปเกรดรูปภาพของผู้ให้บริการ สำหรับอุปกรณ์รุ่นเก่า ผู้ให้บริการสามารถเลือกใช้ HAL เวอร์ชันใหม่และเพิ่ม เวอร์ชัน FCM เป้าหมายได้

พัฒนาอุปกรณ์ใหม่

เมื่อกำหนด FCM เวอร์ชันเป้าหมายของอุปกรณ์สำหรับอุปกรณ์ใหม่ ให้ทำดังนี้

  1. ปล่อยให้ DEVICE_MANIFEST_FILE และ PRODUCT_ENFORCE_VINTF_MANIFEST ไม่ได้กำหนด
  2. ใช้ HAL สำหรับ FCM เวอร์ชันเป้าหมาย
  3. เขียนไฟล์ Manifest ของอุปกรณ์ที่ถูกต้อง
  4. เขียน FCM เวอร์ชันเป้าหมายลงในไฟล์ Manifest ของอุปกรณ์
  5. ตั้งค่า DEVICE_MANIFEST_FILE
  6. ตั้งค่า PRODUCT_ENFORCE_VINTF_MANIFEST เป็น true

เปิดตัวอุปกรณ์ใหม่

เมื่อมีการเปิดตัวอุปกรณ์ใหม่ คุณจะต้องกำหนดเวอร์ชัน FCM เป้าหมายเริ่มต้นและประกาศในไฟล์ Manifest ของอุปกรณ์เป็นแอตทริบิวต์ "target-level" ในองค์ประกอบ <manifest> ระดับบนสุด

ตัวอย่างเช่น อุปกรณ์ที่เปิดตัวพร้อม Android 9 ต้องมี FCM เวอร์ชันเป้าหมายเท่ากับ 3 (เวอร์ชันที่สูงกว่าที่พร้อมใช้งานในขณะนี้) หากต้องการประกาศฟีเจอร์นี้ในไฟล์ Manifest ของอุปกรณ์ ให้ทำดังนี้

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

อัปเกรดอิมเมจของผู้ให้บริการ

เมื่ออัปเกรดรูปภาพของผู้ให้บริการสำหรับอุปกรณ์รุ่นเก่า ผู้ให้บริการสามารถเลือก ใช้ HAL เวอร์ชันใหม่และเพิ่มเวอร์ชัน FCM เป้าหมายได้

อัปเกรด HAL

ในระหว่างการอัปเกรดรูปภาพของผู้ให้บริการ ผู้ให้บริการสามารถใช้ HAL เวอร์ชันใหม่ได้ โดยมีเงื่อนไขว่าชื่อ HAL, ชื่ออินเทอร์เฟซ และชื่ออินสแตนซ์ต้องเหมือนกัน เช่น

  • อุปกรณ์ Google Pixel 2 และ Pixel 2 XL ที่เปิดตัวพร้อมกับ FCM เวอร์ชันเป้าหมาย 2 ซึ่งใช้ HAL เสียง 2.0 ที่จำเป็น 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 จะระบุเฉพาะเสียง 2.0 แต่ข้อกำหนดในอิมเมจของผู้ให้บริการที่มี FCM เวอร์ชันเป้าหมายเป็น 2 ก็ ผ่อนปรนลงเนื่องจากเฟรมเวิร์ก Android 9 (FCM เวอร์ชัน 3) ถือว่าเสียง 4.0 เป็นการแทนที่ HAL เสียง 2.0 ในแง่ของฟังก์ชันการทำงาน

โดยสรุป เนื่องจาก compatibility_matrix.2.xml ต้องใช้ เสียง 2.0 และ compatibility_matrix.3.xml ต้องใช้เสียง 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 ในไฟล์ Manifest ของอุปกรณ์
  3. แก้ไขเวอร์ชัน FCM เป้าหมายในไฟล์ Manifest ของอุปกรณ์
  4. นำ HAL เวอร์ชันที่เลิกใช้งานแล้วออก

เช่น อุปกรณ์ Google Pixel และ Pixel XL เปิดตัวพร้อม Android 7.0 ดังนั้นเวอร์ชัน FCM เป้าหมายจึงต้องเป็นเวอร์ชันเดิมเป็นอย่างน้อย อย่างไรก็ตาม ไฟล์ Manifest ของอุปกรณ์ประกาศ FCM เวอร์ชันเป้าหมายเป็น 2 เนื่องจากอิมเมจของผู้ให้บริการได้รับการอัปเดตให้เป็นไปตาม compatibility_matrix.2.xml

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

หากผู้ให้บริการไม่ใช้ HAL เวอร์ชันใหม่ที่จำเป็นทั้งหมด หรือไม่นำ HAL เวอร์ชันที่เลิกใช้งานแล้วออก ระบบจะอัปเกรด FCM เวอร์ชันเป้าหมายไม่ได้

เช่น อุปกรณ์ Google Pixel 2 และ Pixel 2 XL มี FCM เวอร์ชันเป้าหมายเป็น 2 แม้ว่าอุปกรณ์เหล่านี้จะใช้ HAL บางอย่างที่ compatibility_matrix.3.xml กำหนด (เช่น เสียง 4.0, สุขภาพ 2.0 ฯลฯ) แต่ก็ไม่ได้นำ android.hardware.radio.deprecated@1.0 ออก ซึ่งandroid.hardware.radio.deprecated@1.0 จะเลิกใช้งานใน FCM เวอร์ชัน 3 (Android 9) ดังนั้น อุปกรณ์เหล่านี้จึงอัปเกรด FCM เวอร์ชันเป้าหมายเป็น 3 ไม่ได้

กำหนดข้อกำหนดของเคอร์เนลระหว่าง OTA

การอัปเดตอุปกรณ์จาก Android 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 เมื่อสร้างแพ็กเกจการอัปเดตหรือไม่ก็ได้

ดูข้อมูลเพิ่มเติมเกี่ยวกับ Flag การสร้างนี้ได้ที่ การอัปเดตอุปกรณ์จาก Android 10

การอัปเดตอุปกรณ์จาก Android 10

Android 10 มีฟีเจอร์ใหม่ที่ชื่อว่า Build Flag PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS สำหรับอุปกรณ์ที่เปิดตัวพร้อม Android 10 ระบบจะตั้งค่าสถานะนี้เป็น true โดยอัตโนมัติ เมื่อตั้งค่าสถานะเป็น true สคริปต์จะดึงข้อมูลเวอร์ชันเคอร์เนลและการกำหนดค่าเคอร์เนล จากอิมเมจเคอร์เนลที่ติดตั้ง

  • เมื่ออัปเดตเป็น Android 10 แพ็กเกจการอัปเดต OTA จะมี เวอร์ชันและกำหนดค่าเคอร์เนล ไคลเอ็นต์ OTA ในอุปกรณ์ที่ใช้ Android 10 จะอ่านข้อมูลนี้เพื่อตรวจสอบ ความเข้ากันได้
  • เมื่ออัปเดตเป็น Android 11 การสร้างแพ็กเกจ OTA จะอ่านเวอร์ชันและการกำหนดค่าเคอร์เนลเพื่อตรวจสอบความเข้ากันได้

หากสคริปต์ดึงข้อมูลนี้สำหรับอิมเมจเคอร์เนลไม่ได้ ให้ทำอย่างใดอย่างหนึ่งต่อไปนี้

  • แก้ไขสคริปต์เพื่อรองรับรูปแบบเคอร์เนลและมีส่วนร่วมใน AOSP
  • ตั้งค่า BOARD_KERNEL_VERSION เป็นเวอร์ชันเคอร์เนล และ BOARD_KERNEL_CONFIG_FILE เป็นเส้นทางของไฟล์การกำหนดค่าเคอร์เนลที่สร้างขึ้น .config ต้องอัปเดตทั้ง 2 ตัวแปร เมื่ออัปเดตอิมเมจเคอร์เนล
  • หรือตั้งค่า PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS เป็น false เพื่อข้ามการตรวจสอบข้อกำหนดของเคอร์เนล เราไม่แนะนําให้ทําเช่นนี้เนื่องจาก ความไม่เข้ากันจะซ่อนอยู่และจะพบเมื่อเรียกใช้การทดสอบ VTS หลังจากอัปเดตเท่านั้น

คุณดูซอร์สโค้ดของสคริปต์การแยกข้อมูลเคอร์เนลได้ที่ extract_kernel.py