Android has entered the world of embedded devices starting form mobile phones, spreading to IoT and to TV. The next important member of the Android ecosystem is the car, and this is bringing a set of interesting new partners to the ecosystem. Following this trend RT-RK has started a partnership project with the SoC vendor Telechips, with a goal to develop and evolve an IVI platform based on the Android Automotive OS. The idea of the project is to allow the Telechips’ team to focus on development of the core automotive related technologies for the IVI system, while our teams need to enable efficient and fast integration of the solution in the Android operating system.

Targeted hardware

The targeted hardware is Telechips TCC805x (Dolphin3) Smart Cockpit Solution. TCC805x (Dolphin3) processor family is a 14nm ideal SoC, targeted at IVI/Cockpit and ADAS, built on extensive market knowledge accumulated over a decade of Telechips’ leadership in the IVI/Cockpit processor business. The Telechips’ roadmap is composed of strategic Pin-to-Pin PKG to cover from an entry to a high-level Cockpit. TCC805x is aimed at Automotive Cockpit, Cluster, and the Infotainment system with flexible design based on Arm® Cortex®-A72 Quad core and Arm Cortex-A53 Quad core.

TCC805x provides great performance of a 2D/3D graphic engine for a rich and vivid GUI with Imagination PowerVR Series9XTP Core and supports hardware virtualization for Hypervisor-Less Cockpit (HLC) solution. Not only does TCC805x support multi-display and multi-channel camera input, but it also embodies Image Signal Processing sub-system and MICOM sub-system in support of isolated safety island.

Scope of work

To prove readiness to follow a strict tempo of the Android evolution, each SoC vendor needs to prove a significant level of platform stability to Google, in an early stage after an official Android release. This happens via presenting Android xTS results with a high pass level (~90%). For this project, the goal is to execute a migration from Android 12 to Android 13. The effort in bullets:

• Upgrade the framework code from Android 12 to Android 13
• Migrate the Android kernel from version 5.4 to version 5.10
• Migrate all necessary Telechips’ drivers
• Update the drivers to a version compatible with Android 13 (primarily GPU drivers)
• Implement missing HAL modules on top of the Telechips’ drivers

Timeline

When launching a commercial device with Android, the timelines defined by Google, although demanding, are very reasonable (around 2 years). However, when approaching the matter from the SoC vendor perspective, this effort is on a critical path for the whole ecosystem. The SoC is the first stop after Google that needs to enable the rest of the ecosystem to access the latest Android release.

The first Android 13 release was rolled out end of November 2022, and now the SoC vendors are under pressure, both from Google and OEMs, to make their chipsets accessible to the rest of the Android ecosystem.
The common expectation is that the first drops of BSP with Android 13 become available in 3-5 months (in case of this project Q1 2023). In general, there are three types of release definitions in this process:

• Integrated Build – Functional version with features missing, can be buggy, etc.
• Compatible Build – Build passing the xTS suite, with known issues to add/fix
• Approved Build – Build passing all needed tests and running with acceptable quality

Phases of execution

This project is broken into phases across different levels of the software architecture:

1. Upgrading framework layers
2. Upgrading kernel
3. Enabling new drivers/features

Most of the effort in the project is focused on proving proper functionality of the 3 lowest layers with the rest of the framework coming directly from the AOSP repositors.

Android framework upgrade

The schedules enforced by Google may seem hard, but it is important to understand that there is a significant effort being invested to make this transition undergo smoothly.
One of the critical aspects is Android Common Kernel backward compatibility guarantees. In practice this means that Google is building framework in a way which maintains backward compatibility with the older versions of the kernel. The table below shows the status for Android 13:

This means that that the current framework for Android 13 should be able to run and launch (with limitations for new features) completely on Android 12 Kernel version 5.4. This sums up the project’s first goal – to enable the Telechips’ devices to run Android 13 on the already existing Android 12 kernel version 5.4

This action point involves:

• Update of 1132 software repository coming from the Android project
• Re-apply of the Telechips’ modifications on 20 repositories
• Integration of the Telechips’ device with Android 13 upgrade
• Execution of CTS (Compatibility Test Suite) on the created build

Kernel upgrade

Once the previous step provides satisfying results, the next step is to upgrade the kernel version from version 5.4 to version 5.10. This means merging code from two sources: Android and Telechips’ Linux branch.

This step gets validated through execution and the results of VTS (Vendor Test Suite).

New driver implementation

Android 13 brings several new features that require modifications and upgrades on the hardware level integration layer. Here is a short overview of the affected modules:

• Audio HAL
• Camera HAL
• EVS HAL
• Hardware Composer HAL
• Power HAL
• Vehicle HAL

Validation

The metrics for validation of compatibility with the latest release is simple; it is necessary to successfully pass these 3 test suites:

• VTS – Vendor Test Suite
• CTS – Compatibility Test Suite
• STS – Security Test suite

Vendor Test Suite implies extensive testing of the kernel and Hardware abstraction layer (HAL).
This proves the readiness of the core underlaying software components to support all the necessary software features of the targeted Android release (13 in our case). The test suite covers over 350 software modules evaluated using over 500.000 unique automated tests.

Compatibility Test Suite

The main goal of this test suite is to confirm compatibility of the behavior of the tested device with the Android operating system requirements; in other words, that device can run any Android compatible application without an issue.

The CTS includes the following types of test cases:

• Unit tests – test atomic units of code within the Android platform; e.g. a single class, such as java.util.HashMap
• Functional tests – test a combination of APIs together in a higher-level use-case
• Robustness tests – test durability of the system under stress
• Performance tests – test performance of the system against defined benchmarks, for example rendering frames per second

This test suite covers over 380 software modules, evaluated using over 600.000 unique automated tests.

Security Test Suite

This test suite checks if the devices apply all the latest security patches. Since we are targeting the very latest Android version, zero issues are expected in this run.
This test suite consists of around 600 test.