车载应用

车载操作系统

汽车操作系统是从传统汽车电子不断演变而来的，传统汽车电子产品可分为两类：

一类是汽车电子控制装置，通过直接向执行机构（如电子阀门、继电器开关、执行马达）发送指令，以控制车辆关键部件（如发动机、变速箱、动力电池）协同工作，这类系统一般统称为电子控制单元（ECU）；

另一类是车载电子设备，如仪表、娱乐音响、导航系统、HUD等，这类系统不直接参与汽车行驶的控制决策，不会对车辆行驶性能和安全产生影响，通常统称为车载信息娱乐系统（IVI）。这也是Android程序员主要负责的领域。

MCU

微控制器单元，它负责着汽车很大一部分的功能，例如通过车载控制器对各项数据进行分析处理，以做出最优决策；负责对车辆的信息娱乐交互和运动控制等等。

总的来说，MCU可以应用于车辆的通讯、能源、存储、感知以及计算，对汽车行业有着重要的作用

SOC

SoC的定义多种多样，由于其内涵丰富、应用范围广，很难给出准确定义。一般说来， SoC称为系统级芯片，也有称片上系统（System on Chip），意指它是一个产品，是一个有专用目标的集成电路，其中包含完整系统并有嵌入软件的全部内容。

车载Soc和常见的手机Soc非常类似，内部集成了CPU和GPU。目前最主流的车载Soc是高通的8155，它就是高通在手机Soc骁龙855的基础上发展而来的。

车载 Android 系统

车载Android系统，又称Android Automotive，是对原始Android系统的一个功能扩充版本，在编译AOSP源码时可以看到相应的编译选项。Android Automotive 是一个基于 Android 平台扩展后，适用于现代汽车的智能操作系统，可以直接运行为Android系统开发的应用

image.png|600
Android Automotive与Android最大的区别在于，Android Automotive增加了对汽车特定要求、功能和技术的支持。

Google的官方文档：source.android.google.cn/docs/device…

Android Auto 是一个基于用户手机运行的平台，可通过 USB 连接将 Android Auto 用户体验投射到兼容的车载信息娱乐系统。Android Auto本质上就是一个运行在Android系统上的车载应用，与苹果的CarPlay，百度的CarLife类似。

需要说明的是，使用Android Auto需要用户的手机支持Google服务框架，所以一般只在国内销售的汽车基本都不支持Android Auto，一些沿用了国外车机系统的合资车型可能会支持Android Auto。

常见的车载应用

SystemUI

系统的UI。SystemUI是一个标准的android应用程序，它提供了系统UI的统一管理方案。常见的状态栏、导航栏、消息中心、音量调节弹窗、蓝牙连接弹窗等一系列后台弹窗都是由SystemUI模块负责管理。

开发难度：SystemUI作为Android系统启动的第一个带有UI的应用程序，对启动性能和稳定性都有很高的要求。SystemUI需要管理的模块非常多，导致开发任务比较繁重，有的车载项目会要求SystemUI兼容原有的应用层API，那么开发难度还会上升。开发人员需要对Android原生的SystemUI源码有一定的了解。

Launcher

Android系统的桌面。

开发难度：Launcher是与用户交互最多的应用程序之一，同样对启动性能和稳定性都有很高的要求。Launcher开发难度主要集中在与3D车模的互动（如果有3D模型），可能需要支持Widget的显示（WidgetHost），各种应用的拖动和编辑等。开发人员最好对Android原生的Launcher源码有一定的了解。

CarService

车载Android系统的核心服务之一，所有应用都需要通过CarService来查询、控制整车的状态。例如：车辆的速度、档位、点火状态等等。

车载应用与移动应用的区别

夸张一点说，移动端的应用开发和车载应用开发，完全就不是一个技术思路。总结一下大致有以下几个区别：

1）应用级别不同

多数车载应用属于系统级应用，可以调用Android SDK内部隐藏的API，也不需要动态地向用户申请权限。移动应用是普通应用，系统对其限制很多，需要遵守Android应用的开发规范。

由于车载应用是系统级应用，所以移动端很多常用的技术比如热修复、插件化基本都不会采用，但是相对的进程保活、开机自启就变得非常简单了。

总得来说系统应用具有以下特点

可以访问Android SDK内部的API
不需要申请动态权限
可配置开机自启动
必须对应用进行签名

2）迭代方式不同

移动应用只要用户的手机接入了WiFi就可以进行在线升级，所以移动应用多采用小步快跑的形式，进行快速迭代。

