智能座舱架构与芯片- 测试篇-CSDN博客

本文链接：https://blog.csdn.net/XiaoXiaoPengBo/article/details/147345624

转载：https://www.zhihu.com/people/du-jiao-jian-mo-91

一、验证平台概要

1.1 测试软件方法论

“软件定义汽车” 的时代，软件在整车制造中的重要性日渐凸显。但不同于其他行业的软件开发，汽车行业有自己独特的软件开发要求。首先是需求严谨、需求层次复杂、需要通过专业的工具进行管理；其次开发团队技术需覆盖多个领域，一整套嵌入式软硬件开发的解决方案，涉及硬件设计开发、基础软件开发、上层应用软件开发等，各团队之间技术栈差异极大；最后还要求不同领域 / 团队之间协同紧密，即使是一个简单的功能开发，可能需要涉及多个领域协作完成。

V模型开发与验证

传统的汽车软件开发，一般遵循“V模型”的方式，ASPICE即为其中的代表。

Automotive SPICE（简称 ASPICE），全称是“Automotive Software Process Improvement and Capacity Determination”，即“汽车软件过程改进及能力评定”模型框架。其起源于1994年，是国际标准化组织ISO、国际电工委员会IEC等机构制定的联合标准之一，后由德国汽车工业联合会（VDA）运营发展，用于指导实现高标准的车载软件开发流程，从而改善车载软件的质量。目前，ASPICE是汽车产业的软件流程改进和能力测定标准，当前已成为全球汽车产业评价供应商软件研发能力的普遍标准之一。

ASPICE源自于ISO 12207及ISO 15004–5:2006 提供的重评估模型，目前由VDA WG13 (德国汽车联合公会工作小组13)发行，并且由VDA注册商标。现在最新的ASPICE标准是2017年11月发布的3.1版本。

ASPICE过程域

ASPICE将汽车系统研发过程划分为了32个过程，并将这32个过程归类到3大类、8个过程组。

过程，即Process。首先将一个完整的汽车软件开发项目切割成8个组（Group）。然后对每个组再次切分成若干个子模块，即过程（Process）。每个过程都有自己的过程ID，过程名称，过程目的和过程成果。

如下图所示：

在系统组(SYS)和软件组(SWE)的工作流程中，开发与验证是对应的关系。

在ASPICE的V模型中，需求分析、系统设计、详细设计和编码实现构成了左半部分，单元测试、集成测试、系统测试构成了右半部分，其中左半部分是右半部分的准备阶段，右半部分是左半部分的实现阶段。如下图可以看到，SWE.1 软件需求分析对应的是SWE.6 软件合格性测试；SWE.3 对应的是SWE.4，详细设计对应单元测试。

在需求分析阶段，要考虑系统验证的计划，包括确保每一个需求点都是可验证的，并设计相应的初步系统验证用例；
在概要设计阶段，要考虑部件验证计划，设计相应用例，验证高级模块的功能以及模块之间的接口关系；
进行基础软件验证时需按照顺序开展代码静态验证、单元验证、部件验证（包括软软集成、软硬集成）、系统验证等测试执行工作。其验证类型可分为白盒测试、黑盒测试两类。白盒测试包含代码静态验证、单元验证，重点侧重于代码逻辑、接口实现等内容。黑盒测试包含部件验证、系统验证，重点侧重于硬件功能实现、人机交互实现及通信功能实现等内容。

自动化测试云平台

在汽车的测试中，HIL(Hardware in Loop, 硬件在环)和MIL(Model in Loop, 模型在环) 是两种重要的测试类型。

HIL测试是一种在整套硬件系统上验证代码实现的功能是否与需求定义一致的测试方法，是进行整车仿真测试和实车路试前重要的验证环节。这是一种在硬件在环仿真系统中进行的测试，可以模拟实际车辆的各种工况，以便验证车辆的各项性能指标和功能是否达到预期。

MIL测试是用模型驱动工程开发嵌入式系统的时候，在开发的初期阶段及建模阶段中进行的仿真方式。一般在应用层软件开发用来验证控制算法模型是否准确地实现了需求。这是一种模型在环仿真系统的测试，主要目的是检查模型算法的正确性。

