APEX ใน Android Q: สิ่งที่ใหญ่ที่สุดนับตั้งแต่ Project Treble?

การนำ APEX ไปใช้อาจเป็นเรื่องน่าปวดหัวที่ใหญ่ที่สุดที่ Google ต้องเผชิญนับตั้งแต่เปิดตัว Project Treble APEX คืออะไร และการแนะนำจะเปลี่ยนแปลง Android อย่างไร

แนวคิดเบื้องหลัง APEX นั้นค่อนข้างพบได้ทั่วไปในการแจกแจง GNU/Linux ในชีวิตประจำวัน: การอัปเดตแพ็คเกจที่กำหนดเป้าหมายส่วนเฉพาะของชุดไลบรารี Linux แต่นั่นคือสิ่งที่ Google ไม่เคยพยายามทำเลย เนื่องจาก Android ใช้พาร์ติชั่น RO (อ่านอย่างเดียว) ซึ่งมีไลบรารีระบบและ เฟรมเวิร์กจะถูกจัดเก็บเทียบกับพาร์ติชั่น RW (อ่าน-เขียน) ปกติที่ใช้ในลีนุกซ์ส่วนใหญ่, แสดงผลกระบวนการอัพเกรดมาตรฐาน ไม่เหมาะสม

ไลบรารี่เป็นโค้ดที่คอมไพล์แล้วซึ่งสามารถนำไปใช้ในโปรแกรมอื่นได้ วิธีการที่ใช้กันทั่วไปสามารถสร้างเป็นไลบรารีเพื่อให้แอป Android เรียกใช้ได้ ซึ่งจะช่วยลดขนาดของ APK เนื่องจากไม่จำเป็นต้องนำโค้ดเดียวกันนี้ไปใช้ซ้ำในหลายแอป คุณสามารถค้นหาไลบรารีระบบที่ติดตั้งไว้ล่วงหน้าจำนวนมากได้ในไดเร็กทอรี /system/lib และ /system/lib64 โดยปกติแล้วไลบรารีระบบ Android จะไม่อัปเดตทีละรายการ แต่จะได้รับการอัปเดตโดยเป็นส่วนหนึ่งของการอัปเกรดแพลตฟอร์ม Android ผ่านการอัปเดต OTA ในทางกลับกัน ไลบรารีใน Linux distros อาจได้รับการอัพเดตทีละรายการ ด้วยการเปิดตัว APEX ไลบรารีระบบใน Android สามารถอัปเดตทีละรายการได้เหมือนกับแอป Android ประโยชน์หลักของสิ่งนี้ก็คือ นักพัฒนาแอปจะสามารถใช้ประโยชน์จากไลบรารีที่อัปเดตได้โดยไม่ต้องรอให้ OEM เปิดตัวการอัปเกรดระบบแบบเต็ม มาดูรายละเอียดทางเทคนิคเพิ่มเติมเกี่ยวกับวิธีการทำงานของ APEX กันดีกว่า

APEX จะเปลี่ยนวิธีการอัพเดตไลบรารี่อย่างไร?

APEX เป็นระบบนิเวศที่บังคับ (หรือค่อนข้างจะบังคับให้) Google พิจารณาวิธีที่ Android โหลดไลบรารีและไฟล์ทั้งหมดจากพาร์ติชันที่ไม่ได้มาตรฐานที่แตกต่างจาก /system

ก่อนอื่น เราต้องระบุความแตกต่างระหว่างไลบรารีที่ใช้ร่วมกันและไลบรารีแบบคงที่ ไลบรารีที่ใช้ร่วมกันคือไลบรารี (โดยปกติจะเป็นไฟล์ชื่อ libkind.so) ซึ่งไม่มีโค้ดทั้งหมดที่จำเป็นในการรันในตัวมันเอง แต่จริงๆ แล้ว "เชื่อมโยง" กับไลบรารีอื่น ๆ การให้โค้ด ในขณะที่ไลบรารีแบบคงที่นั้น คุณสามารถเดาได้ว่าเป็นไลบรารีที่ไม่ขึ้นอยู่กับไลบรารีอื่นใดและมีทุกสิ่งที่รวมอยู่ในแบบคงที่ภายใน ไฟล์.

Android ได้กำหนดค่าเส้นทางไลบรารีในอดีต (เรียกว่า LD_LIBRARY_PATH ในโลก Linux) ด้วยไฟล์เดียว เรียกว่า ld.config.txt [0] เพื่อกำหนดค่าพาธการค้นหาที่อนุญาตสำหรับไลบรารีที่แบ่งใช้ซึ่งจำเป็นโดยไบนารี่หรืออื่น ๆ ห้องสมุด. เส้นทางเหล่านี้เป็นฮาร์ดโค้ดในการกำหนดค่าและไม่สามารถขยายได้ เค้าโครงนี้ รวมถึงพาร์ติชันระบบแบบอ่านอย่างเดียว นำไปสู่ไลบรารีที่ไม่สามารถอัปเดตได้ เว้นแต่ผู้ใช้จะติดตั้งการอัปเดต OTA สำหรับ Android Google แก้ไขปัญหานี้โดยอนุญาตให้ขยายเส้นทางการค้นหาโดยปล่อยให้แพ็คเกจ APEX เดียวจัดเตรียม ld.config.txt ของตัวเองซึ่งรวมถึงเส้นทางไลบรารีเพิ่มเติม (และอัปเดต) ที่มีอยู่ในแพ็คเกจเหล่านั้น

