กฎเขตเวลา

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 โดยกำหนดมาตรฐานข้อมูลที่อาจเปลี่ยนแปลงบ่อยเนื่องด้วยเหตุผลทางศาสนา การเมือง และ ภูมิรัฐศาสตร์

การอัปเดตจะใช้กระบวนการต่อไปนี้

1. IANA จะออกการอัปเดตฐานข้อมูลเขตเวลาเพื่อตอบสนองต่อ รัฐบาลอย่างน้อย 1 ประเทศที่เปลี่ยนกฎเขตเวลาในประเทศของตน
2. Google หรือพาร์ทเนอร์ Android เตรียมการอัปเดตโมดูลข้อมูลเขตเวลา (ไฟล์ APEX) ซึ่งมีเขตเวลาที่อัปเดตแล้ว
3. อุปกรณ์ของผู้ใช้ปลายทางจะดาวน์โหลดการอัปเดต รีบูต แล้วใช้การเปลี่ยนแปลง หลังจากนั้นข้อมูลเขตเวลาของอุปกรณ์จะมีข้อมูลเขตเวลาใหม่ จากการอัปเดต

ดูรายละเอียดเกี่ยวกับโมดูลได้ที่ คอมโพเนนต์ของระบบแบบแยกส่วน

หมายเหตุการเลิกใช้งาน

Android หยุดให้บริการแพตช์เขตเวลาสำหรับ Android 10 ในเดือนสิงหาคม 2026 และ TZDB 2026c เป็นแพตช์สุดท้าย OEM มีตัวเลือกในการสนับสนุน Android 10 ต่อไป

การอัปเดตเขตเวลา (Android 8.1–9)

หมายเหตุ: เราได้นำฟีเจอร์กลไกการอัปเดตข้อมูลเขตเวลาที่อิงตาม APK ออกจาก Android 14 เป็นต้นไปโดยสมบูรณ์แล้ว และคุณจะไม่เห็นฟีเจอร์นี้ในซอร์สโค้ด พาร์ทเนอร์ควรย้ายข้อมูลไปยังโมดูล เขตเวลา Mainline อย่างสมบูรณ์

ใน Android 8.1 และ Android 9 ผู้ผลิตอุปกรณ์สามารถใช้กลไกที่อิงตาม 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 (ซึ่งมีสคริปต์และไฟล์อื่นๆ ที่จำเป็นต่อการ สร้างไฟล์การกระจาย)

คอมโพเนนต์การอัปเดตเขตเวลา

การอัปเดตกฎเขตเวลาเกี่ยวข้องกับการส่งไฟล์ distro ไปยัง อุปกรณ์และการติดตั้งไฟล์ที่อยู่ในนั้นอย่างปลอดภัย การโอนและ การติดตั้งต้องมีสิ่งต่อไปนี้

• ฟังก์ชันการทำงานของบริการแพลตฟอร์ม (timezone.RulesManagerService) ซึ่งปิดใช้อยู่โดยค่าเริ่มต้น OEM ต้องเปิดใช้ฟังก์ชันผ่านการกำหนดค่า RulesManagerService ทำงานในกระบวนการเซิร์ฟเวอร์ของระบบและจัดเตรียม การดำเนินการอัปเดตเขตเวลาโดยการเขียนไปยัง /data/misc/zoneinfo/staged RulesManagerService ยังสามารถแทนที่หรือลบการดำเนินการที่จัดเตรียมไว้แล้วได้ด้วย
• TimeZoneUpdater แอปของระบบที่อัปเดตไม่ได้ (หรือที่เรียกว่าแอป Updater) OEM ต้องรวมแอปนี้ไว้ในอิมเมจระบบ ของอุปกรณ์ที่ใช้ฟีเจอร์นี้
• OEM TimeZoneData แอปของระบบที่อัปเดตได้ (หรือที่เรียกว่า แอปข้อมูล) ซึ่งนำไฟล์การจัดจำหน่ายไปยังอุปกรณ์และทำให้ไฟล์เหล่านั้น พร้อมใช้งานในแอป Updater OEM ต้องรวมแอปนี้ไว้ในอิมเมจระบบของ อุปกรณ์ที่ใช้ฟีเจอร์นี้
• tzdatacheck ไบนารีเวลาบูตที่จำเป็นสำหรับการดำเนินการอัปเดตเขตเวลาอย่างถูกต้องและปลอดภัย

