ทุกสิ่งที่คุณต้องรู้เกี่ยวกับ Project Mainline ของ Android

การเปลี่ยนแปลงครั้งใหญ่ที่สุดอย่างหนึ่งใน Android ในช่วงไม่กี่ปีที่ผ่านมาซึ่งถูกมองข้าม ซึ่งค่อนข้างจะสวนทางกับความสำคัญของมันคือการเปิดตัว เมนไลน์โครงการ ใน Android 10 Google กำหนดให้รวมโมดูล Mainline เฉพาะไว้ในรุ่น Android ด้วย แอนดรอยด์ 11 เข้ามาพร้อมกับ รวมภาคบังคับทั้งหมด 25 โมดูล Mainline. ต่อไปนี้คือคำอธิบายว่า Project Mainline คืออะไรและเป้าหมายในการแก้ไขคืออะไร ควบคู่ไปกับรายการโมดูล Project Mainline ทั้งหมดของ Android

Project Mainline คืออะไร?

เพื่อให้เข้าใจ Project Mainline ได้อย่างถูกต้อง เราจะต้องย้อนกลับเล็กน้อย หากคุณย้อนกลับไปไม่กี่ปี การสนทนาจำนวนมากเกี่ยวกับการอัปเดต Android จะเน้นไปที่ปัญหาการแตกแฟรกเมนต์ การแยกส่วนเป็นหนึ่งในความท้าทายที่ยิ่งใหญ่ที่สุดสำหรับ Google ในการแก้ปัญหาบน Android ในยุค Ice Cream Sandwich - Lollipop แม้ว่า Android ในฐานะแพลตฟอร์มจะได้รับการอัปเดตเป็นประจำในรูปแบบที่คาดเดาได้ส่วนใหญ่ แต่การอัปเดตเหล่านี้เคยใช้เวลานานมากกว่าจะถึงมือผู้บริโภคขั้นสุดท้าย หากเป็นเช่นนั้น ดังนั้น ในขณะที่ Google กำลังแก้ไขข้อบกพร่องที่สำคัญและปัญหาด้านความปลอดภัยในระดับแพลตฟอร์ม การเปิดตัวจริงของการเปลี่ยนแปลงเหล่านี้ยังเหลืออีกมากที่ต้องการ มี/มีพ่อค้าคนกลางจำนวนมาก (ผู้ขาย SoC, OEM, ผู้ให้บริการ ฯลฯ) และชิ้นส่วนที่เคลื่อนไหวจำนวนมากที่เกี่ยวข้องในการส่งมอบการอัปเดตให้กับ โทรศัพท์ของคุณ และปัญหาการแตกกระจายไม่ได้ดูเหมือนว่ามันจะแก้ไขได้เองโดยไม่ต้องใช้ความพยายามอย่างหนัก การแทรกแซง

ความพยายามที่สำคัญอย่างหนึ่งในการแก้ไขปัญหานี้มาในรูปของ โครงการเสียงแหลม ควบคู่ไปกับ Android 8.0 Oreo ซึ่งเกี่ยวข้องกับการออกแบบโครงสร้างใหม่ของ Android โดยแยกส่วนประกอบเฟรมเวิร์กระบบปฏิบัติการ Android ออกจาก HAL ของผู้ขายและเคอร์เนล Linux โดยพื้นฐานแล้ว Project Treble ทำให้ Android เป็นโมดูลโดยแยกกรอบระบบปฏิบัติการออกจากซอฟต์แวร์ระดับล่างเฉพาะอุปกรณ์ ด้วยวิธีนี้ ผู้ผลิตอุปกรณ์ (OEM) ไม่จำเป็นต้องรอให้ผู้ผลิตซิลิกอน (ผู้ขาย SoC) อัปเดตรหัสการดำเนินการของผู้ขาย และ OEM สามารถอัปเดตเฟรมเวิร์กระบบปฏิบัติการ Android ได้อย่างอิสระ ผลลัพธ์ที่ได้คือการนำ Android รุ่นใหม่กว่าจาก OEM มาใช้ได้เร็วขึ้น เนื่องจากไม่จำเป็นต้องใช้อีกต่อไป รอให้พ่อค้าคนกลาง (ผู้ขาย SoC) ทำงานให้เสร็จก่อนจึงจะเริ่มดำเนินการได้ ของพวกเขา

