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

Virtual A/B เป็นกลไกการอัปเดตหลักของ Android Virtual 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 เสมือนจะใช้พื้นที่เพิ่มเติมขั้นต่ำโดยการทำซ้ำเฉพาะ พาร์ติชันที่ใช้โดย Bootloader พาร์ติชันอื่นๆ ที่อัปเดตได้จะสร้างสแนปชอต

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

ส่วนนี้จะอธิบายคำศัพท์และเทคโนโลยีที่รองรับการทดสอบ A/B แบบเสมือน ในระหว่างการติดตั้ง OTA ระบบจะเขียนข้อมูลระบบปฏิบัติการใหม่ไปยัง สล็อตใหม่สำหรับพาร์ติชันจริง หรืออุปกรณ์ COW ที่เฉพาะเจาะจงของ Android หลังจากรีบูตอุปกรณ์แล้ว ระบบจะผสานรวมข้อมูลพาร์ติชันแบบไดนามิกกลับไปยังอุปกรณ์ฐานผ่านการใช้ daemon 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 ซึ่งเป็น daemon ของพื้นที่ผู้ใช้เพื่อใช้รูปแบบสแนปชอตใหม่

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

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

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

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

การอัปเดต OTA แบบเต็มประกอบด้วยการดำเนินการ replace และ zero เท่านั้น นอกจากนี้ การอัปเดต 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 คอมโพเนนต์ Userspace ไปยัง dm-user จะใช้การบีบอัด Virtual 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 ขึ้นไป กระบวนการสแนปชอตและการผสานสแนปชอตในการบีบอัด A/B เสมือนจะดำเนินการโดยsnapuserd คอมโพเนนต์ในพื้นที่ผู้ใช้ สำหรับอุปกรณ์ที่อัปเกรดเป็น Android 13 ขึ้นไป คุณต้องเปิดใช้ฟีเจอร์นี้ ดูรายละเอียดได้ที่การผสาน พื้นที่ผู้ใช้

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

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

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

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

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

การเปลี่ยนสถานะเริ่มต้น

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

เพื่อแก้ไขปัญหานี้ snapuserdจะเปลี่ยนไปพร้อมกับ init ดังนี้

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

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

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

ผลกระทบด้านขนาด non-A/B A/B การทดสอบ A/B เสมือน การทดสอบ A/B เสมือน (บีบอัด)
อิมเมจจากโรงงานเดิม Super ขนาด 4.5 GB (รูปภาพ 3.8 GB + สำรอง 700 MB)1 9GB super (3.8G + 700M reserved, for two slots) 4.5GB super (รูปภาพ 3.8G + 700M ที่สงวนไว้) 4.5GB super (รูปภาพ 3.8G + 700M ที่สงวนไว้)
พาร์ติชันแบบคงที่อื่นๆ /cache ไม่มี ไม่มี ไม่มี
พื้นที่เก็บข้อมูลเพิ่มเติมระหว่าง OTA (ระบบจะคืนพื้นที่ให้หลังจากใช้ OTA) 1.4 GB ใน /data 0 3.8 GB2 ใน /data 2.1 GB2 ใน /data
พื้นที่เก็บข้อมูลทั้งหมดที่ต้องใช้ในการใช้ OTA 5.9 GB3 (Super และ Data) 9 GB (ยอดเยี่ยม) 8.3 GB3 (ซูเปอร์และข้อมูล) 6.6 GB3 (ซูเปอร์และข้อมูล)

1ระบุเลย์เอาต์ที่สันนิษฐานโดยอิงตามการแมปของ Pixel

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

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

A/B เสมือนของ Android 11

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

A/B เสมือนของ Android 12

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

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