ตัวเลือกเขตเวลา

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

นาฬิกาแบบเรียลไทม์ทั้งหมดที่มักใช้ในระบบวงจรรวมบนชิป (SoC) มีการดริฟต์บางส่วน สะสมไปเรื่อยๆ เมื่อเวลาผ่านไปและอาจทำให้เกิดข้อผิดพลาดที่สำคัญเมื่อไม่ได้รับการแก้ไข นอกจากนี้ เนื่องจากความคาดหวังสูง จึงสามารถแสดงเวลาท้องถิ่นได้อย่างถูกต้อง การชดเชยที่ถูกต้องจาก ต้องพิจารณาเวลาสากลเชิงพิกัด (UTC)

ข้อมูลเขตเวลา รวมถึงการใช้เวลาออมแสง (DST) อาจมีการเปลี่ยนแปลงในระหว่างอายุการใช้งานที่คาดไว้ของยานพาหนะ ตัวอย่างเช่น หลังจากที่หลาย ปีที่เริ่มใช้ DST นั้น บราซิลเลือกไม่เริ่มจัดทำกำหนดเวลา DST ในปี 2019

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

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

หมายเหตุ: AAOS 10 ใช้ สนับสนุนกลไกการอัปเดตโมดูลตาม APEX ที่มีใน Android รุ่นต่างๆ 10 (และสูงกว่า)

หมายเหตุ: หากต้องการใช้กลไกนี้ คุณต้องรีบูตระบบ

แหล่งข้อมูลเวลา (โซน) ในรถยนต์

อุปกรณ์ Android จะจัดการเวลาตามเวลา Unix ที่ระดับระบบ ใช้ออฟเซ็ตเขตเวลาที่ต้องการ จากนั้นแปลงค่าเป็นเวลาท้องถิ่นเพื่อแสดงต่อผู้ใช้ รหัสโซนของผู้ใช้ปัจจุบัน (มักจะ หรือ Olson ID) จะจัดเก็บเป็นการตั้งค่า เช่น ยุโรป/ลอนดอน

กลไกส่วนใหญ่ที่ระบุไว้ด้านล่างจะอธิบายข้อมูลเวลา วัตถุประสงค์ของมาตรฐานเหล่านี้คือ เพื่อระบุเวลาปัจจุบันให้กับผู้ใช้ ไม่ใช่อธิบายกฎเขตเวลาที่เกี่ยวข้อง หากต้องการทราบว่า เขตเวลาตามจริง อุปกรณ์ต้องแสดงผลจากปัจจัยต่างๆ เช่น ประเทศ ระยะเวลาชดเชย และ DST ก่อนที่จะตั้งค่ารหัสโซน

กระบวนการนี้อาจเป็นเรื่องท้าทาย การย้อนกลับตามข้อมูลที่มีอาจ ไม่ชัดเจน ตัวอย่างเช่น กฎเขตเวลาอเมริกา/เดนเวอร์เป็นไปตามข้อกำหนดของ DST แต่ปรับใช้กับเขตเมาน์เทน เวลาออมแสง (MDT) ในช่วงฤดูร้อน ขณะที่อเมริกา/ฟีนิกซ์ยังคงรู้จัก MDT อยู่

วิทยุเซลลูลาร์

ข้อมูลระบบ (SI) เป็นองค์ประกอบสำคัญของ อินเทอร์เฟซทางอากาศของวิวัฒนาการในระยะยาว (LTE) ซึ่งส่งโดยสถานีฐาน (BS) ผ่านช่องควบคุมการออกอากาศ (BCCH) การแก้ปัญหา 3GPP 36.331 ระบุ SystemInformationBlockType16 (SIB16) ซึ่งมีข้อมูลที่เกี่ยวข้องกับ GPS และ Coordinated Universal Time (UTC) รวมถึงการชดเชยเวลาท้องถิ่น และข้อมูล DST

ฟังก์ชันการทำงานที่คล้ายกันจะมีอยู่ในระบบ 2G และ 3G โดยที่ข้อมูลประจำตัวของเครือข่ายและเขตเวลา (NITZ) ข้อมูล สามารถออกอากาศได้ (ดูรายละเอียด 3GPP TS 22.042) มาตรฐานสัญญาณมือถืออื่นๆ ฟีเจอร์ที่เทียบเท่ากัน

อย่างไรก็ตาม ความเหมือนกันในมาตรฐานส่วนใหญ่คือการส่งข้อมูลเหล่านี้ เป็นตัวเลือก ดังนั้นจึงไม่พร้อมให้บริการอย่างทั่วถึงในทุกเครือข่าย

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

โปรโตคอลเวลาของเครือข่าย