โครงสร้างแหล่งที่มาของ Android มีซอร์สโค้ดทั่วไปสำหรับคอมโพเนนต์ข้างต้น ซึ่ง OEM สามารถเลือกใช้ได้โดยไม่ต้องแก้ไข โค้ดทดสอบ มีไว้เพื่อให้ OEM ตรวจสอบโดยอัตโนมัติ ว่าได้เปิดใช้ฟีเจอร์อย่างถูกต้องแล้ว

การติดตั้ง Distro

กระบวนการติดตั้งการกระจายประกอบด้วยขั้นตอนต่อไปนี้

1. แอปข้อมูลได้รับการอัปเดตผ่านการดาวน์โหลดจาก App Store หรือ การโหลดแอปจากแหล่งที่ไม่รู้จัก กระบวนการเซิร์ฟเวอร์ระบบ (ผ่านคลาส timezone.RulesManagerServer/timezone.PackageTracker) จะตรวจสอบการเปลี่ยนแปลงชื่อแพ็กเกจแอปข้อมูลที่กำหนดค่าและเฉพาะ OEM
   
   

   รูปที่ 1 การอัปเดตแอปข้อมูล

2. กระบวนการเซิร์ฟเวอร์ระบบจะทริกเกอร์การตรวจสอบการอัปเดตโดย ออกอากาศ Intent ที่กำหนดเป้าหมายพร้อมโทเค็นแบบใช้ครั้งเดียวที่ไม่ซ้ำกันไปยังแอป Updater เซิร์ฟเวอร์ระบบจะติดตามโทเค็นล่าสุดที่สร้างขึ้นเพื่อให้ ระบุได้ว่าการตรวจสอบล่าสุดที่ทริกเกอร์เสร็จสมบูรณ์เมื่อใด และจะละเว้นโทเค็นอื่นๆ
   
   

   รูปที่ 2 ทริกเกอร์การตรวจสอบการอัปเดต

3. ในระหว่างการตรวจสอบการอัปเดต แอป Updater จะทำงานต่อไปนี้
   • สอบถามสถานะปัจจุบันของอุปกรณ์โดยการเรียกใช้ RulesManagerService
     
     

     รูปที่ 3 อัปเดตแอปข้อมูลโดยเรียกใช้ RulesManagerService

   • ค้นหาแอป Data โดยการค้นหา URL ของ ContentProvider ที่กำหนดไว้อย่างดีและ ข้อกำหนดของคอลัมน์เพื่อรับข้อมูลเกี่ยวกับการจัดจำหน่าย
     
     

     รูปที่ 4 อัปเดตแอปข้อมูล รับข้อมูลเกี่ยวกับ Distro

4. แอป Updater จะดำเนินการที่เหมาะสมตามข้อมูลที่ได้รับ การดำเนินการที่ใช้ได้มีดังนี้
   • ขอรับการติดตั้ง ระบบจะอ่านข้อมูลการจัดจำหน่ายจากแอปข้อมูล และส่งไปยัง RulesManagerService ในเซิร์ฟเวอร์ระบบ RulesManagerService จะยืนยันอีกครั้งว่าเวอร์ชันรูปแบบการจัดจำหน่ายและเนื้อหา เหมาะสมกับอุปกรณ์และจัดเตรียมการติดตั้ง
   • ขอถอนการติดตั้ง (กรณีนี้เกิดขึ้นได้ยาก) เช่น หากมีการปิดใช้หรือถอนการติดตั้ง APK ที่อัปเดตแล้วใน /data และอุปกรณ์กลับไปใช้เวอร์ชันที่มีอยู่ใน /system
   • ไม่ต้องทำอะไร เกิดขึ้นเมื่อพบว่าการเผยแพร่แอปข้อมูลไม่ถูกต้อง
   ในทุกกรณี แอป Updater จะเรียกใช้ RulesManagerService ด้วยโทเค็นตรวจสอบ เพื่อให้เซิร์ฟเวอร์ระบบทราบว่าการตรวจสอบเสร็จสมบูรณ์และสำเร็จแล้ว
   
   

   รูปที่ 5 การตรวจสอบเสร็จสมบูรณ์แล้ว

