Editing Android 8.1 on the RP2

__TOC__

== Downloading the Update ==

(September 2020) The update is not yet available. According to the manufacturer's announcement, we are expecting the update to be released by October 25th, 2020.

== What to Expect ==

While changing to Android 8.1 will bring some welcome new features to our RP2s, it won't be a major game-changer in terms of emulation speed, stability, or options.

Anyone who has experienced a major update with an Android device in the past will know that it can be a very mixed bag. Every new version of Android brings new features and security enhancements to your old hardware. However, those same new features and enhancements also come with new requirements and limitations for the way that apps can work. Often, when we upgraded an old device, or bought a new device, we found that some of our favorite apps stopped working properly. If the developers never updated their app to work with the new version of Android, it usually meant that we simply couldn't use that app any longer. If we were lucky, we could find an alternative.

Fortunately, while Android 8.1 is newer than the Android 6.0 that the RP2 currently ships with, it's still an older version in 2020, and so most apps have already been updated to work correctly with it, if they are still actively maintained. But that doesn't mean that every Android 8.1 app will run on the RP2.

=== 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).