Network Time Protocol (NTP) มักจะใช้เพื่อให้ได้เวลา Unix Epoch ที่ค่อนข้างแม่นยำ Android รองรับการซิงค์เวลาของระบบกับเซิร์ฟเวอร์ NTP สำหรับลูกค้าของ RadioManager ผ่านลิงก์ทั่วไป ข้อมูลเมตา RadioTuner.getParameters() NTP จะอัปเดตเวลาของระบบเมื่อหมดเวลา ซิงค์และผู้ให้บริการไม่ได้ให้อัปเดต NITZ เมื่อเร็วๆ นี้ หากผู้ใช้เปิดใช้ AUTO_TIMEเมื่อ NITZ ไม่พร้อมใช้งาน ระบบจะตรวจสอบเครือข่ายทันที

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

โปรแกรมจูนวิทยุสำหรับประกาศ

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

ETSI EN 300 401 V1.4.1 (2006-06) ส่วน 8.1 ระบุข้อมูลบริการ ที่ให้ ข้อมูลเพิ่มเติมเกี่ยวกับบริการสำหรับทั้งโปรแกรมเสียงและข้อมูลสำหรับเสียงดิจิทัล ระบบการกระจายเสียง (DAB) ส่วนที่ 8.1.3 กำหนดรูปแบบของเวลาและวันที่ รวมถึง สำหรับการชดเชยเวลาประเทศและเวลาท้องถิ่น

ในทำนองเดียวกัน สำหรับระบบข้อมูลวิทยุ (RDS) มีการใช้งานโดยทั่วไปในตัวรับสัญญาณ FM ส่วนที่ 3.1.5.6 ของ มาตรฐาน EN 50067 กำหนดรูปแบบของเวลาและข้อมูล (ส่งหนึ่งครั้งต่อนาที) นอกจากนี้ ส่วนขยาย รหัสประเทศ (ECC) ยังดึงมาเป็นส่วนหนึ่งของการระบุโปรแกรมที่ส่งได้อีกด้วย

HD Radio มีตัวเลือกที่เกี่ยวข้องซึ่งเป็นส่วนหนึ่งของ การออกแบบอินเทอร์เฟซทางอากาศ HD RadioTM ข้อกำหนดการรับส่งข้อมูลของบริการข้อมูลสถานีคำอธิบายในข้อมูลสถานี ข้อความพารามิเตอร์บริการ (SIS) (MSG ID 0111) ส่วนที่ 5 สะกดคําเตือนอย่างชัดเจนไว้ว่า ต้องระมัดระวังเมื่อพยายามใช้การรองรับนาฬิกาในการออกอากาศ ใช้สติปัญญาเดียวกันนี้ เทียบเท่ากับระบบอื่นๆ

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

นอกจากนี้ สำหรับวิทยุ HD เป็นอย่างน้อย การเผยแพร่ข้อมูลนี้เป็นตัวเลือกที่ไม่บังคับและไม่ควร เป็นที่พึ่งพาแต่เพียงผู้เดียว

ข้อดี ข้อเสีย

• โดยปกติจะมีให้บริการในมาตรฐานวิทยุกระจายเสียงระดับภูมิภาคต่างๆ
• ไม่ต้องใช้การเชื่อมต่ออินเทอร์เน็ต

• Android ไม่รองรับการดำเนินการนี้เมื่อเริ่มใช้งาน
• ต้องเปิดตัวรับสัญญาณ (อย่างน้อยเป็นครั้งคราวในเบื้องหลัง) เพื่อให้เสถียร ตรวจหาข้อมูล

• ความเสถียรขึ้นอยู่กับผู้ออกอากาศ

เคล็ดลับการใช้งาน

Android สนับสนุนการซิงค์เวลาของระบบกับเซิร์ฟเวอร์ NTP ถ้าทำได้ สำหรับลูกค้าของ RadioManager วิธีแก้ไขที่แนะนำคือการใช้ประโยชน์จากฟีเจอร์ส่วนขยายผู้ให้บริการ การติดตั้งใช้งานฟังก์ชันนี้ต้องเกิดขึ้นในเลเยอร์ Abstractionion ของฮาร์ดแวร์ (HAL) หลังจากนั้น ให้ลูกค้า RadioManager เห็นผ่านอินเทอร์เฟซทั่วไป RadioTuner.getParameters()

เพื่อคงประสิทธิภาพของโซลูชันไว้ ผู้บริโภคของส่วนขยายผู้ให้บริการนี้จะต้องพิจารณาว่า HAL รองรับฟีเจอร์นี้ (อย่าคิดว่ามีฟีเจอร์นี้อยู่) สตริงพารามิเตอร์สำหรับ ต้องจัดระเบียบการเรียก getParameters ให้เป็นระเบียบเพื่อให้ใช้งานได้ง่ายจากผู้ให้บริการหลายราย สำหรับ เช่น ใช้เนมสเปซขององค์กรโดยใส่โดเมนที่เหมาะสมไว้หน้าชื่อสำหรับ ตัวอย่างเช่น com.me.timezoneTuner.currenttimezone

