กฎเขตเวลา

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 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/staged RulesManagerService ยังแทนที่หรือลบการดำเนินการที่จัดเตรียมไว้แล้วได้ด้วย
• TimeZoneUpdater ซึ่งเป็นแอประบบที่อัปเดตไม่ได้ (หรือที่เรียกว่าแอปโปรแกรมอัปเดต) OEM ต้องรวมแอปนี้ไว้ในอิมเมจระบบของอุปกรณ์ที่ใช้ฟีเจอร์นี้
• OEM TimeZoneData, แอประบบที่อัปเดตได้ (หรือที่เรียกว่าแอป Data) ซึ่งจะส่งไฟล์ Distro ไปยังอุปกรณ์และทำให้ไฟล์เหล่านั้นพร้อมใช้งานสำหรับแอป Updater OEM ต้องรวมแอปนี้ไว้ในอิมเมจระบบของอุปกรณ์ที่ใช้ฟีเจอร์นี้
• tzdatacheck ไบนารีสำหรับช่วงการบูตที่จําเป็นสําหรับการทํางานอย่างถูกต้องและปลอดภัยของการอัปเดตเขตเวลา

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

การติดตั้งระบบปฏิบัติการ

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

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

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

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

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

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

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

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

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

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

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

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

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

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

รูปแบบนี้สามารถบรรจุข้อมูลได้ดีขึ้นหากใช้เลขฐาน 2 แทนเลขฐาน 10 แต่รูปแบบนี้มีข้อดีตรงที่มนุษย์อ่านได้ หากช่วงตัวเลขเต็มแล้ว ชื่อแพ็กเกจแอป Data อาจเปลี่ยนแปลง

ชื่อเวอร์ชันคือการแสดงรายละเอียดที่มนุษย์อ่านได้ เช่น major=001,minor=001,iana=2017a, revision=1,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.sh
tapas
make -j30 showcommands dist TARGET_BUILD_APPS='TimeZoneData TimeZoneData_test1 TimeZoneData_test2'  TARGET_BUILD_VARIANT=userdebug

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