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

201–210 of 414 posts

Re: Android vendors, don’t kill my app

#201

Post by simonh »

tinus_hn wrote: post #179
simonh wrote: post #95

Earlier quoted context omitted.

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

For some basic use cases, like notifications and downloads, there is a special system or api that allows your app to do that in the background without actually running. If you want to play audio or track gps in the background you need to do things yourself though.

OK, hence the Facebook issue where they played a silent audio track to keep their app active. I'd forgotten about that, thanks.

Re: Android vendors, don’t kill my app

#202

Post by mschuster91 »

morganvachon wrote: post #199
xyzal wrote: post #90

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

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.

Re: Android vendors, don’t kill my app

#203

Post by shimfish »

Ninn wrote: post #170
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?

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

Re: Android vendors, don’t kill my app

#204

Post by aasasd »

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…

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.

Re: Android vendors, don’t kill my app

#205

Post by bad_user »

sudhirj wrote: post #200
bad_user wrote: post #192

Earlier quoted context omitted.

>> " 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 (withou…

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

Re: Android vendors, don’t kill my app

#206

Post by alliecat »

bad_user wrote: post #192
sudhirj wrote: post #58

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

>> " 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 (withou…

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.

Re: Android vendors, don’t kill my app

#207

Post by dmitriid »

anc84 wrote: post #193
CodeWriter23 wrote: post #127

Earlier quoted context omitted.

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?

Slack receives messages with no problem.

If XMPP/IRC can’t provide that, it’s not iOS’ problem.

Re: Android vendors, don’t kill my app

#208

Post by sethammons »

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…

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

Re: Android vendors, don’t kill my app

#209

Post by masklinn »

Ninn wrote: post #170
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?

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.

Post reply on HN