5. รีบูตและ tzdatacheck เมื่อเปิดอุปกรณ์ในครั้งถัดไป ไบนารี tzdatacheck จะดำเนินการที่พักไว้ ไบนารี tzdatacheck สามารถ ดำเนินการต่อไปนี้ได้
   • ดำเนินการตามการดำเนินการที่จัดเตรียมไว้โดยจัดการการสร้าง การแทนที่ และ/หรือการลบไฟล์ /data/misc/zoneinfo/current ก่อน ที่คอมโพเนนต์อื่นๆ ของระบบจะเปิดและเริ่มใช้ไฟล์
   • ตรวจสอบว่าไฟล์ใน /data ถูกต้องสำหรับแพลตฟอร์มเวอร์ชันปัจจุบันหรือไม่ ซึ่งอาจไม่ถูกต้องหากอุปกรณ์เพิ่งได้รับการอัปเดตระบบและเวอร์ชันรูปแบบการจัดจำหน่ายมีการเปลี่ยนแปลง
   • ตรวจสอบว่าเวอร์ชันกฎของ IANA เป็นเวอร์ชันเดียวกันหรือใหม่กว่าเวอร์ชันใน /system ซึ่งจะช่วยป้องกันไม่ให้การอัปเดตระบบทำให้อุปกรณ์มีข้อมูลกฎเขตเวลาที่เก่ากว่าข้อมูลที่มีอยู่ในอิมเมจ /system

ความไว้ใจได้

กระบวนการติดตั้งแบบครบวงจรเป็นแบบอะซิงโครนัสและแบ่งออกเป็น 3 กระบวนการของระบบปฏิบัติการ ในระหว่างการติดตั้ง อุปกรณ์อาจไม่มีกระแสไฟเข้า พื้นที่ในดิสก์ไม่เพียงพอ หรือพบปัญหาอื่นๆ ซึ่งทำให้การตรวจสอบการติดตั้งไม่สมบูรณ์ ในกรณีที่อัปเดตไม่สำเร็จที่ดีที่สุด แอป Updater จะแจ้งให้เซิร์ฟเวอร์ระบบทราบว่าการอัปเดตไม่สำเร็จ ส่วนในกรณีที่อัปเดตไม่สำเร็จที่แย่ที่สุด RulesManagerService จะไม่ได้รับการเรียกใช้เลย

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

ความปลอดภัย

เมื่อเปิดใช้ โค้ด RulesManagerService ในเซิร์ฟเวอร์ระบบจะทำการตรวจสอบหลายอย่างเพื่อให้มั่นใจว่าระบบปลอดภัยต่อการใช้งาน

• ปัญหาที่บ่งบอกว่าอิมเมจระบบได้รับการกำหนดค่าอย่างไม่ถูกต้องจะทําให้อุปกรณ์ บูตไม่ได้ ตัวอย่างเช่น การกําหนดค่าแอป Updater หรือ Data ไม่ถูกต้อง หรือแอป Updater หรือ Data ไม่ได้อยู่ใน /system/priv-app
• ปัญหาที่บ่งชี้ว่ามีการติดตั้งแอปข้อมูลที่ไม่ดีจะไม่ทําให้อุปกรณ์บูตไม่ได้ แต่จะทําให้ระบบไม่ทริกเกอร์การตรวจสอบการอัปเดต ตัวอย่างเช่น ไม่มีสิทธิ์ของระบบที่จําเป็น หรือแอปข้อมูลไม่แสดง ContentProvider ใน URI ที่คาดไว้

ระบบจะบังคับใช้สิทธิ์ของไฟล์สำหรับไดเรกทอรี /data/misc/zoneinfo โดยใช้กฎ SELinux เช่นเดียวกับ APK อื่นๆ แอปข้อมูลต้องได้รับการลงนามโดยใช้คีย์เดียวกันกับที่ใช้ลงนามในเวอร์ชัน /system/priv-app คาดว่าแอปข้อมูลจะมีชื่อแพ็กเกจและคีย์เฉพาะของ OEM

