Mishaal Rahman / Android Authority
TL;DR
- Android 16 adds support for running media codecs outside of their usual sandboxed process and within the app’s process.
- Doing this reduces the amount of inter-process communication that needs to typically happen between the app and codec process, thereby reducing CPU usage and thus power consumption.
- However, this opens the door to security exploits, which is why codecs need to be written in a memory-safe language like Rust for this to be allowed.
Whenever your Android device plays any kind of media, such as songs or YouTube videos, the operating system spawns a number of complex, independent processes to ensure the media is played back securely. This is done to mitigate vulnerabilities that take advantage of malformed media files or insecure media codecs, such as the infamous Stagefright vulnerability from several years ago. While Android’s media file handling is now much more secure, it is also inefficient, which is an issue that a new feature in Android 16 aims to solve.
You’re reading an Authority Insights story. Discover Authority Insights for more exclusive reports, app teardowns, leaks, and in-depth tech coverage you won’t find anywhere else.
A codec is a software algorithm that defines how digital audio or video data is compressed or decompressed. Prior to Android 7.0, the entire media framework was encapsulated in a single, monolithic process that held a lot of sensitive permissions. Because codecs were included, a vulnerability in their media file processing could allow an attacker to escalate privileges.
With Android 7.0, Google hardened the media framework by splitting it into several different processes, each requiring a much smaller set of permissions. Codecs are now run in their own, sandboxed codec process that communicate with other media and app processes using Binder, Android’s inter-process communication (IPC) API. Because the codec process is sandboxed, the impact of vulnerabilities is limited to that sandboxed process. This architectural design reduces the likelihood of another Stagefright-like bug.
Android’s mediaserver architecture.
While more secure, this architecture results in lower performance due to the repeated use of IPC calls. A music streaming app, for example, must make IPC calls to the codec process to pass encoded data and retrieve decoded data. The more IPC calls that need to be made, the higher the CPU usage. Although this only has a small impact on the best Android phones, it’s still worth improving media playback efficiency, especially since it’s such a common user activity.
That’s why Android 16 adds support for in-process software audio codecs, a feature that allows media codecs to run within an app’s process instead of within the usual sandboxed media codec process. Android 16’s MediaCodecInfo class now includes a getSecurityModel() method, returning either SECURITY_MODEL_SANDBOXED (standard sandboxed process) or SECURITY_MODEL_MEMORY_SAFE (in-process operation). The in-process operation, though potentially risky, is deemed safe because the codec’s software implementation is written in a memory-safe language like Rust.
Mishaal Rahman / Android Authority
While Android 16’s documentation on this new feature is brief, Google has been developing it for several years. A source tells me that Google presented this feature at the 2023 Mainline Summit, a private event where it shares changes to Project Mainline modules.
Google’s primary motivation for this feature, as revealed in the presentation, is to enhance AAC codec performance and reduce power consumption. The company estimated that up to 50% of the CPU cycles spent on decoding and encoding content in AAC was due to inter-process communication. Therefore, switching to in-process codecs will improve AAC decoding and encoding efficiency. To address security concerns, Google wants these in-process codecs to be written in a memory-safe language like Rust and not C++.
My source tells me that Google originally planned this feature for Android 15, but the company delayed it to Android 16. While Android 16 does support the feature, it’s not actually in use yet. This is due to the need for codecs to be rewritten in Rust by vendors. Testing the new Android 16 APIs on my Pixel 9 Pro, I found all media codecs still utilize the sandboxed approach.
Mishaal Rahman / Android Authority
Thus, while Android 16’s new in-process software audio codecs feature should theoretically bring better performance and battery life when playing back media, it’s likely we won’t see these benefits for quite some time. Hopefully Google and codec vendors can collaborate to rewrite many popular codecs in Rust so that we can see the benefits of this new feature in the future.
