Android Automotive：在路上释放 Android 操作系统的力量

Android Automotive：在路上释放 Android 操作系统的力量

https://medium.com/@amoljp19/android-automotive-unleashing-the-power-of-android-os-on-the-road-6587c4835ad7

随着谷歌 Android 汽车操作系统的主导，汽车行业兴奋不已。这个复杂的操作系统旨在将您的驾驶体验提升到一个全新的水平——安全、互联和娱乐。

了解全球汽车制造商如何采用 Android 汽车操作系统。一些公司已经与谷歌合作创建最先进的信息娱乐系统，由谷歌汽车服务（GAS）提供支持。其他人正在探索带有汽车扩展的开源 AOSP，以打造自己的 Android 汽车系统。

与我一起踏上这个充满技术的旅程，我们深入了解 Android Automotive 的功能、架构和兼容性，释放它对未来交通的全部潜力。准备好以时尚的方式拥抱前方的道路！

Android 在汽车行业的历程

车载信息娱乐系统 (IVI) 的演变

IVI的概念可以追溯到最早的汽车收音机，它可以让驾驶员和乘客在路上享受音乐。多年来，IVI 系统经历了重大变革，以适应技术的进步和消费者的需求。导航系统、CD 播放器以及后来的 DVD 播放器的集成标志着 IVI 发展的重要里程碑。

然而，真正的突破是随着智能手机和触摸屏技术的出现而出现的。IVI 系统现在提供与智能手机的无缝集成，使驾驶员能够访问联系人、免提通话以及直接从汽车仪表板使用导航应用程序。

顺便说一句，什么是车载信息娱乐系统？

车载信息娱乐系统通常称为 IVI，是指车辆中为驾驶员和乘客提供娱乐、信息、连接和导航服务的集成多媒体系统。这些系统旨在提供广泛的功能，同时确保最大限度地减少对驾驶员的干扰，从而优先考虑道路安全。

汽车中的 Android：演变和进步

Android 进入汽车领域可以追溯到2014 年****Android Auto的推出。这项突破性技术允许用户将智能手机屏幕镜像到汽车主机显示屏上，提供对各种应用程序和功能的访问，同时促进安全驾驶实践。

Android Auto使驾驶员能够使用语音命令或简化的界面与 Google 地图、Spotify 和消息服务等应用程序进行交互，从而减少在路上的干扰。大约在同一时间，Apple CarPlay也出现了，为 iPhone 用户提供了类似的体验。

Android 汽车操作系统的崛起

随着对更加集成和无缝体验的需求不断增长，Android 汽车操作系统的概念于 2017 年开始发挥作用。与 Android Auto 不同，Android Automotive 操作系统直接在汽车主机内运行，为车辆创建专用的 Android 环境。

Android 汽车操作系统不仅仅只是镜像智能手机应用程序，而是提供了一个针对车载使用进行优化的完整操作系统。这种级别的集成提供了更加统一和响应更快的用户体验，可以直接从主机访问本机应用程序和功能。

Polestar 2：开创 Android 汽车体验

Polestar 2 的推出标志着 Android 汽车之旅的一个重要里程碑。作为第一款完全采用 Android Automotive 操作系统的车辆，Polestar 2 为车载技术树立了新标准。这款全电动汽车由 Google 服务提供支持，展示了汽车内完全集成的 Android 生态系统的潜力。

img

Polestar 2 是第一款搭载 Android 汽车操作系统的汽车

借助 Android Automotive OS，Polestar 2 不仅能让驾驶员无缝访问他们喜爱的应用程序，还引入了智能语音助手和个性化建议，以增强驾驶体验。此外，该系统还允许无线更新，确保车辆的软件保持最新，具有最新的功能和改进。

Android 开源项目 (AOSP) 及其他项目

在幕后，Android 开源项目 (AOSP) 一直是 Android 汽车操作系统开发的推动力。AOSP 是 Android 的基础，包括其汽车变体，但它并不是汽车制造商可以立即部署的解决方案。

汽车制造商需要前端用户界面、基本应用程序和后端服务来创建功能齐全的车内体验。为了解决这个问题，Google 提供了额外的解决方案和工具来帮助汽车制造商在 AOSP 之上开发自定义界面和服务。

Google 汽车服务 (GAS)：提升车内体验

GAS 提供了一套全面的集成服务，增强了 Android Automotive OS 的功能。这些服务类似于 Android 智能手机上常见的谷歌移动服务，确保为驾驶员和乘客提供无缝的用户体验。

  1. Play 商店： GAS 包括 Play 商店，允许用户发现并安装专为车内使用而定制的各种汽车和娱乐应用程序。这个应用程序市场开辟了一个充满可能性的世界，使驾驶员能够根据自己的喜好定制他们的信息娱乐体验。
  2. **谷歌助理：**有了谷歌助理，驾驶员可以使用语音命令轻松地与车辆互动。从导航到目的地到控制媒体播放，Google Assistant 的自然语言处理使驾驶时的任务变得更加方便和安全。
  3. **Google 地图：**著名的地图和导航服务 Google 地图提供实时路况更新、路线导航和兴趣点。其与 GAS 的集成可确保驾驶员能够使用可靠且准确的导航工具，实现无压力的旅程。

使用 GAS 运营：许可证要求和质量标准

要在车辆中部署 GAS，汽车制造商必须获得Google 的单位许可证。然而，获得 GAS 的使用权不仅仅是获得许可；车辆还必须通过一系列测试，例如兼容性测试套件（CTS）、供应商测试套件（VTS）和应用程序测试套件（ATS）。这些测试确保 GAS 的集成符合 Google 严格的质量标准，为不同车型提供一致且可靠的体验。

每单位许可证

当汽车制造商决定将 Google 汽车服务 (GAS) 集成到其车辆中时，他们必须从 Google 获得单位许可证。该许可证是按每辆车授予的，这意味着对于将使用 GAS 的每种车型，汽车制造商都需要单独的许可证。

按单位许可为汽车制造商提供了使用Google 服务套件的****合法权利，其中包括 Play 商店、Google Assistant 和 Google Maps 等流行应用程序，作为其信息娱乐系统的一部分。这些服务通过提供对各种应用程序的访问、语音控制帮助和可靠的导航工具来增强整体用户体验。

质量标准和测试

为了确保不同车型和制造商的用户获得一致、可靠的体验，Google 为 GAS 集成制定了严格的质量标准。这些标准通过一系列测试得到验证：

  1. 兼容性测试套件 (CTS)：兼容性测试套件评估汽车制造商的 GAS 实施是否符合 Google 制定的定义标准和要求。它检查系统是否满足必要的功能、性能和安全标准。
  2. 供应商测试套件 (VTS)：供应商测试套件侧重于集成的特定于硬件的方面。它确保 GAS 与每种车型的信息娱乐系统中使用的特定硬件组件无缝运行。
  3. 应用程序测试套件 (ATS)：应用程序测试套件评估****第三方应用程序与 GAS的兼容性。**例如，**它可以确保 Play 商店中的应用程序在 GAS 环境中顺利运行，并且不会导致冲突或问题。

汽车制造商必须根据这些测试套件彻底测试其 GAS 集成，并满足所有指定的要求。成功通过这些测试是获得 Google 批准在其车辆中使用 GAS 的关键一步。

满足质量标准的好处

遵守 Google 的质量标准并通过测试可为汽车制造商和最终用户带来多项显着优势：

  1. 可靠性：满足质量标准可确保 GAS 集成可靠运行，最大限度地减少车内体验中的潜在故障或中断。
  2. 一致性：成功的 GAS 集成意味着同一汽车制造商的不同车型甚至采用 GAS 的不同制造商之间具有一致的用户体验。
  3. 访问 Google 服务： GAS 集成获得批准后，汽车制造商即可访问一套 Google 服务，为用户提供熟悉且功能丰富的车辆体验。
  4. **未来兼容性：遵守质量标准可确保 GAS 集成能够与Google未来的更新和改进良好配合，**从而确保对信息娱乐系统的长期支持。

Android汽车架构

下面给出了 Android 汽车操作系统的高级架构图。

img

Android Automotive的抽象层架构分为四层

它由以下四个主要通用组件组成：

应用框架

应用框架层，也称为**HMI（人机界面），**负责为汽车的信息娱乐系统提供用户界面。它包括用户应用程序（例如音乐播放器和导航应用程序）以及系统应用程序（例如汽车设置和语音助手）。

在这一层设计应用程序非常重要，并将大多数核心业务功能转移到服务层。这种方法确保了未来的可扩展性和轻松更新。

应用框架层包含更多部分，如下所示：

1. Android 开源项目 (AOSP)： Android 开源项目 (AOSP) 是 Android 设备的基础软件。它包括所有必要的组件，如系统应用程序、应用程序框架、系统服务和 HAL 接口。这些组件被组织为“ GIT 树包”。

在 AOSP 中，您可以找到通用系统应用程序，例如默认启动器、联系人应用程序和时钟应用程序。应用程序框架提供了用于应用程序开发的工具。系统服务管理网络连接和安全等重要功能。HAL 接口有助于与设备特定的硬件进行交互。

当你在设备上安装Android时，所有这些组件都存储在**/system分区**中，该分区就像Android系统的“核心”。自定义 ROM 替换这些文件以提供不同的功能和优化。

2. OEM 和第3 方应用程序： OEM 和第3 方应用程序是汽车信息娱乐系统的**“面孔” 。**它们是人们看到并与之互动的东西。HMI 是人们与这些应用程序交互的方式。而应用程序后台服务则是保证整个系统顺利运行的东西。

顺便说一句，什么是 OEM？

OEM 代表原始设备制造商。一般来说，OEM 是指生产以另一家公司的品牌名称销售的产品的公司。例如，Bose 是音响系统的 OEM。他们生产音响系统，并以丰田、福特和本田等其他公司的品牌销售。

换句话说，Bose 是实际制造音响系统的公司，而丰田、福特和本田则是向客户销售音响系统的公司。