这两种测试方法都是为了在车辆真正上路之前，尽可能发现并解决潜在的问题，以确保车辆在实际运行中的安全性和可靠性。

因此，必须搭建汽车软件测试验证平台，以验证可能存在的问题。为了提高验证的效率，可以采用云平台的方式，实现全面的端云一体，无人值守测试体系。

整体架构：采用云到端的框架，实现远程监控，集中管理，自动构建，持续集成，无人值守的测试；

平台构成：云服务器，数据服务器，测试台架，测试目标机，监控客户端等；

在上述云测试平台系统中，测试台架和测试车机是控制并实现HIL测试的关键设备。它们需要支持如下功能：

支持CAN/LIN/Ethernet 信号收发与诊断；
支持外设控制，电源控制，音频模拟与截取，图像模拟与截取等功能；
支持多种日志记录与分析，包括Linux系统日志，QNX日志，Android日志记录等；
支持自动部署软件，自动上下电，自动运行，自动抓取Log等功能；

对于自动化测试云平台来说，需要满足如下的功能需要：

支持服务仿真、同域和跨域交互仿真、持续集成（CI）、持续部署（CD）以及Android、QNX、Linux等多种主流操作系统。
协助研发人员高效便捷的搭建SOA仿真环境，并在研发阶段进行服务仿真调试和自测。
具有自动化测试执行、测试用例及脚本自动生成等功能。
拥有广泛的应用领域，适用于服务订阅/发布测试、服务功能测试、服务接口测试、服务性能测试、服务压力测试、服务稳定性测试等多种场景。

1.2 测试软件体系

在汽车软件自动化测试云平台中，智能座舱的测试软件体系主要分为以下几部分：

云端管理软件：这一部分的软件包含了云测试管理平台，它对测试资源进行统一管理，对测试任务、测试用例、测试活动、测试远程控制、测试记录与报表等实行集中管理。
上位机软件：这一部分的软件运行在上位机(测试台架)中，主要面向汽车信号模拟测试与智能座舱操作控制测试同步、自动完成，利用图像识别技术自动进行结果验证，生成可视化测试报表。
信号控制硬件：这一部分的硬件主要用来模拟常用的汽车信号以及发送CAN信号，另外还提供多个外设接口，模拟一些特殊的信号，例如外接音频分析仪进行报警音检测等。
车机软件：这一部分软件运行在被测试的车机上，它按实际工作逻辑，接收仿真信号注入，产生应答，并按标准接口将应答信息或日志记录等上传。

无疑，台架软件(上位机软件)是承上启下，实现自动测试的关键要点。它在测试体系中主要负责以下功能：

信号模拟与测试：台架可以模拟汽车信号以及发送CAN信号，并且可以提供多个外设接口，模拟一些特殊的信号，例如外接音频分析仪进行报警音检测等。
操作控制测试：针对智能座舱的操作控制测试，它可以实现自动化测试，并且可以利用图像识别技术自动进行结果验证，生成可视化测试报表。
数据记录与分析：可以记录测试过程中的各种数据，包括但不限于信号的变化、测试结果、时间戳等，并且可以对这些数据进行统计分析，以便于发现问题、改进测试方案。
远程监控与控制：可以通过云端管理软件，对远程的测试资源进行监控和控制，使得测试过程可以更加灵活和高效。
系统集成与优化：可以集成其他测试工具、仪器和设备，并且可以根据实际需求进行优化和调整，以提升整体测试效率和质量。

如下图，给出了一个简要的自动测试流程，可见台架软件是如何通过以下步骤实现信号模拟与测试的：

