HN Debrief

I'm switching my phone from Android to Linux

  • Open Source
  • Mobile
  • Privacy
  • Hardware
  • Regulation

The post is a personal migration note from someone leaving Android for a Linux phone. The author’s complaint is not that Android is technically bad in the abstract. It is that the usable version of Android increasingly means Google services, closed bits, and policy decisions that make the phone feel less like a general-purpose computer and more like a controlled appliance. Linux is appealing for the opposite reason. It gives shell access, remote administration over SSH, and the sense that the device works for its owner instead of for the vendor. The catch, which the author openly admits, is that this is not a clean replacement. They still need Android around for some bank and government verification apps in Norway because Waydroid is not available on their setup.

If you want more control over mobile, the practical near-term option is still hardened or de-Googled Android on carefully chosen hardware, not a clean break to Linux. Watch the choke points around attestation, payments, and mandatory apps, because that is where platform lock-in is tightening fastest.

Discussion mood

Sympathetic and frustrated. People like the goal of owning and controlling the computer in their pocket, but most see today’s blockers as external lock-in from banks, governments, payments, carriers, and proprietary services rather than a lack of Linux enthusiasm.

Key insights

  1. 01

    Phone cameras fail on calibration work

    Getting good photos on Linux phones is not primarily about missing a magical proprietary algorithm. It is about building and tuning the image signal processor pipeline for each device, then doing detailed sensor calibration across lighting conditions. Commenters with hands-on experience said the community has only recently had enough people working on this to make real progress, which makes camera quality look more hopeless than it is.

    If camera quality is your adoption gate, look for devices and projects with active per-device camera work instead of judging mobile Linux as a whole. Hardware with decent sensors is not enough unless someone is maintaining the full imaging stack.

      Attribution:
    • megous #1 #2
    • seba_dos1 #1
  2. 02

    App lock-in is now civic infrastructure

    The hardest blockers were not entertainment apps. They were bank authentication, government ID, contactless payments, and local services that have replaced physical cards and even parts of the wallet. The Ukraine examples made the point brutally clear. In some places the smartphone app is not a convenience layer on top of another system. It is the system.

    Before considering a Linux-phone move, audit your dependence on country-specific finance, identity, transit, and travel apps. The feasibility of switching is increasingly determined by local institutions, not by your technical tolerance for bugs.

  3. 03

    AOSP is open on paper, not in practice

    The useful distinction is between the Android source tree and the actual Android ecosystem people have to survive in. Commenters pushed back on blaming AOSP itself for every Google decision, but the stronger point was that this barely helps users because real devices and real apps expect keyboards, call stacks, Play Services, and other pieces that AOSP alone does not fully provide. The open core remains, while the indispensable layers drift closed.

    Treat claims of Android openness as a supply-chain question, not a repo question. What matters is whether your device, ROM, and required apps can function without Google-controlled components.

      Attribution:
    • charcircuit #1
    • realusername #1
    • hagbard_c #1
  4. 04

    Attestation is the new control point

    Several comments cut past rooting and customization to the actual leverage point. Apps increasingly demand proof that the device is in a vendor-approved state, because banks, wallets, and employers want the phone to enforce their policy instead of yours. That makes ownership conflicts explicit. The device can be technically yours while still refusing to act on your behalf for the apps that matter most.

    Expect more important mobile workflows to hinge on attestation rather than raw OS choice. If your product depends on mobile trust, decide now whether you are building around open standards or around vendor gatekeeping.

      Attribution:
    • skeptic_ai #1
    • surajrmal #1
    • shakna #1
  5. 05

    Daily-driving Linux already works for some

    The strongest pro-Linux evidence came from people who have actually used Linux phones for years. Their reports were not romantic. Reboots, browser video glitches, weak mapping, and hardware quirks are still normal. But they also said the device covers messaging, email, navigation, banking, TOTP, media, and even niche uses like low-latency audio or lightweight development. The point is not that mobile Linux is polished. It is that for a certain user it has crossed from toy to viable primary device.

    If your own phone usage is mostly web, messaging, authentication, and basic utilities, mobile Linux may already be good enough. Test against your real workflow rather than assuming mainstream app expectations apply to you.

      Attribution:
    • seba_dos1 #1 #2
    • pelzatessa #1
  6. 06

    Carrier support still decides viability

    US commenters highlighted a boring but decisive problem. Without VoLTE and compatible modem support, a Linux phone can fail at the one job nobody will forgive it for failing. A recent Fairphone 5 Ubuntu Touch report saying VoLTE now works shows the situation is improving, but also how device- and carrier-specific the answer still is.

    Verify modem, carrier, and VoLTE support before you care about any higher-level software feature. A phone that cannot reliably register, call, or text on your network is not a platform experiment. It is dead hardware.

      Attribution:
    • ryukafalz #1
    • burningChrome #1