在 Android Automotive OS 架构的背景下，OEM 是指使用 Android Automotive OS 作为其汽车信息娱乐系统操作系统的汽车制造商。

OEM 在如何使用 Android 汽车操作系统方面具有很大的灵活性。他们可以定制系统的外观和感觉，添加自己的应用程序，并将系统与汽车的其他系统集成。

以下是使用 Android 汽车操作系统的 OEM 的一些示例：

沃尔沃：沃尔沃是一家瑞典汽车制造商，在其****XC40 Recharge 电动汽车中使用 Android Automotive OS 。

雷诺：雷诺是一家法国汽车制造商，在其****梅甘娜 E-Tech 电动汽车中使用 Android 汽车操作系统。

本田：本田是一家日本汽车制造商，在其****e:NS1 电动汽车中使用 Android Automotive OS 。

这些组件存储在汽车硬盘上的**/product 分区中。**这是一个独立于 /system 分区的分区，其中包含 Android 操作系统本身。这种分离允许 OEM 和开发人员定制汽车的信息娱乐系统，而不会影响底层的 Android 操作系统。

Android 汽车系统服务

该层包含所有重要的系统服务，用于处理 Android Automotive 系统中的各种基本功能，例如管理网络连接、电源和安全功能。

这一层的一个有趣的方面是，它就像系统的安全防护罩。它们不让应用程序通过硬件抽象层 (HAL) 直接与硬件通信，而是与系统服务交互。这些服务充当应用程序和硬件之间的中介。

这种方法在安全性方面具有显着的优势。通过使用服务层作为中间人，OEM 可以确保以安全的方式访问和控制硬件的敏感功能。它可以防止常规应用程序直接访问硬件，从而降低潜在漏洞或未经授权访问的风险。

Android 汽车系统服务层包含更多部分，如下所示：

1.汽车服务：汽车服务是Android汽车架构服务层的重要组成部分。它们为应用程序与汽车硬件和软件进行交互提供了一致、安全且高效的方式。这些服务的一些示例包括CarPropertyService、CarAudioService、CarClimateControlService和CarNavigationService。

**2. 汽车管理器：**汽车管理器是一组系统管理器，提供对汽车硬件和软件的访问。它们作为一组类来实现，每个类负责汽车的特定区域，例如音频系统、气候控制系统或导航系统。

img

不同汽车管理器的概述及其各自的描述

硬件抽象层 (HAL)

硬件抽象层（HAL）起着至关重要的作用。它充当车辆硬件（特别是电子控制单元 (ECU)）与系统其余部分（包括应用程序框架和系统服务）之间的桥梁。

HAL 的主要目的是公开标准化接口，系统服务可以使用这些接口与车辆内的不同硬件组件进行通信。这创建了一个“与车辆无关”的架构，这意味着 Android Automotive 系统不需要了解每辆车硬件的具体细节。

通过使用 HAL，系统服务可以以一致且标准化的方式与车辆硬件进行交互。这使得数据交换和各种汽车功能的控制成为可能，例如处理传感器、管理显示器以及控制音频和气候系统。

Vehicle HAL： Vehicle HAL 是 Android Automotive 架构中的重要组成部分。其主要目的是为系统服务与汽车专用硬件和功能进行通信提供标准化且适应性强的方式。

Vehicle HAL 提供对各种汽车特定功能的访问，包括：

  • 车辆中 ECU 发出/发出的信号： ECU **（电子控制单元）**是汽车的电子大脑。他们控制从发动机到气候控制系统的一切。Vehicle HAL 提供对 ECU 之间发送的信号的访问，从而允许 Android Automotive 系统监视和控制汽车系统。
  • 从车辆微控制器单元生成的信号发送至 IVI OS： IVI **OS（车载信息娱乐操作系统）**是在汽车信息娱乐系统上运行的软件。车辆 HAL 提供对汽车微控制器单元生成的信号的访问，从而允许 IVI OS 与汽车硬件进行交互。
  • 访问车辆网络上可用的面向服务的功能（例如：SOME-IP）： SOME-IP 是车辆中面向服务的通信的标准。Vehicle HAL 提供对汽车网络上可用的 SOME-IP 服务的访问，这允许 Android Automotive 系统与汽车中的其他设备进行通信。

板级支持包 (BSP)

在 Android Automotive 架构中，**BSP 代表“板支持包”。**它是一个关键组件，在使 Android Automotive 系统与特定硬件配置（**尤其是片上系统 (SoC) 设备）**兼容方面发挥着至关重要的作用。

片上系统 (SoC) 是指一种半导体集成电路 (IC)，它将计算机或电子系统的多个基本组件集成到单个芯片上。它是一个完整的单芯片计算系统，包括中央处理单元（CPU）、内存、图形处理单元（GPU）、输入/输出接口和各种其他组件。

img

片上系统 (SoC)：智能手机、平板电脑、笔记本电脑、电视和汽车的大脑。

BSP 是 Android Automotive 架构的重要组成部分，因为它允许操作系统与汽车硬件进行交互。这是操作系统运行和应用程序正常运行所必需的。

BSP 也很重要，因为它允许 OEM 定制汽车的信息娱乐系统。OEM 可以使用自己的代码和应用程序扩展 BSP，这使他们能够添加特定于其汽车的功能。

BSP通常由 SoC 供应商或 OEM 开发。然后将其提供给 Android Automotive 团队，后者将其集成到 Android Automotive 操作系统中。

Linux 内核： BSP 通常包含 Linux 内核映像，它是操作系统的核心。Linux 内核处理硬件交互，并为在给定硬件平台上运行 Android 提供基础。

AIDL 和 HIDL

在 Android Automotive 架构中，**AIDL（Android 接口定义语言）和HIDL（HAL 接口定义语言）**在实现系统不同组件之间的通信方面发挥着重要作用。

AIDL（Android 接口定义语言）：

  • AIDL是一种通信接口，主要用于Android系统上运行的应用程序之间的进程间通信（IPC）。
  • 在 Android Automotive 中，AIDL 用于用户应用程序和系统服务之间的通信。它使应用程序能够与系统服务交互并访问 Android 框架提供的某些功能。
  • AIDL 通常用于远程方法调用，其中一个应用程序可以向运行在不同进程中的另一个应用程序请求服务。

HIDL（HAL 接口定义语言）：

  • HIDL 是用于与硬件抽象层 (HAL) 交互的通信接口。
  • 在 Android Automotive 中，HIDL 允许系统服务和其他组件与车辆的硬件特定功能进行通信。
  • HAL 抽象了特定于硬件的细节，并通过 HIDL 公开标准化接口，从而允许系统的其余部分以一致的方式与车辆的硬件进行交互。

因此，AIDL 用于用户应用程序和系统服务之间的通信，而 HIDL 则有助于 Android 系统服务和硬件抽象层 (HAL) 之间的通信。

Project Treble 和 Android 汽车操作系统

Project Treble是 Google在 Android 8.0 Oreo 中推出的一项举措，旨在解决 Android 碎片化的挑战（*这里碎片化是指许多 Android 设备运行不同版本操作系统的情况*），并使设备制造商更容易将其设备更新到较新的 Android 版本。它将Android操作系统框架与特定于硬件的组件分开，允许制造商在不修改较低级别的硬件驱动程序和固件的情况下更新Android操作系统。

img

高音项目

在 Android 汽车操作系统的背景下，Project Treble 也有类似的目标，但适应了汽车信息娱乐系统的特定需求。Android 汽车操作系统构建于常规 Android 操作系统之上，但针对车辆使用进行了优化。它提供定制的用户界面，并与汽车特定的硬件和功能集成。

Android 汽车操作系统中的 Project Treble 可帮助汽车制造商 (OEM) 更高效地更新其车载信息娱乐系统。将 Android 操作系统框架与特定于硬件的组件分离，使 OEM 能够专注于开发和更新其独特的信息娱乐功能，而不会因复杂的硬件集成造成的延迟而受到阻碍。

Android 开源项目 (AOSP) 架构

在 Android 开源项目 (AOSP) 架构中，Android 系统服务之上的所有内容都称为“Android 框架”，由 Google 提供。这包括各种组件，例如用户界面、应用程序开发框架和系统级服务。

img

AOSP架构

另一方面，硬件抽象层（HAL）和内核由片上系统（SoC）和硬件供应商提供。HAL 充当 Android 框架和特定硬件组件之间的桥梁，允许 Android 系统在不同的硬件配置下高效工作。

谷歌开创性地扩展了Android开源项目（AOSP），创建了一个完整的车载信息娱乐操作系统（我们稍后会详细介绍）。下面是对扩展的简单解释：

  1. 汽车系统应用程序： 谷歌添加了专为车内使用而设计的特定应用程序，例如音乐播放器、导航应用程序和通信工具。这些应用程序经过优化，可在驾驶时轻松、安全地使用。
  2. 汽车 API： Google 推出了专门的应用程序编程接口 (API)，允许开发人员访问汽车特定的功能。这些 API 为应用程序提供了与传感器和控件等汽车功能进行交互的标准化方式。
  3. 汽车服务： 汽车服务是处理汽车特定功能的系统级组件，例如管理汽车传感器、音频系统和气候控制。这些服务为应用程序与汽车硬件交互提供了一致且安全的方式。
  4. 车辆硬件抽象层： 为了与不同车辆的独特硬件组件进行交互，Google 开发了车辆硬件抽象层（HAL）。它充当 Android 系统和特定硬件之间的桥梁，使各种汽车能够获得无缝且一致的体验。

通过将这些扩展与现有的 Android 系统相结合，谷歌创建了一个功能齐全且适应性强的车载信息娱乐操作系统。该系统无需进行重大修改即可用于不同的车辆，为驾驶员和乘客提供统一且人性化的体验。

高音组件

Project Treble 向 Android 架构引入了多个新组件，以增强模块化并简化Android 设备的更新过程。

img

显示 Treble 新添加的内容

