DEV Community: A. Ababa

Fix: Linux PC Wakes Up Instantly After You Suspend It

A. Ababa — Thu, 13 Aug 2026 05:43:49 +0000

The Problem

You hit suspend. Screen goes black. A second later, it's back on, showing the lock screen. Every time.

This isn't random, and it isn't just your machine being weird. Something in your hardware is sending a wake signal the moment the system tries to sleep, so the kernel just does what it's told.

This Is a Known, Recurring Bug

This exact issue has been reported for years across Arch, Ubuntu, Fedora, Linux Mint, and Unraid, showing up on laptops, desktops, and even AMD B550 and X670E motherboards. It's been discussed on the Arch forums, Ubuntu's bug tracker, Linux Mint forums, GitHub issues, and even the kernel.org bug tracker itself. An AMD kernel engineer has confirmed it's a long-standing hardware quirk rather than a new bug, and it just started showing up more clearly in logs after kernel 5.17.

So if you're stuck on this at 1am, you're not the only one, and it's fixable.

What's Actually Causing It

Two components are responsible for almost every case:

1. Your NVMe SSD's PCIe port
Your NVMe drive sits on a PCIe root port that has "wake-up" enabled by default. Sometimes that port sends a wake signal, called a PME, and it gets stuck "on" instead of clearing properly. The next time you suspend, the kernel sees that stuck signal and immediately wakes the system back up.

2. Your USB controller (xHCI)
Check your logs, and if you see something like this right after a failed suspend, this is your culprit:

xhci_hcd 0000:02:00.0: xHC error in resume, USBSTS 0x401, Reinit

That means your USB controller couldn't cleanly suspend, so it had to restart itself. This is common with wireless mouse and keyboard dongles or USB touchscreens.

Both problems look identical from the outside, since either one causes the same pattern: suspend, then instant wake, every time.

Step 1: Confirm What's Happening

Before fixing anything, check what's actually going on.

Check if it's really an instant wake:

journalctl --since "10 minutes ago" -g "PM:|resume|suspend"

Look for a suspend entry immediately followed by resume lines, within a second or two of each other. If you also see xhci_hcd and USBSTS mentioned, that's your USB-side clue.

Check which PCI devices can wake your system:

