กฎเขตเวลา

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

สำหรับรายละเอียดเกี่ยวกับโมดูล โปรดดูที่ ส่วนประกอบระบบโมดูลา ร์

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

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

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

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

การติดตั้ง Distro

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

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

   

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

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

   

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

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

     

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

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

     

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

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

   

   รูปที่ 5. ตรวจสอบเสร็จสิ้น

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

ความน่าเชื่อถือ

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

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

ความปลอดภัย

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

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

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

การรวมการอัปเดตโซนเวลา

ในการเปิดใช้งานคุณลักษณะการอัปเดตเขตเวลา โดยทั่วไปแล้ว OEM:

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

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

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

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

การสร้างแอพข้อมูล

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

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

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

หมายเหตุ: การลงนาม APK และการจัดการคีย์อย่างปลอดภัยอยู่นอกเหนือขอบเขตของบทความนี้

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

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

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

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

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

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

คุณสมบัติ	คำอธิบาย	จำเป็นต้องแทนที่?
config_enableUpdateableTimeZoneRules	ต้องตั้งค่า true เพื่อเปิดใช้งาน RulesManagerService	ใช่
config_timeZoneRulesUpdateTrackingEnabled	ต้องตั้งค่า true เพื่อให้ระบบรับฟังการเปลี่ยนแปลงในแอป Data	ใช่
config_timeZoneRulesDataPackage	ชื่อแพ็กเกจของแอป Data เฉพาะของ 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 การทดสอบที่สร้างไว้ล่วงหน้าตามที่การทดสอบต้องการ

หมายเหตุ: การตั้งค่าชุดทดสอบเฉพาะ OEM อยู่นอกเหนือขอบเขตของบทความนี้

การสร้างการอัปเดตโซนเวลา

เมื่อ IANA เผยแพร่กฎเขตเวลาชุดใหม่ ทีมไลบรารีหลักของ Android จะสร้างแพตช์เพื่ออัปเดตรุ่นใน AOSP OEM ที่ใช้ระบบสต็อก Android และไฟล์ distro สามารถรับคอมมิตเหล่านี้ ใช้เพื่อสร้างแอป Data เวอร์ชันใหม่ จากนั้นปล่อยเวอร์ชันใหม่เพื่ออัปเดตอุปกรณ์ในเวอร์ชันที่ใช้งานจริง

หมายเหตุ: ขั้นตอนต่อไปนี้ไม่ได้อธิบายวิธีอัปเดตไฟล์ข้อมูลพื้นฐานในอิมเมจ /system ซึ่งจำเป็นสำหรับการเตรียมอิมเมจจากโรงงานหรือการอัปเดตระบบ กระบวนการนั้นยังสร้างไฟล์ distro เพื่อรวมไว้ในแอพ Data สำหรับคำแนะนำในการอัพเดตไฟล์แพลตฟอร์ม โปรดดูที่ /system/timezone/README.android

เนื่องจากแอป Data มีไฟล์ distro ที่เชื่อมโยงกับเวอร์ชัน Android อย่างใกล้ชิด OEM จึงต้องสร้างเวอร์ชันใหม่ของแอป Data สำหรับ Android ทุก รุ่นที่รองรับซึ่ง OEM ต้องการอัปเดต ตัวอย่างเช่น หาก OEM ต้องการให้การอัปเดตสำหรับอุปกรณ์ Android 8.1, 9 และ 10 พวกเขาจะต้องดำเนินการให้เสร็จสิ้นสามครั้ง

ขั้นตอนที่ 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: การอัปเดตรหัสเวอร์ชันของแอป Data

ในขั้นตอนนี้ OEM จะอัปเดตรหัสเวอร์ชันของแอป Data บิลด์จะรับ distro.zip โดยอัตโนมัติ แต่แอป Data เวอร์ชันใหม่ต้องมีรหัสเวอร์ชันใหม่จึงจะรับรู้ได้ว่าเป็นเวอร์ชันใหม่และใช้เพื่อแทนที่แอป 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 ใหม่ในไดเรกทอรีที่สร้างไว้ล่วงหน้าของแอปข้อมูลเพื่อให้แน่ใจว่าอิมเมจระบบและการทดสอบ 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 จะไม่ถูกใช้ในรูปแบบรหัสเวอร์ชันแอปข้อมูล)

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

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

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

