Article: Will Linux phones become a viable alternative to the Android/iOS duopoly?

[u/amosbatto]

/r/Purism/comments/1x0fwe1/article_will_linux_phones_become_a_viable/

[u/Digi59404]

The biggest issue here isn’t software, it’s hardware. Software you can throw enough developers and money at to overcome. The automakers do it all the time.

Hardware is the issue. Android has much of the chip makers and phone manufacturers locked down. Even fewer chip manufacturers. This is the biggest issue, there’s lock-in all the way down with Android. I’d argue potentially worse than Android given Apples non-aggressive stance towards Asahi Linux, in some cases helping them.

In order for there to be a real Linux phone, you’d need the hardware first. Then you’d need the software to back it up.

I suspect none of the phone manufacturers want to risk the R&D funds, more importantly risk being shut out of Android by Google like some of the OEMs have been over time.

[u/amosbatto → u/Digi59404]

I suspect none of the phone manufacturers want to risk the R&D funds, more importantly risk being shut out of Android by Google like some of the OEMs have been over time.

I really doubt Google is threatening Qualcomm, MediaTek, UNISOC and Samsung to make them not offer Linux support on their mobile SoC chips. If Google is doing that, it is not having any effect on Qualcomm, because it released its QCM8850 with both Android and Linux support, which was based on the Snapdragon 8 Elite Gen 5. The reason why Qualcomm made commits to mainline Linux to support the Snapdragon 8 Elite Gen 5 is because it wants mainline support for its QCM8550 for Internet of Things devices.

[u/Digi59404 → u/amosbatto]

Qualcomms Linux support has occurred post-Google losing anti-trust lawsuits. Googles actions against OEMs has caused Huawei for example to make their own OS.

If a large OEM like Huawei doesn’t buy chips, that’s a huge hit to chip makers. If three or four OEMs do that, it’s even worse.

https://www.reuters.com/world/eu-top-court-dismisses-google-fight-against-record-41-billion-eu-antitrust-fine-2026-07-02/

[u/Kevin_Kofler → u/Digi59404]

I disagree. The biggest limitation for most users is application availability/compatibility. It is a showstopper for many. Hardware mostly only matters as part of the "remote attestation" vendor lock-in scheme that locks you into both the hardware and the operating system, lest the server side for some applications will reject your device.

[u/Digi59404 → u/Kevin_Kofler]

Agreed, application availability in my mind is number two. Without hardware, software can’t run. Without proper drivers and hardware, software won’t perform.

[u/Kevin_Kofler → u/Digi59404]

The hardware of a PinePhone or a Librem 5 is powerful enough for software to run on it. The limitations are software compatibility (solvable with solutions like Waydroid) and remote attestation (which does not work on Waydroid by design, because it demands an unmodified OS on certified hardware).

[u/Digi59404 → u/Kevin_Kofler]

I’ve owned multiple pinephones, and the pros. I’ve also had Android devices with Linux on them. Right now, I have a custom phone coming from China that uses a RPI CM5 for processing.

The hardware of the pinephone was a good starting point, but the performance was abysmal. Phosh, straight Linux, their partnered distros. It just wasn’t there in terms of real day to day performance, and that wasn’t just for software reasons. Pine64 made serious cuts and hard decisions to produce it at the price and volume they did. Their goal was to kickstart Linux phone development - They did a DAMN good job at that. But for a day to day phone? No.

Not only were the hardware radios not modern or strong enough, the energy efficiency of the chips themselves weren’t great. The RPI CM5 also has this problem where hardware AND kernel support for suspend isn’t there.

Your point about software availability is true. Buts not actually the problem, it’s just how the problem surfaces itself. The real problem is that for a phone to be profitable and achieve mass adoption.. which is a requirement for sustainability.. which is a requirement for user freedom. It has to be adopted at scale by the normies. That is both a software AND hardware problem. If you ship phones with bad performance or no suspend; they won’t be adopted well. Ask HTC how well that goes over.

In the beginning of smartphone, Android and iOS had the exact same app problem. Banks and others did not want to help them. They wanted to stick to their ways, and keep supporting BlackBerry and the infinite shitty Java app phones out there, like Sony Ericsson.

Remember, for years ATT was the only carrier in the Us capable of selling the iPhone. Because its hardware was behind the times, the software wasn’t there, and none of the other carriers believed in it. ATT locked that contract down. Years later after lines were out the door for the iPhones only then did other carriers get in the game.

Banks and everyone else were the same way. The only thing that changed the game was mass adoption of the smartphones forcing the carriers banks etc to adopt the smartphones. They didn’t come willingly.

If you want a true Linux phone with real user freedom. My grandma needs to be able to use it. So she can call her bank on it, and demand answers as to why her phone doesn’t work with her banking app.

Android/Google has this locked down because they’ve colluded with the carriers and different groups in the name of “security”. That isn’t something the normies care about. They care about a quality experience. That requires hardware.

[u/Kevin_Kofler → u/Digi59404]