车载系统级应用的更新只能以整车OTA的形式进行，而OTA可能会消耗宝贵的车机流量，所以车载应用在SOP（量产）前，就必须完成全部需求的开发，而且不能出现严重的bug。在正式交付用户前，车厂内部或4S店还会进行几次OTA升级用做最后的bug修复。（如果在交付用户后还有严重的bug或需求未完成，那么大概率项目经理、程序员都要祭天了)

3）技术路线不同

正是因为车载应用对稳定性的要求极高，所以车载应用在开发时，对待新型技术会非常的慎重，比如，目前只有少数主机厂商在使用Kotlin开发车载应用，毕竟Android Framework都还没有改成Kotlin，大部分厂商对Kotlin的积极性不高。而且车载应用也不允许随意使用开源框架，如果必须使用，务必注意框架的开源协议，以免给汽车厂商带来不必要的麻烦。

4）运行环境不同

车载应用的运行环境是经过高度定制化的Android系统，定制化也就意味着bug。移动端的应用出现bug时，我们的第一反应是应用的代码有缺陷。车载应用发现bug也要考虑到是不是系统本身出现了bug，这是一件非常有挑战性的事，应用开发与系统开发相互扯皮、泼脏水也属于家常便饭。

车载应用需要掌握的技能

性能优化

应用的性能优化是个亘古不变的话题，掌握应用的各种性能优化方式，也是一个Android程序员必备的生存手段，汽车座舱的SOC性能比旗舰手机要差不少，如果优化好车载应用将是一个非常有挑战性的任务。

IPC通信

Android中最常用的跨进程通信手段是Binder，因为有大量的Service需要与应用进行交互，所以基于Binder的AIDL在车载应用开发中使用得非常广泛，学会使用AIDL也同样属于必备技能之一。

系统应用源码

这一项是我认为最重要的，不少车载应用层项目都是反复定制各种SystemUI、Launcher、Settings等等，读懂Android系统应用源码对我们定制化开发这些应用有非常大的好处。

编写一个系统级应用

Android车载应用开发与分析（11）- 车载Android应用开发入门指南 - 掘金

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.car"
    android:sharedUserId="android.uid.system">

    <uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" />
    <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />

    <application
        android:allowBackup="true"
        android:icon="@mipmap/ic_launcher"
        android:label="@string/app_name"
        android:persistent="true"
        android:roundIcon="@mipmap/ic_launcher_round"
        android:supportsRtl="true"
        android:theme="@style/Theme.First">

        <activity
            android:name=".MainActivity"
            android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>

</manifest>

在上面源码中我们需要关注两个普通应用用不到的属性： android:sharedUserId 将与其他应用程序共享的 Linux 用户 ID 的名称。默认情况下，Android 会为每个应用分配自己唯一的用户 ID。但是，如果为两个或多个应用将此属性设置为相同的值，则它们将共享相同的 ID，前提是它们的证书集相同。具有相同用户 ID 的应用可以访问彼此的数据，如果需要，可以在同一进程中运行。开发系统应用时，此项不是必须配置的。配置为android.uid.system后，该应用会变成system用户，可以访问一些system用户才能访问的空间。

android:persistent 配置应用程序是否应始终保持运行，默认为false。设为true之后，应用在开机广播发出之前就会自行启动，而且应用被杀死后，也会立即重启。开发系统应用时，此项不是必须配置的。

基于Android源码环境的app工程结构与基于Gradle的AndroidStudio工程结构是完全不一样的，目录结构如下：

image.png|600

编写一个Android.bp或Android.mk脚本，然后完整编译一次Android的源码

# 编译Android源码
/aosp$ source build/envsetup.sh 
/aosp$ lunch 12
/aosp$ make -j 32
/aosp$ emulator -writable-system -netdelay none -netspeed full

目录
/system/priv-app 该路径存放一些系统底层的应用，比如Setting，systemUI等。该目录中的app拥有较高的系统权限，而且如果要使用android:protectionLevel=signatureOrSystem，那么该app必须放到priv-app目录中去。

/system/app 该目录中存放的系统app权限相对较低，而且当拥有root权限时，就有可能卸载掉这些app。

/vendor/app 该目录存放vendor厂商的app

/data/app 用户安装的第三方app

调试耗时且费力车载应用开发难度其实并不大，但是很烦！特别是调试，不同于开发手机应用，车载应用的运行环境是基于AOSP定制的，而且大多数时候都会存在数不清的BUG，有时系统底层的bug会在上层应用中体现，这就要求应用开发者必须有能力准确识别出这个bug的归属方。

引用：
Android车载应用开发与分析（1） - Android Automotive概述与编译 - 简书

AOSP

车载应用

http://peiniwan.github.io/2024/04/3b7de3a8c3a8.html

作者

六月的雨

发布于

2024年4月6日

许可协议

1-Android的启动流程上一篇

vim 学习下一篇