Android as a complete OS solution involves a lot of moving parts. Very broadly speaking, these parts are the app ecosystem and then the OS itself. As a developer, your programming language of choice varies depending on what part of Android you are working on. For app developers, Java and Kotlin are popular options. For developers working on the OS and the lower levels within it, C and C++ have been popular choices so far. Today, Google is adding a third option for OS developers, as the Android Open Source Project now supports the Rust programming language for developing the OS itself.
Limitations of C and C++
Lower levels of the Android OS require systems programming languages like C and C++. These languages provide developers with control and predictability, which is important when accessing low-level system resources and hardware.
Unfortunately, C and C++ fail to provide memory safety guarantees, making them prone to bugs and security vulnerabilities. The developer is responsible for managing memory lifetime on these languages, but in complex and multi-threaded codebases, that is easier said than done.
C and C++ together constitute tens of millions of lines of code on the Android platform. These memory safety bugs become the most difficult-to-address source of incorrectness of code, representing ~70% of Android’s high severity security vulnerabilities. Merely fixing these bugs becomes insufficient to deal with the issue, and a better approach would be to prevent them in the first place.
The lack of memory safety guarantees forces developers to run Android processes within tightly constrained and unprivileged sandboxes. But sandboxes are expensive on resources, consuming additional overhead and introducing latency. Sandboxing also doesn’t eliminate the code’s vulnerabilities entirely, and its efficacy is reduced because of high bug density, further allowing attackers to chain multiple vulnerabilities.
Another limitation, though not unique to C and C++ but applicable to all memory safety issues, is that the erroneous state must actually be triggered in instrumented code in order to be detected. So even if your code has excellent testing, the actual bug may stay undetected. And when bugs are found, getting them fixed is another task, involving a long and costly process that may not always lead to a correct fix. Thus, bug detection becomes unreliable, and bug prevention is the better approach to take in light of these limitations.
This is where the switch to a memory-safe language like Rust comes into the picture.
