Comment by ConceitedCode

13 hours ago

What's the concern? They are working with Motorola as a manufacturer. It'll probably be a hard fork eventually but why not make it work in the meantime.

If they hard fork, a lot of apps that are generally "necessary for the average person" (e.g. Uber, banking apps, Gmail, Whatsapp/Wechat/Line) might stop working.

  • Sure, but what could graphene do in the meantime? It's either make it work for the moment or stop those apps from working today.

    I'd like to see them lay more ground work for web apps but it's a tough spot and the easiest choice at the moment is to continue with AOSP.

    • I mean we privacy nerds all love webapps but the reality is the people actually in charge of S&P500 companies hate them. They really, REALLY want to fingerprint your device and use it as a verification and tracking mechanism.

      Until that changes, webapps aren't going to sell.

      Even Google tried multiple things to "sell" the idea of webapps (e.g. Polymer project) in 2011-2015 and failed.

      Funny enough, Wechat kinda succeeded at webapps in China because there's a strong user preference to stay inside one monolithic "everything app".

      1 reply →

    • I don't want to see more groundwork for web apps. GrapheneOS is meant to be secure, which means running trusted apps on-device. My messages are less secure if they permanently are stored on a server.

  • Yes, but there is no alternative other than giving up. Starting a new OS from scratch with zero apps is a much worse starting point compared to a platform where 99.9% of apps work (minus those relying on Play Integrity with strong integrity) which may have its rug pulled in the future. The race here is about getting to a big enough market share that GrapheneOS cannot just be ignored as completely niche but has to be treated as a small but not insignificant minority.

  • It's not ideal, but in the case a hard fork happens, they could implement the same APIs and most apps will probably continue to work. Similar to how microG is a replacement for Play Services and still works for most apps (not as well as sandboxed Google Play of course).

    Above that, not much would change for a few years anyway, because apps still target ancient Android versions.

Seriously, I don't see a mediocre android provider like Motorola running and maintaining a hard fork.

Forking is all easy, keeping it up to date year after year as codebases diverge is a whole different story.

I could see Samsung doing it. But they won't, they're too good buddies with Google. But they have the resources. A Motorola no. The grapheneos team won't either, maintaining a disparate fork and introducing new features independently from aosp would just be beyond their scope. You're not just hardening at that point. You're basically doing everything.

Don't forget when Huawei didn't fork. Well they started with that but then replaced every component with their own design. It's easier because if you fork you're still bound by decisions made by the original party. Better to greenfield the whole thing then.

And look at how many people made a soft fork of chrome with some ui changes. There's tons of those. There's no hard fork that no longer follows Google. Even a large company like Microsoft didn't.

  • I think graphene could maintain a hard fork with manufacturer support (Motorola). At least for a while. Long term viability is an open question.

    • They could for a while but what's the point if it's not sustainable? Google is not going to turn around and make it more open again.

      With every Android release you will build up more feature base to replicate. Unless you cut all ties and drive a separate ecosystem but good luck getting enough developers to buy into that.

      3 replies →

[flagged]

  • We've collaborated with many Google engineers working on Android. Many of their engineers, security researchers and even people in management positions follow us on social media. One person who describes themselves as an AOSP engineer on Hacker News doesn't reflect what their overall engineering team thinks about GrapheneOS. This person likely also finds the security engineers at Google complaining about the same things and pushing for improvements annoying too.

  • One AOSP engineer.

    Google is the one making bad actions, which it makes sense to complain about. They moved to building in private so forks don't get features as they come and more recently they stopped providing certain source code in a timely manner.