Android vendors, don’t kill my app | Hacker News Reader

Android vendors, don’t kill my app

dontkillmyapp.com

515 pointskumaranvpl402 comments

For our Zombies, Run! run tracking/audio adventure app, "battery management" is turning into our most consistent customer complaint, to the point where it's impacting review scores, active users, and probably subscriptions. The result of the changes made by Huawei, OnePlus, Xiaomi, and Samsung mean that our app is killed during runs, and people interpret that as the app crashing.

We're trying to figure out the best way of telling users how to change their battery settings (which, for the avoidance of doubt, are usually on by default; and sometimes revert back to default on OS updates); some kind of annoying modal popup in the app before they begin a run, perhaps.

What can I say? These Android manufacturers are prioritising numbers they can put on a spec sheet over the end-user experience on entire categories of legitimate fitness and audio apps. We have no recourse and no way to get on their whitelist. Maybe Google could threaten the manufacturers, but that would be a nuclear-level response.

Yet another thing third-party app developers have to deal with.

>We're trying to figure out the best way of telling users how to change their battery settings

The best way to do that is to remotely figure out on which devices the app is getting killed by sending data push notification messages and an in-app ack mechanism. And then show users an annoying popup message the next time they launch to make sure that they whitelist the app. We faced the same problem while building Flock, a team messenger and the details are outlined here.

https://hackernoon.com/notifications-in-android-are-horribly...

Samsung is part of OHA (Open Handset Alliance) & Others have access to Google Play Services; so Google can in-fact ask them to stick to the android specs.

Background services management was let loose in Android till 6.0; with doze mode & Job scheduler it has vastly improved. I think manufacturers shouldn't start killing apps themselves, as shaming apps which abuse background services, eat power inconsistently by displaying notification & allowing user to 'force stop' the app themselves does the job as in OxygenOS.

For all the flak iOS gets regarding multitasking, I was impressed by their uncompromising attitude towards background services from the start, even when I was bashing my head during iOS development to implement features on par with android version. The background operations should be completed within 3 minutes, but there's no guarantee that it will not be killed before that!

> We're trying to figure out the best way of telling users how to change their battery settings (which, for the avoidance of doubt, are usually on by default; and sometimes revert back to default on OS updates); some kind of annoying modal popup in the app before they begin a run, perhaps.

That seems to be exactly what TFA notes in various per-manufacturer segments (the color blocks with poop emoji are clickable and provide manufacturer-specific information and complaints) e.g. for Nokia:

> every [background] process gets killed after 20 minutes regardless it is actually supposed to be running and doing a useful job for the user.

or for OnePlus:

> Not only did users need to enable extra settings to make their apps work properly, but those settings even get reset with firmware update so that apps break again and users are required to re-enable those settings on a regular basis. […] On some OnePlus phones there is also a thing called App Auto-Launch which essentially prevents apps from working in the background.

Would it be possible to detect that the app was killed while engaged in such a situration as yours, i.e. similar how to systemd detects killed apps with a keepalive ping written to the fs while engaged.

Then on the next boot explain that you detected this, and guide the user to OP's page? Or is it way more complicated than so?

As TFA notes (in the Nokia section, possibly others):

> This app kills apps in the most brutal way we have seen so far among Android vendors.

You can't detect that your application was kill -9'd. I don't think you can detect that "PowerSavingAppG3" is running either (I'd guess it's running as root and you're not), so you can't even infer from its existence that your application will be traumatically killed in short order.

I think you are reversing what the parent comment meant. You can continually write to the sandboxed filesystem of your app, say write the current timestamp every 10 seconds, and a status of if the app exited gracefully (which you can control). Then when restarting the app you check if there was a timestamp written in the last say 2 hours and no graceful exit then you know the app was terminated and can explain that the app didn't crash but that the OS vendor force quit it.

Please don't! This will wear out both the battery and the flash memory for no reason. It's exactly this kind of sloppy coding that made these manufacturers decide app killers were necessary.

How do you differentiate an apps crash from an OS forceful kill?

Both would show a last good status and no good exit.

Sure you can:

1. Create an empty file when the application launches

2. When the application terminates, write the reason for termination into the file.

3. When the app launches again, read the file. If it was empty, then you were SIGKILL'd, or you crashed.

> you were SIGKILL'd, or you crashed.

"Might have been killed, might have crashed" is not helpful, and the inability to know is the very issue at hand here. You can't know whether your application crashed, the user forcefully killed it or you fell afoul a background killer. What now, do you start spamming the user anyway?

Android doesn't offer any signal of normal termination. Your process gets killed when the OS needs memory for some other app.

A kill -9 wouldn't give you a chance to write the reason for termination to a file. It's the equivalent of the OS saying "you have already run your last CPU cycle, you will receive zero more CPU cycles, good bye".

You might be able to write the word "bad" in a file, and then clear the file if your app closes nicely. If you start and find the word "bad" in the file, then you know you were killed. A slight variation of what you suggested.

There is a way to detect it but it's hacky. You need to use fcm xmpp to send data push notifications with delivery receipts and also send an acknowledgement from the apps background service. Devices where you don't get the app ack have an app which is force killed

Details outlined here : hackernoon.com/notifications-in-android-are-horribly-broken-b8dbec63f48a

That sounds way over-complicated. Why not just keep a flag in the database that's updated during the Activity lifecycle?

Sorry, I didn't understand. We need a service side service to keep track of ack's that we received from the device. I am not able to understand how a db flag would help.

Have an app priority defined by user

Whether this is possible or not is deeply missing the point as well as showing a vital misunderstanding about UX.

People were correct to downvote my comment. The tone was all wrong. For some reason, I take Android's many shortcomings as a personal affront. I guess that's what years of being a dev where all the piracy and user support are with Android issues while only returning a fraction of the profit compared to iOS will do to you.

The point is that this is entirely Google's fault and yet it's the devs who have to clear up the mess and take the blame, or alternatively we bombard the users with technical fixes and explanations. Quite clearly neither of these options is where we should be with a mature OS on a mass consumer device.

Now I'm getting all angry again just thinking about it. Time to up my meds.

> as well as showing a vital misunderstanding about UX

The third party controlling your user's experience is forcibly killing your application while it's in use as intended. This somehow means you are misunderstanding UX?

People are suggesting ways to detect it and teach the user how to stop it, because they have no automated solution to this problem.

>a vital misunderstanding about UX.

What misunderstanding would that be exactly? App developer has to find a way to help customers work around an issue they cannot resolve themselves. Seems reasonable to me.

If Play Store allows to mark the app as incompatible with specific models, that might be the best recourse―since the app can't function properly on those phones anyway.

Isn't that basically a death knell - especially if you're not a top 10/50/100 app - when trying to reach customers? If you wait until the customer has downloaded your app, you'll probably have better retention. If you mark your app as incompatible, people won't even bother to install even though there could be a work around. You'd basically be trying to send a message to users about device manufacturers and the Android operating system while killing your own numbers.

Not even that: marking it as incompatible will render the app listing invisible for those devices (in both top lists and searches), and if you do reach the listing directly then the install button will be disabled.

Pulling the nuclear option for something with clear workarounds (or which only impacts peripheral features) is unacceptable.

I don't think it's just that. As an app user I can say I'm tired of apps running in the background that don't need to be, and there are tons of them that do it. Maybe Android needs to be more refined in how it handles apps that run in the background but as a user who prizes control of my phone I also think developers need to think twice about what they leave running in the background and why.

Seems like battery management has the traditional firewall problems.

Eg. Blocking legit services and obscure errors popping up.

Ps. Love zombies run

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 services.

Apple took a lot of flak for not having multitasking, but to they credit they took the time to build explicit APIs that allowed apps to handoff certain whitelisted tasks (audio playback, downloads, alarms, notifications) to the OS, and made clear guarantees about the circumstances under which the APIs would work.

>> "Apple took a lot of flak for not having multitasking, but to they credit they took the time to build explicit APIs that allowed apps to handoff certain whitelisted tasks"

iOS's support for background tasks is still shit. This is why some apps have been abusing the location API to ensure that background tasks don't get killed. Apple deserved all the flak it got and it still does.

_Example 1:_ fetch email (without push) for any non-Apple email app will not work reliably, because the app can get killed. You have to rely on Apple's built-in notification support, but this means that a server-side connection needs to be maintained.

As a result, if you want reliable mail delivery without using Apple's Mail, you have no way but to share your username and password with third-party app servers which you don't trust. For example: Airmail or Canary Mail.

Of course, Apple's own Mail has no such restrictions because it is a special part of the OS. This is no surprise however, since Apple has been actively hostile to alternatives for their own apps.

_Example 2:_ backing up photos and videos (with Dropbox, Google Drive, etc).

There's no way to ensure that your photos get backed up without making an effort to keep the app active, in the foreground, with the screen on, or without the app developer abusing the location API, which Dropbox has been doing.

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...

1. no, does not work — email clients warn users that if the app gets killed then notifications will stop and yes, I tested this quite recently

2. no, it does not work for background uploads, here are screenshots of Dropbox's configuration and Dropbox is not alone in doing this ;-)

Step 1: https://www.dropbox.com/s/b7vylhljg2fwtb8/2019-01-14%2015.02...

Step 2: https://www.dropbox.com/s/c9knz2zz6zs28l5/2019-01-14%2015.04...

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 apps. Users do actually benefit from this on balance.

