Image credit: analognowhere.com

The state of Android modding, and some tangential thoughts.

Android modding is as old as Android itself. Ever since the HTC Dream, the first device to run the operating system, Android has had a thriving modding scene. From escalating privileges on the vendor OS, to replacing the whole OS with a customised version (“custom ROMs”), Android modding has quite the history (a history that I will not get into now, maybe another time).

However, many companies don’t really like Android modding. This is in large part due to Android locking things down by default in ways that suck for the user but are quite convenient for certain application developers as it can help enforce DRM, or stop mobile gamers from just cheating in money in blatantly pay to win games (I don’t care who you are, if the game is purely singleplayer and is pay to win as hell then it’s perfectly ethical to cheat in a bunch of money to even the odds).

So of course, they started fighting back! But how exactly? Let’s get into that, shall we?

Google SafetyNet/Play Integrity

Google develops Android, and thus controls most of its “security” systems that conveniently make life a pain in the ass for modders. By far the most prominent measure the company has implemented comes in the form of the now deprecated SafetyNet Attestation API, and its successor, the Play Integrity API.

The specifics are somewhat contrived, but the tl;dr of it is that it’s an online anti-tampering scheme. The verification is done by passing cryptographically-signed messages between your phone, Google’s servers, and the server of the application developer. Any sort of tampering, such as gaining root access or flashing a custom ROM, causes the attestation process to fail. Should that happen, the Play Store will hide applications from the storefront (individual application developers can choose to hide their applications from the storefront should a device fail attestation), and several applications such as Netflix or various banking apps will refuse to run on your device.

Put even more simply, this is basically kernel anti-cheat for a single player game, but for the whole OS. And unfortunately, it’s effective. I don’t know about you, but I’ve lost count of the people who said they’ve only withheld from modding because of something they used that required these checks to pass. These checks manage to deter the majority of people from modding their phones and claiming their God-given right to use the hardware they bought as they please. Instead this induces apathy. “Why bother if I’ll lose all these things?” There is also a level of induced social pressure here. Sure, you could mod your phone, but if you lose access to all that stuff everyone around you uses, you’ll be left out.

But of course, not everyone is happy with just this. Introducing…

Samsung Knox

This is both better and worse than Google’s “solutions”. Knox doesn’t have an online component, instead it relies on an eFuse inside the phone. When you unlock the bootloader, the eFuse gets blown, permanently marking your phone as “tampered”, voiding your warranty and blocking you from using some Samsung services. Thankfully, Knox is only used by Samsung to verify integrity for their own services. Most other applications won’t know or care about the blown eFuse, and if you run a custom ROM there won’t even be a way to check for it.

The legality of voiding the warranty is… questionable. This is basically a fancy warranty seal, and those have been declared legally unenforceable in courts, however this is just different enough that you are unlikely to get your phone fixed/replaced under warranty without taking things to court, at which point it’s cheaper to buy a new phone.

That said, this is assuming you even can trip Knox. If you live in the US, it’s far more likely you’ll run into the other, even bigger “fuck you” Samsung and many other OEMs often opt to use, and that is…

Permanently locked bootloaders

This is probably the moment I should explain what a “locked bootloader” is in the context of Android.

During Android’s boot process on most phones, the first thing that loads is the bootloader. This is quite different from the bootloaders you might be used to on your computer, in that Android’s bootloader is the very first thing to load on power up. There’s no BIOS, no UEFI, no Coreboot, the bootloader is directly loaded, and then it loads the OS.

The bootloader also won’t load just about anything. By default, the bootloader is “locked” to only boot up the vendor’s original, untampered firmware. Should you want to either modify or completely replace that firmware, you will have to unlock the bootloader. The exact procedure depends on the vendor, but the important thing is that sometimes it’s not even possible.

If you have a phone from Huawei, Nokia, or a US models from Samsung (among others), then you can’t unlock the bootloader and are stuck with the OEM’s firmware.

How things are getting better

Despite all the efforts to actively hinder modding, Google has also made it quite a lot easier than during what most would consider the Golden Era of Android modding, during the days of CyanogenMod, kind of.

In Android 8, Google introduced “Project Treble” with the goal to make it possible for the same Generic System Image (GSI) to run on multiple phones just as well. This still left a lot of issues unaddressed, with some devices able to run a GSI only after flashing a device-specific custom kernel on top, but the Generic Kernel Image (GKI) project helps solve that issue by further separating the hardware-specific parts of the OS, with all device drivers shipped as loadable kernel modules as opposed to being baked into the kernel (y'know, how literally everyone else, including Linux itself have been doing for many years; better late than never I guess).

GKI 1.0 only really happened on devices shipping Linux kernel 5.4, and GKI 2.0 on devices shipping Linux 5.10. Unfortunately, lots of devices are still shipping with older kernels (My Galaxy A34 released in 2023 shipped with Linux 4.19, released in 2018, a full five years earlier), so you might not get the benefits of this if you buy a phone today. That said, this is still good in the long term, not only for Android modding but also for people looking to run proper mobile Linux on their phones and ditch Android altogether. And even for existing devices, some of them might see modders strip the device-specific bits from the vendor kernel and package them to be loaded by a GKI, although I don’t expect that to happen for anything but the most popular of devices.

Things can still get better

In truth, the fact Android is cutting its ties to hardware, allowing you to run generic images on a wide variety of devices is good, but it’s not enough. At the end of the day, it’s still Android with all of its bad, ugly, and outright evil. It’s not a true victory until we can flash an actually alternative OS, but things are looking bright there too. Mobile-focused Linux distributions have already been riding on Project Treble to help support more hardware, and GKI is likely to make things even easier for users and developers alike. We’re not there yet, but mobile Linux with widespread hardware support is in sight.