ผสานรวมการอัปเดตเขตเวลา

โดยปกติแล้ว OEM จะทำสิ่งต่อไปนี้เพื่อเปิดใช้ฟีเจอร์อัปเดตเขตเวลา

• สร้างแอปข้อมูลของตนเอง
• รวมแอป Updater และ Data ไว้ในการสร้างอิมเมจระบบ
• กำหนดค่าเซิร์ฟเวอร์ระบบเพื่อเปิดใช้ RulesManagerService

การเตรียมพร้อม

ก่อนเริ่มต้น OEM ควรตรวจสอบนโยบาย การประกันคุณภาพ และข้อควรพิจารณาด้านความปลอดภัยต่อไปนี้

• สร้างคีย์การลงนามเฉพาะแอปสำหรับแอปข้อมูล
• สร้างกลยุทธ์การเผยแพร่และการกำหนดเวอร์ชันสำหรับการอัปเดตเขตเวลา เพื่อทำความเข้าใจว่าอุปกรณ์ใดจะได้รับการอัปเดตและวิธีที่อุปกรณ์เหล่านั้นจะช่วยให้มั่นใจได้ว่า การอัปเดตจะติดตั้งเฉพาะในอุปกรณ์ที่จำเป็นเท่านั้น ตัวอย่างเช่น OEM อาจต้องการ มีแอปข้อมูลเดียวสำหรับอุปกรณ์ทั้งหมด หรืออาจเลือกมีแอปข้อมูลที่แตกต่างกัน สำหรับอุปกรณ์ที่แตกต่างกัน การตัดสินใจนี้ส่งผลต่อการเลือกชื่อแพ็กเกจ ซึ่งอาจส่งผลต่อรหัสเวอร์ชันที่ใช้และกลยุทธ์ QA
• ทำความเข้าใจว่าผู้ใช้ต้องการใช้ข้อมูลเขตเวลาของ Android ในสต็อก จาก AOSP หรือสร้างข้อมูลของตนเอง

สร้างแอปข้อมูล

AOSP มีซอร์สโค้ดและกฎการสร้างทั้งหมดที่จำเป็นต่อการสร้างแอปข้อมูลใน packages/apps/TimeZoneData พร้อมคำสั่งและเทมเพลตตัวอย่างสำหรับ AndroidManifest.xml และไฟล์อื่นๆ ที่อยู่ใน packages/apps/TimeZoneData/oem_template ตัวอย่างเทมเพลตประกอบด้วย ทั้งเป้าหมายบิลด์สำหรับ APK ของแอปข้อมูลจริงและเป้าหมายเพิ่มเติมสำหรับ การสร้างแอปข้อมูลเวอร์ชันทดสอบ

OEM สามารถปรับแต่งแอป Data ด้วยไอคอน ชื่อ คำแปล และ รายละเอียดอื่นๆ ของตนเอง อย่างไรก็ตาม เนื่องจากเปิดแอป Data ไม่ได้ ไอคอนจึงปรากฏเฉพาะในหน้าจอการตั้งค่า > แอป

แอปข้อมูลมีไว้เพื่อสร้างด้วยบิลด์ tapas ซึ่งสร้าง APK ที่เหมาะสำหรับการเพิ่มลงในอิมเมจระบบ (สำหรับการเปิดตัวครั้งแรก) และลงนามและจัดจำหน่ายผ่าน App Store (สำหรับการอัปเดตครั้งต่อๆ ไป) ดูรายละเอียดเกี่ยวกับการใช้ Tapas ได้ที่การสร้างแอปข้อมูลโดยใช้ Tapas

OEM ต้องติดตั้งแอป Data ที่สร้างไว้ล่วงหน้าในอิมเมจระบบของอุปกรณ์ใน /system/priv-app หากต้องการรวม APK ที่สร้างไว้ล่วงหน้า (สร้างโดยกระบวนการบิลด์ tapas ) ไว้ในอิมเมจระบบ OEM สามารถคัดลอกไฟล์ตัวอย่างใน packages/apps/TimeZoneData/oem_template/data_app_prebuilt เทมเพลตตัวอย่างยังมีเป้าหมายการสร้างสำหรับการรวมเวอร์ชันทดสอบของ แอปข้อมูลในชุดทดสอบด้วย

