原副标题:导航Android应用应用领域合作开发进阶手册

导航iOS应用领域合作开发进阶手册插图

01.序言 – 终端互联网涨潮下的电动汽车混战

将时间班莱班县到2017年我大学刚毕业时,由此可见终端互联网已经已经开始涨潮,各大个培训机构也争相停止了Android相关的培训,曾经不亦乐乎的应用应用领域合作开发从那以后,已经开始迈向上坡路,小程序和众多虚拟化框架也让市场对Android原生植物合作开发的需求逐年减少,市场需求的减少也造了Android合作开发的复试变得的卷。

终于我在2019年选择离开了互联网,投身于由此可见还不是非常火爆的导航Android应用领域继续专门从事Android原生植物合作开发。而这一年中国申港的整车制造项目,上海Tesla超级工厂开工了。

Tesla在智能和网络化上的巨大优势将智能电动汽车推至了两个全新的度,先进的自动驾驶和BMS电池管理掌控系统,深深震撼人心了全世界的人,在由此可见的儒者眼中Tesla几乎是新能源电动汽车的同义词,时至,Model Y和Model 3已也依然是新能源电动汽车应用领域的卖座车型。

不可否认电动汽车轻工业是发达国家重要的经济支柱,而中国是世界上小电动汽车生产和销售国,Tesla的热卖立马引发了这场 若丽鱼效应,国内外的电动汽车制造商争相已经开始布局智能电动汽车,电动汽车轻工业迈向了应用软件表述电动汽车的时代。应用软件表述电动汽车的中心思想是,决定未来电动汽车的是以人工智慧为核心的微电子,导航应用软件在电动汽车应用领域的重要性首次被神化到了前所未有的度,这样这场血雨腥风的导航微电子混战上演了。

02.智能电动汽车驾驶舱基本上内部结构

在专门从事导航Android应用应用领域合作开发前,必须要对电动汽车驾驶舱的基本上内部结构有两个大体的知觉,只有意识到电动汽车驾驶舱是一种与手机完全不同的构架,就可以更好的助推我们日后学习导航Android应用应用领域的合作开发。下面来如是说两个比较非主流的导航操作掌控系统构架。

上面是目前非主流电动汽车驾驶舱采用技术构架,我们由上而下依次如是说:

T-BOX

T-Box又称TCU(车联网掌控模块),指安装在电动汽车上用于掌控跟踪电动汽车的PDP掌控系统,是导航信息可视化掌控系统关键部件,有了它电动汽车就可以实现联网机能,所以也起到中央交换机的作用。通常包括GPS模块、终端通信外部USB电子处理模块、中央处理器、终端通信模块和内存等。

对工程车,T-Box可提供更多工程车机械故障监控、电源管理、远距升级、数据采集、智慧交通等机能,对车主,T-Box可为提供更多工程车远距掌控、智能家居服务等机能。

T-BOX属于外围硬体,与中控台、仪表并不软件系统在两个主板上。

SOC

SoC的表述多种多样,由于其内涵丰富、应用应用领域范围广,很难给出准确表述。一般说来, SoC称为掌控系统级芯片,也有称片上掌控系统(System on Chip),意指它是两个产品,是两个有专用目标的软件系统电路,其中包含完整掌控系统并有嵌入应用软件的全部内容。

导航Soc和我们常见的手机Soc非常类似,内部软件系统了CPU和GPU。目前非主流的导航Soc是高通的SA8155,它是高通在手机Soc骁龙855的基础上发展而来的。

MCU

微掌控模块(Microcontroller Unit;MCU) ,又称单片微型计算机(Single Chip Microcomputer )或者单片机,是把中央处理器(Central Process Unit;CPU)的频率与规格做适当缩减,并将内存(memory)、计数器(Timer)、USB、A/D转换、UART、PLC、DMA等周边USB,甚至LCD驱动电路都整合在单一芯片上,形成芯片级的计算机。

AutoSAR

Adaptive AutoSAR 是一种适用于高级自动驾驶的应用软件构架平台,提要提供更多高性能的计算和通信,提供更多灵活的应用软件配置,支撑应用应用领域的更新。

Adaptive AutoSAR 的主要构架分为硬体层、ARA(AutoSAR Run-timeFor Adaptive实时运行环境)和应用应用领域层。

应用应用领域层包含的应用应用领域程序模块(AA)运行在ARA之上,每个AA以独立的进程运行。ARA由机能集群提供更多的应用应用领域USB组成,他们属于自适应平台。自适应平台提供更多Adaptive AutoSAR 的基本上机能和标准服务。

