กฎเขตเวลา

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ความปลอดภัย

เมื่อเปิดใช้ โค้ด 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 จากสาขาการพัฒนารุ่นใน 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 ใหม่โดยใช้ทาปาส จากนั้นลงนาม APK ที่สร้างขึ้น จากนั้นทดสอบและเผยแพร่ APK

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

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

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

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

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

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

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

ตัวอย่างกลยุทธ์เกี่ยวกับโค้ดเวอร์ชัน

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

สร้างแอป Data โดยใช้ทาปาส

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

หลังจากสร้างแผนผังต้นทางแล้ว ให้เรียกใช้บิลด์ทาปาสโดยใช้คำสั่งต่อไปนี้

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 สำหรับอุปกรณ์ที่เข้ากันได้