Hacker News Reader

Comment by ogre_codes | Hacker News Reader

> Instead, they have this warped reasoning where they don't allow any program to run in background, except theirs, "to save the battery".

Looking at the landscape of shit software out there, I find this justification entirely plausible. If iOS & Android didn't lock this down, phones would be running 4-5 different poorly implemented push platforms (or more). Battery performance on mobile would be utter crap.

There is a big balancing act going on here. People want phones that do the thing they are supposed to do. They also want battery life to be excellent and the device to be secure by default. It's impossible to give 3rd party devs 100% access and meet those 2 demands.

View on HN

I imagine without restrictions on background working most people's phones would be busily mining cryptocurrency by now.

Why couldn't the OS simply surface a push notification of its own, that app X is consuming lots of CPU?

And have such malware figure out the threshold, and throttle themselves just slightly under it.

Then give us a control to adjust the threshold.

How many end users prefer to adjust their phone background CPU activity alert threshold just so that some developers can use a different push notification framework?

Story seems pretty much the same with Web push notifications. You send a json to the temporary url provided by the browser push api.

1. From client get a push url.

2. Pass that to your app server for future use.

3. Send notification json to that url.

4. That url points to the specific browser vendor's Push notification server, and when it recieves a notification from your app server. It relays the message to the client.

And that url is different for different browsers.

Firefox - https://mozilla-push-service.readthedocs.io/en/latest/

Chrome - uses FCM

Can't configure a custom push server endpoint, like self hosted server without shipping your own browser.

It sucks that mainstream os'es have spent the last decade on a race to the bottom, to control & reduce possibility.

There are bad actors abound but many users were navigating the environment semi-ok, checking for information on how bad their apps were acting.

The clampdown is both for the user but also enormously user hostile. We can try to pin down how justified or not it is, but it bloody sucks either way & I am worried, really worried, with current events like Mozilla & Apple teaming up to decry webmidi & ambient light sensing as enemies. Yes they have some risk? But mostly this comes off as farce to me, & spun with heavy marketing "be afraid" FUD.

Not clamping dawn is user hostile. These are phones and messaging platforms that are under constant attack by bad actors. Semi-ok means the bad actors have succeeded many times on hundreds of millions of devices.

Stop mistaking your unique desires for those of the vast majority of smartphone users. Very few care about alternate push notification services, or sideloading, they are happy to use the default app stores and services.

You're being close minded. Neither of us have any idea what would have happened if computing was left open, if the doors didn't keep getting closed, & the presumption that I'm greedy & everyone want & must have stupid, as not just a foregone conclusion, but that this was the only possible path towards that conclusion, that no space could have been created, is tragic to see in people.

Looking at the piles of malware which litter the Windows PC world and the web, we have a pretty good idea of what would have happened if smartphones were left wide open. Also, Android started far more open than it is now. Over the years been getting more and more restrictive in terms of security because privileges were abused. In the early years Android battery life was particularly bad because of bad performing software.

Even with the restrictions in place, Facebook and other apps have been caught abusing privileges to get more CPU rights and burn up battery life (and get collect user information).

This post just landed, & it's a glorious takedown of this clutching of pearls desperate "we need lockdown!!!" close mindedness,

https://cheapskatesguide.org/articles/techno-cage.html

There has to be space for more. General purpose computing getting snuffed out under the new security regime is accepting the abyss, & we must strive for more.

Yeah we would, it’s call the Linux desktop.

I'd say that things would get terrible if Linux were the popular OS, that we'd become a target for malware, & that we are not now.

Except since our community actually knows stuff & we have users interests at hearts & it's open source, places like Debian would be largely immune to most of the horseshit.

> There are bad actors abound but many users were navigating the environment semi-ok, checking for information on how bad their apps were acting.

I truly hope Pine phone picks up share (and performance/ functionality) so people who want this level of control over what their phone runs have a platform.

A lot of people don't know how to manage their phones. I know how to manage performance on my computer but would prefer to not have to do the same on my phone. I suspect I'm not the only computer professional who wants to leave that sort of administrative detail to their work life and not have to deal with a phone that crashes due to a poorly written app.

I suspect this is why the iPad is so popular. It has much of the power people expect from a PC, but removes much of the headaches associated with them.

My feeling here is there is space for managed platforms such as the phone and the iPad; less managed platforms like the Windows/ MacOS; and truly open platforms like Linux. I'm not sure open platforms are very well suited to phones myself, but I'm not against them either.

This reads like a comment written by someone not aware of the depth of the problem.

The post is Android-centric because in typical Android fashion, a passable concept is implemented is the most disjointed way varying scross devices.

Limiting excessive background communication? Thats a good thing.

Killing useful apps like media players in the background repeatedly until you end up with 1 star reviews because people don't realize their own phone is killing apps?

Intentionally breaking well defined OS scheduling guarantees?

Silently breaking functionality that users rely on?

Making alarms fail to ring?

Not as useful.

It's to the point there's literally a website dedicated to worksrounds: https://dontkillmyapp.com/

Look at at this entry for OnePlus

> Not only did users need to enable extra settings to make their apps work properly, but those settings even got reset with firmware updates. So apps break again and users are required to re-enable those settings on a regular basis.

What's funny/sad is their edit only applies to vanilla Android. Other manufacturers have manufacturer-specific settings needed to whitelist apps, because they're not respecting the contract Android provides on background processing

And maybe the most insulting part is the fact that the apps that consistently show up as higher energy users on people's devices... like Facebook...

Are normally exempt! These "optimizers" usually exclude any app deemed "too big to make fail".

So it actually undoes an enormous amount of good that would otherwise be done, and shows it's hardly being done with actual results in mind

These optimizers have existed since the early days of Android, but advanced users understood that intentionally breaking apps wasn't the right way to go about saving battery.

Manufacturers picked them up, in large part because clueless users who like the sound of the idea (right up until it starts killing their music or making their alarms fail to ring) were installing them

Some of them even feel like anti-competitive implementations.

Huawei has an implementation that can't be controlled by the user on some devices! So only apps on the pre-installed Huawei whitelist can run in the background period, and that list includes their homegrown apps and a few major ones like Facebook. Good luck if you have a small app with useful functionality.

I don't think you quite grasp what I meant by balancing act. This is an issue which the 2 biggest companies in tech have been fighting for 15 years (and Microsoft fought and failed to solve prior to that).

This is arguably one of the biggest problems in tech and as devices get smaller and more personal, it's only going to get trickier. Your watch battery isn't going to last all day when you are running a crypto currency miner which is disguised as a media player.

Oh please.

A non-user modifiable app killer isn't the fine line separating us from media app currency miners.

How are Google's devices keeping OS guarantees while delivering some of the best in class battery life figured on Android

Also, imagine seriously implying it's ok they blanket-kill user installed media players because there's a chance they might be currency mining?

https://www.cnet.com/news/vlc-for-android-blacklists-huawei-...

> The decision came in response to the Chinese phone maker's decision to cut off all background apps except its own, which stops VLC's audio playback, VideoLAN said in a tweet.

Here's a real, not made up, not founded in a slippery slope from allowing music to allowing crypto mining, example of what these manufacturers are doing to users and devs alike.

It's not about battery life, it's about flexing their power to seem like they're doing something, while ensuring their bundled apps are the best option for a wide range of tasks

In fact, you can look at the manufacturer list and come to that conclusion yourself.

The manufacturers at the top of the list of breaking optimizers are mostly selling devices heavily subsidized by bundled services. Even Samsung is more aggressive on cheaper devices that target BRIC markets because they need revenue from bundled services.

Google is the only exception to the rule... until you realize their devices are just following the guarantees Android makes.

And they still manage to have some of the best battery life on the market.

That's because it's not even as simple as just blindly killing background apps.

When you kill these background apps, users get in the habit of opening the apps back up manually to not miss updates.

Repeatedly waking the radio is more battery consuming than if the OS just keeps it's promises and smartly wakes these apps.

It's not like they get infinite processing time anyways, having this stuff be managed intelligently instead of just taking a sledgehammer to the concept of background processing is better for everyone involved but a manufacturer that wants their music app to be the only functional one...

I have absolutely no idea what any of this has to do with my original point or my reply.

Android OEMs have bad battery life because they install their own services and layers of nonsense over the top of Android. That doesn't change the fundamental issue here.

You understand your comment is talking about the balancing act OEMs are supposedly putting on to save battery life?

You understand me replying to you and talking about how they're not balancing anything but personal gain and optics is relevant to that?

Or you don't understand that?

> This reads like a comment written by someone not aware of the depth of the problem.

> Oh please.

> Or you don't understand that?

What I understand is that your posts have wandered between being dismissive, condescending, and argumentative. I've ignored that to this point, but since you've been insisted on being consistently so in 3 messages straight, I'm calling you on it.

If you have a point other than being argumentative, it's not well made.

You're complaining that my replies have nothing to do with the original point... then typing up a screed about my tone?

Especially after starting your initial reply to me with

>I have absolutely no idea what any of this has to do with my original point or my reply.

Do you know what dismissive means?

If I come across as dismissive it's because you really don't seem to know what you're talking about, and if anything this attempt to deflect from the fact just cements that.

Me telling you that your comment comes across as being written by someone not aware of the depth of the problem is exactly what it sounds like, you said things that strongly implied you were not aware of the deeper background to this post.

If you choose to take it as a personal slight, be my guest.

Likewise if you're going to play the "music players can be crypto miners" card I'm going to be dismissive of that too, it's a lazy attempt to distract from the problem.

Of course apps can be bad actors. Jumping to the most fear-mongery example possible is just that... fear mongering.

For every app mining cryptocurrency, there's 10 more that are just poorly behaved in respect to battery life.

Trying to act like OEM's attempts to lock down background apps should be dictated by the former rather than the latter is something I'll gladly dismiss. It's nonsense.

So you’re saying OEMs take no efforts to optimize for battery life. That’s kind of an extreme position to take. We know they are working on battery life because updates have extended battery life in deployed assets.

What? No? Where did I say "OEMs take no efforts to optimize for battery life"? Usually you try and be subtle about a strawman, no?

I said overbearing app killers aren't optimizing for battery life.

Do you think that's the only knob for battery life? I'm currently working on an unreleased Android device at our company, the number of knobs we have to turn for battery life is insane. Throttling behavior, optimizing existing services, screen off behavior, etc.

App killers don't work, again, that's why vanilla Android devices consistently top battery life charts. Forcing apps to start up more often, breaking user functionality, it's not a real solution.

Android already has built-in management of background services and has had it for half a decade: (https://developer.android.com/training/monitoring-device-sta...)

The defaults scope of background processing is already very tight on Android, breaking that already limited scope for little to negative gain isn't helping anyone but themselves.

It's easy to implement a software solution that punishes poorly behaving apps and allowing the rest.

No matter how good the push implementation is, it is still best to only have one connection that the phone has maintain. 5 great push services still takes 5 times the battery that 1 great push service would take.

> 5 great push services still takes 5 times the battery that 1 great push service would take.

This is true with current implementations, but it doesn't have to be true.

Coordinated CPU wakeups and radio packet timings would mean the power consumption from waking the radio would be not much larger with 5 apps than 1.

It needs coordination, but the coordination doesn't have to be done inside a service daemon as it is now, and it doesn't have to go through one shared cloud service provider as it is now.

> It needs coordination, but the coordination doesn't have to be done inside a service daemon as it is now, and

It more-or-less does need to go through a single daemon, or it would be nearly impossible to coordinate the requests.

> it doesn't have to go through one shared cloud service provider as it is now.

This is more true, for example you could have an open protocol and an app could register with the push daemon. It would be impossible to consolidate push notifications or throttle them for bad actors though.

> It more-or-less does need to go through a single daemon, or it would be nearly impossible to coordinate the requests.

A single daemon, or a single kernel, it doesn't really matter which.

I'm thinking a few socket() options. The kernel already coordinates coarse-grained timer wakeups between processes; it's not that outrageous to think it could nudge multiple pinging sockets towards each other then coalesce timings.

The underlying mobile network registration for notifications is already quite low level.

> It would be impossible to consolidate push notifications or throttle them for bad actors though

At least at the moment, I don't think there's a need to consolidate push notifications into the same packet for different apps. The rate of notifications isn't high enough to matter.

For keepalive pings (if the underlying radio network can't provide events to piggyback on), and consolidating pushes (if that is needed), voluntary cooperation on timings among good actors would allow incoming packets to arrive around the same time, and the mobile base station could, if a protocol was agreed, queue and coordinate the transmission time of those packets as a group, or coalesce them into a specially-addressed packet representing the group.

For throttling bad actor pushers, the device itself (kernel or daemon) could block sockets and source IPs that are sending too fast.

Presumably there's already some mechanism in place for things like SYN attacks. If there isn't, bad actors already have a way to drain your battery.

It's not that linear.

The savings are from letting radio go to idle. If you have more than one (ideally non-cooperating) services that are keeping the radio permamently on, you won't ever get to idling and say good bye to battery.

I'm skeptical that Microsoft, Apple, and Google have all failed at this, but some dude on HN has a simple solution. I think you need to expand on your concept a bit before I take it seriously.

What does the software solution look like that distinguishes between a crypto miner and a media player?

How can you tell when an app legitimately needs access to files from another app versus being malware of some sort?

Not sure if you're a programmer, but you can have a centralised local service that listens multiple channels over a standard API and wakes up the respective app. Some quota management on top can ensure fair share. And of course, allow the user to prioritise any app they want.

Could you implement something like this in pine phone? I’m not a programmer but if it’s easy as you say, I’m excited!

It's not even that, simply having open sockets with heartbeats (and then re-opening them once the connection breaks or you switch networks) isnt efficient with 5+ different sockets always open listening for notifications, and that's if every app is coded the same way to operate extremely efficiently.

It would not be technically impossible to have all 5+ wake up at the same time and activate the radio at the same time, even with different packets to different destinations.

And it would not be impossible to coordinate the return timings to match either.

Or even better, to have just one low-level packet shared among them all, with a mobile operator or backbone protocol that fans them out and in, analogous to multicast and IGMP but designed for push/keepalive systems.

There are no insurmountable technical obstacles. Just challenges.

There is negligible consequence for power consumption too, with a suitable API.

But rather than design for everyone, as we would have seen in the utopian days of the internet, it's much easier to run a single walled-garden service, and it fits with the "you must go through us for everything" model used by many of the device's other services.

Utopian days of the internet? Where a bug in a prank can spread a worm that takes down most of the known internet? The same security mindset that allowed for the utopian days is not only long gone, it could survive in an age where my banking and medical info is online.

The attitude that different vendors can create independently run services is still alive, now with better security.

But not on major mobile devices, at the moment.

In the banking world, it appears to be getting slightly more open. There are more independent feeds and open standards than there used to be. This is a mixed benefit as there are also more "middleman" sites that want to read your banking data to help you visualise it better, and some of them might not be doing it just for the benefit of the account holder.

I’m looking forward to your white paper and demo of this increasing either usability or battery life without sacrificing the other.

Reply on news.ycombinator.com