每个AA可以向其他AA发生服务。基于这种构架,整车的机能之间可以解耦。

Hypervisor

一种运行在基础物理服务器和操作掌控系统之间的中间应用软件层,可允许多个操作掌控系统和应用应用领域共享硬体。也可叫做VMM( virtual machine monitor ),即虚拟机监视器。

目前非主流的电动汽车驾驶舱,都是同时在两个Soc上运行着两个不同的操作掌控系统,两个是显示电动汽车仪表盘的QNX掌控系统,另两个用于导航信息娱乐的Android掌控系统,其底层技术原理是Hypervisor。

QNX

QNX是一种商用的、遵从POSIX规范的类Unix实时操作掌控系统,目标市场主要是面向PDP掌控系统,具备高运行效率、高可靠性特点,并在工控应用领域拥有近40年的使用经验,被广泛应用应用领域于电动汽车、轨道交通、航空航天等对安全性、实时性要求较高的应用领域。

QNX在导航操作掌控系统市场的占有率超过75%,在更注重生态和内容的导航娱乐掌控系统占有率也超过60%,而在强调安全性的仪表盘和驾驶辅助应用领域,QNX的市占率更是达到了近。

SOA

SOA(Service-OrientedArchitecture)是一种基于业务实现的粗粒度松耦合的面向服务的分布式构架,即实现业务和技术的分离,又实现业务和技术的自由组合。

以位置服务为例,很多车内应用应用领域会用到位置信息,像天气、拍照、导航,这些应用应用领域根据自身服务有不同的需求,对位置信息的处理各不相同,SOA可以很好地解决这个问题。

SOA原本是服务器合作开发中用到的技术,现如今也被用在导航操作掌控系统应用领域,但是目前关于SOA的技术规范比较混乱,国内主机厂商外对于SOA的实现方式也有区别。

SOA并不导航操作掌控系统必须的,其实目前为止已经上市的车型中,很少采用了SOA构架,所以它还只是导航操作掌控系统未来的两个发展方向。

导航以太网

导航以太网是一种用以太网连接车内电子模块的新型局域网技术,与传统以太网使用4对非屏蔽双绞线电缆不同,导航以太网在单对非屏蔽双绞线上可实现100 Mbit /s,甚至1Gbit/s的传输速率,同时还满足电动汽车行业对高可靠性、低电磁辐射、低功耗、带宽分配、低延迟和同步实时性等方面的要求。

导航以太网的设计是为了满足导航环境中的一些特殊需求。例如:满足导航设备对于电气特性的要求(EMI/RF);满足导航设备对高带宽、低延迟和音视频同步等应用应用领域的要求;满足导航掌控系统对网络管理的需求等。因此可以理解为,导航以太网在民用以太网协议的基础上,改变了物理USB的电气特性,并结合导航网络需求专门定制了一些新标准。针对导航以太网标准,IEEE组织也对IEEE 802.1和IEEE 802.3标准进行了相应的补充和修订。

CAN

CAN是掌控器域网 (Controller Area Network, CAN) 的简称,是由研发和生产电动汽车电子产品著称的德国BOSCH公司合作开发了的,并终成为国际标准(ISO11898)。是国际上应用应用领域广泛的现场总线之一。在北美和西欧,CAN总线协议已经成为电动汽车计算机掌控掌控系统和PDP轻工业掌控局域网的标准总线,并且拥有以CAN为底层协议专为大型货车和重工机械工程车设计的J1939协议。近年来,其所具有的高可靠性和良好的错误检测能力受到重视,被广泛应用应用领域于电动汽车计算机掌控掌控系统和环境温度恶劣、电磁辐射强和振动大的轻工业环境。

3D HMI设计工具 & PDP图形引擎

随着导航Soc算力的提高,现代驾驶舱越来越喜欢引入3D化的图形界面,3D化的界面可以实时生成动画反馈,大大提升了界面的美观性和易用性。目前导航合作开发中非主流的3D HMI设计工具&图形引擎有老牌的游戏合作开发工具如Unity 3d、Unreal(虚幻),也有专用于电动汽车HMI设计&图形显示的 — Kanzi 。

上面如是说了电动汽车驾驶舱的基础知识,Android应用应用领域程序员说到底还是负责在驾驶舱中控台,编写各类型的应用应用领域,下面来如是说导航应用应用领域与互联网应用应用领域的不同之处。