连接硬件：台架软件需要与硬件设备连接，例如CAN总线适配器、USB转串口适配器、音频分析仪等。这些硬件设备可以通过串口、USB接口或其他方式与台架软件进行通信。
模拟信号生成：台架软件可以根据测试需求，通过模拟信号生成模块来生成不同的模拟信号。例如，可以生成模拟车辆速度、发动机转速、温度等信号，也可以模拟车辆故障信号，如ABS故障、发动机故障等。
信号采集与转换：在测试过程中，台架软件需要获取来自硬件设备的信号，例如电压、电流、温度等信号。这些信号在信号控制硬件被采集后转换为数字信号，并通过通信接口与台架进行数据传输。
信号分析与处理：台架软件通过数字信号处理技术，例如FFT（快速傅里叶变换）算法、滤波算法等，对采集到的信号进行分析和处理，以提取出有用的测试数据。
数据存储与分析：云端软件将测试数据存储在本地或云端数据库中，并且可以通过数据可视化技术，例如曲线图、柱状图等，对测试数据进行展示和分析。这样，测试人员可以更加方便地查看测试结果，并且可以通过对数据的分析，发现测试中存在的问题和改进测试方案。

1.3 自动化测试工具

对于测试系统来说，一个好的自动化测试工具是提升效率，节省时间和金钱的效费比选择。在之前介绍的自动化测试平台中，有2类自动化测试工具可供选用。

1. 云端自动测试工具

可用的云端自动测试工具很多，在此仅举一个例子用来说明：

Phoenix Framework是一款基于Selenium、webdriver、autoIt研发的自动化测试工具，使用java语言封装，包含无脚本模式执行、无人值守模式执行、自由定制模式、分布式执行等功能。它主要用于应对复杂应用系统的测试，提高测试效率和质量，缩减测试成本。

Phoenix Framework具有以下特点：

跨浏览器兼容性：Phoenix Framework支持四种浏览器类型，包括Chrome、Firefox、Safari和Edge，可以满足不同浏览器的测试需求。
智能识别机制：它支持七种元素动态定位方式，能够智能地识别和定位页面元素，提高了测试的准确性和效率。
数据维护模块：Phoenix Framework集成了数据维护模块，方便了自动化后期脚本数据维护的问题，减少了人工干预和错误。
属性录制模块：该框架还具有属性录制模块，能够方便地记录和导入元素定位信息，减少了手动的测试工作量。
自定义模块：Phoenix Framework还支持自由定制模式，用户可以根据自己的测试需求，自定义测试脚本和流程，实现更灵活的自动化测试。
分布式执行：该框架支持分布式执行，可以同时在多台计算机上执行测试任务，加快了测试速度，提高了测试效率。
详细的测试报告：Phoenix Framework提供了详细的测试报告和执行过程的录制回放功能，可以帮助测试人员对测试结果进行全面的分析和评估。
多平台支持：Phoenix Framework不仅可以在Windows上运行，还可以在Linux和Mac OS等平台上运行，具有很好的跨平台兼容性。
支持B/S结构的系统的自动化测试：Phoenix Framework能够应对B/S结构的系统的自动化测试，包括Web应用程序、Web服务、REST API等。
与其他工具集成：Phoenix Framework可以与其他测试工具、缺陷管理工具和持续集成/持续部署（CI/CD）工具集成，如Jira、TestRail、Jenkins等，方便了测试管理和自动化流程的整合。
支持多种数据库：除了默认的MySql数据库，Phoenix Framework还支持Oracle、DB2、SQL Server等多种数据库。

Phoenix Framework的系统框架主要由以下几部分组成：

用户接口（User Interface）：用户接口是用户与Phoenix Framework交互的方式。用户可以通过该接口创建、编辑、运行和管理测试脚本，以及查看测试报告和执行结果。
测试脚本引擎（Test Script Engine）：测试脚本引擎是Phoenix Framework的核心组件之一，负责解析、执行和报告测试脚本的执行情况。
浏览器驱动（Browser Driver）：浏览器驱动是Phoenix Framework与被测系统（被测应用或网站）进行交互的组件。它负责模拟用户操作，如点击、输入、滚动页面等，并与测试脚本引擎通信，确保测试的正确性和稳定性。
数据库（Database）：Phoenix Framework使用数据库来存储和管理测试数据、配置信息和其他相关信息。
模块（Modules）：模块是Phoenix Framework的功能扩展组件，可以增强框架的功能和灵活性。例如，数据维护模块可以方便地管理测试数据，属性录制模块可以方便地记录和导入元素定位信息等。

