กฎเขตเวลา

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 เป็นต้นไปโดยสมบูรณ์แล้ว และคุณจะไม่พบฟีเจอร์นี้ในซอร์สโค้ด พาร์ทเนอร์ควรย้ายข้อมูลไปยัง Time Zone Mainline module อย่างสมบูรณ์

ใน 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

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

เมื่อสร้างแอปข้อมูลโดยใช้ไฟล์ที่คัดลอกจาก 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 Platform หลายๆ รุ่น (และไม่ได้ใช้ระดับ API ในรูปแบบรหัสเวอร์ชันของแอปข้อมูล)

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

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