Hacker News Reader

Comment by drnick1 | Hacker News Reader

I think the crucial issue here is Android app compatibility. Desktop Linux programs aren't suited for use on mobile devices; the experience is inevitably poor. Android compatibility is claimed, but no information beyond that is provided. If this device does not run at the very least any app that does not depend on Google Play, e.g. apps from F-Droid, it's dead on arrival. In that case, you are much better off with a Pixel running GrapheneOS. Graphene is very polished and has 100% compatibility with Android. Everything just works and the user experience is as good as an official Android device, only free of Google spyware.

View on HN

> If this device does not run at the very least any app that does not depend on Google Play, e.g. apps from F-Droid

It does.

I have an FLX1, a review sample.

https://www.theregister.com/2025/02/03/furiphone_flx1/

I had 3 app stores on mine: Amazon, F-Droid, and Aurora. Apps from all 3 worked.

"I think the crucial issue here is Android app compatibility ..."

I thought there was a robust android emulator for linux such that I could run android apps - and call an Uber or whatever - from desktop linux ...

Is that not so ?

>I thought there was a robust android emulator for linux such that I could run android apps - and call an Uber or whatever - from desktop linux ...

There are some but not really great and it will become impossible very soon with remote attestation and play integrity. Already Uber is one of the few apps that have the hardware attestation keys for grapheneos manually added.

In my experience, Waydroid works very well actually. The question is whether it wouldn't just be simpler and better to use AOSP (or Graphene) as the OS for these phones. In principle, a "Linux phone" sounds great, until you realize that there are close to zero Linux programs that are actually usable on a small touch display. The Android project already has done the hard work of adapting Linux to mobile devices and FOSS apps are plentiful and polished. The problem with the common variety of Android phones is control by Google, not the underlying tech.

Wait, many people are complaining that PC applications and websites are designed with a touch screen / mobile in mind... Think about the UI, huge spacing, etc. So which is it?

> close to zero Linux programs that are actually usable on a small touch display

Beg to differ: https://linuxphoneapps.org/

(And no, that does not list all of them. Only all I got around to adding.)

Fair enough, but how many of these are as polished as their Android counterparts? How many are still actively maintained and will be for the foreseeable future? Android already is "Linux for mobile devices" and has all the features people expect from a phone. Reinventing the wheel on the software side seems counterproductive when what we need is simply more hardware to run Android on. I wish Furi collaborated with Graphene or Lineage and released a proper FLOSS Android device instead of going the "desktop Linux" route.

AFAIK GrapheneOS is in the talks with a hardware company and we may end up with a GrapheneOS-first device!

Yeah everything works except payment, and banking apps, and probably some other stuff. Considering Google's policy direction this isn't going to improve sadly

You can't use Google Pay obviously if the phone is de-Googled. That's a good thing IMO, the last thing I want is Google tracking how I spend my money. Carrying a credit card in a wallet case with my phone is a very minor inconvenience.

The Bank of America app runs on Graphene without issues however. So generally speaking it is not true that banking apps don't run on de-Googled phones. Here it is the developers that are to blame if they enforce compliance with Google's requirements and don't stick to the basic FOSS version of the OS.

My banking app works without any issues, but I do have google play enabled.

To be precise, there's an Android API called Play Integrity that defines a device's integrity. This integrity can be STRONG, DEVICE, BASIC, and no integrity.

GrapheneOS can only pass a check for BASIC integrity. It cannot pass a check for DEVICE or STRONG integrity.

STRONG integrity is hardware-backed (think TPM) and is not spoofable. DEVICE integrity can be spoofed and there are tools to do it, if you root your device, but Graphene does not want to this for various reasons. [1]

It is up to the developer of every app to choose to use this API or not, and to lock some or all of the features of their app behind this API.

GrapheneOS actually supports hardware integrity (the STRONG variant), but in a particular way. Every OS integrity API (including eg. Secure Boot) is based on a list of master keys, that are installed with every computer. Users that want to install custom operating system that are not signed by a major company will have to enroll their own keys into the Secure Boot system.

Hardware integrity also requires root keys, and those are owned by Google. But the API is actually general enough to allow both a "Verified" (signed by a root Google key) and "SelfSigned" custom keys. GrapheneOS provides a guide [2] that describes how to adapt the hardware integrity checks to accept either a Verified key or a SelfSigned key from a list of keys from GrapheneOS.

There is no reason why app developers should not accept operating systems signed by GrapheneOS just like those signed by Google, for the simple reason that it provides the exact same anti-tamper protection.

