Android 10 รองรับพาร์ติชันแบบไดนามิก ซึ่งเป็นระบบการแบ่งพาร์ติชันในพื้นที่ผู้ใช้ ที่สร้าง ปรับขนาด และทำลายพาร์ติชันได้ในระหว่างการอัปเดตผ่านอากาศ (OTA)
หน้านี้อธิบายวิธีที่ไคลเอ็นต์ OTA ปรับขนาดพาร์ติชันแบบไดนามิกระหว่างการอัปเดตสำหรับอุปกรณ์ A/B ที่เปิดตัวโดยไม่รองรับพาร์ติชันแบบไดนามิก และวิธีที่ไคลเอ็นต์ OTA อัปเกรดเป็น Android 10
ฉากหลัง
        ในระหว่างการอัปเดตอุปกรณ์ A/B เพื่อรองรับพาร์ติชันแบบไดนามิก ระบบจะเก็บรักษา
        ตารางพาร์ติชัน GUID (GPT) ในอุปกรณ์ไว้ จึงไม่มีพาร์ติชัน super ในอุปกรณ์
 ระบบจะจัดเก็บข้อมูลเมตาไว้ที่
        system_a และ system_b แต่คุณปรับแต่งได้โดยเปลี่ยน BOARD_SUPER_PARTITION_METADATA_DEVICE
      
        อุปกรณ์บล็อกแต่ละเครื่องมีช่องข้อมูลเมตา 2 ช่อง ใช้
        ช่องข้อมูลเมตาเพียงช่องเดียวในอุปกรณ์บล็อกแต่ละเครื่อง เช่น ข้อมูลเมตา 0 ที่
        system_a และข้อมูลเมตา 1 ที่ system_b
        จะสอดคล้องกับพาร์ติชันในสล็อต A และ B ตามลำดับ ใน
        รันไทม์ ไม่ว่าจะเป็นการอัปเดตสล็อตใดก็ตาม
      
        ในหน้านี้ ช่องข้อมูลเมตาจะเรียกว่าข้อมูลเมตา S
        (แหล่งที่มา) และข้อมูลเมตา T (เป้าหมาย) ในทํานองเดียวกัน พาร์ติชันจะเรียกว่า system_s, vendor_t และอื่นๆ
      
ดูข้อมูลเพิ่มเติมเกี่ยวกับการกำหนดค่าระบบบิลด์ได้ที่ การอัปเกรดอุปกรณ์
ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีที่พาร์ติชันเป็นของกลุ่ม การอัปเดตได้ที่ การเปลี่ยนแปลง การกำหนดค่าบอร์ดสำหรับอุปกรณ์ใหม่
ตัวอย่างข้อมูลเมตาในอุปกรณ์มีดังนี้
- อุปกรณ์บล็อกจริง system_a- ข้อมูลเมตา 0
              - กลุ่ม foo_a- พาร์ติชันเชิงตรรกะ (ไดนามิก) system_a
- พาร์ติชันเชิงตรรกะ (ไดนามิก)
                      product_services_a
- พาร์ติชันอื่นๆ ที่ Foo อัปเดต
 
- พาร์ติชันเชิงตรรกะ (ไดนามิก) 
 - กลุ่ม bar_a- พาร์ติชันเชิงตรรกะ (ไดนามิก) vendor_a
- พาร์ติชันเชิงตรรกะ (ไดนามิก)
                      product_a
- พาร์ติชันอื่นๆ ที่ Bar อัปเดต
 
- พาร์ติชันเชิงตรรกะ (ไดนามิก) 
 
- กลุ่ม 
- ข้อมูลเมตา 1 (ไม่ได้ใช้)
 
- ข้อมูลเมตา 0
              
- อุปกรณ์บล็อกจริง system_b- ข้อมูลเมตา 0 (ไม่ได้ใช้)
- ข้อมูลเมตา 1
              - กลุ่ม foo_b
                  - พาร์ติชันเชิงตรรกะ (ไดนามิก)
                      system_b
- พาร์ติชันเชิงตรรกะ (ไดนามิก)
                      product_services_b
- พาร์ติชันอื่นๆ ที่ Foo อัปเดต
 
- พาร์ติชันเชิงตรรกะ (ไดนามิก)
                      
- Group bar_b
                  - พาร์ติชันเชิงตรรกะ (ไดนามิก)
                      vendor_b
