Some people (like myself) prefer the desktop userland which is more familiar and works like you would expect as opposed to the android quirks.

eOS is basically what you are looking for for most phones or GrapheneOS (pixel only)

> That's already happening today.

That's not a hard fork. They always rebase on top of AOSP when there's a new AOSP source release

There is no reason to hard fork, as long as Google contributes to AOSP without breaking it.

Regulators in the US decided that Android did not have to be split from Google, but they could theoretically decide that Google is not allowed to break AOSP to gain a competitive advantage. Not that it would matter: TooBigTech is too powerful to care about regulations anyway.

Nobody really want a hard fork, if you can't run Android apps, you might as well use a Linux distribution.

Well the idea would be to run Android apps on the hard fork :-).

If you can run Android apps then you need the same behavior as AOSP or I'm missing something?

If you don't rebase from AOSP, the apps won't run pretty quickly.

I actually wonder: if Google stopped pushing to AOSP and "the community" had to fork... the whole Android SDK/NDK is not open source, so I wonder if AOSP could survive at all without Google, even though it is open source.

I think if Google would stop pushing AOSP, there's a very high risk for Google that a consortium of manufacturers would continue themselves as they need it and they would lose control.

I think that is unlikely reality because from manufacturers perspective they don't get AOSP from the public. They get it from their chip provider like Qualcomm who gets private releases from Google. Everything is already set up such that people aren't using the public version, so the more likely reality is that the public version goes away, and google partners keep doing what they are doing. Maybe things are different on the Chinese side of things. So if it were to be created, it would be over there.

Would they, though? Like Huawei forked for a while, and then they made their proprietary HarmonyOS.

For a while I thought it was a missed opportunity to compete on a hard fork, but then I realised that Huawei probably cannot fork the Android SDK/NDK because it's not open source.

It doesn't have to be. Most of Android is fine.

Outside of China, to a first approximation no one once to use an Android device without Google Play Services.

I would love to, for the record.

I really wanted to like Graphene OS but I ended up bouncing off it due to a few major pain points that badly effected battery life.

- Using the default 5g setting resulted in far worse battery life than stock, telling people to choose 4g isn't a solution. They desperately need something like the adaptive connectivity service.

- Using Homeassistant's GPS tracking feature just destroyed the battery life, even switching to 4g didn't solve this issue. Changing all the GPS settings didn't help either.

- The obnoxious green GPS active icon makes the notification bar useless if using a GPS tracking app (or even gps navigation). The request for a whitelist was either ignored or rejected, the teams communication can come off a bit rough.

No normal user is going to be happy with Grapheneos. From what I've seen postmarketos is much more user friendly.

I don't know what to say about your battery life issue, other than that I don't have any such problems.

What's obnoxious about the green GPS icon? How does it make the notification bar useless? It is on all the time while I'm using Google Maps, it's small and not in the way and is a good reminder if I have accidentally left Google Maps open in the background. What's the problem?

I don't recognise the 5g battery life issues personally. I do 100% agree the GPS thing is such a bad decision. It just becomes noise that no one pays attention to anymore.

I ended up using my public ip address in combination with a list of known ips for home and work and such, and building my HA automations around that. I wanted to do it with wifi SSID's, but that also requires the location permission and triggers the indicator (which is understandable, just wish I could still read SSID's with location services disabled entirely) (or, just let me disable the gps antenna and leave everything else).

> I do 100% agree the GPS thing is such a bad decision. It just becomes noise that no one pays attention to anymore.

It's not noise for me, I only ever have GPS on for Google Maps, and I like the indicator because its absence reassures me that nothing is using GPS in the background.

I also want to have audible notification or, even better, a loud siren when GPS, or WiFi are activated without my direct action. Sadly, SafeDot doesn't work properly on Graphene.

It certainly could be something else other than 5g but it's one of the first things that gets thrown around when battery drain is mentioned and the mobile internet was the main user of power on the phone.

I'd wager nobody on HN is a normal user. If you know what AOSP is, you are already way too nerdy to qualify.

You are very fortunate for not hitting any edge cases, but sorry anyone commenting here typically isn't anywhere near to what you could call a "normal user". I ran into quite few minor issues with the enhanced security settings, my partner would never been able to figure out the solution to that issue and I consider them a normal user.

Not to mention the 5g battery drain is a hard show stopper, not just Homeassistant issues. I even experimented with different apps like owntracks but same problem with GPS.

I found a solution to the GPS icon but it requires an ADB command so not a great fix.

How is Postmarket OS antiquated ? Its just a standard Linux distro (unlike anything Android based).