03.导航应用应用领域合作开发

导航Android应用应用领域说到底是,在导航Android掌控系统中嵌入一系列掌控系统级应用应用领域,这里既包含与用户存在可视化的HMI应用应用领域,也包含在后台运行没有HMI的Service应用应用领域。

常见有HMI的导航应用应用领域如,导航空调、多媒体应用应用领域、桌面、SystemUI、掌控系统设置、车控车设、蓝牙电话和一些第三方应用应用领域等等。

没有HMI的应用应用领域有,CarService、AudioService、AccountService等等。在导航应用应用领域合作开发中需要定制大量的Service,这也是应用应用领域合作开发中工作量比较大的一部分。

3.1 掌控系统级应用应用领域与普通应用应用领域的区别

掌控系统应用应用领域需要嵌入到Android ROM中运行,虽然普通的应用应用领域也可以嵌入到ROM中,但是掌控系统应用应用领域可以调用Android SDK的内部API,而这一点是普通应用应用领域做不到的,总得来说掌控系统应用应用领域具有以下特点

接下来我们实际上手编写两个掌控系统级应用应用领域。

3.2 编写两个掌控系统级应用应用领域

编写Android掌控系统应用应用领域与普通的Android应用应用领域基本上相同,我们首先在AndroidStudio中编写两个demo,只需要两个空白的Activity和Application即可。

publicclassDemoAppextendsApplication{

privateHandlerhandler ;

@Override

publicvoidonCreate(){

super.onCreate();

Log.e(“TAG”,”onCreate: start”);

handler =newHandler(Looper.getMainLooper());

handler .postDelayed(newRunnable(){

@Override

publicvoidrun(){

showView();

}

},5000);

}

privatevoidshowView(){

WindowManagermanager =getSystemService(WindowManager.class);

Viewview =newView(this);

WindowManager.LayoutParamsparams =newWindowManager.LayoutParams(WindowManager.LayoutParams.MATCH_PARENT ,WindowManager.LayoutParams.MATCH_PARENT );

params .type =WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY ;

manager .addView(view ,params );

}

}

上面的application逻辑很简单,app启动5秒后,弹出两个全屏的Window的。

接下来在AndroidManifest.xml中注册application。

package=”com.example.car “

android:sharedUserId =”android.uid.system “>

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 “>

android:name =”.MainActivity “

android:exported =”true “>

在上面源码中我们需要关注两个普通应用应用领域用不到的属性:

android:sharedUserId

将与其他应用应用领域程序共享的 Linux 用户 ID 的名称。默认情况下,Android 会为每个应用应用领域分配自己的用户 ID。但是,如果为两个或多个应用应用领域将此属性设置为相同的值,则它们将共享相同的 ID,前提是它们的证书集相同。具有相同用户 ID 的应用应用领域可以访问彼此的数据,如果需要,可以在同一进程中运行。

合作开发掌控系统应用应用领域时,此项不是必须配置的。配置为 android.uid.system 后,该应用应用领域会变成system用户,可以访问一些system用户就可以访问的空间。

android:persistent

配置应用应用领域程序是否应始终保持运行,默认为false。设为true之后,应用应用领域在开机广播发出之前会自行启动,而且应用应用领域被杀死后,也会立即重启。

合作开发掌控系统应用应用领域时,此项不是必须配置的。

3.3 测试掌控系统应用应用领域 3.3.1 准备测试环境

测试掌控系统应用应用领域比较麻烦了,由于手边没有合作开发板,只能基于模拟器进行测试,所以必须下载Android的源码,并使用Android源码环境编译出带有掌控系统签名的APK。

下载、编译Android源码 请参考 :Android导航应用应用领域合作开发与分析(1) – Android Automotive概述与编译

完成Android源码编译后,我们将编写好的FirstCarApp部分源码拷贝到 /aosp/packages/apps/Car/ 下,

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

3.3.2 编译&运行应用应用领域

源码环境下编译出Android应用应用领域,需要编写两个Android.bp或Android.mk脚本,如果你对Android.bp或Android.mk并不了解的话请参考:Android.mk 上手手册 | Android.bp进阶教程

本篇测试用的Android.bp脚本如下

package{

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.appcompat_appcompat”,

“com.google.android.material_material”,

],

optimize: {

enabled:false ,

},

dex_preopt: {

enabled:false ,

},

product_variables: {

pdk:{

enabled:false ,

},

},

}

然后完整编译一次Android的源码

编译Android源码