- พาร์ติชันเชิงตรรกะ (ไดนามิก)
                      product_b
- พาร์ติชันอื่นๆ ที่ Bar อัปเดต
 
- พาร์ติชันเชิงตรรกะ (ไดนามิก)
                      
 
- กลุ่ม foo_b
                  
 
        คุณสามารถใช้เครื่องมือ lpdump ในส่วน
        system/extras/partition_tools เพื่อส่งออกข้อมูลเมตาใน
        อุปกรณ์ของคุณ เช่น
      
lpdump --slot 0 /dev/block/by-name/system_alpdump --slot 1 /dev/block/by-name/system_b
ปรับการอัปเดต
ในอุปกรณ์ที่ใช้ Android 9 และต่ำกว่า ไคลเอ็นต์ OTA ในอุปกรณ์ ไม่รองรับการแมปพาร์ติชันแบบไดนามิกก่อนการอัปเดต ระบบจะสร้างชุดแพตช์เพิ่มเติมเพื่อให้ใช้การแมปกับพาร์ติชันจริงที่มีอยู่ได้โดยตรง
        ตัวสร้าง OTA จะสร้างไฟล์ super.img สุดท้ายที่มีเนื้อหาของพาร์ติชันแบบไดนามิกทั้งหมด จากนั้นจะแยกอิมเมจ
        ออกเป็นหลายอิมเมจที่ตรงกับขนาดของอุปกรณ์บล็อกจริง
        ที่สอดคล้องกับระบบ ผู้ให้บริการ และอื่นๆ รูปภาพเหล่านี้มีชื่อว่า
        super_system.img, super_vendor.img และอื่นๆ
        ไคลเอ็นต์ OTA จะใช้รูปภาพเหล่านี้กับพาร์ติชันจริง
        แทนที่จะใช้รูปภาพกับพาร์ติชันเชิงตรรกะ (ไดนามิก)
      
เนื่องจากไคลเอ็นต์ OTA ไม่ทราบวิธีแมปพาร์ติชันแบบไดนามิก ระบบจึงปิดใช้ขั้นตอนหลังการติดตั้งทั้งหมดโดยอัตโนมัติสำหรับพาร์ติชันเหล่านี้ เมื่อสร้างแพ็กเกจการอัปเดต ดูรายละเอียดเพิ่มเติมได้ที่ การกำหนดค่าหลังการติดตั้ง
ขั้นตอนการอัปเดตจะเหมือนกับใน Android 9
ก่อนการอัปเดต ให้ทำดังนี้
ro.boot.dynamic_partitions= ro.boot.dynamic_partitions_retrofit=
หลังจากอัปเดตแล้ว
ro.boot.dynamic_partitions=true ro.boot.dynamic_partitions_retrofit=true
การอัปเดตในอนาคตหลังจากการติดตั้งเพิ่มเติม
หลังจากการอัปเดตแบบติดตั้งเพิ่มเติม ไคลเอ็นต์ OTA จะได้รับการอัปเดตให้ทำงานร่วมกับ พาร์ติชันแบบไดนามิก ขอบเขตสำหรับพาร์ติชันแหล่งที่มาจะไม่ครอบคลุม พาร์ติชันจริงเป้าหมาย
ขั้นตอนการอัปเดตโดยใช้แพ็กเกจอัปเดตปกติ
- เริ่มต้นข้อมูลเมตาของพาร์ติชัน super- 
                สร้างข้อมูลเมตาใหม่ M จากข้อมูลเมตา S (ข้อมูลเมตาต้นทาง)
                เช่น หากข้อมูลเมตา S ใช้ [system_s,vendor_s,product_s] เป็นอุปกรณ์บล็อก ข้อมูลเมตา M ใหม่จะใช้ [system_t,vendor_t,product_t] เป็นอุปกรณ์บล็อก ระบบจะทิ้งกลุ่มและการแบ่งพาร์ติชันทั้งหมดใน M
- 
                เพิ่มกลุ่มเป้าหมายและพาร์ติชันตามฟิลด์ dynamic_partition_metadataในไฟล์ Manifest ของการอัปเดต คุณดูขนาดของแต่ละพาร์ติชันได้ในnew_partition_info
- เขียน M ไปยังข้อมูลเมตา T
- แมปพาร์ติชันที่เพิ่มใน Device Mapper เป็นแบบเขียนได้
 
