ภาพรวม A/B เสมือนจริง

Android มีกลไกการอัปเดต 2 แบบ ได้แก่ การอัปเดต A/B (อย่างราบรื่น) และการอัปเดตที่ไม่ใช่ A/B เพื่อลดความซับซ้อนของโค้ดและเพิ่มประสิทธิภาพให้กระบวนการอัปเดต ใน Android 11 2 กลไกรวมกันเป็น A/B เสมือนเพื่อให้การอัปเดตที่ราบรื่น อุปกรณ์ให้มีต้นทุนในการจัดเก็บข้อมูลที่ลดลง Android 12 มีตัวเลือกการบีบอัด A/B เสมือนเพื่อบีบอัดพาร์ติชันสแนปชอต ใน Android 11 และ Android 12 จะมีเงื่อนไขต่อไปนี้ ใช้:

• การอัปเดต A/B ทางออนไลน์จะราบรื่นเหมือนการอัปเดต A/B การอัปเดต A/B ทางออนไลน์ ลดเวลาที่อุปกรณ์ออฟไลน์และใช้งานไม่ได้
• การอัปเดต A/B เสมือนจริงสามารถย้อนกลับได้ หากเปิดเครื่องระบบปฏิบัติการใหม่ไม่สำเร็จ จะย้อนกลับไปเป็นเวอร์ชันก่อนหน้าโดยอัตโนมัติ
• การอัปเดต A/B เสมือนจริงใช้พื้นที่เพิ่มเติมขั้นต่ำโดยทำซ้ำเฉพาะ พาร์ติชันที่ Bootloader ใช้ พาร์ติชันอื่นๆ ที่อัปเดตได้ ได้แก่ ที่ถ่ายไว้

ความเป็นมาและคำศัพท์

ส่วนนี้จะอธิบายคำศัพท์และอธิบายเทคโนโลยีที่สนับสนุน A/B เสมือน

เครื่องมือแมปอุปกรณ์

การแมปอุปกรณ์คือเลเยอร์บล็อกเสมือนของ Linux ที่ใช้บ่อยใน Android ด้วย พาร์ติชันแบบไดนามิก พาร์ติชันอย่างเช่น /system คือกลุ่มอุปกรณ์ที่ซ้อนกันดังนี้

• ที่ด้านล่างของสแต็กคือพาร์ติชันขั้นสูงจริง (ตัวอย่างเช่น /dev/block/by-name/super)
• ตรงกลางเป็นอุปกรณ์ dm-linear ซึ่งระบุบล็อกใน Super พาร์ติชันของพาร์ติชันที่ระบุ ซึ่งปรากฏเป็น /dev/block/mapper/system_[a|b] ในอุปกรณ์ A/B หรือ /dev/block/mapper/system ในอุปกรณ์ที่ไม่ใช่ A/B
• ที่ด้านบนเป็นอุปกรณ์ dm-verity ซึ่งสร้างขึ้นสำหรับพาร์ติชันที่ยืนยันแล้ว อุปกรณ์นี้ยืนยันว่ามีการลงชื่อบล็อกในอุปกรณ์ dm-linear อย่างถูกต้อง ปรากฏเป็น /dev/block/mapper/system-verity และเป็นแหล่งที่มา ของจุดต่อเชื่อม /system

รูปที่ 1 แสดงลักษณะของกองใต้จุดต่อเชื่อม /system

รูปที่ 1 กองซ้อนใต้จุดต่อเชื่อม /system

สแนปชอต DM

A/B เสมือนใช้ dm-snapshot ซึ่งเป็นโมดูลโปรแกรมแมปอุปกรณ์เพื่อทำสแนปชอต สถานะของอุปกรณ์จัดเก็บข้อมูล เมื่อใช้ dm-snapshot จะมีอุปกรณ์ 4 เครื่องใน เล่น:

