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

A/B เสมือนเป็นกลไกการอัปเดตหลักของ Android A/B เสมือนจะอิงตามการอัปเดต A/B เดิม (ดูการอัปเดตระบบ A/B) และไม่ใช่ A/B ซึ่งเลิกใช้งานใน 15 เพื่อลดพื้นที่เก็บข้อมูลส่วนเกินของการอัปเดต

จริงๆ แล้ว A/B เสมือนไม่มีสล็อตเพิ่มเติมสําหรับพาร์ติชันแบบไดนามิก โปรดดูพาร์ติชันแบบไดนามิก แต่ระบบจะเขียนข้อมูลส่วนต่างลงในสแนปชอต แล้วผสานเข้ากับพาร์ติชันฐานหลังจากยืนยันว่าการบูตสำเร็จแล้ว A/B เสมือนใช้รูปแบบสแนปชอตเฉพาะ Android ดูรูปแบบ COW สำหรับสแนปชอตที่บีบอัด ซึ่งช่วยให้บีบอัดสแนปชอตและลดการใช้พื้นที่ในดิสก์ได้ เมื่อใช้การบีบอัดใน OTA แบบเต็ม ขนาดสแนปชอตจะลดลงประมาณ 45% และขนาดสแนปชอต OTA แบบเพิ่มจะลดลงประมาณ 55%

Android 12 มีตัวเลือกการบีบอัด A/B เสมือนจริงเพื่อบีบอัดพาร์ติชันที่บันทึกภาพไว้ การทดสอบ A/B เสมือนมีข้อดีดังนี้

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

หมายเหตุ: A/B เสมือนเป็นข้อกําหนดของ GMS ในอุปกรณ์ที่เปิดตัวด้วย Android 11 ขึ้นไป

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

ส่วนนี้จะอธิบายคําศัพท์และเทคโนโลยีที่รองรับการทดสอบ A/B เสมือนจริง ในระหว่างการติดตั้ง OTA ระบบจะเขียนข้อมูลระบบปฏิบัติการใหม่ลงในช่องใหม่สำหรับพาร์ติชันจริง หรืออุปกรณ์ COW สำหรับ Android โดยเฉพาะ หลังจากรีบูตอุปกรณ์แล้ว ระบบจะผสานข้อมูลพาร์ติชันแบบไดนามิกกลับไปยังอุปกรณ์พื้นฐานผ่านการใช้ dm-user และเดรัม snapuserd กระบวนการนี้จะดำเนินการทั้งหมดในพื้นที่ผู้ใช้

Device-mapper

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

• ที่ด้านล่างของกองคือพาร์ติชัน super จริง (เช่น /dev/block/by-name/super)
• ตรงกลางคืออุปกรณ์ dm-linear ซึ่งระบุบล็อกในซุปเปอร์พาร์ติชันที่ประกอบกันเป็นพาร์ติชันแบบไดนามิกที่ระบุ ซึ่งจะปรากฏเป็น /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

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

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

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

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

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

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

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

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

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

เลย์เอาต์สแนปชอตแบบเต็มบนดิสก์จะมีลักษณะดังนี้

รูปที่ 2 รูปแบบ COW ของ Android ในดิสก์

dm-user

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

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

snapuserd

คอมโพเนนต์พื้นที่ผู้ใช้ snapuserd ไปยัง dm-user ใช้การบีบอัด A/B เสมือน Snapuserd เป็นเดรัมน์สเปซผู้ใช้ที่รับผิดชอบการเขียนและการอ่านอุปกรณ์ COW ของ Android I/O ทั้งหมดไปยังสแนปชอตต้องผ่านบริการนี้ ในระหว่างการติดตั้ง OTA ระบบจะเขียนข้อมูลระบบปฏิบัติการใหม่ลงในสแนปชอตโดย snapuserd (มีการบีบอัด) นอกจากนี้ ระบบจะจัดการการแยกวิเคราะห์ข้อมูลเมตาและการแตกไฟล์ข้อมูลบล็อกใหม่ที่นี่ด้วย

การบีบอัด XOR

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

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

การผสานสแนปชอต

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

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

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

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

กระบวนการผสานสแนปชอตอาจถูกขัดจังหวะ หากรีบูตอุปกรณ์ระหว่างกระบวนการผสาน ระบบจะผสานต่อหลังจากรีบูต

การเปลี่ยนผ่าน Init

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

snapuserd จึงเปลี่ยนไปพร้อมกับ init ดังนี้

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

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

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

ผลกระทบด้านขนาด	ไม่ใช่ A/B	A/B	การทดสอบ A/B เสมือน	A/B เสมือน (บีบอัด)
รูปภาพต้นฉบับจากโรงงาน	4.5 GB Super (ภาพ 3.8 GB + 700 MB ที่สงวนไว้)^1	9 GB Super (3.8 GB + 700 MB สำรองไว้สำหรับ 2 ช่อง)	4.5 GB Super (ภาพ 3.8 GB + 700 MB ที่จองไว้)	4.5 GB Super (ภาพ 3.8 GB + 700 MB ที่จองไว้)
พาร์ติชันแบบคงที่อื่นๆ	/cache	ไม่มี	ไม่มี	ไม่มี
พื้นที่เก็บข้อมูลเพิ่มเติมระหว่าง OTA (พื้นที่ว่างที่คืนหลังจากใช้ OTA)	1.4 GB ใน /data	0	3.8 GB^2ใน /data	2.1 GB^2ใน /data
พื้นที่เก็บข้อมูลทั้งหมดที่จําเป็นในการใช้ OTA	5.9 GB^3 (Super และ Data)	9 GB (Super)	8.3 GB^3 (Super และ Data)	6.6 GB^3 (Super และข้อมูล)

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

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

³ พื้นที่ทำงานที่ต้องการจะหายไปชั่วคราวจนกว่าจะรีบูต

การทดสอบ A/B เสมือนของ Android 11

Android 11 ของ Virtual A/B เขียนลงในพาร์ติชันแบบไดนามิกโดยใช้รูปแบบ COW ของเคอร์เนล ในที่สุดเราก็เลิกใช้งานรูปแบบนี้เนื่องจากรูปแบบ COW ของเคอร์เนลไม่รองรับการบีบอัด

การทดสอบ A/B เสมือนของ Android 12

ใน Android 12 ระบบจะรองรับการบีบอัดในรูปแบบ COW สำหรับ Android โดยเฉพาะ A/B เสมือนจริงเวอร์ชันนี้จำเป็นต้องมีการแปล COW สำหรับ Android โดยเฉพาะเป็นรูปแบบ COW ของ Kernel ในที่สุด รูปแบบนี้ก็ได้ถูกแทนที่ใน Android 13 ซึ่งนำการพึ่งพารูปแบบ COW ของเคอร์เนลและ dm-snapshot ออก

หากต้องการใช้ Virtual A/B หรือใช้ความสามารถของสแนปชอตแบบบีบอัด โปรดดูหัวข้อการใช้ Virtual A/B