chetanvashistth I build software.

The Technical Walls of Running Linux on an Android Phone

I tried to turn an old Android phone into a minimal Linux feature phone. Boot, display, touch and Wi-Fi work. The modem, VoLTE and audio routing are where you hit the wall. Here are the six walls, in order.

I am using Android for 15 years now and every 2.5 years on average I am buying a new phone. I have more than 6-7 Android phones that are with perfectly working hardware but these are old, slow, and low on battery and memory.

So I thought about building a minimal Linux based phone OS that can do basic functions of a phone — make it like a feature phone. Because even 1 GB of RAM and 32 GB of ROM is great for a terminal kind of UI.

I had some plans for an open source project around this idea (we shall discuss that some other day — the idea is not dropped completely). While working on it I faced some serious setbacks and hit the wall.

These are the walls.

A monstrous Android robot towering over a ruined city, with a sign reading Apps, Data, Privacy, Your Life

A note on the hardware: the Google Pixel 4a shows up throughout this post. It is my research and development device — one of the handful of phones where mainline Linux boots far enough to actually study these problems. Nothing here is a product. The walls are the story.

Wall 1 — The mainline kernel gap

Android phones do not run the standard Linux kernel. They run a heavily modified, vendor-specific fork of Linux — sometimes years behind the mainline kernel, with thousands of patches specific to that chipset and that phone.

PostmarketOS and similar projects have done remarkable work porting specific phones to mainline Linux. For a handful of devices — the Google Pixel 4a is one of them — mainline Linux boots with working display, touch, and Wi-Fi.

But “boots” and “everything works” are very different things.

On the Pixel 4a running mainline Linux today:

The modem is in the device. The SIM is in the device. The network is there. But the driver path from the kernel to the modem is either incomplete, broken, or dependent on firmware that was never upstreamed.

Wall 2 — The modem is a black box

The cellular modem in a modern Android phone is not like a Wi-Fi card. It is a separate processor running its own proprietary firmware, with its own operating system, communicating with the main processor over a private interface — QMI, MBIM, or a vendor-specific protocol.

To use the modem from Linux, you need all five of these to work together:

  1. A kernel driver that speaks the modem’s interface
  2. A userspace daemon (ModemManager or oFono) that speaks the protocol
  3. The modem firmware loaded correctly at boot
  4. The carrier APN configured correctly
  5. All of the above agreeing on network registration

On Qualcomm chips — which is most Android phones — the modem interface is QMI (Qualcomm MSM Interface). The kernel driver (qmi_wwan, rmnet) is in mainline. The problem is that it does not work on every Qualcomm phone just because the driver exists. It needs firmware blobs, the right device tree configuration, and often device-specific patches that have not been merged upstream.

Cellular data (internet from the SIM) is the easier modem problem. No call audio, no IMS, no real-time constraints — just establish a packet data connection.

Voice calls are a completely different category of difficult.

Wall 3 — Voice calls in 2026 are not what they were in 2006

In 2006, a voice call was circuit-switched. The network set up a dedicated channel, audio went over it, call ended, channel torn down.

In 2026, on most networks, voice calls are VoLTE — Voice over LTE. Voice goes over the data network as IP packets, like a WhatsApp call, except it is the regular cellular call system.

VoLTE requires:

The IMS stack on Android phones is a vendor blob — a binary shipped by Qualcomm or MediaTek, implementing carrier integration, not available as open source.

Linux has open source IMS implementations. They are incomplete for carrier use and largely untested on real hardware.

The result: on almost every Android phone running mainline Linux, you can boot the OS but you cannot make a phone call.

Wall 4 — Audio routing is a separate nightmare

Even if the modem could handle a call, the audio still has to go somewhere.

On Android, audio routing is handled by the Audio HAL (Hardware Abstraction Layer) — a vendor blob that knows the exact wiring of the audio codec on that specific phone: which microphone is which, how to switch between earpiece and speaker, how to handle Bluetooth audio during calls.

On mainline Linux, audio uses ALSA or PipeWire/PulseAudio. The codec driver may or may not be upstreamed. The routing configuration has to be written by hand, device by device.

On the Pixel 4a specifically:

This is not an edge case. The same Bluetooth mic problem exists on sibling Qualcomm devices — the OnePlus 6 with the same WCN3990 chip has an open, unresolved postmarketOS issue where the Bluetooth headset mic does not work at all, while the same headset works on a PinePhone.

The practical consequence on this device: you can hear audio over Bluetooth but you cannot record from the microphone.

Wall 5 — The vendor blob problem

Android’s hardware stack is held together by HALs. There is one for audio, one for the camera, one for cellular, one for sensors. These are compiled binaries, shipped by the chipset vendor, specific to the Android version and the phone model.

Projects like Halium and libhybris let Linux systems call into these Android HALs — a compatibility shim that translates Linux calls into Android HAL calls. This is the pragmatic path: use Android’s own driver knowledge from a Linux userspace.

The tradeoff: you are now dependent on the vendor HAL. If the vendor does not update it, you are stuck. If the phone is discontinued, the HAL may stop working as the ecosystem changes.

For voice calls specifically, the Android RIL (Radio Interface Layer) is the most complete implementation of carrier-compatible voice for these chipsets. Using it via Halium is currently the most realistic path to working calls on a recycled Android phone running Linux.

Wall 6 — Every phone is different

None of the above is uniform across devices.

What works on a Pixel 4a may not work on a Samsung Galaxy with the same chipset. What works on one carrier in India may not work on another.

Getting Linux to fully work on an Android phone is not a problem you solve once. It is a per-device, per-carrier, partially-solved set of problems that the open source community is chipping away at, one device at a time.

What actually works today

Works well on mainline Linux on supported devices:

Works with effort and device-specific work:

Why it is still worth doing

Google’s hold on Android is not primarily about the OS kernel. It is about services — Play Services, the Play Store, account systems, push notifications, and the ecosystem of apps that depend on all of the above.

The hardware works fine without Google. The kernel works. The question is whether the hardware abstraction layer — the part that makes the radio, audio, and camera work — can be made open.

The answer is: slowly, yes. One device at a time. One subsystem at a time.

The Pixel 4a in 2026 can run mainline Linux, connect to Wi-Fi, browse the web, SSH, and play audio over Bluetooth. A year ago it could do less. A year from now it may be able to do more.

That is the actual pace of progress on breaking out of the Android hardware lock.

#architecture#open-source

← All posts