• อุปกรณ์ฐานคืออุปกรณ์ที่ได้รับสแนปชอต ในหน้านี้ ส่วนฐาน จะเป็นพาร์ติชันแบบไดนามิกเสมอ เช่น ระบบหรือผู้ให้บริการ
• อุปกรณ์ copy-on-write (COW) สำหรับบันทึกการเปลี่ยนแปลงในอุปกรณ์พื้นฐาน ทั้งนี้ มีขนาดเท่าใดก็ได้ แต่ต้องมีขนาดใหญ่พอที่จะรองรับ อุปกรณ์ฐาน
• อุปกรณ์สแนปชอตสร้างขึ้นโดยใช้เป้าหมาย snapshot เขียนถึง เขียนอุปกรณ์สแนปชอตไปยังอุปกรณ์ COW การอ่านจากสแนปชอต อ่านจากอุปกรณ์พื้นฐานหรืออุปกรณ์ COW โดยขึ้นอยู่กับ ข้อมูลที่เข้าถึงมีการเปลี่ยนแปลงโดยสแนปชอตหรือไม่
• อุปกรณ์ต้นทางสร้างขึ้นโดยใช้เป้าหมาย snapshot-origin อ่านถึง ที่อุปกรณ์ต้นทางอ่านจากอุปกรณ์ฐานโดยตรง เขียนไปยังต้นทาง จะเขียนไปยังอุปกรณ์พื้นฐานโดยตรง แต่ระบบจะสำรองข้อมูลดั้งเดิม โดยการเขียนไปยังอุปกรณ์ COW

รูปที่ 2 การแมปอุปกรณ์สําหรับสแนปชอต DM

สแนปชอตที่บีบอัด

ใน Android 12 ขึ้นไป เนื่องจากข้อกำหนดด้านพื้นที่ใน พาร์ติชัน /data อาจมีระดับสูง คุณเปิดใช้สแนปชอตที่บีบอัดได้ใน บิลด์เพื่อตอบสนองความต้องการด้านพื้นที่ที่สูงขึ้นของพาร์ติชัน /data

สแนปชอตที่บีบอัดโดย A/B เสมือนสร้างขึ้นจากคอมโพเนนต์ต่อไปนี้ ที่มีใน Android 12 ขึ้นไป

• dm-user ซึ่งเป็นโมดูลเคอร์เนลที่คล้ายกับ FUSE ที่อนุญาตให้มีพื้นที่ผู้ใช้ ในการนำอุปกรณ์บล็อกไปใช้
• snapuserd เป็น Daemon ของ userspace สำหรับใช้สแนปชอตใหม่

คอมโพเนนต์เหล่านี้จะเปิดใช้การบีบอัด การเปลี่ยนแปลงที่จำเป็นอื่นๆ ที่ดำเนินการ นำความสามารถของสแนปชอตที่บีบอัดไปใช้ในส่วนถัดไป รูปแบบ COW สำหรับสแนปชอตที่บีบอัด dm-user และ Snapuserd

รูปแบบ COW สำหรับสแนปชอตที่บีบอัด

ใน Android 12 ขึ้นไป สแนปชอตที่บีบอัดจะใช้ รูปแบบ COW คล้ายกับรูปแบบในตัวของเคอร์เนลที่ใช้สำหรับที่ไม่มีการบีบอัด ของสแนปชอต รูปแบบ COW สำหรับสแนปชอตที่บีบอัดจะมีส่วนที่สลับกัน ข้อมูลเมตาและข้อมูล ข้อมูลเมตาของรูปแบบต้นฉบับอนุญาตให้แทนที่ได้เท่านั้น การดำเนินการ: แทนที่บล็อก X ในรูปภาพฐานด้วยเนื้อหาของบล็อก Y ในภาพรวม รูปแบบสแนปชอตของ COW ที่บีบอัดนั้นสื่อความหมายได้ดีกว่าและ สนับสนุนการดำเนินการต่อไปนี้

