กฎเขตเวลา

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. เอียนา เผยแพร่การอัปเดตของฐานข้อมูลเขตเวลา เผยแพร่การอัปเดตตาม มีรัฐบาลอย่างน้อย 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

ไฟล์ Distro .zip ประกอบด้วยไฟล์ข้อมูลที่ต้องใช้ในการสร้าง ไดเรกทอรี /data/misc/zoneinfo/current นอกจากนี้ ไฟล์ Distro ยัง มีข้อมูลเมตาที่ช่วยให้อุปกรณ์ตรวจหาปัญหาการกำหนดเวอร์ชันได้

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

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

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

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

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

การติดตั้ง Distro

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ความปลอดภัย

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

แอป Updater ควรลงชื่อด้วยคีย์แพลตฟอร์มและรวมไว้กับคีย์แพลตฟอร์ม แอประบบอื่นๆ เป้าหมายจะกำหนดใน 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/โปรแกรมอัปเดตที่ต่างกัน) จะถือว่าเป็น การกำหนดค่าที่ไม่ถูกต้อง

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

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

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

ขั้นตอนที่ 3: สร้างใหม่ ลงนาม ทดสอบ และเผยแพร่

ในขั้นตอนนี้ OEM จะสร้าง APK ใหม่โดยใช้ทาปาส จากนั้นลงนาม APK จากนั้นทดสอบและเผยแพร่ APK ด้วยคำสั่งต่อไปนี้

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

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

กลยุทธ์โค้ดเวอร์ชันแอปข้อมูล

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

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

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

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

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

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

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

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

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

• ตัวอย่างที่ 1 และ 2 แสดง APK 2 เวอร์ชันสำหรับ IANA รุ่นเดียวกันในปี 2017 ที่มีเวอร์ชันรูปแบบหลักแตกต่างกัน 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 จะเป็นผู้รับผิดชอบในการจัดการแง่มุมส่วนใหญ่ของแอปข้อมูล และ กำลังกำหนดค่าอิมเมจระบบอย่างถูกต้อง แอป Data มีไว้สร้างขึ้นมา ด้วยเวอร์ชันทาปาสที่สร้าง APK ที่เหมาะสำหรับการเพิ่มลงใน อิมเมจระบบ (สำหรับรุ่นแรก) และลงนามและเผยแพร่ผ่าน app store (สำหรับการอัปเดตครั้งต่อๆ ไป)

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

สร้างไฟล์ Manifest

แผนผังแหล่งที่มาที่ลดลงมักจะสร้างด้วยไฟล์ Manifest ที่กำหนดเองซึ่ง จะอ้างอิงเฉพาะโปรเจ็กต์ Git ที่จำเป็นสำหรับระบบบิลด์และสำหรับการสร้าง แอป หลังจากทำตามคำแนะนำใน การสร้างแอปข้อมูล, OEM ควรมี โปรเจ็กต์ Git สำหรับ OEM โดยเฉพาะอย่างน้อย 2 โปรเจ็กต์ที่สร้างด้วยไฟล์เทมเพลตภายใต้ packages/apps/TimeZoneData/oem_template:

• โปรเจ็กต์ Git หนึ่งโปรเจ็กต์มีไฟล์แอป เช่น ไฟล์ Manifest และ ไฟล์บิลด์ที่ต้องใช้สร้างไฟล์ APK ของแอป (เช่น vendor/oem/apps/TimeZoneData) โปรเจ็กต์นี้ มีกฎบิลด์สำหรับ APK การทดสอบที่สามารถใช้โดยการทดสอบ xTS
• โปรเจ็กต์ Git หนึ่งโปรเจ็กต์มี APK ที่รับรองแล้วซึ่งสร้างโดยบิลด์ของแอปสำหรับ การรวมในการสร้างอิมเมจของระบบและการทดสอบ xTS

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

ข้อมูลโค้ดไฟล์ Manifest ต่อไปนี้มีชุดโปรเจ็กต์ Git น้อยที่สุด ที่จำเป็นต่อการรองรับบิลด์ O-MR1 ของแอป Data เขตเวลา 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" />

เปิดร้านทาปาส

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

source build/envsetup.sh
tapas
make -j30 showcommands dist TARGET_BUILD_APPS='TimeZoneData TimeZoneData_test1 TimeZoneData_test2'  TARGET_BUILD_VARIANT=userdebug

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