Background App Refresh has been a thing for ages - It took them a while, but Apple solved this problem in a super user-friendly manner.

No, they haven't solved it.

Isn't it also the consequence of taking the control away from the user? Why can't I whitelist which applications I want to allow to run in the background? Why do I still have to grant an application all the permissions it requests when I install it instead of being able to turn them on or off individually?

By dumbing things down that way Google created this situation IMO, it's bad from a quality, usability and privacy perspective. Of course Google considers that you leaking your personal info is a feature so that part probably won't change, but they should at least care about the two other points.

No, it’s the consequence of permitting background tasks at will. Apple took some heat, and there is learning curve associated with doing it their way, but they actually thought it through and created an energy-efficient architecture that addresses common use cases. And apps that don’t fit those use cases - what are they doing with your device?

Can I run XMPP or IRC on an iphone by now or does it still only receive messages when foregrounded?

> 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 own & control in my pocket, not some stripped-down communicator owned & control by someone else.

> Why do I still have to grant an application all the permissions it requests when I install it instead of being able to turn them on or off individually?

I don't think this is true in the later releases is it? I get a lot more ad-hoc permission requests these days, and there's much more control in the application settings (the android app settings, not the settings the app presents).

It is true to some extent since Marshmellow. But apps can tell when their permissions are denied, so some of them straight out refuse to start unless you give it all the permissions it wants. This is especially problematic when a new version of an app holds your data hostage and refuses to start unless you give it a ridiculous new permission.

The Play Store has no requirement that apps degrade gracefully when permissions are denied. So the result is usually the same as pre-Marshmellow. You just get more annoying popups.

I miss Cyanogenmod where I could deny a permission (e.g. contacts) and the app would have no idea it was denied (it would receive an empty list of contacts).

That is the case in iOS. All permissions are optional and the app must gracefully degrade if permissions are denied.

Should also see if the killer apps are phoning home every time they kill anything, along with info about which app is killed on whose phone at what time. Becuase, you know, analytics.

On my phone (android), going to apps>selecting app I want to run in the background>battery>background usage I can allow the app to run unrestricted in the background.

All android phones I've owned had this option.

My understanding from the OP website is that this is ineffective for certain popular phone vendors' customizations. In particular, the Nokia phone listed comes preinstalled with an app that aggressively shuts down any running process, whitelisted or not, if the screen has been off for 20 minutes. There's simply no way to stop this behavior apart from gaining root and uninstalling the battery "saving" app, or flashing a stock Android image that doesn't contain it.

And yeah, the permissions model in Android vs Apple is different, but multi tasking in particular feels the same. i.e. Apple has fine grained permissions on demand for contacts, microphone, camera, location, etc, and requires that all apps gracefully degrade when permissions is denied.

But for multitasking there isn’t really any fine grained permissions - as long as the app is doing a whitelisted task in the background, no user permission is required. I think Apple does check that background APIs are not misused as part of the review process, though - I don’t think you could implement a tracking socket masquerading as a background download, for instace.

As I understand it, on iOS third part apps don’t actually do any tasks in the background, most such services are actually implemented by platform services provided by Apple that the third part apps request or subscribe to. So for example apps request an Apple service to do a background download on their behalf. Or the app subscribes to a notification feed that wakes it up when triggered to handle the notification, but the app doesn't do a download or wait for notifications itself.

Very often on iOS when you see a notification 'from an app' or something in the background is completed 'by an app', in fact the app didn't do any of it. This means fine grained permissions for background processing aren't really an issue on iOS, because such behavior is managed and guaranteed by Apple. It only matters when there's a security or privacy implication.

This is why background activities came so much later to iOS, because Apple had to very carefully think through and implement all the background services apps would require in an efficient and secure way.

EDIT: To be clear there are some exceptions but I'm not sure exactly what they are.

Technically, you could have an app that plays silent audio in the background to keep from getting killed and then do something else, but that would get flagged by the review process.

But, if I recall correctly, VLC will continue a background file transfer session from its built in web server on iOS if you play a movie in the background. Otherwise it will be killed after 10 minutes.

>I don’t think you could implement a tracking socket masquerading as a background download

The Facebook app used to play a silent audio track to stay active in the background, until they got called out: https://www.reddit.com/r/iphone/comments/3opxhm/facebook_app...

This isn't about protecting the user from badly written and battery draining apps. Almost all of the mentioned manufacturers ship their devices with a long list of pre-installed and whitelisted services, including Facebook and other spyware.