• คัดลอก: บล็อก X ในอุปกรณ์พื้นฐานควรแทนที่ด้วยบล็อก Y ใน อุปกรณ์ฐาน
• แทนที่: บล็อก X ในอุปกรณ์พื้นฐานควรแทนที่ด้วยเนื้อหา ของบล็อก Y ในสแนปชอต บล็อกเหล่านี้แต่ละบล็อกถูกบีบอัดโดย gz
• 0: ควรเปลี่ยนบล็อก X ในอุปกรณ์พื้นฐานด้วยเลข 0 ทั้งหมด
• XOR: อุปกรณ์ COW จะจัดเก็บไบต์ที่บีบอัดด้วย XOR ระหว่างบล็อก X กับ บล็อก Y (พร้อมใช้งานใน Android 13 ขึ้นไป)

การอัปเดต OTA ทั้งหมดประกอบด้วยการดำเนินการแทนที่และศูนย์เท่านั้น เพิ่ม การอัปเดต OTA ยังทำงานคัดลอกได้ด้วย

ผู้ใช้ dm ใน Android 12

โมดูลเคอร์เนลของผู้ใช้ DM ช่วยให้ userspace ใช้บล็อกการแมปอุปกรณ์ได้ อุปกรณ์ รายการตารางของผู้ใช้ DM จะสร้างอุปกรณ์เบ็ดเตล็ดภายใต้ /dev/dm-user/<control-name> กระบวนการของ userspace จะสำรวจอุปกรณ์เพื่อ รับคำขออ่านและเขียนจากเคอร์เนล แต่ละคำขอมีการเชื่อมโยง บัฟเฟอร์สำหรับพื้นที่ผู้ใช้เพื่อป้อนข้อมูล (สำหรับการอ่าน) หรือเผยแพร่ (สำหรับการเขียน)

โมดูลเคอร์เนล dm-user มีอินเทอร์เฟซใหม่ที่ผู้ใช้มองเห็นได้สำหรับเคอร์เนล ที่ไม่ได้เป็นส่วนหนึ่งของฐานโค้ด kernel.org ของอัปสตรีม ในระหว่างนี้ Google ขอสงวนสิทธิ์ในการแก้ไขอินเทอร์เฟซ dm-user ใน Android

Snapuserd

คอมโพเนนต์พื้นที่ผู้ใช้ snapuserd ของ dm-user จะใช้ A/B เสมือน การบีบอัด

ใน Virtual A/B เวอร์ชันที่ไม่มีการบีบอัด (ใน Android 11 และต่ำกว่า หรือ ใน Android 12 โดยไม่มีตัวเลือกสแนปชอตที่บีบอัด) อุปกรณ์ COW คือไฟล์ RAW เมื่อเปิดใช้การบีบอัด ฟังก์ชัน COW แทนที่จะเป็นอุปกรณ์ dm-user ซึ่งเชื่อมต่อกับอินสแตนซ์ของ Daemon snapuserd รายการ

เคอร์เนลไม่ได้ใช้ COW รูปแบบใหม่ ดังนั้นคอมโพเนนต์ snapuserd จะแปลคำขอระหว่างรูปแบบ Android COW และเคอร์เนลในตัว รูปแบบ:

รูปที่ 3 แผนภาพโฟลว์ของ Snapuserd เป็นตัวแปลระหว่าง Android กับ Kernel รูปแบบของ COW

การแปลและการยกเลิกการบีบอัดนี้จะไม่เกิดขึ้นบนดิสก์ snapuserd จะขัดขวางการอ่านและเขียนของ COW ที่เกิดขึ้นในเคอร์เนล และ ติดตั้งใช้งานได้โดยใช้รูปแบบ Android COW

การบีบอัด XOR

สำหรับอุปกรณ์ที่ใช้ Android 13 ขึ้นไป ฟีเจอร์การบีบอัด XOR ซึ่งเปิดใช้อยู่โดยค่าเริ่มต้นจะเปิดใช้พื้นที่ผู้ใช้ เพื่อจัดเก็บไบต์ที่บีบอัดของ XOR ระหว่างบล็อกเก่าและการบล็อกใหม่ วันและเวลา มีการเปลี่ยนแปลงเพียงไม่กี่ไบต์ในหนึ่งบล็อกในการอัปเดต A/B เสมือน XOR รูปแบบพื้นที่เก็บข้อมูลการบีบอัดจะใช้พื้นที่น้อยกว่ารูปแบบพื้นที่เก็บข้อมูลเริ่มต้น เพราะสแนปชอตไม่ได้เก็บข้อมูลไบต์ 4K แบบเต็ม ขนาดสแนปชอตที่ลดลงนี้ ที่เป็นไปได้เนื่องจากข้อมูล XOR มีเลขศูนย์จำนวนมากและบีบอัดได้ง่ายกว่าไฟล์ข้อมูล RAW บล็อกเน็ตมือถือ ในอุปกรณ์ Pixel การบีบอัด XOR จะลดขนาดสแนปชอตลง 25% เหลือ 40%