让我们简要解释一下每个组件：

  1. **新的 HAL 类型：**这些是硬件抽象层 (HAL)，可帮助 Android 系统以标准化方式与各种硬件组件进行通信。它们允许更轻松地将不同硬件集成到 Android 系统中。
  2. 硬件接口定义语言 (HIDL)： HIDL 是一种用于定义 HAL 和 Android 框架之间的接口的语言。它使硬件和软件之间的通信更加高效。
  3. 新分区： *Treble 在 Android 系统中引入了新分区，例如 /vendor 分区。这些分区有助于分隔系统的不同部分，使更新更容易、更快*。
  4. ConfigStore HAL： 该组件管理硬件组件的配置设置。它提供了访问和更新配置数据的标准化方法。
  5. 设备树覆盖： 设备树覆盖可以更改硬件配置，而无需修改内核。它允许更轻松地定制硬件。
  6. **供应商 NDK：**供应商本机开发套件 (NDK) 为设备制造商提供工具和库，以开发特定于其硬件的软件。它简化了定制功能的集成。
  7. 供应商接口对象： 供应商接口对象 (VINTF) 定义 Android 操作系统和供应商的 HAL 实现之间的稳定接口。它确保兼容性和平滑更新。
  8. 供应商测试套件 (VTS)： VTS 是一个测试套件，可确保 HAL 实现与 Android 框架正常工作。它有助于验证设备的兼容性和可靠性。

Project Treble 的组件使 Android 更加模块化、高效且可定制。它们简化了与硬件的通信，分离了系统组件，并允许设备制造商更轻松地更新和优化其设备，从而带来更好的用户体验和更快的 Android 更新。

Android Automotive 中的模块化与 Treble

由于 Project Treble 带来的架构变化以及分区使用的扩大，Android Automotive 的未来已变得更加灵活和适应性强。此增强功能不仅限于人机界面 (HMI) 层，还允许对 Android 框架、主板支持包 (BSP) 甚至硬件（如果需要）进行潜在的替换。

简单来说，Android Automotive系统的核心组件变得更加独立和模块化。这意味着制造商现在可以自由地升级或定制系统的特定部分，而无需从头开始。其结果是一个高度面向未来的系统，可以轻松拥抱新兴技术并满足不断变化的用户偏好。

让我们深入研究一下这种转变，看看在 Project Treble 实施后如何实现这种模块化：

Treble 之前的 HAL

在 Project Treble 之前，HAL 接口被定义为位于 Android 系统的 hardware/libhardware 文件夹中的 C 头文件。Android的每个新版本都需要HAL支持新的接口，这意味着硬件供应商需要付出巨大的努力和改变。

img

Treble 之前的 HAL

简单来说，HAL 过去与 Android 框架紧密耦合，每当发布新的 Android 版本时，硬件供应商都必须更新其 HAL 以匹配新接口。这个过程既耗时又复杂，导致设备更新延迟，并且很难跟上最新的 Android 功能。

Project Treble 通过引入硬件接口定义语言 (HIDL) 解决了这个问题。借助 HIDL，HAL 接口现在以更加标准化和独立的方式定义，使硬件供应商可以更轻松地实现和更新其 HAL 以支持新的 Android 版本。这一变化显着提高了 Android 更新的效率，并实现了更加灵活、面向未来的 Android 生态系统。

直通 HAL

在 Android Automotive 的上下文中，直通 HAL 是使用硬件接口定义语言 (HIDL) 接口的特殊硬件抽象层 (HAL)。传递 HAL 的独特之处在于您可以直接从应用程序进程中调用它们，而无需通过通常的 Binder 通信。

img

直通 HAL

简单来说，当应用程序想要与常规 HAL 交互时，它会使用 Binder 机制进行通信，这涉及到在不同进程之间传递消息。但是，通过传递 HAL，您可以从应用程序的进程直接与 HAL 进行通信。这种直接调用方法可以在汽车环境中的特定任务的效率和性能方面提供一定的优势。它允许应用程序以减少的开销和更快的响应时间访问硬件功能。

粘合剂化的 HAL

在 Android Automotive 上下文中，Binderized HAL 在其专用进程中运行，并且只能通过 Binder 进程间通信 (IPC) 调用进行访问。此设置可确保 Android 系统和 HAL 之间的通信安全且高效。

img

粘合剂化的 HAL

关于旧版 HAL，Google 已经创建了一个包装器，使它们可以在 Binderized 环境中工作。该包装器充当中间层，允许现有的 Legacy HAL 通过 Binder IPC 机制与 Android 框架进行通信。因此，这些旧版 HAL 可以与 Binderized HAL 一起无缝运行，确保兼容性并顺利过渡到新架构。

从本质上讲，包装器在旧版硬件组件和现代 Android 系统之间提供了一座桥梁，使旧版 HAL 能够在 Binderized 环境中协同工作。这种方法确保 Android Automotive 系统可以受益于 Binderized HAL 的改进性能和安全性，同时仍然支持和集成依赖于旧版 HAL 的旧硬件。

理想的 HAL

在理想情况下，Binderized HAL 是 Android 中硬件抽象层 (HAL) 的首选方法。Binder 化的 HAL 在其专用进程中运行，并通过安全的 Binder 进程间通信 (IPC) 机制进行访问。这种设计确保了高效的通信、更好的安全性以及硬件功能与 Android 系统的分离。

img

理想的 HAL

然而，由于某些原因，我们没有按照预期实现 Binderized HAL。相反，我们使用不同的方法，可能使用最初不是为 Binder IPC 设计的遗留 HAL。虽然这种替代方法可能有效，但它可能无法提供 Binderized HAL 的全部优势，例如改进的性能和安全性。

重要的是要认识到，坚持使用理想的 Binderized HAL 可以提供多种优势，并且符合 Google 推荐的最佳实践。如果可能，最好考虑过渡到 Binderized HAL，以获得更强大、更高效的 Android Automotive 系统。

详细架构

现在，如您所知，在 Android 8.0 中，Android 操作系统经历了重新架构，以在独立于设备的 Android 平台和特定于设备或供应商的代码之间建立清晰的界限。在此更新之前，Android 已经定义了称为 HAL 接口的接口，这些接口编写在位于 hardware/libhardware 中的 C 头文件中。

通过重新架构，这些 HAL 接口被称为 HIDL（HAL 接口定义语言）的新概念所取代。HIDL 提供稳定且版本化的接口，可以用 Java 编写，也可以用 C++ 编写为客户端和服务器端 HIDL 接口。

img

详细架构C++

HIDL 接口的主要目的是从本机代码中使用，特别是专注于自动生成高效的 C++ 代码。这是因为对于低级硬件交互来说，本机代码通常更快、更高效。但是，为了保持兼容性并支持各种 Android 子系统，一些 HIDL 接口也直接暴露给 Java 代码。

img

详细架构/Java

例如，某些 Android 子系统（例如 Telephony）利用 Java HIDL 接口与底层硬件组件进行交互。这使他们能够受益于 HIDL 提供的稳定且版本化的接口定义，确保独立于设备的 Android 平台和设备特定代码之间的无缝通信。

Android汽车操作系统在汽车中的架构

Android Automotive OS 是 Android 操作系统的专门版本，旨在为车载信息娱乐和其他互联服务提供支持。它作为主要操作系统，提供对各种汽车服务和应用程序的访问。

它由三个主要组件组成：Vehicle HAL、Car Service 和 Car Manager。让我们仔细看看它们是如何协同工作的。

img

Android汽车操作系统架构

从底层开始是连接到车辆总线（通常是 CAN（控制器局域网）总线）的电子控制单元 (ECU)。ECU 是车辆不可或缺的一部分，因为它们监视和控制车辆运行的各个方面。

在 Android 方面，我们有车辆硬件抽象层 (VHAL)。VHAL 将来自车辆总线的信号转换为车辆属性，在 Android 12 中具有超过 150 个预定义的“系统”属性。例如，“PERF_VEHICLE_SPEED”代表车辆的速度（以米每秒为单位），制造商可以添加自己的“供应商”属性。

汽车服务建立在这些车辆属性的基础上，并通过其他来源的附加信息来丰富它们，从而为应用程序创建了一组有用的服务。

应用程序不直接调用汽车服务；相反，它们与实现 android.car.* 包的 Car Manager 库交互。Android 开源项目 (AOSP) 中的演示汽车应用展示了如何使用这些 android.car 类。这些应用程序通常由汽车制造商预安装，可以访问低级功能，例如控制汽车的侧窗。

最后，Play 商店或其他应用商店提供第三方汽车应用。这些应用程序对汽车某些部分的访问受到限制，并且必须遵守指南以防止驾驶员分心。它们提供音乐流媒体、有声读物和导航等功能。

Android 汽车操作系统 (AAOS) 详细架构视图

Android Automotive 的软件组件架构是一个分层系统，允许汽车应用、汽车管理器、汽车服务以及底层车辆 HAL 和 ECU 之间的无缝交互。

img

详细架构视图

这种详细的架构视图使开发人员和汽车制造商能够创建创新、安全且用户友好的应用程序，以增强驾驶体验。

车辆HAL

车辆 HAL（硬件抽象层）是管理有关车辆及其功能的信息的组件。它将这些信息存储为**“车辆属性”。**这些属性就像代表车辆各个方面的数据点。

例如，一些常见的车辆属性包括：

speed： 一个浮点值，表示车辆的速度（以米每秒为单位）。

加热控制设置： 一个浮点值，表示加热系统的温度设置（以摄氏度为单位）。

这些属性通常与车辆通信总线上的信号相关。当总线上的信号发生变化时，它可以更新Vehicle HAL中相应的属性。此外，这些属性可以通过 Android 应用程序以编程方式更改。

简而言之，Vehicle HAL 将车辆相关信息作为属性进行管理和存储，这些属性可以通过车辆总线上的信号进行更新，也可以通过 Android 应用程序以编程方式进行更新。

系统属性标识符

Vehicle HAL 中的系统属性标识符是用于分类和标识特定属性的唯一标签。**它们标有“VehiclePropertyGroup:SYSTEM”**标签，以将其与其他类型的属性区分开来。

