← Back to context

Comment by drnick1

5 months ago

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.

24 comments

drnick1

Reply
rsync  5 months ago

"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 ?

  • IlikeKitties  5 months ago

    >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.

    • drnick1  5 months ago

      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.

      4 replies →

lta  5 months ago

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

  • serbuvlad  5 months ago

    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...

    • rcxdude  5 months ago

      >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.

  • drnick1  5 months ago

    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.

gf000  5 months ago

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.

  • mixmastamyk  5 months ago

    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.