android 车载app怎么开发(车载安卓系统设置)

01.前言——移动互联网退潮下的汽车大战要回到2017年，我刚刚大学毕业。当时移动互联网已经开始退潮，各大培训机构也停止了Android相关的培训。从此，曾经炙手可热的应用开发开始走下坡路。小程序和众多的跨平台框架也使得Android原生开发的市场需求逐年减少，市场需求的减少也创造了Android开发前所未有的面试“量”。最终在2019年，我选择离开互联网，投身到当时还不是很火的车载安卓领域，继续从事原生安卓开发。这一年，中国首个外商独资整车制造项目“上海特斯拉超级工厂”开工。特斯拉在智能化、电子化方面的巨大优势，将智能汽车推向了一个新的高度。先进的自动驾驶和BMS电池管理系统深深震撼了全世界的人们。那时候，特斯拉在国人眼里几乎是新能源汽车的代名词。时至今日，Model Y和Model 3依然是新能源汽车领域最畅销的车型。众所周知，汽车产业是发达国家的重要经济支柱，而中国是世界上最大的汽车产销国。特斯拉的热销立刻引发了鲶鱼效应，国内外汽车厂商开始布局智能汽车，汽车行业走向软件定义汽车时代。软件定义汽车的核心思想是，未来的汽车将由以人工智能为核心的软件技术决定。车载软件在汽车领域的重要性第一次被提升到了前所未有的高度，上演了如此轰轰烈烈的车载软件技术大战。
02.智能汽车驾驶舱的基本结构在从事车载Android应用的开发之前，我们必须对汽车驾驶舱的基本结构有一个大致的了解。只有认识到汽车驾驶舱是和手机完全不同的结构，才能更好的帮助我们以后学习车载Android应用的开发。下面介绍一种主流的车载操作系统架构。
注意：并非所有车载操作系统都采用以下架构。比如特斯拉就采用了基于Linux的架构。
以上是目前主流汽车驾驶舱采用的技术架构。我们将从上到下进行介绍：
T-box又称TCU(Vehicle Networking Control Unit)，是指安装在车辆上的嵌入式系统，用于控制和跟踪车辆。它是车载信息交互系统的核心部件，车辆可以通过它实现联网功能，因此它也是中央网关。一般包括GPS单元、移动通信外部接口电子处理单元、微控制器、移动通信单元和存储器。对于车辆，T-Box可以提供车辆故障监控、电源管理、远程升级、数据采集、智能交通等功能。对于车主来说，T-Box可以提供车辆远程控制、安全服务等功能。T-BOX属于外设硬件，不与中控和仪表集成在一个主板上。
SOC的定义多种多样，内涵丰富，应用范围广，很难给出一个准确的定义。一般来说，SoC被称为片上系统，或System on Chip，意思是它是一个产品，一个具有特殊用途的集成电路，包含了一个完整的系统和嵌入式软件的所有内容。车载Soc和我们最常见的手机Soc很像，集成了CPU和GPU。目前最主流的车载Soc是高通的SA8155，它是由高通手机Soc的骁龙855发展而来的。
MCU微控制器单元(微控制器单元；MCU)，也叫单片机或单片机，是中央处理单元(Central Process Unit；CPU)频率和规格适当降低，将存储器、定时器、USB、A/D转换、UART、PLC、DMA，甚至LCD驱动电路等外围接口集成在一块芯片上，形成芯片级计算机。
一般来说，在集成了汽车驾驶舱SOC的主板上会额外集成一个或多个MCU。
AutoSARAdaptive AutoSAR是一个适用于高级自动驾驶仪的软件架构平台。它提供高性能计算和通信、灵活的软件配置，并支持应用程序更新。autosar的主要架构分为硬件层、ARA(AutoSAR Run-time for Adaptive real-time running environment)和应用层。应用层包含的应用模块(AA)运行在ARA上，每个AA作为一个独立的进程运行。它由ARA功能集群提供的应用接口组成，属于自适应平台。Adaptive platform提供Adaptive AutoSAR的基本功能和标准服务。每个AA可以向其他AA提供服务。基于这种架构，整车功能可以解耦。
虚拟机管理程序是运行在基本物理服务器和操作系统之间的中间软件层，它允许多个操作系统和应用程序共享硬件。也可以叫VMM( virtual machine monitor)，即虚拟机监视器。目前主流的汽车驾驶舱都是在一个Soc上同时运行两个不同的操作系统，一个是显示汽车仪表盘的QNX系统，一个是车载信息娱乐的安卓系统，其底层技术原理是Hypervisor。
QNXQNX是一个符合POSIX规范的商业类Unix实时操作系统。其目标市场主要面向嵌入式系统，具有运行效率高、可靠性高的特点。QNNX拥有近40年的工业控制经验，广泛应用于汽车、轨道交通、航空航天等对安全性和实时性要求较高的领域。QNX在车载操作系统市场占有率超过75%，在更注重生态和内容的车载娱乐系统市场占有率超过60%。在强调安全性的仪表板和驾驶员辅助领域，QNX的市场份额接近100%。
2010年，QNX被黑莓的母公司RIM Canada收购。
SOA SOA(Service-Oriented Architecture)是一种基于业务实现的粗粒度、松耦合的面向服务的分布式架构，实现了业务和技术的分离以及业务和技术的自由结合。以位置服务为例。许多车载应用程序使用位置信息，如天气、拍照和导航。这些应用根据自己的服务有不同的需求，它们处理位置信息的方式也不同。SOA可以很好的解决这个问题。SOA最初是一种用于服务器开发的技术，现在也用于星上操作系统领域。但是目前SOA的技术规范比较混乱，国内主机厂商之外的SOA实现方式也不尽相同。车载操作系统不需要SOA。事实上，目前已经上市的车型很少有采用SOA架构的，所以它只是车载操作系统未来的一个发展方向。
2021年，SAIC零捆绑率先发布了行业首个汽车SOA软件架构规范。马尾汽车科技集团旗下的W6号称是国内首款采用SOA的量产车。
车辆以太网车辆以太网是一种新的局域网技术，通过以太网连接车辆中的电子单元。与传统以太网使用四对非屏蔽双绞线不同，车载以太网可以在一对非屏蔽双绞线上实现100 Mbit /s甚至1Gbit/s的传输速率。同时也满足了汽车行业对高可靠性、低电磁辐射、低功耗、带宽分配、低延迟、同步实时的要求。车载以太网是为了满足车载环境的一些特殊要求而设计的。比如满足车载设备对电气特性(EMI/RF)的要求；满足车载设备对高带宽、低延迟、音视频同步等应用的要求；满足车载系统对网络管理的需求等。所以可以理解为车载以太网在民用以太网协议的基础上，改变了物理接口的电气特性，根据车载网络的要求专门定制了一些新的标准。针对车载以太网标准，IEEE组织也对IEEE 802.1和IEEE 802.3标准进行了补充和修订。
CAN (Controller Area Network)是CAN(控制器局域网)的缩写，由以研究和生产汽车电子产品闻名的德国博世公司开发，最终成为国际标准(ISO11898)。它是世界上使用最广泛的现场总线之一。在北美和西欧，CAN总线协议已经成为汽车计算机控制系统和嵌入式工业控制局域网的标准总线，它有J1939协议，是为大型卡车和重型机械车辆设计的，以CAN为底层协议。近年来，其高可靠性和良好的检错能力受到人们的重视，广泛应用于汽车计算机控制系统和环境温度恶劣、电磁辐射强、振动大的工业环境中。CAN广泛应用于车载操作系统的应用开发中。车载Android的核心服务之一CarService，本质上是将外部硬件通信消息解析成上层应用可以识别的数据。目前这里的通信报文一般都是CAN报文。
CAN通信在车辆中的广泛应用，以至于作为Android程序员，我们都要学习CAN仿真测试工具的使用，有时甚至需要读取和分析CAN报文。值得一提的是，CAN仿真测试工具非常昂贵。虽然国内有替代品，但目前德国Victor公司生产的各类工具和软件仍在广泛使用，价格从几万到几十万元不等。
HMI设计工具的嵌入式图形引擎随着车辆Soc计算能力的提升，现代驾驶舱越来越喜欢引入3D图形界面，可以实时生成动画反馈，大大提高了界面的美观性和可用性。目前车辆开发中3D HMI设计工具的主流图形引擎有Unity 3d、Unreal等老牌游戏开发工具，以及致力于汽车HMI设计图形展示的Kanzi。
2016年，芬兰汽车软件公司Rightware及其产品Kanzi被国内汽车软件供应商中科创达收购。
以上介绍了汽车驾驶舱的基础知识。Android应用程序员归根结底还是负责控制驾驶舱，编写各种类型的应用。这就是汽车应用和互联网应用的区别。
03.车载应用开发归根结底，车载安卓应用就是在车载安卓系统中嵌入一系列系统级应用，既包括与用户交互的HMI应用，也包括在后台运行的没有HMI的服务应用。
一般来说，车载应用的复杂度低于一般的互联网应用。
带HMI的常见车载应用，如车载空调、多媒体应用、桌面、SystemUI、系统设置、汽车控制和汽车设置、蓝牙电话和一些第三方应用等。还有没有HMI的应用，比如CarService，AudioService，AccountService等等。在车辆应用程序开发中，需要定制大量的服务，这也是应用程序开发工作量的一部分。
3.1系统级应用与普通应用的区别系统应用需要嵌入Android ROM才能运行。虽然普通应用也可以嵌入ROM，但是系统应用可以调用Android SDK的内部API，这是普通应用做不到的。一般来说，系统应用程序具有以下特征
不需要申请动态权限就可以访问Android SDK内部的API，但是可以配置启动和自启动，并且必须对应用进行签名。接下来，我们实际编写一个系统级应用程序。
3.2写一个系统级应用写Android系统应用和普通Android应用基本一样。首先我们在AndroidStudio里面写一个demo，只需要一个空白的活动和应用。
公共类DemoApp扩展应用程序{ private Handler handler@ Override public void onCreate(){ super . onCreate()；Log.e(‘TAG ‘，’ oncreate : start ‘)；Handler=new Handler(looper . getmainlooper())；handler . post delayed(new Runnable(){ @ Override public void run(){ show view()；} },5000);} private void showView(){ window manager manager=getsystem service(window manager . class)；View view=新视图(this)；窗口管理器。layout params params=new window manager。LayoutParams(WindowManager。LayoutParams.MATCH_PARENT，WindowManager。layout params . MATCH _ PARENT)；params.type=WindowManager。layout params . TYPE _ APPLICATION _ OVERLAY；manager.addView(view，params)；}}上面的应用逻辑很简单。app启动5秒后，会弹出一个全屏窗口。接下来，在AndroidManifest.xml中注册应用程序
XML=’ 1.0′ Encoding=’ UTF-8 ‘在上面的源代码中，我们需要注意两个普通应用程序不使用的属性：android:sharedUserId将与其他应用程序共享的Linux用户id的名称。默认情况下，Android会为每个应用程序分配自己唯一的用户id。但是，如果两个或更多应用程序的此属性设置为相同的值，只要它们的证书集相同，它们将共享相同的ID。如果需要，具有相同用户ID的应用程序可以访问彼此的数据，并在相同的进程中运行。开发系统应用程序时，不需要配置此项。配置为android.uid.system后，应用就会成为系统用户，可以访问一些只有系统用户才能访问的空间。Android:persistent配置应用程序是否应该总是运行，默认值为false。当设置为true时，应用程序将在引导广播发出之前自行启动，并在应用程序被终止后立即重新启动。开发系统应用程序时，不需要配置此项。
3.3测试系统应用3.3.1准备测试环境测试系统应用比较麻烦。由于手头没有开发板，只能基于模拟器进行测试，所以你必须下载Android源代码，使用Android源代码环境编译带有系统签名的APK。请参考：Android车载应用开发与分析(一)Android Automotive概述与编译Android源代码编译完成后，我们会将编译好的FirstCarApp部分源代码复制到/aosp/packages/apps/Car/。基于Android源代码环境的app工程架构和基于Gradle的AndroidStudio完全不同。目录结构如下：
你应该注意到src目录下的androids studio工程结构中没有main/java。应该强调的是，这种基于本地的书写并不常用。其实我们还是在Android Studio中完成开发，将源代码提交给gerrit，jenkins会帮我们完成后续的编译、签名、复制过程。
3.3.2在编译运行应用源代码的环境下编译一个Android应用，需要写一个Android.bp或者Android.mk脚本。如果你对Android.bp或Android.mk一无所知，请参考：Android.mk入门指南| Android.bp入门教程本次测试使用的Android.bp脚本如下
包{ default _ applicable _ licenses :[‘ Android-Apache-2.0 ‘]，} Android _ app { name : ‘ CarFirstApp ‘，srcs: [‘src/**/*。java’]，resource_dirs: [‘res’]，platform_apis: true，certificate: ‘platform ‘，privileged: true，static _ libs :[‘ androidx . app compat _ app compat ‘，’ com . Google . Android . material _ material ‘，]，optimize : { Enabled : false，}，Dex _ preopt 3: { Enabled 3360 false，}，Product _ Variables 3360 {PDK3
#编译Android源代码/aosp $ source build/env setup . sh/aosp $ lunch 12/aosp $ make-j32/AOSP $ emulator-writeable-system-net delay none-net speed full一般情况下，我们可以使用emulator命令直接启动编译后的仿真器，但是此时仿真器的文件系统仍然是只读模式，无法执行remount命令。通过添加-writeable-system-net delay none-net speed full，我们可以正常使用重新安装指令。
重启/AOSP $ ADB Root/AOSP $ ADB Remount/AOSP $ ADB Shell Reboot等模拟器后，我们继续编译CarFristApp的apk。
Link @ Link-PC :/AOSP $ Make car first app.# #编译输出的apk路径=========================================Generic _ car _ x86/system/priv-app/carfirstapp/carfirstapp . apk # # # # Build Completed Successfully(2s)# # #然后使用adb指令在模拟器apk中创建carfriapp目录将编译好的apk推送到system/priv-app/carfriapp/目录。
/Carfirstapp $ ad root/Carfirstapp $ ad remount #创建目录/carfirstapp $ adbshell mkdir/system/priv-app/Carfirstapp/Carfirstapp $ ADB push Carfirstapp.apk/system/priv-app/Carfirstapp #重新启动/Carfirstapp $ ADB shell重新启动等待模拟器重新启动后，可以看到应用会自行启动，然后会弹出一个WindowView覆盖屏幕。不知道大家有没有注意到，无论是自启动，还是弹出一个覆盖屏幕的窗口，都没有显示申请权限的窗口。这是系统级应用程序的一个重要特性。在上面的操作中，我们选择将APK推送到priv-app。除此之外，Android应用还有以下安装路径，可以根据实际需要安装在不同的目录下。/system/priv-app这个路径存储了一些系统底层的应用，比如Setting、systemUI等。这个目录下的应用都有很高的系统权限，如果要使用Android :保护级别=signatureorsystem，那么应用必须放在priv-app目录下。/system/app该目录下存储的系统app权限相对较低，当你拥有root权限时，就有可能卸载这些app。/vendor/app此目录存储应用程序用户安装的供应商的应用程序/数据/第三方应用程序。
3.4车辆应用难点在车辆应用开发过程中，经常会遇到以下几个难点：
调试费时费力。其实车载应用的开发不是难，而是烦！尤其是调试，不像开发移动应用，车载应用的运行环境是基于AOSP定制的，很多时候会出现无数的bug。有时候系统底层的bug会在上层应用中体现出来，这就需要应用开发者有能力准确识别这个bug的主人。复杂的ui现在的车载应用都有一套复杂酷炫的交互ui。同时，由于车载安卓与QNX共用一个Soc和内存，大部分时间系统资源比主流手机差很多。对于应用程序开发人员来说，实现一套复杂的高性能HMI通常是非常具有挑战性的。缺乏对系统API的理解。大多数时候，车载应用程序的开发需要对原系统中已经存在的应用程序进行重新定制，例如系统设置。这就需要开发者对原生应用的运行方式和调用的API有一定的了解。04.车载Android的发展前景。看完以上，相信你对车载安卓的发展已经有了简单的了解。不知道你是不是觉得我在劝你转行做板载Android的开发？答案是否定的！纯Android应用工程师只能负责整车驾驶舱内很小的一个技术领域，这已经决定了这个职业的发展高度。想要突破这个天花板，就必须深入Android系统底层，掌握一些Framework、HAL甚至Native的运行原理。此外，Linux、汽车相关知识也需要额外学习。目前车载Android的发展还是有很好的前景的，但是远没有达到以前移动互联网的普及程度，甚至未来可能都达不到。就像曾经炙手可热的移动互联网，随着大量开发者的涌入，汽车制造业的洗牌，供求关系的改变，必然有衰落的一天。我曾经后悔进入车载开发，因为相比移动应用开发，要学的知识太多，调试过程也比移动应用复杂，但这一代人不都是在后悔中度过的吗？