时区选项

准确显示时间是车载信息娱乐系统的一项核心功能。虽然这可能看起来很简单,特别是在人们对时间和时区管理的期望值较低且必须满足时,但是,如果必须在没有人工干预的情况下显示可靠准确的日期和时间,时间问题很快就会变得复杂起来。

系统芯片 (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)。其他移动网络无线装置标准具有同等的功能。

遗憾的是,大多数标准的共性在于,这些信息的发送是可选的,因此并非在所有网络中都广泛提供。

优点 缺点
  • 如果可用的话,可提供大部分所需的信息。
  • 简洁,在移动网络无线装置作为手机(而不仅仅是数据调制解调器)提供时就已受 Android 支持。
  • 不需要连接到互联网。
  • 不能保证信息会进行广播,也不能保证基站会正确配置。

  • 在边境地区容易接上相邻国家/地区的(漫游)手机基站,有可能传递错误的时区。

  • 在某些位置,更新可能需要数小时甚至数天才能完成。

网络时间协议

网络时间协议 (NTP) 通常用于获取相对精确的 Unix 纪元时间信息。Android 支持将系统时间与 NTP 服务器的时间同步,前提是能够通过通用 RadioTuner.getParameters() 元数据向 RadioManager 的客户端提供 NTP 服务器的时间。如果系统时间没有同步,并且运营商最近没有提供 NITZ 更新,NTP 会更新系统时间。如果用户在 NITZ 不可用时启用 AUTO_TIME,系统会立即检查网络时间。

优点 缺点

简洁,受 Android 支持。

  • 不完整,NTP 只提供一个需要的值(时间)。即使在最好的情况下,NTP 也无法提供时区。

  • 需要连接到互联网。

广播无线装置调谐器

利用内置的调谐器来检索时间和时区信息虽然极具吸引力,但也需要克服一些挑战。众多无线装置广播标准定义了多个选项,用于提供所需的信息。一般来说,广播无线装置调谐器提供的信息与移动网络无线装置相同。

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 电台,这些信息的广播是可选的,因此不应完全依赖于它。

优点 缺点
  • 通常适用于不同的地区性广播无线装置标准。
  • 不需要连接到互联网。
  • Android 对此不提供开箱即用的支持。
  • 需要开启调谐器(至少偶尔在后台运行),以可靠地检测信息。
  • 可靠性取决于广播方。

实现提示

Android 支持将系统时间与 NTP 服务器的时间同步,前提是能够向 RadioManager 的客户端提供 NTP 服务器的时间。建议的解决方案是使用供应商扩展功能。此功能必须在硬件抽象层 (HAL) 中实现,之后,它可以通过常规 RadioTuner.getParameters() 方法提供给 RadioManager 的客户端。

为了让该解决方案保持稳健性,此供应商扩展的使用方必须确定 HAL 是否支持该功能(不要假定存在这类支持)。getParameters 调用的参数字符串必须进行清晰的整理,供各供应商明确使用。例如,可通过在贵组织的命名空间前面加上合适的域名前缀(例如 com.me.timezoneTuner.currenttimezone)来使用它。

考虑到此类信息的事件驱动性质,使用 RadioTuner.Callback.onParametersUpdated() 回调来接收此类信息可能大有裨益。如果这个功能应该是可配置的,可以在 setParameters 之上设计一套自定义例程。例如:

com.me.timezoneTuner.currenttimezoneEvent.enable

全球导航卫星系统 (GNSS) 本身只能提供准确的时间信息和位置信息。

地理定位

解决这一不便的方案是执行反向地理编码,根据位置进行查询来确定国家/地区和时区。在确定车辆的位置信息方面,GNSS 是显而易见的(也是最优质的)选择。Google 的 Time Zone API 提供了运行必要的转换所需的全部功能。当然,还必须连接到互联网。在实现在线解决方案时,确保用户隐私必定是首要任务!在消耗流量之前,需要先确认用户是否接受流量使用费;必须请求这一许可。

可以制定一个适合离线使用的解决方案。一个具有足够的分辨率,可准确确定国家/地区和时区的本地地图数据库可以装入车辆的存储器中。部署了这个数据库,再加上可根据需要更新时区(和国家/地区)信息且完全实现的策略,就可以根据从定位子系统获取的 GNSS 位置信息对国家/地区/时区进行反向地理编码。

优点 缺点
  • 可以明确确定正确的时区。
  • 不需要连接到互联网(如果使用本地数据库)。
  • 在大多数驾驶场景下都能可靠地运行。
  • Android 对此不提供开箱即用的支持。
  • 如果在初始配置期间,车辆位于室内/有遮挡的地方,无法接收到良好的 GNSS 卫星信号,则无法获得准确的时间、位置和时区信息。
  • 本地数据库需要更新机制。
  • 实现比较复杂。

已通过蓝牙、Wi-Fi 或 USB 连接的手机

我们可以借助多种技术,利用用户的手机来获取时间和时区数据。对于所有手机,必须在手机上以及车载信息娱乐 (IVI) 系统上安装一对自定义应用和配套应用。然后,您就可以按照所需的间隔同步时间了。例如,在建立连接时,以及手机检测到新的时区时。

一些支持蓝牙低功耗 (BLE) 的手机提供了通过 GATT 当前时间特性当前时间服务配置文件规范 1.1 来检索时间的选项。不过,这种选项无法满足足够大的细分市场的要求,因此不应完全依赖于它。

优点 缺点
  • 不需要连接到互联网。
  • 手机检测到的时区更改可能会中继到车机。
  • Android 对此不提供开箱即用的支持。
  • 仅在手机连接到车机时有效。
  • 时间的质量好坏与手机提供的内容一样。
  • 实现比较复杂。
  • 并非所有手机都支持 BLE GATT 当前时间服务配置文件。

使用信息来源

每家设备供应商都必须确定要设定多高的门槛,以及哪些用户体验历程是最关键的。只有清楚地了解所需的关键用户体验,才能做出最佳决策。在大多数情况下,供应商必须在便利性和实现复杂性之间进行权衡。

上述每个选项都有各自的优势和劣势。例如,必须在如下方面做出关键的设计选择:与偶尔出现的时间显示不清的情况相比,多大程度的弹性是可以接受的;以及如何化解相应的不利因素。一个完全自动的解决方案预计可以在所有情况下都出色地运行,但它必须基于几个信息来源的组合。没有一个选项可实现 100% 的可用性。

手动配置选项是一种临时后备方案,易于执行,在实际使用情形中对许多用户而言已经足够。