แม้ว่าสถานการณ์การอัปเดต Android จะไม่ดีขึ้นอย่างรวดเร็วด้วย Project Treble แต่ก็ช่วยให้ OEM กว้างขึ้นเป็นส่วนใหญ่ การเข้าร่วมใน Android 10 และ Android 11 betas รวมถึงทำให้ OEM สามารถอัปเดตอุปกรณ์ของตนได้มากขึ้นและรวดเร็วขึ้น เส้นเวลา. นอกจากนี้ แนวคิดทั้งหมดของ GSI (Generic System Image) มีผลกระทบอย่างมากต่อการพัฒนาหลังการขายในฟอรัมของเรา

นักพัฒนาเริ่มระบบ Android 11 บนอุปกรณ์รุ่นเก่า 22 เครื่องด้วย Project Treble GSI

Project Mainline ขยายความพยายามของ Project Treble ในขณะที่ Treble ลดการพึ่งพา OEM บนผู้ให้บริการ SoC สำหรับการอัปเดตระบบปฏิบัติการทุกรายการ Mainline ลดการพึ่งพา Google บน OEM สำหรับการส่งมอบการอัปเดตความปลอดภัยให้กับส่วนประกอบระบบปฏิบัติการหลัก Project Mainline ขยายปรัชญาของ Treble ไปสู่ส่วนที่มีความสำคัญมากขึ้นของเฟรมเวิร์ก Android โดยลบ OEM ในฐานะพ่อค้าคนกลางที่ต้องพึ่งพาออกจากสมการนี้ จุดประสงค์ของ Project Mainline คือให้ Google เข้าควบคุมส่วนประกอบเฟรมเวิร์กและแอปพลิเคชันระบบที่เป็นอยู่ สำคัญต่อความปลอดภัยและการรักษาความสม่ำเสมอในการพัฒนาให้ห่างจาก OEM Project Mainline ถูกอ้างถึงอย่างถูกต้องว่า เดอะ การเปลี่ยนแปลงครั้งใหญ่ที่สุดใน Android นับตั้งแต่ Project Treble.

สำหรับ Project Mainline Google ใช้โมดูล Mainline ซึ่งจัดส่งผ่านเฟรมเวิร์ก Google Play Services และ Google Play Store แต่ละโมดูล Mainline จัดส่งเป็นไฟล์ APK, ไฟล์ APEX หรือเป็น APK-in-APEX เมื่อกำลังอัปเดตโมดูล Mainline ผู้ใช้จะเห็นการแจ้งเตือน "การอัปเดตระบบ Google Play" (GPSU) บนอุปกรณ์ของตน เพื่อให้มีการอัปเดตส่วนประกอบที่สำคัญอย่างมีประสิทธิภาพ Google ได้ข้ามขั้นตอนที่จำเป็นในการรอ OEM เพื่อเผยแพร่การอัปเดต โดยเลือกที่จะดำเนินการเอง

เช่น Google ระบุบนเว็บไซต์ Android:

ส่วนประกอบของระบบแบบโมดูลาร์ช่วยให้พันธมิตรของ Google และ Android สามารถเผยแพร่การอัปเดตในวงกว้าง รวดเร็ว และราบรื่นไปยังอุปกรณ์ของผู้ใช้ในลักษณะที่ไม่ล่วงล้ำ ตัวอย่างเช่น การรวมกันของการแยกส่วนตัวแปลงสัญญาณสื่อและจุดบกพร่องที่สำคัญอาจทำให้การยอมรับแอปและการมีส่วนร่วมของผู้ใช้ช้าลงอย่างมาก การอัปเดตโมดูลที่เกี่ยวข้องกับสื่อบ่อยๆ สามารถลดการกระจายตัวของโคเดกเพื่อให้พฤติกรรมของแอปสื่อมีความสอดคล้องกันมากขึ้นในอุปกรณ์ Android ต่างๆ และแก้ไขจุดบกพร่องที่สำคัญเพื่อสร้างความไว้วางใจให้กับผู้ใช้