รวมแอป Updater และ Data ไว้ในอิมเมจระบบ

OEM ต้องวาง APK ของแอป Updater และ Data ไว้ในไดเรกทอรี /system/priv-app ของอิมเมจระบบ โดยการดำเนินการนี้ บิลด์อิมเมจระบบต้องมีแอป Updater และเป้าหมายที่สร้างไว้ล่วงหน้าของแอป Data อย่างชัดเจน

แอปโปรแกรมอัปเดตควรลงนามด้วยคีย์แพลตฟอร์มและรวมไว้เป็นแอปของระบบอื่นๆ เป้าหมายจะกำหนดไว้ใน packages/apps/TimeZoneUpdater เป็น TimeZoneUpdater การรวมแอปข้อมูลจะขึ้นอยู่กับ OEM และขึ้นอยู่กับชื่อเป้าหมายที่เลือกสำหรับ การสร้างล่วงหน้า

กำหนดค่าเซิร์ฟเวอร์ระบบ

หากต้องการเปิดใช้การอัปเดตเขตเวลา OEM สามารถกำหนดค่าเซิร์ฟเวอร์ระบบได้โดย การลบล้างพร็อพเพอร์ตี้การกำหนดค่าที่กำหนดไว้ใน frameworks/base/core/res/res/values/config.xml

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

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

การทดสอบ 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 ที่ใช้ไฟล์ระบบและไฟล์ distro ของ Android สต็อกสามารถเลือกคอมมิตเหล่านี้ ใช้เพื่อสร้างแอป Data เวอร์ชันใหม่ แล้วเผยแพร่เวอร์ชันใหม่เพื่ออัปเดตอุปกรณ์ในการผลิต

เนื่องจากแอปข้อมูลมีไฟล์การจัดจำหน่ายที่เชื่อมโยงอย่างใกล้ชิดกับ Android เวอร์ชันต่างๆ OEM จึงต้องสร้างแอปข้อมูลเวอร์ชันใหม่สำหรับ 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 ของแอป Data

ขั้นตอนที่ 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 ใหม่ในไดเรกทอรีของแอปข้อมูลที่สร้างไว้ล่วงหน้า เพื่อให้มั่นใจว่าอิมเมจระบบและการทดสอบ xTS มี APK ล่าสุด OEM ควร ทดสอบว่าไฟล์ใหม่ทำงานได้อย่างถูกต้อง (กล่าวคือ ผ่าน CTS และการทดสอบอัตโนมัติและด้วยตนเองที่ OEM ระบุ)
• สำหรับอุปกรณ์ที่เปิดตัวแล้วซึ่งไม่ได้รับการอัปเดตระบบอีกต่อไป อาจมีการเผยแพร่ APK ที่ลงนามแล้วผ่าน App Store เท่านั้น

OEM มีหน้าที่รับผิดชอบในการประกันคุณภาพและทดสอบแอป Data ที่อัปเดตแล้วในอุปกรณ์ของตนก่อนที่จะเผยแพร่

กลยุทธ์รหัสเวอร์ชันของแอปข้อมูล

แอปข้อมูลต้องมีกลยุทธ์การกำหนดเวอร์ชัน ที่เหมาะสมเพื่อให้มั่นใจว่าอุปกรณ์จะได้รับ APK ที่ถูกต้อง ตัวอย่างเช่น หากได้รับการอัปเดตระบบที่มี APK เก่ากว่า APK ที่ดาวน์โหลดจาก App Store คุณควรเก็บเวอร์ชันจาก App Store ไว้

รหัสเวอร์ชัน APK ควรมีข้อมูลต่อไปนี้

• เวอร์ชันรูปแบบการจัดจำหน่าย (หลัก + ย่อย)
• หมายเลขเวอร์ชันที่เพิ่มขึ้น (ทึบแสง)

