Editing Android 8.1 on the RP2 (section)

=== Why Won't the Update Let Us Run All Apps That Require Android 8.1? ===

The version of Android that a device uses is not the only limiting factor that can prevent a particular app from running. There are other concerns such as memory, storage space, and hardware features. For many Android emulators, the RP2's GPU will still be a barrier to working. Many more advanced emulators, and especially those for more recent systems, require a GPU that supports at least OpenGL ES version 3.1.

The RP2 is built around a MediaTek MT6580 system-on-a-chip. This includes a quad-core Cortex-A7 CPU and a Mali-400 series GPU.

The Mali-400 series of GPU designs were released in 2008, and were only ever intended to support OpenGL ES 2.0 at best. The OpenGL ES 3.1 and 3.2 specifications were published in 2014 and 2015 respectively, and Vulkan even later. While OpenGL and Vulkan are software standards (APIs), they are standards for translating from a common graphics language to actual instruction codes that can be interpreted by a particular GPU. That means that there isn't a generic "OpenGL ES 2.0" app that can easily be upgraded or replaced. Instead, there is a device driver (similar to those in a desktop computer's operating system) which has been written specifically to translate between OpenGL ES 2.0 and the Mali-400's internal instruction set.

Here's our first hurdle: that driver is closed-source. ARM wrote it and maintained every version of it themselves. There is an effort to create open-source drivers for Mali GPUs, but for the Mali-400 series, they have stopped at supporting OpenGL ES 2.0. There's a reason for that.

Our second hurdle is that the Mali-400 series GPUs simply don't offer most of the functionality that later versions of OpenGL ES (or Vulkan) expect.

Think of our GPU as a robot arm that paints cars. We own a car factory, and we bought the robot arm (GPU) from an agency that also sent a trained operator (the device driver) along with it. But a few years later, various companies start making robot arms that can both paint and weld. We want our robot arm to do that, too. But the operator doesn't know anything about welding, so we can't even explain to them what we want the robot arm to do.

Someone sat down and figured out how to work the robot arm without the original operator, so now we could, in theory, train our own operator (write our own device driver) who does understand welding (later graphics languages) as well as painting. However, our robot arm (GPU) still doesn't have any welding attachments. We could try to strap a welding rig to the arm (emulate the unsupported new functionality in software), but we'd have to pull additional workers off the line (use CPU time) to make that work. In fact, it would almost certainly take more workers to make this happen than the size of our current welding team (we'd end up with worse overall performance than just sticking with our existing workload split between CPU and GPU).

An updated version of Android would be like restructuring the employees at the factory. Some older employees are retired, some underperforming employees are let go, and some new people are hired. But that won't change the fact that our robot arm (GPU) just wasn't built to do welding (support newer graphics APIs).