Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android vendors, don’t kill my app

dontkillmyapp.com

Post reply on HN
Print view View original

351–360 of 414 posts

Re: Android vendors, don’t kill my app

#351

Post by avree »

fixermark wrote: post #324

Counterpoint: Battery life consumption rarely comes up as a feature bullet-point for an app writer, because visibility on whether a given app is a battery hog is low (both for developers and users). There are a couple of reasons iOS was so draconian about background processes for most of its history, and this was one of them. This ecosystem shift puts pressure back on developers to get creative and ask hard questions…

>Battery life consumption rarely comes up as a feature bullet-point for an app writer, because visibility on whether a given app is a battery hog is low (both for developers and users).

Both platforms offer extremely easy to access, at-a-glance views of which apps are using the most battery for any given period.

Re: Android vendors, don’t kill my app

#352

Post by AnthonyMouse »

ajross wrote: post #343
sudhirj wrote: post #200

Earlier quoted context omitted.

Example 1 has been solved with Background App Refresh a long time ago [1] Example 2 should work fine with the background mode declared [2] Both these APIs are pretty old... is there something I'm missing? [1] https://developer.apple.com/documentation/uikit/core_app/man... [2] https://developer.apple.com/documentation/foundation/url_loa...

Isn't that the same kind of excuse-making you're dinging the Android world for? "OK, fine, the experience sucks by default but it works fine if you just do this and this and this". Android has all those sorts of features too. It's just a hard problem. App developers are bad, and do bad things. OSes can't protect against all bad behavior. Phone manufacturers do have a vested interest in protecting their users from bad…

> Users do actually benefit from this on balance.

Users don't benefit from lazy ham-fisted hacks. There is no benefit to killing an app without notifying it in any way, or killing a background app that is using 0.2% of available memory and 0.0% of CPU just because it has been open for a long time.

Re: Android vendors, don’t kill my app

#353

Post by untog »

vxNsr wrote: post #344
untog wrote: post #341

Earlier quoted context omitted.

Background refresh doesn't work if the user "force closes" the app, i.e. they go to the task manager and swipe it away. Anecdotally, it's super common for people to do this as they have read somewhere that it helps battery life (not untrue, but also not really effective). So if you were writing an e-mail app you wouldn't be able to guarantee that you'll actually deliver e-mail to users, which feels kind of important.

Sounds like user error at that point, I would popup a message after the next force quit saying that doing so will pause email notification until the app is reopened. There you go: bug turned into a feature.

How on earth would that be a feature? If you have to show a popup on launch for something like that then it's a user experience failure, no matter if it's your fault or Apple's. Either way, it means the user has to treat your app differently to every other app on their phone. That is bad.

"It's user error" is a weak excuse if any kind of significant number of users are doing it.

Re: Android vendors, don’t kill my app

#354

Post by ajross »

AnthonyMouse wrote: post #352
ajross wrote: post #343

Earlier quoted context omitted.

Isn't that the same kind of excuse-making you're dinging the Android world for? "OK, fine, the experience sucks by default but it works fine if you just do this and this and this". Android has all those sorts of features too. It's just a hard problem. App developers are bad, and do bad things. OSes can't protect against all bad behavior. Phone manufacturers do have a vested interest in protecting their users from bad…

> Users do actually benefit from this on balance. Users don't benefit from lazy ham-fisted hacks. There is no benefit to killing an app without notifying it in any way, or killing a background app that is using 0.2% of available memory and 0.0% of CPU just because it has been open for a long time.

> There is no benefit to killing an app without notifying it in any way

Sigh. There can be on balance. Bad apps get killed, users don't see as many dead phones. A few false positives get killed too, to great annoyance of their authors (and potentially users, but it's mostly the app authors upset here, be honest).

Whether that's worth it or not depends on the numbers involved, not your personal definition for "ham-fisted" or the existence of a better solution.

All I'm saying is that app vendors aren't the only parties involved here, and that the problem being addressed is real, and quite important.

Re: Android vendors, don’t kill my app

#355

Post by AnthonyMouse »

fixermark wrote: post #330
zeveb wrote: post #268

Earlier quoted context omitted.

> And apps that don’t fit those use cases - what are they doing with your device? What I, the owner of my device, have directed them to do. Apple's approach makes easy things difficult (because one must use their APIs) and difficult things impossible (because Apple have decided that purchasers of their devices shouldn't be permitted to do things Apple wishes them not to do). I want a general-purpose computer that I o…

You've definitely made the case that you don't want an iOS device. ... the market appears to be making the case that you are not the average consumer, but that's an independent variable.

The market has consistently been choosing Android phones in higher volumes than iPhones for years.

Re: Android vendors, don’t kill my app

#356

Post by AnthonyMouse »

simonh wrote: post #72
squarefoot wrote: post #70

Earlier quoted context omitted.

The locked environment may prevent users from removing branded crapware installed by vendors, but it's not its cause. Popularity is. If Gentoo Linux (just to name one we wouldn't expect Joe User to know) became popular as Android on cellphones, we would see in no time vendors trying to cram their crapware into every platform running Gentoo as well, but its open nature would allow users to remove unwanted stuff, so ve…

