การแสดงเวลาที่ถูกต้องเป็นฟีเจอร์หลักที่คาดหวังจากระบบสาระบันเทิงของยานยนต์ แม้ว่าการดำเนินการนี้อาจดูง่าย แต่การจัดการเวลาและเขตเวลาก็อาจกลายเป็นเรื่องซับซ้อนได้อย่างรวดเร็วเมื่อต้องแสดงวันที่และเวลาที่ถูกต้องอย่างน่าเชื่อถือโดยไม่ต้องมีการจัดการด้วยตนเอง
นาฬิกาแบบเรียลไทม์ทั้งหมดที่ใช้ในระบบวงจรรวมบนชิป (SoC) มักจะมีความคลาดเคลื่อนอยู่บ้าง ซึ่งจะสะสมเมื่อเวลาผ่านไปและอาจทําให้เกิดข้อผิดพลาดร้ายแรงหากไม่ได้รับการแก้ไข นอกจากนี้ เนื่องจากผู้ใช้คาดหวังให้แสดงเวลาท้องถิ่นอย่างถูกต้อง จึงต้องพิจารณาการชดเชยที่ถูกต้องจากเวลาสากลตามการประสาน (UTC)
ข้อมูลเขตเวลาและการใช้เวลาออมแสง (DST) อาจเปลี่ยนแปลงได้ตลอดอายุการใช้งานที่คาดไว้ของยานพาหนะ ตัวอย่างเช่น หลังจากใช้เวลาออมแสงมาหลายปี บราซิลเลือกที่จะไม่เริ่มใช้เวลาออมแสงในปี 2019
Android มีโครงสร้างพื้นฐานที่จำเป็นต่อการจัดการกฎเขตเวลาที่ซับซ้อน โปรดดูรายละเอียดที่หัวข้อกฎเขตเวลา ซึ่งช่วยให้ OEM สามารถพุชข้อมูลกฎเขตเวลาที่อัปเดตไปยังอุปกรณ์ได้โดยไม่ต้องอัปเดตระบบ กลไกนี้ช่วยให้ทำสิ่งต่อไปนี้ได้
- ผู้ใช้ได้รับการอัปเดตอย่างทันท่วงที (ซึ่งช่วยยืดอายุการใช้งานของอุปกรณ์ Android)
- OEM ทดสอบการอัปเดตเขตเวลาแยกจากการอัปเดตอิมเมจระบบ
หมายเหตุ: AAOS 10 ไม่รองรับกลไกการอัปเดตโมดูลที่อิงตาม APEX ซึ่งมีให้ในรุ่นของ Android 10 (และเวอร์ชันที่ใหม่กว่า)
หมายเหตุ: หากต้องการใช้กลไกนี้ คุณต้องรีบูตระบบ
แหล่งข้อมูลเวลา (เขตเวลา) ในรถยนต์
อุปกรณ์ Android จะจัดการเวลาในเขตเวลา Unix ที่ระดับระบบ ใช้ค่าออฟเซ็ตเขตเวลาที่ต้องการ แล้วแปลงค่าเป็นเขตเวลาท้องถิ่นเพื่อแสดงต่อผู้ใช้ ระบบจะจัดเก็บรหัสโซนของผู้ใช้ปัจจุบัน (มักเรียกว่ารหัส Olson) เป็นการตั้งค่า เช่น Europe/London
กลไกส่วนใหญ่ที่ระบุไว้ด้านล่างจะอธิบายข้อมูลเวลา มาตรฐานเหล่านี้มีจุดประสงค์เพื่อแสดงเวลาปัจจุบันแก่ผู้ใช้ ไม่ใช่เพื่ออธิบายกฎเขตเวลาที่มีผล หากต้องการระบุเขตเวลาที่แท้จริง อุปกรณ์จะต้องทำงานย้อนกลับจากปัจจัยต่างๆ เช่น ประเทศ การเลื่อนเวลา และเวลาออมแสงก่อนตั้งค่ารหัสเขตเวลา
กระบวนการนี้อาจเป็นเรื่องท้าทาย การย้อนกลับตามข้อมูลที่มีอยู่อาจไม่ชัดเจน ตัวอย่างเช่น กฎเขตเวลาอเมริกา/เดนเวอร์ใช้เขตเวลาออมแสง (DST) แต่ใช้เขตเวลาออมแสงตอนกลางวัน (MDT) ในช่วงฤดูร้อน ขณะที่อเมริกา/ฟีนิกซ์ยังคงใช้เขตเวลา MDT
วิทยุเซลลูลาร์
ข้อมูลระบบ (SI) เป็นองค์ประกอบสําคัญของอินเทอร์เฟซอากาศ Long-Term Evolution (LTE) ซึ่งสถานีฐาน (BS) ส่งผ่านช่องควบคุมการออกอากาศ (BCCH) 3GPP TS 36.331 ระบุ SystemInformationBlockType16 (SIB16) ซึ่งมีข้อมูลเกี่ยวกับ GPS และเวลาสากลเชิงพิกัด (UTC) เขตเวลาท้องถิ่น รวมถึงข้อมูล DST
ฟังก์ชันการทำงานที่คล้ายกันนี้พบได้ใน 2G และ 3G ซึ่งสามารถออกอากาศข้อมูลระบุตัวตนเครือข่ายและเขตเวลา (NITZ) ได้ (ดูรายละเอียดใน 3GPP TS 22.042) มาตรฐานวิทยุมือถืออื่นๆ มีฟีเจอร์ที่เทียบเท่า
แต่ข้อเสียคือมาตรฐานส่วนใหญ่จะกำหนดให้การส่งข้อมูลนี้ไม่บังคับ จึงอาจไม่พร้อมใช้งานในเครือข่ายบางแห่ง
ข้อดี | ข้อเสีย |
---|---|
|
|
โปรโตคอลเวลาเครือข่าย
โปรโตคอลเวลาของเครือข่าย (NTP) มักใช้เพื่อรับข้อมูลเวลาของยุค Unix ที่ค่อนข้างแม่นยำ Android รองรับการซิงค์เวลาของระบบกับเวลาของเซิร์ฟเวอร์ NTP หากสามารถแสดงต่อไคลเอ็นต์ของ RadioManager
ผ่านข้อมูลเมตาทั่วไป RadioTuner.getParameters()
NTP จะอัปเดตเวลาของระบบเมื่อระบบไม่ซิงค์และผู้ให้บริการไม่ได้ให้ข้อมูลอัปเดต NITZ เมื่อเร็วๆ นี้ หากผู้ใช้เปิดใช้ AUTO_TIME
เมื่อไม่มี NITZ ระบบจะตรวจสอบเวลาของเครือข่ายทันที
ข้อดี | ข้อเสีย |
---|---|
ความเรียบง่ายที่ Android รองรับ |
|
เครื่องรับสัญญาณวิทยุกระจายเสียง
แม้ว่าการใช้จูนเนอร์ในตัวเพื่อดึงข้อมูลเวลาและเขตเวลาจะน่าสนใจ แต่ก็มีปัญหาอยู่ มาตรฐานการออกอากาศทางวิทยุจำนวนมากกำหนดตัวเลือกในการแสดงข้อมูลที่ต้องการ โดยทั่วไปแล้ว เครื่องรับสัญญาณวิทยุกระจายเสียงจะให้ข้อมูลเดียวกับวิทยุมือถือ
ETSI EN 300 401 V1.4.1 (2006-06) ส่วน 8.1 ระบุข้อมูลบริการ ฟีเจอร์ที่ให้ข้อมูลเพิ่มเติมเกี่ยวกับบริการสำหรับทั้งโปรแกรมเสียงและข้อมูลสำหรับระบบการออกอากาศเสียงดิจิทัล (DAB) ส่วน 8.1.3 จะกำหนดรูปแบบสำหรับเวลาและวันที่ รวมถึงข้อมูลสำหรับประเทศและเวลาออฟเซ็ตท้องถิ่น
ในทำนองเดียวกัน สำหรับระบบข้อมูลวิทยุ (RDS) ที่มักใช้ในเครื่องรับสัญญาณ FM ส่วน 3.1.5.6 ของมาตรฐาน EN 50067 จะกำหนดรูปแบบสำหรับเวลาและข้อมูล (ส่ง 1 ครั้งต่อนาที) นอกจากนี้ คุณยังเรียกดูรหัสประเทศแบบขยาย (ECC) เป็นส่วนหนึ่งของการระบุโปรแกรมที่ส่งได้ด้วย
HD Radio มีตัวเลือกที่เกี่ยวข้องซึ่งเป็นส่วนหนึ่งของข้อกำหนดการออกแบบอินเทอร์เฟซทางอากาศของ HD Radio™ สำหรับการอธิบายการขนส่งข้อมูลบริการข้อมูลสถานีในข้อความพารามิเตอร์บริการข้อมูลสถานี (Station Information Service หรือ SIS) (รหัสข้อความ 0111) ส่วน 5 ระบุคำเตือนอย่างชัดเจนว่าต้องคำนึงถึงอะไรบ้างเมื่อพยายามใช้การรองรับนาฬิกาของออกอากาศ หลักการเดียวกันนี้ใช้กับระบบอื่นๆ ได้อย่างเท่าเทียม
... ข้อมูลเหล่านี้อธิบายถึงประเพณีท้องถิ่น ณ สถานที่ของผู้ออกอากาศ ซึ่งอาจไม่เหมือนกับประเพณีท้องถิ่น ณ สถานที่ของผู้รับ ผู้บริโภคที่อยู่ใกล้เขตแดนเขตเวลาต่างๆ อาจได้รับข้อมูลที่แตกต่างกันจากสถานีหลายแห่ง ดังนั้น ข้อมูลเหล่านี้จึงมีไว้เพื่อเป็นคำแนะนำเท่านั้น การตีความและการใช้ข้อมูลควรขึ้นอยู่กับการพิจารณาของลูกค้า ..." |
นอกจากนี้ อย่างน้อยสำหรับวิทยุ HD การออกอากาศข้อมูลนี้ก็เป็นทางเลือกและไม่ควรใช้เพียงอย่างเดียว
ข้อดี ข้อเสีย- มักพร้อมให้บริการในมาตรฐานวิทยุกระจายเสียงระดับภูมิภาคต่างๆ
- ไม่ต้องใช้การเชื่อมต่ออินเทอร์เน็ต
- Android ไม่รองรับการดำเนินการนี้โดยค่าเริ่มต้น
- ต้องเปิดเครื่องรับสัญญาณ (อย่างน้อยเป็นครั้งคราวในเบื้องหลัง) เพื่อตรวจหาข้อมูลอย่างน่าเชื่อถือ
-
ความน่าเชื่อถือขึ้นอยู่กับผู้ออกอากาศ
เคล็ดลับการติดตั้งใช้งาน
Android รองรับการซิงค์เวลาของระบบกับเวลาของเซิร์ฟเวอร์ NTP หากสามารถแสดงเวลาดังกล่าวต่อไคลเอ็นต์ของRadioManager
โซลูชันที่แนะนําคือใช้ประโยชน์จากฟีเจอร์ส่วนขยายของผู้ให้บริการ
การใช้งานฟังก์ชันนี้ต้องเกิดขึ้นในเลเยอร์การแยกแยะฮาร์ดแวร์ (HAL) หลังจากนั้นจึงจะแสดงให้กับไคลเอ็นต์ของ RadioManager
ผ่านเมธอด RadioTuner.getParameters()
ทั่วไปได้
ผู้ใช้ส่วนขยายของผู้ให้บริการรายนี้ต้องตรวจสอบว่า HAL รองรับฟีเจอร์ดังกล่าว (อย่าคิดว่ามี) เพื่อให้โซลูชันยังคงมีประสิทธิภาพ สตริงพารามิเตอร์สําหรับการเรียกใช้ getParameters
ต้องจัดระเบียบอย่างเป็นระเบียบเพื่อให้ใช้งานกับผู้ให้บริการต่างๆ ได้อย่างชัดเจน เช่น ใช้เนมสเปซขององค์กรโดยใส่โดเมนที่เหมาะสมไว้ข้างหน้า เช่น com.me.timezoneTuner.currenttimezone
การใช้ RadioTuner.Callback.onParametersUpdated()
callback เพื่อรับข้อมูลนี้อาจมีประโยชน์เนื่องจากข้อมูลมีลักษณะที่ทำงานตามเหตุการณ์ หากต้องกำหนดค่าสิ่งอำนวยความสะดวกนี้ ให้ออกแบบชุดกิจวัตรที่กำหนดเองเพิ่มเติมจาก setParameters
เช่น
com.me.timezoneTuner.currenttimezoneEvent.enable
ระบบดาวเทียมนำร่องทั่วโลก
ระบบนำทางด้วยดาวเทียมทั่วโลก (GNSS) จะให้ข้อมูลเวลาและตำแหน่งที่ถูกต้องได้เท่านั้น
ตำแหน่งภูมิศาสตร์
วิธีแก้ปัญหาความไม่สะดวกนี้คือการเรียกใช้การแปลงพิกัดภูมิศาสตร์ย้อนกลับและระบุประเทศและเขตเวลาโดยการค้นหาตามตำแหน่ง GNSS เป็นตัวเลือกที่ชัดเจน (และมีคุณภาพดีที่สุด) สำหรับข้อมูลตำแหน่งในยานพาหนะ Time Zone API ของ Google มีทุกอย่างที่จำเป็นต่อการแปลงที่จำเป็น แน่นอนว่าต้องมีการเชื่อมต่ออินเทอร์เน็ต การปกป้องความเป็นส่วนตัวของผู้ใช้ต้องถือเป็นสิ่งสําคัญที่สุดเมื่อติดตั้งใช้งานโซลูชันออนไลน์ ต้องขอและได้รับสิทธิ์จากผู้ใช้เพื่อยอมรับ (หรือไม่ยอมรับ) ค่าใช้จ่ายในการใช้อินเทอร์เน็ต
คุณสามารถสร้างโซลูชันที่เหมาะสมสำหรับการใช้งานแบบออฟไลน์ได้ ฐานข้อมูลแผนที่ในเครื่องที่มีความละเอียดเพียงพอในการระบุประเทศและเขตเวลาได้อย่างถูกต้องจะพอดีกับพื้นที่เก็บข้อมูลของยานพาหนะ การใช้ข้อมูลนี้และกลยุทธ์ที่นำมาใช้งานอย่างเต็มรูปแบบสำหรับการอัปเดตข้อมูลเขตเวลา (และประเทศ) ตามที่จำเป็นจะช่วยให้สามารถแปลงพิกัดภูมิศาสตร์กลับเป็นประเทศ/เขตเวลาตามตำแหน่ง GNSS ที่ได้รับจากระบบย่อยตำแหน่ง
ข้อดี | ข้อเสีย |
---|---|
|
|
โทรศัพท์ที่เชื่อมต่อผ่านบลูทูธ, Wi-Fi หรือ USB
สามารถใช้เทคโนโลยีหลายอย่างเพื่อใช้ประโยชน์จากโทรศัพท์ของผู้ใช้เพื่อรับข้อมูลเวลาและเขตเวลา สำหรับโทรศัพท์ทุกรุ่น คุณต้องติดตั้งแอปที่กำหนดเองและแอปที่ใช้ร่วมกัน 2 แอปในโทรศัพท์และในระบบสาระบันเทิงในรถ (IVI) จากนั้นคุณก็สามารถซิงค์เวลาเป็นช่วงเวลาที่ต้องการได้ เช่น เมื่อสร้างการเชื่อมต่อและเมื่อโทรศัพท์ตรวจพบเขตเวลาใหม่
โทรศัพท์บางรุ่นที่รองรับบลูทูธพลังงานต่ำ (BLE) มีตัวเลือกในการดึงข้อมูลเวลาผ่านลักษณะเวลาปัจจุบัน GATT และข้อกำหนดเฉพาะของโปรไฟล์บริการเวลาปัจจุบัน 1.1 อย่างไรก็ตาม ตัวเลือกนี้ไม่ได้กล่าวถึงกลุ่มตลาดขนาดใหญ่พอที่จะใช้เพียงอย่างเดียว
ข้อดี | ข้อเสีย |
---|---|
|
|
ใช้แหล่งที่มา
ผู้ให้บริการอุปกรณ์ทุกรายต้องกำหนดมาตรฐานให้สูงเท่าใดและเส้นทางของผู้ใช้ใดที่ถือว่าสำคัญที่สุด การตัดสินใจที่ดีที่สุดจะเกิดขึ้นได้ก็ต่อเมื่อคุณเข้าใจประสบการณ์ของผู้ใช้ที่สําคัญที่ต้องการอย่างชัดเจน ในกรณีส่วนใหญ่ ผู้ให้บริการต้องพิจารณาข้อดีข้อเสียระหว่างความสะดวกและความซับซ้อนในการติดตั้งใช้งาน
ตัวเลือกแต่ละรายการที่อธิบายไว้ข้างต้นมีทั้งข้อดีและข้อเสีย ตัวอย่างเช่น คุณต้องเลือกการออกแบบที่สำคัญเกี่ยวกับความยืดหยุ่นที่ยอมรับได้เมื่อเทียบกับการแสดงเวลาที่ไม่ดีเป็นครั้งคราว และวิธีจัดการกับข้อเสีย โซลูชันอัตโนมัติทั้งหมดที่คาดว่าจะทํางานได้ดีในทุกสถานการณ์ แต่ต้องอิงตามแหล่งข้อมูลหลายแหล่ง ไม่มีตัวเลือกใดที่ให้ความพร้อมให้บริการ 100%
ตัวเลือกการกําหนดค่าด้วยตนเองเป็นทางเลือกสำรองชั่วคราวนั้นใช้งานได้ง่ายและในทางปฏิบัติแล้วอาจเพียงพอสําหรับผู้ใช้จํานวนมาก