กฎเขตเวลา

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 14 เป็นต้นไปโดยสิ้นเชิง และไม่พบในซอร์สโค้ด พันธมิตรควรย้ายไปยัง โมดูล 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/ code ใช้สำเนา /data ของไฟล์ tzdata และ tzlookup.xml
  • รหัส ICU4J/ICU4C ใช้ไฟล์ใน /data และถอยกลับไปที่ไฟล์ /system สำหรับข้อมูลที่ไม่มีอยู่ (สำหรับรูปแบบ สตริงที่แปลเป็นภาษาท้องถิ่น ฯลฯ)

ไฟล์ดิสโทร

ไฟล์ 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 ประกอบด้วยขั้นตอนต่อไปนี้:

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

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

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

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

      รับข้อมูล 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

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

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

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

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

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

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

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

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

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

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

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

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

ตรวจสอบเวอร์ชัน
รูปที่ 6 ตัวอย่างกลยุทธ์โค้ดเวอร์ชัน
ตัวอย่าง ค่า วัตถุประสงค์
ที่สงวนไว้ อนุญาตให้ใช้รูปแบบทางเลือก/ทดสอบ APK ในอนาคต โดยค่าเริ่มต้นจะเป็น 0 เนื่องจากประเภทที่ซ่อนอยู่นั้นเป็นประเภท int 32 บิตแบบมีลายเซ็น รูปแบบนี้จึงรองรับการแก้ไขรูปแบบการกำหนดหมายเลขในอนาคตได้สูงสุดสองครั้ง
01 เวอร์ชันรูปแบบหลัก ติดตามเวอร์ชันรูปแบบหลักทศนิยม 3 หลัก รูปแบบ distro รองรับทศนิยม 3 หลัก แต่ที่นี่ใช้เพียง 2 หลักเท่านั้น ไม่น่าจะถึง 100 เนื่องจากมีการเพิ่มขึ้นอย่างมากต่อระดับ API ที่คาดไว้ เวอร์ชันหลัก 1 เทียบเท่ากับ API ระดับ 27
1 เวอร์ชันรูปแบบย่อย ติดตามเวอร์ชันรูปแบบย่อยทศนิยม 3 หลัก รูปแบบ distro รองรับทศนิยม 3 หลัก แต่ที่นี่ใช้เพียง 1 หลักเท่านั้น ไม่น่าจะถึง 10 เลย
เอ็กซ์ ที่สงวนไว้ เป็น 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 หลัก=001,รอง=001,iana=2018a,การแก้ไข=1
7 21000030 หลัก=002,รอง=001,iana=2018a,การแก้ไข=1
8 1123456789 - - - -
9 11000021 O-MR1 หลัก=001,รอง=001,iana=2017a,การแก้ไข=2,respin=2
  • ตัวอย่างที่ 1 และ 2 แสดง APK สองเวอร์ชันสำหรับรุ่น IANA ปี 2017a เดียวกันซึ่งมีเวอร์ชันรูปแบบหลักที่แตกต่างกัน 2 เป็นตัวเลขที่สูงกว่า 1 ซึ่งจำเป็นเพื่อให้แน่ใจว่าอุปกรณ์รุ่นใหม่จะได้รับเวอร์ชันที่มีรูปแบบสูงกว่า minSdkVersion ช่วยให้แน่ใจว่าเวอร์ชัน P จะไม่ถูกส่งไปยังอุปกรณ์ O
  • ตัวอย่างที่ 3 คือการแก้ไข/แก้ไขสำหรับ 1 และมีตัวเลขสูงกว่า 1
  • ตัวอย่างที่ 4 และ 5 แสดงรุ่น O-MR1 และ P รุ่นปี 2017b โดยมีตัวเลขที่สูงกว่า โดยแทนที่รุ่นก่อนหน้าของ 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 ปกติ

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

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

   <!-- 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 สำหรับอุปกรณ์ที่รองรับ