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 ซึ่งเป็นมาตรฐานข้อมูลที่สามารถเปลี่ยนแปลงได้บ่อยครั้งด้วยเหตุผลทางศาสนา การเมือง และภูมิศาสตร์การเมือง
การอัปเดตใช้กระบวนการต่อไปนี้:
- IANA เผยแพร่การอัปเดตฐานข้อมูลเขตเวลาเผยแพร่การอัปเดตเพื่อตอบสนองต่อรัฐบาลอย่างน้อยหนึ่งแห่งที่เปลี่ยนแปลงกฎเขตเวลาในประเทศของตน
- Google หรือพาร์ทเนอร์ Android เตรียมอัปเดตโมดูลข้อมูลโซนเวลา (ไฟล์ APEX) ที่มีโซนเวลาที่อัปเดต
- อุปกรณ์ของผู้ใช้ปลายทางจะดาวน์โหลดการอัปเดต รีบูต จากนั้นใช้การเปลี่ยนแปลง หลังจากนั้นข้อมูลเขตเวลาของอุปกรณ์จะมีข้อมูลเขตเวลาใหม่จากการอัปเดต
สำหรับรายละเอียดเกี่ยวกับโมดูล โปรดดูที่ ส่วนประกอบระบบโมดูลา ร์
การอัปเดตเขตเวลา (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 ประกอบด้วยขั้นตอนต่อไปนี้:
- แอพข้อมูลอัปเดต ผ่านการดาวน์โหลดจากแอพสโตร์หรือไซด์โหลด กระบวนการของเซิร์ฟเวอร์ระบบ (ผ่านคลาส
timezone.RulesManagerServer/timezone.PackageTracker
) จะคอยตรวจสอบการเปลี่ยนแปลงชื่อแพ็กเกจแอป Data ที่กำหนดค่าเฉพาะ OEMรูปที่ 1. การอัพเดตแอพข้อมูล - กระบวนการของเซิร์ฟเวอร์ระบบจะทริกเกอร์การตรวจสอบการอัปเดต โดยเผยแพร่เจตนาที่เป็นเป้าหมายด้วยโทเค็นแบบใช้ครั้งเดียวที่ไม่ซ้ำใครไปยังแอป Updater เซิร์ฟเวอร์ระบบติดตามโทเค็นล่าสุดที่สร้างขึ้น เพื่อให้สามารถระบุได้ว่าการตรวจสอบล่าสุดที่เรียกใช้เสร็จสิ้นเมื่อใด โทเค็นอื่น ๆ จะถูกละเว้น
รูปที่ 2. การตรวจสอบการอัพเดตทริกเกอร์ - ระหว่างการตรวจสอบการอัปเดต แอพ Updater จะทำงานต่อไปนี้:
- สอบถามสถานะอุปกรณ์ปัจจุบันโดยการเรียก RulesManagerService
รูปที่ 3. การอัพเดตแอพข้อมูล การเรียก RulesManagerService - สืบค้นข้อมูลแอพ Data โดยการสืบค้น ContentProvider URL ที่กำหนดไว้อย่างดีและข้อกำหนดของคอลัมน์เพื่อรับข้อมูลเกี่ยวกับ distro
รูปที่ 4. อัพเดตแอพข้อมูล รับข้อมูลเกี่ยวกับ distro
- สอบถามสถานะอุปกรณ์ปัจจุบันโดยการเรียก RulesManagerService
- แอป Updater จะดำเนินการตามความเหมาะสม ตามข้อมูลที่มี การดำเนินการที่มีอยู่ ได้แก่:
- ขอติดตั้ง. ข้อมูล Distro ถูกอ่านจากแอป Data และส่งผ่านไปยัง RulesManagerService ในเซิร์ฟเวอร์ระบบ RulesManagerService ยืนยันอีกครั้งว่าเวอร์ชันและเนื้อหารูปแบบ distro เหมาะสำหรับอุปกรณ์และขั้นตอนการติดตั้ง
- ขอถอนการติดตั้ง (ซึ่งหายาก) ตัวอย่างเช่น หาก APK ที่อัปเดตใน
/data
ถูกปิดใช้งานหรือถอนการติดตั้ง และอุปกรณ์กลับเป็นเวอร์ชันที่มีอยู่ใน/system
- ไม่ทำอะไร. เกิดขึ้นเมื่อพบว่า distro แอป Data ไม่ถูกต้อง
รูปที่ 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 (สำหรับการอัปเดตที่ตามมา) สำหรับรายละเอียดเกี่ยวกับการใช้ทาปาส โปรดดู การสร้างแอปข้อมูลโดยใช้ทาปาส
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 การทดสอบที่สร้างไว้ล่วงหน้าตามที่การทดสอบต้องการ
การสร้างการอัปเดตโซนเวลา
เมื่อ IANA เผยแพร่กฎเขตเวลาชุดใหม่ ทีมไลบรารีหลักของ Android จะสร้างแพตช์เพื่ออัปเดตรุ่นใน AOSP OEM ที่ใช้ระบบสต็อก Android และไฟล์ distro สามารถรับคอมมิตเหล่านี้ ใช้เพื่อสร้างแอป Data เวอร์ชันใหม่ จากนั้นปล่อยเวอร์ชันใหม่เพื่ออัปเดตอุปกรณ์ในเวอร์ชันที่ใช้งานจริง
เนื่องจากแอป 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 ที่สูงกว่าที่สามารถจัดการได้

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