As a developer myself, it is just annoying do deal with and just not scalable if you have to explain each user individually how to turn of these "optimizations" (if that's even possible).

It’s also not scalable if every app starts running background processes on an operating system without “virtual memory” - yes, I know there is a difference between virtual memory and swapping to the disk.

Even stock android does not guarantee that background services can run indefinitely, but Google at least provides clear rules what process may run how long in the background and under which circumstances it is killed. I have no idea why the manufacturers are allowed to blatantly break those rules and still brand their operating system Android.

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.

I think the locked environments we have on phones is the reason we see a lot of trash apps. You don't have this development on more open platforms. At least no to that degree. So both, Apple and Google are at fault here.

It is not the API, it is not threading capabilities. Just shitty and locked environments. So define as many additional rules as you like. Won't change much.

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 vendors would use any tactic to make it less open in order to force users to run their crap, get more brand exposition, steal personal data etc.

> but its open nature would allow users to remove unwanted stuff

They would find a way, because money.

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.

The point is trash apps don't have to be a problem as long as the platform is managed properly. Anyway your trash app is probably someone else's fun entertainment.

I just doubt that "managed" platforms are delivering what they have promised and think that the quality of apps on more open systems is generally better by a few magnitudes without exaggerating too much.

And no, the trash app I am talking about exists to prey on unaware users by being an obvious fake or by extracting information about location, contacts and configuration.

"Managed" platforms accelerated this phenomenon in my opinion.

What is a trash app by your definition?

We are running a (very niche) platform + app for people with special needs, where accurate and offline alarms are necessary: this is a big problem for us.

I think about 1/3 of all our support requests are about the app being killed in the background on specific phones. The part of the app that does the actual scheduling of the alarms is a big mess with lots of device & API level exceptions. Debugging alarm problems is a nightmare.

We often advice users on what phone to buy and tell them to avoid specific brands. Sometimes users even need to buy a new phone to be able to have reliable alarm signals.

I understand why manufactures are doing this. But it really degrades the user experiences for our users quite a bit and is a significant cost (in terms of support load + extra development) for us as an app vendor.

Really hope that Android 8+ incentive manufactures to just use the standard Android mechanisms: they seems to work quite well in my experience. You can run things in the background, but only if it has a user interaction as a result: i.e an alarm notification. The user can then determine if this is wanted or not directly from the notification itself.

Unfortunately it is not much better on the Apple side of things with local push notifications limits.

>I understand why manufactures are doing this

I really don't. User has power to uninstall or replace app that is in his opinion using too much power. There is no need for manufacturers to intervene. They should only display warning about app using too much power. But it seems killing app is so much easier for them.

The majority of people don't know how or even want to be an administrator on their phone. They'll just as quickly hand the phone off to someone else to fix it, or call support, or even just get a different new phone. It's way too much of a leap to assume most users will make the connection that their poor battery life is linked to an app misbehaving, then track down that app and uninstall it in favor of an app that is better on battery.

If Samsung kills the apps, the app maker gets a bad review. If Samsung doesn't kill the apps, Samsung gets a bad review. I know which one I would pick if I was Samsung. At that point it's up to the user to decide if that choice is something they want to subscribe to.

>make the connection that their poor battery life is linked to an app misbehaving

that's why I mentioned, they could display some notification when app is using battery heavily (similar to ANR).

>The majority of people don't know how or even want to be an administrator on their phone.

Exactly same thinking as those device manufacturers. user = idiot (let's kill apps for him, what could go wrong, right?) This kind of thinking brought us here.

Does Android not have the concept of “local notifications” where you can tell the OS to schedule a notification to be sent to the app to wake it up instead of being in the background the whole time?

It does - the one that works properly is https://developer.android.com/reference/android/app/AlarmMan...

However, the implementations of the API are questionable.

Some calls to that API on some OEMs device round alarms to the nearest minute, some to the nearest ten minutes.

> Some calls to that API on some OEMs device round alarms to the nearest minute, some to the nearest ten minutes.

WHY? What benefit does that serve?

As others replied; it does. But the API does not behave consistent on different brands and API levels.

Also some manufacturers cancel alarms when the user swipes away an app (which some users do constantly to keep the recent apps list "clean")

I'm one of those users. The visual clutter leads to mental clutter. Having a "clean" notification bar makes it easier to ignore the pavlovian "check your phone!" conditioning that has built up over time.

I appreciate that in some cases apps need to be in the notification bar in order to remain running. I also appreciate those like Tasker that have the option to hide their icons or use "empty" icons (so nothing shows).

It has, but from what I've read some of these "optimizers" helpfully "optimize" the scheduled notifications away or move them around in time.

Yes, and these manufacturer optimizations often break them.

What about changing your app to a service that you host that calls their phone instead of an alarm?

He did specifically just say they have to work offline.

doh, must have missed it

For me this problem is very real. For example I got my mother a Pocofone F1 (by Xiaomi). Everything works fine, WhatsApp notifications arrive but there are some apps which just get crushed by Xiaomi's battery saver.

Audible's lock-screen widget for example just does not show up unless you enable/disable 2-3 battery saving and notification settings after installing the app. I think this incantation can't be expected even from advanced users. Normal users will just give up and live with terrible UX, complain to the dev or switch to another app. The same goes for fitbit, getting it to sync in the background involves a similar mixture of battery saving and notification settings which are labeled in a way that noone would dare to change them or have questionable defaults. None of this was an issue on the Nexus 5X. To me it looks like Xiaomi has a whitelist of apps which get special defaults when installing so they work fine while others which are not on this whitelist don't get this treatment.

I can understand the benefits of aggressive battery saving especially as there are apps which behave badly but the state it has come to now is terrible UX and is just another frustration instead if actually delivering a benefit to the user. This seems to me like "optimisation" for the sake of benchmarks and marketing claims.

If they didn't do this sort of aggressive system management, I'm wondering what the negative effects would be for them as a brand. I doubt it would be about benchmarks, those are generally done on clean systems at least for review purposes. Likewise Marketing is mainly about features.

I suppose it must be genuinely about the user experience and brand perception by device owners. If the phone slows down and the battery drains fast users will blame the phone manufacturer, while if apps crash or app features don't work users will blame the app vendor even though the reality in both cases would be the other way around.

Another anecdote: my wife and a colleague at work (so 2 different people I know) have Xiaomi Note fives, and this model kills the stock alarm clock app! Regularly for both these people the alarm does not go off. My wife keeps an old Nokia candy bar phone around as a backup alarm it has happened so often. There's a workaround, maybe just placebo?, for this too: you can go to the recent apps screen and pin the app. But any kind of system update seems to undo the fix. I imagine your audible lock-screen widget will have the same issue, that system updates break the fix, and MIUI updates quite regularly.

I have a Xiaomi A1, with a more stock version of Android, and so far this has not been an issue. But I noticed in the recent Pie update that it mentioned "battery improvements". I've had no problem with battery before now, it lasts all day easily and I get home with 70% or so. I hope it doesn't start killing the alarm clock at night, when it's plugged in to charge, just to save battery.

The first thing I do on any Xiaomi phone is to install Lineage OS - because MIUI is just unusable for me. Lineage 16 release for Poco F1 is very stable although it's not an official release yet.

Go to the developers settings and turn off MIUI optimization. That's the only setting that worked for me. No more killed bg apps.

MIUI has always known for aggressive sleep patterns, considering Pocofone is an India targeted device & WhatsApp is the go-to social media platform in India; It's intriguing that they haven't fixed such issues.

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 own to "do stuff" no more than I want my Ubuntu to "do stuff" while I'm doing something else. I only want the application to respond when I'm viewing it.

On Ubuntu, I always disable stuff like evolution server and automatic indexing after a fresh installation. At least you can do that on Ubuntu, that isn't necessarily always possible on locked-down systems. I'm happy that Android is quite usable these days because of Doze and background task killing.

Did you even bother reading the complaints? These "background killers" kill background applications the user wants to run and has specifically asked for e.g. alarms, health/fitness trackers, …, usually in the most harmful way possible (e.g. straight kill -9) meaning the application can't even tell the user what the issue is, and with complex steps users have to take (possibly repeatedly) to whitelist specific applications.

Hell there are comments in this thread testifying that these built-in "battery savers" even kill the built-in alarm application.

been using android since forever. Now I'm on a s8+. I never had a case like this. maybe I didn't noticed it. But my alarm always went on like it should. my music always played.

is this a bug that sometimes happens? how rare is it?

S8 has this, but can be opted out (plus it has what I assume is a whitelist of pre-approved apps, but even those can be opted in, IIRC). It's clumsy, but sort-of works. It does break some old apps that rely on scheduled wakeups, though :(

Seems it's mainly an issue with Nokia devices, the other manufacturers were minor problems in comparisons.

It is not a good thing to kill an alarm app then purposely ignore its registered alarms, or killing a media player the user wants to listen to in the background.

You using Ubuntu so you’re fine with wasting time setting up stuff that’s just supposed to work, but most users are not

Case in point:

https://androidcentral.com/blocking-huawei-phones-downloadin...

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 connection. It's very frustrating.

Try selecting 'Lock' for the VPN App from the recent apps section (top right)[1]

[1]:https://imgur.com/Bk8jXbJ

Hmmm, I had no idea this was a thing. Will give it a try!

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.

On my phone, if I go to the apps list>tap app I want to run in the background (VPN app for example)>battery>allow background usage.

I have a galaxy S9 but there should be the same or similar setting on yours.

It's exactly the same thing he's talking about. The issue here (I also own a OnePlus 5T) is that OnePlus' implementation of memory saving is too agressive and often ignores user configs.

Actually, I think it depends on the use-case. I mean, there are some use-cases which are inherently battery intensive. Like accurate position tracking or receiving real-time messages.

I think the problem is, that many users do not know which apps require more energy due to the specific problem they solve and which apps are just badly engineered. So to let the user decide every case is a bad option (+ decision fatigue). Letting the developers decide is even worse, as they would simply say, that their app requires as much energy as they need. So the vendor thinks he has to make that decision (as they don't want their phone to being perceived as having a bad battery life), who neither knows anything about the specific app nor about the use-case (probably the worst option).

I think the system should simply report battery offenders (above the threshold of a well-engineered instant messaging app for example) to the user in a manner of 'App X used Y% of your battery in the last 24 hours. By limiting the battery usage, the app might not function as it is supposed to be. Do you want to limit the battery usage of this app?'

That way, most developers would have a chance to build good apps which do not get reported and users would stay in control.

> in a manner of 'App X used Y% of your battery in the last 24 hours.

I am pretty sure that my stock Android 8 is doing that already

Killing background tasks is great and Android does that automatically to save battery usage. But these manufacturers have implemented their own functionality on top of Android which cripples even critical messaging applications like WhatsApp, Slack, Gmail by not delivering Instant Messages notifications instantly.

Just as an example, only chat/messenger apps on my Oneplus with saver enabled (default):

- Skype - always killed

- Slack - always killed

- Whatsapp - sometimes killed, rarely

- Telegram - never killed

- FB Messenger - never killed

All these are fully featured apps with tons of different functionality.

Telegram and FBM never ever trigger "this app is draining your battery" while Skype triggers it regularly when I sometimes start it on phone.

I'm going to generalize and say that probably some apps are simple bad and need to be fixed instead of granting them exceptions and allowing to be battery hogs.

Those apps are explicitly whitelisted by OnePlus. There's nothing to "fix" they're by the app developer, because the killing algorithm chooses based on app name, not app battery consumption. Facebook can kill your whole battery and you'll never get a warning.

I've had a Nokia 6.1 on Pie, apparently the worst-case scenario for this, for a few months. The third-party optimiser is running, and I haven't problems with Slack or Jabber clients. How are people reproducing this behaviour?

I have a OnePlus 6 and none of the apps you've just mentioned fail to receive notifications when my phone is asleep.

It does happen on oneplus devices and it's quite common to find complaints on oneplus forums like : https://bit.ly/2VSkhty . In all cases it is solved by adding these apps to the whitelist.

If you aren't facing issues then these apps are probably already a part of the whitelist on your device.

Auto-killing apps to save battery is obviously good - nobody is contesting that. The bad thing that is being highlighted here is that there's no user friendly way for app developers to request additional privileges from the user.

If you're looking for user friendly ways to request privileges, that solution should really be offered by core android in a way that works for manufacturers and users and probably won't appease all developers. App permissions systems have been a nightmare for users from the start so you can't expect users to learn a newly revamped permissions system. They'll just continue to ignore permissions on install and complained when their phones aren't working the way they expected. What's evolving out of the manufacturers is a simplified system that requires explicit permissions from the user after installation to enable problematic privileges and active governance to manage battery/data hogs.

What?

The system you’re saying “evolved out of the manufacturers”, runtime permission requests, is from “core Android” all they way back at 6.0

And the problem has almost never been users blindly revoking permissions, it’s blindly granting permissions.

The problem the parent comment mention isn’t the method of asking for permission, it’s the fact there literally is not a permission.

And Android already has built in “active” battery management with Doze, if anything manufacturers are ruining it with poorly coded “optimizers” that do dumb things like kill their own alarm apps...

And even if Android did add a permission to allow an app to do whatever it wants in the background and kill the battery as much as it wants, manufacturers can’t be bothered to write optimizers that don’t kill a music playing app while the user listens to music, why would they bother respecting a permission they didn’t make?

we would end in the same place where we are now, apps would nag and require that we put them on the whitelist, I have a huawei mate 20 pro, the biggest reason thah I like this phone is the battery life. it has a huge battery and with agresive management I can go with 50% from morning till evening. there are only couple of apps in my whitelist. everything else its free to manage for me automatically. before that on my nexus device I got annoying notifications from my smart watch watchface app, that was using notifications for promotions and such.

Killing apps that the user isn't using or relying on is a good thing. Randomly killing apps running in the background is a bad thing.

This sounds like it should be an app permission: is this app allowed to run in the background or not?

LG even lets you pin apps you don't want auto-killed which is useful but I rarely use it since I kill them manually before it gets to do it for me, I didn't realize this was an issue on other phones. I guess that's why LG is technically not on this list? I've always thought it was a stock Android feature.

I actually like the move to kill background tasks. Don't get me wrong I think they're great when they're needed. But if I only installed the app because the mobile site is crippled I don't want it to destroy my battery polling for content changes when I only open the app once in a blue moon.

The right way to solve this is with explicit permissions (similar to iOS). Rather than arbitrarily and sporadically crippling apps with opaque limitations.

Google & manufacturerers have gone too far in the quest for the Holy Grail of extending battery life. To the point where it’s negatively affects the user experience quite often (there are quite a few examples in these comments).

It makes Android overall seem more buggy (for example, not receiving notifications for an instant messaging app is pretty ridiculous, assuming I’ve opted in and want these notifications).

One other big issue is that push-based wake-ups on Android don’t work reliably. For example, on iOS, if you want to wake up the app in the background when you come in range of an iBeacon, you can do so (with user permission), and it just works. Meaning you don’t need to run a special arbitrary background job (which is much less battery efficient).

On Android - BLE wakeups are so incredibly unreliable that entire classes of apps are becoming less and less viable. And without the loophole of running background jobs to manually scan for beacons, users (and developers) are basically shit out of luck.

God save us from beacon-related functionality anyway. No I don't want my day interrupted for a message about your service, sorry!

In that case you wouldn’t opt-in to beacon notifications.

But there are many people with varying use-cases - some of whome want reliable BLE detections on their devices. And if they opt-in to these notifications, then it’s a shitty experience when it doesn’t actually work as intended.

It makes Android overall seem more buggy (for example, not receiving notifications for an instant messaging app is pretty ridiculous, assuming I’ve opted in and want these notifications).

Do instant messaging apps really need to be running to listen for notifications? Why isn’t listening for notifications being handled by one central Android process that then dispatches it and launches the app if necessary?

That’s exactly how it works - but this service itself is throttled.

And, in Android 9, “App Buckets” will increase/decrease throttling depending on your usage of the app.

For example, an app that you don’t open regularly, but do want receive timely notifications from (like a banking app, or calendar/scheduling app), might only get 1 window a day where it receives notifications.

And worse, what they're doing confuses android's own code into thinking the apps are crashy.

So if you run e.g. (new JobInfo.Builder(1234, name)).setRequiresCharging(true).setRequiresDeviceIdle(true)... to do something heavy (like reindexing an on-device database) while the phone is charging, that job will simply not be run on some phones. You have to check whether it's been run at app startup, and if necessary run it while the user is actively using your app.

Xiaomi Redmi Note 3 Pro even kills Google Maps navigation after few minutes (with screen on). I have to use MAPS.ME, it doesn't kill it.

I don't want WhatsApp (owned by Facebook) to run in the background on my phone at all times. I don't trust them, especially after Instagram (also owned by Facebook) started using the camera by itself on my phone, without my permission.

Slack would be fine, I guess.

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 messaging app and you don't receive messages because Huawei didn't whitelist the app).

The irony: Many manufacturers factory-whitelist apps like WhatsApp, Skype, sometimes Telegram. That means that smaller messengers get killed (=no more new message notifications) and users complain to the developer because "with WhatsApp everything works fine"...

These days the app doesn’t run in the background when receiving an FCM push notification (unless it’s already awake). The message is created by a separate Google Play Services process. It’s only when you click the notification does the target app’s process get woken up.

IMO, the best way to solve this is with an explicit “Let this app run in the background” permission, rather than implementing all these “smart” features which are incredibly non-deterministic. Which leads to developer & user frustration alike.

Take the example of the new “App Bucketing” battery saving feature in Android 9, plus a banking app and WhatsApp....

App Bucketing will basically restrict your background processing based on how often you interact with the app. So for your banking app (where you usually want immediate spending notifications), because you don’t really open the app that often, it’s going to start throttling your notifications (and prevent it from running arbitrary background jobs).

But for WhatsApp on the other hand - because you’ll likely open it more often - it will have full permissions to run in the background any time.

If as a user you wanted to prevent arbitrary WhatsApp background jobs and get instant banking notifications - well tough luck!

Then you need to uninstall the app. No phone is going to guarantee you that it won't run.

I don't want Slack or Gmail to deliver notifications instantly. I'd love to have functionality that saves battery by delaying them.

If the app is killed that doesn't just delay notifications. It prevents them until you manually open the app again.

So why not disable the notification functionality if you don't want it?

Both these apps allow you to do that in-app. I have Gmail not notify me for work emails and notify me for stuff on my personal account.

Get one of the phones listed in the link. Xiaomi is brilliant in this regard !

Don't most apps use GCM to deliver notifications anyway?

Yes this is very true. Some apps like Truecaller just destroy the battery like there is no tommorow. Most other app including some games keep running just to tell me when it's time to collect my mystery box.

Point being the majority of the apps are badly coded to poll or drain battery, send unnecessary notifications.

This reminds me of the popup blocker thing in web browsers. While there were some legitimate uses most of the time it's abused so every browser blocked it.

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 alarm clock only -- and the phone has no problem lasting a week.

I use these modes extensively when going backpacking for several days, as I do not have to carry any power banks, which saves precious gramms :)

edit: punctuation, grammar

Interesting. Batteries in smartphones usually have five times more battery capacity then feature phones, it should last over a month!

It depends on how often he uses his phone and where he backpacks. Being in a low-signal environment will eat up a lot of battery even on a feature phone plus having screens 5x bigger than feature phones also lead to more battery usage when being used. My old OnePlus3 which at this point is only used for alarms and has apps set to auto update (doze is on, but battery saver is off) in the background lasts around a month before I have to charge it again.

Smartphones also have 5x more screen to light up, too.

Reminds me of YotaPhone 2 eInk display - pretty crummy, but the Snapdragon 820 device stayed on a week on without additional power saving...

My old Turbo 2 could, in fact, sleep for a month in airplane mode (with crappy apps removed). However that would quickly drop to about a week with light usage, e.g. connecting to WiFi somewhere to get directions or pull email for the day.

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.

I wanted to say exactly the same. The Sony page is horribly misinformed.

Calling Sony "toxic" for including a useful OPT-IN feature to extend battery life? Pfff...

A much better (in my mind) solution to your backpacking battery life issue is to carry a phone with a removable battery. If you're turning off all services including calls and SMS, there's simply no reason for the device to be powered on at all, and removing the battery guarantees there's not even a trickle of power being drained. For your alarm, well I assume you wear a watch backpacking, so you can use its alarm feature.

Of course, then you have the issue of finding a quality midrange or higher end phone with a removable battery in the first place. They are an endangered species due to the thinness war.

> Of course, then you have the issue of finding a quality midrange or higher end phone with a removable battery in the first place. They are an endangered species due to the thinness war.

I prefer external charging bricks -- if you upgrade your phone, you might need to buy a new cable with an external brick, but you are more likely to need a replaceable battery with a new form factor or output.

> If you're turning off all services including calls and SMS,

The way I read GP he disabled everything except calls, SMS and alarms.

Which kinda makes sense, you want something for authorities to track you in case you end up missing and unable to call for help yourself.

Yep I completely misread that, sorry.

Interestingly though it is possible to remotely detect which users are facing this problem and send them instructions on how to add an app to the device's whitelist. I faced this exact problem in my previous company Flock, and built services to detect and inform users which substantially brought down user complaints.

https://hackernoon.com/notifications-in-android-are-horribly...

Nice write-up, and interesting idea.

But how did you guys deal with the situation where FCM delivers and displays a notification without waking your app up. In that case, if the user dismisses the notification without opening it, then it will count as delivered by FCM, but not as delivered by your app, right? Which isn’t actually the case.

What we observed was that in cases of devices like xiaomi and oneplus, the app goes into a state of being force killed. So even if the notification sent is one without a data payload ( in which case the app is not woken up ) , the notification will not be displayed to the user. To get around this issue we sent all messages with a data payload to ensure that the app is woken up(or atleast the system tries to wake it up).

I have an Android One Nokia (8 Sirocco), and:

a) I wholeheartedly want this behaviour. The phone lasts 2-3 days without recharging, and I no longer fear leaving home with 30% battery.

