Some people here like iOS for the reasons you described. However I'm willing to bet, unless you can show me otherwise, that it's a vocal minority. I don't know of anyone personally who is happy that Apple disallows GPL code.

Comparing Apple's digital Fort Knox with Google's unsupervised free-for-all is a false dichotomy.

There exists a happy medium, where power users get all the freedom they want but apps are still by default beholden to certain restrictions. And this is orthogonal to a proprietary API.

Is this not the happy medium Google is trying to hit?

Power users can unlock their bootloader and do whatever they want. This is still officially supported, with vendor blobs officially provided.

By default things are restricted to deliver a happy user experience in the context of the average person that just wants a product that works. But you're free to do whatever you want. There's (usually) even controls to remove restrictions from apps manually without doing the custom ROM route, but there is always the ultimate power user toggle there of "flash a custom ROM"

Huawei recently stopped allowing bootloader unlocks.

Unlocking the bootloader is becoming increasingly rare.

To be honest, ignoring the back and forth between the discussions here, am the only one that doesn't get WHY the firebase library isn't open source? It could just be GPL right? Most of the interesting stuff happens in the backend anyway, so what's the issue.

Am I also the only one that thinks this gives google the chance to lock out/cripple third parties like huawei or other non certified android vendors from distributing Android apps that were built for the play store.

This is a bit of "you get what you buy" territory. Google's devices have official bootloader unlock capability and always have, with instructions here: https://source.android.com/setup/build/running - already updated for the Pixel 3a & 3a XL even. You take your risks when you buy something that doesn't advertise that.

> Most of the interesting stuff happens in the backend anyway, so what's the issue.

I think most of the interesting stuff on the device is even in Google Play Services and not in the firebase library. I have no idea why the client SDK can't be open source, but how much does that even matter?

This was not mentioned at any time during the purchase and they would not take my phone back.

Buying unlocked phones from the start can be an expensive downside, but being free from contracts and carrier bullshit can be a huge upside.

