Comment by whouweling | Hacker News Reader

Comment by whouweling | Hacker News Reader

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?

Yes, and these manufacturer optimizations often break them.

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?

Probably a crude way to stop apps from waking themselves every minute.

'Performance'

Edit: It's become the new '911'... Family Guy Joke!

>WHY?

Because China.

Having lived in China for a few months with an Android phone I can with absolute certainty tell you that this is needed over there. The amount of garbage apps, even from big companies like baidu is enourmous!

And without a Google playstore, or play services, or play safety thing it is an absolute wild-west of background alarms, API calls, battery draining and whatnot.

Sorry, how does rounding to the nearest minute or nearest TEN minutes solve any problems?

Like are apps setting alarms for every 3 seconds or something for no reason??

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

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

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

Both.

Limits the potential battery impact.

Without this restriction, how long before an app maker schedules their alarm every millisecond?

Rounding timers can greatly increase battery life, at the expense of apps not working - but who checks that apps work on their phone before buying it?

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

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

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

Reply on news.ycombinator.com