แม้ว่าการย้ายครั้งนี้จะแก้ไขปัญหาหลักปัญหาหนึ่ง แต่ก็ยังมีปัญหาร้ายแรงบางประการที่ต้องแก้ไข ประการแรก: ความเสถียรของ ABI (application binary interface) ไลบรารีควรส่งออกชุดอินเทอร์เฟซที่เสถียรเสมอเพื่อให้แอปและไลบรารีอื่นๆ สามารถทำงานกับโปรโตคอลเดียวกันต่อไปได้แม้จะใช้ไลบรารีที่อัปเกรดแล้วก็ตาม Google กำลังทำงานอย่างแข็งขันโดยพยายามสร้างอินเทอร์เฟซ C ที่เสถียรระหว่างไลบรารี APEXed

แต่ APEX ไม่ได้จำกัดอยู่เพียงไลบรารีและไบนารีเพียงอย่างเดียว ในความเป็นจริง มันสามารถประกอบด้วยไฟล์การกำหนดค่า การอัพเดตเขตเวลา และเฟรมเวิร์ก Java บางตัว (เข้ารหัสในขณะที่เขียน)

นี่คือตัวอย่างบางส่วนของแพ็คเกจ APEX ปัจจุบันที่ AOSP มอบให้:

• com.android.runtime: ART และไบโอนิครันไทม์ (ไบนารีและไลบรารี)
• com.android.tzdata: ข้อมูล TimeZone และ ICU (ไลบรารีและข้อมูลการกำหนดค่า)
• com.android.resolv: ไลบรารีที่ใช้โดย Android เพื่อแก้ไขคำขอที่เกี่ยวข้องกับเครือข่าย (ไลบรารี)
• com.android.conscrypt: ผู้ให้บริการความปลอดภัย Java (เฟรมเวิร์ก Java)

แพ็คเกจ APEX ได้รับการติดตั้งและจัดโครงสร้างอย่างไร

แพ็คเกจ APEX เป็นไฟล์ zip อย่างง่าย (เช่น APK) ที่ ADB ที่มีประโยชน์ของเราสามารถติดตั้งได้ (ณ จุดนี้อยู่ระหว่างการพัฒนา) และต่อมาโดยผู้ใช้เองผ่านตัวจัดการแพ็คเกจ (เช่น Google Play หรือด้วยตนเองผ่านแพ็คเกจ Android ผู้ติดตั้ง)

เค้าโครง ZIP มีลักษณะดังนี้:

มาดำดิ่งกัน

apex_manifest.json ระบุชื่อแพ็กเกจและเวอร์ชัน

apex_payload.img เป็นอิมเมจระบบไฟล์ขนาดเล็ก (จัดรูปแบบเป็น EXT4)

ไฟล์อื่นๆ เป็นส่วนหนึ่งของกระบวนการตรวจสอบที่ใช้ในการติดตั้งแพ็คเกจ มาดูกัน.

การมีอยู่ของ AndroidManifest.xmlแม้ว่าจะใช้ในแอปพลิเคชันเป็นหลัก แต่ก็ช่วยให้เราเข้าใจว่าการใช้งานส่วนใหญ่ที่ใช้สำหรับการติดตั้ง APK มาตรฐานนั้นถูกนำมาใช้ซ้ำแม้กระทั่งกับแพ็คเกจเหล่านี้ ในความเป็นจริง มีการตรวจสอบเฉพาะส่วนขยายเท่านั้นเพื่อแยกความแตกต่างระหว่างส่วนขยายเหล่านั้น

ที่ เมตา-INF/ ไดเรกทอรีมีใบรับรองแพ็คเกจและใช้กลไกเดียวกันกับ APK ปกติ ดังนั้นแพ็คเกจเหล่านี้ ได้รับการตรวจสอบโดยคู่คีย์ส่วนตัว/สาธารณะในขณะรันไทม์ก่อนที่ผู้ใช้จะได้รับอนุญาตให้ติดตั้งการอัปเดต แต่นั่นยังไม่เพียงพอสำหรับ Google ดังนั้นพวกเขาจึงเพิ่มการรักษาความปลอดภัยอีก 2 ชั้น พวกเขากำลังใช้ dm-verity เพื่อตรวจสอบความสมบูรณ์ของรูปภาพและการตรวจสอบ AVB (Android Verified Boot) เพื่อให้แน่ใจว่ารูปภาพมาจากแหล่งที่เชื่อถือได้ ในกรณีที่เลวร้ายที่สุด แพ็คเกจ APEX จะถูกปฏิเสธ