If google was trying to hit some sweet spot (I'm not willing to give them the benefit of the doubt here any longer) then they would not spout such obviously wrong BS to scare users into submission. Conversations and telegram both put the work into doing push notifications The Right Way (TM) so scaring users about this is stupid at best.

You don't have to be a kernel hacker to build & flash AOSP. Google has a guide on it: https://source.android.com/setup/build/running

But whether or not you consider this a "power user" or not is obviously less clear cut. How you define "power user" does of course change things. The point is just that there is the ultimate escape hatch of flashing a custom ROM, and it's not THAT hard to do, especially with all the tools out there to flash things like LineageOS super easily. You may not understand what it's doing, but it is at least sitting on officially supported things for the devices Google sells.

A bit of a tangent but I'm a "power user" and still can't get rid of the stupid warning in the beginning. Definitely not a happy medium.

Where does Apple say that GPL code isn’t allowed on the App Store? I ask entirely out of my selfish need to avoid unpleasant surprises later on.

https://forums.developer.apple.com/thread/18922

Essentially it works like it should anywhere else: If you don't publish source code and someone complains, you're out. In an ideal world Google Play would hold itself to the same standards.

However, the App Store does impart restrictions which are incompatible with GPL, so it's not so much that Apple doesn't allow it as it is that GPL doesn't allow it.

Apple has no official statement on this of course, but we know how they feel about GPL code given that they've removed every bit of it from their OS over the last few years.

E.g. Git is on GPL version 2 still (and probably forever), and Apple continues to update that in a relatively timely fashion.

See for example https://apple.stackexchange.com/questions/6109/is-it-possibl... .

This is an Apple problem, not FSF.

And this is what you call a geek bubble. In the grand scheme of things most people don’t know what the GPL is and out of those, only a minority care about it running on their phone.

No, that would be a regular No True Scotsman.

> So you have friends that are not geeks who know about the GPL and care?

Did I say that? No, I didn't say that. I said I don't know anyone who is happy that Apple disallows GPL. This includes people who have no idea what the GPL is.

With Google there is a bait and switch (and it doesn't really just apply to this particular story). They came to market defining themselves as the open alternative to Apple to get market share and developer interest (and evangelism), and now that they've achieved dominance the terms are changing.

There's no surprise that there's going to be massive pushback (and probably antitrust implications).

The reverse is also true: whatever sufficiently good product that doesn't generate money is basically doomed by them no matter how many users depend on it. (Reader, Inbox, Talk, ...)

https://www.statista.com/statistics/266572/market-share-held...

This may be an ideal solution for you but its really not for most people.

A good example of this is that there were scams that involved having people paste some script into their chrome devtools and steal data. This worked fairly effectively. Facebook ended up doing some magic to show a warning message in the devtools console to tell people that no, you really shouldn't paste random stuff here, it will do bad things.

Configurability does come with a cost. And "the ability to reroute all push notifications through an arbitrary MITM" is a security cost that I expect wouldn't be worth it.

But I actually think you are mis-portraying the situation is because I don't think the average adult has the ability to comprehend these things. It's not the difference between adults and children, but adults and expert adults.

Here are some analogies to other parts of society that we don't have a problem with:

Seat belt laws Hard hat required construction area Safety guideline in Handling of hazardous materials

We basically said society doesn't trust you to decide for yourself about your safety - you just have to follow the rule.

Part of me wants to challenge the existing groupings of adults and children where all that matter is if you have been around the sun 18 times or not. This is but one weakness in the existing grouping that furthers my questions, such as why do we allow the non-expert adults a vote over laws, but deny a 17 year old the same?

I think if you take the groups of children, adults, and expert adults you will find upon reducing them to only two groups based on similarity that you are left with experts and non-experts.

The impulse to protect people from themselves is a dangerous one. In the article itself we see that in practice it is used to push inescapable spyware.

"But our spyware is better than their spyware!"

Google says they will protect you. But the truth is they are just concern trolling to shut down marginally worse competitors.

For kids and elderly that can't make decisions on their own it could be default -locked to some entity contractually bound to good ior. Locked with an administrator password. That would be a reasonable compromise.

But yeah, if you want to avoid Google's servers, then it's not enough. But in that case, you're probably on Google-free LineageOS anyway right?

But yes, I agree, Android's competition is iOS and that's freaking sad.

1. According to the reddit post the firebase library makes no difference to battery life

2. It is perfectly possible to provide strong guarantees around battery usage and resource consumption with open source code

Unfortunately, the choices today are limited.

Let app developers and users have a choice.

And this has been my experience constantly:

- "Eh, I'll just demand full storage access for my game, it's easier to unpack files in root of sd card" - "Eh, I'll just constantly reconnect HTTP no matter what the current device state is" - "Eh, I'll just download 600mb on mobile, it's easier than checking"

There are some developers that did right by users, but enough Android devs are constantly ignoring the best practices of development and users privacy because it's "easier" and requires less code.

Because of that I fully understand Google's new stance: developers haven't proven themselves trustworthy and it seems Apple's way is the only way to defend users against abuse.

It would have been so much better if the Play Store and SDK and Android platform could have features that clearly highlight these resource-hogging apps as bad actors. That's the kind of killer feature I expect from Google. I don't feel like they're living up to their reputation for hiring brilliant programmers. Instead they're taking out a really large hammer and hitting everyone with it.

It is lying, alright.

That said, I don't think that this lying notification is the best example of Android designers being nefarious jerks. The notification lies to user about non-existing "battery drain", but it only does so when developer tries to get around the requirement to show notification with foreground Service. It is shown when you set notification to be hidden via low-priority. I have also seen it when notification icon was fully transparent. It is basically a retaliation against developer misconduct (when developer tries to run persistent background process without telling user). Ideally, this should encourage developers to show a proper foreground Service notification, which the user may consequently hide via notification settings.

(Btw, the on-device battery meter is horribly inaccurate and always has been. Multiple values, like screen power use, are hardcoded by OEM and tracking app power use is not reliable in any case because those graphs are incapable of measuring cascading power efficienty effects coming from using the radio or Play Services.

Use Battery Historian if you want more useful battery use debugging.)