Android has been around since 10+ years now, mainly as smartphone Operating System. It is the most popular phone OS as of today. The popularity is because of its user friendliness, reliability and the availability of variety of apps. It has also gained popularity from the developers as well. Android is open source, comes with several open source licenses.
There has been a lot of experiments and efforts to bring Android as an operating system for the Infotainment devices. From Google, as well as from the car makers(OEMs). There are few OEMs who took one version of Android(AOSP), customized it for their car variants, and released it as the infotainment OS. The effort was appreciated but there were few downsides as they did not have collaboration with Google. Android was not up-gradable to new Android releases from Google. If the OEM has to provide Android update, then they have get the latest AOSP, customize it again, add the ‘on the top’ modules and release it. This Android can not have Google’s play store, instead the OEMs host their own store. Developers have to use the OEM’s SDK to develop the apps. Users can’t use any of the services from Google.
Android could not reach as much in the Car Infotainment area, until recent years. In 2017, Google announced that it is partnering with Volvo and Audi to develop Android based IVI devices. When there is support from Google, Android can be updated to the latest releases of Android. Since Android N, Google came up with Android Automotive. By the way, not to confuse this with Android Auto; Android Auto is only an interface on the Infotainment device(Head Unit), which allows the phone to be connected to the Head Unit and allows access to the phone on the Head Unit. On the other hand, Android Automotive is a module which provides access to the Car Data, which is embedded in the IVI device along with the Android OS.
When Android runs on a phone, it has to interact with a set of hardware modules. Example; GSM, WiFi, Bluetooth, Microphone, Speakers(Ear piece and loudspeaker), Gyroscope, Accelerometer, Vibrator, Battery module, etc to name some. But when Android runs on an Infotainment device, it has to interact with a different set of hardware interfaces. It may not need GSM module (If no phone calls directly from the head unit), Speakers(Ear piece and loudspeaker), Gyroscope, Accelerometer, Vibrator, Battery module, etc., but it may need 4G module, WiFi, Bluetooth, more than one microphone. In addition to these, the head unit must have interface to in-car networks. i.e; CAN (Controller Area Network), MOST(Media Oriented System Transport), LIN(Local Interconnect Network), Automotive Ethernet, etc. CAN is the protocol or the network used inside the car since decades. Most of the car data comes through CAN bus. The head unit is connected to the CAN gateway in the car. The head unit should get these data, interpret them, and do associated actions. When the user wants to change some car data, for example, the temperature, the device should send this data on the CAN. MOST is used for media, especially to interact with the Amplifier. LIN is used to control the body-control electronics, like the mirrors, wipers.
So, an additional low level modules have to be running on the Android IVI device, like the CAN driver for CAN network. Linux has been a popular OS in IVI since a very long time, so integrating CAN driver is not a big task, as Android has Linux at the native level. Then, Android’s framework needs handlers / providers to exchange data between the upper and lower layers. Android Automotive provides these modules. The newly added Hardware Abstraction Layer (HAL) is called as Vehicle HAL. Below is the Vehicle HAL architecture from Android developer website
Using Android on a Car Head Unit is different than using it on a Phone. Google has also worked on customizing the UI and changing it as per the needs of a driver. e.g; more focus on voice based interactions.
Real Challenges
The real challenges have been several.
First of all, the boot up time. When Android runs on a device, it takes some time to boot up. Example, Reboot an Android phone. It takes a while until the phone becomes fully usable. But it is not a good idea to have a head unit in the car which takes a while to get going once the ignition is turned on. The head unit is expected to run fully functional as soon as the ignition is turned on. The Embedded Linux systems boot up quite fast compared to Android systems. To replace the existing systems, Android has to meet their boot up time.
The boot sequence of an Android system is as follows. Initially, the boot rom starts, which is a small piece of code that is hardwired in the CPU ASIC which loads the primary bootloader, x-loader. Primary bootloader which initializes memory and loads the bootloader from the storage or ROM such as flash memory or memory card or even through serial connection, depending on the system architecture. Bootloader does memory and peripheral initialization and loads kernel. Kernel is the main component here, this involves uncompressing the kernel, initializing the processor, initializing the platform, etc. Kernel also mounts file system and runs the first userspace process “init”. “init” is a key component (refer to init.rc. There are 2 init.rc’s. init.rc and init_<machine>.rc). Android has a different booting pattern from here. Unlike traditional Linux systems, Android has its own boot sequence once the init is loaded. The daemon processes like surfaceflinger, audioflinger and started at this point. Then the Zygote starts, which is the first process in the java world. Zygote processes are forked from init. The daemon processes provide native system functions, such as display, and audio. Zygote, the parent for all Java processes including the system server initializes (ART VM) and preloads some classes and drawable resources, which are shared in all Java processes. When the Zygote process completes, the system server is created and starts all Java system services and launches the system UI and the launcher app. Finally,the home screen is shown, signifying the end of the boot procedure. Once the surfaceflinger starts running, until the user sees the system UI, the android boot animation is shown on the screen. Now the challenge is to optimize this whole sequence.
Flash/storage wearing out. When Android persists the data, it writes it into the flash. In a day’s use, in an Android phone, the on board flash is accessed multiple times. Whenever user updates the persisted data (e.g; change in settings)or whenever a new data arrives to an app which has to be persisted or when a sync happens, the old data is erased and new data is written into the internal flash or internal storage. Life of a flash chip is limited. Whenever the system writes into a segment in the flash, it is actually reducing the life of that particular segment. When the storage segment is written over and again, in a long run the segment becomes not usable anymore. In simple words, it becomes corrupt. So as the number of segments get corrupt, available internal storage goes on reducing. Life of a mobile phone is around 3 years. Users usually go for a new phone in 3 years time or even less. But, life of a car is 10 –15 years. May be more. So the device in the car is expected to run for 10 –15 years without any problem. Flash wear out can be a major problem. It can reduce the amount of available storage over the period of time. Reduced flash size may affect the performance as well. Sometimes, the system may behave abnormal, which is not expected in a (soft) real time system like a car head unit. It would be strange to drive a car with a corrupted Infotainment device or it could be additional expense for a car owner to replace the system once in every couple of years.
(User does not reboot his phone often, but in a car, head unit is rebooted every time the ignition is switched off and on, because of this, some data has to be persisted on every ignition cycle)
Response time. In a device like Car head unit, the responses from the apps and system UI are expected to be very reliable. There should not be delay in the touch response or App launch response. Since the introduction of ART in Android, the response time to load any app has improved, but some apps may still take time to load if the app has a lot of data to load. Some may have dependency over internet.
Googlemaps challenge. Googlemaps is Google’s one of flagship products. On the other hand, Googlemaps are not considered to be automotive grade. The accuracy provided by Googlemaps (as of today) is not considered to be reliable in a moving car. Car makers still use navigation products from other vendors like Telnav, Garmin, Tom Tom, etc.
Play store challenge. Automotive playstore can not be same as the normal playstore. Reason being, any types of apps can not be allowed on a car head unit. The car makers will have to have a separate store or a different way to handle these apps. When the car makers do not have support from Google, then they have to host their own app store, have their own sdk, and then not all developers can develop apps for the cars of these car makers.
General Android behavior. This is about Android behavior. When an Android device is turned on after few hours, it will immediately connect to the wifi and start looking for updates. When the updates are available, it will start downloading them. This behavior can not be shown in a head unit. This will considerably slow down the system. Such a behaviour can be annoying to the driver, where he is in a hurry to drive but the head unit is updating itself. The updates should be allowed only in certain scenarios like ‘Garage mode’.
Additional modules. In addition to standard Android modules, Car head unit needs extra implementations to control HVAC, Radio, Heating, Seat Control, Windows, etc. These are on top of the regular AOSP. Google has come up with Vehicle HAL, which supports some of the features.
Android UI. A Car display unit definitely needs a different UI than phones. It would be a safety concern for the driver to look for the small icons on the screen while driving. So the whole system UI needs a better look and feel.
Garage mode. This is a special mode in Automotive Electronics, which provides special behavior. This is used in the workshop. In this mode, the device should provide additional interfaces, access to special data and Diagnostic Trouble Codes of the car. Garage mode should be like a super user mode where it can provide special access to the system.
Internet Security. Security is a main concern in an automotive device. If a phone is hacked, user may lose his data, or money. But if the automotive system is hacked, it is quite dangerous for the life.
Latest Updates in Android P
In Android P, Google has made a lot of changes in the low level. HIDL (Hardware Interface Definition Language) has been introduced. This makes Android P different from the previous versions of Android, at the HAL(Hardware Abstraction Layer). It makes it different, at the same time, it makes it easy when someone wants to add a new hardware module to the system. It is definitely done by keeping Automotive market in mind. This is a welcoming move in the Automotive Android community.
Rear Seat Entertainment
Rear seat entertainment(RSE) is also IVI, for the rear seat passengers. This can be one device or a set of devices. Since Android has started occupying this space, Car makers have been coming up with multiple devices in this area. If we go back in time and look at the RSE from 2009, BMW X6 has one unit controlling multiple screens. Since Android has entered this space, Car Makers have come up with RSE with multiple devices. 2 separate Tabs for each rear seat passenger, Android remote control, a center main unit, etc. All these run independently on Android running on board. Challenges in these devices are not as much in the Head Units. These also run with Automotive grade Android, but they do not have to follow strict guidelines as the Head Units. For example, it does not matter if the RSE is not yet running, as soon as the ignition is ON. If the storage flash gets worn out in the RSE Tab, the Tab can be replaced. So, developing an RSE is not as challenging as developing a Head Unit.
Future
Android seems to be getting its traction in the Automotive world lately. In Android P, Google has made a lot of changes keeping the Automotive market in mind. This is a good development. So, it would be possible that Android takes over the Car Infotainment if the above said challenges are rightly addressed.
OEM — Original Equipment Manufacturer