เนื่องจากข้อมูลที่ขับเคลื่อนด้วยเหตุการณ์ การใช้มิติข้อมูล RadioTuner.Callback.onParametersUpdated() โทรกลับหาคุณเพื่อรับข้อมูลนี้ ถ้า สถานที่นี้ควรกำหนดค่าได้ ออกแบบชุดกิจวัตรแบบกำหนดเองนอกเหนือจาก setParameters เช่น

com.me.timezoneTuner.currenttimezoneEvent.enable

ระบบดาวเทียมนำทางทั่วโลก

ระบบดาวเทียมนำทางทั่วโลก (GNSS) สามารถให้เวลาที่แม่นยำเพียงอย่างเดียวได้ ข้อมูลและตำแหน่ง

ตำแหน่งภูมิศาสตร์

วิธีแก้ปัญหาสำหรับความไม่สะดวกนี้คือการใช้การเข้ารหัสภูมิศาสตร์ย้อนกลับ และระบุประเทศและ โดยใช้การค้นหาตามตำแหน่ง GNSS เป็นตัวเลือกที่ชัดเจน (และมีคุณภาพดีที่สุด) ของ ข้อมูลตำแหน่งในรถ จาก Google API เขตเวลา เสนอทุกสิ่งที่จำเป็นในการเรียกใช้ Conversion ที่จำเป็น แน่นอนว่าการเชื่อมต่ออินเทอร์เน็ต ต้องระบุ การดูแลความเป็นส่วนตัวของผู้ใช้จะต้องเป็นสิ่งสำคัญสูงสุดเมื่อใช้โซลูชันออนไลน์ จำเป็นต้องขอสิทธิ์ของผู้ใช้เพื่อยอมรับค่าใช้จ่ายจากการใช้ข้อมูล (หรือไม่) และต้องมีการขอสิทธิ์ดังกล่าว

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

ข้อดี	ข้อเสีย
ระบุเขตเวลาที่ถูกต้องได้อย่างชัดเจน ไม่ต้องใช้การเชื่อมต่ออินเทอร์เน็ต (ในกรณีของ DB ในเครื่อง) ทำงานได้อย่างราบรื่นในสถานการณ์การขับขี่ส่วนใหญ่	Android ไม่รองรับการดำเนินการนี้เมื่อเริ่มใช้งาน หากยานพาหนะอยู่ในอาคาร/พื้นที่ที่มีหลังคาซึ่งการรับสัญญาณดาวเทียม GNSS ไม่ดี ในระหว่างการกำหนดค่าครั้งแรก ก็คงหาเวลา ตำแหน่งที่แม่นยำ และเขตเวลา ฐานข้อมูลในเครื่องต้องมีกลไกการอัปเดต ความซับซ้อนในการติดตั้งใช้งาน

โทรศัพท์ที่เชื่อมต่อผ่านบลูทูธ, Wi-Fi หรือ USB

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

โทรศัพท์บางรุ่นที่รองรับบลูทูธพลังงานต่ำ (BLE) จะมีตัวเลือกให้ดึงข้อมูลเวลาผ่าน ลักษณะเฉพาะของเวลาปัจจุบัน GATT และข้อกำหนดของโปรไฟล์บริการเวลาปัจจุบัน 1.1 อย่างไรก็ตาม ตัวเลือกนี้จะ ไม่ใช่ตลาดที่ใหญ่พอ สำหรับผู้อ่านโดยเฉพาะ

ข้อดี	ข้อเสีย
ไม่ต้องใช้การเชื่อมต่ออินเทอร์เน็ต การเปลี่ยนแปลงเขตเวลาที่โทรศัพท์ตรวจพบสามารถส่งต่อการเปลี่ยนแปลงไปยังเครื่องเล่นวิทยุได้	Android ไม่รองรับการดำเนินการนี้เมื่อเริ่มใช้งาน ทำงานเมื่อโทรศัพท์เชื่อมต่อกับเครื่องเล่นวิทยุเท่านั้น เวลาจะดีหรือไม่ขึ้นอยู่กับสิ่งที่โทรศัพท์มีให้ การใช้งานมีความซับซ้อน โทรศัพท์บางรุ่นไม่รองรับโปรไฟล์บริการ BLE GATT Current Time

ใช้แหล่งที่มา

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

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

ตัวเลือกการกำหนดค่าด้วยตนเองในฐานะวิดีโอสำรองชั่วคราวนั้นสามารถทำได้ง่าย และในทางปฏิบัติสามารถ เพียงพอสำหรับผู้ใช้จำนวนมาก