在 Android 12 中，此类标识符超过 150 个。每个标识符代表与车辆系统和功能相关的不同属性。例如，这些标识符之一是**“HVAC_TEMPERATURE_SET”，** 它代表为车辆的HVAC系统设置的目标温度。

让我们分解一下“HVAC_TEMPERATURE_SET”标识符的详细信息：

  • 属性名称： HVAC_TEMPERATURE_SET
  • 描述：表示 车辆***HVAC（供暖、通风和空调）***系统的目标温度设置。
  • 更改模式：该属性在 ***“ON_CHANGE”*模式下进行监控，这意味着只要目标温度发生变化就会触发事件。
  • 访问： 该属性可以读取和写入，允许应用程序检索当前目标温度并以编程方式更新它。
  • 单位： 温度值以摄氏度 (°C) 为单位测量。

车辆 HAL 中的系统属性标识符是对与车辆系统相关的不同属性进行分类的唯一标签。它们提供对各种功能的标准化访问，例如设置 HVAC 系统的目标温度。通过使用这些标识符，Android应用程序可以与车辆硬件无缝交互，从而增强用户体验并控制各种车辆功能。

扩展车辆财产

Vehicle HAL 还允许开发人员通过添加自己的标有“VehiclePropertyGroup:VENDOR”的标识符来扩展可用车辆属性的范围**。**此功能允许开发人员根据特定的车辆硬件和功能定制其应用程序。

扩展 VehicleProperty 需要在本机代码中定义标识符，如下所示：

原生代码：

constexpr  int VENDOR_EXAMPLE = ( int )( 0x1001 | VehiclePropertyGroup::VENDOR | VehiclePropertyType::INT32 | VehicleArea::GLOBAL);

在 C++ 中，我们定义了一个名为“VENDOR_EXAMPLE”的新常量，其十六进制值为 0x1001。我们使用按位 OR (|) 将其与 VehiclePropertyGroup、VehiclePropertyType 和 VehicleArea 的标志组合起来。标志 VehiclePropertyGroup::VENDOR 指示它是特定于供应商的属性，VehiclePropertyType::INT32 指示它是整数属性，而 VehicleArea::GLOBAL 指示它全局应用于车辆。

或者，它可以在 Java 中定义如下：

爪哇：

私有 静态 最终 int  VENDOR_EXAMPLE  =  0x1001 | 供应商|VehiclePropertyGroup.VENDOR | 车辆属性类型.INT32 | 车辆区域.GLOBAL;

在Java中，我们定义了一个名为“VENDOR_EXAMPLE”的新私有静态最终变量，其十六进制值为0x1001。我们使用按位或 (|) 将其与 VehiclePropertyGroup、VehiclePropertyType 和 VehicleArea 的标志组合起来。标志 VehiclePropertyGroup.VENDOR 指示它是供应商特定的属性，VehiclePropertyType.INT32 指示它是整数属性，VehicleArea.GLOBAL 指示它全局应用于vehicle。

此代码允许您创建一个名为“VENDOR_EXAMPLE”的新供应商特定属性，该属性可以在 C++ 和 Java 代码中访问和使用。它是一个全局适用于车辆的整数属性，唯一标识符 0x1001 有助于将其区分为供应商特定的属性。

VHAL 接口（IVehicle）

IVehicle.hal 文件

请注意，下面的 .hal 文件不是 Java、C++ 或 scss 文件（我选择了“自动模式”，因此它将采用 Java、C++ 或 scss）

顺便说一句，什么是 .hal 文件？

.hal 文件是一个硬件抽象层 (HAL) 文件，它定义硬件设备和 Android 操作系统之间的接口。HAL 文件是用硬件接口描述语言 (HIDL) 编写的，HIDL 是一种以独立于平台的方式描述硬件接口的语言。

package android.hardware.automotive.vehicle@2.0;
import IVehicleCallback;
interface IVehicle {
  /**
   * Returns a list of all property configurations supported by this vehicle
   * HAL.
   */
  getAllPropConfigs() generates (vec<VehiclePropConfig> propConfigs);
  /**
   * Returns a list of property configurations for given properties.
   *
   * If requested VehicleProperty wasn't found it must return
   * StatusCode::INVALID_ARG, otherwise a list of vehicle property
   * configurations with StatusCode::OK
   */
  getPropConfigs(vec<int32_t> props)
          generates (StatusCode status, vec<VehiclePropConfig> propConfigs);
  /**
   * Get a vehicle property value.
   *
   * For VehiclePropertyChangeMode::STATIC properties, this method must always
   * return the same value always.
   * For VehiclePropertyChangeMode::ON_CHANGE properties, it must return the
   * latest available value.
   *
   * Some properties like AUDIO_VOLUME requires to pass additional data in
   * GET request in VehiclePropValue object.
   *
   * If there is no data available yet, which can happen during initial stage,
   * this call must return immediately with an error code of
   * StatusCode::TRY_AGAIN.
   */
  get(VehiclePropValue requestedPropValue)
          generates (StatusCode status, VehiclePropValue propValue);
  /**
   * Set a vehicle property value.
   *
   * Timestamp of data must be ignored for set operation.
   *
   * Setting some properties require having initial state available. If initial
   * data is not available yet this call must return StatusCode::TRY_AGAIN.
   * For a property with separate power control this call must return
   * StatusCode::NOT_AVAILABLE error if property is not powered on.
   */
  set(VehiclePropValue propValue) generates (StatusCode status);
  /**
   * Subscribes to property events.
   *
   * Clients must be able to subscribe to multiple properties at a time
   * depending on data provided in options argument.
   *
   * @param listener This client must be called on appropriate event.
   * @param options List of options to subscribe. SubscribeOption contains
   *                information such as property Id, area Id, sample rate, etc.
   */
  subscribe(IVehicleCallback callback, vec<SubscribeOptions> options)
          generates (StatusCode status);
  /**
   * Unsubscribes from property events.
   *
   * If this client wasn't subscribed to the given property, this method
   * must return StatusCode::INVALID_ARG.
   */
  unsubscribe(IVehicleCallback callback, int32_t propId)
          generates (StatusCode status);
  /**
   * Print out debugging state for the vehicle hal.
   *
   * The text must be in ASCII encoding only.
   *
   * Performance requirements:
   *
   * The HAL must return from this call in less than 10ms. This call must avoid
   * deadlocks, as it may be called at any point of operation. Any synchronization
   * primitives used (such as mutex locks or semaphores) must be acquired
   * with a timeout.
   *
   */
  debugDump() generates (string s);
};

getAllPropConfigs():

*该接口返回 VHAL 支持的所有属性的列表。此列表包括属性 ID、属性类型和其他元数据。*

  • 生成(vec<VehiclePropConfig> propConfigs).
  • 列出 VHAL 支持的所有属性的配置。
  • CarService 仅使用受支持的属性。

getPropConfigs(vec<int32_t> props):

*该接口返回特定属性的配置。配置包括属性 ID、属性类型、访问权限和其他元数据。*

  • 生成(StatusCode status, vec<VehiclePropConfig> propConfigs).
  • 返回所选属性的配置。
  • 允许查询特定属性的配置。

set(VehiclePropValue propValue):

*该接口允许您向属性写入值。您写入的值必须是属性的正确类型。*

  • 生成(StatusCode status).
  • 将值写入属性。
  • 写入操作的结果是按属性定义的。

subscribe(IVehicleCallback callback, vec<SubscribeOptions> options):

*此接口允许您订阅属性，以便在其值更改时通知您。只要属性值发生更改，您提供的回调就会被调用。*

  • 生成(StatusCode status).
  • 开始监视属性值变化。
  • 对于分区属性，还有一种附加unsubscribe(IVehicleCallback callback, int32_t propId)方法可以停止监视给定回调的特定属性。

VHAL回调接口

IVehicleCallback.hal

package android.hardware.automotive.vehicle@2.0;
interface IVehicleCallback {
    /**
     * Event callback happens whenever a variable that the API user has
     * subscribed to needs to be reported. This may be based purely on
     * threshold and frequency (a regular subscription, see subscribe call's
     * arguments) or when the IVehicle#set method was called and the actual
     * change needs to be reported.
     *
     * These callbacks are chunked.
     *
     * @param values that has been updated.
     */
    oneway onPropertyEvent(vec<VehiclePropValue> propValues);
    /**
     * This method gets called if the client was subscribed to a property using
     * SubscribeFlags::SET_CALL flag and IVehicle#set(...) method was called.
     *
     * These events must be delivered to subscriber immediately without any
     * batching.
     *
     * @param value Value that was set by a client.
     */
    oneway onPropertySet(VehiclePropValue propValue);
    /**
     * Set property value is usually asynchronous operation. Thus even if
     * client received StatusCode::OK from the IVehicle::set(...) this
     * doesn't guarantee that the value was successfully propagated to the
     * vehicle network. If such rare event occurs this method must be called.
     *
     * @param errorCode - any value from StatusCode enum.
     * @param property - a property where error has happened.
     * @param areaId - bitmask that specifies in which areas the problem has
     *                 occurred, must be 0 for global properties
     */
    oneway onPropertySetError(StatusCode errorCode,
                              int32_t propId,
                              int32_t areaId);
};

看到这个文件后，您可能想知道什么是单向方法。

HAL 文件中的单向方法是一种不需要硬件设备响应的方法。单向方法通常用于异步操作，例如向硬件设备发送命令或从硬件设备接收通知。

以下是 HAL 文件中的单向方法的示例：

oneway void  setBrightness ( int亮度) ;

该方法将硬件设备的亮度设置为指定值。该方法不需要硬件设备的响应，因此调用者无需等待该方法完成即可继续。

单向方法通常与直通 HAL 结合使用。直通 HAL 是与调用应用程序在同一进程中运行的 HAL。这意味着直通 HAL 中的单向方法可以由调用应用程序直接调用，而不需要绑定器调用。