2. 台架自动测试工具

台架软件上可运行的自动测试工具一般需要定制开发，它属于专用的上位机软件。一般来说，造车新势力主机厂，或者智能座舱Tier1供应商等，都会有相对较大的座舱软件团队，他们会根据自己的需要设计专用的自动化测试台架。部分Tier1供应商也会为不同的客户提供基础测试软件平台，并可基于客户的要求进行客制化。这些座舱测试软件平台拥有共同的特质：

设备连接与测试环境搭建：系统可以快速实现与被测设备的连接，并搭建稳定的测试环境，支持多种类型的座舱设备，如车载信息娱乐系统、导航系统、仪表盘等。
自动化测试脚本生成：基于图像和文字识别技术，系统能够自动识别被测设备的界面元素，并生成可执行的自动化测试脚本。用户可以通过简单的操作来生成测试用例，减少了手动编写测试脚本的工作量。
实时测试过程监控：在测试执行过程中，系统可以实时监控被测设备的状态，包括界面元素的状态、设备硬件的运行状态等。如果出现异常情况，系统会立即告警，以便测试人员及时处理问题。
测试数据统计与分析：系统能够自动记录测试过程中的各种数据，如测试用例的执行结果、设备性能指标等。用户可以对这些数据进行统计和分析，以便更好地评估座舱软件的质量和稳定性。
远程协同测试：多个测试人员可以在不同地点进行协同测试。这对于大规模的座舱软件测试项目来说，可以提高测试效率并减少人力成本。
自动化测试报告生成：系统可以自动生成详细的测试报告，包括测试用例的执行情况、缺陷记录、性能指标等。用户可以根据测试报告来评估座舱软件的质量和改进方向。

对于台架测试软件来说，各家的功能大同小异，其核心价值在于测试Case的设计与数量，而这些测试Case需要项目与经验的积累。

二、验证平台案例

2.1 测试用例概述

智能座舱的功能复杂度与日俱增，新技术的挑战层出不穷。随着多屏联动、语音识别、手势控制、增强现实、多模交互等新技术的涌现，座舱功能越来越丰富、越来越复杂，在丰富功能的同时也给测试带来很多新的挑战。为了迅速抢占先机，占领市场，产品上市周期随之缩短。如何在交付之前保证产品的安全可靠，如何控制替换成本，是当下智能座舱供应商面临的严峻考验。

传统人工测试的方式早已被证明效率低下，座舱测试引入自动化也不是什么新鲜事物。

自动化测试的关键在于如何确认测试用例，对于智能座舱测试来说，它的测试用例（test case）主要包括以下几类：

基础功能测试：测试智能座舱的基本功能是否正常，例如音响、导航、车窗、空调、语音识别等。
性能测试：测试智能座舱的性能是否满足设计要求，例如响应时间、精度等。
界面测试：测试智能座舱的界面是否易用、美观，例如按钮布局、菜单结构、字体大小等。
兼容性测试：测试智能座舱是否能够适应不同的硬件、软件环境，例如不同的手机、操作系统等。
安全性测试：测试智能座舱的安全性能，例如密码保护、数据加密等。
可靠性测试：测试智能座舱的可靠性，例如长时间使用是否会出错、是否耐高温等。
自动化测试：使用自动化测试工具进行测试，例如模拟用户的实际操作，测试智能座舱的反应是否正常。
用户体验测试：测试智能座舱的用户体验是否良好，例如是否容易上手、是否符合用户习惯等。
稳定性测试：在长时间、大量次数的使用下，测试智能座舱是否仍能保持稳定性。

如下图，给出了智能座舱中典型的测试场景：

以上简要介绍了智能座舱中，需要验证的典型场景，下一步还需要给出两个详细的实例进行说明。

2.2 网络通信测试验证