Note that all this anti-tamper protection is, in the end, an effort to protect users from others hacking their devices and gaining access to their apps. These measures do not help companies per-se, since user commands should ALWAYS be verified server-side.

[1]: "they use fingerprinting techniques such as GPU fingerprinting and send along that data, which enables detecting and banning spoofing. It is NOT practical to pretend to pass these checks. It is only possible in the short term at a small scale. It will get banned and stop working."

[2]: https://grapheneos.org/articles/attestation-compatibility-gu...

>Note that all this anti-tamper protection is, in the end, an effort to protect users from others hacking their devices and gaining access to their apps. These measures do not help companies per-se, since user commands should ALWAYS be verified server-side.

This is the stated reason, but the behavior of it is anything but: if they really cared, they would fail massively outdated versions of android that have critical remotely exploitable vulnerabilities, but they do not. It is also much easier to tamper with a ROM slightly and have a version that passes these checks, compared to having a secure, up-to-date, maintainable ROM that passes.

And let's be honest, it's not like there hasn't been spent a decade or more, with thousands of developers working tirelessly on making Android as good as it is today. Like linux laptops not burning up immediately is itself a change upstreamed from android development, but that's just half of the story.

A mobile OS fundamentally needs a different application model -- apps can't just decide to run whenever they like. How will desktop GIMP know that it shouldn't waste my battery when in the background (unless it very specially requests it throuhg an API made just for that)? Does suspending it work as you expect? For how long will you suspend it, shouldn't you kill it as well after a while? Who saves stuff?

I can't help but feel that anyone strongly advocating for a GNU Linux phone (because let's be honest, Android is the linux phone) is just not familiar with the actual context of what it entails.

No one is running gimp on their phone, besides for laughs. There are a number mobile-centric apps in the repos, stick to them and you'll be fine.

The issue is that the mobile-centric apps are few and far fetween, and not nearly as polished as the Android ecosystem.

I maintain a project [1] that tries to collect and track them all, and ... at least for keeping track of how they all develop, there's not a few apps. ;-)

[1]: https://linuxphoneapps.org/apps/

You currently list 720 apps, Google Play Store has 3.3 million.

Even if we assume that a good chunk of that may be "duplicate" in terms of functionality (e.g. todo apps), that is still just a completely different dimension of apps and use cases covered by android natively.

I don't recommend using the vast majority of mobile apps, which exist for data-mining and addiction-maintenance purposes. Android is specifically known as the worst ecosystem in this regard. Browsers continue to work, despite the corporate push to dark patterns.

It's Linux, if you need something you or someone else will eventually write it. But first there needs to be acceptable, working hardware. Enter the FLX1/s, and we come full circle.

Sure, the majority of mobile apps suck. But even then, 1% of it is still orders of magnitude larger than the number of "Linux" apps, and there are surely more actually decent mobile apps than that.

Besides, open-source doesn't have to be GNU, there are a bunch of open source apps on F-Droid.

(See cousin comment.)

I don't need more than a handful of apps, one being a browser. These already exist.

I also reject non-free apps whose main purpose is to snoop on their users like Facebook. But what about dozens of FOSS projects like Home Assistant, Jellyfin, Nextcloud, KeePass and many others? All of these have polished clients that work perfectly on Android and provide an experience that rivals or surpasses commercial offerings. They took years to develop and I don't expect Linux phone versions will ever be released because of the chicken and egg problem. You can emulate these apps with Waydroid on a Linux device, but you will almost certainly lose some features like GPS access or notifications. At the end of the day, you will mainly be running Android apps anyway, free or non-free, so you are better off with an Android device in the first place.

I currently use 0 Android apps, so honestly believe one could survive without them.

I'm glad Waydroid is a thing for folks that are, and sorry attestation prevents full compatibility. But neither issue should get in the way of investment in modern Linux phones, which I've been desperately waiting for, for years.

Web apps are still a thing as well, believe it or not.

Fair point!

That said, Google Play is not really the thing to compare this too. F-Droid could be. Summing up the "Show all ..." counts, F-Droid clocks in at 6147 apps, and it started way earlier (2009? 2010?).

Some of these F-Droid apps (specifically those created in QtQuick or Flutter) should also run with very minor tweaks on #MobileLinux.

Also, there's more than these 720, some are just very hard to evaluate (because they are for hardware or services I don't have/use), which then keeps me from adding these apps.

Reply on news.ycombinator.com