6 ms·

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 imp

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.

Ninn 8y ago
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?
- shimfish 8y ago
  Whether this is possible or not is deeply missing the point as well as showing a vital misunderstanding about UX.
  - reificator 8y ago
    > 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.
  - EpicEng 8y ago
    >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.
  - shimfish 8y ago
    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.
- masklinn 8y ago
  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.
  - lukevp 8y ago
    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.
    - dorfsmay 8y ago
      How do you differentiate an apps crash from an OS forceful kill? Both would show a last good status and no good exit.
      - ehnto 8y ago
        Presumably you would have an error log in the crash circumstance, unless it was very seriously broken.
      - jessaustin 8y ago
        You can detect which model of phone the app is running on, right? On these problematic models you should probably just assume that the app got killed in that circumstance.
        masklinn 8y ago
        Yes, but that's not a detection or even an inference, it's a loose assumption.
- me551ah 8y ago
  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
  - Izkata 8y ago
    That sounds way over-complicated. Why not just keep a flag in the database that's updated during the Activity lifecycle?
    - me551ah 8y ago
      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.
      - Izkata 8y ago
        If all you need is to detect it on the next boot to notify the user, as the prior comment said, then for example: onCreate - check "running" flag, then set to true onDestroy - set flag to "ended" If onCreate saw the flag was already "running" before it was set, then you have a crash to recover from or a kill to notify the user about.
- hernan604 8y ago
  Have an app priority defined by user
masklinn 8y ago
> 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.
Abishek_Muthian 8y ago
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!
aasasd 8y ago
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.
- noxToken 8y ago
  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.
  - Nullabillity 8y ago
    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.
me551ah 8y ago
>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-broken-b8dbec63f48a https://hackernoon.com/notifications-in-android-are-horribly...
NicoJuicy 8y ago
Seems like battery management has the traditional firewall problems. Eg. Blocking legit services and obscure errors popping up. Ps. Love zombies run
troyvit 8y ago
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.

Ninn 8y ago

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?

shimfish 8y ago
Whether this is possible or not is deeply missing the point as well as showing a vital misunderstanding about UX.
- reificator 8y ago
  > 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.
- EpicEng 8y ago
  >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.
- shimfish 8y ago
  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.
masklinn 8y ago
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.
- lukevp 8y ago
  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.
  - dorfsmay 8y ago
    How do you differentiate an apps crash from an OS forceful kill? Both would show a last good status and no good exit.
    - ehnto 8y ago
      Presumably you would have an error log in the crash circumstance, unless it was very seriously broken.
    - jessaustin 8y ago
      You can detect which model of phone the app is running on, right? On these problematic models you should probably just assume that the app got killed in that circumstance.
      - masklinn 8y ago
        Yes, but that's not a detection or even an inference, it's a loose assumption.
me551ah 8y ago
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
- Izkata 8y ago
  That sounds way over-complicated. Why not just keep a flag in the database that's updated during the Activity lifecycle?
  - me551ah 8y ago
    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.
    - Izkata 8y ago
      If all you need is to detect it on the next boot to notify the user, as the prior comment said, then for example: onCreate - check "running" flag, then set to true onDestroy - set flag to "ended" If onCreate saw the flag was already "running" before it was set, then you have a crash to recover from or a kill to notify the user about.
hernan604 8y ago
Have an app priority defined by user

masklinn 8y ago

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

Abishek_Muthian 8y ago

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!

aasasd 8y ago

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.

noxToken 8y ago
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.
- Nullabillity 8y ago
  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.

me551ah 8y ago

>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-broken-b8dbec63f48a https://hackernoon.com/notifications-in-android-are-horribly...

NicoJuicy 8y ago

Seems like battery management has the traditional firewall problems. Eg. Blocking legit services and obscure errors popping up. Ps. Love zombies run

troyvit 8y ago

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.