1. Foreword - The car war under the ebb tide of mobile Internet
Going back to 2017, when I just graduated from university, the mobile Internet had already started to ebb, and all major training institutions also stopped Android-related training. Since then, the once-hot application development has started to go downhill. , Small programs and many cross-platform frameworks have also reduced the market demand for Android native development year by year, and the reduction in market demand has also created an unprecedented "volume" of interviews for Android development.
Finally, I chose to leave the Internet in 2019, and devoted myself to the in-vehicle Android field, which was not very hot at the time, and continued to engage in native Android development. And this year, China's first wholly foreign-owned vehicle manufacturing project, the "Shanghai Tesla Super Factory", started construction.
Tesla's huge advantages in intelligence and electronics pushed smart cars to a whole new level. The advanced automatic driving and BMS battery management system deeply shocked people all over the world. In the eyes of Chinese people at that time, Tesla La is almost synonymous with new energy vehicles. Today, Model Y and Model 3 are still the best-selling models in the field of new energy vehicles.
As we all know, the automobile industry is an important economic pillar of developed countries, and China is the world's largest automobile production and sales country. Tesla's hot sales immediately triggered a catfish . , the automobile industry is moving towards the era of software-defined automobiles. The core idea of software-defined cars is that software technology with artificial intelligence as the core determines the future of cars, and the importance of car software in the automotive field has been raised to an unprecedented height for the first time, so a vigorous car software technology war has been staged .
2022.10.17 Another article was updated, some content was deleted, please refer to: https://blog.csdn.net/linkwj/article/details/127398839
2. Basic structure of smart car cockpit
Before engaging in the development of in-vehicle Android applications, it is necessary to have a general understanding of the basic structure of the car cockpit. Only when we realize that the car cockpit is a completely different structure from that of mobile phones can we better help us learn about in-vehicle Android applications in the future. develop. Let's introduce a more mainstream in-vehicle operating system architecture.
Note: Not all in-vehicle operating systems use the following architecture. For example, Tesla uses a Linux-based architecture.
The above is the technical architecture adopted by the current mainstream car cockpit. We will introduce it from top to bottom:
T-BOX
T-Box, also known as TCU (Internet of Vehicles Control Unit), refers to the embedded system installed on the car to control and track the car. It is the core component of the vehicle information interaction system. The role of the gateway. Usually includes GPS unit, mobile communication external interface electronic processing unit, microcontroller, mobile communication unit and memory etc.
For vehicles, T-Box can provide vehicle fault monitoring, power management, remote upgrade, data collection, smart transportation and other functions. For car owners, T-Box can provide functions such as vehicle remote control and security services.
T-BOX belongs to the peripheral hardware, and is not integrated with the central control and instrumentation on the same motherboard.
SOC
There are various definitions of SoC, and it is difficult to give an accurate definition because of its rich connotation and wide application range. Generally speaking, SoC is called a system-on-chip, also known as a system on a chip (System on Chip), which means that it is a product, an integrated circuit with a dedicated target, which contains a complete system and all the content of embedded software.
The car Soc is very similar to our most common mobile phone Soc, which integrates CPU and GPU. At present, the most mainstream car Soc is Qualcomm's SA8155, which is developed by Qualcomm on the basis of the mobile phone Soc Snapdragon 855.
MCU
Microcontroller Unit (MCU), also known as Single Chip Microcomputer (Single Chip Microcomputer) or single-chip microcomputer, is to appropriately reduce the frequency and specifications of the Central Processing Unit (Central Process Unit; , counter (Timer), USB, A/D conversion, UART, PLC, DMA and other peripheral interfaces, and even LCD drive circuits are integrated on a single chip to form a chip-level computer.
Generally, in the cockpit of a car, one or more MCUs will also be integrated on the motherboard integrating the SOC.
AutoSAR
Adaptive AutoSAR is a software architecture platform suitable for advanced autonomous driving. It provides high-performance computing and communication, flexible software configuration, and supports application updates.
The main architecture of Adaptive AutoSAR is divided into hardware layer, ARA (AutoSAR Run-timeFor Adaptive real-time operating environment) and application layer.
The application module (AA) contained in the application layer runs on top of the ARA, and each AA runs as an independent process. ARA consists of application interfaces provided by functional clusters, which belong to the Adaptive Platform. The adaptive platform provides the basic functions and standard services of Adaptive AutoSAR.
Each AA can initiate services to other AAs. Based on this architecture, the functions of the vehicle can be decoupled.
Hypervisor
An intermediate software layer that runs between the underlying physical server and the operating system, allowing multiple operating systems and applications to share hardware. It can also be called VMM (virtual machine monitor), that is, a virtual machine monitor.
At present, mainstream car cockpits run two different operating systems on one SoC at the same time, one is the QNX system for displaying the car dashboard, and the other is the Android system for in-vehicle infotainment. The underlying technical principle is Hypervisor.
QNX
QNX is a commercial Unix-like real-time operating system that complies with the POSIX specification. The target market is mainly for embedded systems. It has the characteristics of high operating efficiency and high reliability. It has nearly 40 years of experience in the field of industrial control and is widely used It is used in fields with high safety and real-time requirements such as automobiles, rail transit, and aerospace.
QNX has a market share of more than 75% in the car operating system market, and more than 60% in the car entertainment system that pays more attention to ecology and content. In the field of dashboards and driver assistance that emphasize safety, QNX's market share is even higher. Reached nearly 100%.
In 2010, QNX was acquired by Canadian RIM Corporation, which is the parent company of BlackBerry.
SOA
SOA (Service-Oriented Architecture) is a coarse-grained and loosely coupled service-oriented distributed architecture based on business implementation, which not only realizes the separation of business and technology, but also realizes the free combination of business and technology.
Taking location services as an example, many in-vehicle applications use location information, such as weather, photography, and navigation. These applications have different needs according to their own services, and they process location information differently. SOA can solve this problem very well. question.
SOA was originally a technology used in server development, and is now also used in the field of vehicle operating systems. However, the current technical specifications for SOA are confusing, and there are differences in the implementation of SOA between domestic and foreign host manufacturers.
SOA is not necessary for the vehicle operating system. In fact, few of the models that have been launched so far have adopted the SOA architecture, so it is only a future development direction of the vehicle operating system.
In 2021, SAIC Zero Beam will be the first to release the industry's first vehicle-mounted SOA software architecture specification. W6, a subsidiary of WM Automotive Technology Group, claims to be the first domestic mass-produced car using SOA.
Automotive Ethernet
Vehicle Ethernet is a new type of local area network technology that uses Ethernet to connect electronic units in vehicles. Unlike traditional Ethernet that uses 4 pairs of unshielded twisted pair cables, vehicle Ethernet can achieve 100Mbit/ s, even a transmission rate of 1Gbit/s, and at the same time meet the requirements of the automotive industry for high reliability, low electromagnetic radiation, low power consumption, bandwidth allocation, low delay, and synchronous real-time performance.
Automotive Ethernet is designed to meet some special needs in the automotive environment. For example: meet the requirements of vehicle equipment for electrical characteristics (EMI/RF); meet the requirements of vehicle equipment for applications such as high bandwidth, low latency, and audio and video synchronization; meet the needs of vehicle systems for network management, etc. Therefore, it can be understood that on the basis of the civilian Ethernet protocol, the vehicle Ethernet has changed the electrical characteristics of the physical interface, and customized some new standards in combination with the vehicle network requirements. For the automotive Ethernet standard, the IEEE organization has also made corresponding supplements and revisions to the IEEE 802.1 and IEEE 802.3 standards.
CAN
CAN is the abbreviation of Controller Area Network (CAN). It was developed by German BOSCH company, which is famous for R&D and production of automotive electronic products, and finally became an international standard (ISO11898). It is one of the most widely used field buses in the world. In North America and Western Europe, the CAN bus protocol has become the standard bus for automotive computer control systems and embedded industrial control LANs, and has a J1939 protocol designed for large trucks and heavy machinery vehicles with CAN as the underlying protocol. In recent years, its high reliability and good error detection ability have been valued, and it is widely used in automotive computer control systems and industrial environments with harsh ambient temperatures, strong electromagnetic radiation, and large vibrations.
CAN is widely used in vehicle operating system & application development. One of the core services of vehicle Android - CarService is essentially to parse external hardware communication messages into data that can be recognized by upper-layer applications. The communication messages here are generally CAN message.
CAN communication is so widely used in vehicles that as Android programmers, we have to learn the use of CAN simulation test tools, and sometimes we even need to read and parse CAN messages.
It is worth mentioning that the CAN simulation test tools are very expensive. Although there are domestic alternatives, various tools and software produced by the German company Victor are still widely used, and the prices range from tens of thousands to hundreds of thousands.
3D HMI Design Tool & Embedded Graphics Engine
With the improvement of on-board SoC computing power, modern cockpits increasingly prefer to introduce 3D graphical interfaces, which can generate animation feedback in real time, greatly improving the aesthetics and ease of use of the interface. At present, the mainstream 3D HMI design tools & graphics engines in vehicle development include old-fashioned game development tools such as Unity 3d and Unreal (Unreal), as well as Kanzi, which is dedicated to automotive HMI design & graphics display.
In 2016, Finnish automotive software company Rightware and its product Kanzi were acquired by domestic automotive software provider Thundersoft.
The above introduces the basic knowledge of the car cockpit. Android application programmers are responsible for controlling and writing various types of applications in the cockpit. Next, we will introduce the differences between in-vehicle applications and Internet applications.
3. Vehicle application development
In the final analysis, the car Android application is to embed a series of system-level applications in the car Android system, including HMI applications that interact with users, and Service applications that run in the background without HMI.
Generally speaking, the complexity of in-vehicle applications is lower than that of general Internet applications.
Common vehicle applications with HMI include vehicle air conditioners, multimedia applications, desktops, SystemUI, system settings, car control devices, Bluetooth phones, and some third-party applications.
Applications without HMI include CarService, AudioService, AccountService and so on. In the development of in-vehicle applications, a large number of services need to be customized, which is also a relatively large part of the workload in application development.
3.1 Differences between system-level applications and common applications
System applications need to be embedded in Android ROM to run. Although ordinary applications can also be embedded in ROM, system applications can call the internal API of Android SDK, which cannot be done by ordinary applications. Generally speaking, system applications have the following features
- Can access the API inside the Android SDK
- No need to apply for dynamic permissions
- Configurable auto-start
- App must be signed
Next we actually write a system-level application by hand.
3.2 Writing a system-level application
Writing an Android system application is basically the same as an ordinary Android application. We first write a demo in AndroidStudio, and only need a blank Activity and Application.
public class DemoApp extends Application {
private Handler handler;
@Override
public void onCreate() {
super.onCreate();
Log.e("TAG", "onCreate: start");
handler = new Handler(Looper.getMainLooper());
handler.postDelayed(new Runnable() {
@Override
public void run() {
showView();
}
},5000);
}
private void showView(){
WindowManager manager = getSystemService(WindowManager.class);
View view = new View(this);
WindowManager.LayoutParams params = new WindowManager.LayoutParams(WindowManager.LayoutParams.MATCH_PARENT,WindowManager.LayoutParams.MATCH_PARENT);
params.type = WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY;
manager.addView(view,params);
}
}
The above application logic is very simple, 5 seconds after the app starts, a full-screen Window pops up.
Next, register the application in AndroidManifest.xml.
<?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>
In the above source code we need to pay attention to two properties that are not used by ordinary applications: the name of the Linux user ID that will be shared with other applications. By default, Android assigns each application its own unique user ID. However, if you set this property to the same value for two or more apps, they will share the same ID, provided they have the same set of certificates. Apps with the same user ID can access each other's data and, if desired, run in the same process. When developing system applications, this item is not required to be configured. After configuring as , the application will become a system user and can access some spaces that system users can only access.
android:sharedUserIdandroid.uid.system
android:persistent
Configures whether the application should always keep running, defaults to false. When set to true, the application will start itself before the boot broadcast is sent, and it will restart immediately after the application is killed.
When developing system applications, this item is not required to be configured.
3.3 Test System Application
3.3.1 Prepare the test environment
It is more troublesome to test the system application. Since there is no development board at hand, it can only be tested based on the emulator, so it is necessary to download the Android source code and use the Android source code environment to compile an APK with a system signature.
To download and compile the Android source code, please refer to: Android Automotive Application Development and Analysis (1) - Android Automotive Overview and Compilation
After compiling the Android source code, we will copy the compiled FirstCarApp part of the source code to /aosp/packages/apps/Car/,
The app project structure based on the Android source code environment is completely different from the AndroidStudio project structure based on Gradle. The directory structure is as follows:
You should have noticed that there is no main/java in the androids studio project structure in the src directory. What
needs to be emphasized is that this native-based writing method is not commonly used. In actual development, we still complete the development in Android Studio, submit the source code to gerrit, and Jenkins will help us complete the subsequent compilation, signing, and copying processes.
3.3.2 Compile & run the application
To compile an Android application in the source code environment, you need to write an Android.bp or Android.mk script. If you don’t know Android.bp or Android.mk, please refer to: Android.mk Getting Started Guide | Android.bp Getting Started Tutorial
The Android.bp script used in this test is as follows
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,
},
},
}
Then compile the Android source code once
# 编译Android源码
/aosp$ source build/envsetup.sh
/aosp$ lunch 12
/aosp$ make -j 32
/aosp$ emulator -writable-system -netdelay none -netspeed full
Under normal circumstances, we can directly use the emulator command to start the compiled emulator, but at this time the file system of the emulator is still in read-only mode, and the remount command cannot be executed, by adding -writable-system -netdelay none - netspeed full, we can use the remount command normally.
/aosp$ adb root
/aosp$ adb remount
/aosp$ adb shell reboot
After the emulator restarts, we continue to compile the apk of CarFristApp.
link@link-PC:/aosp$ make CarFirstApp
...
## 编译后输出的apk路径
============================================
[100% 4/4] Install: out/target/product/generic_car_x86/system/priv-app/CarFirstApp/CarFirstApp.apk
#### build completed successfully (2 seconds) ####
Then use the adb command to create a CarFristApp directory in the emulator, and push the compiled apk to the system/priv-app/CarFristApp/ directory.
/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
After waiting for the emulator to restart, you can see that the app will start by itself, and then a WindowView will pop up to cover the screen. I don’t know if you have noticed, whether it is self-starting or popping up a window that covers the screen, there is no window to apply for permission. This is an important feature of system-level applications.
In the above operation, we choose to push the apk to priv-app. In addition, Android applications also have the following installation paths, which can be installed in different directories according to actual needs. This path stores some underlying system applications, such as Setting, systemUI, etc. The app in this directory has higher system permissions, and if you want to use it , then the app must be placed in the priv-app directory.
/system/priv-appandroid:protectionLevel=signatureOrSystem
/system/app
The system app permissions stored in this directory are relatively low, and when you have root permissions, it is possible to uninstall these apps.
/vendor/app
This directory stores the app of the vendor manufacturer
/data/app
Third-party apps installed by the user
3.4 Difficulties in Vehicle Applications
In the process of vehicle application development, the following difficulties are often encountered:
-
Debugging is time-consuming and labor-intensive.
In-vehicle application development is actually not very difficult, but it is annoying! Especially debugging, different from mobile phone application development, the operating environment of vehicle application is customized based on AOSP, and most of the time there will be countless bugs, sometimes the bugs at the bottom of the system will be reflected in the upper application, which requires application development The author must be able to accurately identify the attribution of this bug. -
Complicated UI
Today's in-vehicle applications will have a complex and cool interactive UI. At the same time, because the in-vehicle Android and QNX share a Soc and memory, most of the time the system resources are much worse than mainstream mobile phones. For developers, it is often very challenging to implement a set of complex and high-performance HMI. -
Insufficient understanding of the system API
Most of the time when developing an in-vehicle application requires re-customizing an existing application in the original system, such as system settings. This requires developers to have a certain understanding of the operating mode of native applications and the APIs they call.
4. Prospects of in-vehicle Android development
After reading the above content, I believe you already have a basic understanding of the development of in-vehicle Android. I don’t know if you think I am advising you to switch to car Android development? The answer is NO!
A simple Android application engineer can only be responsible for a very small technical field in the vehicle cockpit, which has already determined the development height of this profession. If you want to break through this ceiling, you must go deep into the bottom layer of the Android system and master the Framework , HAL and even some operating principles of Native. In addition, Linux and car-related knowledge also require additional learning.
For now, the development of in-vehicle Android still has a good prospect, but it is far from reaching the popularity of the mobile Internet, and it may not even be achieved in the future. The influx, the reshuffling of the automobile manufacturing industry, and the change in the relationship between supply and demand, one day it will inevitably go downhill.
I once regretted entering in-vehicle development, because compared with mobile application development, the knowledge required to learn is too much and complicated, and the debugging process is also more complicated than mobile application development, but why not spend this life in regret?
References
Smart cockpit: intelligent basic platform and architecture (Part 2)
Analysis of the status quo of China's T-BOX industry in 2020, the assembly rate of passenger car T-Box is rapidly increasing "Figure" Vehicle operating system (3): The first
intelligent cockpit operating system
The integrated HMI tool built by the advanced smart cockpit——Kanzi One released
Automotive | Android Open Source Project | Android Open Source Project
Automotive Ethernet - Electronic Paper