ตัวอย่าง	ค่า	วัตถุประสงค์
Y	ที่สงวนไว้	อนุญาตให้ใช้แผนทางเลือกในอนาคต/ทดสอบ APK เริ่มแรก (โดยนัย) 0 เนื่องจากประเภทพื้นฐานเป็นประเภท int 32 บิตแบบมีลายเซ็น แบบแผนนี้รองรับการแก้ไขรูปแบบการกำหนดหมายเลขในอนาคตสูงสุดสองครั้ง
01	เวอร์ชันรูปแบบหลัก	ติดตามเวอร์ชันรูปแบบหลักทศนิยม 3 หลัก รูปแบบ distro รองรับทศนิยม 3 หลัก แต่ที่นี่ใช้เพียง 2 หลักเท่านั้น ไม่น่าจะถึง 100 เมื่อพิจารณาถึงการเพิ่มขึ้นที่สำคัญต่อระดับ API ที่คาดไว้ เวอร์ชันหลัก 1 เทียบเท่ากับ API ระดับ 27
1	เวอร์ชันรูปแบบรอง	ติดตามเวอร์ชันรูปแบบรองทศนิยม 3 หลัก รูปแบบ distro รองรับทศนิยม 3 หลัก แต่ที่นี่ใช้เพียง 1 หลักเท่านั้น ไม่น่าจะถึง 10
X	ที่สงวนไว้	เป็น 0 สำหรับรุ่นที่ใช้งานจริง (และอาจแตกต่างกันสำหรับ APK ทดสอบ)
ZZZZ	หมายเลขเวอร์ชันทึบแสง	เลขทศนิยมที่จัดสรรตามความต้องการ รวมถึงช่องว่างเพื่อให้สามารถอัปเดตโฆษณาคั่นระหว่างหน้าได้หากจำเป็น

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

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

#	รหัสเวอร์ชัน	minSdkVersion	{เวอร์ชันรูปแบบหลัก},{เวอร์ชันรูปแบบรอง},{เวอร์ชันกฎ IANA},{การแก้ไข}
1	11000010	O-MR1	เมเจอร์=001,ไมเนอร์=001,iana=2017a,ฉบับแก้ไข=1
2	21000010	พี	เมเจอร์=002,ไมเนอร์=001,iana=2017a,ฉบับแก้ไข=1
3	11000020	O-MR1	เมเจอร์=001,ไมเนอร์=001,iana=2017a,แก้ไข=2
4	11000030	O-MR1	เมเจอร์=001,ไมเนอร์=001,iana=2017b,แก้ไข=1
5	21000020	พี	เมเจอร์=002,ไมเนอร์=001,iana=2017b,ฉบับแก้ไข=1
6	11000040	O-MR1	major=001, minor=001,iana=2018a,revision=1
7	21000030	พี	เมเจอร์=002,ไมเนอร์=001,iana=2018a,ฉบับแก้ไข=1
8	1123456789	-	-
9	11000021	O-MR1	major=001, minor=001,iana=2017a,revision=2,respin=2

• ตัวอย่างที่ 1 และ 2 แสดง APK สองเวอร์ชันสำหรับเวอร์ชัน 2017a IANA ที่มีเวอร์ชันรูปแบบหลักต่างกัน 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 โซนเวลาและกำหนดค่าอิมเมจระบบอย่างถูกต้อง แอป Data ออกแบบมาเพื่อสร้างด้วย ทาปาสบิลด์ ที่สร้าง APK ที่เหมาะสมที่จะเพิ่มลงในอิมเมจระบบ (สำหรับการเปิดตัวครั้งแรก) และลงนามและเผยแพร่ผ่าน App Store (สำหรับการอัปเดตที่ตามมา)

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

การสร้างรายการ

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

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

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

ข้อมูลโค้ด Manifest ต่อไปนี้มีชุดโปรเจ็กต์ Git ขั้นต่ำที่จำเป็นเพื่อรองรับบิวด์ O-MR1 ของแอป Data โซนเวลา OEM ต้องเพิ่มโปรเจ็กต์ Git เฉพาะสำหรับ OEM ของตน (ซึ่งโดยทั่วไปแล้วจะมีโปรเจ็กต์ที่มีใบรับรองการลงนาม) ในรายการนี้ และอาจกำหนดค่าสาขาต่างๆ ตามลำดับ

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