Android 10 จะเลิกใช้งานกลไกการอัปเดตข้อมูลเขตเวลาตาม APK (ใช้ได้ใน Android 8.1 และ Android 9) และแทนที่ด้วยกลไกการอัปเดตโมดูลตาม APEX AOSP 8.1 ถึง 13 ยังคงมีโค้ดแพลตฟอร์มที่จําเป็นสําหรับ OEM เพื่อเปิดใช้การอัปเดตตาม APK ดังนั้นอุปกรณ์ที่อัปเกรดเป็น Android 10 จะยังคงได้รับการอัปเดตข้อมูลเขตเวลาจากพาร์ทเนอร์ผ่าน APK อย่างไรก็ตาม ไม่ควรใช้กลไกการอัปเดต APK ในอุปกรณ์เวอร์ชันที่ใช้งานจริงซึ่งกำลังได้รับการอัปเดตโมดูลด้วยเนื่องจากการอัปเดตแบบ APK จะแทนที่การอัปเดตแบบ APEX (กล่าวคือ อุปกรณ์ที่ได้รับการอัปเดต APK จะละเว้นการอัปเดตแบบ APEX)
การอัปเดตเขตเวลา (Android 10 ขึ้นไป)
โมดูลข้อมูลเขตเวลาซึ่งรองรับใน Android 10 ขึ้นไปจะอัปเดตเวลาออมแสง (DST) และเขตเวลาในอุปกรณ์ Android โดยกำหนดมาตรฐานข้อมูลซึ่งอาจเปลี่ยนแปลงบ่อยครั้งเนื่องจากเหตุผลทางศาสนา การเมือง และภูมิศาสตร์การเมือง
การอัปเดตจะใช้กระบวนการต่อไปนี้
- IANA เผยแพร่การอัปเดตฐานข้อมูลเขตเวลาเพื่อตอบสนองต่อการเปลี่ยนแปลงกฎเขตเวลาในประเทศของรัฐบาลอย่างน้อย 1 แห่ง
- Google หรือพาร์ทเนอร์ Android จะเตรียมการอัปเดตข้อบังคับของข้อมูลเขตเวลา (ไฟล์ APEX) ซึ่งมีเขตเวลาที่อัปเดตแล้ว
- อุปกรณ์ของผู้ใช้ปลายทางจะดาวน์โหลดการอัปเดต รีบูต แล้วใช้การเปลี่ยนแปลง จากนั้นข้อมูลเขตเวลาของอุปกรณ์จะมีข้อมูลเขตเวลาใหม่จากการอัปเดต
โปรดดูรายละเอียดเกี่ยวกับโมดูลที่หัวข้อคอมโพเนนต์ของระบบแบบโมดูล
การอัปเดตเขตเวลา (Android 8.1–9)
หมายเหตุ: เราได้นําฟีเจอร์กลไกการอัปเดตข้อมูลเขตเวลาตาม APK ออกจาก Android 14 ขึ้นไปโดยสมบูรณ์แล้ว และจะไม่พบในซอร์สโค้ด พาร์ทเนอร์ควรย้ายข้อมูลไปยังโมดูลเขตเวลาหลักอย่างสมบูรณ์
ใน Android 8.1 และ Android 9 OEM สามารถใช้กลไกที่อิงตาม APK เพื่อพุชข้อมูลกฎเขตเวลาเวอร์ชันอัปเดตไปยังอุปกรณ์ได้โดยไม่ต้องอัปเดตระบบ กลไกนี้ช่วยให้ผู้ใช้ได้รับการอัปเดตอย่างทันท่วงที (ซึ่งช่วยยืดอายุการใช้งานของอุปกรณ์ Android) และช่วยให้พาร์ทเนอร์ Android ทดสอบการอัปเดตเขตเวลาได้โดยไม่เกี่ยวข้องกับการอัปเดตอิมเมจระบบ
ทีมไลบรารีหลักของ Android มีไฟล์ข้อมูลที่จำเป็นสำหรับการอัปเดตกฎเขตเวลาในอุปกรณ์ Android เวอร์ชันสต็อก OEM สามารถเลือกที่จะใช้ไฟล์ข้อมูลเหล่านี้เมื่อสร้างการอัปเดตเขตเวลาสำหรับอุปกรณ์ หรือจะสร้างไฟล์ข้อมูลของตนเองก็ได้หากต้องการ ในทุกกรณี OEM จะยังคงควบคุมการรับรอง/การทดสอบคุณภาพ การกำหนดเวลา และการเปิดตัวการอัปเดตกฎเขตเวลาสำหรับอุปกรณ์ที่รองรับ
ซอร์สโค้ดและข้อมูลเขตเวลาของ Android
อุปกรณ์ Android ทั้งหมดที่มาพร้อมกับระบบปฏิบัติการ ต้องมีทั้งข้อมูลกฎเขตเวลาและมาพร้อมกับชุดข้อมูลกฎเขตเวลาเริ่มต้นในพาร์ติชัน /system จากนั้นโค้ดจากไลบรารีต่อไปนี้ในซอร์สทรีของ Android จะใช้ข้อมูลนี้
- โค้ดที่มีการจัดการจาก
libcore/(เช่นjava.util.TimeZone) ใช้ไฟล์tzdataและtzlookup.xml - โค้ดไลบรารีแบบเนทีฟใน
bionic/(เช่นmktime, การเรียกใช้ระบบ localtime) ใช้ไฟล์tzdata - โค้ดไลบรารี ICU4J/ICU4C ใน
external/icu/ใช้ไฟล์ icu.dat
ไลบรารีเหล่านี้จะติดตามไฟล์วางซ้อนที่อาจอยู่ในไดเรกทอรี /data/misc/zoneinfo/current ไฟล์วางซ้อนควรมีข้อมูลกฎเขตเวลาที่ปรับปรุงแล้ว ซึ่งจะช่วยให้อัปเดตอุปกรณ์ได้โดยไม่ต้องเปลี่ยน /system
คอมโพเนนต์ของระบบ Android ที่ต้องการข้อมูลกฎเขตเวลาจะตรวจสอบตำแหน่งต่อไปนี้ก่อน
- โค้ด
libcore/และbionic/ใช้/dataสำเนาของไฟล์tzdataและtzlookup.xml - โค้ด ICU4J/ICU4C ใช้ไฟล์ใน
/dataและจะใช้ไฟล์/systemแทนสำหรับข้อมูลที่ไม่มี (สำหรับรูปแบบ สตริงที่แปลแล้ว ฯลฯ)
ไฟล์ Distro
ไฟล์ .zip ของดิสโทรประกอบด้วยไฟล์ข้อมูลที่จำเป็นในการสร้างไดเรกทอรี /data/misc/zoneinfo/current ไฟล์การเผยแพร่ยังมีข้อมูลเมตาที่ช่วยให้อุปกรณ์ตรวจหาปัญหาเกี่ยวกับเวอร์ชันได้อีกด้วย
รูปแบบไฟล์ของดิสโทรจะขึ้นอยู่กับรุ่นของ Android เนื่องจากเนื้อหาจะเปลี่ยนแปลงไปตามเวอร์ชัน ICU, ข้อกำหนดของแพลตฟอร์ม Android และการเปลี่ยนแปลงอื่นๆ ของรุ่น Android มีไฟล์สำหรับระบบปฏิบัติการสำหรับ Android ทุกรุ่นที่รองรับสำหรับการอัปเดต IANA ทุกครั้ง (นอกเหนือจากการอัปเดตไฟล์ระบบแพลตฟอร์ม) OEM สามารถใช้ไฟล์ดิสโทรเหล่านี้หรือสร้างไฟล์ของตนเองโดยใช้ซอร์สทรีของ Android (ซึ่งมีสคริปต์และไฟล์อื่นๆ ที่จำเป็นในการสร้างไฟล์ดิสโทร) เพื่อให้อุปกรณ์เป็นเวอร์ชันล่าสุดอยู่เสมอ
คอมโพเนนต์การอัปเดตเขตเวลา
การอัปเดตกฎเขตเวลาเกี่ยวข้องกับการส่งไฟล์ดิสโทรไปยังอุปกรณ์และการติดตั้งไฟล์ที่มีอยู่ในนั้นอย่างปลอดภัย การโอนและการติดตั้งต้องใช้สิ่งต่อไปนี้
- ฟังก์ชันการทำงานของบริการแพลตฟอร์ม (
timezone.RulesManagerService) ซึ่งปิดอยู่โดยค่าเริ่มต้น OEM ต้องเปิดใช้ฟังก์ชันการทำงานผ่านการกําหนดค่าRulesManagerServiceทำงานในกระบวนการเซิร์ฟเวอร์ของระบบและระยะต่างๆ ของการดำเนินการอัปเดตเขตเวลาโดยการเขียนลงใน/data/misc/zoneinfo/stagedRulesManagerServiceยังแทนที่หรือลบการดำเนินการที่จัดเตรียมไว้แล้วได้ด้วย -
TimeZoneUpdaterซึ่งเป็นแอประบบที่อัปเดตไม่ได้ (หรือที่เรียกว่าแอปโปรแกรมอัปเดต) OEM ต้องรวมแอปนี้ไว้ในอิมเมจระบบของอุปกรณ์ที่ใช้ฟีเจอร์นี้ - OEM
TimeZoneData, แอประบบที่อัปเดตได้ (หรือที่เรียกว่าแอป Data) ซึ่งจะส่งไฟล์ Distro ไปยังอุปกรณ์และทำให้ไฟล์เหล่านั้นพร้อมใช้งานสำหรับแอป Updater OEM ต้องรวมแอปนี้ไว้ในอิมเมจระบบของอุปกรณ์ที่ใช้ฟีเจอร์นี้ -
tzdatacheckไบนารีสำหรับช่วงการบูตที่จําเป็นสําหรับการทํางานอย่างถูกต้องและปลอดภัยของการอัปเดตเขตเวลา
ต้นไม้ซอร์สโค้ดของ Android มีซอร์สโค้ดทั่วไปสำหรับคอมโพเนนต์ข้างต้น ซึ่ง OEM สามารถเลือกนำไปใช้ได้โดยไม่ต้องแก้ไข รหัสทดสอบมีไว้เพื่อให้ OEM ตรวจสอบโดยอัตโนมัติว่าเปิดใช้ฟีเจอร์อย่างถูกต้องแล้ว
การติดตั้งระบบปฏิบัติการ
กระบวนการติดตั้งดิสโทรประกอบด้วยขั้นตอนต่อไปนี้
- อัปเดตแอปข้อมูลผ่านการดาวน์โหลดจาก App Store หรือโหลดจากแหล่งที่ไม่รู้จัก กระบวนการเซิร์ฟเวอร์ของระบบ (ผ่านคลาส
timezone.RulesManagerServer/timezone.PackageTracker) จะคอยตรวจสอบการเปลี่ยนแปลงชื่อแพ็กเกจแอป Data ที่กําหนดค่าไว้สำหรับ OEM โดยเฉพาะ
รูปที่ 1 การอัปเดตแอปข้อมูล
- กระบวนการของเซิร์ฟเวอร์ระบบจะทริกเกอร์การตรวจสอบการอัปเดตด้วยการออกอากาศ Intent ที่กำหนดเป้าหมายซึ่งมีโทเค็นแบบใช้ครั้งเดียวที่ไม่ซ้ำกันไปยังแอป Updater เซิร์ฟเวอร์ระบบจะติดตามโทเค็นล่าสุดที่สร้างขึ้นเพื่อให้ระบุได้ว่าการตรวจสอบล่าสุดที่ทริกเกอร์เสร็จสมบูรณ์แล้วหรือไม่ ระบบจะไม่สนใจโทเค็นอื่นๆ
รูปที่ 2 ทริกเกอร์การตรวจสอบการอัปเดต
- ระหว่างการตรวจสอบการอัปเดต แอป Updater จะทํางานต่อไปนี้
- ค้นหาสถานะปัจจุบันของอุปกรณ์โดยการเรียกใช้ RulesManagerService
รูปที่ 3 การอัปเดตแอปข้อมูล การเรียกใช้ RulesManagerService
- ค้นหาแอปข้อมูลโดยการค้นหา URL ของ ContentProvider และข้อกําหนดของคอลัมน์ที่กําหนดไว้อย่างดีเพื่อรับข้อมูลเกี่ยวกับระบบปฏิบัติการ
รูปที่ 4 การอัปเดตแอปข้อมูล รับข้อมูลเกี่ยวกับระบบปฏิบัติการ
- ค้นหาสถานะปัจจุบันของอุปกรณ์โดยการเรียกใช้ RulesManagerService
- แอป Updater จะดําเนินการที่เหมาะสมตามข้อมูลที่มี การดำเนินการที่ใช้ได้มีดังนี้
- ขอการติดตั้ง ระบบจะอ่านข้อมูล Distro จากแอป Data และส่งต่อไปยัง RulesManagerService ในเซิร์ฟเวอร์ระบบ บริการนี้จะยืนยันอีกครั้งว่าเวอร์ชันและเนื้อหาของรูปแบบการแจกจ่ายเหมาะสมกับอุปกรณ์และจัดเตรียมระยะการติดตั้ง
- ขอถอนการติดตั้ง (กรณีนี้เกิดขึ้นได้น้อยมาก) เช่น หากมีการปิดใช้หรือถอนการติดตั้ง APK ที่อัปเดตใน
/dataและอุปกรณ์จะกลับไปใช้เวอร์ชันที่มีอยู่ใน/system - ไม่ต้องทำอะไร เกิดขึ้นเมื่อพบว่า Distribution ของแอปข้อมูลไม่ถูกต้อง
รูปที่ 5 การตรวจสอบเสร็จสมบูรณ์แล้ว
- รีบูตและ tzdatacheck เมื่ออุปกรณ์บูตในครั้งถัดไป ไฟล์ปฏิบัติการ tzdatacheck จะดำเนินการที่จัดเตรียมไว้ ไบนารี tzdatacheck สามารถดำเนินการต่อไปนี้ได้
- ดำเนินการที่แบ่งระยะการทำงานโดยจัดการการสร้าง การเปลี่ยนทดแทน และ/หรือการลบไฟล์
/data/misc/zoneinfo/currentก่อนที่คอมโพเนนต์อื่นๆ ของระบบจะเปิดและเริ่มใช้ไฟล์ - ตรวจสอบว่าไฟล์ใน
/dataถูกต้องสำหรับเวอร์ชันแพลตฟอร์มปัจจุบัน ซึ่งอาจไม่ใช่กรณีนี้หากอุปกรณ์เพิ่งได้รับการอัปเดตระบบและเวอร์ชันรูปแบบดิสโทรมีการเปลี่ยนแปลง - ตรวจสอบว่าเวอร์ชันกฎ IANA เหมือนกับหรือใหม่กว่าเวอร์ชันใน
/systemวิธีนี้ช่วยป้องกันไม่ให้การอัปเดตระบบทำให้อุปกรณ์มีข้อมูลกฎเขตเวลาเก่ากว่าข้อมูลใน/systemรูปภาพ
- ดำเนินการที่แบ่งระยะการทำงานโดยจัดการการสร้าง การเปลี่ยนทดแทน และ/หรือการลบไฟล์
ความไว้ใจได้
กระบวนการติดตั้งจากต้นทางถึงปลายทางเป็นแบบไม่พร้อมกันและแบ่งออกเป็น 3 กระบวนการสำหรับระบบปฏิบัติการ ในระหว่างการติดตั้ง อุปกรณ์อาจไม่มีไฟเข้า พื้นที่ในดิสก์เต็ม หรือพบปัญหาอื่นๆ ซึ่งทำให้การตรวจสอบการติดตั้งไม่สมบูรณ์ ในกรณีที่ไม่สําเร็จที่ดีที่สุด แอป Updater จะแจ้งให้เซิร์ฟเวอร์ของระบบทราบว่าไม่สําเร็จ ในกรณีที่ไม่สําเร็จที่เลวร้ายที่สุด ระบบจะไม่เรียกใช้ RulesManagerService เลย
ในการดำเนินการนี้ รหัสเซิร์ฟเวอร์ของระบบจะติดตามว่าการตรวจสอบการอัปเดตที่ทริกเกอร์เสร็จสมบูรณ์หรือไม่ และรหัสเวอร์ชันล่าสุดที่ตรวจสอบของแอปข้อมูลคืออะไร เมื่ออุปกรณ์ไม่ได้ใช้งานและกำลังชาร์จ รหัสเซิร์ฟเวอร์ของระบบจะตรวจสอบสถานะปัจจุบันได้ หากตรวจพบการตรวจสอบการอัปเดตที่ไม่สมบูรณ์หรือเวอร์ชัน Data App ที่ไม่คาดคิด ระบบจะเรียกให้การตรวจสอบการอัปเดตทำงานโดยอัตโนมัติ
ความปลอดภัย
เมื่อเปิดใช้ โค้ด RulesManagerService ในเซิร์ฟเวอร์ระบบจะดำเนินการตรวจสอบหลายรายการเพื่อให้ระบบใช้งานได้อย่างปลอดภัย
- ปัญหาที่บ่งชี้ว่าอิมเมจระบบได้รับการกําหนดค่าไม่ถูกต้องทําให้อุปกรณ์บูตไม่ได้ เช่น การกําหนดค่าโปรแกรมอัปเดตหรือแอปข้อมูลไม่ถูกต้อง หรือโปรแกรมอัปเดตหรือแอปข้อมูลไม่ได้อยู่ใน
/system/priv-app - ปัญหาที่ระบุว่ามีการติดตั้งแอปข้อมูลที่ไม่ถูกต้องจะไม่ป้องกันไม่ให้อุปกรณ์บูต แต่จะไม่ทริกเกอร์การตรวจสอบการอัปเดต เช่น อุปกรณ์ไม่มีสิทธิ์ของระบบที่จําเป็น หรือแอปข้อมูลไม่ได้แสดง ContentProvider ใน URI ที่คาดไว้
ระบบจะบังคับใช้สิทธิ์ไฟล์สำหรับไดเรกทอรี /data/misc/zoneinfo โดยใช้กฎ SELinux แอปข้อมูลต้องได้รับการลงนามด้วยคีย์เดียวกับที่ใช้ลงนามเวอร์ชัน /system/priv-app เช่นเดียวกับ APK อื่นๆ แอปข้อมูลควรมีชื่อและคีย์แพ็กเกจเฉพาะสำหรับ OEM
ผสานรวมการอัปเดตเขตเวลา
โดยปกติแล้ว OEM จะดำเนินการต่อไปนี้เพื่อเปิดใช้ฟีเจอร์การอัปเดตเขตเวลา
- สร้างแอปข้อมูลของตนเอง
- รวมแอป Updater และแอป Data ไว้ในบิลด์อิมเมจระบบ
- กำหนดค่าเซิร์ฟเวอร์ระบบเพื่อเปิดใช้ RulesManagerService
การเตรียมพร้อม
ก่อนเริ่มต้น OEM ควรอ่านนโยบาย การรับรองคุณภาพ และข้อควรพิจารณาด้านความปลอดภัยต่อไปนี้
- สร้างคีย์ App Signing สำหรับแอปข้อมูลโดยเฉพาะ
- สร้างกลยุทธ์การเผยแพร่และการกำหนดเวอร์ชันสำหรับการอัปเดตเขตเวลาเพื่อให้ทราบว่าอุปกรณ์ใดบ้างที่จะอัปเดต และวิธีตรวจสอบว่ามีการอัปเดตในอุปกรณ์ที่จำเป็นเท่านั้น ตัวอย่างเช่น OEM อาจต้องการมีแอปข้อมูลแอปเดียวสำหรับอุปกรณ์ทั้งหมด หรืออาจเลือกมีแอปข้อมูลที่แตกต่างกันสำหรับอุปกรณ์แต่ละเครื่อง การตัดสินใจนี้จะส่งผลต่อชื่อแพ็กเกจ โค้ดเวอร์ชันที่ใช้ และกลยุทธ์ QA
- ทำความเข้าใจว่าผู้ใช้ต้องการใช้ข้อมูลเขตเวลาของ Android เวอร์ชันเสถียรจาก AOSP หรือสร้างเขตเวลาของตนเอง
สร้างแอปข้อมูล
AOSP มีซอร์สโค้ดและกฎการสร้างทั้งหมดที่จำเป็นต่อการสร้างแอปข้อมูลใน packages/apps/TimeZoneData พร้อมวิธีการและเทมเพลตตัวอย่างสำหรับ AndroidManifest.xml และไฟล์อื่นๆ ที่อยู่ใน packages/apps/TimeZoneData/oem_template ตัวอย่างเทมเพลตมีทั้งเป้าหมายการสร้างสําหรับ APK ของแอป Data จริงและเป้าหมายเพิ่มเติมสําหรับการสร้างแอป Data เวอร์ชันทดสอบ
OEM สามารถปรับแต่งแอปข้อมูลด้วยไอคอน ชื่อ คำแปล และรายละเอียดอื่นๆ ของตนเอง อย่างไรก็ตาม เนื่องจากแอปข้อมูลเปิดไม่ได้ ไอคอนจะปรากฏในหน้าจอการตั้งค่า > แอปเท่านั้น
แอปข้อมูลมีไว้สำหรับสร้างด้วยบิลด์ tapas ซึ่งจะสร้าง APK ที่เหมาะสมที่จะเพิ่มลงในอิมเมจระบบ (สำหรับรุ่นแรก) และเซ็นชื่อและเผยแพร่ผ่าน App Store (สำหรับการอัปเดตในภายหลัง) โปรดดูรายละเอียดเกี่ยวกับการใช้ tapas ที่หัวข้อการสร้างแอปข้อมูลโดยใช้ tapas
OEM ต้องติดตั้งแอป Data ที่สร้างขึ้นล่วงหน้าในอิมเมจระบบของอุปกรณ์ใน /system/priv-app หากต้องการรวม APK ที่คอมไพล์ไว้ล่วงหน้า (สร้างโดยกระบวนการสร้าง tapas) ในอิมเมจระบบ OEM สามารถคัดลอกไฟล์ตัวอย่างใน packages/apps/TimeZoneData/oem_template/data_app_prebuilt เทมเพลตตัวอย่างยังมีเป้าหมายการสร้างสําหรับรวมแอป Data เวอร์ชันทดสอบไว้ในชุดทดสอบด้วย
รวมแอป Updater และแอป Data ไว้ในอิมเมจระบบ
OEM ต้องวาง APK ของโปรแกรมอัปเดตและแอปข้อมูลไว้ในไดเรกทอรี /system/priv-app ของอิมเมจระบบ โดยบิลด์อิมเมจระบบต้องระบุแอป Updater และแอป Data ที่คอมไพล์ไว้ล่วงหน้าเป็นเป้าหมายอย่างชัดเจน
แอปโปรแกรมอัปเดตควรลงชื่อด้วยคีย์แพลตฟอร์มและรวมไว้เป็นแอประบบอื่นๆ เป้าหมายจะกำหนดใน packages/apps/TimeZoneUpdater เป็น TimeZoneUpdater การรวมแอปข้อมูลจะเจาะจง OEM และขึ้นอยู่กับชื่อเป้าหมายที่เลือกไว้สำหรับรุ่นก่อนสร้าง
กำหนดค่าเซิร์ฟเวอร์ระบบ
หากต้องการเปิดใช้การอัปเดตเขตเวลา OEM สามารถกำหนดค่าเซิร์ฟเวอร์ระบบโดยลบล้างพร็อพเพอร์ตี้การกําหนดค่าที่ระบุไว้ใน frameworks/base/core/res/res/values/config.xml
| พร็อพเพอร์ตี้ | คำอธิบาย | ต้องลบล้างหรือไม่ |
|---|---|---|
config_enableUpdateableTimeZoneRules |
ต้องตั้งค่าเป็น true เพื่อเปิดใช้ RulesManagerService |
ใช่ |
config_timeZoneRulesUpdateTrackingEnabled |
ต้องตั้งค่าเป็น true เพื่อให้ระบบคอยฟังการเปลี่ยนแปลงของแอป Data |
ใช่ |
config_timeZoneRulesDataPackage |
ชื่อแพ็กเกจของแอปข้อมูลเฉพาะ OEM | ใช่ |
config_timeZoneRulesUpdaterPackage |
กำหนดค่าไว้สำหรับแอป Updater เริ่มต้น โปรดเปลี่ยนเฉพาะในกรณีที่มีการใช้งานแอป Updater อื่น | ไม่ |
config_timeZoneRulesCheckTimeMillisAllowed |
ระยะเวลาที่อนุญาตให้มีระหว่างการตรวจสอบการอัปเดตที่เกิดจาก RulesManagerService กับการติดตั้ง ถอนการติดตั้ง หรือไม่ดำเนินการใดๆ หลังจากนี้ ระบบอาจสร้างทริกเกอร์ความน่าเชื่อถือที่เกิดขึ้นเอง | ไม่ |
config_timeZoneRulesCheckRetryCount |
จำนวนการตรวจสอบการอัปเดตที่ไม่สําเร็จตามลําดับที่อนุญาตก่อนที่ RulesManagerService จะหยุดสร้างการตรวจสอบเพิ่มเติม | ไม่ |
การลบล้างการกำหนดค่าควรอยู่ในอิมเมจระบบ (ไม่ใช่ของผู้ให้บริการหรืออื่นๆ) เนื่องจากอุปกรณ์ที่กำหนดค่าไม่ถูกต้องอาจปฏิเสธที่จะบูต หากการลบล้างการกำหนดค่าอยู่ในอิมเมจของผู้ให้บริการ การอัปเดตเป็นอิมเมจของระบบที่ไม่มีแอป Data (หรือมีชื่อแพ็กเกจแอป Data/Updater อื่น) จะถือว่าเป็นการกำหนดค่าที่ไม่ถูกต้อง
การทดสอบ xTS
xTS หมายถึงชุดทดสอบเฉพาะ OEM ที่คล้ายกับชุดทดสอบ Android มาตรฐานที่ใช้ Tradefed (เช่น CTS และ VTS) OEM ที่มีชุดทดสอบดังกล่าวสามารถเพิ่มการทดสอบการอัปเดตเขตเวลาของ Android ที่มีให้ในส่วนต่อไปนี้
packages/apps/TimeZoneData/testing/xtsมีโค้ดที่จําเป็นสําหรับการทดสอบฟังก์ชันอัตโนมัติขั้นพื้นฐานpackages/apps/TimeZoneData/oem_template/xtsมีตัวอย่างโครงสร้างไดเรกทอรีสำหรับการรวมการทดสอบไว้ในชุด xTS รูปแบบ Tradefed OEM จะต้องคัดลอกและปรับแต่งตามความต้องการของตนเช่นเดียวกับไดเรกทอรีเทมเพลตอื่นๆpackages/apps/TimeZoneData/oem_template/data_app_prebuiltมีการกำหนดค่าเวลาสร้างสำหรับการรวม APK ทดสอบที่สร้างไว้ล่วงหน้าซึ่งการทดสอบต้องใช้
สร้างการอัปเดตเขตเวลา
เมื่อ IANA เผยแพร่กฎเขตเวลาชุดใหม่ ทีมไลบรารีหลักของ Android จะสร้างแพตช์เพื่ออัปเดตรุ่นใน AOSP OEM ที่ใช้ระบบและไฟล์การแจกจ่าย Android เวอร์ชันมาตรฐานจะเลือกคอมมิตเหล่านี้ได้ และใช้คอมมิตดังกล่าวเพื่อสร้างแอป Data เวอร์ชันใหม่ จากนั้นจึงเผยแพร่เวอร์ชันใหม่เพื่ออัปเดตอุปกรณ์ในเวอร์ชันที่ใช้งานจริง
เนื่องจากแอป Data มีไฟล์การแจกจ่ายที่เชื่อมโยงกับเวอร์ชัน Android อย่างใกล้ชิด OEM จึงต้องสร้างแอป Data เวอร์ชันใหม่สำหรับทุกรุ่น Android ที่รองรับซึ่ง OEM ต้องการอัปเดต ตัวอย่างเช่น หาก OEM ต้องการอัปเดตอุปกรณ์ Android 8.1, 9 และ 10 จะต้องดำเนินการตามกระบวนการนี้ 3 ครั้ง
ขั้นตอนที่ 1: อัปเดตไฟล์ข้อมูลระบบ/เขตเวลาและภายนอก/icu
ในขั้นตอนนี้ OEM จะนำการคอมมิต Android ที่ใช้จริงสำหรับ system/timezone และ external/icu จากสาขา release-dev ใน AOSP มาใช้กับสำเนาซอร์สโค้ด Android
การแก้ไข AOSP สำหรับระบบ/เขตเวลาจะมีไฟล์ที่อัปเดตแล้วใน system/timezone/input_data และ system/timezone/output_data OEM ที่ต้องการทำการแก้ไขเพิ่มเติมในเครื่องสามารถแก้ไขไฟล์อินพุต จากนั้นใช้ไฟล์ใน system/timezone/input_data และ external/icu เพื่อสร้างไฟล์ใน output_data
ไฟล์ที่สําคัญที่สุดคือ system/timezone/output_data/distro/distro.zip ซึ่งจะรวมอยู่โดยอัตโนมัติเมื่อสร้าง APK ของแอปข้อมูล
ขั้นตอนที่ 2: อัปเดตรหัสเวอร์ชันของแอปข้อมูล
ในขั้นตอนนี้ OEM จะอัปเดตรหัสเวอร์ชันของแอป Data โดยบิลด์จะรับ distro.zip โดยอัตโนมัติ แต่แอป Data เวอร์ชันใหม่ต้องมีรหัสเวอร์ชันใหม่เพื่อให้ระบบจดจำว่าเป็นเวอร์ชันใหม่และใช้แทนแอป Data ที่โหลดไว้ล่วงหน้าหรือแอป Data ที่ติดตั้งในอุปกรณ์จากการอัปเดตครั้งก่อนหน้า
เมื่อสร้างแอปข้อมูลโดยใช้ไฟล์ที่คัดลอกจาก package/apps/TimeZoneData/oem_template/data_app คุณจะดูรหัสเวอร์ชัน/ชื่อเวอร์ชันที่ใช้กับ APK ได้ใน Android.mk
TIME_ZONE_DATA_APP_VERSION_CODE := TIME_ZONE_DATA_APP_VERSION_NAME :=
รายการที่คล้ายกันจะอยู่ใน testing/Android.mk (แต่รหัสเวอร์ชันทดสอบต้องสูงกว่าเวอร์ชันของภาพระบบ) ดูรายละเอียดได้ที่รูปแบบกลยุทธ์รหัสเวอร์ชันตัวอย่าง หากใช้รูปแบบตัวอย่างหรือรูปแบบที่คล้ายกัน ก็ไม่จำเป็นต้องอัปเดตรหัสเวอร์ชันทดสอบ เนื่องจากระบบรับประกันว่ารหัสเวอร์ชันทดสอบจะสูงกว่ารหัสเวอร์ชันจริง
ขั้นตอนที่ 3: บิลด์อีกครั้ง เซ็น ทดสอบ และเผยแพร่
ในขั้นตอนนี้ OEM จะสร้าง APK อีกครั้งโดยใช้ tapas, รับรอง APK ที่สร้างขึ้น จากนั้นทดสอบและเผยแพร่ APK
- สำหรับอุปกรณ์ที่ยังไม่ได้เปิดตัว (หรือเมื่อเตรียมการอัปเดตระบบสำหรับอุปกรณ์ที่เปิดตัวแล้ว) ให้ส่ง APK ใหม่ในไดเรกทอรีที่สร้างไว้ล่วงหน้าของแอป Data เพื่อให้แน่ใจว่าอิมเมจระบบและการทดสอบ xTS มี APK เวอร์ชันล่าสุด OEM ควรทดสอบว่าไฟล์ใหม่ทำงานได้อย่างถูกต้อง (กล่าวคือ ผ่าน CTS และการทดสอบอัตโนมัติและด้วยตนเองสำหรับ OEM โดยเฉพาะ)
- สำหรับอุปกรณ์ที่เปิดตัวแล้วซึ่งไม่ได้รับการอัปเดตระบบอีกต่อไป APK ที่เซ็นชื่อแล้วอาจเผยแพร่ผ่าน App Store เท่านั้น
OEM มีหน้าที่รับผิดชอบในการควบคุมคุณภาพและการทดสอบแอป Data ที่อัปเดตแล้วในอุปกรณ์ของตนก่อนการเผยแพร่
กลยุทธ์รหัสเวอร์ชันของแอปข้อมูล
แอปข้อมูลต้องมีกลยุทธ์การกำหนดเวอร์ชันที่เหมาะสมเพื่อให้อุปกรณ์ได้รับ APK ที่ถูกต้อง เช่น หากได้รับการอัปเดตระบบที่มี APK เก่ากว่าที่ดาวน์โหลดจาก App Store คุณควรเก็บเวอร์ชัน App Store ไว้
รหัสเวอร์ชัน APK ควรมีข้อมูลต่อไปนี้
- เวอร์ชันรูปแบบ Distro (หลัก + ย่อย)
- หมายเลขเวอร์ชันแบบเพิ่ม (ทึบแสง)
ปัจจุบันระดับ API ของแพลตฟอร์มมีความเกี่ยวข้องอย่างมากกับเวอร์ชันรูปแบบของดิสโทร เนื่องจากระดับ API แต่ละระดับมักจะเชื่อมโยงกับ ICU เวอร์ชันใหม่ (ซึ่งทำให้ไฟล์ดิสโทรใช้ร่วมกันไม่ได้) ในอนาคต Android อาจเปลี่ยนแปลงข้อมูลนี้เพื่อให้ไฟล์การแจกจ่ายใช้งานได้กับแพลตฟอร์ม Android หลายรุ่น (และไม่ได้ใช้ระดับ API ในรูปแบบรหัสเวอร์ชันแอปข้อมูล)
ตัวอย่างกลยุทธ์รหัสเวอร์ชัน
รูปแบบตัวเลขเวอร์ชันตัวอย่างนี้ช่วยให้มั่นใจได้ว่าเวอร์ชันรูปแบบการจำหน่ายที่สูงกว่าจะแทนที่เวอร์ชันรูปแบบการจำหน่ายที่ต่ำกว่า
AndroidManifest.xml ใช้ android:minSdkVersion เพื่อให้มั่นใจว่าอุปกรณ์รุ่นเก่าจะไม่ได้รับการอัปเดตเป็นเวอร์ชันที่มีรูปแบบการจำหน่ายสูงกว่าที่รองรับ
รูปที่ 6 ตัวอย่างกลยุทธ์รหัสเวอร์ชัน
| ตัวอย่าง | ค่า | วัตถุประสงค์ |
|---|---|---|
| Y | สงวนไว้ | อนุญาตให้ใช้รูปแบบ/APK ทดสอบอื่นในอนาคต โดยค่าเริ่มต้น (โดยนัย) จะเป็น 0 เนื่องจากประเภทพื้นฐานเป็นประเภท int 32 บิตที่มีเครื่องหมายบวกลบ สคีมานี้จึงรองรับการแก้ไขรูปแบบการนับในอนาคตได้สูงสุด 2 ครั้ง |
| 01 | เวอร์ชันรูปแบบหลัก | ติดตามเวอร์ชันรูปแบบหลัก 3 หลักที่เป็นทศนิยม รูปแบบการแจกจ่ายรองรับทศนิยม 3 หลัก แต่จะใช้เพียง 2 หลักเท่านั้น แต่ไม่น่าจะมีค่าถึง 100 เนื่องจากการเพิ่มขึ้นอย่างมากที่คาดไว้ในแต่ละระดับ API เวอร์ชันหลัก 1 เทียบเท่ากับ API ระดับ 27 |
| 1 | เวอร์ชันย่อยของรูปแบบ | ติดตามเวอร์ชันย่อยในรูปแบบตัวเลขฐานสิบ 3 หลัก รูปแบบการเผยแพร่รองรับทศนิยม 3 หลัก แต่จะใช้เพียง 1 หลักเท่านั้น แต่ไม่น่าจะมีจำนวนถึง 10 |
| X | สงวนไว้ | เป็น 0 สำหรับรุ่นที่ใช้งานจริง (และอาจแตกต่างออกไปสำหรับ APK ทดสอบ) |
| ZZZZZ | หมายเลขเวอร์ชันแบบทึบ | จำนวนทศนิยมที่จัดสรรตามดีมานด์ มีช่วงพักเพื่อให้อัปเดตโฆษณาคั่นระหว่างหน้าได้หากจำเป็น |
รูปแบบนี้สามารถบรรจุข้อมูลได้ดีขึ้นหากใช้เลขฐาน 2 แทนเลขฐาน 10 แต่รูปแบบนี้มีข้อดีคือมนุษย์อ่านได้ หากช่วงตัวเลขเต็มแล้ว ชื่อแพ็กเกจแอป Data อาจเปลี่ยนแปลง
ชื่อเวอร์ชันคือการแสดงรายละเอียดที่มนุษย์อ่านได้ เช่น major=001,minor=001,iana=2017a, revision=1,respin=2
ตัวอย่างแสดงอยู่ในตารางต่อไปนี้
| # | รหัสรุ่น | minSdkVersion | {Major format version},{Minor format version},{IANA rules version},{Revision} |
|---|---|---|---|
| 1 | 11000010 | O-MR1 | major=001,minor=001,iana=2017a,revision=1 |
| 2 | 21000010 | P | major=002,minor=001,iana=2017a,revision=1 |
| 3 | 11000020 | O-MR1 | major=001,minor=001,iana=2017a,revision=2 |
| 4 | 11000030 | O-MR1 | major=001,minor=001,iana=2017b,revision=1 |
| 5 | 21000020 | P | major=002,minor=001,iana=2017b,revision=1 |
| 6 | 11000040 | O-MR1 | major=001,minor=001,iana=2018a,revision=1 |
| 7 | 21000030 | P | major=002,minor=001,iana=2018a,revision=1 |
| 8 | 1123456789 | - | - |
| 9 | 11000021 | O-MR1 | major=001,minor=001,iana=2017a,revision=2,respin=2 |
- ตัวอย่างที่ 1 และ 2 แสดง APK 2 เวอร์ชันสำหรับรุ่น IANA 2017a เดียวกันซึ่งมีรูปแบบหลักเวอร์ชันต่างกัน 2 มีตัวเลขสูงกว่า 1 ซึ่งจําเป็นเพื่อให้อุปกรณ์รุ่นใหม่ได้รับรูปแบบเวอร์ชันที่สูงกว่า ตัวแปร minSdkVersion ช่วยให้มั่นใจว่าอุปกรณ์ O จะไม่ได้รับการระบุเวอร์ชัน P
- ตัวอย่างที่ 3 เป็นการแก้ไข/แก้ไขสำหรับ 1 และมีตัวเลขสูงกว่า 1
- ตัวอย่างที่ 4 และ 5 แสดงรุ่น 2017b สำหรับ O-MR1 และ P เนื่องจากมีตัวเลขสูงกว่า จึงใช้แทนรุ่น IANA/การแก้ไข Android ก่อนหน้าของรุ่นก่อนหน้า
- ตัวอย่างที่ 6 และ 7 แสดงรุ่น 2018a สำหรับ O-MR1 และ P
- ตัวอย่างที่ 8 แสดงการใช้ Y เพื่อแทนที่รูปแบบ Y=0 โดยสมบูรณ์
- ตัวอย่างที่ 9 แสดงการใช้ช่องว่างระหว่าง 3 และ 4 เพื่อหมุนเวียน APK อีกครั้ง
เนื่องจากอุปกรณ์แต่ละเครื่องมาพร้อมกับ APK เวอร์ชันเริ่มต้นที่เหมาะสมในอิมเมจระบบ จึงไม่มีความเสี่ยงที่จะมีการติดตั้งเวอร์ชัน O-MR1 ในอุปกรณ์ P เนื่องจากมีหมายเลขเวอร์ชันต่ำกว่าเวอร์ชันอิมเมจระบบ P อุปกรณ์ที่ติดตั้งเวอร์ชัน O-MR1 ใน /data ซึ่งได้รับการอัปเดตระบบเป็น P จะใช้เวอร์ชัน /system แทนเวอร์ชัน O-MR1 ใน /data เนื่องจากเวอร์ชัน P สูงกว่าแอปใดๆ ที่มีไว้สำหรับ O-MR1 เสมอ
สร้างแอปข้อมูลโดยใช้ tapas
OEM มีหน้าที่รับผิดชอบในการจัดการแง่มุมส่วนใหญ่ของแอปข้อมูลเขตเวลาและการกำหนดค่าภาพระบบอย่างถูกต้อง แอปข้อมูลมีไว้เพื่อสร้างด้วยบิลด์ tapas ที่จะสร้าง APK ที่เหมาะสมสำหรับการเพิ่มลงในอิมเมจระบบ (สำหรับรุ่นแรก) และเซ็นชื่อและเผยแพร่ผ่าน App Store (สำหรับการอัปเดตครั้งต่อๆ ไป)
Tapas เป็นระบบการสร้าง Android เวอร์ชันที่ปรับให้เล็กลงซึ่งใช้สคีมาต้นทางที่ลดลงเพื่อสร้างแอปเวอร์ชันที่เผยแพร่ได้ OEM ที่คุ้นเคยกับระบบบิลด์ Android ปกติควรรู้จักไฟล์บิลด์จากบิลด์แพลตฟอร์ม Android ปกติ
สร้างไฟล์ Manifest
โดยทั่วไปแล้ว ต้นไม้แหล่งที่มาที่ลดลงจะสร้างขึ้นด้วยไฟล์ Manifest ที่กําหนดเองซึ่งอ้างอิงเฉพาะโปรเจ็กต์ Git ที่ระบบบิลด์จําเป็นต้องใช้และสำหรับการสร้างแอป หลังจากทําตามวิธีการในการสร้างแอป Data แล้ว OEM ควรมีโปรเจ็กต์ Git สำหรับ OEM โดยเฉพาะอย่างน้อย 2 โปรเจ็กต์ซึ่งสร้างขึ้นโดยใช้ไฟล์เทมเพลตในส่วนpackages/apps/TimeZoneData/oem_template
- โปรเจ็กต์ Git 1 โปรเจ็กต์มีไฟล์แอป เช่น Manifest และไฟล์บิลด์ที่จําเป็นสําหรับสร้างไฟล์ APK ของแอป (เช่น
vendor/oem/apps/TimeZoneData) โปรเจ็กต์นี้ยังมีกฎการสร้างสําหรับ APK ทดสอบที่การทดสอบ xTS สามารถใช้ได้ - โปรเจ็กต์ Git 1 โปรเจ็กต์มี APK ที่ลงนามซึ่งสร้างโดยบิลด์แอปเพื่อรวมไว้ในบิลด์อิมเมจระบบและการทดสอบ xTS
บิลด์แอปใช้ประโยชน์จากโปรเจ็กต์ Git อื่นๆ อีกหลายโปรเจ็กต์ที่แชร์กับบิลด์แพลตฟอร์มหรือมีไลบรารีโค้ดที่ไม่ขึ้นอยู่กับ OEM
ข้อมูลโค้ดไฟล์ Manifest ต่อไปนี้ประกอบด้วยชุดโปรเจ็กต์ Git ขั้นต่ำที่จําเป็นเพื่อรองรับบิลด์ O-MR1 ของแอปข้อมูลเขตเวลา OEM ต้องเพิ่มโปรเจ็กต์ Git สำหรับ OEM โดยเฉพาะ (ซึ่งโดยทั่วไปจะมีโปรเจ็กต์ที่มีใบรับรองการรับรอง) ลงในไฟล์ Manifest นี้ และอาจกําหนดค่าสาขาต่างๆ ตามความเหมาะสม
<!-- Tapas Build --> <project path="build" name="platform/build"> <copyfile src="core/root.mk" dest="Makefile" /> </project> <project path="prebuilts/build-tools" name="platform/prebuilts/build-tools" clone-depth="1" /> <project path="prebuilts/go/linux-x86" name="platform/prebuilts/go/linux-x86" clone-depth="1" /> <project path="build/blueprint" name="platform/build/blueprint" /> <project path="build/kati" name="platform/build/kati" /> <project path="build/soong" name="platform/build/soong"> <linkfile src="root.bp" dest="Android.bp" /> <linkfile src="bootstrap.bash" dest="bootstrap.bash" /> </project> <!-- SDK for system / public API stubs --> <project path="prebuilts/sdk" name="platform/prebuilts/sdk" clone-depth="1" /> <!-- App source --> <project path="system/timezone" name="platform/system/timezone" /> <project path="packages/apps/TimeZoneData" name="platform/packages/apps/TimeZoneData" /> <!-- Enable repohooks --> <project path="tools/repohooks" name="platform/tools/repohooks" revision="main" clone_depth="1" /> <repo-hooks in-project="platform/tools/repohooks" enabled-list="pre-upload" />
เรียกใช้บิลด์ Tapas
หลังจากสร้างสคีมาต้นทางแล้ว ให้เรียกใช้บิลด์ tapas โดยใช้คำสั่งต่อไปนี้
source build/envsetup.shtapasmake -j30 showcommands dist TARGET_BUILD_APPS='TimeZoneData TimeZoneData_test1 TimeZoneData_test2' TARGET_BUILD_VARIANT=userdebug
การสร้างที่ประสบความสําเร็จจะสร้างไฟล์ในไดเรกทอรี out/dist เพื่อการทดสอบ ไฟล์เหล่านี้สามารถวางไว้ในไดเรกทอรี prebuilts เพื่อรวมไว้ในอิมเมจระบบและ/หรือเผยแพร่ผ่าน App Store สำหรับอุปกรณ์ที่เข้ากันได้