grep -l enabled /sys/bus/pci/devices/*/power/wakeup

This usually points to one PCIe bridge, and that's your suspect.

Find which PCIe port your NVMe drive sits on:

lspci -tv | head -30

Look for your SSD in the tree, then note the address just above it, something like 00:01.1.

Confirm that port has actually fired a wake signal:

cat /sys/bus/pci/devices/0000:00:01.1/power/wakeup_count
cat /sys/bus/pci/devices/0000:00:01.1/power/wakeup_last_time_ms

A number above zero means it's really happened, not just a theory.

Also check ACPI-level wake sources:

cat /proc/acpi/wakeup

Look for anything marked *enabled, especially entries starting with XHC (USB controller) or GPP (PCIe root port). Keep in mind this list won't always match the sysfs check above, so treat the sysfs check as the real answer for the NVMe issue, and this list as the real answer for the USB issue.

Step 2: Fix It

Fix A: a udev rule that runs at boot

Replace 0000:00:01.1 with the address you found above:

echo 'ACTION=="add", SUBSYSTEM=="pci", KERNEL=="0000:00:01.1", ATTR{power/wakeup}="disabled"' | sudo tee /etc/udev/rules.d/99-disable-nvme-pme-wake.rules

sudo udevadm control --reload-rules
sudo udevadm trigger --action=add --sysname-match=0000:00:01.1
sudo udevadm settle

cat /sys/bus/pci/devices/0000:00:01.1/power/wakeup   # should now say "disabled"

Fix B: a systemd service that runs before every suspend

A udev rule only applies once at boot, so if anything re-enables the wake flag later, whether that's a driver, a power tool, or a kernel update, the udev rule won't catch it again until your next reboot. This service re-applies the fix every single time you suspend, so it's the one that actually closes the loop:

sudo tee /etc/systemd/system/disable-nvme-wake.service <<'EOF'
[Unit]
Description=Disable NVMe PCIe PME wake before suspend
Before=suspend.target systemd-suspend.service

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'echo disabled > /sys/bus/pci/devices/0000:00:01.1/power/wakeup'

[Install]
WantedBy=suspend.target
EOF

sudo systemctl enable --now disable-nvme-wake

If it's a USB controller rather than a PCIe bridge, use the same service, but point it at the USB entry instead:

ExecStart=/bin/sh -c 'echo XHC0 > /proc/acpi/wakeup'

Other Things Worth Trying First

Check your BIOS/UEFI. Look for "Wake on PCI-E," "PCIe device wake," or "Wake on PME." Turning this off in firmware fixes it before Linux even gets involved, and it survives reinstalls. Be careful with a setting called "ErP Ready," since it can also affect suspend, sometimes for better and sometimes for worse.

How to Actually Test It

One successful suspend doesn't prove anything, so test it properly:

Reboot, then check the flag is already disabled with no manual steps.
Suspend once, and confirm it actually stays asleep for a couple of minutes.
Wake it, then suspend again immediately. This second suspend is the real test, since it tells you whether something re-armed the wake flag after the first resume. If both rounds stay asleep, you're done.

Undo It (If You Ever Need To)

sudo rm /etc/udev/rules.d/99-disable-nvme-pme-wake.rules
sudo udevadm control --reload-rules
sudo systemctl disable --now disable-nvme-wake
sudo rm /etc/systemd/system/disable-nvme-wake.service

Quick Reference


Symptom	Suspend, then instant wake, every time
Cause	A stuck PCIe wake signal, usually from your NVMe's port, or a USB controller failing to suspend cleanly
Find it	`grep -l enabled /sys/bus/pci/devices/*/power/wakeup`, `lspci -tv`, `cat /proc/acpi/wakeup`
Fix it	A udev rule paired with a systemd service, both disabling wake-up on the port
Test it	Reboot, then suspend, then wake, then suspend again

This has been independently reported on AMD B550 and X670E boards, NVMe laptops, and USB touchscreen all-in-ones, across Arch, Ubuntu, Mint, and more. It's a well-known issue with a well-known fix.

My Journey With Linux

A. Ababa — Mon, 10 Aug 2026 05:34:39 +0000

Looking back, my path to Linux was less of a conscious decision and more of a slow drift, one small moment leading to the next, until one day I realised Windows isn't really my gig anymore. At least it hasn't been since Windows 7.

So, this is my story on how I ended up using Linux.

The Disc I Didn't Install

I was a teenager when I first saw a disc of Ubuntu at one of my school teacher's places. I asked him what it was, and he said it was an operating system, like Windows is.

Didn't really understand anything, but the name stuck with me. I came home and searched it up on the internet with my Android tablet (tablets were popular back then) using 3G internet, but got even more confused.

That was the day, however, I first got introduced to the name Linux.

The First Go

It took years before curiosity turned into action. Around six to seven years ago, I finally decided to try Linux out for real, and I installed Zorin OS.

It made sense as a starting point, built specifically to feel familiar to Windows users making the jump. It was genuinely great. Clean, functional, easy to use.

But it didn't strike a chord with me yet, mostly because I only used my PC at the time for playing cracked games (don't call the police on me, I know you're guilty as well), and gaming wasn't really a thing on Linux at the time. To be more modest, it wasn't a practical choice for gaming, to say the least.

I used Zorin, appreciated it, and moved back to Windows. Sometimes the timing just isn't right.

Where It Actually Proved Itself

The moment Linux earned my respect had nothing to do with me.

It was my sister's laptop, an old, underpowered machine that struggled to run Windows 10 (which it shipped with out of the box) without lagging on the simplest tasks. She mostly used it for light browsing and watching videos, so I installed Zorin on it, added VLC and Chrome, and that's it.

A laptop that used to choke on Windows was suddenly usable, actually more than usable, again. It was snappy and it got the job done. Funny thing is, she didn't even notice a difference in usability.

This was the moment Linux truly made its place in my heart.

Living Two Lives

Not long after, I set up Zorin alongside Windows 11 in a dual boot on my own PC. At first, it was just something I'd boot into out of curiosity every once in a while.

But slowly, without ever really deciding to, I noticed I was reaching for the Zorin side more and more. My PC wasn't powerful enough for serious gaming at the time anyway, so I was still playing the occasional casual title, strictly on Windows.

Gaming on Linux wasn't even on my radar yet. Linux was quietly becoming the OS for everything else, while Windows stayed the place I went to play.

The Reset

Then life got in the way, as it tends to (by now I know, that's just how life is).

I got busy with things that didn't really need my PC, took what was basically a sabbatical from casual gaming, and at one point barely touched the machine at all.

Then my CPU broke. I brought it home from servicing and found my primary SSD wiped clean, freshly loaded with Windows 11.

Since I wasn't using the PC much anyway, I didn't even bother dual booting Linux back onto it. For a while, that chapter just quietly closed, without any real goodbye.

Round Two, For a Familiar Reason

They say history repeats itself. Apparently, so does my history with Linux.

My wife's laptop was showing its age and struggling under the heavy load (and bloat) of Windows 11. So I did what I did with my sister's laptop years prior: installing Linux.

And once again, Linux did its magic and replenished an almost dying device. Apps opened and closed faster than ever, the barely audible speakers on the laptop became audible again (thanks Pipewire), and even the battery life was noticeably better. The OS was Arch Linux (BTW) and the desktop environment was KDE Plasma with this one.

My wife was happy, so I was happy, and life was happy.

Down the Ricing Rabbit Hole

Around the same time, a friend who had been deep into Linux for a while got me interested in something new: window managers, tiling windows, and the never ending spiral of Linux ricing.

That sent me straight down the rabbit hole of customising every graphical component of your desktop until it truly became your own. I used my wife's laptop as my testing ground, still running Arch through the whole phase (hands down the best distro for doing whatever-you-want stuff).

I broke that installation more times than I'd like to admit, re-installing and re-configuring over and over. But every time I rebuilt it, I understood a little more about how the system actually worked underneath the surface.

That understanding is what turned Linux from something I merely used into something I genuinely enjoyed using.

By the end of this stretch, I wasn't dual booting out of necessity anymore, and I wasn't fixing someone else's slow laptop. I was choosing Linux because I wanted to be there.

Gaming was still firmly a Windows thing in my mind. That was about to change too, but not just yet.

All That Shines Ain't No Gold

The ricing phase taught me a lot about Linux, but it also taught me something about myself. As you mature, stability, though it may be boring, matters more than the latest and greatest.

Constantly rebuilding a broken Arch install is fun for a while, and I don't regret a single hour of it (or maybe a few, but whatever). But eventually I wanted a system I could just use and rely on.

A system I knew wouldn't break on me while I'm focusing on my work, doing important stuff that earns the bread. A machine with a heart, one that I know will open up my workspace without any hiccups, every single time I press the power button.

That's what led me to settle on Fedora, specifically the KDE Plasma Spin.

I know what some of you are already thinking. Fedora is still pretty bleeding edge in the grand scheme of distros. That's fair.

But it's backed by a large, active community and a genuinely massive corporation behind the scenes. I'll be upfront about it, I don't fully trust corporations either.

But in the world of open source, having that kind of infrastructure and a dedicated team keeping things running matters more than you realise. It gives me confidence and a sense of credibility in what I choose to run every single day, something a smaller, less resourced project just cannot match.

The KDE of It All

KDE itself has always been my desktop environment of choice, over GNOME and everything else I've tried along the way.

I don't love every single thing about it, no desktop environment is perfect. But there's so much I genuinely appreciate about how it works and how much control it hands back to you.

That's honestly a whole article on its own, and I'll get to it eventually.

Bringing It Into the Workplace

When I started my new job, the very first thing I did on my office PC was replicate the exact Fedora KDE setup I'd already built on my wife's laptop. No hesitation, no second guessing which OS to pick.

For the kind of work I do day-to-day, document processing, web browsing, communication, and everything in between, Fedora has been a stable, reliable, and genuinely functional tool. That's also a topic I'll get into properly in a dedicated article some day in the future.

By now, Linux wasn't just something I used at home as a hobby. It had become the operating system I trusted for actual work, every single day.

Gaming was still the last piece of the puzzle to put the whole picture together. And in 2026, thanks to Valve, Proton, and all the hobbyists and professionals behind them, gaming on Linux ain't so puzzling no more as it was a few years ago.

Finally, the Gaming Machine

Today, I'm running Fedora Kinoite (it's the atomic desktop version of Fedora KDE) on a new PC I built specifically for gaming and development work. As it genuinely deserves its own space, I'll go deep into what atomic desktops are, and why I made the switch, in the article I'll write about my choice of distro, Fedora.

Throughout this whole journey, LLMs like Gemini, Claude, DeepSeek, and ChatGPT were a constant part of my troubleshooting process, and for the most part, they worked.

Linux troubleshooting often involves spending substantial time in the terminal (if the issue is substantial as well), and in the world of intuitive GUIs, it takes a while to get used to. You must accept the terminal for what it is, work through it, and let yourself learn its way from the mistakes you'll inevitably make.

You can go nuts with Linux, if you want, and don't be afraid to do so either. You can also have a rock-solid daily driver on Linux, if that's what you want instead. The choice is yours.

And having that choice is what I think is the most beautiful thing about Linux and the open source world.

Where That Leaves Me

Linux has matured to a point where it can genuinely serve as a reliable daily driver, even for people who have zero interest in tinkering under the hood.

As I'm using an immutable distro, I barely touch the terminal. Maybe for installing a few apps that I need for some particular workflow.

For example, for typing in Bangla, I needed an input method (OpenBangla Keyboard, to be specific), and there isn't really a GUI way of getting it on my system. However, in the age of generative AI, it was as easy as asking Claude what I wanted and pasting a few commands into the terminal. A couple of minutes later, boom, I was typing in Bangla.

That kind of usability and reliability has largely belonged to macOS and Windows for decades. Linux has finally caught up, and in more ways than one, I'd say it's overtaken them.

With the right tools and the right choices, Linux can be truly yours, a piece of software you actually admire and enjoy using every day.

A tool you can trust and rely on. A tool that doesn't spy on you, a tool that respects your decisions, and a tool that genuinely does what it says on the box.

The Toolkit That Made It Stick

Finally, to end this article, here are a few apps I've daily driven since day one of going all in on Linux.

And not just for me. Below is a list of apps that I genuinely believe will help everyone switching to Linux feel right at home:

KDE Connect: Keeps your phone and PC connected at all times. It syncs notifications and clipboard, and you can even browse your phone's internal storage from your desktop.
Flatseal: Simple and intuitive. Flatpak apps run sandboxed in a containerized environment for security reasons, which comes with some restrictions by design. Flatseal gives you an easy way to manage those permissions without a fight. I'll write about Flatpaks and Linux app packaging in a later article.
Okular: A simple yet fully featured PDF viewer.
LocalSend: Transfers files instantly to any device on the same WiFi network. Works flawlessly across everything I own, and it's cross platform too.
OnlyOffice: I primarily live in Google Workspace for work, but for opening files locally and getting the best compatibility with Microsoft Office formats, which are still dominant everywhere, OnlyOffice is the way to go. The UI is clean, familiar, and intuitive.
qBittorrent: My default torrent client since my Windows days. It just works, and that's really all I need from it.
Thunderbird: My email client. I don't really need it (I mostly use Gmail on my browser), but it's there and it's solid.
VLC: The undisputed GOAT of media players. The automatic subtitle loading feature they recently added through a plugin is genuinely all it took to fully sell me on it, all over again.
Web App Hub: You can technically turn any webpage into a web app straight from Chrome, but you can't really blend it into your system with native window decorations. This app solves that. It also isolates each web app so the system doesn't lump them all together as just another Chrome window, so that's another plus.

That's the journey then: from a disc I never even got around to installing, all the way to a Kinoite gaming rig I now trust completely.

The gaming part itself, Proton, Steam Play, and everything I had to figure out along the way, deserves its own telling. That one's coming next.

RAMageddon: How the AI Gold Rush Is Emptying Your Wallet, One Gigabyte at a Time

A. Ababa — Tue, 21 Jul 2026 07:41:20 +0000

If you've priced a new laptop, phone, or gaming console this summer, you've probably felt it: the same product now costs hundreds of dollars more than it did a year ago. This isn't garden-variety inflation. It's the fallout of a silent war for a component that most of us never think about: memory chips.

The industry has started calling it "RAMageddon." It's not hype. It's now backed by a federal lawsuit.

The Bill Has Arrived

On June 25, 2026, Apple and Microsoft both announced sweeping price hikes across their most popular products on the very same day, and both cited the same cause: an AI-driven global memory shortage.

📈 Apple: MacBook Air jumped from $1,099 to $1,299. The entry MacBook Pro went from $1,699 to $1,999. iPad Air rose from $599 to $749, and iPad Pro from $999 to $1,199, increases of up to $300 in a single announcement. Apple said it had been absorbing rising component costs for months and had simply run out of room. Tim Cook, in a Wall Street Journal interview, described the memory crunch as a "hundred-year flood." Analysts now expect the iPhone 18 to carry a $150 to $200 premium when it launches in September, even though phones were spared this round.

🎮 Microsoft: Hours later, Microsoft raised Xbox console prices by $100 to $150 and discontinued its highest-storage configuration entirely. The company said console memory and storage costs have already risen more than 150%, and it expects another doubling by fall 2027.

This isn't limited to two giants. Valve just launched its new Steam Machine at $1,919 for the top configuration, pricier than originally planned, the company said, specifically because of the RAM shortage. IDC now projects the worst annual smartphone shipment decline on record (nearly 14%) and an 11%+ drop in PC shipments for 2026, driven almost entirely by memory-driven price increases pricing out everyday buyers.

Whos Actually Holding the Supply

Three companies, Samsung, SK Hynix, and Micron, control roughly 90% of the world's DRAM supply. Building a new fab costs $15 to 20 billion and takes years, so that concentration isn't changing anytime soon.

Here's the mechanism driving the squeeze: manufacturing one gigabyte of High-Bandwidth Memory (HBM), the specialized chip that AI accelerators need, consumes roughly 3-times the wafer capacity of standard DDR5 used in your laptop. Every wafer redirected to HBM is a wafer pulled straight out of the consumer supply chain.

And the redirection has been dramatic:

SK Hynix has reportedly locked in 60 to 70% of its next-generation HBM4 capacity for Nvidia alone, tied to Nvidia's upcoming "Vera Rubin" AI platform. Nvidia has reportedly prepaid SK Hynix and Micron $540 to 770 million each just to secure the allocation. Preliminary agreements for OpenAI's $500 billion Stargate project point to demand of up to 900,000 DRAM wafers per month, which could represent as much as 40% of total global DRAM output.

Micron formally exited the consumer DRAM business in December 2025.
The payoff for manufacturers has been staggering, since SK Hynix's Q1 2026 operating profit rose 405% year-over-year to a 72% operating margin, which was reportedly higher than Nvidia's. Micron posted record quarterly revenue of $41.5 billion with an 85% gross margin, and it is guiding toward $50 billion next quarter.

Meanwhile, TrendForce data shows conventional DRAM contract prices jumped 80 to 98% in Q1 2026 alone, with further double-digit increases still forecast through the rest of the year.

Now, It's in Court

This is where it stops being just an industry story. On June 25, 2026, 17 plaintiffs (14 consumers and three small PC-building businesses) filed a federal antitrust class action against Samsung, SK Hynix, and Micron in the Northern District of California (Garciaguirre v. Samsung Electronics). The complaint alleges the three companies used the shift to AI-focused HBM production as cover to deliberately choke output of legacy DDR3 and DDR4 memory, driving conventional DRAM prices up by roughly 700% over four years. It even points to Apple's own price hikes as evidence of the downstream damage. The suit seeks an injunction and treble damages.

It's worth being precise here, since these are allegations, not findings. Micron has publicly denied wrongdoing, saying it competes lawfully and vigorously. History cuts both ways for the plaintiffs, too. Samsung and SK Hynix's predecessor did plead guilty to real, criminal DRAM price-fixing in the mid-2000s, resulting in over $700 million in combined fines and prison time for several executives. But a nearly identical class action filed in 2018, which alleged collusion during the 2016 to 2017 DRAM price spike, was dismissed in 2020 and upheld on appeal in 2022. The courts ruled that three companies independently cutting output in a concentrated market, a practice antitrust law calls "conscious parallelism," isn't automatically illegal. Proving an actual agreement, rather than three firms rationally chasing the same profits, is a much higher legal bar, and that's precisely the question this new case will have to answer.

A Familiar Pattern, With a Twist

For anyone who's watched commodity markets in South Asia, the shape of this story feels familiar. Cold storage syndicates hoarding potatoes and onions during peak harvest, releasing them gradually at inflated prices while blaming weather or crop failure, is a well-worn playbook for engineering artificial scarcity.

The DRAM story rhymes with that pattern: a concentrated handful of players, control of the bottleneck, advance deals that lock up supply years ahead, and a convenient external narrative ("it's just AI demand") to explain the squeeze. But there's a crucial difference, and it's the one a US federal court now has to untangle: unlike a black-market syndicate, none of what Samsung, SK Hynix, and Micron have done is obviously illegal. Chasing the most profitable product a factory can make is, on its face, ordinary capitalism. Whether it crosses into an unlawful agreement to hurt consumers is exactly what Garciaguirre v. Samsung will need to prove.

The Real Question

Is this simply supply and demand doing what markets do when a once-in-a-generation technology shock hits a genuinely scarce resource? Or is a market this concentrated, with three players controlling 90% of global supply and multibillion-dollar barriers to entry, structurally incapable of behaving competitively once the incentives align?

Either way, the person paying the "AI tax" isn't Nvidia, OpenAI, or the hyperscalers. It's the student buying their first laptop, the small business upgrading office PCs, and the family replacing a broken Xbox.

What do you think: is this free market at work, or a supply chain concentrated enough that "independent" decisions start looking a lot like coordination?

Sources: Tom's Hardware, CNBC, CBS News, Al Jazeera, Reuters/TrendForce, Fortune, Yahoo Finance, Notebookcheck, and court filings in Garciaguirre v. Samsung Electronics (N.D. Cal., No. 5:26-cv-06345).

Porting a Pygame Game from Arch (BTW) to Android (By losing my mind so you don’t have to)

A. Ababa — Tue, 20 Jan 2026 21:32:31 +0000

Introduction

If you have ever tried to run buildozer android debug on a rolling-release distribution like Arch Linux, you probably know the pain. It usually starts with a simple command and ends with you staring at gcc compiler logs at 3 AM, wondering why longintrepr.h is missing.

The Golden Stack (TL;DR)
Step 1: System Prerequisites
Step 2: The Virtual Environment
Step 3: The "Flag Sanitization" Patch
Step 4: Building the APK
Troubleshooting Cheatsheet
Final Thoughts

The Golden Stack (TL;DR)

Android cross-compilation is fragile. If you mix the wrong versions of Python, Cython, and Java, the build fails. Here is the exact combination that works in 2026:

Tool	Version	The Why
Python	`3.11`	3.12+ removed `distutils`, breaking many Android recipes.
Cython	`< 3.0.0`	Cython 3.0 removed `longintrepr.h`, breaking Kivy/Pygame recipes.
Java	`JDK 17`	Required by the latest Android SDK/Gradle.

Step 1: System Prerequisites

Arch is "bare bones," so we need to manually fetch the headers that python-for-android (p4a) needs to compile the recipes.

Run the following in your terminal to install the build toolchain and headers:

# Update everything first
sudo pacman -Syu


# Install the build toolchain and headers
# We need jdk17-openjdk for Gradle and base-devel for gcc/make
sudo pacman -S git zip unzip jdk17-openjdk python pip python-virtualenv \
    base-devel autoconf libtool pkg-config zlib ncurses cmake libffi openssl

Step 2: The Virtual Environment (DO NOT SKIP THIS)

Never install Buildozer or Cython globally on Arch. System updates will break your build toolchain. We need an isolated environment where we can pin older versions of Cython without messing up the system.

# 1. Create the venv with Python 3.11
python3.11 -m venv .venv


# 2. Activate it
source .venv/bin/activate


# 3. Install the specific versions
# We pin Cython < 3.0 to fix the "longintrepr.h" error
pip install "Cython<3.0" "setuptools<71.0.0" buildozer

Step 3: The "Flag Sanitization" Patch

This was the hardest bug to track down.

On Arch Linux, the system compilers are configured with aggressive security and optimization flags like -fcf-protection (Intel Control-flow enforcement) and -march=x86-64.

When Buildozer runs, it sometimes leaks these Host Flags into the Target (Android) build process. The Android NDK compiler sees -march=x86-64, panics because it's trying to build for ARM, and crashes with cryptic errors.

The Fix: We need to "sanitize" the environment variables in the recipe before the build starts.

Navigate to the pygame recipe inside your hidden .buildozer directory. It is usually located here: .buildozer/android/platform/python-for-android/pythonforandroid/recipes/pygame/__init__.py
Locate the build_armeabi_v7a method and inject this sanitation logic:

import re


# ... inside the build_armeabi_v7a method ...
env = self.get_recipe_env(arch)


# 🧹 THE SANITIZER
# Strip flags that break ARM builds (like x86 specific protections)
bad_flags = [
    r'-m(arch|tune|cpu)=\S+',      # e.g., -march=x86-64
    r'-fcf-protection(=\S+)?',     # Intel specific
    r'-fno-plt'                    # PLT hardening
]


for var in ['CFLAGS', 'LDFLAGS']:
    if var in env:
        for pattern in bad_flags:
            env[var] = re.sub(pattern, '', env[var])


# ... proceed with the build ...

This simple script strips the x86 flags before they reach the NDK.

Step 4: Building the APK

Now that our environment is clean and our flags are sanitized, we can build.

CRITICAL: You must export your local venv path before building. If you don't, Buildozer might use the system Cython (v3.0+) and fail.

# Force the build to use our local venv tools
export PATH="$(pwd)/.venv/bin:$PATH"


# Build the debug APK
buildozer android debug

This will:

Download the Android SDK/NDK (takes a while the first time).
Compile Python 3.11 for ARM.
Package your Pygame app.

If everything goes well, you’ll see the glorious Application pushed. message.

Troubleshooting Cheatsheet

If (when) things break, here is your rescue kit.

1. The "longintrepr.h not found" Error

Cause: You are using Cython 3.0+.
Fix: Run pip install "Cython<3.0" and check your PATH.

2. The App Crashes Immediately

Buildozer hides the Python errors. You need logcat to see why your game crashed.

# Filter specifically for Python crashes
adb logcat -s python studio.flappybird.game

3. "Get Android SDK" Hangs

Cause: You need to accept a license agreement.
Fix: Run the command in the foreground first, or check your internet connection.

Final Thoughts

Porting to Android doesn't have to be a nightmare, but on Linux (Arch BTW), you have to respect the toolchain. By pinning your dependencies and sanitizing your compiler flags, you can build reliable APKs even on a bleeding-edge distro like Arch.

Happy Coding!