Comment by pizzaiolo

Waydroid can't run nearly as many Android apps as AOSP on bare metal or especially GrapheneOS with the compatibility features it provides. It's an approach with far more limited compatibility.

Waydroid has very poor privacy and security due to disabling most of the app sandbox. It's also based on an old version of LineageOS so it's missing many important privacy/security updates, but it's much more relevant that it doesn't have SELinux and exposes much more kernel attack surface to apps. SELinux is not an extra layer of security for Android but rather is used in a far more deeply integrated way than any typical desktop/server usage. It's a huge portion of the security model including the app sandbox and protecting the Linux kernel.

We greatly prefer virtual machines over a half-baked container approach disabling most of the privacy/security model. There's already hardware accelerated virtualization on all of the supported devices for GrapheneOS and we plan to make a lot more use of that in the future.

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.

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.

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

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.

They basically have opposite goals to Google so I don't imagine there will every be good feelings there. There shouldn't be.

Yes Google wants android to be secure, but the problem is that to be truly secure it should be secure from Google too. And they don't want that. They want it to be their personal datamine and walled garden. Just like Apple with ios.

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.

IE's monopoly was replaced by Chrome and Safari's, and Safari only exists because Apple gives you no choice but to use it on iOS. Firefox had a brief spot on top, but it really didn't last that long.

Windows still has the vast majority share of desktop.

Android is an open source Linux distribution for smartphones. It doesn't have to be used with Google Mobile Services. AOSP is far more private, secure, usable and compatible with a far broader amount of apps. Why wouldn't we use that as the starting point even if the goal was to diverge?

The AOSP is fully open source. What you suggest is a significant step back in terms of privacy and security.

That's a huge downgrade for privacy, security, usability, battery life and compatibility with apps. GrapheneOS is Linux too. Linux doesn't mean glibc and systemd. Linux is unfortunately not a great base for an OS focused on privacy and security but it's the only practical choice at this time. In the long term, it needs to be replaced as the bare metal kernel.

I have it. It's far too slow to be useful, and it's not the hardware's fault. GTK and Libhybris are bad separately and hot garbage together. This problem won't be going away while the hardware is relevant.

RCS is important because it provides end-to-end encryption (E2EE) for contacts with Google Messages and iOS. That means having E2EE for the vast majority of smartphone users since Google Messages is the standard GMS Android carrier-based messaging app.

https://news.ycombinator.com/item?id=49593026

It would go against our approach to choose specific messaging apps and protocols to bundle with the OS beyond SMS/MMS/RCS. We shouldn't be the ones choosing Signal vs. SimpleX vs. Element or other options but rather that's up to users to decide.

I disagree with this somewhat. Apple and Google make these sweeping decisions for their users and in effect promote one tech over another. Adopting RCS and integrating it natively, but shunning open protocols and leaving them for third party apps (with probably worse OS integration) means you are following, not leading.

I would at least consider shifting approaches somewhere down the line. Yes, there are a plethora of open messaging protocols out there, but adopting one for first party integration doesn't prevent the others from being used.

I use cheogram daily.

I remember who forced me to consider other options.