[jraph]

Because AOSP is controlled by Google and the incentives to develop an actually open platform are not there. Even the SDK to develop for it is guarded by a silly license.

That could have been a first step though, but at the risk of endangering the motivation to develop for mobile GNU/Linux and still be dependent of AOSP with nowhere to go when it really goes towards the wrong direction. More and more (essential) components are proprietary and shipped with the GApps. Even something as essential as the notification system relies on Google's servers and proprietary bits (this part has an open source re-implementation though, microG). At this point you need to recompile Android apps to avoid that… if you have access to the source code.

It's hard to fight against this direction, release after release, I think it is a lost battle.

I could live with AOSP today but I'd rather have a functional GNU/Linux environment with no bullshit in a few years.

[mschuster91]

> Even something as essential as the notification system relies on Google's servers and proprietary bits.

Agreed, but a notification broker that's usable for more than just "on-device" generation of notifications or wants to avoid every app polling constantly will always need some sort of centralized server infrastructure that costs a lot of money to develop, keep running and secure (something like "user A gets notifications intended for user B" or "attacker manages to dump notifications" must never happen).

> I could live with AOSP today but I'd rather have a functional GNU/Linux environment with no bullshit in a few years.

Same, but as long as people continue bikeshedding and insisting on complete 100% purity every such effort is doomed to fail.

[swiley-taway]

I told myself I'd stay off this site because there's so much distracting crap on here but I need to correct this one.

You don't need a notification broker unless you want to run non-free garbage. Well written apps will just service the socket they get data from just fine. This is already the way things work on Linux, the only thing missing for real time notifications is to have the network interfaces wake the device up instead of relying on eg rtc-wake.

>centralized server infrastructure that costs a lot of money to develop

Maybe but Mozilla seems to get away with doing it for free and they have way less money.

And the higher level comments are right. AOSP is absolute fucking garbage. Before Android 5 it wasn't clear if this was something intentional from Google but it's clear now. They hate people having control over their devices and are in many ways even worse than Apple here despite publishing some code.

>100% purity

Purity will be the only thing that results in success. Already the Pinephone works well enough for people who are used to desktop Linux (sans the hardware issues with the modem.)

[jraph]

Yes, I'm quite done eating Google's free lunch.

> the only thing missing for real time notifications is to have the network interfaces wake the device up instead of relying on eg rtc-wake

Waking the device up for each incoming packet would probably drain the battery. But yeah, I had descent battery life on Android without GApps with mails and two chat apps (Signal and Element) so this can't be impossible to achieve. The modem has to stay up for incoming calls, listening a few additional TCP connections is probably fine. Maybe it's less power efficient than a centralized solution but still very usable. We could also imagine a solution where the used service is configurable.

> Purity will be the only thing that results in success

If you don't enforce 100% open source, you are less incentivized to fix broken stuff and develop open source alternatives.

The "open source but not quite" niche is already fulfilled and it's LineageOS and its friends. That's already done. So nobody loses here.

[mschuster91]

> You don't need a notification broker unless you want to run non-free garbage.

Face reality: most of what the utter majority of the people on this planet use is proprietary and ffs purity bikeshedding won't lead to any success.

> Well written apps will just service the socket they get data from just fine.

The utter majority of providers use CGNAT with extremely short keepalive times for cost saving, the worst I've seen was some crap MVNO dumping connections after ten seconds idling. That means your usual phone will have 20-50 apps that all have to send keepalive data all the time meaning the modem never goes asleep and drains your battery, vs one centralized notification broker that even shoddy MVNOs configure to be exempt from frequent connection drops.

> Already the Pinephone works well enough for people who are used to desktop Linux (sans the hardware issues with the modem.)

So... like what, 3% of users given Desktop Linux market share? LOL the only ones used to Linux on desktop are either forced to do so by their employer or are utter masochists willing to overlook catastrophic flaws for the sake of purity.

[zozbot234]

If the connection dies, you just re-establish it when the device is scheduled to wake up (as directed by timers which can easily be auto-coalesced on Linux, so battery drain is a total non-issue regardless of how many apps are active). It's not a bigger issue than checking your email or refreshing your Slack/Discord/whatever.

[birdman3131]

Unless I am missing something you need a notification broker due to the very widespread usage of CGNAT on most mobile networks. There has to be a reachable outside server.

[jraph]

Nope, because your phone initiates the connection. The network knows to find your phone again when there are incoming packets from this connection. This is no different for the service broker by the way, as far as I know.