ภาพรวม 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 Stack ภายใต้จุดต่อเชื่อม /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
  • 0: บล็อก X ในอุปกรณ์ฐานควรแทนที่ด้วย 0 ทั้งหมด
  • 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 เป็น Daemon ใน Userspace ที่มีหน้าที่เขียนและอ่าน อุปกรณ์ 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 snapuserd ใน Userspace ซึ่งจะจัดการ คำขอ I/O
  3. เมื่อการผสานเสร็จสมบูรณ์ เฟรมเวิร์กจะยุบ dm-verity อยู่ด้านบนของ dm-linear (system_base) และนำ dm-user ออก

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

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

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

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

เมื่อบูตด้วยสแนปชอตที่บีบอัด 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 ต่างๆ โดยใช้ระบบปฏิบัติการและขนาด OTA ของ Pixel

ผลกระทบด้านขนาด non-A/B A/B การทดสอบ A/B เสมือน การทดสอบ A/B เสมือน (บีบอัด)
อิมเมจจากโรงงานเดิม 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.1GB2 ใน /data
พื้นที่เก็บข้อมูลทั้งหมดที่ต้องใช้ในการใช้ OTA 5.9 GB3 (Super และ Data) 9 GB (ยอดเยี่ยม) 8.3 GB3 (ซูเปอร์และข้อมูล) 6.6 GB3 (super และ data)

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