- 
                สร้างข้อมูลเมตาใหม่ M จากข้อมูลเมตา S (ข้อมูลเมตาต้นทาง)
                เช่น หากข้อมูลเมตา S ใช้ [
- ใช้การอัปเดตในอุปกรณ์ที่บล็อก
            - หากจำเป็น ให้แมปพาร์ติชันต้นทางในตัวแมปอุปกรณ์ เป็นแบบอ่านอย่างเดียว การดำเนินการนี้จำเป็นสำหรับการโหลดแอปจากแหล่งที่ไม่รู้จัก เนื่องจากไม่ได้แมปพาร์ติชันแหล่งที่มาก่อนการอัปเดต
- ใช้การอัปเดตแบบเต็มหรือแบบเดลต้ากับอุปกรณ์บล็อกทั้งหมดใน ช่องเป้าหมาย
- เมานต์พาร์ติชันเพื่อเรียกใช้สคริปต์หลังการติดตั้ง แล้ว ยกเลิกการเมานต์พาร์ติชัน
 
- ยกเลิกการแมปพาร์ติชันเป้าหมาย
ขั้นตอนการอัปเดตโดยใช้แพ็กเกจอัปเดตแบบติดตั้งเพิ่มเติม
          หากใช้แพ็กเกจการอัปเดตแบบติดตั้งเพิ่มเติมในอุปกรณ์ที่เปิดใช้พาร์ติชันแบบไดนามิกอยู่แล้ว ไคลเอ็นต์ OTA จะใช้ไฟล์ super.img ที่แยกไว้ในอุปกรณ์บล็อกโดยตรง ขั้นตอนการอัปเดต
          จะคล้ายกับการอัปเดตแบบติดตั้งเพิ่มเติม ดูรายละเอียดได้ที่
          การปรับการอัปเดต
        
ตัวอย่างเช่น สมมติว่ามีข้อมูลต่อไปนี้
- ช่อง A เป็นช่องที่ใช้งานอยู่
- 
            system_aมีข้อมูลเมตาที่ใช้งานอยู่ที่ช่อง 0
- 
            system_a,vendor_aและproduct_aใช้เป็นอุปกรณ์บล็อก
          เมื่อไคลเอ็นต์ OTA ได้รับแพ็กเกจการอัปเดตแบบติดตั้งเพิ่มเติม ไคลเอ็นต์จะใช้
          super_system.img ใน system_b จริง
          super_vendor.img ใน vendor_b จริง และ
          super_product.img ใน product_b จริง
          อุปกรณ์บล็อกจริง system_b มีข้อมูลเมตาที่ถูกต้อง
          เพื่อแมป system_b เชิงตรรกะ
          vendor_b และ product_b ในเวลาบูต
        
สร้างแพ็กเกจอัปเดต
OTA ที่เพิ่มขึ้น
          เมื่อสร้าง OTA แบบเพิ่มทีละรายการสำหรับอุปกรณ์ที่ติดตั้งเพิ่มเติม การอัปเดต
          จะขึ้นอยู่กับว่าบิลด์ฐานกำหนด
          PRODUCT_USE_DYNAMIC_PARTITIONS และ
          PRODUCT_RETROFIT_DYNAMIC_PARTITIONS หรือไม่
        
- 
            หากบิลด์พื้นฐานไม่ได้กำหนดตัวแปรไว้ นี่คือการอัปเดต
            การปรับเปลี่ยน แพ็กเกจการอัปเดตมีไฟล์ super.imgที่แยก และปิดใช้ขั้นตอนหลังการติดตั้ง
- หากบิลด์ฐานไม่ได้กำหนดตัวแปร การดำเนินการนี้จะเหมือนกับการ อัปเดตทั่วไปที่มีการแบ่งพาร์ติชันแบบไดนามิก แพ็กเกจการอัปเดต มีรูปภาพสำหรับพาร์ติชันเชิงตรรกะ (ไดนามิก) คุณเปิดใช้ ขั้นตอนหลังการติดตั้งได้
OTA แบบเต็ม
ระบบจะสร้างแพ็กเกจ OTA แบบเต็ม 2 แพ็กเกจสำหรับอุปกรณ์ที่ติดตั้งเพิ่มเติม
- 
            $(PRODUCT)-ota-retrofit-$(TAG).zipมี splitsuper.imgเสมอและปิดใช้ขั้นตอนหลังการติดตั้ง สำหรับการอัปเดตแบบย้อนหลัง- 
                โดยจะสร้างขึ้นพร้อมกับอาร์กิวเมนต์เพิ่มเติม
                --retrofit_dynamic_partitionsไปยังสคริปต์ota_from_target_files
- ซึ่งใช้ได้กับทุกบิลด์
 
- 
                โดยจะสร้างขึ้นพร้อมกับอาร์กิวเมนต์เพิ่มเติม
                
- 
            $(PRODUCT)-ota-$(TAG).zipมีรูปภาพที่สมเหตุสมผลสำหรับการ อัปเดตในอนาคต- ใช้กับบิลด์ที่เปิดใช้พาร์ติชันแบบไดนามิกเท่านั้น ดูรายละเอียดเกี่ยวกับการบังคับใช้ข้อกำหนดนี้ได้ที่ด้านล่าง
 
ปฏิเสธการอัปเดตที่ไม่ใช่การดัดแปลงในบิลด์เก่า
ใช้แพ็กเกจ OTA แบบเต็มปกติกับบิลด์ที่เปิดใช้พาร์ติชันแบบไดนามิกเท่านั้น หากกำหนดค่าเซิร์ฟเวอร์ OTA ไม่ถูกต้อง และพุชแพ็กเกจเหล่านี้ไปยังอุปกรณ์ที่ใช้ Android 9 หรือ ต่ำกว่า อุปกรณ์จะบูตไม่สำเร็จ ไคลเอ็นต์ OTA ใน Android 9 และเวอร์ชันที่ต่ำกว่าไม่สามารถแยกความแตกต่างระหว่างแพ็กเกจ OTA แบบติดตั้งเพิ่มเติมกับแพ็กเกจ OTA แบบเต็มปกติได้ ดังนั้นไคลเอ็นต์จะไม่ปฏิเสธแพ็กเกจแบบเต็ม
หากต้องการป้องกันไม่ให้อุปกรณ์ยอมรับแพ็กเกจ OTA แบบเต็ม คุณสามารถ กำหนดให้มีขั้นตอนหลังการติดตั้งเพื่อตรวจสอบการกำหนดค่า อุปกรณ์ที่มีอยู่ เช่น
        device/device_name/dynamic_partitions/check_dynamic_partitions
      
#!/system/bin/sh DP_PROPERTY_NAME="ro.boot.dynamic_partitions" DP_RETROFIT_PROPERTY_NAME="ro.boot.dynamic_partitions_retrofit" DP_PROPERTY=$(getprop ${DP_PROPERTY_NAME}) DP_RETROFIT_PROPERTY=$(getprop ${DP_RETROFIT_PROPERTY_NAME}) if [ "${DP_PROPERTY}" != "true" ] || [ "${DP_RETROFIT_PROPERTY}" != "true" ] ; then echo "Error: applied non-retrofit update on build without dynamic" \ "partitions." echo "${DP_PROPERTY_NAME}=${DP_PROPERTY}" echo "${DP_RETROFIT_PROPERTY_NAME}=${DP_RETROFIT_PROPERTY}" exit 1 fi
        device/device_name/dynamic_partitions/Android.mk
      
LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE:= check_dynamic_partitions LOCAL_MODULE_TAGS := optional LOCAL_MODULE_CLASS := EXECUTABLES LOCAL_SRC_FILES := check_dynamic_partitions LOCAL_PRODUCT_MODULE := true include $(BUILD_PREBUILT)
        device/device_name/device.mk
      
PRODUCT_PACKAGES += check_dynamic_partitions # OPTIONAL=false so that the error in check_dynamic_partitions will be # propagated to OTA client. AB_OTA_POSTINSTALL_CONFIG += \ RUN_POSTINSTALL_product=true \ POSTINSTALL_PATH_product=bin/check_dynamic_partitions \ FILESYSTEM_TYPE_product=ext4 \ POSTINSTALL_OPTIONAL_product=false \
        เมื่อใช้แพ็กเกจ OTA ปกติในอุปกรณ์ที่ไม่ได้เปิดใช้พาร์ติชันแบบไดนามิก
        ไคลเอ็นต์ OTA จะทำงาน
        check_dynamic_partitions เป็นขั้นตอนหลังการติดตั้งและ
        ปฏิเสธการอัปเดต
      