At least in regards to the security model, it is decades out of date. For example any app can listen to your microphone and spy on you at anytime. Programs can act as ransomeware or destroy all of your files. Stealers can steal your login credentials and access tokens for all your sites including banking ones.

I think people don't realize how inadequate the Unix security model is.

Linux doesn't solely rely on the Unix security model. Linux security is mostly based on trust, the trust of the distribution and its maintainers. But if you want to run random, untrusted apps you'll want a different model. Linux is slowly addressing that need w/ a variety of different approaches which could be picked up and used for a mobile OS.

Well, isn't the idea that you use apps compiled from source by distro maintainers, which are separate from the upstream maintainers ?

Frankly, I still trust this model much more than black box Android apps automatically updating in the background, sending tons of telemetry and demanding random permissions so they can spy on you.

Not to mention the security model preventing many useful things from working properly (try to get a SFTP working on an Android system so that you can copy out photos taken by the phones camera.

>isn't the idea that you use apps compiled from source by distro maintainers

That might work if the main danger was upstream maintainers with bad intentions. But the main danger is security holes that no upstream or distro maintainer knows about, which allow attacks by parties that are not open-source maintainers.

Big picture is that GrapheneOS is much, much more secure than PostmarketOS.

Meaning, it's a way to keep old hardware running linux instead of being a phone.

...except in virtually any case where you'd run something untrusted there you'd use Flatpak or something similar where what you wrote doesn't apply.

> untrusted

I think the important distinction is _everything_ should be considered untrusted because even trustworthy software can become malicious. For example, the XZ Utils backdoor[0].

On Android, everything I run is subject to the permission model and sandboxed. That is not the case on Linux.

[0] https://en.wikipedia.org/wiki/XZ_Utils_backdoor

It's not the case on Android either and it could be subjected to a XZ-like backdoor just as anything else.

Could you be more specific on how to circumvent the android permission model + sandbox? So far I have only thought of two ways an XZ-like backdoor could circumvent that:

1. By being baked into the OS itself, which is unavoidable since the OS is the thing providing the sandboxing + security model. It still massively reduces the attack surface.

2. By being run through the android debug bridge, which is far from normal and something users have to explicitly enable. Leaving you the option to shoot yourself in the foot in an opt-in manner 99.9% of users will never touch isn't the same as Linux where foot-shooting is the default.

The defining aspect of the XZ backdoor was that it was baked into the OS itself, being linked into memory space by about half of the system and activated by being packaged in a specific way in a specific distribution. If you wanted to ignore 1), you would have to choose a different example.

If you want to confine yourself in a sandbox, feel free to do it. The past decades have demonstrated that it's only necessary for some specific threat models.

> If you want to confine yourself in a sandbox, feel free to do it.

I want to confine apps in a sandbox. Android has that, Linux... well not really. I mean "it's possible", but it's not integrated like in Android.

>where what you wrote doesn't apply

You can configure your flatpak app so that it will have permission to read microphone in the background or have full access to the disk. Many flatpaks of real apps request dangerous permissions that users have been conditioned to ignore. For example Blender is such an app which has full disk access and background microphone access, and I'm sure many people have installed that. This is unlike Android where these are locked down for every app.

...and if you want an Android app to actually be able to do something useful, you give it root permissions and completely bypass the permission model.

The world isn't black and white. Most reasons why Android apps are being so heavily locked down don't apply to Blender. As a user, I'm not interested in Android-bis - if I were, I would just use Android after all. Nevertheless, things like Flatpak give me, the user, the power over application's permissions and I can take them away (or give more) in a few taps at will. The defaults being tuned for different use cases and threat models are not "being decades out of date", especially when you could already use the existing tooling to replicate other models - regardless of whether you happen to like these defaults or whether they fit your specific use case.

>you give it root permissions

This is not possible on a device following the Android security model. Permissioned features should always be implemented using proper security mechanisms like permissions.

>don't apply to Blender

You say that until the SuperRetopologyTools5000.py addon you try out infects your system.

>Flatpak give me, the user, the power over application's permission

Most people are not going to bother with this. It's important for the defaults to be secure. People shouldn't have to opt in to a secure experience, and doing so shouldn't break the program.

> This is not possible on a device following the Android security model.

Yes, that's the user experience on such devices. "This is not possible on a device following the Android security model, either bypass it or use another device".

One of the other appeals of the Android ecosystem was a large selection of hardware for user-specific needs. GrapheneOS only supports Google Pixel phones which do not compare to the sorts of hardware postmarketOS or other Linux OS support.

or they already have hardware which postmarketOS supports and grapheneOS does not (or they would just prefer that hardware)