Against the grain

  1. 01

    Many missing features are optional habits

    Some people rejected the idea that losing Google Wallet, digital car keys, or phone-based payments is a serious problem. They argued that physical keys and cards remain perfectly workable, and that part of the attraction of a Linux phone is escaping systems that pressure you into app-only behavior. That changes the frame from capability loss to deliberate refusal.

    Separate true requirements from conveniences you have normalized. If physical alternatives still exist for your core tasks, the switch may be more practical than your first reaction suggests.

      Attribution:
    • prmoustache #1
    • Gigachad #1
    • downrightmike #1
  2. 02

    A Google clampdown could accelerate Linux

    One commenter argued that Linux phones do not need to beat Android feature for feature on their own. If Google further restricts sideloading or weakens AOSP’s usefulness, millions of custom-ROM users would suddenly become a natural constituency for non-Android alternatives. In that view, the missing ingredient is not technical possibility but a forcing event.

    Watch Android policy changes as market-creation events. A hostile move on sideloading or custom ROMs could quickly expand demand for Linux mobile far beyond today’s hobbyist base.

      Attribution:
    • colordrops #1
  3. 03

    Regulation may matter more than engineering

    Some comments pushed the problem upstream. If banks, governments, and platforms can require mobile apps tied to closed ecosystems, then better Linux engineering alone will not fix the lock-in. The bottleneck is legal and institutional. Without mandates for web access and open standards, every alternative phone OS stays structurally disadvantaged.

    If you care about platform competition, track policy around app store access, browser parity, and public-service interoperability. Product work alone will not break mobile lock-in if institutions are allowed to hard-code it.

      Attribution:
    • pizzaballs #1
    • TheCoelacanth #1

In plain english

AOSP ↩
Android Open Source Project, the open-source base version of Android that device makers and custom ROM projects build on.
GrapheneOS ↩
A privacy- and security-focused Android-based operating system for supported phones, especially Google Pixel devices.
LineageOS ↩
A popular community-built Android distribution that replaces the stock software on supported phones.
OEM ↩
Original Equipment Manufacturer, a company that builds and sells hardware devices such as phones.
ROM ↩
In Android modding, a full operating system image installed on a phone to replace the manufacturer’s default software.
SSH ↩
Secure Shell, a standard way to remotely log into and control another computer over a network.
TOTP ↩
Time-Based One-Time Password, a common two-factor authentication code that changes every 30 seconds.
VoLTE ↩
Voice over Long-Term Evolution, a mobile carrier feature that carries phone calls over 4G data networks instead of older voice networks.
Waydroid ↩
A tool that runs Android inside a Linux environment on a phone or desktop so Linux users can access Android apps.

Reference links

Mobile Linux projects and device support

Alternative hardware and vendors

  • Purism Liberty Phone
    Mentioned as a privacy-focused Linux phone, mainly as a high-priced option with tradeoffs.
  • The Hammer
    Shared as another Linux-based mobile texting device concept.
  • OpenStick
    Posted by a commenter selling Linux-capable mobile hardware in bulk.
  • Commodore callback phone
    Mentioned jokingly in the side discussion about avoiding smartphones altogether.

Platform policy and historical references

Performance references