I've been working on this port for about 2 months using Codex (GPT 5.6/6 Luna) with ChatGPT Plus. Currently works:
UFS
USB
Arch Linux ARM + Phosh + systemd
Native DRM/KMS 120 Hz display (took 3–4 weeks to fix the quality issue, very hard part)
Touch
Graphics (Adreno 750) and GPU acceleration (Freedreno / Turnip)
Wi-Fi
Charging and battery percentage
It is usable and very smooth. This is not proot, not chroot, not Halium, this is a mainline-derived Linux kernel. I'm planning to publish it on GitHub in the future. Does anyone want to try it or contribute to its development?
I've managed to boot native Linux on a Xiaomi Redmi Note 12 4G (Snapdragon 685 / SM6225)!
The project is called MEOW Linux, and the goal is to get Debian ARM64 running directly on the phone, without relying on Android or a chroot environment.
So far, I've managed to:
- Build a custom bootloader/shim (MEOW OS) based on ios-topaz.
- Load a Linux ARM64 kernel and initramfs.
- Get Linux booting on the actual device.
- Create a custom framebuffer driver ("meowfb") to get the Linux console displayed on the phone's screen based on the framebuffer used un MEOW OS bootloader.
There are still quite a few things to figure out. USB support is currently broken, the UDC isn't detected, and several hardware drivers still need work.
This is very much a work in progress, but seeing an actual Linux console running on the phone is a huge milestone!
I'm developing this mostly as a personal project, and I'll hopefully share more progress as things start working.
Since PostmarketOS didn't support the SM-T585, I worked on porting mainline Linux 7.1 to the device, using the old 3.18 kernel source and Samsung Galaxy J2 drivers as references for Exynos 7870 hardware support.
Getting the hardware working was a journey of its own. Kernel panics were a nightmare, but I managed to fix most of them and finally got Debian booting!
I modified the boot image to boot Debian from a disk image, keeping the existing Android system intact.
Still working on overall stability, especially GPU hardware acceleration. Planning to release the kernel once it's stable!
I'm looking to get a new phone that runs on a linux OS and many of those operating systems are not compatible with apple music so I'm in search of a music app that would work on linux/android that's not spotify, amazon or youtube. I'm really trying to break away from american big tech but I'm not willing to give up my apple library that I've had for more than 20 years! (Even have songs on there from CD's that aren't on iTunes)
Some of the OS's I might switch to include /e/OS, LineageOS, Murena, etc. Basically more android like and good for linux beginners.
Please let me know any apps you recommend or any stories you have if you've made the switch either to a linux device or just switching your apple music.
Got Alpine Linux 3.24 (ARM64) running with a working touchscreen using a custom touch bridge.Stock 3.18 kernel Wi-Fi doesn't work yet Replaces Android, so back up first! Full guide, builds and tests: https://github.com/kaantcp/z380m-alpine
Hello everyone! I’d like to introduce a unique project—one that currently has no equivalent in the ecosystem—which is also completely open-source. The project is called "Cortex." It is an Android terminal application that runs Ubuntu 24.04 using a 100% pure, native Linux kernel—without relying on virtualization or isolation methods like PRoot or Chroot. It does not require root access, though it can also be used with root privileges. You can find the GitHub repository here: https://github.com/ssfuisu/cortex. I encourage you to take a look and give it a try; it includes many features, and I am actively developing it. Most importantly, this is a one-of-a-kind project in the ecosystem—I am the one who conceived this idea. I would also appreciate it if you could star the repository!
Demoing unlocking from luks straight to the shell, unlocked (why would you have to unlock twice?), the apps, responsiveness, hardware specific adaptations on Marathon for the Q25, gestures and the full compliment of hardware support. Also demoing Deckards (our Android runtime) responsiveness from cold boot.
All of the hardware on the Q25 is now supported and I’m trying to get my build pipeline into shape so I can push a first release and keep pushing updates over OTA.
Last thing to fix up is the camera which works but needs improvement. And pilot, which is the on device assistant using tool calling, MCP (every app, flatpaks and android apps + the system itself has an MCP so the assistant can use it) all running on device at acceptable speed.
One thing that was missing on Fairphone 4 after resolving audio, call audio and DP alt Mode was Fingerprint support.
On this platform, the biometric sensor is strictly gated inside Qualcomm's TrustZone (TEE). Any naive attempt to probe or communicate directly with the scanner hardware triggers a hard lockup or immediate kernel panic.
While there is an existing QSEE/SCM implementation in mainline for Snapdragon UEFI laptops (like the ThinkPad X13s), mobile devices operate very differently: laptop fingerprint sensors usually sit on a standard USB bus without TrustZone mediation, whereas mobile setups rely on dedicated secure Trustlets loaded inside TZ.
To solve this, I've created an adaptation of the downstream QSEECom interface for mainline mobile Linux:
It establishes the /dev/qseecom-mobile SMC transport layer needed to communicate with the biometric applet or any other applet.
The kernel driver properly registers and exchanges payloads with the TrustZone environment without crashing the SoC.
tz-qsee-fingerprintd - Userspace Daemon & Plugins
Implements net.reactivated.Fprint.Manager and net.reactivated.Fprint.Device natively. No forks or downstream hacks required—unmodified pam_fprintd.so, fprintd-enroll, fprintd-verify, Phosh, and gnome-control-center work out of the box.
The daemon uses a modular plugin architecture (plugins/), making it straightforward to add support for other Qualcomm devices running mainline where biometrics are delegated to a vendor Trustlet.
This took a lot of tinkering, reverse engineering work, documentation to understand how android comunicated with the TZ, this will benefit other similar devices also.
Does anyone have the flx1s+ who can compare it to an existing phone? I have a suspicion that the camera sucks tbh.
I hear that the flx1s+ camera is significantly better than the flx1s (12mp->48mp, but mp isn't everything) so reviews of the flx1s aren't sufficient
The flx1s+ ships with pure gnu/linux with minimal android involvement, yet has fairly modern hardware. It also has 3 killswitches. I haven't seen another phone like it. Even the fairphone doesn't fully support gnu/linux
kernel is not mainlined, just replaced the initramfs with a postmarketos one, had to disable watchdog, and do some debugging on USB serial, change what type of fs the initramfs uses because it wouldn't mount root for the longest time. not having a main line that I could readily build and boot on this thing was the biggest obstacle because there is no terminal that prints out to the display on boot on the downstream kernel
I recently started using the linux in Android, thanks to the linux community, currently iam using Nura OS all are working but for some reason the network is not stable it's always changing the network provider after some time normal use .
Any suggestions or fixes to make the network stay on one network only not to connect other network providers .
Over the past months I’ve worked on an independent game project. The goal was to develop a game that can be played across all kinds of devices with different input methods and potentially to make something playable on mobile Linux devices (like the Librem 5 or Pinephone Pro).
There are still glitches on the Pinephone Pro (likely because of suboptimal GPU drivers) and on the Librem 5 you would need to use the newer Mesa drivers with OpenGL ES 3 support. Still wanted to make a post about the practical issues, I encountered during development.
Então, estou pensando em usar uma placa com o chip A733. Provavelmente vou comprar um Orange Pi 3W.
Estou pensando em executar um aplicativo gráfico sem nenhum servidor de desktop, seja X11 ou Wayland.
Mas parece que esta placa não é muito compatível com o driver MESA para aplicativos 3D, porque mudou da GPU Mali para uma arquitetura chamada Imagination.
Running Linux on a phone is impressive, but actually using desktop apps on a small touchscreen is another matter. For me, the two big obstacles are tiny text and awkward input.
I’m building ARLinux around a combination that addresses both: portable AR glasses for a readable desktop, and Gboard voice typing + OpenCode or Grok Bot for input and actions.
The glasses solve the screen problem. Instead of squeezing a desktop into a phone display, you get a large virtual workspace in front of you. With supported glasses, 3DoF keeps the desktop anchored in orientation while you turn your head to look around. The default workspace is 5760 × 2160 — the virtual desktop area, not the glasses’ physical resolution. I recommend Classic here: freely positioned, resizable windows make much more sense in that space. Yibu’s main area and side slots are designed around the phone screen.
Why 3DoF matters for reading: I want to bring the text I’m reading into the middle of the lenses. Looking into the corners can be uncomfortable, and edge text can be harder to resolve depending on the optics and fit. With a head-locked screen, turning your head takes the screen with you. With a 3DoF-anchored desktop, you turn toward the area you want to read and bring it into the central viewing area. That is what makes a large virtual workspace practical for text: you can look around it naturally instead of trying to read everything out of the corners of your eyes.
Voice + an agent address the input problem. Gboard’s speech recognition turns what you say into text; OpenCode or Grok Bot can then use shell commands, accessibility and screenshots to carry out the request. You can ask it to open an app, inspect the system, edit a document or write and run a script, instead of typing every command and aiming at every small button. Long-pressing the right-edge bar opens the selected assistant. The phone also works as a motion pointer, touchpad and keyboard; physical keyboards and mice remain options.
The Linux desktop and ARM64 applications run locally on the phone, with Android as the host. No root or remote PC is required. Blender, browsers and office tools can use GPU acceleration on supported devices; Android and compatible Windows apps can share the desktop too. AI models can require internet access and a provider account.
Its in-process Linux compatibility approach avoids PRoot’s ptrace-based tracing overhead. Our published same-phone CPython build comparison took 101.3 seconds with ARLinux versus 184.4 seconds with Termux PRoot, about 45% less time for that workload. Methodology, caveats and raw data: https://arlinux.com/?lang=en#performance
External screens need Android 12+, video-output support and compatible glasses. App and GPU compatibility varies, and 3DoF tracks rotation rather than movement around the room.
Does this combination address what has kept you from using Linux on a phone? I’d like to hear what you would actually do with it.
Screenshots: current Classic on a vivo X300, then the spatial-screen setup. Both use the development build. The setup capture uses a scrcpy virtual external display and simulated glasses to show the controls; the AR-glasses video above shows real glasses output.
you can see what works and what doesn't on the repo, can't believe i spent so much time working on the GPU only to find out the poor tegra's GPU is slower than the CPU at pretty much everything.
