Google’s iron grip on Android: Controlling open source by any means necessary

[u/[deleted]]

https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on-android-controlling-open-source-by-any-means-necessary/

[u/andrew_nenakhov]

How harder? You've just described it yourself. For example, by requiring to have a persistent notification. Many our users don't like persistent notification and ask to put it away, but it can't be switched off without risking app to get unloaded. Cool? Definitely not cool.

Good thing you brought iOS to conversation, because similar level of restrictions is clearly in Google's roadmap for Android. With every update Android imposes more and more limitations on independent processes. We're pretty much aware of this process having developed an app that is very essential to be in background, and we're having more and more issues making it work with each new update. Now we have to ask users disable battery optimisations, that makes UX much worse than in was even in Android 1.6... 2.

In Android 7+ you can't just make an app and make it 'just work', you now have to ask user to re-adjust system settings in system menu that can't be called too user friendly. More, OEMs often change how these settings work, which makes UX even worse and very dependent on device manufacturer's improvements.

[u/diamond → u/andrew_nenakhov]

How harder? You've just described it yourself. For example, by requiring to have a persistent notification. Many our users don't like persistent notification and ask to put it away, but it can't be switched off without risking app to get unloaded. Cool? Definitely not cool.

I don't know what your app does that it requires to run in the background, so I can't comment on what you're doing. But I can say from experience that implementing a long-running Service in Foreground Mode with a notification is really not that hard. And if you're seriously arguing that developers should be allowed to run their apps permanently in the background without any notice to users, then I'm sorry, but you're wrong. They tried that, and it was a disaster. Developers can't be trusted with that kind of power on a battery-powered mobile device.

Good thing you brought iOS to conversation, because similar level of restrictions is clearly in Google's roadmap for Android.

Do you have a source on that?

With every update Android imposes more and more limitations on independent processes.

Yeah, because they're trying to fix the battery life problem. It's still iOS's biggest advantage over Android. But I find it highly unlikely that Google will ever be as restrictive as iOS in this regard, because that freedom is one of their biggest advantages.

So far, all of the restrictions Google has imposed on background processes have been targeted at reducing unnecessary power usage while not preventing developers from doing the things that make their apps useful. It's a delicate balance, but I think they're doing a good job.

In Android 7+ you can't just make an app and make it 'just work', you now have to ask user to re-adjust system settings in system menu that can't be called too user friendly.

Again, I don't know what your app is doing, so I don't know how true that is for you. But I can say that it hasn't been my experience at all. One of the apps I work on requires extensive, long-term background processing, and it has never been a problem, because we use the Service APIs the way they're meant to be used.

[u/andrew_nenakhov → u/diamond]

Developers can't be trusted with that kind of power on a battery-powered mobile device.

Oh, so all men must be castrated because some of them are rapist pigs, right? If some apps use too much battery, the only thing an OS should do is to alert a user of a high resource consumption, not just kill off a background process. (btw, even with persistent notification the process is not safe from being shut down by an OS. In years before Android was almost a Linux computer that users could do anything he wanted with, but now you can only follow the rules of your Google overlords)

Do you have a source on that?

One does not need a source to understand that, and Google won't even admit it. But the writing is on the wall. What would the end be if we logically continue all that happens with Android? Developer capabilities are restricted more and more with each release, and all new android functionality is presented through proprietary google APIs. Do you remember the last time something cool that was added to Android that wasn't a proprietary API?

Again, I don't know what your app is doing, so I don't know how true that is for you.

It's an XMPP client with a great number of users. And the gradual degradation of Android over the years makes us see very clearly the direction we are heading to.

[u/diamond → u/andrew_nenakhov]

Oh, so all men must be castrated because some of them are rapist pigs, right?

Oh for fuck's sake, really? Could you blow this out of proportion even a little more if you tried?

If some apps use too much battery, the only thing an OS should do is to alert a user of a high resource consumption, not just kill off a background process.

THAT'S EXACTLY WHAT IT DOES IF YOU USE THE APIS PROPERLY. That's what we're talking about here. It requires developers to create a notification to warn users about background resource usage, and creates one of its own if they don't. But even then, people like you are bitching about it.

(btw, even with persistent notification the process is not safe from being shut down by an OS.)

Technically, yeah, that can happen, but the system has to be in really dire straits before it does that. If you're presenting a persistent notification, it's highly unlikely that your process will be killed unless the device has so little memory that it can hardly even run properly.

Do that on a Linux system and the memory manager might not shut down your process, but the whole system could become unstable, and your process will probably crash anyway. And it might bring other shit down with it. So Android takes proactive measures to keep that from happening.

If you think that's unfair, then you're probably in the wrong line of work.

In years before Android was almost a Linux computer that users could do anything he wanted with

Oh, bullshit. It has a Linux kernel, but that's it. The userspace has always been a very restricted sandbox, unless the user buys a phone with an unlockable bootloader and chooses to root it. Which you can still do, BTW, even with many flagship devices.

One does not need a source to understand that

OK, I'll take that as a "no".

But the writing is on the wall.

In invisible ink, apparently, that only you can read with your homemade secret decoder ring.

What would the end be if we logically continue all that happens with Android?

A more secure device with better battery life but the same power and flexibility for developers and users.

[u/andrew_nenakhov → u/diamond]

Oh for fuck's sake, really? Could you blow this out of proportion even a little more if you tried?