Android 10 ขึ้นไปจะแปลงส่วนประกอบของระบบที่เลือกเป็นโมดูล ซึ่งบางส่วนใช้รูปแบบคอนเทนเนอร์ APEX (เปิดตัวใน Android 10) และบางส่วนใช้รูปแบบ APK สถาปัตยกรรมโมดูลาร์ช่วยให้สามารถอัปเดตส่วนประกอบของระบบด้วยการแก้ไขจุดบกพร่องที่สำคัญและอื่นๆ การปรับปรุงตามความจำเป็น โดยไม่กระทบต่อการใช้งานของผู้จำหน่ายระดับล่างหรือแอพระดับสูงกว่า และ บริการ.

เช่น อาท เทคนิค กล่าวถึง:

Project Mainline หรือที่เรียกว่า "การอัปเดตระบบ Google Play" ได้รับการแนะนำใน Android 10 โดยเป็นความพยายามหลักในการทำให้ส่วนประกอบระบบหลักของ Android เป็นโมดูลและอัปเดตได้มากขึ้น Mainline เปิดตัวประเภทไฟล์ใหม่ "APEX" สำหรับส่วนประกอบของระบบโดยเฉพาะ โดยมีเป้าหมายในการจัดส่งโค้ดหลักของ Android ผ่าน Play Store อย่างง่ายดายเหมือนกับที่คุณจัดส่งการอัปเดตแอป ก่อนหน้านี้ บล็อกโค้ดที่จัดส่งได้เพียงอย่างเดียวของ Android คือ APK ซึ่งเป็นประเภทไฟล์ที่เดิมออกแบบมาสำหรับแอปของบุคคลที่สาม สิ่งนี้มาพร้อมกับข้อจำกัดด้านความปลอดภัยทุกประเภทและจะเริ่มช้าในกระบวนการบู๊ตเท่านั้น ดังนั้น APEX จึงถูกสร้างขึ้นโดยคำนึงถึงส่วนประกอบของระบบที่มีประสิทธิภาพมากกว่า เฉพาะ Google หรือผู้ผลิตอุปกรณ์ของคุณเท่านั้นที่สร้าง APEX ได้ ดังนั้น APEX จึงมีประสิทธิภาพมากกว่าอย่างเห็นได้ชัดและเป็นส่วนประกอบที่สำคัญสำหรับการบูทเครื่อง เช่น รันไทม์ของแอป

Mainline ไม่ใช่แค่โซลูชันทางเทคนิค แต่ยังเกี่ยวกับการสร้างส่วนต่างๆ ของ Android ที่กระจายจากส่วนกลางด้วย Google ซึ่งเกี่ยวข้องกับการเจรจากับผู้ผลิตอุปกรณ์และทำให้พวกเขาทั้งหมดตกลงที่จะจัดส่งบล็อกเดียวกันของ รหัส. ในที่สุดโมดูล Mainline ก็กลายเป็นข้อบังคับในการจัดส่ง ดังนั้น Mainline จึงเป็นความร่วมมือครั้งใหญ่กับผู้ผลิตอุปกรณ์เพื่อให้แน่ใจว่าโมดูลทั่วทั้งระบบนิเวศเดียวจะตอบสนองความต้องการของทุกคน ไม่ใช่โมดูล Mainline ทุกโมดูลที่เป็นโมดูล APEX ที่ทรงพลังเป็นพิเศษ บางโมดูลเป็นเพียง APK ที่ตอนนี้เป็นรหัส Android ที่แจกจ่ายโดย Google

Project Mainline — โมดูล

ด้วย Android 10 Google สั่งให้รวมโมดูล Mainline เฉพาะ 13 โมดูล ด้วย Android 11 จำนวนโมดูลบังคับทั้งหมดคือ 25 นี่คือรายการทั้งหมดพร้อมกับรายละเอียดที่สำคัญ:

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

Mainline แต่ละโมดูลทำหน้าที่อะไร?

ต่อไปนี้เป็นคำอธิบายโดยย่อสำหรับโมดูล Mainline แต่ละโมดูล:

เพิ่ม

โมดูล adbd จัดการเซสชันการดีบักบรรทัดคำสั่ง adb และ IDE การปรับ adbd แบบแยกส่วนช่วยให้ Google ปรับปรุงประสิทธิภาพและแก้ไขข้อบกพร่องได้รวดเร็วขึ้น นี่เป็นสิ่งสำคัญเนื่องจากข้อบกพร่องบางอย่างในอดีตเกี่ยวข้องกับการระบายแบตเตอรี่ และอาจทำให้อุปกรณ์ใช้ CPU 100% ต่อไปจนกว่าโทรศัพท์จะหมด ดังนั้นการแก้ไขเหล่านี้จึงมีความสำคัญอย่างยิ่งสำหรับ Google เนื่องจากนักพัฒนาแอปและ OEM ใช้ adb กันอย่างแพร่หลายในการทดสอบ

