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

Android vendors, don’t kill my app

dontkillmyapp.com

Post reply on HN
Print view View original

161–170 of 414 posts

Re: Android vendors, don’t kill my app

#161

Post by ecocentrik »

Wintamute wrote: post #136
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…

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.

Re: Android vendors, don’t kill my app

#162

Post by finchisko »

whouweling wrote: post #126

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

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

Re: Android vendors, don’t kill my app

#163

Post by majewsky »

kijin wrote: post #42

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…

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.

Re: Android vendors, don’t kill my app

#164

Post by whouweling »

scarface74 wrote: post #143
whouweling wrote: post #126

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

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?

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

Re: Android vendors, don’t kill my app

#165

Post by scarface74 »

kkarakk wrote: post #89

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

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.

Re: Android vendors, don’t kill my app

#166

Post by EamonnMR »

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.

Re: Android vendors, don’t kill my app

#167

Post by Plasmoid2000ad »

salex89 wrote: post #18

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…

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.

Re: Android vendors, don’t kill my app

#168

Post by mcny »

izacus wrote: post #40
xyproto wrote: post #24

Earlier quoted context omitted.

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

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

I blame it on stock Android. Phone manufacturers probably don't want to spend money on OS changes but Android doesn't do the right thing by default so they have to make changes.

The right thing to do is to deny apps launching at startup, apps running in background, and apps getting network access. Let the user say yes or no. Your use case for signal is different from mine. Maybe I just want to see messages when I open the app?

But yeah I agree, the user should be in control.

Re: Android vendors, don’t kill my app

#169

Post by GeneralTspoon »

scarface74 wrote: post #145
GeneralTspoon wrote: post #54

Earlier quoted context omitted.

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…

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.

Re: Android vendors, don’t kill my app

#170

Post by Ninn »

adrianhon wrote: post #148

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

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?

Post reply on HN