b) It's not an app that kills background apps. It's Android's own Background Activity Manager, where apps that are not whitelisted can't wake up the CPU. They run only when the CPU wakes up for some other reason (screen-on qualifies but it's not the only opportunity).

I had to get used to it. In one instance the alarm didn't wake me up, because it is not whitelisted to wake up the CPU. After enabling the correct apps, I maintain pretty much the same great battery life and all app functionality I want.

From a usability perspective, this sounds crazy. Is is responsible of me to recommend Android to my non-technical friends?

I wouldn't say so. I got my grandma a cheap Android phone and a book to help her learn because I thought it'd be better since I also have Android and can help her.

My grandma is 89 now, she uses Whatsapp, Youtube and whatnot and I am not kidding but within 2 months she had:

- AVG antivirus (an ad told her she had a virus)

- She had batterylife for 7 hours before a charge was needed due to shitty apps

- Ads on her lock screen?!

- Ads on her homepage

After 6 months and 3 house calls to fix her phone we gave up and she got my aunts old iPhone 5s with a new battery.

It runs iOS 12 now and it runs flawlessly and protects her from all the stuff I mentioned.

From a guy that has always had Android: most users need iOS level protection. Just simple facts.

A cheap phone has worse functionality than an expensive* one? Forgive the snark but this comparison doesn't make sense to me.

*Speaking in terms of launch MSRP.

No. For anyone non-technical I always recommend an iPhone. I can simply say, "Press this button if you need to open another app." The difference in UI/UX you see on different android phones and auto-hide enabled soft navigation buttons confuse non technical people a lot.

> No. For anyone non-technical I always recommend an iPhone. I can simply say, "Press this button if you need to open another app." The difference in UI/UX you see on different android phones and auto-hide enabled soft navigation buttons confuse non technical people a lot.

I wonder how they'll deal with the new gesture nav (both iOS and Android), because I think that's possibly more confusing to a layman.

It's not a usability problem. It's an option I'm very glad to have.

If you disable the background activity manager, under Settings | Battery, you get the same battery life you do on iOS (about a day, give or take).

If you're not a power user and you're only getting one day from a charge on an iPhone, you may want to investigate the health of your battery.

Another big benefit of going with Apple for non-technical users is the Apple retail stores. These stores host free classes on how to use Apple devices and apps. This is huge for older people.

https://dontkillmyapp.com/samsung

> Yes, even Samsung - a dominant vendor in the Android market - is using nasty battery saving technique which may kill background processes and render alarm clocks useless. See below for workarounds.

Wait, do you really need a background task for alarms?

(why) isn't there a system-level service to notify and wake up your app at a pre-defined time or interval?

No, you don't need a background task for alarms. There is a JobScheduler API for that.

The aggressive battery settings of most vendors only interfere with badly coded apps to begin with, apps that use background tasks when they should be using more appropriate APIs.

On some Xiaomi devices the stock alarm clock - the Google one - regularly fails to trigger alarms. If Google themselves cannot code an Android alarm clock that works with these aggressive battery saving anti-features there's little hope for anyone else.

Are you referring to Xiaomi devices that are running stock android (part of Android One program)?

>apps that use background tasks when they should be using more appropriate APIs.

But some tasks do need to run in background, don't they? Specifically, sports tracking apps. Had a lot of issues with those on on various phones; now I simply don't switch out of the tracking app at all while it's running (otherwise, I can never be sure it simply won't be tombstoned in the background).