onPropertyEvent(vec<VehiclePropValue> propValues):

*每当您订阅的属性值发生更改时，就会调用此回调。回调将传递已更改的属性及其新值的列表。*

  • 一种单向回调函数。
  • 通知已注册回调的车辆属性值更改。
  • 此功能只能用于已订阅监控的属性。

onPropertySetError(StatusCode errorCode, int32_t propId, int32_t areaId):

*如果在尝试设置属性值时发生错误，则会调用此回调。回调将传递错误代码和正在设置的属性 ID。*

  • 一种单向回调函数。
  • 通知属性写入操作期间发生的错误。
  • 该错误可能与 VHAL 级别相关，也可能与某个属性和区域相关（在分区属性的情况下）。

这些接口和回调构成了 VHAL 与其他组件（例如 CarService 和应用程序）之间的核心通信机制，允许配置、查询、写入和监控车辆属性。这些接口的使用可能会根据VHAL在不同系统或平台中的具体实现而有所不同。

属性监控和通知

在车辆硬件抽象层（VHAL）及其属性的上下文中，该**IVehicle::subscribe**方法和**IVehicleCallback::onChange**回调用于监视车辆属性的变化。此外，还有一个**ChangeMode**枚举定义属性在更新频率方面的行为方式。

IVehicle::subscribe

  • 该**IVehicle::subscribe**方法用于注册回调（实现**IVehicleCallback**）以在订阅的属性更改时接收更新。
  • 此方法允许应用程序开始监视特定车辆属性的值变化。

IVehicleCallback::onChange

  • **IVehicleCallback::onChange**当订阅的属性有更新时，将调用回调函数。
  • 当属性更改并且 VHAL 检测到更改时，它会使用此回调函数通知所有已注册的回调。

ChangeMode枚举

  • 枚举**ChangeMode**定义特定属性在更新频率方面的行为方式。它有以下可能的值：
  • **STATIC**: 属性永远不会改变。
  • **ON_CHANGE****：**该属性仅在其值更改时发出事件信号。
  • **CONTINUOUS**： 属性不断变化，并以订阅者设置的采样率进行通知。

这些定义允许应用程序根据其特定需求订阅具有不同更新行为的属性。例如，如果应用程序有兴趣监视车辆速度，则它可以使用更改**CONTINUOUS**模式订阅速度属性，以以特定采样率接收连续的速度更新流。另一方面，如果应用程序对车辆的白天/夜间模式感兴趣，则它可以订阅改变**ON_CHANGE**模式以仅当模式从白天变为夜间时接收更新，反之亦然。

使用这些定义和方法可以有效监控和通知车辆属性的变化，确保应用程序能够及时了解来自车辆传感器和系统的最新数据。

汽车服务

汽车服务是一个系统服务，它提供了许多API供应用程序与车辆的硬件和软件进行交互。它被实现为一个名为com.android.car的****持久系统应用程序。服务名称为 car_service，接口为****android.car.ICar。

您可以将其视为汽车使用的特殊应用程序，称为**“com.android.car”**。它的主要工作是确保这些工具可用于其他应用程序。

如果您想与汽车服务交谈，您可以使用名为****“android.car.ICar”的东西。要获取有关汽车服务的更多信息，可以使用dumpsys car_service命令。该命令将打印出所有可用 API 及其描述的列表。您还可以使用 -h 选项来获取所有可用选项的列表。

汽车服务的代码位于名为**“packages/services/Car/service”的**位置。

车管家

汽车管理器就像Android 中与汽车相关的任务的主管。它由特殊的类组成，这些类为应用程序创建了一种处理与汽车相关的内容的方式。这些类位于**“android.car.*”**组中，它们构成了 Android Automotive 的工具。

您可以将汽车管理器视为一组特殊的指令，应用程序可以遵循这些指令来与汽车相关的事物进行交互。如果您想了解有关这些类的更多信息，可以查看链接**“** https://developer.android.com/reference/android/car/classes ”。

Car Manager是Android系统自带的一个库，位于**“/system/framework/android.car.jar”**的位置。该库帮助设备管理与汽车相关的任务和交互。

组成汽车管理器的代码位于**“packages/services/Car/car-lib”**位置。

汽车管理器界面：简要概述

汽车管理器包含一系列23 个不同的界面，每个界面都是为管理车辆数字基础设施的特定方面而定制的。这些接口充当不同服务和应用程序进行通信、协作和和谐共存的途径。从输入管理到诊断服务，汽车管理器界面涵盖了一系列功能，共同增强了驾驶体验。

img

车管家提供了这23个接口

属性_服务：

PROPERTY_SERVICE 接口在 Car Manager 生态系统中起着至关重要的作用。它充当访问和管理各种车辆属性的网关。这些属性包含广泛的信息，包括车速、燃油油位、发动机温度等。应用程序和服务可以利用该界面来收集实时数据，从而为用户提供有关车辆性能的宝贵见解。

权限和安全

PROPERTY_SERVICE 接口的一个重要方面是其强大的权限系统。对车辆财产的访问受到监管，确保应用程序遵守严格的安全措施。每个属性都与特定的权限相关联，应用程序必须授予这些权限才能访问它。

代码和实现

**PROPERTY_SERVICE (CarPropertyManager)的核心功能在“CarPropertyManager.java”文件中实现，该文件位于“packages/services/Car/car-lib/src/android/car/hardware/property/”**目录中。该文件封装了促进应用程序和车辆属性之间无缝通信所需的方法、数据结构和逻辑。

信息服务：

INFO_SERVICE 接口充当汽车管理器框架内的信息中心。它有助于交换与车辆状态、健康状况和性能相关的数据。该接口使应用程序能够访问诊断信息、维护计划以及车辆内检测到的任何潜在问题。

权限和安全

为了确保车辆信息的安全和隐私，CarInfoManager 实施了强大的权限系统。对静态车辆信息的访问由“PERMISSION_CAR_INFO”权限控制，该权限在“正常”级别授予。这种方法保证只有授权的应用程序才能访问有关车辆的关键数据。

代码和实现

CarInfoManager 的核心功能封装在**“CarInfoManager.java”文件中。该文件位于“packages/services/Car/car-lib/src/android/car/”**目录中，包含检索静态车辆信息并将其呈现给应用程序所需的方法、结构和逻辑。

CAR_UX_RESTRICTION_SERVICE：

随着安全和用户体验成为汽车行业的中心舞台，CAR_UX_RESTRICTION_SERVICE 接口成为关键参与者。该界面旨在管理和实施车辆行驶时的用户体验限制。它确保应用程序遵守安全准则，防止可能影响驾驶员对道路注意力的干扰。

实现和代码：CarUxRestrictionsManager.java

