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

361–370 of 414 posts

Re: Android vendors, don’t kill my app

#361

Post by fixermark »

xyzal wrote: post #90

To be honest, as a user I really like the implementation of battery saving features of my Sony phone: 1. They are not enabled by default 2. Their settings screen explicitly states what the modes do 3. They can extend battery life significantly The most aggressive mode is called Ultra Stamina, and it works by basically turning the phone into dumbphone mode -- complete without any internet connectivity, calls, SMS and…

In my experience, Sony Android devices are pretty well architected. I had a tablet for a long time with a built-in IR transceiver for acting as a TV remote. Seems like a silly add-on, but I used that thing until it broke.

Re: Android vendors, don’t kill my app

#362

Post by zmmmmm »

sudhirj wrote: post #58

This is the Android multitasking lead finally coming fully circle. Android had multi tasking much earlier and in a more powerful way by allowing apps to start their own serivices and do pretty much whatever they wanted, but this is the unfortunate logical result - apps that agressively kill other apps, installed by the handset manufacturers, to protect users from badly written apps that drain the battery in the servi…

I think that's an over fatalistic interpretation. You're implying that giving more power to users inevitably results in them harming themselves and therefore should not be done, instead the OS vendor should make explicit APIs for everything and only whitelist "allowable" things.

My problem with that is that it kills all innovation and creativity - only the OS vendor can come up with a "new" whitelisted activity. Anybody else is out of luck. Inevitably that means you simply can't get niche applications because what Google or Apple sized company is going to invest in something only 10,000 people might use? I might be idealistic, but I firmly believe that it's possible to both grant power to end users (as in, enable app developers to have a very large amount of control) AND deliver a good end user experience. It requires a lot of good design and discipline and it's definitely hard, but that's not an excuse to give up and hand over all control to the OS vendor.

Re: Android vendors, don’t kill my app

#363

Post by zmmmmm »

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…

I agree. What's really broken is lack of a good feedback loop both to app developers and the OS vendors. It would be good if this translated to two things:

- google mandates that killing background apps must be based on actual battery consumption

- when an app that requested background permissions is background-killed, this is reported to the app developer and OS vendor in some sort of aggregate metrics they can see

- users should get some kind of report or notification as well about it

You would instantly see both OS vendors and app developers trying to optimise the battery life of their apps so that they can stay alive.

Ideally, users who want to should be able to actually set thresholds on how much battery any app can consume. Eg: if I am OK that my phone only lasts an hour I should be allowed to tell it to keep my minecraft server on on the background so everyone can keep playing.

Re: Android vendors, don’t kill my app

#364

Post by lstamour »

scarface74 wrote: post #174
lstamour wrote: post #17

Earlier quoted context omitted.

You can, for certain classes of application, and for certain types of tasks (like background downloads). It’s entirely managed by the OS, and is often reduced or suspended entirely under Low Power mode. But Apple allows for other kinds of wake notifications and is usually pretty good with Push Notifications due to carrier partnerships. That said, Apple does intentionally make certain apps a lot harder: https://stacko…

And... well, it rarely allows apps that duplicate built-in functionality on the App Store. This is such an old meme and there are plenty of existence proofs that it isn’t true. There are third party apps for every single app on iOS including navigation, podcasts, mail, music players, calendars, password managers (with integration APIs specifically for them as of iOS 12), weather, notes, etc.

There are rules:

Unacceptable: https://developer.apple.com/app-store/review/guidelines/#una... Spam: https://developer.apple.com/app-store/review/guidelines/#spa... Copycats: https://developer.apple.com/app-store/review/guidelines/#cop...

You can't make your own App Store, you can't ship your own browser -- https://developer.apple.com/app-store/review/guidelines/#sof... -- you have to use HLS, you can't use background features except for approved categories: "VoIP, audio playback, location, task completion, local notifications". "Apps that create alternate desktop/home screen environments or simulate multi-app widget experiences will be rejected."

I'm not saying the rules aren't much improved from what they used to be -- it's been years since the simple advice was "don't ship something we ship," but ... at its core, it's still somewhat true. You have to ship an original app -- and all of the app categories you mentioned have truly original apps on the App Store already.

Re: Android vendors, don’t kill my app

#365

Post by UnFleshedOne »