หากขั้นตอนการยืนยันทั้งหมดสำเร็จ รูปภาพจะถูกทำเครื่องหมายว่าถูกต้อง และจะแทนที่ตัวแปรของระบบในการรีบูตครั้งถัดไป

อิมเมจถูกติดตั้งตอนบู๊ตอย่างไร?

เริ่มต้นด้วยการดู APEX ที่ติดตั้งบนอุปกรณ์ของฉันในปัจจุบัน (โปรแกรมจำลอง)

อย่างที่คุณเห็น แพ็คเกจที่ติดตั้งไว้ล่วงหน้าจะถูกจัดเก็บไว้ใน /system/apex/ และแพ็คเกจทั้งหมดเป็นเวอร์ชันหมายเลข 1 แต่จะเกิดอะไรขึ้นเมื่อเปิดใช้งาน APEX? เราจะใช้ com.android.tzdata เป็นตัวอย่างอีกครั้ง

มารีบูทอุปกรณ์และวิเคราะห์ logcat

2 บรรทัดแรกให้ข้อมูลที่เพียงพอในการทำความเข้าใจที่มาของบรรจุภัณฑ์และแหล่งที่มาของพัสดุ ติดตั้งแล้ว: /apex/ ไดเร็กทอรีใหม่ที่เปิดตัวใน Android Q ที่จะใช้เพื่อจัดเก็บที่เปิดใช้งาน แพคเกจ

หลังจากที่แพ็คเกจได้รับการตรวจสอบเรียบร้อยแล้วด้วย AVB และคีย์สาธารณะที่ตรงกัน APEX จะถูกเมาท์โดยใช้อุปกรณ์ลูปไปที่ /dev/block/loop0 ทำให้ระบบไฟล์ EXT4 สามารถเข้าถึงได้โดยระบบ อุปกรณ์วนรอบเป็นอุปกรณ์หลอกที่ทำให้ไฟล์สามารถเข้าถึงได้ในฐานะอุปกรณ์บล็อก ทำให้เนื้อหาของไฟล์นั้นสามารถเข้าถึงได้เป็นจุดเมานท์

ณ จุดนี้ APEX ยังคงไม่ได้ใช้เนื่องจากส่วนต่อท้าย @1 (ซึ่งระบุเวอร์ชันแพ็คเกจ) เพื่อให้ระบบทราบว่าแพ็คเกจของเราเปิดใช้งานสำเร็จแล้ว จะมีการผูกเข้ากับ /apex/com.android.tzdata โดยที่ Android คาดหวังให้ tzdata ทำงานอยู่ การผูกเมานต์จะซ้อนทับไดเร็กทอรีหรือไฟล์ที่มีอยู่ภายใต้จุดอื่น [1]

การใช้งาน APEX นั้นรวมอยู่ในพื้นที่เก็บข้อมูลเดียวภายใต้ AOSP [2] ไดเรกทอรี apexd (APEX daemon) มีโค้ดที่ทำงานบน Android ไดเร็กทอรี apexer มีโค้ดที่ใช้โดยระบบ build เพื่อสร้างแพ็คเกจ APEX

จุดประสงค์คืออะไร?

ณ จุดนี้สิ่งที่ฉันทำได้คือคาดเดา การคาดเดาที่ดีที่สุดของฉันคือ Google กำลังพยายามสร้างชุดหลักของแพ็คเกจ APEX ที่ Google สามารถอัปเดตเพื่อสร้างได้ แกนหลักแบบรวมของ Android ที่ใช้ร่วมกันระหว่างผู้จำหน่าย ทำให้ "ระบบ" สามารถอัปเดตได้เท่านั้น แต่ใช้แพ็คเกจเดียว อัปเดต

อุปกรณ์ทั้งหมดจะรองรับ APEX หรือไม่

ไม่ ตัวอย่างเช่น apexd ต้องการให้ /data/apex พร้อมใช้งานทันทีหลังจากบูตเพื่ออัปเดตโมดูล Android ทั้งหมด ด้วย FDE (การเข้ารหัสดิสก์แบบเต็ม) /data/apex จะถูกเข้ารหัสจนกว่าผู้ใช้จะปลดล็อคอุปกรณ์ ทำให้ APEX โดยทั่วไปไร้ประโยชน์เนื่องจากเฉพาะตัวแปร APEX ของระบบเท่านั้นที่จะถูกโหลดตอนบู๊ต นอกเหนือจากนั้น อุปกรณ์ทั้งหมดควรรองรับ APEX แต่จำเป็นต้องมีแพตช์เคอร์เนลบางส่วน (หลายรายการได้รับการแก้ไขโดย Google ขณะเล่นกับอุปกรณ์วนซ้ำ) [3] [4]

---

แหล่งที่มา [0], [1], [2], [3], [4]