网络通信是实现汽车各控制器进行信息交互的桥梁，在汽车主干网中常用的总线通信类型大致包含CAN总线、LIN 总线、以太网三类。此外，智能网联化的发展也对车辆的网络通信提出了低延时，大带宽，高可靠的要求。上述三类网络通信方式的组合及其在基础软件验证平台的应用，基本能够满足汽车在不同架构类型及不同功能场景下的通信需求。与之相对应的基础测试验证则成为了检验基础软件是否满足通信需求的重要一环。

以下为摘自《中国汽车基础软件发展白皮书3.0》中，关于网络通信测试验证的具体实例内容。

1. 需求分析：

基础软件虽然具备软硬件的解耦、接口的可复用性、平台的可移植性等优势，但是其可灵活配置的特性也决定了其面向整车系统时配置参数具有差异化或在基础软件代码开发移植阶段存在不满足整车通信需求的情况。例如某一车型平台或某一架构下各个控制器的基础软件在开发阶段的通信参数设置、信号交互、总线通信故障处理逻辑等与期望不一致的情况。这些差异化的内容往往会导致汽车总线无法通信、功能无法正常执行等问题，因此网络通信测试的验证务必在单个控制器开发完成后进行，以保证装车后的通信质量。

2. 验证方法：

CAN/LIN 网络通信的验证主要针对通信配置参数、总线容错处理及恢复逻辑、报文交互等内容进行验证，因此测试设计方法主要为需求分析方法、边界值分析、等价类法。为实现网络通信验证，需视不同的需求搭建测试环境。网络通信验证的测试环境可分为基于示波器的测试、基于总线分析仪的测试、基于总线干扰仪的测试三类。

3. 验证范围：

依据 OSI 模型，为保证基础软件开发严格按照需求进行，需针对通信需求内容进行覆盖。网络通信的测试验证主要包含数据链路层、交互层、应用层测试。数据链路层主要针对采样点、波特率、帧类型兼容等层面进行基础软件通信配置参数的验证；交互层主要针对车辆的报文交互是否严格按照通信定义开发进行验证，应用层主要针对总线故障及 bus off 等网络容错处理恢复策略进行验证。此外，如有功能或信息安全的应用，需基于交互层进行算法逻辑的验证。如下表格为网络通信基础验证的部分用例，详细测试用例中的每条用例应包含有唯一的编号、需明确需求点、测试目的、测试环境、测试步骤、评价标准等内容。

CAN验证范围

图片来源：中国汽车基础软件发展白皮书3.0

LIN验证范围

图片来源：中国汽车基础软件发展白皮书3.0

ETH验证范围

图片来源：中国汽车基础软件发展白皮书3.0

2.3 图像失效测试验证

在智能座舱中，在仪表屏上显示关键告警图标(称为Telltale)是涉及到功能安全的关键功能。自动化测试验证平台如何识别并判断发生了Telltale安全失效呢？采用图像失效验证是一个可行的测试方法。

通过自动化测试验证图像失效的一种方案为：

定义图像识别规则：根据仪表屏显示区域的设计要求，定义图像识别的规则和标准，主要是telltale图标在仪表屏上显示的坐标，显示区域，尺寸等数据。该规则也称为ROI(Region of Interest)。
采集ROI图像：在软件设计和开发过程中，采集标准的图像样本，包括正常情况下的图像以及异常情况下的图像，用于后续的图像比对和验证。台架软件通过通信网络，下发截取ROI区域的指令。被测的车机软件接收到指令后，通过截屏指令，抓取ROI区域的图像显示数据，一般为RGB或者YUV格式。
图像识别与对比：编写自动化测试脚本，台架软件首先从车机软件获取截取的ROI图像数据。然后它使用图像识别算法对抓取的ROI截图与预先存储的标准ROI图像进行比对，判断图像是否符合设计要求。
执行测试脚本：执行自动化测试脚本，模拟用户在智能座舱中的操作，并在执行过程中对界面进行截图，将截图与标准图像进行比对。如果比对失败，则判断测试fail，图像失效。
分析与报告：根据比对结果，分析图像失效的原因和影响范围，并生成测试报告。根据测试报告的结果，修复软件中的问题，并进行再次测试，直到达到预期的测试结果。

通过自动化测试验证图像失效的关键在于定义准确的图像识别规则、采集全面的ROI图像、编写稳定可靠的自动化测试脚本、执行测试并正确地分析测试结果。