gambiting wrote: post #130
yason wrote: post #129

Killing apps is a good thing . There have been battery saver programs since the very beginning of early Android versions to kill of connectivity and clean up running apps. When Android now supports some of that natively and vendors too, even more aggressively, this is just responding to users' needs. There is a quite clear usage pattern to support this behaviour: unless I explicitly say so, I don't want apps on their…

I mean sure, but at least give me a way to override it. On my OnePlus 5T running Android Pie, the system will keep killing my VPN client when in sleep mode, even though I have selected that I don't want to optimize it under battery usage. With the VPN client restricting all unprotected access, it means that once the phone goes into sleep, I stop getting all notifications for anything because there is no internet conn…

I use NetGuard on 5T, which is using VPN API, and that seems to stay alive. That with battery optimization off for it and with its own watchdog option enabled. I think I had it dying without watchdog though.

Re: Android vendors, don’t kill my app

#366

Post by scarface74 »

lstamour wrote: post #364
scarface74 wrote: post #174

Earlier quoted context omitted.

And... well, it rarely allows apps that duplicate built-in functionality on the App Store. This is such an old meme and there are plenty of existence proofs that it isn’t true. There are third party apps for every single app on iOS including navigation, podcasts, mail, music players, calendars, password managers (with integration APIs specifically for them as of iOS 12), weather, notes, etc.

There are rules: Unacceptable: https://developer.apple.com/app-store/review/guidelines/#una... Spam: https://developer.apple.com/app-store/review/guidelines/#spa... Copycats: https://developer.apple.com/app-store/review/guidelines/#cop... You can't make your own App Store, you can't ship your own browser -- https://developer.apple.com/app-store/review/guidelines/#sof... -- you have to use HLS, you can't use backgroun…

I'm not saying the rules aren't much improved from what they used to be -- it's been years since the simple advice was "don't ship something we ship," but ... at its core, it's still somewhat true. You have to ship an original app -- and all of the app categories you mentioned have truly original apps on the App Store already.

There is a difference between "I want to write a podcast app" and "I want to duplicate Overcast and just change a few icons"

And your first quote was "don't ship something we ship", which is quite different from "don't just reskin an existing app".

https://developer.apple.com/app-store/review/guidelines/#cop...

Don’t simply copy the latest popular app on the App Store, or make some minor changes to another app’s name or UI and pass it off as your own. In addition to risking an intellectual property infringement claim, it makes the App Store harder to navigate and just isn’t fair to your fellow developers.

You can't use background features except for approved categories: "VoIP, audio playback, location, task completion, local notifications".

https://developer.apple.com/library/archive/documentation/iP...

Re: Android vendors, don’t kill my app

#368

Post by madeofpalk »

untog wrote: post #353
vxNsr wrote: post #344

Earlier quoted context omitted.

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.

If a user 'force quits' an app, don't they expect that it won't be running in the background receiving app content updates?

If I force quit an app on my computer, it no longer runs and does things.

Re: Android vendors, don’t kill my app

#369

Post by mfoy_ »

apexalpha wrote: post #310
mfoy_ wrote: post #303

Earlier quoted context omitted.

Sorry, how does rounding to the nearest minute or nearest TEN minutes solve any problems? Like are apps setting alarms for every 3 seconds or something for no reason??

Yes. Rounding to 10 min means you fire up the cpu and do all apps at once then go idle.

Oh, so when we say "alarms" we mean "background processes that occur at set intervals"?

Not literally "alarms", like the ones that ring?

Re: Android vendors, don’t kill my app

#370

Post by jmull »

untog wrote: post #341
jmull wrote: post #304

Earlier quoted context omitted.

I’m curious: why doesn’t background refresh solve the problem?

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.

I see. I can see the issue.

But it comes down to this: if a user explicitly kills an app, should it keep running in the background?

If the answer is "yes", then what you're really saying is users shouldn't be able to kill apps if the app doesn't want to be killed.

I get that some users don't know what killing an app means but do it anyway for some reason.

But that's not a problem with background refresh. E.g., maybe iOS could warn/explain about the implications of killing an app (with a checkbox so you can opt-out of further warnings).

Edit: just realized I left the word “not” out just above, which reverses it’s meaning

Post reply on HN