กฎเขตเวลา

Android 10 deprecates เวลากลไกการปรับปรุงข้อมูลโซนเอพีเค-based (ใช้ได้ใน Android 8.1 และ Android 9) และแทนที่ด้วย กลไกการปรับปรุงโมดูล APEX-based AOSP ยังคงรวมรหัสแพลตฟอร์มที่จำเป็นสำหรับ 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)

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

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

การติดตั้ง Distro

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

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

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

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

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

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

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

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

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

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

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

การจัดเตรียม

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

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

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

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

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

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

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

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

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

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

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

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

คุณสมบัติ คำอธิบาย จำเป็นต้องแทนที่?
config_enableUpdateableTimeZoneRules
จะต้องตั้งค่า true การเปิดใช้งาน RulesManagerService ใช่
config_timeZoneRulesUpdateTrackingEnabled
จะต้องตั้งค่า true ที่จะมีระบบฟังสำหรับการเปลี่ยนแปลงไปยังแอปข้อมูล ใช่
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 มีโครงสร้างไดเรกทอรีตัวอย่างสำหรับการรวมการทดสอบใน Tradefed เหมือน XTS ห้องสวีท เช่นเดียวกับไดเร็กทอรีเทมเพลตอื่น ๆ OEM จะต้องคัดลอกและปรับแต่งตามความต้องการ
  • packages/apps/TimeZoneData/oem_template/data_app_prebuilt มีกำหนดค่าการสร้างเวลาสำหรับการรวมที่สร้างไว้ล่วงหน้า APK ที่ทดสอบที่จำเป็นโดยการทดสอบ

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

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

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

ขั้นตอนที่ 1: การอัปเดตระบบ/เขตเวลาและไฟล์ข้อมูลภายนอก/icu

ในขั้นตอนนี้จะใช้หุ้น OEMs กระทำ Android สำหรับ system/timezone และ external/icu จากรุ่น -DEV สาขาใน AOSP และนำไปใช้กระทำเหล่านั้นเพื่อสำเนาของรหัสที่มาของ Android

แพทช์ระบบ / เขต AOSP มีการปรับปรุงไฟล์ใน system/timezone/input_data และ system/timezone/output_data OEMs ที่ต้องทำให้การแก้ไขเพิ่มเติมในท้องถิ่นสามารถปรับเปลี่ยนแฟ้มใส่แล้วใช้ไฟล์ใน system/timezone/input_data และ external/icu ในการสร้างไฟล์ใน output_data

ไฟล์ที่สำคัญที่สุดคือ system/timezone/output_data/distro/distro.zip ซึ่งรวมโดยอัตโนมัติเมื่อข้อมูลแอปพลิเคเอพีเคถูกสร้างขึ้น

ขั้นตอนที่ 2: การอัปเดตรหัสเวอร์ชันของแอป Data

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

เมื่อมีการสร้างแอพพลิเคข้อมูลโดยใช้ไฟล์ที่คัดลอกจาก package/apps/TimeZoneData/oem_template/data_app คุณสามารถหาชื่อรหัสรุ่น / รุ่นที่ใช้กับเอพีเคในที่ 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 มีหน้าที่รับผิดชอบในการประกันคุณภาพและทดสอบแอปข้อมูลที่อัปเดตบนอุปกรณ์ของตนก่อนเผยแพร่

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

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

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

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

# รหัสเวอร์ชัน minSdkVersion {เวอร์ชันรูปแบบหลัก},{เวอร์ชันรูปแบบรอง},{เวอร์ชันกฎ IANA},{การแก้ไข}
1 11000010 O-MR1 เมเจอร์=001,ไมเนอร์=001,iana=2017a,ฉบับแก้ไข=1
2 21000010 NS เมเจอร์=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 NS เมเจอร์=002,ไมเนอร์=001,iana=2017b,ฉบับแก้ไข=1
6 11000040 O-MR1 เมเจอร์=001,ไมเนอร์=001,iana=2018a,ฉบับแก้ไข=1
7 21000030 NS เมเจอร์=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 อยู่เสมอสูงกว่า app ใด ๆ ที่มีไว้สำหรับ O- MR1

การสร้างแอป Data โดยใช้ทาปาส

OEM มีหน้าที่จัดการส่วนต่างๆ ของแอป Data โซนเวลาและกำหนดค่าอิมเมจระบบอย่างถูกต้อง แอปพลิเคข้อมูลมีวัตถุประสงค์ที่จะสร้างขึ้นด้วยการสร้างทาปาสที่ผลิต APK ที่เหมาะสมที่จะเพิ่มเข้ามาในระบบภาพ (สำหรับรุ่นแรก) และลงนามและจัดจำหน่ายผ่านร้านค้าแอป (สำหรับการปรับปรุงในภายหลัง)

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

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

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

  • หนึ่งในโครงการ Git มีไฟล์แอปเช่นประจักษ์และสร้างไฟล์ที่จำเป็นในการสร้างไฟล์แอปพลิเคเอพีเค (ตัวอย่างเช่น, 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 สำหรับอุปกรณ์ที่เข้ากันได้