其核心功能**CarUxRestrictionsManager**在该文件中实现**CarUxRestrictionsManager.java**。该文件可以在以下目录中找到：**packages/services/Car/car-lib/src/android/car/drivingstate/**。在此文件中，您将找到促进 和其他相关组件之间通信的逻辑、方法和数据结构**CarDrivingStateManager**。

CarService的设计结构

CarService 在 Android 汽车数据框架中发挥着至关重要的作用，它提供了一种结构化且有组织的方法来访问一系列汽车特定的服务。在这里，我们的目的是剖析 CarService 的架构和设计，重点关注其实现和各个组件的交互。我们将使用 CarProperty 服务作为示例来说明设计模式，并认识到 CarImpl 中的其他 CarServices 采用了类似的方法。

img

car -lib****通过调用 ICar 提供的 getCarServices(“property”) AIDL 方法来使用对 CarProperty Android 服务的引用。这个非常通用且简单的方法由ICarImpl中的CarService实现，以返回通过getCarService方法请求的特定服务，以服务名称作为参数指定。因此，ICarImpl 遵循工厂模式实现，它返回所请求服务的 IBinder 对象。在 car-lib 中，Car.Java 将通过使用 ICarProperty.Stub.asInterface(binder) 调用特定的客户端接口来获取服务引用。通过返回的服务引用，CarPropertyManager将访问由****CarPropertyService实现的方法。因此，汽车服务框架级服务访问按照这种实现模式被抽象出来，应用程序将包含 car-lib 并利用 Car.Java 返回相应的 Manager 类对象。

以下是流程的简短摘要：

  • 您的应用程序 (* ***car-lib\***) 使用汽车服务框架来访问特定的车辆功能。*
  • ***getCarService\****您使用 提供的方法*请求特定服务（例如 CarProperty）****ICarImpl\***。*
  • ***ICarImpl\****返回一个表示所请求服务的 Binder 对象。*
  • 您可以使用 将此 Binder 对象转换为接口****.asInterface(binder)\***。*
  • *该接口允许您的应用程序以更抽象和用户友好的方式与服务（例如，CarPropertyService）进行交互。*

在CarServices下添加新服务或修改现有服务实现（例如扩展 CarMediaService 以添加新功能或更新 CarNavigationServices 以增强导航信息数据）时，了解类的模式及其关系非常重要。

汽车属性和权限

通过 Android 汽车数据框架访问汽车属性为开发人员提供了大量的车辆特定数据，从而增强了汽车应用程序的功能。然而，某些属性受权限保护，需要仔细考虑并征得用户同意。让我们深入了解汽车属性、权限以及 CarService 框架内访问的细微差别的概念。

了解汽车属性

汽车属性封装了车辆数据的各个方面，从汽车 VIN（车辆识别码）等基本信息到更复杂的详细信息。

字符串vin = propertyManager. getProperty < String >( INFO_VIN , VEHICLE_AREA_TYPE_GLOBAL )?. 价值

所有汽车属性均在VehiclePropertyIds文件中定义。可以使用CarPropertyManager读取它们**。但是，当尝试读取汽车 VIN 时，会引发 SecurityException。这意味着应用程序需要请求用户许可才能访问此数据**。

汽车权限

就像俱乐部的保镖一样，Android 权限控制哪些应用程序可以访问特定服务。这确保了只有正确的应用程序才能获得数字王国的钥匙。当涉及到汽车服务时，权限在确定哪些应用程序可以利用其功能方面发挥着至关重要的作用。

然而，汽车服务对于谁得到什么是非常有选择性的。以下是第三方应用程序可以请求并可能收到的一些权限：

  1. CAR_INFO： 将其视为您汽车的数字日记*。具有此权限的应用程序可以访问有关您车辆的一般信息，例如其品牌、型号和年份*。
  2. READ_CAR_DISPLAY_UNITS： 此权限允许应用收集有关汽车显示单元的数据，例如屏幕尺寸和分辨率。这就像让应用程序知道舞台有多大。
  3. **CONTROL_CAR_DISPLAY_UNITS：**有了此权限，应用程序实际上可以调整汽车的显示设置。这就像让他们调整舞台灯光来营造完美的氛围。
  4. **CAR_ENERGY_PORTS：**具有此权限的应用程序可以监控汽车中的能源端口，例如电动汽车的充电点。这就像为他们提供了通往汽车能源的后台通行证。
  5. CAR_EXTERIOR_ENVIRONMENT： 此权限允许应用访问有关汽车周围外部环境的数据，例如温度和天气状况。这就像给了他们一个传感器来感受外面的世界。
  6. CAR_POWERTRAIN、CAR_SPEED、CAR_ENERGY： 这些权限授予应用程序访问汽车动力系统、速度和能耗数据的权限。这就像让他们偷看引擎盖下面，看看你的汽车的性能如何。

现在，问题来了：有些权限是 VIP 独有的。它们被标记为**“签名”或“特权”，**并且只有由原始设备制造商 (OEM) 构建并随平台附带的应用程序才能获取它们。这些就像为少数人保留的金票——它们可以解锁高级功能并与汽车服务进行更深入的集成。

汽车应用程序

汽车应用程序是互联汽车生态系统不可或缺的一部分，使驾驶员和乘客能够访问各种功能和服务。这些应用程序满足驾驶体验的不同方面，从娱乐和通信到导航和车辆控制。让我们探讨一些值得注意的汽车应用程序示例：

  1. CarLauncher： 将其想象为您汽车的主屏幕。CarLauncher 应用程序以用户友好的界面迎接您，帮助您轻松访问其他应用程序和功能。
  2. **CarHvacApp：**当您需要调节车内温度时，CarHvacApp 就会介入。它就像一个数字恒温器，让您轻松控制供暖、通风和空调。
  3. **CarRadioApp：**CarRadioApp 是您的虚拟 DJ，可让您访问广播电台并帮助您收听您最喜爱的音乐和节目。
  4. CarDialerApp： 开车时需要打电话吗？CarDialerApp 是您的首选。它可以让您在视线不离开路面的情况下拨打电话。
  5. CarMapsPlaceholder： *虽然没有具体说明，但该应用程序暗示了导航和地图的潜力。它可以成为您的数字导航器，引导您穿越未知的领域。*
  6. LocalMediaPlayer： 如果您想听一些音乐，LocalMediaPlayer 应用程序可以满足您的需求。它是您的个人音乐播放器，让您在驾车期间欣赏您喜爱的曲目。
  7. CarMessengerApp： 使用 CarMessengerApp 保持联系，不受干扰。它处理消息和通知，确保您可以在保持安全的同时保持联系。
  8. **CarSettings：**就像手机上的设置一样，CarSettings 应用程序可让您个性化您的驾驶体验。调整偏好设置、建立连接等等，全部由驾驶座完成。
  9. EmbeddedKitchenSinkApp： 这个应用程序就像演示中的瑞士军刀！它展示了各种功能和可能性，让您体验您的汽车技术的功能*。*

*这些应用程序可以在“packages/apps/Car/ *”*和“packages/services/Car/* ”**目录中找到。它们旨在增强您的驾驶旅程，使其更安全、更愉快且个性化。无论您需要导航、通信、娱乐还是只是一点便利，汽车应用程序都能满足您的需求。

第三方汽车应用程序

当谈到汽车和汽车的第三方应用程序时，需要记住一些重要的事情。这些应用程序分为特定类别，每个类别都提供独特的功能，同时控制驾驶员的注意力。我们来看看支持的应用类别：

  1. **媒体（音频）应用程序：**这些应用程序将您的汽车变成移动娱乐中心。它们可让您在驾驶时欣赏您喜爱的音乐、播客和音频内容，让您在整个旅程中保持娱乐。
  2. 消息应用程序： 消息应用程序采用免提方式。它们使用文本转语音和语音输入来让您保持联系，而无需将手离开方向盘或眼睛离开路面。您可以在专注于驾驶的同时接收和发送消息。
  3. 导航、停车和充电应用程序（2021 年新增）： 这些应用程序是该系列的最新成员，是您的导航伴侣。它们可以帮助您找到路线、找到停车位，甚至引导您前往电动汽车充电站。

为了确保这些第三方应用符合最高的质量和安全标准，Google 为开发者提供了一套参考和指南：

  1. 汽车应用入门： *https://developer.android.com/training/cars/start*
  2. 汽车应用质量指南： *https://developer.android.com/docs/quality-guidelines/car-app-quality*
  3. 汽车应用导航指南： *https://developer.android.com/training/cars/navigation*

这些应用程序可在汽车和汽车 Play 商店等平台上使用，专为在旅途中提供安全、简化的体验而量身定制。以下是您应该了解的内容：

  1. 对系统 API 的访问有限： 第三方应用程序无法自由控制汽车的系统 API。他们在受控范围内运行，以确保您的驾驶体验保持安全和专注。
  2. 更严格的安全限制： 重点是安全。第三方应用程序受到严格限制，以最大程度地减少对驾驶员的潜在干扰。这可确保您的注意力集中在最重要的地方：路上。
  3. Google 的驾驶员分心指南： Google 非常重视驾驶员分心问题。应用程序必须符合特定的设计要求，才能在 Android Automotive OS 和 Android Auto 的 Google Play 上列出。这些指南的制定是为了确保应用程序有助于营造安全的驾驶环境。

值得注意的是，虽然汽车和汽车的第三方应用程序可能有一定的局限性，但它们在增强您的驾驶体验方面仍然发挥着宝贵的作用。它们提供便利、娱乐和有用的功能，同时保持对安全的坚定承诺。

因此，下次您为您的汽车探索第三方应用程序时，请记住它们的设计考虑了您的健康。

Android 汽车开发

Android 开发领域已将其影响力扩展到智能手机和平板电脑之外，张开双臂拥抱汽车领域。开发人员现在有机会创建可增强驾驶体验的应用程序，使车辆更智能、更安全、更互联。在此背景下，让我们深入探讨推动这一令人兴奋的努力的工具、要求和注意事项。

Android Automotive 开发的主要亮点包括：

  1. SDK 可用性： Android Studio 提供适用于 Android 版本***R/11、S/12 和 T/13 的***汽车 SDK 。这些 SDK 将其功能扩展到汽车领域，为开发人员提供创建引人入胜且功能齐全的汽车应用程序所需的工具和资源。
  2. **最低 Android Studio 版本：要开发汽车应用，开发人员需要 Android Studio 版本*4.2 或更高***版本。该版本包含汽车开发所需的工具和资源，例如Automotive Gradle插件和Automotive SDK。
  3. 过渡到稳定版： Android Studio ***4.2***版本于 2021 年 5 月过渡到稳定版。这意味着它是汽车开发的推荐版本。不过，开发人员还可以使用 Android Studio 的最新预览版，其中包括更多用于汽车开发的功能和改进。

适用于 Android 汽车服务开发的汽车 AVD

Automotive AVD（Android 虚拟设备）为开发人员提供了一个****模拟Android Automotive 系统的平台，有助于在部署到物理车辆之前完善应用程序和服务。让我们探讨一下汽车 AVD 的关键组件和方面。

SDK和系统镜像

Automotive AVD 在**Android 10.0 (Q)（最新 T/13）软件开发套件 (SDK) 内运行。该 SDK 版本专为满足 Android Automotive 汽车服务的需求而定制。AVD 利用“Automotive with Google Play Intel x86 Atom”**系统映像，在基于 Intel x86 的硬件上复制 Android Automotive 环境的架构和功能。

AVD配置

AVD 配置围绕**“汽车（1024p 横向）API 29”和最新的“汽车（1024p 横向）API 32”设置**构建。此配置模仿横向 1024p（像素）显示器，这是车辆中常见的信息娱乐系统的代表。这种分辨率和方向的选择可确保开发人员能够准确评估他们的应用程序在汽车显示屏环境中的显示方式和功能。

外视系统（EVS）

在快节奏的汽车技术世界中，每一秒都很重要，尤其是在确保驾驶员和行人的安全方面。现代车辆的一个重要组成部分是后视摄像头，它可以让驾驶员清楚地看到后方的情况。然而，当摄像头系统需要在点火后短短几秒钟内启动并运行时，就会出现挑战，而控制车辆许多功能的 Android 操作系统的启动时间要长得多。在这里，我们将探索解决此问题的突破性解决方案 - 外部视图系统 (EVS)，这是一个独立的应用程序，旨在最大限度地减少点火和摄像头激活之间的延迟。

问题

在车辆中，车辆后部有一个摄像头，可为驾驶员提供后方的视野。该摄像头对于停车、倒车和整体安全非常有用。然而，有一个要求是，这个后视摄像头应该能够在车辆点火（发动机启动）打开后2秒内在显示屏上显示图像。

挑战

挑战在于，许多车辆使用 Android 操作系统来为其信息娱乐系统提供支持，包括显示后视摄像头图像的显示屏。Android 与任何计算机系统一样，需要一些时间来启动。在这种情况下，在点火开关打开后，Android 需要数十秒（即大约 10 秒或更多秒）才能完全启动并开始运行。

解决方案

外视系统（EVS）：为了解决Android启动时间慢的问题，并保证后视摄像头能够在规定的2秒内显示图像，提出了外视系统（EVS）的解决方案。

那么，什么是外视系统（EVS）

外视系统 (EVS) 是解决摄像头激活延迟问题的开创性解决方案。与严重依赖Android操作系统的传统相机系统不同，EVS是一个用C++开发的独立应用程序。这种方法大大减少了系统对 Android 的依赖，使 EVS 在启动后仅需两秒即可开始运行。

Android Automotive 中的外部视图系统 (EVS) 是一个硬件抽象层 (HAL)，为车辆中的后视和环视摄像头提供支持。EVS 使 OEM 能够开发和部署高级驾驶员辅助系统 (ADAS) 以及依赖多个摄像头视图的其他安全功能。

EVS HAL 由许多组件组成，包括：

  • 提供对车辆摄像头的访问的摄像头管理器
  • 控制相机流输出的显示管理器
  • 帧缓冲区管理器，管理用于存储相机帧的内存
  • 传感器融合模块 ，结合多个摄像头的数据，创建车辆周围环境的单一、统一视图。

建筑学

外景系统的架构旨在最大限度地提高效率和速度，同时保持无缝的用户体验。EVS 架构中存在以下系统组件：

img

EVS 系统组件概述

电动车应用

您可以在**/packages/services/Car/evs/app**找到一个用 C++ 编写的 EVS 应用程序示例。此示例向您展示如何使用 EVS。该应用程序的工作是向 EVS 管理器请求视频帧，然后将这些帧发送到 EVS 管理器，以便它们可以显示在屏幕上。它设计为在 EVS 和汽车服务准备就绪后立即启动，通常在汽车启动后两秒内启动。如果汽车制造商愿意，他们可以更改或使用不同的 EVS 应用程序。