XOR สำหรับอุปกรณ์ที่อัปเกรดเป็น Android 13 ขึ้นไป แล้วต้องเปิดใช้งานการบีบอัด โปรดดูรายละเอียดที่ XOR การบีบอัด

กระบวนการบีบอัด A/B เสมือน

ส่วนนี้แสดงรายละเอียดเกี่ยวกับขั้นตอนการบีบอัด Virtual A/B ที่ใช้ใน Android 13 และ Android 12

ข้อมูลเมตาการอ่าน (Android 12)

ข้อมูลเมตาสร้างขึ้นโดย Daemon snapuserd ข้อมูลเมตาหลักๆ แล้ว การแมปสองรหัส แต่ละรหัส ขนาด 8 ไบต์ที่แสดงถึงภาคส่วนที่จะผสานรวม ในเดือนdm-snapshot ชื่อว่า disk_exception

struct disk_exception {
    uint64_t old_chunk;
    uint64_t new_chunk;
};

ระบบจะใช้ข้อยกเว้นของดิสก์เมื่อมีการแทนที่กลุ่มข้อมูลเก่าด้วยกลุ่มข้อมูลใหม่

Daemon snapuserd อ่านไฟล์ COW ภายในผ่านไลบรารี COW และ จะสร้างข้อมูลเมตาสำหรับการดำเนินการ COW แต่ละรายการที่ปรากฏในไฟล์ COW

การอ่านข้อมูลเมตาเริ่มต้นจาก dm-snapshot ในเคอร์เนลเมื่อสร้างอุปกรณ์ dm- snapshot แล้ว

ภาพด้านล่างแสดงแผนภาพลำดับเส้นทาง IO สำหรับข้อมูลเมตา การก่อสร้าง

รูปที่ 4 โฟลว์ลำดับสำหรับเส้นทาง IO ในการสร้างข้อมูลเมตา

การรวม (Android 12)

เมื่อกระบวนการเปิดเครื่องเสร็จสมบูรณ์แล้ว เครื่องมือการอัปเดตจะทำเครื่องหมายสล็อตว่ากำลังเปิดเครื่อง สำเร็จและเริ่มการรวมโดยเปลี่ยนเป้าหมาย dm-snapshot เป็น เป้าหมาย dm-snapshot-merge

dm-snapshot แนะนำข้อมูลเมตาและเริ่ม IO สำหรับผสานสำหรับแต่ละดิสก์ ข้อยกเว้น ภาพรวมระดับสูงของเส้นทาง IO สำหรับผสานจะแสดงไว้ด้านล่างนี้

รูปที่ 5 ภาพรวมเส้นทาง IO สำหรับผสาน

หากอุปกรณ์รีบูตในกระบวนการผสาน การผสานรวมจะกลับมาทำงานอีกครั้งใน การรีบูตครั้งถัดไป และการรวมจะเสร็จสมบูรณ์

การกำหนดเลเยอร์ของแผนที่อุปกรณ์

สำหรับอุปกรณ์ที่ใช้ Android 13 ขึ้นไป ดำเนินการผสานสแนปชอตและสแนปชอตในการบีบอัด A/B เสมือน ตามคอมโพเนนต์พื้นที่ผู้ใช้ snapuserd สำหรับอุปกรณ์ที่อัปเกรดเป็น Android 13 ขึ้นไป จะต้องเปิดใช้ฟีเจอร์นี้ สำหรับ โปรดดูรายละเอียดที่หัวข้อพื้นที่ผู้ใช้ ผสาน

