Android vendors, don’t kill my app • Hacker News Board

Re: Android vendors, don’t kill my app

#271

Post by sergiosgc » Mon, Jan 14, 2019, 3:40 PM UTC

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.

Re: Android vendors, don’t kill my app

#272

Post by WrtCdEvrydy » Mon, Jan 14, 2019, 3:40 PM UTC

colejohnson66 wrote: post #251

richardwhiuk wrote: post #151

Earlier quoted context omitted.

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?

'Performance'

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

Re: Android vendors, don’t kill my app

#273

Post by TruthSHIFT » Mon, Jan 14, 2019, 3:44 PM UTC

sergiosgc wrote: post #271

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…

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

Re: Android vendors, don’t kill my app

#274

Post by morganvachon » Mon, Jan 14, 2019, 3:45 PM UTC

mschuster91 wrote: post #202

morganvachon wrote: post #199

Earlier quoted context omitted.

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 fe…

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

Re: Android vendors, don’t kill my app

#275

Post by marcodave » Mon, Jan 14, 2019, 3:48 PM UTC

arendtio wrote: post #173

yason wrote: post #129

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

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…

> 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

Re: Android vendors, don’t kill my app

#276

Post by sonnyblarney » Mon, Jan 14, 2019, 3:49 PM UTC

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.

Re: Android vendors, don’t kill my app

#277

Post by njsubedi » Mon, Jan 14, 2019, 3:57 PM UTC

TruthSHIFT wrote: post #273

sergiosgc wrote: post #271

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…

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

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.

Re: Android vendors, don’t kill my app

#278

Post by daveFNbuck » Mon, Jan 14, 2019, 3:58 PM UTC

dtech wrote: post #67

daveFNbuck wrote: post #20

Earlier quoted context omitted.

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

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

I want the notification functionality, I just don't need it to be instant.

Re: Android vendors, don’t kill my app

#279

Post by daveFNbuck » Mon, Jan 14, 2019, 4:00 PM UTC

scarejunba wrote: post #23

daveFNbuck wrote: post #20

Earlier quoted context omitted.

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

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.

I want all the notifications. This was a question about timing. I don't want them to do the constant polling required for the notifications to appear instantly.

Re: Android vendors, don’t kill my app

#280

Post by jsjohnst » Mon, Jan 14, 2019, 4:02 PM UTC

feikname wrote: post #252

JustSomeNobody wrote: post #245

Earlier quoted context omitted.

Getting messages should not/does not have anything to do with running in the background.

Receiving messages (aka "listening" in server jargon) is essentially a background task, constantly probing to check for any changes.

I think the point being made is that’s a terrible use of resources, not only are you keeping the app running, but you are also forcing the power hungry LTE radio to stay on more.

This idea that the end device should do all the work is not a sustainable approach. There should be a server side component that is handling this for you and sending push notifications when your app needs to wake up for new data.