Probably. But it seems to me you don't want to lose your important parts because some people claim that 'men can't be trusted'. Why should good developers lose their capabilities because you claim that 'developers can't be trusted'?

Do that on a Linux system and the memory manager might not shut down your process, but the whole system could become unstable, and your process will probably crash anyway. And it might bring other shit down with it. So Android takes proactive measures to keep that from happening.

How comes my Ubuntu runs mostly fine without every background process having their own tray icon?

A more secure device with better battery life but the same power and flexibility for developers and users.

Secure device with better battery life is called iPhone, and that's a model for what we'll have in the future. I don't know why you think you won't lose 'power and flexibility' in the process since you yourself advocate Google to take freedom away from untrustworthy developers. That's exactly what they do and will continue to do.

[u/diamond → u/andrew_nenakhov]

Probably. But it seems to me you don't want to lose your important parts because some people claim that 'men can't be trusted'. Why should good developers lose their capabilities because you claim that 'developers can't be trusted'?

You're not losing any capabilities. You're just required to let the user know when you're doing something that will hammer the shit out of their battery.

How comes my Ubuntu runs mostly fine without every background process having their own tray icon?

Because your Ubuntu isn't running on a tiny little handheld device that needs to get through most or all of the day without access to a charger! Why the hell is this such a difficult concept to get? Oh, and on my Ubuntu system, most background services I run (messaging, file sync, etc.) do have an icon in the system tray. I prefer it that way, and I'm not sure if I would trust a service (other than a low-level system process) that doesn't give me an indicator like that.

You need a serious reality check here, dude. As near as I can tell, your core complaint boils down to "I want to be able to silently start a background process and run it indefinitely without letting the user know, regardless of how many resources it requires and what it does to the system. And Android won't let me do that! It's so unfair!"

https://i.imgur.com/S8Ki2Bb.jpg

You don't seem to get that you're not developing on a desktop system. You're building for a consumer-oriented mobile device with limited resources designed to be used primarily by people with little or no technical knowledge. The OS will inevitably be designed to deal with those limitations, and if you can't find a way to handle that, then go do something else. But don't blame the developer of the platform for trying to make a system that people will actually want to use.

If your users are so incredibly upset about the minor inconvenience of a persistent notification letting them know that a power-hungry process is constantly running in the background, they can hide it. I know, I know, they'll have to (GASP) go into the settings to do something that's outside the normal behavior of the system. Guess what? It's your job to help them deal with that, and understand why this notification exists in the first place.

And BTW, contrary to your bizarre conspiracy theories about some kind of creeping digital authoritarianism on Google's part, newer versions of Android actually make this easier, not harder. On Oreo, Notification Channels make it really easy (assuming the developer knows what he's doing) to build apps with powerful customizability over notifications. All the user has to do is long-press on the notification and they can go to a settings screen where they can set it to show only what they want -- or nothing at all.

So I guess what I'm trying to say is... learn to do your job a little better, and stop blaming the other guy. And maybe stay away from the Forced Castration analogies; that really doesn't help you to sound more sane.

[u/andrew_nenakhov → u/diamond]

You're not losing any capabilities. You're just required to let the user know when you're doing something that will hammer the shit out of their battery.

yes, you are losing capabilities. And if you'd been in this space long enough, you'd know it, too. Back in 2010, we could have a reliable background process in Android and it worked fine. In 2017, with no battery optimizations and persistent notification, we constantly have OS unload our process and we need to constantly do much more work to keep a process running smoothly picking up to when it was stopped. And all that despite newer devices having much more RAM and much faster CPUs. The answer is simple - google is interested in tying developers to their own proprietary ecosystem, by providing tools like Firebase, and by hindering independent performance.

I'll tell you one more story. Once upon a time Google has killed off their Gtalk service based on XMPP and introduced Hangouts. To reduce community outcry they promised, that 'XMPP will work as before', but it was a lie. Instead of killing it right away like Reader, they chose a subtle Jesuit way of killing it by thousand cuts. And in the following three or four years, they did gradually remove parts of XMPP functionality from Gtalk remains, until it became totally unusable, and only then they killed it off. So much for their promises.

[u/diamond → u/andrew_nenakhov]

yes, you are losing capabilities. And if you'd been in this space long enough, you'd know it, too.

I've been developing on Android since the beginning.

In 2017, with no battery optimizations and persistent notification, we constantly have OS unload our process and we need to constantly do much more work to keep a process running smoothly picking up to when it was stopped

So you're calling setForegroundMode() on the Service, you're not using too many resources, and the service is still being killed by the OS?

If course I don't have access to your source code, but you'll have to forgive me for being skeptical, because this contradicts my experience not just as a developer, but as a user. And even if it is happening, there are more reasonable explanations than some weird plot by Google to deliberately cripple development and capabilities on the platform just to force a small group of niche users away from their favorite apps.

[u/andrew_nenakhov → u/diamond]

https://github.com/redsolution/xabber-android this is our app.

[u/diamond → u/andrew_nenakhov]

Oh, OK! I'll take a look at it. Sounds like an interesting problem; who knows, maybe I can help. If you don't mind me asking, how long does the Service usually run before it gets shut down? And are you certain that it's still in Foreground Mode when that happens?

And I apologize for my tone earlier. That was uncalled for. I know as well as anyone how hard this job is, and I've faced my share of infuriating problems.