准确显示时间是车载信息娱乐系统的一项核心功能。虽然这可能看起来很简单,特别是在人们对时间和时区管理的期望值较低且必须满足时,但是,如果必须在没有人工干预的情况下显示可靠准确的日期和时间,时间问题很快就会变得复杂起来。
系统芯片 (SoC) 所用的所有实时时钟通常都会有一些偏移;这些偏移会随着时间的推移而累积,如果不加以纠正,可能会导致重大偏差。此外,由于人们对准确显示本地时间的期望值很高,因此必须考虑相对于世界协调时间 (UTC) 的正确偏移值。
时区信息以及夏令时 (DST) 的采用在车辆的预计生命周期内可能会发生变化。例如,在实行夏令时多年后,巴西决定在 2019 年不实行夏令时时间表。
Android 提供了对时区规则管理方面的复杂问题进行协商所需的基础架构。如需了解详情,请参阅时区规则;OEM 可以使用这种机制将更新后的时区规则数据推送到设备,而无需进行系统更新。借助此机制:
- 用户能够及时获得更新(从而延长 Android 设备的使用期限)。
- OEM 能够独立于系统映像更新来测试时区更新。
注意:AAOS 10 不支持 Android 10(及更高版本)中提供的基于 APEX 的模块更新机制。
注意:如需实现此机制,需要重新启动系统。
车载设备中的时间(时区)信息来源
Android 设备可在系统级别根据 Unix 时间管理时间,采用所需的时区偏移量,然后将相应的值转换为本地时间,以向用户显示。当前用户的时区 ID(通常称为 Olson ID)会以设置的形式存储,如 Europe/London。
下文所述的大部分机制都介绍了时间信息。这些标准的目的在于为用户提供当前时间,而不是描述适用的时区规则。为确定实际时区,设备必须先回溯国家/地区、偏移值和 DST 偏移值等因素,然后再设置时区 ID。
这个过程可能并非易事。根据现有的信息进行回溯可能会模糊不清。例如,时区规则 America/Denver 遵守夏令时,但在夏季会采用山地夏令时 (MDT),America/Phoenix 则一直采用 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 开箱就支持通过 NewNetworkTimeUpdateService 将系统时间与 NTP 服务器的时间同步。NTP 会监控网络时间,并在网络时间不同步以及运营商最近没有提供 NITZ 更新时更新系统时间。如果用户在 NITZ 不可用时启用 AUTO_TIME
,系统会立即检查网络时间。
优点 | 缺点 |
---|---|
简洁,受 Android 支持。 |
|
广播无线装置调谐器
利用内置的调谐器来检索时间和时区信息虽然极具吸引力,但也需要克服一些挑战。众多无线装置广播标准定义了多个选项,用于提供所需的信息。一般来说,广播无线装置调谐器提供的信息与移动网络无线装置相同。
ETSI EN 300 401 V1.4.1 (2006-06) 第 8.1 部分规定了服务信息功能,为数字音频广播 (DAB) 系统的音频节目服务和数据服务提供了补充信息。第 8.1.3 部分定义了时间和日期的格式,以及有关国家/地区和当地时间偏移值的信息。
同样,对于通常在 FM 调谐器中实现的无线装置数据系统 (RDS),EN 50067 标准第 3.1.5.6 部分定义了时钟时间和数据的格式(每分钟传输一次)。此外,在识别传输的节目时,还可以检索扩展的国家/地区代码 (ECC)。
HD 电台包含对应的选项,作为 HD Radio™ 空中接口设计说明电台信息服务传输规范中电台信息服务 (SIS) 参数消息 (MSG ID 0111) 的一部分。第 5 部分明确阐述了在尝试使用广播的时钟支持时必须注意的事项。同样的智慧一样适用于其他系统:
“…这些数据描述的是广播方所在地的当地习惯,可能与接收方所在地的当地习惯相同,也可能不相同。在接近时区边界的地方,使用方可能会收到提供不同数据的多个电台。因此,这些数据仅作为提示提供,其解释和使用应根据客户的控制情况酌情决定。…” |
此外,至少对于 HD 电台,这些信息的广播是可选的,因此不应完全依赖于它。
优点 | 缺点 |
---|---|
|
|
实现提示
当前的 BroadcastRadio HAL 2.0 未提供处理时间(时区)元数据的配置。因此,建议的解决方案是使用供应商扩展功能。此功能必须在硬件抽象层 (HAL) 中实现,之后,它可以通过常规 RadioTuner.getParameters()
方法提供给 RadioManager 的客户端。
为了让该解决方案保持稳健性,此供应商扩展的使用方必须确定 HAL 是否支持该功能(不要假定存在这类支持)。getParameters
调用的参数字符串必须进行清晰的整理,供各供应商明确使用。例如,可通过在贵组织的命名空间前面加上合适的域名前缀(如 "com.me.timezoneTuner.currenttimezone"
)来使用它。
考虑到此类信息的事件驱动性质,使用 RadioTuner.Callback.onParametersUpdated()
回调来接收此类信息可能大有裨益。如果这个功能应该是可配置的,可以在 setParameters
之上设计一套自定义例程。例如:
com.me.timezoneTuner.currenttimezoneEvent.enable
全球导航卫星系统
全球导航卫星系统 (GNSS) 本身只能提供(非常)准确的时间信息和位置信息。
地理定位
解决这一不便的方案是执行反向地理编码,根据位置进行查询来确定国家/地区和时区。在确定车辆的位置信息方面,GNSS 是显而易见的(也是最优质的)选择。Google 的 <aclass="external" l10n-attrs-original-order="href,class" l10n-encrypted-href="6z2vbshndiNBlkSF5nuHzqXc57TIW5VywCkhSp4WUypzRwGNXACB5ltAIGicGTa2qjmYZJAor4qTntaXrxsSZqMZz/kq5DDJnT+TJu5E3bE=">Time Zone API 提供了运行必要的转换所需的全部功能。当然,还必须连接到互联网。在实现在线解决方案时,确保用户隐私必定是首要任务!在消耗流量之前,需要先确认用户是否接受流量使用费;必须请求这一许可。</aclass="external">
可以制定一个适合离线使用的解决方案。一个具有足够的分辨率,可准确确定国家/地区和时区的本地地图数据库可以装入车辆的存储器中。部署了这个数据库,再加上可根据需要更新时区(和国家/地区)信息且完全实现的策略,就可以根据从定位子系统获取的 GNSS 位置信息对国家/地区/时区进行反向地理编码。
优点 | 缺点 |
---|---|
|
|
已通过蓝牙、Wi-Fi 或 USB 连接的手机
我们可以借助多种技术,利用用户的手机来获取时间和时区数据。对于所有手机,必须在手机上以及车载信息娱乐 (IVI) 系统上安装一对自定义应用和配套应用。然后,您就可以按照所需的间隔同步时间了。例如,在建立连接时,以及手机检测到新的时区时。
一些支持蓝牙低功耗 (BLE) 的手机提供了通过 GATT 当前时间特性和当前时间服务配置文件规范 1.1 来检索时间的选项。不过,这种选项无法满足足够大的细分市场的要求,因此不应完全依赖于它。
优点 | 缺点 |
---|---|
|
|
使用来源
每家设备供应商都必须确定要设定多高的门槛,以及哪些用户体验历程是最关键的。只有清楚地了解所需的关键用户体验,才能做出最佳决策。在大多数情况下,供应商必须在便利性和实现复杂性之间进行权衡。
上述每个选项都有各自的优势和劣势。例如,必须在如下方面做出关键的设计选择:与偶尔出现的时间显示不清的情况相比,多大程度的弹性是可以接受的;以及如何化解相应的不利因素。一个完全自动的解决方案预计可以在所有情况下都出色地运行,但它必须基于几个信息来源的组合。没有一个选项可实现 100% 的可用性。
手动配置选项是一种临时后备方案,易于执行,在实际使用情形中对许多用户而言已经足够。