三、持续集成与交付

3.1 自动化编译框架

在智能座舱软件中，分为上层应用软件和底层软件。有些上层应用软件是与指令集平台无关的，例如Java应用程序等，它们对所运行的CPU平台没有依赖性，可以很好的适配当前平台进行执行。而在底层软件，包括操作系统，驱动程序，乃至中间件等，都与CPU指令集架构强绑定。

智能座舱域控制器所使用的SOC各有不同的指令集架构。有些SOC的CPU是x86架构，其余大部分是ARM架构。在SOC上运行的操作系统和底层软件，需要采用适应本平台的指令集进行编译，得到可运行的二进制代码。获得这些软件的二进制执行程序的过程，称为编译。

编译的过程如下图所示，C代码源文件(.c)通过编译器，生成二进制目标文件(.o)。所谓的.o文件只是编译过程中间所生成的过渡性文件。多个.o文件通过链接器，链接生成可执行的二进制映像文件(.axf)。这个二进制映像文件包含了执行代码(.bin)和可供调试分析的debug信息(.txt)。

在程序开发阶段，.axf文件是软件工程师调试分析问题所必不可少的；当软件成熟并可进行发布以后，去除.txt 调试信息，只保留.bin 执行代码就可以了，这样可以节省大量的程序存储空间。

对于大量使用ARM架构的座舱SOC来说，在PC机上进行程序开发，生成二进制映像程序后再下载到SOC上运行是非常自然的行为。这其中的原因在于PC机软件上具有大量的IDE(集成开发环境)软件，对于程序员非常友好。而在ARM 机器上，通常只能使用命令行工具来对软件源代码进行编辑、编译，并且执行效率也远远不及PC机或者服务器。因此，这种在A机器进行代码编辑和编译，生成二进制执行程序后运行在B机器上的行为，称为交叉编译。

座舱SOC所使用的操作系统，无论是Linux，QNX，还是Android，都提供了完整可用的交叉编译工具链。以Android为例，它主要包含：

arm-linux-androideabi-gcc：这是用于编译ARM架构下C代码，生成目标文件(.o)的编译器。
arm-linux-androideabi-ld：这是用于将编译后的目标文件(.o)链接成可执行文件的链接器。
arm-linux-androideabi-as：这是用于将汇编代码编译生成目标文件的汇编器。
arm-linux-androideabi-g++：这是用于编译C++代码的编译器。

以上这些工具程序，包含在Android开发包NDK (Native Development Kit) 中。它们是一些二进制的可执行文件，通常会被IDE或者命令行输入的命令所调用。事实上，这些编译工具链由ARM公司提供。

自动构建系统

一个可用的智能座舱软件平台，通常包括成千上万的源代码程序。这些.c, .cpp, .s 源代码文件，按逻辑功能划分，放置在不同的目录结构下。那么如何才能方便快捷地通过一个操作命令，就能编译生成所需的可执行文件呢？操作系统的开发者(既包括Google等商业公司，也包括Linux社区等开源项目)，早就准备好了对应的自动构建系统。

GNU Make：GNU Make是基于Makefile的构建工具，它通过编写Makefile脚本来描述构建过程。它支持多种操作系统和编译器，但由于是Unix系统的传统工具，在一些非Unix系统上可能会有兼容性问题。在Android 7.0之前，Google使用GNU Make来管理自动编译和构建。
CMake：CMake是开源的跨平台工具系列，可以用于构建、测试、打包软件，支持多种操作系统和编译器。它通过编写CMakeLists.txt文件来描述构建过程。
Clang/LLVM：LLVM则是一个独立的开源项目，提供了可扩展的编译、链接等工具链，支持多种平台和架构。它包括Clang等编译器，提供了LLDB等调试器，还提供了编译、链接等工具链。因为是开源项目，所以有一些独立的CPU研发项目会使用LLVM来构建自己的交叉编译工具链。
Ninja：Ninja是一个轻量级的构建系统，使用Ninja文件作为构建脚本，专注于提高构建速度。在Android7.0之后，Google认为 GNU Make编译缓慢、容易出错、不可扩展且难以测试，因此引入了Ninja构建系统，该系统通过.ninja文件实现了Android构建系统的灵活性，因为.ninja文件是人类可读的。
Soong：Soong是Android平台上的构建系统，用于编译和管理Android源代码。它使用Makefile作为构建脚本。在Soong编译系统中，每个模块都有一个相应的.mk文件，其中包含了该模块的编译规则和依赖关系。Soong读取这些.mk文件，并按照其中的规则和依赖关系生成.ninja。对于复杂的.mk文件(如Android.mk)，Soong还会使用到一些工具来辅助编译过程，例如kati和ckati工具可以将.mk/Makefile文件转换为.ninja文件。