รันไทม์ Android Neural Networks API

นี่คือไลบรารีที่อยู่ระหว่างแอพและไดรเวอร์แบ็กเอนด์ API ในทางกลับกันคือ Android C API สำหรับการเรียกใช้การดำเนินการเรียนรู้ของเครื่องที่เน้นการคำนวณบนอุปกรณ์พกพา และเพื่อเปิดใช้งานการดำเนินการอนุมานที่เร่งด้วยฮาร์ดแวร์

CellBroadcast

Cell Broadcast หมายถึงการแจ้งเตือนเหตุฉุกเฉินและไม่ฉุกเฉิน (เช่น การแจ้งเตือน AMBER) โมดูลนี้เกี่ยวข้องกับงานเกี่ยวกับการแจ้งเตือนเหล่านี้ และกับฟังก์ชันเสริมอื่นๆ เช่น การถอดรหัส SMS และ geofencing สำหรับการแจ้งเตือนฉุกเฉินแบบไร้สาย

เข้ารหัส

โมดูล Conscrypt จัดการการใช้งาน TLS ของ Android และฟังก์ชันการเข้ารหัสอื่นๆ เช่น ตัวสร้างคีย์ cipers และการแยกย่อยข้อความ การจัดส่งนี้เป็นโมดูลที่ช่วยให้ Google เร่งการปรับปรุงความปลอดภัย โดยไม่จำเป็นต้องพึ่งพาการอัปเดต OTA

ตัวแก้ไข DNS

ตามที่ชื่อบอกไว้ ตัวแก้ไข DNS จะแก้ไข DNS นั่นคือจะแปลง URL ที่มนุษย์อ่านได้ให้เป็นที่อยู่ IP โมดูลประกอบด้วยรหัสที่ใช้ตัวแก้ไข DNS stub และการจัดส่งเป็นโมดูลช่วยให้ Google ให้การป้องกันผู้ใช้ที่ดีขึ้นจากการสกัดกั้น DNS และการโจมตีการอัปเดตการกำหนดค่า

เอกสาร UI

Documents UI เป็นโมดูลที่รับผิดชอบในการควบคุมการเข้าถึงไฟล์เฉพาะสำหรับส่วนประกอบที่จัดการสิทธิ์ของเอกสาร ตามที่ Google ระบุไว้ การเข้าถึงที่เก็บข้อมูลและการอนุญาตในโมดูลจะเพิ่มความเป็นส่วนตัวและความปลอดภัยให้กับผู้ใช้ปลายทาง ในขณะเดียวกัน คุณลักษณะการซ้อนทับทรัพยากรรันไทม์ (RRO) ช่วยให้ OEM สามารถกำหนดรูปแบบประสบการณ์ (อ้างอิงถึงแอปไฟล์) ได้หากต้องการ ถึง. ในฐานะโมดูล อุปกรณ์ Google-Android ทั้งหมดจะมาพร้อมกับประสบการณ์การใช้งาน Documents UI เดียวกัน

ExtServices

โมดูลนี้ประกอบด้วยองค์ประกอบเฟรมเวิร์กสำหรับฟังก์ชันหลักของระบบปฏิบัติการ เช่น การจัดอันดับการแจ้งเตือน กลยุทธ์การจับคู่ข้อความป้อนอัตโนมัติ แคชพื้นที่เก็บข้อมูล โปรแกรมเฝ้าระวังแพ็คเกจ และบริการอื่นๆ

ไลบรารี IPsec/IKEv2

โมดูลไลบรารีนี้เกี่ยวข้องกับคุณสมบัติใหม่และที่มีอยู่รอบ Interworking Wireless LAN (IWLAN) และ VPN เช่น การต่อรองพารามิเตอร์ความปลอดภัย เช่น คีย์ อัลกอริทึม และทันเนล การกำหนดค่า แนวคิดเกี่ยวกับการทำให้ฟังก์ชันเหล่านี้เป็นโมดูลคือการส่งเสริมความสอดคล้องของระบบนิเวศและให้วิธีการแก้ไขอย่างรวดเร็วสำหรับปัญหาด้านความปลอดภัยและการทำงานร่วมกัน