ปัจจุบันระดับ API ของแพลตฟอร์มมีความสัมพันธ์อย่างมากกับเวอร์ชันรูปแบบการจัดจำหน่าย เนื่องจากโดยปกติแล้วระดับ API แต่ละระดับจะเชื่อมโยงกับ ICU เวอร์ชันใหม่ (ซึ่ง ทำให้ไฟล์การจัดจำหน่ายเข้ากันไม่ได้) ในอนาคต Android อาจเปลี่ยนแปลงสิ่งนี้เพื่อให้ไฟล์ distro ทำงานได้ในแพลตฟอร์ม Android หลายรุ่น (และไม่ได้ใช้ระดับ API ในรูปแบบรหัสเวอร์ชันของแอป Data)

ตัวอย่างกลยุทธ์รหัสเวอร์ชัน

รูปแบบการกำหนดหมายเลขเวอร์ชันในตัวอย่างนี้ช่วยให้มั่นใจได้ว่าเวอร์ชันรูปแบบการจัดจำหน่ายที่สูงกว่าจะแทนที่เวอร์ชันรูปแบบการจัดจำหน่ายที่ต่ำกว่า AndroidManifest.xml ใช้ android:minSdkVersion เพื่อ ให้มั่นใจว่าอุปกรณ์รุ่นเก่าจะไม่ได้รับเวอร์ชันที่มีรูปแบบการจัดจำหน่าย เวอร์ชันสูงกว่าที่อุปกรณ์รองรับ

รูปที่ 6 ตัวอย่างกลยุทธ์รหัสเวอร์ชัน

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

ชื่อเวอร์ชันคือการแสดงรายละเอียดที่มนุษย์อ่านได้ เช่น major=001,minor=001,iana=2017a, revision=1,respin=2 ตัวอย่างแสดงอยู่ในตารางต่อไปนี้

• ตัวอย่างที่ 1 และ 2 แสดง APK 2 เวอร์ชันสำหรับการเผยแพร่ IANA ปี 2017a เดียวกัน ที่มีเวอร์ชันรูปแบบหลักต่างกัน 2 สูงกว่า 1 ซึ่งเป็น สิ่งจำเป็นเพื่อให้มั่นใจว่าอุปกรณ์รุ่นใหม่จะได้รับเวอร์ชันรูปแบบที่สูงกว่า minSdkVersion ช่วยให้มั่นใจได้ว่าจะไม่มีการจัดหาเวอร์ชัน P ให้กับอุปกรณ์ O
• ตัวอย่างที่ 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 ที่ระบบบิลด์ต้องการและใช้ในการบิลด์ แอป หลังจากทำตามวิธีการในการสร้างแอปข้อมูลแล้ว OEM ควรมีโปรเจ็กต์ Git อย่างน้อย 2 รายการที่เฉพาะเจาะจงสำหรับ OEM ซึ่งสร้างขึ้นโดยใช้ไฟล์เทมเพลตในpackages/apps/TimeZoneData/oem_template

• โปรเจ็กต์ Git หนึ่งโปรเจ็กต์มีไฟล์แอป เช่น ไฟล์ Manifest และไฟล์ บิลด์ที่จำเป็นต่อการสร้างไฟล์ APK ของแอป (เช่น vendor/oem/apps/TimeZoneData) โปรเจ็กต์นี้ยังมี กฎการบิลด์สำหรับ APK ของการทดสอบที่การทดสอบ xTS ใช้ได้ด้วย
• โปรเจ็กต์ Git หนึ่งโปรเจ็กต์มี 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.sh
tapas
make -j30 showcommands dist TARGET_BUILD_APPS='TimeZoneData TimeZoneData_test1 TimeZoneData_test2'  TARGET_BUILD_VARIANT=userdebug

การสร้างที่สำเร็จจะสร้างไฟล์ในไดเรกทอรี out/dist สำหรับ การทดสอบ คุณวางไฟล์เหล่านี้ลงในไดเรกทอรี prebuilts เพื่อรวมไว้ใน อิมเมจระบบและ/หรือเผยแพร่ผ่าน App Store สำหรับอุปกรณ์ที่เข้ากันได้