what the jobscheduler api is supposed to be used for isn't clear in the docs so people tend to default to creating services(the old way of doing background activities) instead.

The API docs seem perfectly clear to me.

https://developer.android.com/topic/performance/scheduling

> (why) isn't there a system-level service to notify and wake up your app at a pre-defined time or interval?

there is. But, defining services is extremely easy and so people often just roll their own. Plus, it's academic.

The whole damn page you're commenting on exists because those APIs are broken by OEMs. You schedule execution, the alarm doesn't trigger. Did you look at the page before commenting? :(

My Galaxy S6 was really aggressive for closing apps that it thought might impact battery life. Specifically, it was always closing one app I used to record my workouts in the gym. Very annoying.

My S8 seems a lot less extreme in this regard.

The default mail app on my recent-ish Samsung flagship phone notifies me of new email anywhere from 30 minutes to 1 hour late. I used to depend on K9 Mail for business on the go, but it was even worse: notifications were often several hours late. Android was dropping the IMAP connection and not allowing the app to reconnect for a routine poll.

There doesn't seem to be any general-purpose email app on Android that can actually notify me at a reasonable interval (less than 10 minutes, if not immediately). Even after disabling every power-saving feature I could find, Samsung is still killing and crippling their own default app.

I understand that it takes a bit of battery to poll an IMAP server every few minutes. But if I want an app to be able to poll an IMAP server in the background at the cost of having to charge my phone a little more often, that's my choice. Besides, my old phone didn't have this problem and its battery still lasted a whole day.

What's even more infuriating is that the phone allows preinstalled social networking apps that I don't even use to continue running in the background while it happily kills the apps I actually need.

The social media apps will almost certainly use Googles push notification service, which is the only background notification allowed.

Your imap client is trying to hold a TCP connection open to your server, which isn't allowed.

There's a good reason the phone doesn't allow that. Firstly, the push notification service can be waiting for a notification for an app while the app is entirely unloaded from RAM. Hundreds of apps can be listening for notifications at once, with no system resource overhead.

Secondly, imagine every app wanted to have a TCP connection open to it's own server. TCP must generally go through your wifi/3g providers NAT. That NAT gateway will drop idle connections, with the rules on which connections are dropped varying for every type of router and provider. In general, if you want reliable delivery, you're going to have to send some packet down a TCP connection every 5 minutes, although some providers it can be up to every 3 hours. If every app applies it's own heuristics to figure out how often to send a keep-alive message, and you have hundreds of listening apps each with their own connection, and no synchronisation between them, your phone will end up waking up every few seconds for some app to send a keep-alive.

Instead, Google keeps open just one connection. They have a serverside database of all network providers to know which ones drop connections when (BTW, this is a big advantage of using your cable providers default modem. If you have your own modem, this mechanism won't be accurate). It can then wake up and send just one keep-alive at the exact correct time.

From the server side, Google can batch messages to clients. It can decide that receiving 8 new marketing emails is important enough to sync to your phone, but only if the phone will be waking up for some other reason. Then when a snapchat message comes in, both the mail app and snapchat will be notified by a single wakeup of the phone.

Overall, it's a very good design. There are only 2 big downsides:

1) It's centralized. Nobody else can run a notification server. They have a monopoly on delivering notifications.

2) Their server isn't very good. It doesn't have the capability for example to simultaneously listen on 3G and wifi. It sometimes gets overloaded and unnecessarily delays messages. Their database of network providers is sometimes a bit off, meaning your phone is sending keep-alives every 30 minutes, while the connection times out after 20 minutes, meaning there is a 33% chance your message will get delayed by up to 10 mins.

Yeah, I don't really expect a mobile O/S to keep connections open indefinitely. It's hard enough to do that when the phone is awake and on the move, much less sleeping.

The O/S should, however, honor an app's request to wake up every 5-15 minutes to open a new connection, do some things with it, and go back to sleep. Especially if the user has given explicit permission to let the app in question use all the battery it wants. Periodic wakeup is what most email apps expect when they're set to "polling" mode. It used to work perfectly until about two years ago. It doesn't work anymore on recent Samsung phones. The system just ignores the wakeup schedule set by the app.

Do you know of anywhere, where this is all explained? Like the idea of recording average timeouts by ISP?

I'm not sure anyones written it up yet. You can see it for yourself if you run adb logcat on a sleeping phone. Try running it on different networks and see the keep alive period. (you'll have to turn off all push notification sources, because a push message counts as a keep alive too).

In fairness an exception is made for ActiveSync. I wonder how that is handled at the OS level.

I got weirder behaviour from the stock Android email app: I discovered it's sending emails weeks late. When I discovered this, I found one email that was several months old lingering in my outbox.

Probably not related to this, but still incredibly weird, not to mention seriously broken.

K-9 Mail works instantly for me (OnePlus One on Cyanogen). When I buy a beverage at my hackerspace, I hear the pling from the confirmation email within a few seconds of the purchase.

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 about how much energy they really need to consume for their tasks.

One issue is that these first furtive steps in that direction may not be putting the tools in the developers' hands to do that well. But everything in software starts at an early phase.

