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

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

การอัปเดตอุปกรณ์จาก Android 9 หรือต่ำกว่า

ในอุปกรณ์ที่ใช้ Android 9 หรือต่ำกว่า ให้ตรวจสอบว่า CL ต่อไปนี้ได้รับการเลือกสรร

การเปลี่ยนแปลงเหล่านี้จะเปิดตัว Flag การสร้าง PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS และจะไม่ตั้งค่า Flag สำหรับอุปกรณ์ที่เปิดตัวด้วย Android 9 หรือต่ำกว่า

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

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

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

Android 10 เปิดตัว Flag การสร้างใหม่ PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS สำหรับอุปกรณ์ที่เปิดตัวด้วย Android 10 ระบบจะตั้งค่า Flag นี้เป็น true โดยอัตโนมัติ เมื่อตั้งค่า Flag เป็น 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