เนื้อหาต่อไปนี้อธิบายกระบวนการบีบอัด A/B เสมือน

1. เฟรมเวิร์กจะต่อเชื่อมพาร์ติชัน /system จากอุปกรณ์ dm-verity ซึ่งวางซ้อนอยู่ด้านบนอุปกรณ์ dm-user ซึ่งหมายความว่าทุกๆ I/O จากระบบไฟล์รูทจะถูกกำหนดเส้นทางไปยัง dm-user
2. dm-user จะกำหนดเส้นทาง I/O ไปยัง Daemon snapuserd ของ Userspace ซึ่งจัดการ คำขอ I/O
3. เมื่อการผสานเสร็จสมบูรณ์ เฟรมเวิร์กจะยุบ dm-verity ใน ที่ด้านบนของ dm-linear (system_base) และนํา dm-user ออก

รูปที่ 6 กระบวนการบีบอัด A/B เสมือนจริง

กระบวนการผสานสแนปชอตอาจหยุดชะงัก หากอุปกรณ์รีบูตในระหว่าง กระบวนการผสาน แล้ว กระบวนการผสานจะดำเนินการต่อหลังจากรีบูต

เริ่มการเปลี่ยน

เมื่อเปิดเครื่องด้วยสแนปชอตที่บีบอัด ต้องเริ่มต้น init ขั้นตอนแรก snapuserd เพื่อต่อเชื่อมพาร์ติชัน ปัญหานี้อาจก่อให้เกิดปัญหาเมื่อโหลด sepolicy และบังคับใช้ snapuserd ในบริบทที่ไม่ถูกต้อง และคำขออ่าน ล้มเหลวด้วยการปฏิเสธ Selinux

ในการแก้ปัญหานี้ snapuserd จะเปลี่ยนในขั้นตอนล็อกด้วย init ดังนี้

1. init ในระยะแรกจะเปิด snapuserd จาก RAM และบันทึกการเปิด File-descriptor ไปยังไฟล์ดังกล่าวในตัวแปรสภาพแวดล้อม
2. init ระยะแรกจะเปลี่ยนระบบไฟล์รูทเป็นพาร์ติชันระบบ จากนั้นจะประมวลผลสำเนาระบบของ init
3. สำเนาระบบของ init จะอ่าน sepolicy แบบรวมเป็นสตริง
4. Init จะเรียก mlock() ในหน้าที่หนุนหลัง ext4 ทั้งหมด จากนั้นจะปิดทั้งหมด ตารางตัวแมปอุปกรณ์สำหรับอุปกรณ์สแนปชอต และหยุด snapuserd หลังจากนี้ ระบบจะห้ามไม่ให้อ่านจากพาร์ติชัน เพราะจะทำให้ระบบติดตาย
5. ใช้ตัวบ่งชี้แบบเปิดกับสำเนา ramdisk ของ snapuserd, init เปิด Daemon อีกครั้งด้วยบริบท Selinux ที่ถูกต้อง ตารางเครื่องมือแมปอุปกรณ์ สำหรับอุปกรณ์สแนปชอตเปิดใช้งานอีกครั้งแล้ว
6. เรียกใช้ munlockall() - ดำเนินการ IO อีกครั้งได้อย่างปลอดภัย

การใช้พื้นที่

ตารางต่อไปนี้แสดงการเปรียบเทียบการใช้พื้นที่ของ OTA ที่แตกต่างกัน ที่ใช้ระบบปฏิบัติการของ Pixel และขนาด OTA

¹ระบุเลย์เอาต์สมมติตามการแมปพิกเซล

² ถือว่าอิมเมจระบบใหม่มีขนาดเท่ากับต้นฉบับ

³ข้อกำหนดด้านพื้นที่จะเป็นชั่วคราวจนกว่าจะรีบูต

หากต้องการใช้ A/B เสมือนจริง หรือใช้ความสามารถของสแนปชอตที่บีบอัด โปรดดู การนำ A/B แบบออนไลน์