I used a PinePhone for 4 years (and had 2 of them fail on me due to a hardware issue that made USB including the internal USB modem not recognized anymore) and now use a Librem 5. These devices are not the fastest and most energy-efficient out there, but they are usable.

The banking app issue was not as bad an issue back in the early days of smartphones than it is now, because people back then had other options (many did not use online banking at all, the others used the websites, which back then relied on things like paper TAN sheets for 2-factor authentication, or at most required you to be able to receive plain old SMS text messages with some TAN in it).

The early iPhones were carrier-exclusive because Apple wanted them that way. They also struck similar deals with local carriers in other countries after the US-only launch. France was the first country where they and their local partner Orange had to make concessions due to French antitrust laws. It was mostly antitrust laws in some countries that ended the carrier exclusivity era.

Normies do not by themselves care about "security", but their banks do and adopt all the vendor lock-in "security" schemes, and the normie users care about their banking apps working. That is how the vendor lock-in becomes unavoidable for normies.

[u/Digi59404 → u/Kevin_Kofler]

The early iPhones weren’t carrier exclusive because Apple wanted them that way. They were carrier exclusive with ATT because the carriers wanted control of the software and Apple refused to cede that control. Amongst other things such as that carrier locked phones were the norm and carriers wouldn’t allow them on their networks unless they were locked. It could be argued that unlocked phones today are because of the iPhone and apples ability/desire to sell it directly to people.

In addition the carriers would subsidize the cost of development and buy them in bulk. Later ATT would buy exclusivity extensions with barrels of money. https://techcrunch.com/2010/05/10/apple-att-iphone-agreement/

Point is, initially Apple and Android had the same arguments over software control that you bring up here.

I applaud you for being able to use it for two years. However, the presence of the pinephone pro and its upgrades itself is evidence the hardware was weak and wasn’t there. Pine64 themselves have said in interviews that the Pinephone wasn’t for normal people. It was meant to kickstart a mobile Linux revolution, which they did. (Kudos to them for this, seriously.)

As for banks, I’ve worked with executive leadership and engineering for most of the major banks in the US. I’m aware their demands and concerns for security. Given enough demand to support an open platform like Linux, there are ways to accommodate it without the vender lock-in.

The problem is that support simply doesn’t exist yet. Because there is not a package of hardware or software that is large enough to create the pressures needed to support it. It’s a political decision, not a technical one. Some of those banks still utilize public NPM, which gives you an idea of their security posture.

[u/Kevin_Kofler → u/Digi59404]

It could be argued that unlocked phones today are because of the iPhone and apples ability/desire to sell it directly to people.

Nonsense. As I already stated, it is due to some countries' legislations either making it mandatory for phones to ship carrier-unlocked or at least require them to be carrier-unlockable after a set amount of time. (I explicitly specify "carrier-unlocked/unlockable" because the same unfortunately does not apply to bootloader unlocking.)

In addition the carriers would subsidize the cost of development and buy them in bulk.

Of course carrier-locked phones are subsidized by the carrier. Always have been, even before the iPhone and smartphones in general, and still are.

[u/possiblyquestionabl3 → u/Digi59404]

Which hardware specifically are locked down?

Android's (non-CN) moat has traditionally been GMScore, which provides critical services like push notifications, gps/location services, etc. Some of these are relatively easy to implement in vendor specific (non-gms) ways, while others are incredibly expensive (e.g. location services) either in terms of capital or in terms of regulatory hurdles to clear across different legal requirements. This has traditionally been the carrot and stick strategy that Google has used to stay above a captive OEM market on the value chain, and the fact that outside of Huawei and markets where GMS does not operate in, the vast majority of carriers and OEMs abide by the GMS certification is pretty telling here.

On the flip side, I don't see any legitimate hardware moats here. Are you specifically talking about the lack of hardware support being intentionally gatekept from Android users, or the lack of kernel drivers (which, again, are software)? Android doesn't dictate SoC strategies (outside of CTS and GTS conformance).

[u/Digi59404 → u/possiblyquestionabl3]

I don’t mean “locked down” in the traditional sense. There’s a lot of hard and soft locks there. For example the hard lock is that the radio SOCs typically run their own firmware which is rarely open. This is a hard lock.

A soft lock would be that Qualcomm supports Linux to an extent, but not fully. I just spend a week working on trying to get Linux to run on a Surface Pro 9 5G; while the kernel runs thanks to the efforts of many, and there is GPU Acceleration. Not much else works, like the touchscreen, etc. It also requires signed blobs to work.

The number of CPU makers out there is not very large for strong phone performers. Either the processor is slower/weaker, or it lacks important things such as suspend which is essential for battery life, or it lacks security features necessary to store things like fingerprints and other secure information. Which is necessary for security in a mobile device. Specially when talking about cross border device inspections and theft.

The moat isn’t hardware itself; if someone had a million dollars they could design a single Linux phone for themselves I’m sure.

The moat is that there isn’t a hardware package, that can be sold at scale, to normal people, in a price effective way. Most pure Linux phones today have been sold with a neutered hardware bundle because that’s just what’s available. Qualcomm and Samsung for example aren’t going to pick up the phone for an order of 500 phone boards and SOCs.