电动车管理器

EVS 管理器位于**/packages/services/Car/evs/manager**，就像 EVS 应用程序的工具箱。它帮助这些应用程序创建不同的东西，例如显示基本的后视摄像头视图甚至复杂的 6DOF（六自由度 (6DOF)是指刚体能够在三维空间中自由移动的特定轴数。 )多摄像头 3D 视图。它通过 HIDL（Android 中的一种特殊通信方式）与应用程序进行通信。它可以同时与许多应用程序一起工作。

其他程序（例如汽车服务）也可以与 EVS 管理器通信。他们可以询问 EVS 经理EVS 系统是否已启动并正在运行。这有助于他们了解 EVS 系统何时工作。

EVS HIDL 接口

EVS HIDL 接口是 EVS 系统的摄像头和显示部件相互通信的方式。您可以在android.hardware.automotive.evs包中找到此接口。/hardware/interfaces/automotive/evs/1.0/default中有一个示例版本，您可以用它来测试。此示例制作假图像并检查它们是否正常工作。

汽车制造商（OEM）需要为此接口编写实际代码。该代码基于**/hardware/interfaces/automotive/evs中的.hal 文件**。此代码设置真实相机，获取其数据，并将其放入 Gralloc（Gralloc 是一种也与 GPU 共享的共享内存*****）****可以理解的特殊内存区域中。代码的显示部分必须创建一个内存区域，应用程序可以在其中放置其图像（通常使用称为EGL的东西），然后将这些图像显示在汽车屏幕上。此显示部分很重要，因为它确保应用程序的图像而不是屏幕上的其他任何内容显示。汽车制造商可以将自己版本的 EVS 代码放在不同的位置，例如*/vendor/… /device/…或hardware/…（例如/hardware/[vendor]/[platform]/evs**）。

内核驱动程序

为了使设备能够与 EVS 系统配合使用，它需要称为内核驱动程序的特殊软件。如果设备已经具有相机和显示器的驱动程序，那么这些驱动程序通常也可用于 EVS。这可能很有帮助，特别是对于显示驱动程序，因为显示图像可能需要与设备中发生的其他事情一起工作。

在Android 8.0中，有一个基于v4l2的示例驱动程序（您可以在packages/services/Car/evs/sampleDriver中找到它）。该驱动程序使用内核来支持v4l2（一种处理视频的方法），并使用称为SurfaceFlinger 的东西来显示图像。

需要注意的是，示例驱动程序使用 SurfaceFlinger，这并不适合真实设备，因为 EVS 需要快速启动，甚至在 SurfaceFlinger 完全准备好之前也是如此。但是，示例驱动程序设计用于与不同的硬件配合使用，并允许开发人员在开发 EVS 驱动程序的同时测试和使用 EVS 应用程序。

典型控制流程

Android 中的 EVS 应用程序是一个 C++ 程序，它与 EVS Manager 和车辆 HAL 交互以提供基本的后视摄像头功能。它应该在系统启动过程的早期启动，并可以根据可用摄像头和汽车状态（档位、转向灯）显示适当的视频。制造商可以用自己的逻辑和视觉效果定制或替换该应用程序。

img

EVS应用程序示例逻辑，获取摄像机列表。

由于图像数据是在标准图形缓冲区中提供的，因此应用程序需要将图像从源缓冲区移动到输出缓冲区。这涉及数据复制，但它也使应用程序可以灵活地在显示图像之前对其进行操作。

img

EVS 应用程序示例逻辑，接收帧回调。

例如，应用程序可以在添加缩放或旋转的同时****移动像素数据。或者，它可以使用源图像作为 OpenGL 纹理，并将复杂的场景渲染到输出缓冲区上，包括图标、指南和动画等虚拟元素。更高级的应用程序甚至可能将多个摄像头输入组合到单个输出帧中，以实现车辆周围环境的自上而下的视图。

总体而言，EVS 应用程序提供了硬件和用户演示之间的必要连接，使制造商能够根据其特定的车辆设计和功能创建定制且复杂的视觉体验。

显示共享 — EVS 优先级和机制

车辆外部摄像头的集成改变了驾驶员驾驭周围环境的方式。从平行停车到狭窄空间导航，这些摄像头提供了宝贵的帮助。然而，当确定如何在通常具有多种功能的主显示屏和 EVS 提供的外部视图之间无缝切换时，就会出现挑战。解决方案在于优先考虑 EVS 来实现显示共享。

EVS 优先于主显示器

EVS 应用程序的设计优先于主显示器。这意味着当满足某些条件时，EVS可以控制主显示器来显示其内容。主显示屏是通常用于各种功能的屏幕，例如娱乐、导航和其他信息娱乐功能。

抓住显示器

每当需要显示来自外部摄像头（例如后视摄像头）的图像时，EVS 应用程序就可以“抓取”或控制主显示屏。这使得摄像头图像能够显着地向驾驶员显示，提供有关车辆周围环境的重要视觉信息。

示例场景 — 倒档

使用该显示共享机制的一种特定场景是选择车辆的倒档时。当驾驶员将变速箱换至倒车档时，EVS 应用程序可以立即控制主显示屏，以显示后视摄像头的实时反馈。这对于协助驾驶员在倒车时安全操纵车辆至关重要。

没有同时显示内容

重要的是，没有适当的机制允许 EVS 应用程序和 Android 操作系统在主显示屏上同时显示内容。换句话说，在任何给定时间，只有其中一个可以处于活动状态并显示内容。

简而言之，在这种情况下，显示器共享的概念涉及外部视图系统（EVS），其优先级高于车辆中的主显示器。每当需要显示来自外部摄像头（例如后视摄像头）的图像时，EVS 都可以控制主显示屏。该机制可确保驾驶员及时接收到相关视觉信息，以实现安全驾驶。此外，需要注意的是，一次只有一个应用程序（EVS 或 Android）可以在主屏幕上显示内容；它们不同时运行。

汽车音响

在当今世界，汽车已经超越了其运输的基本作用。它们现在已成为我们生活的重要组成部分，提供舒适性、连通性和超越道路的体验。车内音频系统在增强这种体验方面发挥着重要作用。汽车音响领域错综复杂且引人入胜，其特点是其独特的挑战和创新。在本文中，我们将深入研究汽车音频系统及其与众不同的卓越功能。

车辆音频有何特别之处？

汽车音频是 Android 汽车操作系统的一项功能，允许车辆播放信息娱乐声音，例如媒体、导航和通信。AAOS 不负责具有严格可用性和时间要求的提示音和警告，因为这些声音通常由车辆硬件处理。

以下是车辆音频的一些特殊之处：

许多具有特殊行为的音频通道

*在车辆中，可以有许多不同的音频通道，每个通道都有其独特的用途。例如，*可以是音乐频道、导航指令频道、电话通话频道、以及警告声音频道*。每个渠道都需要以特定的方式运作才能有效。例如，音乐频道不应被导航指令打断，并且警告声音应在所有其他频道上听到*。

关键提示音和警告声

在车辆中，即使在吵闹的音乐或其他噪音中，也能够清晰地听到紧急提示音和警告声*非常重要。这就是为什么这些声音通常通过一组单独的扬声器播放，或者通过扬声器以较高的音量播放*。

音频通道之间的交互

车辆中的音频通道可以通过多种方式相互交互。例如，当说出导航指令时，音乐频道可以被静音，或者警告声音可以覆盖所有其他频道*。这些交互需要仔细设计，以确保音频系统安全有效。*

很多扬声器

为了**在车辆中***提供良好的音质，通常安装有许多扬声器。***这是因为声波需要能够到达车辆的所有部分，即使驾驶员和乘客没有直接坐在扬声器前面。

除了这些特殊功能外，车辆音频还面临着许多挑战，例如：

噪音

车辆中**通常会产生很多***噪音，这些噪音***来自发动机、道路和风*。*这种噪音会使您很难听到音频系统的声音，尤其是关键提示音和警告声。

振动

车辆可能会振动，这也会导致很难听到音频系统的声音。

温度

车内的温度变化很大*，从非常热到非常冷。这也会影响音频系统的性能。*

尽管存在这些挑战，车辆中的音频仍然是一项重要的安全功能，也是驾驶时享受音乐和娱乐的好方法。

汽车声音和流媒体

汽车声音和流媒体世界证明了技术、设计和人类体验的交叉。车内的声音交响乐，加上流媒体服务的无缝集成，创造了一个全面的旅程，吸引我们的感官，并将驾驶行为转变为一次难忘的冒险

