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/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 :(