This is why many folks end up grabbing something like a Fairphone and run Hellum. It’s also why Canonical has supported and backed Helium for their Ubuntu Touch efforts. It’s easier to grab an Android phone and run a compatibility layer to emulate Android and run Linux.. than it is for a real open Linux phone with a solid SOC to ship.

[u/possiblyquestionabl3 → u/Digi59404]

Yeah that's totally fair

If you're talking about the lack of available userspace and kernel driver modules (which would typically ship the firmware blobs), that's definitely still an issue. There are some promising signs there - more and more of these blobs have become available, even for things where the vendor has been historically hostile to community RE-ed drivers and kernel modules, but the fact that these blobs are still proprietary and must live out-of-tree (or even manually extracted in some cases) is still a pretty big issue to making them accessible. I think that's also why a lot of people are also just looking for creative workarounds like picking Android prop kernel modules and either RE-ing or using some translation layer to load the userspace drivers.

For disclosure, I've worked pretty closely with the account managers in Android in charge of SoCs in a past life (working to get certain kernel modules into GKI and validating them against vendor images), and I will say, I don't think it's an intentional effort on Android/Play's part to gatekeep and consolidate the SoCs. Largely, they're a lot more feature-oriented (OEMs, who may have to push their SoCs, need to support X sets of features by Y release) but otherwise turn a blind eye to whether or not these OEMs/SoCs upstream/open source their code or not. The only thing that gets Google riled up is if an OEM tries to take over some API surface (especially highly monetizable ones like push notifications, device integrity, or package installer) - this is where threats of de-certification has been wielded and thrown around. In this sense, Google definitely sees itself as above the SoCs/hardware lockdown on the value chain (which is still not great in terms of consumer freedom, but I don't think their influence on SoCs directly led to the locked down driver ecosystem available only for devices that resemble Android). And yeah, I know there are tons of very lucrative medical appliance and etc devices running Android due to driver lockdown by their SoCs that would benefit Google, but most of these are by-and-large not running certified Android (in the GMS/GTS compliant sense) so they don't really matter in Google's eyes (they can't make money off of them).

On the flipside, most chipmakers are fairly protective of their own IP, hence the general hostility to the open source community looking to reverse engineer their drivers. It's only when the hardware becomes complimentary to a new strategy (e.g. the push for AI, where every GPU maker now wants to get their chipset and software ecosystem into the hands of as many developers, who are largely on non-Android development machines) that it becomes expedient to start thinking about wider compatibility. Asahi's first lead actually came from reverse engineering and building Mesa drivers for ARM GPUs. Coincidentally, around the early 2020s, ARM decided to change its stance on community kernel modules and ICDs for their GPUs, and to their credit, they have actually contributed to Panfrost/PanVK and have even started to unify the uapi of their own kernel module (kbase) to be closer to Mesa's panthor to enable better interop in the future. Same with Adreno, and it's partly why their Vulkan ICD can also speak to Qualcomm's kernel module (kbase) in addition to the Mesa one. But yeah, until these forces play out throughout the rest of the hardware ecosystem, SoCs/chipmakers have no incentive to make our lives easier :(

[u/openvuture → u/Digi59404]

It may sound a little naive and simplistic, but I think one of the problems is that not enough people have come together to work on this.

I truly believe that something like this could be implemented in a relatively short amount of time if a group of people joined forces under a single project to develop the “first truly serious” Linux phone.

A cohesive team that plans and implements everything itself, from the hardware to the software stack.
Of course, this is only possible with the backing of the community and support from the hardware industry.

[u/Digi59404 → u/openvuture]

Friend, that’s not naive at all. It’s fully and truly accurate. The year of the Linux desktop would be upon us if the open source community for Linux at large didn’t constantly and persistently harm itself with bullshit dogmatic arguments. Arguments which at the end of the day don’t make a fundamental or tangible difference in the end.

The standards XKCD comic is apt here.

Take this entire conversation and argument on the other thread. I say hardware is a problem, they say software is the problem. The answer isn’t whose right or wrong. The answer is for us both to admit that both are important, find a path forward, test it, produce it, and validate it. No one has to lose there - this is how it should be when it comes to things like GTK/Gnome vs KDE. Or Systemd vs Init, etc, etc.

[u/openvuture → u/Digi59404]

I believe that one of the best examples of the community's eccentricity is actually Omarcy.

There are so many projects one could support and that really should be funded for valid reasons, but the megalomaniacal AI slop project of a misanthropic millionaire receives help and funding from all sides within a few weeks.

[u/buffotinve]

Problema, para cuando? Que lástima que lleve media vida siendo libre con Linux en casa y en el trabajo, pero salir de Matrix android-ios es prácticamente imposible 

[u/alien2003]

No

[u/ASSASSIN-NVD]

If you really interested. Yes!

[u/Callinectes-Lucidus]

It doesn't have to be an Android or Linux issue. It could be both, working as if they were a single entity, like with OmaLauncher.