logoalt Hacker News

microtonal • today at 6:13 AM • 8 replies • view on HN

No, they won't become a viable alternative:

- Worse compatibility with the millions of Android apps already out there.

- Hardware vendors (outside Apple) all target Android.

- The usability of Android/iOS is far better than non-Android Linux phones.

- The security of non-Android Linux phones is in a bad state (e.g. lacking proper app sandboxing). Heck, even the Android emulation layers that some of these phones have, throw the strong Android sandbox model out of the window.

The answer is very obvious and it is AOSP. Even though Google is trying to close AOSP more (e.g. by not pushing source continuously to the AOSP Git repos and keeping QPR1/3 for themselves), it is still an open source system. Play Services can either be run sandboxed or emulated with microG. AOSP allows alternative systems to hit the ground running, you get great app compatibility, a tested security model, great usability, and support from hardware vendors, including vendors that are alternative friendly (used to be Pixel, now Motorola, Fairphone, etc.). If ever needed, AOSP could be forked and it would still be leagues ahead of non-Android Linux phones.

All the downsides that apply to AOSP-based systems (like things getting blocked by Play Integrity, unlockable bootloaders) also apply to non-Android Linux systems.


Replies

apatheticonion • today at 6:23 AM

The lack of polish is a function of the inability to use the hardware. The hardware is tightly gatekept so competition _cannot_ exist. Regulators are the only ones who can force vendors to distribute documentation for and unlock their hardware.

Once we can actually target the hardware, open source alternatives will be much better than first party options.

You can already see the potential in the open source world.

Linux has Waydroid so Android apps can be run on Linux at full speed without emulation. That means, if you had a Linux phone, you have the entire Android library - the only thing lacking is the launcher. How hard is a launcher to program? It's just Steam's big picture mode.

Other examples of the nice things we can't have; FEX lets you run Steam games on phone hardware. Open source drivers can unlock displayport over USBC. Instantly your phone becomes a thin client / laptop replacement that can play PC games (poorly, but 1080p games are possible).

We are _not allowed_ to do these things. I love OS development and, if I was allowed, I'd make iOS look like janky trash.

➕ show 5 replies
drnick1 • today at 7:08 AM

> Play Services can either be run sandboxed or emulated with microG.

Play Services is absolutely not needed for a usable Android experience. I am running GrapheneOS without any Google crap and you could not pay me to do so.

➕ show 4 replies
norman784 • today at 8:53 AM

> Worse compatibility with the millions of Android apps already out there.

Most of the apps on Android and iOS aren't necessarily useful.

opengears • today at 6:46 AM

Actually, with the recent advances in LLMs - they could. If people start to reverse their phones and upstream to Linux, we would not need the hardware vendors to support their own hardware even.

commandersaki • today at 9:10 AM

Do any Linux phones or even GrapheneOS phones have a secure enclave/TEE?

➕ show 2 replies
Quartzium • today at 7:14 AM

>The answer is very obvious and it is AOSP

I disagree. Working on AOSP with Google having so much control of it is just a waste of time. You have no guarantees what you are working for, in the future.

I'd go full Linux, the effort is worth it and will pay out in the future. Google has the AOSP project by the balls and it's a very high risk investing anything into it, as a developer.

With today's LLM tech might as well do something nice with Linux.

➕ show 2 replies
pilooch • today at 6:47 AM

Apps may just well go away with llms and agents.

➕ show 1 reply
preisschild • today at 8:03 AM

> If ever needed, AOSP could be forked and it would still be leagues ahead of non-Android Linux phones.

I agree and thus donate to independent AOSP development (such as GrapheneOS).

It would probably be a great idea to replace many android components with components from the linux userspace ecosystem so that more code sharing between desktop linux distros and this is possible