เหล่านี้เป็นสามโมดูลที่แยกสองส่วน แต่มีฟังก์ชันที่ต้องพึ่งพาซึ่งกันและกัน โมดูลสื่อเหล่านี้จัดการประเภทสื่อและรหัส โต้ตอบกับ ExoPlayer เปิดเผยการควบคุมการขนส่งและข้อมูลการเล่นไปยังเฟรมเวิร์ก ปรับข้อมูลเมตาที่จัดทำดัชนีให้เหมาะสม ฯลฯ จดจำ Stagefright การใช้ประโยชน์ที่เปลี่ยน Android และนำแนวคิดของการอัปเดตความปลอดภัยรายเดือนมาสู่แพลตฟอร์ม? การใช้ประโยชน์ดังกล่าวอาศัยช่องโหว่ภายในไลบรารีการเล่นสื่อ ดังนั้น การทำให้องค์ประกอบสื่อเป็นโมดูลทำให้ Google สามารถตอบสนองได้อย่างรวดเร็วและกว้างขวางในกรณีที่พบข้อบกพร่องด้านความปลอดภัยในองค์ประกอบที่มักเป็นเป้าหมายนี้

ฟังก์ชันของโมดูลนี้ชัดเจนทันทีจากชื่อ แม้ว่าจุดประสงค์จะไม่ใช่ก็ตาม โมดูลข้อมูลเมตาของโมดูลประกอบด้วย...ข้อมูลเมตาเกี่ยวกับรายการโมดูลบนอุปกรณ์ และนั่นก็เกี่ยวกับมัน

ส่วนประกอบ Network Stack, การกำหนดค่าสิทธิ์ Network Stack, การเข้าสู่ระบบ Captive Portal

โมดูล Network Stack Components ให้บริการ IP ทั่วไป การตรวจสอบการเชื่อมต่อเครือข่าย การตรวจจับพอร์ทัลล็อกอินแบบ Captive โมดูลการกำหนดค่าสิทธิ์กำหนดสิทธิ์ที่ช่วยให้โมดูลอื่นสามารถทำงานที่เกี่ยวข้องกับเครือข่ายได้ โมดูลการเข้าสู่ระบบ Captive Portal เกี่ยวข้องกับ Captive Portal — หน้าเว็บที่จะแสดงเมื่อ เชื่อมต่อกับเครือข่าย Wi-Fi สาธารณะบางเครือข่าย ซึ่งผู้ใช้จะต้องป้อนรายละเอียดเพื่อรับอินเทอร์เน็ต เข้าถึง.

ตัวควบคุมสิทธิ์

โมดูลนี้นำเสนอนโยบายความเป็นส่วนตัวที่อัปเดตได้และองค์ประกอบ UI เกี่ยวกับการอนุญาตและการจัดการสิทธิ์ หากฟังดูคุ้นๆ กับสิ่งที่ Package Installer ทำ นั่นเป็นเพราะเป็นเช่นนั้น ฟังก์ชันต่างๆ เช่น การให้สิทธิ์รันไทม์ การจัดการ และการติดตามการใช้งานเป็นส่วนหนึ่งของแอป Package Installer จนถึง Android 9 ใน Android 10 แอป Package Installer จะแบ่งออกเป็นส่วนๆ เพื่อเปิดใช้งานตรรกะสิทธิ์ที่จะอัปเดต โมดูลตัวควบคุมสิทธิ์จะถูกส่งเป็นไฟล์ APK และใน Android 11 โมดูลสามารถเพิกถอนสิทธิ์รันไทม์โดยอัตโนมัติสำหรับแอปที่ไม่ได้ใช้งานเป็นระยะเวลานาน

ส่วนขยาย SDK

โมดูลนี้เข้าใจยากเล็กน้อยและเป็นผลให้ต้องอธิบาย Android ทุกรุ่นได้รับการกำหนดระดับ SDK (โดยปกติจะเป็น +1 จากรุ่นก่อน) เมื่อแอปกำหนดเป้าหมายไปที่ SDK เฉพาะ จะถือว่านักพัฒนาได้คำนึงถึงพฤติกรรมของแพลตฟอร์มและการเปลี่ยนแปลง API ที่ Android เผยแพร่ออกมาด้วย

