เมื่อพัฒนาและเปิดตัวอุปกรณ์ใหม่ ผู้จำหน่ายสามารถกำหนดและประกาศ เวอร์ชัน FCM เป้าหมายในไฟล์ Manifest ของอุปกรณ์ (DM) ได้ เมื่ออัปเกรดรูปภาพของผู้ให้บริการ สำหรับอุปกรณ์รุ่นเก่า ผู้ให้บริการสามารถเลือกใช้ HAL เวอร์ชันใหม่และเพิ่ม เวอร์ชัน FCM เป้าหมายได้
พัฒนาอุปกรณ์ใหม่
เมื่อกำหนด FCM เวอร์ชันเป้าหมายของอุปกรณ์สำหรับอุปกรณ์ใหม่ ให้ทำดังนี้
- ปล่อยให้
DEVICE_MANIFEST_FILEและPRODUCT_ENFORCE_VINTF_MANIFESTไม่ได้กำหนด - ใช้ HAL สำหรับ FCM เวอร์ชันเป้าหมาย
- เขียนไฟล์ Manifest ของอุปกรณ์ที่ถูกต้อง
- เขียน FCM เวอร์ชันเป้าหมายลงในไฟล์ Manifest ของอุปกรณ์
- ตั้งค่า
DEVICE_MANIFEST_FILE - ตั้งค่า
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 เป้าหมายของอุปกรณ์ ผู้ให้บริการต้องดำเนินการดังนี้
- ใช้ HAL เวอร์ชันใหม่ที่จำเป็นทั้งหมดสำหรับ FCM เวอร์ชันเป้าหมาย
- แก้ไขเวอร์ชัน HAL ในไฟล์ Manifest ของอุปกรณ์
- แก้ไขเวอร์ชัน FCM เป้าหมายในไฟล์ Manifest ของอุปกรณ์
- นำ 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