Android自动化编译框架

既然智能座舱使用的操作系统以Android，QNX，Linux为主，而Android无疑是最为复杂，且变化最快，迭代最多的系统，那么我们将以Android为例，简要讲述其自动化编译架构：

使用Kati工具，从复杂的Android.mk或其他Makefiles生成out/build-aosp_bluejay.ninja文件。
对于简单的Android.mk文件，Soong会生成Android.bp；而后生成out/soong/build.ninja文件。此外，还会生成一个较小的out/combined-aosp_bluejay.ninja文件，负责将两者连接起来，作为执行入口。
最终，Ninja文件是真正直接控制源代码编译的工具，负责生成apk、aar和dex文件。APK的签名也是使用ninja规则完成的，然后完成这一切后，会创建*.img文件。

对于Android命令行工具来说，要编译完整的可执行文件，只需要输入如下3步命令：

运行source build/envsetup.sh : 该命令执行envsetup.sh脚本，可以设置Android产品的各函数，例如lunch就是生成的shell函数。
选择lunch选项：执行envsetup.sh中生成的lunch()函数，用于构建映像文件和其他构件(apk, jar, so等)的环境，以适配多项目的需求。每个项目都是lunch()函数的一个参数。
运行make <module-name>或m <module-name>

在Android N之前：

m或make命令相当于make -f build/core/main.mk（通过GNU make构建）

在Android N之后：

m或make命令相当于build/soong/soong_ui.bash -make-mode，这意味着soong_ui.bash是Android平台构建系统的核心。

3.2 持续集成

概念

持续集成 (CI, Continuous Integration) 是指在开发人员将代码频繁地提交到版本控制系统后，通过自动化构建、测试和部署操作，及时发现并解决代码错误，以保证软件的稳定性和可靠性。

持续交付 (CD, Continuous Delivery) 则是在持续集成的基础上，通过不断地自动化流程，实现软件交付过程的自动化，以优化软件交付的时间，并减少人为错误，提高软件的质量和可靠性。

步骤

汽车软件全景图对持续集成所包含的内容总结如下图：

图片来源：汽车软件全景图(2022)

而持续集成的核心，集中在代码提交之后的自动化测试流程上。

典型的持续集成流程，大致可以总结为以下步骤：

代码提交 --> 触发持续集成流程 --> 提交前测试 --> 自动构建 --> 代码提交

代码提交：通常需要使用强大的代码管理软件，比如，在Linux环境下，许多公司都采用了git系统。一些常用的代码管理工具还有SVN，ClearCase等。
提交前测试：在多人协作的开发环境中，有些公司的持续集成策略规定：每一个工程师在提交代码前，系统都应自动执行静态代码检测和预编译功能。静态代码检测通常会选用优秀的工具，对新增代码的逻辑调用关系，参数设置，内存分配，语法规范等进行扫描，如果检测出问题，则本次代码提交即被终止。这样可以有效避免多人协同工作时，由于单个人的疏忽而影响到整个系统的及时交付。
自动构建：系统调用自动编译命令，生成可执行的程序。并通过自动化测试平台，将程序下发到被测试车机中进行自动验证。
代码提交：当自动构建顺利通过后，新代码才会真正提交到代码仓库中。代码管理工具会为提交操作生成记录和确认依赖关系。

持续集成工具

持续集成常见的工具有：