(It'll be interesting to see whether the market prioritizes battery life by getting the phones implementing these features or app richness by treating these phones as "damaged" and routing around them. This site certainly helps customers make that choice).

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.

>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.

Here's a process management UX I've been asking for ever since Android came out:

I want to have a list of all running apps and their background services. I want to be able to put any app/service from this list down, and have it stay down. That is, I want the ability to kill an app and/or their services, and not see them again until next reboot or the next time I launch the app in question.

It's not that big of an UX burden, and it would solve a lot of the battery management issues.

Not sure if the complaint here is simply from developers of badly designed apps?

I didn't do much Android development, but last year I had to develop a small app doing a continuous background task.

Yes, it is hard to do that in Android (it seems). But you are supposed to use all sorts of other mechanisms that Android provides. Like for an alarm clock, I guess you tell some system service to play the sound and then go back to sleep. The sound keeps playing and your app sleeps (I guess - don't know this particular case).

Some things seemed really hard to do, but it is by design, and users really need to be protected from vampiric apps.

I don’t see their problem with Sony’s stamina mode:

The UI makes it very clear if you have it enabled, it explicitly tells you what it does and I never missed anything because of it.

If you keep your phone on silent you don’t care if it delays fetching messages until you actually turn on your screen anyway...

> If you keep your phone on silent you don't care if it delays fetching messages until you actually turn on your screen anyway...

That doesn't follow. All I want is my phone to be quiet; I don't stop caring about timely notifications because of this. Also, just because my phone is on silent doesn't mean vibration is turned off and, in the case of my iPhone, the notifications go to my Apple Watch.

If your phone is silent it still blinks the message indicator led when something has arrived.

My phone is almost always silent because of our dogs, but I have it lying on my desk and see when something has arrived due to the blinking indicator.

I am glad that they are doing it. Also, I don't think this is being done for benchmarks or marketing. Pretty much all mobile manufacturers specify/market the battery capacity in mAh and not in terms of hours. Also, even in cases where the battery life is marketed as full day/2 day, I don't think it impacts the purchase decisions. Killing background apps has annoyed me sometimes, but there have always been solutions by tweaking the settings, in my experience (on Nokia, Xiaomi & Samsung). Overall, it has definitely improved my experience by drastically improving battery life. The article says "just to get a little more juice", which I have found to be untrue in my experience. For example, comparing the battery life of Xiaomi Redmi Note 3 running MIUI vs the same hardware running Lineage OS, the battery life was significantly better on MIUI and worth the sacrifice of spending some additional time in setting up apps for background execution. I wish my current Nokia phone was more aggressive in killing tasks.

I'm confused. Is this something that occurs all the time, or only when I turn on Battery Saver? Because I love Battery Saver mode. Unless you're a communications app (messaging, phone, email) I don't need your app running when I'm not actively using it.

Most brands of phone do this all the time, and do it even more aggressively in battery saver mode.

I dont get it?

This is the best thing for me. Iam fed up of the notification loop of apps that I have to eventually delete.

Thank god for telling me to buy a Nokia next time.

(assuming the claims on the site are correct, since I have no first-hand data on it) You really don't get that some people think apps like alarm clocks, sleep tracking, GPS logging, ... are useful and should be allowed to run if the user chooses them? To me, a phone that can't reliably run an application for a few hours is fairly useless.

I own a Nokia phone running Pie.

My alarms go off just fine (although I vaguely remember it not going off once or twice a few updates ago), my activity tracker works fine[0] and syncs periodically. I don't use GPS constantly. Signal notifications were also delayed a few updates ago, but now everything runs smoothly.

I find it a worthy sacrifice to make for a sturdy Android One phone with solid performance and a battery that can last two days on medium usage. My activity tracker lasts weeks without charging (comparable to a Kindle).

[0] Worth pointing out that my activity tracker was also developed by Nokia (before they've sold their health division to Withings), so it may receive some special treatment.

I read a comment on Reddit [0] from a Nokia user that had a large file transfer using Solid Explorer killed twice because he left the phone unattended and the screen shut off. It worked when he kept the screen on.

Would you mind testing if background file transfers work as standard and with manual battery optimization whitelisting?

[0] https://www.reddit.com/r/Nokia/comments/afkuh4/dontkillmyapp...

I've never had any issues with alarms not going off either, on my Nokia device running Android P

The site lacks proper technical explanation of what the problem is exactly.

This sheds a bit more light on it, whilst still being non-technical: https://dontkillmyapp.com/problem/

It seems to be that these vendors ship builds of Android with aggressive battery-optimized defaults that breaks applications that rely on being able to run in the background.

Not just long-running background processes (e.g. gemerating a backup of your app). It may even prevent your push notification handler from running.

Most push notifications are spam, and even when they aren't, they are usually from self-important apps that think they are the most important thing running on your phone.

The only push notifications I want are messages from humans.

If you click on a brand you get more detail, e.g.:

https://dontkillmyapp.com/nokia

I actually really like the battery optimization feature. I've only needed to turn off battery optimization for one app: Slack, because I need alerts for it at all hours. Every other app manages to get it's alerts through without it and the battery on my OnePlus 6 lasts forever. Sorry app developers but if I have to trade performance for battery in background apps, I'm going to choose battery almost every time.

I think Google should consider addressing this issue in their next Android.

If you browse through Alarm Clock app in Google Play Store, you will realize most them are having similar customer complain - "The app used to work till I upgrade Android OS"

Currently, I need to post the text in my Google Play Store description :-

" Reminder doesn't work reliably for certain devices. Their over aggressive Battery management mode, have prevent reminder to work in background. Please turn off that "feature", allow WeNote runs in background, if you want reminder to work reliably.

Please read https://dontkillmyapp.com/?3 for solution. "

First I though "Is Nokia bad or good? Then I saw 'bad vendor score'" so I figured they are the worst. Then I got confused about all the vendors having the same score, but a different colour. Then I saw that some of the circles are slightly darker than the others... This type of visual communication hurts my brain too much.

Something on your end is not loading (JavaScript off?)

Each vendor has 1-5 poop emojis with Nokia having 5 and Stock Android only 1

Thanks, yep, I ad-block external domains by default.

It seems that just as bad apps they are trying to shield their website is also badly written and the simple picture of poop is linked from whatever of the 7 third-party sites with spying javascript code they are using and is blocked by adblock. Circles for me too.

Ah that explains it. I was under the impression that I was looking at a simple website, not some super fancy front-end application. I block all external domains with ublock-origin.

Since when do you need to serve emojis from a third party? I thought you can just insert them straight into your HTML. Or is that not cool enough?

I think it's a delay loading the images - it's scored by poo emojis.

It took a few seconds for that to be visible when I visited the page, initially only showing as large dots.

I watch the evolution (and evolution is the right word here, given the complete lack of intelligent design) of Android APIs with a kind of morbid fascination; a ritual dance between inept API designers with the foresight of a two year old spotting an ice cream vendor across a busy street and app developers who (driven by management) have to buy into the fact that their life saving and community transforming app (CRUD app for ordering fast food or something like that) must support 34 kinds of real time notifications.

Interesting - I recently got myself an S9 and my wife a OnePlus 6T, and the OnePlus gets much better battery life (with fewer apps and overall lighter usage) - but now I'm not so impressed if that's how it's achieved.

It's a fairly divisive issue - I can understand developers getting frustrated if their app's functionality is broken, but I do think this should be more in the user's control. A permissions-based model for backgrounding would be better, but there's too much permission prompting as well on Android (and this is something you can't back up - so on any restore, you're left 'allowing' permissions in every app you use in a new way - yes, when I select the camera mode in an app, I want to allow use of the camera - gets tedious across a bunch of different apps).

My S9 (or maybe it's just Android) also puts a notification up if an app continues to run when I click 'back' out of it (or some other heuristic - it's not for every app, but it does a good job of identifying which are running) - which I think is a better compromise. It makes it much more visible which apps are consuming resources, and tapping the notification takes me to the App Info page with the 'Force Stop' button at the top. It's a bit noisy (it appears even for the stock music player, where obviously I want that to continue running), but it serves well as forcing visibility of battery hogs (whether it's through incompetence or nefarious background data collection), and reassuring to see it there for the apps I want running in the background. I would rather see more of this sort of visibility - maybe as well as just overall battery usage, the battery use in settings should show battery usage by apps when the screen is off or the app is not in the foreground. As the device owner, I want to be in charge of which apps get that privilege.

An example of this problem is casting shows to Chromecast. Android often kills your app in the background while you're watching, and now your Chromecast controls don't work and you have to reconnect.

This is so annoying! Do you know what needs to be whitelisted?

I haven't been able to really figure it out, to be honest.

Such a relief to find this! Some of our users use our Android app for very time sensitive notifications. They constantly come to us saying that our apps and push notifications are slow. It always seems to come back to battery saving modes for their specific Android device, and a quick Google and following the top steps never seem to work. This is so very helpful!

On the other hand there is an uncontrollable mess of bad apps made even by reputable vendors such as Samsung that just sometimes enter whatever weird state that is impossible to debug and just drain battery like there is no tomorrow. More advanced power drainers don't drain battery themselves but hide in shadows and just keep the phone in "awake" state, essentially halving it's battery life and are very hard to catch and impossible to fix (except for uninstall). I'm both hands for ultra aggressive battery saving modes because if one or even ten apps malfunction it not good but acceptable, if in the evening of day 1 I have 5-10% of battery on the phone that is verifiable capable of running for 2 days, now this is unacceptable. It it renders Skype on mobile unusable, because it is always killed by battery saver, well to hell with such crappy app, their competitors work just fine in the same environment.

If they'd just abandon the quest for thinness and put decently-large removable batteries in their phones, it would make crap like this unnessary.

The solution to this should be user experience billing.

If your app wants to run a background service which degrades the users battery, you are degrading the user experience for that user, and all the other apps they use.

Another app on the same phone which is very power efficient will still not get used if the battery is dead!

App developers who use up the phone battery should be required to compensate those who use it sparingly.

Google could set up a market for 'milliamp-hours', where each mAh used up by an app is worth $0.00001c. Apps will put money in the pot (subtracted from ad revenue) proportional to how much power they use, and be handed out to all apps based on app usage (how many hours in the foreground for example).

Ehm, no?! I want more control over what runs not less. It's my electricity on my phone, I certainly don't need someone else auctioning it off like my phone is a billboard.

Your idea basically means that apps that spam ads can use more power, even if they're used less. And free or paid apps without ads couldn't afford to run at all. How does this help the user?

> Apps will put money in the pot (subtracted from ad revenue)

At this point you discover it costs more to render an ad to the user (and especially to download it) than it pays the app developer ...

I have had SO many problems with my Android version of a background-running app I made. I've even made a PDF guide just like this page for my customers. Glad to see it's "not just me" - hopefully the vendors will start waking up.

Only issue I have on my OnePlus 3T is Slack. I'm constantly missing or getting late notifications. And I tried fixing the issues with their support, but it didn't lead anywhere. They tried their best, but I can't blame the phone vendor because I have a dozen more apps with notifications, services and whatnot running quite well.

I've been out of Android app development for some time, but I hang out with a few Android developers, they usually have most of the issues with Samsung, they say that there are often some quirks that have to overcome. That mostly corresponds to my outdated experience.

Whether it's an Android issue or specific to OnePlus, I've noticed I have to reconfigure Slack as a "non-battery-optimised" app after each app update.

EDIT: More info on the subpage: "To avoid the system to automatically revert the not optimized setting, you must also lock the app into the ‘Recent App’ list." https://dontkillmyapp.com/oneplus

It also for me explains a lot about about the problems I've had with Fitbit notifications. They use an always running background task, and have a long list of troubleshooting steps to disable/re-enable the service repeatedly and after every Fitbit app update.

Makese sense no since I have a Oneplus.

"Doze" is a nightmare for apps that need reliable GPS readings.. the only real solution is a service that polls continually to get the GPS when the screen is on so that when the screen is off it can use it to do various background tasks (and of course, it ends up not being super accurate as when the screen is off the user is typically moving, which is when you'd want the GPS to be accurate). This ends up using more energy than would have been saved if the GPS wasn't available periodically when the screen is off! It's totally ridiculous..

Badly written apps make 99% of Google Play, no wonder vendors are trying to resolve it.

I only looked at Nokia but it shows an embarrassing solution to the problem of users not having enough control over their phones. It should be effortless for users to control what apps can run and how much power they can use in the background.

It is time for the vendor neutral cell sized tablet with only a data module to avoid the draconian telecom monopoly protection regulations.

See also this post about notifications delivery interruptions on Android and how to fix it: https://onesignal.com/blog/manufacturers-interfere-with-reli...

I think the approach taken by these phone manufacturers a tually makes a lot of sense.

Most developers won't admit it but a lot of apps are quite terrible nowadays. Yes it is very convenient that your app does something in the background that is maybe useful, but it's only one app. When you have 30-40 apps installed w/o auto kill, the battery drainage is terrible.

For me moving from LG to Xiaomi was great in terms of battery life. And yes, sometimes there are app which shouldn't be killed but it's easy enough to change their setting in the battery saver. And really these are only few, most app deserve the auto kill, as they abuse the priviledge of being able to run in the background.

I hate apps that run in background and do not trust it at all, fuck yaah, I like Android when he stop this shitty apps. 99% of times I'll choose not run in background if I asked for it by your app.

It is really important to point out when cell manufacturers "improve" Android in a way that breaks apps. They are doing this for the improved battery stat. But if even a few users are dissuaded from buying their headset because it has a poor compatibility rating they will find better solutions. How about a bigger battery or one that can be exchanged? Or a more power efficient phone. Both are possible.

All I want is a way to protect certain apps from being closed, or at least be the last in line to be closed. That way I can make sure the 1-3 apps I always need are ready to go. And I'm not talking about some instantly loading alarm clock app. I'm talking about complex games or applications that take some time to initialize (Star Trek Timelines, for one).

Battery saving is needed for apps like WhatsApp. Even after doing a force kill to Whatsapp, a few seconds later, I see that it opened itself. I can't find a way to close WhatsApp and not have it open until I tell it to. The only option I could find (for a non rooted phone) is to use a VPN and route WhatsApp to a non existent address

Signal's support docs have instructions for various brands of phone. Really shouldn't be necessary

https://support.signal.org/hc/en-us/articles/360007318711-Tr...

If your app is in the background it shouldn't need a load of resources. These resource limits are there to prevent bad developers using all your resources in the background. If you are having issues with this limit you are probably one of these bad developers. Removing the limit is not the solution, writing a better app is.

So how do you propose to write a sleep tracking app that doesn't run a background process for longer than 20 minutes?

I have a Xiaomi and oneplus phone, neither of them have ever closed a background app so I dunno what you are talking about, but if phones are doing that then, yea fair enough thats a problem.

The wording in the linked website is talking more specifically about cpu limits, which is how most os manage background resources, whats the problem with that?

Sleep tracking is a good example you should use an event system, but developers are lazy and use "while (true) {}", which is my point.

Are fitness tracking apps able to run uninterrupted in your Xiaomi phone? Did you change any relevant settings?

In a way that it has to be explicitly allowed to do so by the user.

I don't need an online store app to eat up my phone's battery, and disabling background by default seems to be only option here.

That’s a solved problem on iOS. iOS itself keeps track of measurements coming from your device even when it’s sleep using the power efficient Mx chip. Applications can then - with user permissions - request the data when needed. This has been the case since 2013.

The app doesn’t need to be running in the background.

Sad that HTC, perhaps the vendor that's worst off on the list, seems to be the least bad actor besides stock Android.

You gotta love the developers' schizophrenia where on one hand we go batshit crazy over mass data collection by "malicious" apps, and on the other we fight with passion for the same apps to just run unmonitored in the background and collect. "You've got a smart phone but a dumb ass..."

Recently I limited the number of background processes on my phone(Galaxy S8) to two.

On one hand lag is essentially gone, on the other I usually have to "restart" an app(in the Android sense of the word) if I want it to regain focus. E.g. tabs in Chrome always refresh, which has its downsides.

I don't have any issue with applications dying unexpectedly or not receiving expected notifications on my OnePlus.

If anything, my gf's Galaxy is much worse in this respect. She doesn't usually get Hangouts notifications until she explicitly launches the app.

That's why I'm happy with Android One (which many Nokia phones come with these days).

Apparently the app that kills other apps comes installed on Nokias with Android One as well.

https://www.reddit.com/r/Nokia/comments/actk7z/android_one_p...

It’s there on my Nokia 7+ running Android 9.

Have you had any problems because of it?

This is a kind of "benchmark" optimization. Perceived battery life is a factor when users buy mobile phones. And all it takes is one bad app and one influent user - to kill an entire product, and even a whole brand.

I used Android for 9 years until I recently got the iPhone 10s. I'm never switching back. The only thing I miss is automated profiles using Tasker. Vertical integration and lack of SKUs has major advantages.

You need to do this:

https://hackernoon.com/notifications-in-android-are-horribly...

Compared to IOS, Android is very forgiving. That said, it also does a lot worse with battery life. As an Android dev it can be annoying to work around, but I appreciate why they have taken these steps!

android needs to stop being treated as garbage by google. take the reins, full control - monetarily fine OEMs who make their own garbage modifications to the underlying OS and actively harm the user experience. no timely updates? fine. garbage ux reported by vast majority of users? fine. basically re-implement nintendo's seal of approval for games but with the help of crowd-sourced reviews. we have the technology.

but no instead we'll probably get fuschia and android will be deprecated lmao

A lot of the issues are also caused by Google’s poor API design that is not well thought out causing app makers to have to roll their own solutions.

Google has no motivation to make sure that the ecosystem is good as long as they can sell ads and collect user data.

Device manufacturers favoring some apps by putting them on a whitelist to prevent them from being killed should be considered as unfair practice (potentially illegal).

Does this feature affect notifications?

More specifically, could this be the reason I've recently not received Discord notifications for DMs?

What I want to know is why years into its existence, Android still can't stop waking up the screen for no reason, with no notification displaying. Whatever app(s) is doing this can still keep doing it to this day, on my #2 poop OnePlus. So clearly it can't be that bad.

Lock em down. App developers are terrible and have no taste. Y'all had years to make these devices useful and failed. Instead it's all cloud idiocy.

Just please give me plain Linux ...

There is Sailfish OS (https://sailfishos.org/). It's a GNU/Linux and has true multitasking.

Yes, the problem is finding a good phone that supports it.

help my wifi driver isn't working on latest build of cyanogenmod /s

you may get linux on your hardware but goodluck getting hardware vendors to support linux even on a supposedly "linux compatible" device in any way

> Smartphones are turning back into dumbphones. We have to fight back!

Actually, it is not a bad thing.

No mention at all about foreground services. That should fix all these issues.

Some manufacturers don't even respect the foregrounding of services! Our app's Service runs in the foreground, and is sometimes killed by the OS, e.g. on Huawei devices. This issue affects spotify too:

https://community.spotify.com/t5/Android/Music-stops-play-af...

Is this why the alarm never went off reliably on my Android phone?

(iOS user now)

It might be. I never had an issue with this on my previous OnePlus phone (which at least at the time was pretty close to stock Android), but I was stumped to see that the Google Clock alarm was not going off multiple nights (seemingly at random) on my new Huawei phone. Turns out the phone was closing the app in the background due to it running for a long time... huh.

Switching the the built-in clock app (it's whitelisted, probably) fixed the issue, though it's not a good user experience. (To note: there is a settings screen to override per-app background closing behavior, but for an alarm clock I don't mind so much which app I end up using.)

It is pretty annoying still having the whitelist e.g. VPN apps manually whilst travelling as the phone was closing them constantly.

Interesting. Mine was a Motorola handset. I gave up with Android in the end due to stuff like this. I don't want to have to fight the tech I use to keep it doing what I want it to do.

App vendors, don't abuse background tasks.

App publishers, don't kill my battery!

Custom alarm clocks and health trackers work fine on my OnePlus. What is the problem exactly?

We are encountering tremendous problems with OnePlus while keeping up the Bluetooth connection in the background with our Heath Tracker. Seems it might be related to the situation described in the linked page by OP.

I had problems with synchronization between my OnePlus 3 and my Fitbit tracker (it'd work fine for an hour or a day and then just stop), but those problems went away when I upgraded to a OnePlus 6T. Regarding slack notifications and similar things, all I can say is that they sometimes appear a few seconds later than on my active desktop, but I don't find that delay to be a problem.

I had problems with my FitBit and other Bluetooth devices on my OP3 running stock firmware but these have all been resolved since I moved to LineageOS. Battery life seems better too (although I haven't explicitly measured).

Fuck your app, Android vendors, please kill background tracking and bullshit.

This is so true.

Google had better understand this kind of fragmentation is what makes their platform useless.

It's fine for vendors to do specific things, but it has to be very clear, documented, and within certain parameters.

Google has to realize that they are responsible for coordinating and publishing this information, and making sure it's clearly communicated to developers.

That they don't grasp this is byzantine.

There's a corollary in tech, relating to how many API's are released without proper documentation, thereby rendering all of the 'hard work' of making the software basically useless.

I should add: dealing with these kinds of problems are quite fundamentally different than other engineering challenges. For some reason, while working on this stuff, I can't help but feel frustrated and angry, mostly at Google (and the vendors) - because we're essentially 'solving their stupidity'. It's costing you money, and many small businesses don't have spare money and risk to hand out. It seriously strains developer relations and perpetuates an existential notion that developers have been 'lied to' by the platform vendors.

90% of the time you don't need to constantly run crap in the background scooping up my personal information, thanksno.

tl;dr The author would like to run his app in the background without notifying the user about it, because otherwise the author would just add add an ongoing notification, which would allow the app to run in the background forever on all platforms.

If this were the solution, I'd have to have a notification that I can't swipe away for email, Telegram, Wire, navigation while navigating, music player while playing, alarm clock when an alarm is set... So say I'm driving with music, that's five useless notifications. The app can ask me on first launch if I want it to do this or not, rather than being permanently in my face about it.

The notification area is becoming increasingly useless (for actual notifications). Since upgrading from 4.4 to 7.0 last year, this has been bugging me quite a bit and I haven't yet found a solution. I was much happier with the old OS, but security updates...

You can set the notification to "Hide" in the App properties screen. You don't have to swipe it away/close it.

But then it hides all notifications. I still want to know when I received a new email or message.

Again, Cyanogenmod based on Android 4.4 was better here: I could selectively hide notifications with certain contents. In Android 7, I can only choose not to display notifications from a certain app. I still have to write something that reads notifications and kill them selectively, but then I guess such a service would get killed as well without its own annoying notification... (The "you must update google play services to use this app" notification (which is a falsehood) is also annoying the crap out of me, another issue I didn't have on 4.4.)

I didn't actually know the wake lock would still work if you hide an app's notifications, I thought the notification was the prerequisite for not getting killed.

Not really no. It's more problematic, a good amount of vendors doesn't allow applications to run in the background and it's not a matter of notifications.

It's a big issue with IM apps like Conversations or calendars and contacts synchronisation apps like DAVx5

Some example: https://github.com/siacs/Conversations/issues/2771

I wouldn't necessarily ascribe anything shady here (which I got a bit of from your comment, if that was intended).

I found this helpful in debugging an issue I've had with my OnePlus - namely, many apps that I'd like to get notifications from abruptly stop getting them after a while, and I have to reopen them to get notifications. Today alone I had to manually open Facebook Messenger and Venmo in order to get notifications from them - this seriously degrades the functionality of those apps since opening Messenger multiple times a day still isn't apparently sufficient to exempt it from being "optimized".

There is much scope for abuse if things are relaxed, but all kinds of very serious use cases become somewhere in between “very difficult and/or unreliable” and “impossible” due to these techniques. For example: email clients, chat clients, calendars, even alarms sometimes.

The first affected things tend to be synchronisation jobs, but it’s distressingly common for these systems to break things so that notifications just mysteriously stop working outright—with no diagnostics of any form for user or developer.

Or how about emergency notifications? I live out in a rural area and it’s bushfire season; I want the VicEmergency app’s notifications pronto so that, if a threatening fire starts nearby I can get out quick.

Your TL;DR is wrong and it completely misses the core issue the website is describing. It's about OEMs breaking core Android API guarantees in cases where the OS (by documentation) allows you to run in the background for short bursts during so-called Doze maintenance interval.

I'm not sure this is the case, the website talks about propietary "battery savers", not about the standard Android one. I find it completely possible that they kill apps regardless of ongoing notifications.

I haven't followed the scene closely, but isn't it the same behavior as Apple? Can you even do background tasks in iOS?

> I haven't followed the scene closely, but isn't it the same behavior as Apple? Can you even do background tasks in iOS?

This is about OEMs breaking the guarantees of the OS. Yes, Apple restricts your background processing time, but it will still reliably deliver APNS push notifications or keep your running if it's actively providing turn-by-turn nav, background calls or something that API deliberately allows you to do.

With Android, the issue is that OEMs listed on that site break guarantees that Android API gives you. Your app suddently stops receiveing push notifications because it's not on the whitelisted "golden set" - breaking smaller messengers like Signal. Or the OEM "battery saver" kills off Google Maps while it's running turn-by-turn during your drive. Issues like that, which are significantly different than having Doze mode save your battery. Or you schedule a sync job once per day on Wifi (which JobScheduler API gives you the ability to do) and Huawei decides to just break the API and not run it.

As a developer, you are aware of the limitations so that you can work with them. E.g. when your app is closing down you have X ms to wrap your work up. But you can also request a longer task, or request the app to work in the background in certain scenarios. And as there is only 'one iOS', it will always work as 'agreed on'.

It seems like in Android the developer just assumes their app will be able to run in the background, except some versions just decides to kill it based on their own agendas.

> It seems like in Android the developer just assumes their app will be able to run in the background, except some versions just decides to kill it based on their own agendas.

That hasn't been true for some versions now. Yes, there's a mode where apps can run in the background without restrictions, but that hasn't been true for most apps for years now.

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://stackoverflow.com/questions/35388086/is-there-a-way-... And... well, it rarely allows apps that duplicate built-in functionality on the App Store. So most iOS users stick to default apps. But at least one app takes advantage of Apple allowing the microphone in the background to create a “smart” alarm clock which Apple has featured as the App of the Day: Sleep Cycle alarm clock http://www.sleepcycle.com

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.

In iOS, you have a few narrow cases where you're allowed to run in the background; some of which are specified to only maybe run.

In Android, you're technically allowed to run whenever you feel like it, but starting with Android 6, Google started limits, but I don't think apps get much feedback about when they might run, or if they can access the network when they do run. And the multitude of OEMs that are all dieing to make their product stick out means it's really a crapshoot; some oems were trying to do this before Google's release of the feature, some enable Google's version, but very aggressively, etc.

I understand the intent of these features, but there really needs to be a better way. Some apps do real, useful, work in the background, and it's not great for users when that can't happen. Many apps should probably only run when they're in the foreground. Either way, the app should be informed, so it can do the best it can, including informing users why it's not working and being able to direct users to where they can fix it, if desired.

> I understand the intent of these features, but there really needs to be a better way. Some apps do real, useful, work in the background, and it's not great for users when that can't happen. Many apps should probably only run when they're in the foreground. Either way, the app should be informed, so it can do the best it can, including informing users why it's not working and being able to direct users to where they can fix it, if desired.

This is why Android allows you to still run unrestricted if you show a persistent notification (as long as there's enough RAM). The whole point of the link you're commenting on is that some OEMs break this API.

Apple is actually more aggressive in terms of what's allowed in the background AFAIR.

But they have an arguably better push notification system which seems to use less battery and work better with sleeping apps.

The apps are not allowed to do background process. But can register a callback to be called when is in background. But there is no guarantee it will be called for sure.

For some cases, there is a 100% guarantee, especially for Bluetooth. I think we never lost a >sample< in the background so far (where I can't say the same for the Android).

You don’t need to, most of the time.

For example, push notifications are handled by one system process, and will only open the relevant app when the user clicks it.

I don't understand why manufacturers are trying to solve problem for user. User has power uninstall app that is draining battery or replace it with something else. There is rating and comment section in app store exactly for this. What they could do instead is to display warning that app is using too much battery, but they SHOULD NEVER KILL AN APP.

It may sound radical, but only countermeasure we developers have is to block installments of our apps on such devices until moment manufactures stop doing this nasty "optimizations". It's like taking users as hostages, but that exactly what manufacturers are doing as well.

PS: for all down voters, I would like to hear from you if you just android user or you've also developed some app (I doubt you did).

The user experience is more important than a app developer's need.

Users want better battery life. They don't want a app using it up.

Feel free to block the installation of your app on devices that you feel unfairly target background apps, they'll just use a different application.

>Feel free to block the installation of your app on devices that you feel unfairly target background apps, they'll just use a different application. reply

with some devices you just can't find alternative that would work reliably in the background for example. Imagine sport tracker, that needs to record locations even when in background. You cannot just use another app, because any sport app could get killed due excessive power management.

Favoring some apps by manufacturers putting them on a whitelist to prevent them from being killed should be considered as unfair practice (potentially illegal).

>Users want better battery life. They don't want a app using it up.

Everybody wants better battery life, but also their alarm app to wake them up, or tracking app to record their runs in the background, receive notification when there is new email or im message, etc. And these functionalities get disrupted by excessive battery management (killing apps in the background).

Somebody thinking he knows what users want and making decision based on this assumption (without really asking user) is exactly what brought us here. We are not all the same, somebody can have bit different priorities then you.

Reply on news.ycombinator.com