在使用 Android 的汽车音响系统中，管理不同的声音和流：

img

以流为中心的架构图

逻辑流

*逻辑流是由 Android 应用程序生成的音频数据流。****这些流用AudioAttributes*标记，提供诸如它们来自何处的详细信息，以及有关音频类型的信息，例如其重要性、延迟要求和所需的输出设备。

物理流

物理流是车辆音频硬件输出的音频数据流。这些是**从扬声器中发出的**实际声音。*这些流没有使用AudioAttributes***标记，因为它们不受 Android 控制。它们是通过将逻辑流混合在一起而制成的。有些声音（例如重要警告）是与 Android 分开管理的。

逻辑流和物理流之间的主要区别在于逻辑流由Android控制，而物理流则不受控制。这意味着Android可以控制逻辑流的音量、路由和焦点，但无法控制物理流的音量、路由或焦点。

Android 应用程序声音

*应用程序会发出声音，例如音乐或导航。这些声音被发送到混音器，然后发送到扬声器。****混音器将不同的声音组合在一起，并将它们合而为一***。

外部声音

外部声音是由 Android 应用程序以外的来源生成的声音，例如安全带警告铃声*。这些声音在 Android 外部进行管理，并且不受与 Android 声音相同的音频策略的约束。*有些声音不应该通过 Android，因此它们会直接进入混音器*。****当这些重要的声音播放时，混音器可以要求 Android 暂停其他声音***。

外部声音通常在 Android 外部进行管理，因为它们具有严格的时序要求或者因为它们对安全至关重要。例如，当未扣安全带时，必须立即播放安全带警告铃声，并且必须在播放的任何其他声音中听到该铃声。这就是为什么外部声音通常由车辆硬件处理，而不是由 Android 软件处理。

上下文

上下文用于识别音频数据的用途*。系统使用此信息来确定如何呈现音频，例如音量级别、优先级以及是否应该被其他声音打断*。

巴士

总线是路由到同一输出设备的物理流的逻辑组*。这允许系统在将多个音频流发送到扬声器****之前将它们混合在一起*。

音频投掷器

*AudioFlinger是管理音频输出的系统服务。它使用上下文将逻辑流混合为称为总线的物理流。这允许多个逻辑流混合在一起，即使它们具有不同的格式或具有不同的优先级*。

该方法从上下文映射到总线*。****应用程序使用此方法来获取与特定上下文关联的总线。****该信息可用于将音频输出路由到所需的扬声器*。***IAudioControl::getBusForContext\***

*例如，导航上下文可以路由到驾驶员侧扬声器。这将确保即使在播放音乐时也始终可以听到导航指令。*

物理流、上下文和总线是 Android 音频系统的重要组成部分。它们使系统能够智能地管理音频输出，并确保最重要的声音始终清晰可见。

音频上下文

音频上下文是一组音频用法，用于简化 Android Automotive OS 中的音频配置。我们首先讨论音频的使用

音频使用

在 Android Automotive OS (AAOS) 中，AudioAttributes.AttributeUsages 就像声音的标签。 它们帮助控制声音的去向、声音的大小以及谁可以控制声音。每个声音或焦点请求都需要定义特定的用途。如果未设置用途，则将其视为一般媒体声音。

Android 11引入了系统用法，这是需要特定权限才能使用的特殊标签。这些都是：

  1. USAGE_EMERGENCY
  2. 使用安全
  3. USAGE_VEHICLE_STATUS
  4. USAGE_ANNOUNCMENT

要设置系统使用情况，请使用 AudioAttributes.Builder#setSystemUsage。如果您尝试将常规使用与系统使用混合在一起，则不会起作用。

package com.softaai.automotive.audio

import android.media.AudioAttributes;


public class AudioAttributesExample {

    public static void main(String[] args) {
        // 使用系统使用
        AudioAttributes.Builder attributesBuilder = new AudioAttributes.Builder()
                .setSystemUsage(AudioAttributes.USAGE_ALARM); // Set a system usage (alarm)

        // 也可以设置一般用途，但不能同时设置系统用途和一般用途
        // attributesBuilder.setUsage(AudioAttributes.USAGE_MEDIA); // 取消注释此行会导致错误

        // 构建 AudioAttributes 实例
        AudioAttributes audioAttributes = attributesBuilder.build();

        // 检查关联的系统使用情况或使用情况
        int systemUsage = audioAttributes.getSystemUsage();
        System.out.println("Associated System Usage: " + systemUsage);

    }
}

在这个例子中：

  1. 我们用来***AudioAttributes.Builder\***创建音频属性的实例。
  2. 我们用来***setSystemUsage\***指定音频的系统上下文，在本例中为警报用途。
  3. *尝试同时设置系统用法和一般用法****setUsage\******会导致错误，****因此该行被注释掉*。
  4. 然后我们***AudioAttributes\***使用 构建实例***attributesBuilder.build()\***。
  5. 最后，我们用来***audioAttributes.getSystemUsage()\***检索相关的系统使用情况并打印它。

音频上下文

Android 中使用音频上下文来识别声音的用途。系统使用该信息来确定如何呈现声音，例如音量级别、优先级以及是否应该被其他声音打断。

以下是 Android 中当前定义的音频上下文：

  1. **音乐：**用于在车内播放音乐，例如您最喜欢的歌曲。
  2. 导航： 这些是车辆导航系统为您提供的指示，可帮助您找到方向。
  3. VOICE_COMMAND： 当您与车辆交谈时，例如告诉它更改设置或为您做某事。
  4. CALL_RING： 当有人打电话给您时，这是您听到的铃声。
  5. 通话： 适用于您在车内与某人通过电话交谈时。
  6. 警报： 如果有事情需要您立即注意，可能会发出响亮的声音。
  7. 通知： 这些是来自车辆系统的小消息或提醒。
  8. SYSTEM_SOUND： 按下按钮或与车辆控件交互时听到的声音。

下表总结了Android Automotive OS 中音频上下文和用法之间的映射：

img

Android 11 中的音频上下文

声音的音频上下文可以由播放声音的应用程序指定。这是通过设置用于创建声音的对象**context**的属性来完成的。**AudioAttributes**

系统使用音频上下文来确定如何呈现声音。例如，对于上下文来说，声音的音量级别可以比***MUSIC\***对于上下文来说更高***NOTIFICATION\***。系统还可以选择用较高优先级的声音来中断较低优先级的声音。

音频上下文是 Android 音频系统的重要组成部分。它们使系统能够智能地管理音频输出，并确保最重要的声音始终清晰可见。

鸣响和警告

车辆内的鸣响和警告充当听觉提示，向驾驶员和乘员传达重要信息。从安全带提醒到碰撞警告，这些声音旨在迅速引起人们对需要立即采取行动的情况的注意。这些听觉提示增强了态势感知并有助于提高驾驶体验的整体安全性。

Android 在汽车音响中的作用

虽然 Android 已成为各种设备普遍使用的操作系统，但它在汽车安全方面提出了某些考虑因素。Android 在其标准形式下并未被归类为安全关键型操作系统。与车辆中专用的安全关键系统不同，Android 的主要重点是提供多功能且用户友好的平台。

早期音频路径的缺失

在铃声和警告的背景下，Android 缺乏对于产生监管和安全相关声音至关重要的早期音频路径。早期的音频路径将涉及直接访问音频硬件，以确保这些关键声音能够及时且不间断地播放。Android 作为一个多功能操作系统，可能不具备这种即时音频播放所需的机制。

Android 之外的监管声音

鉴于监管铃声和警告的重要性，生成和传递这些声音不属于 Android 操作系统的范围。为了确保这些声音可靠且及时，它们通常独立于 Android 生成和混合，然后集成到车辆的整体音频输出链中。这种方法可以保证监管声音保持完整性，即使在 Android 由于主要关注多功能性而可能面临限制的情况下也是如此。

安全关键考虑因素

Android 中早期音频路径的缺乏凸显了与汽车音频的安全关键性相关的更广泛的担忧。随着车辆不断集成先进技术，包括信息娱乐系统和连接功能，挑战在于找到创新与安全之间的平衡。监管机构和汽车制造商合作，确保对安全关键元件（例如提示音和警告）给予最大程度的关注和可靠性。

未来之路：安全与技术整合

将包括 Android 等操作系统在内的技术集成到车辆中，证明了汽车领域的动态演变。随着行业不断创新，解决安全问题仍然至关重要。未来有望弥合安全关键需求和技术能力之间的差距。这可能涉及 Android 和车辆安全系统之间的进一步同步，确保无缝且不受影响地传递关键警报和警告。

简而言之，汽车音响中的提示音和警告领域强调了安全与技术之间的微妙平衡。虽然 Android 对现代驾驶体验做出了重大贡献，但仍有一些特定的安全关键方面（例如监管声音）需要特别关注。监管机构、汽车制造商和技术提供商的共同努力将继续为所有人塑造更安全、更身临其境的驾驶旅程。

结论

Android Automotive 代表了针对汽车的 Android 操作系统的定制版本。这种演变带来了车辆硬件抽象层 (VHAL)、汽车服务和汽车管理器等关键组件的实现。这些新增功能有助于为驾驶员和乘客提供更加集成和无缝的体验。

此外，Android Automotive 通过容纳外部摄像头扩展了其功能，提供增强的可视性和安全功能。这种包容性符合当代对全面车辆意识的重视。

在音频领域，Android Automotive 带来了显着的进步。音频区域或总线的概念提供了一种细致入微的音频管理方法，允许将各种音频源定向到车辆内的特定区域。此外，基于上下文的路由通过调整音频输出以适应周围的环境和条件，增强了整体听觉体验。

随着汽车领域的不断发展，Android Automotive 作为一个平台应运而生，它不仅改变了车内体验，还为技术和移动性的融合开创了先例。这些功能的推出凸显了 Android 致力于重新定义驾驶的未来，专注于舒适性、安全性和创新。