Right, so 'open' Gentoo would get forked into a hundred locked down, obfuscated, proprietary flavours with all the same problems. In fact it's only a closed system with a single gatekeeper that can avoid this problem at scale, because it's the only way to maintain clear lines of responsibility.

> In fact it's only a closed system with a single gatekeeper that can avoid this problem at scale, because it's the only way to maintain clear lines of responsibility.

PC hardware is available from arbitrarily many vendors and you can install stock Windows or Linux on pretty much all of it. Many of the OEMs preinstall their various spyware, but you don't have to buy from them to begin with, and even then they can't stop you from removing it.

The primary difference in the phone market is the lack of open source drivers, so you can't install stock Android on your arbitrary phone because it needs the specific weird kernel it came with. But basically everybody hates that -- even the OEMs, because they neither want to be blamed for not providing updates nor want to have to actually provide them themselves. So it's slowly changing.

And even now, as a customer, there are unlocked devices available that will run stock Android, all you have to do is buy one of them.

Re: Android vendors, don’t kill my app

#357

Post by AnthonyMouse »

ajross wrote: post #354
AnthonyMouse wrote: post #352

Earlier quoted context omitted.

> Users do actually benefit from this on balance. Users don't benefit from lazy ham-fisted hacks. There is no benefit to killing an app without notifying it in any way, or killing a background app that is using 0.2% of available memory and 0.0% of CPU just because it has been open for a long time.

> There is no benefit to killing an app without notifying it in any way Sigh. There can be on balance . Bad apps get killed, users don't see as many dead phones. A few false positives get killed too, to great annoyance of their authors (and potentially users, but it's mostly the app authors upset here, be honest). Whether that's worth it or not depends on the numbers involved, not your personal definition for "ham-fi…

Can you explain the advantage in killing the app without notifying it? You're going to kill the app because it's consuming 500MB of memory, fine, send it SIGTERM or equivalent and then give it two minutes to orderly shut down before you send SIGKILL. Not doing it that way has a cost and no apparent benefit to "balance" it with.

Re: Android vendors, don’t kill my app

#358

Post by fixermark »

int_19h wrote: post #342
fixermark wrote: post #327

Earlier quoted context omitted.

And also, it's the 21st century and we don't need chat protocols to be client-side-liveness chatty to "stay on" when the entire cellular network is architected to find devices and route messages to them. IRC isn't a well-designed protocol for this use case, and a "land-side" bouncer that bridges the chatty protocol to a lazier protocol ought to be more energy-efficient overall.

Well-designed or not, it exists, and sometimes you just want to use it, without a lecture on how it's suboptimal.

That's fine. you are "free" to hack your own version of Android that modifies the APIs to disregard power-management best practices.

... and maybe your own hardware to run them on. But I wouldn't expect any major player competing against other companies to do the work for you when the outcome is supporting some chat protocols that most people don't use.

(Otherwise, if you're expecting vendors to do it for you, you get to expect the lecture that comes with that expectation, in the form of APIs designed to minimize the ease of doing the wrong-for-the-average-utility-of-the-platform thing. Your cell radio could probably be adjusted to operate as a spark-gap transmitter also, but I don't expect them to provide an easy API for that either ;) ).

Re: Android vendors, don’t kill my app

#359

Post by izacus »

mcny wrote: post #168
izacus wrote: post #40

Earlier quoted context omitted.

I think you misunderstood the core issue here - it's not that the USER can decide what runs. It's that the USER cannot override those settings and decide that something can run and function if required. There are special whitelists for apps that are allowed exceptions (e.g. Facebook and other common apps are usually allowed to work) and others are killed against the Android API guarantees (e.g. you install Signal mes…

> I think you misunderstood the core issue here - it's not that the USER can decide what runs. It's that the USER cannot override those settings and decide that something can run and function if required. There are special whitelists for apps that are allowed exceptions (e.g. Facebook and other common apps are usually allowed to work) and others are killed against the Android API guarantees (e.g. you install Signal m…

Android has done the right thing at least since 6.0 and that has resulted in massive battery life improvements.

Re: Android vendors, don’t kill my app

#360

Post by stickfigure »

vxNsr wrote: post #346
admax88q wrote: post #284

Earlier quoted context omitted.

My XMPP client works perfectly on my Android phone. Prompt and reliable notifications of new messages. Better than most "Push Message" based clients I've used for other chat services. It's consistently the last in battery usage as well. Honestly I don't need the OS to protect me from poorly engineered apps, I just need it to correctly blame the apps so I know which ones to stop using.

Classic HN response. I'd guess a FTP and a linux file-server would solve all your filesharing woes as well. No dev making a mass market device or software should build as if the 1% graybeard engineer is gonna be the only user, that's a lot more user hostile.

Android's "these are the apps killing your battery life" interface is perfectly usable by Joe Everyuser. This is a specious argument.
Post reply on HN