/aosp$ source build /envsetup .sh

/aosp$ lunch 12

/aosp$ make -j 32

/aosp$ emulator -writable -system -netdelay none -netspeed full

一般情况下我们可以直接使用emulator指令可以启动编译好的模拟器,但是此时的模拟器的文件掌控系统还是read-only模式,并且不可以执行remount指令,通过添加-writable-system -netdelay none -netspeed full,我们可以正常使用remount指令了。

/aosp$ adb root

/aosp$ adb remount

/aosp$ adb shell reboot

等模拟器重启后,我们继续编译出CarFristApp的apk。

link@link -PC :/aosp$ make CarFirstApp

编译后输出的apk路径

============================================

[4/4]Install :out/target /product /generic_car_x86 /system /priv -app /CarFirstApp /CarFirstApp .apk

build completed successfully (2 seconds)

然后使用adb指令在模拟器中创建两个CarFristApp目录,将编译好的apk push到system/priv-app/CarFristApp/目录下。

/CarFirstApp$ adb root

/CarFirstApp$ adb remount

创建目录

/CarFirstApp$ adb shell mkdir /system /priv -app /CarFirstApp

/CarFirstApp$ adb push CarFirstApp.apk /system /priv -app /CarFirstApp

重启

/CarFirstApp$ adb shell reboot

等待模拟器重启结束后,可以看到,app会自行启动,然后会弹出两个WindowView遮住屏幕。不知道你是否注意到了,无论是自启动,还是弹出两个遮住屏幕的Window,都没有申请权限的窗口显示出来,这掌控系统级应用应用领域的两个重要特点。

在上面的操作中我们选择把apk push到priv-app下面,除此以外Android应用应用领域还有以下几种安装路径,可以根据实际需要安装到不同的目录中去。

/system/priv-app

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

/system/app

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

/vendor/app

该目录存放vendor厂商的app

/data/app

用户安装的第三方app

3.4 导航应用应用领域的难点

导航应用应用领域合作开发过程中,往往都会遇到以下几个难点:

复杂的UI 现如今的导航应用应用领域都会有着两个套复杂且炫酷可视化UI,同时,由于导航Android与QNX共享两个Soc和内存,所以多数时候掌控系统资源都比非主流的手机要差不少,对应用应用领域合作开发者来说,实现一套复杂且高性能的HMI,往往会非常有挑战性。对掌控系统API理解不够 合作开发导航应用应用领域多数时候都会要求重新定制两个原本掌控系统中已经存在的应用应用领域,比如掌控系统设置。这就要求合作开发者对于原生植物应用应用领域的运行方式、调用的API都有一定的了解。

04. 导航Android合作开发的前景

读完以上的内容,相信你已经对导航Android的合作开发有两个浅显的认识了。不知道你会不会认为我在劝你转行做导航Android的合作开发?答案是NO!

单纯的Android应用应用领域工程师在整车驾驶舱上只能负责非常小的两个技术应用领域,这已经决定了这个职业的发展度,如果想突破这层天花板,必须要深入到Android掌控系统的底层,掌握Framework、HAL甚至于Native的一些运行原理。除此以外,Linux、电动汽车相关的知识也是需要额外学习的。

目前而言,导航Android合作开发依然有着不错的前景,但还远没有达到曾经的终端互联网的热度,甚至可能以后也不会达到,并且像曾经不亦乐乎的终端互联网一样,随着大量合作开发人员的涌入、电动汽车制造业的重新洗牌、供需关系的改变,总有它也会不可避免的迈向上坡路。

我曾经后悔过入行导航合作开发,因为相比手机应用应用领域合作开发,所需要学习知识实在太多太杂,调试过程也比手机应用应用领域复杂,但是人这一辈何尝不是在后悔中度过的呢?

参考资料:

[智能驾驶舱:智能基础平台及构架(下)]

[2020年中国T-BOX行业现状分析,乘用车T-Box装配率迅速提升「图」]

[导航操作掌控系统(三):智能驾驶舱操作掌控系统]

[专为先进智能驾舱打造的一体化HMI工具——Kanzi One重磅发布]

[Automotive | Android 开源项目 | Android Open Source Project]

[导航以太网-电子发烧友网]

来源:智能交通技术(微信公号ID:ITSTech)返回搜狐,查看更多

责任编辑:

作者 nasiapp

在线客服
官方客服
我们将24小时内回复。
12:01
您好,有任何疑问请与我们联系!

选择聊天工具: