Hacker News Reader

Comment by gruez | Hacker News Reader

>Unfortunately, many vendors remove half the settings from their interfaces and make their app killers extra aggressive (just to spite people, it seems, because battery life doesn't seem affected in my experience).

To be fair, for every well behaved background app (ie. a ssh server that's listening on a socket, which should consume basically zero power), there's probably 10 other misbehaving app that's phoning home every 30 seconds for ad/tracking/analytics purposes. Moreover, "battery life" is a metric that often shows up on reviews, so it makes sense to game this metric as hard as possible, especially since most people probably aren't running servers 24/7 on their phones.

View on HN

I'm not opposed to power saving measures being enabled by default, but "let this app run in the background at all times" should still be a setting. Require a PIN or biometrics to toggle the setting for all I care, but not being able to turn off app killers is what turned me off several brands of phones. The defaults are good for the general population but I'm not the general population so let me turn that damn thing off. Show me a daily notification about how an app drained 40% of my battery life if you have to but don't make me root my phone again just to turn off the stupid app killer.

I run into issues with the smart watch integration app getting killed before Google Maps, even when I'm not navigating on one of my devices. No way to whitelist the integration app or set some kind of preference, it's just a lottery, probably based on guesstimated power consumption (which, for an app with a Bluetooth lock, will probably be above average) that I want to tweak.

Some sales/ad Manager will force app dev for money (that will happily take money - and write in hn after 5 years that he/she is so overwhelmed with guilt that they have to live with 6digit money on a beach now) and build UI that will trick user into enabling that for that crap app.

Some of those apps are things I want to phone home, like the system I have that is supposed to dial my thermostat back automatically (as well as back up again).

When these are the tasks that are killed, it costs me more than whatever precious bodily fluids that some ad/tracking/analytics stuff may sap: It costs me real money.

The problem is less with phoning home per se, and more about doing it in a way that's against user expectations. I already acknowledged that there are legitimate use cases out there, but for the overwhelming majority of users, their phone is primarily a communication and media consumption device, which doesn't need 24/7 background access. Yes, it's tragic that the handful of people are being harmed by this, but it's hardly because of "spite" as OP suggested.

The problem is that I'm only theoretically harmed by things that unexpectedly succeed in phoning home, while I'm absolutely harmed by things failing to phone home when I need them to do so.

Dollars I have lost due to things phoning home against my expectations: Close to zero -- if not literally zero. (And close to zero time spent managing that.)

Dollars I have lost due to things failing to phone home when I want them to do so: More than zero. (And hours and hours of time spent trying to make them work more reliably.)

If you really want to get into a game of theoretically vs practically, for most users: they're only theoretically harmed by not being able to disable background activity, because all they're doing is texting (worst case, there's GCM which is whitelisted) and watching tiktok. Meanwhile they're practically harmed because the one-of-a-dozen e-commerce app has some misbehaving background service that's trying to send telemetry 24/7. People also have terrible battery discipline, and if you're out and about a dead phone has actual costs (eg. having to rent a power bank, or having to take a cab rather than uber).

None of this invalidates your use case, but given the rarity of your use case compared to the more common use case, I hope you understand why companies are implementing it not purely out of "spite".

Spite?

A thing can be abhorrent and disdainful and motivated by the best and most pure of intentions, all at the same time. These are not in any way mutually-exclusive constructs.

Rarity?

Perhaps the best way to make sure a thing remains rare or unusual is to neuter it straight out of the gate. In the past few days here we've seen SSH servers and Docker containers on Android, with the repeated caveat of "Yeah, but the task killer won't let that really work." And that's absolutely true: It won't.

Reply on news.ycombinator.com