Last year Alibaba T-Head reported that the basic features of Android had been ported onto RISC-V-based Xuantie cores. Since then more effort has been spent on Android 12 and enabling third-party modules to support video, camera, and Wi-Fi/Bluetooth features based on RISC-V. Specifically, we have focused on incorporating high-performance RISC-V processors onto Android 12. In this update we will also provide some insight into building TensorFlow Lite models on RISC-V-based cores. Building these AI models with software stacks can accelerate the integration of RISC-V into smart terminal products.
Support for RISC-V in Android 12
The support for RISC-V in Android 12 is implemented based on Android 10.
Figure 1 Support for RISC-V in Android 12
In the upper box, the green blocks represent the modules that can be upgraded to adapt to Android 12 with minimum changes required. These modules are: tool chains, build support, Google Chrome, and system libraries. The light yellow blocks are the new features of Android 12 with RISC-V, including Bazel, Rust, and Android studio. The dark yellow blocks indicate the Android Runtime (ART) and Bionic modules relating to the architecture. They are very different from those in Android 10. The red blocks show the vendor modules that are irrelevant to the CPU architecture. They are audio, video, camera, and other peripheral modules.
Bazel is a new build system introduced by Android 11. It replaces the blueprint support in Android 7. Rust is a new native development language introduced in Android 12. It performs with higher security without reducing the overall performance. Changes are made in configurations, constraints, crates, and the C standard library API to enable RISC-V to support these build infrastructures.
Some major changes are made to Android 12 so that ART and Bionic are compatible with RISC-V. The changes related to ART involve Nterp and the ART module. Using the same call constraints as the compiler, Nterp can save costs of stack transitions. The modularization of ART compresses ART-related sub-modules into a single .capex file, which is decompressed and loaded during system initialization.
Figure 2 Updates in ART
The new version of Bionics, with it’s dynamic distribution of indirect functions (IFUNCs) and with its hardware capabilities, can bind the IFUNC handler to a specific assembly-optimized implementation. Other changes include generation of dynamic system calls, new relocation types, and updates of the kernel header files. In total, these changes involved modifying almost 20,000 lines of code in more than 100 GitHub repositories.
Figure 3 Android 12 on RISC-V
Running TensorFlow Lite on RISC-V
In addition to the changes in the Android Open Source Project (AOSP), we also improved and configured the demo app of TensorFlow Lite to execute on RISC-V-based cores. The NDK/SDK (windows version) is also integrated into Android Studio in support of RISC-V ABI APKs.
First, we add RISC-V build support to the TensorFlow Lite project. We then compile the installation package with Android Studio. Then, we integrate the hardware accelerator and Hardware Abstraction Layer (HAL) of the neural network so that user application calls of Neural Networks API (NNAPI) can be supported.
Once that is complete, we can install the demo app of TensorFlow Lite for execution onto Android. The following figure illustrates the demonstration of super-resolution on Android. In this example, the image resolution can be increased from 50 × 50 to 200 × 200. The lower image resampled by using bicubic is lower quality than that of the upper image using TensorFlow Lite.
Figure 4 An example of Super-resolution comparing to illustration by bicubic
Integration of Vendor Modules
In the past year, we successfully integrated several key features into Android. They are audio and video playback, DRM hwcomposer, Wi-Fi/Bluetooth, and USB OTG.
Figure 5 Challenges in vendor module integration
There are three major challenges we encountered: poor support for RISC-V, incompatibility, and lack of verification. For example, the default media codec and executable files of media playback services cannot be generated based on the 64-bit architecture. The data objects and header definitions provided by vendors may conflict with those of Android. In addition, some exceptions may occur in the initialization of hardware OMX service due to unverified source code on RISC-V.
Milestones
The following figure shows the four phases establishing the infrastructure of a RISC-V-based product certified by Android.
Figure 6 Milestones in porting Android onto RISC-V
The basic features of Android 10 were ported onto RISC-V-based Xuantie cores last year. Since then we are able to improve Android on RISC-V with module integration of Android 12. The next planned milestone of enhancement is upstream code merger. To accomplish this goal, we have set up a plan with clear workflows and lessen the effort of patch development:
Figure 7 Plan for merging upstream code
Meanwhile, we plan to continuously improve compatibility and reduce errors by fixing the test case failures in compatibility and vendor test suits. With refinement for Android 12, patches for external projects can be directly submitted to third-party open-source projects for code integration, while other patches related to the core components of Android must be submitted during the development window of a new version.
By the release of Android 13, we plan to rebase the support for RISC-V with minimum changes. The refined patch set of the core components for RISC-V would be ready for submission by the development window of Android 14.
Summary
The support of Android 12, vendor modules, and AI framework is another key milestone in porting Android onto high-performance RISC-V-based GUI devices. While more effort is required to improve code integration in support of RISC-V, we are confident that upstream code merger will bring better compatibility and far fewer errors. We look forward to delivering high quality products with more ported features in the future.