โมดูลส่วนขยาย SDK ตัดสินใจเลือกระดับ "ส่วนขยาย SDK" ของอุปกรณ์และเปิดเผย API สำหรับแอปเพื่อค้นหาระดับ SDK ส่วนขยาย นั่นคือทั้งหมดที่เอกสารอย่างเป็นทางการกล่าวถึง ArsTechnica, แม้ว่ากล่าวถึง ซึ่งน่าจะเป็นชั้น API รองที่จะจัดส่งผ่าน Play Store

Statsd แพ็คเกจเวอร์ชั่น Telemetry Train

Statsd มีหน้าที่รวบรวมเมตริกอุปกรณ์ ในทางกลับกัน แพ็คเกจ Telemetry Train Version ไม่มีรหัสที่ใช้งานอยู่หรือฟังก์ชันการทำงานใดๆ ของมันเอง มีเพียงหมายเลขเวอร์ชันสำหรับ "Telemetry Train" ซึ่ง Google กล่าวว่าเป็นชุดของโมดูลที่เกี่ยวข้องกับเมตริก ตามหมายเลขเวอร์ชัน Google Play จะแสดงเวอร์ชันแพตช์ความปลอดภัยแก่ผู้ใช้ปลายทาง และพิจารณาว่ามีการอัปเดตสำหรับโมดูลที่เกี่ยวข้องกับเมตริกหรือไม่

การเชื่อมต่ออินเทอร์เน็ตผ่านมือถือ

โมดูล Tethering แชร์การเชื่อมต่ออินเทอร์เน็ตของอุปกรณ์กับอุปกรณ์ไคลเอ็นต์ที่เชื่อมต่ออื่นๆ ผ่าน Wi-Fi, USB, Bluetooth หรือ Ethernet โมดูลประกอบด้วยส่วนประกอบการปล่อยสัญญาณและการอ้างอิง เมื่อใช้โมดูล Tethering นี้ OEM สามารถพึ่งพาการใช้งานอ้างอิงมาตรฐานเดียวและนำประสบการณ์ที่สอดคล้องกันในอุปกรณ์ต่างๆ

ข้อมูลเขตเวลา

โมดูลข้อมูลโซนเวลาจะอัปเดตเวลาออมแสง (DST) และโซนเวลาบนอุปกรณ์ Android โดยสร้างมาตรฐานให้กับทั้งข้อมูล (ซึ่งสามารถและ เปลี่ยนแปลงค่อนข้างบ่อยตามเหตุผลทางศาสนา การเมือง และภูมิรัฐศาสตร์) และกลไกการอัปเดตทั่วทั้งระบบนิเวศ Android 8.1 และ Android 9 ใช้กลไกการอัปเดตข้อมูลเขตเวลาตาม APK และ Android 10 แทนที่ด้วยกลไกการอัปเดตโมดูลตาม APEX Google ระบุว่า AOSP ยังคงรวมรหัสแพลตฟอร์มที่จำเป็นสำหรับการอัปเดตตาม APK ต่อไป อุปกรณ์ที่อัปเกรดเป็น Android 10 จะยังคงสามารถรับการอัปเดตข้อมูลเขตเวลาจากพาร์ทเนอร์ได้ผ่านทาง เอพีเค. อย่างไรก็ตาม Google เตือนว่าการอัปเดตที่ใช้ APK จะแทนที่การอัปเดตตาม APEX

Wi-Fi

นี่คือโมดูลสำหรับการทำงานของ Wi-Fi ขณะนี้ผู้ใช้ปลายทางสามารถรับประสบการณ์ Wi-Fi ที่สอดคล้องกันในอุปกรณ์ Android ตลอดจนแก้ไขปัญหาการทำงานร่วมกันผ่านการอัปเดตโมดูล แอป นักพัฒนาจะได้รับการลดการกระจายตัวของแพลตฟอร์ม และ OEM สามารถตอบสนองความต้องการของผู้ให้บริการในขณะเดียวกันก็ลดค่าใช้จ่ายสำหรับแต่ละราย การปรับแต่ง

---

หวังว่าบทความนี้จะเน้นย้ำว่า Project Mainline มีความสำคัญต่อระบบนิเวศ Android ของ Google เพียงใด