I published an app on the play store that purely relies on a persistent notification + wakelocks to keep the screen active (since the whole point of the app is to keep the screen awake) - Samsung was definitely the worst when it comes to this for my app, as I would receive endless support emails about people with Samsung devices where it would get killed, even when disabling battery optimization for my app. The other manufacturers listed there came up every now and then, but disabling battery optimization generally did the trick for them.
With there being nothing that I could do for my app, I tried disabling compatibility in the play store for a ton of Samsung models, but then I got even more emails about people wondering why it wasn’t available anymore so I re-enabled it, but to this day there’s still (AFAIK) zero things I can do to prevent the app from getting killed on those devices.
It’s called “Caffeinate” (I’m avoiding posting the direct link just so I don’t break any self promotion rules), I made it in the Android 7 days when the quick settings Tile API came out to replicate the similar tile that was available in CyanogenMod. It ended up getting way more downloads than I ever expected honestly - I just wanted to try the new API haha.
I know that Caffeinate itself doesn’t use up a lot of RAM (the only thing it does when its active is create a persistent notification and creates a wakelock in order to keep the screen active), but perhaps the lower end Samsung device models just have less RAM available, so opening a browser or such kills it.
I tried your caffeinate app. The last time I checked, it was using 32mb while running. Currently, using 11mb. Android says it uses an average of 143kb with a maximum of 7.8mb for the whole day.
It has been installed for the past 3 days, and I try it once a day from the drop-down tile. It hasn’t been killed or reloaded yet.
I have 6GB of ram with 6GB of ram plus enabled. I guess its low ram and cpu usage make it never likely to be booted off ram. Those users who complain must be using Samsung devices on older oneui and / or low ram like 3GB or 4GB.
Well I definitely am glad to hear that! Yeah the situation is just unfortunate, as there’s really nothing I can do for the users who are getting the issue - since as you’ve seen, Caffeinate is already really light on RAM usage (which would normally be one of the only ways to try to remedy the issue as a developer, from what I can tell).
In the end I just decided to keep it compatible for all mobile devices, though I did consider adding a “compatibility warning” type of banner to the app or a one-time notification for devices that had a small amount of RAM. Eventually the emails stopped coming in about it though so I figured either the problem ended up resolving itself as updates to the platform occurred, or everyone who was going to run into the issue already ran into the issue. I’ve pretty much considered the app to be feature complete now, short of any Android changes that break it (such as when notification channels was introduced, followed by full-on notification runtime permission requirements).
You said the app is feature complete. But, if you find the time and energy to spend. You can probably try to add a dark theme that utilizes the “follow system” theme setting. And later if desired material you theming support. Otherwise, it does the job and is good as far as it can go.
Hey, I read the top review of a samsung user. Even in my own testing, the app doesn’t appear to extend the screen timeout on samsung. It locks out after the default timeout.
Interesting, sounds like they’re killing the wakelock that Caffeinate acquires then (which is what actually keeps the screen active), rather than killing the whole app itself.
That’s another one of those issues that I don’t think there’s too many workarounds for. Theoretically I might be able to have the app check to see if the wakelock is still active and if not, re-acquire it… but if there’s no way for the app to “know” that the wakelock has been killed in the first place, the only way around it would be to constantly ask Android “Is the wakelock still active? Is the wakelock still active? Is the wakelock still active?” over and over again, which would definitely lead to battery issues.
I do know it works on some Samsung devices, as I bought an old A2… something to test it on, and couldn’t find any signs of a problem there.
I mean hell, I’d love for there to be a way to not even require a wakelock for Caffeinate, but the only other way is a “soft” wakelock, in which you tell Android “Never turn the screen off while my app’s window is open”, but of course that would mean you’d need to keep the actual app window in the foreground and would defeat the whole purpose (such as my favorite usecase, keeping the screen on while I’m reading a recipe - or keeping the screen on while I’m tracking a delivery from a food delivery application).
I published an app on the play store that purely relies on a persistent notification + wakelocks to keep the screen active (since the whole point of the app is to keep the screen awake) - Samsung was definitely the worst when it comes to this for my app, as I would receive endless support emails about people with Samsung devices where it would get killed, even when disabling battery optimization for my app. The other manufacturers listed there came up every now and then, but disabling battery optimization generally did the trick for them.
With there being nothing that I could do for my app, I tried disabling compatibility in the play store for a ton of Samsung models, but then I got even more emails about people wondering why it wasn’t available anymore so I re-enabled it, but to this day there’s still (AFAIK) zero things I can do to prevent the app from getting killed on those devices.
What app is that? I only notice app reload issues when I max my ram usage playing heavy games or running apps that require maximum ram.
It’s called “Caffeinate” (I’m avoiding posting the direct link just so I don’t break any self promotion rules), I made it in the Android 7 days when the quick settings Tile API came out to replicate the similar tile that was available in CyanogenMod. It ended up getting way more downloads than I ever expected honestly - I just wanted to try the new API haha.
I know that Caffeinate itself doesn’t use up a lot of RAM (the only thing it does when its active is create a persistent notification and creates a wakelock in order to keep the screen active), but perhaps the lower end Samsung device models just have less RAM available, so opening a browser or such kills it.
I tried your caffeinate app. The last time I checked, it was using 32mb while running. Currently, using 11mb. Android says it uses an average of 143kb with a maximum of 7.8mb for the whole day.
It has been installed for the past 3 days, and I try it once a day from the drop-down tile. It hasn’t been killed or reloaded yet.
I have 6GB of ram with 6GB of ram plus enabled. I guess its low ram and cpu usage make it never likely to be booted off ram. Those users who complain must be using Samsung devices on older oneui and / or low ram like 3GB or 4GB.
Well I definitely am glad to hear that! Yeah the situation is just unfortunate, as there’s really nothing I can do for the users who are getting the issue - since as you’ve seen, Caffeinate is already really light on RAM usage (which would normally be one of the only ways to try to remedy the issue as a developer, from what I can tell).
In the end I just decided to keep it compatible for all mobile devices, though I did consider adding a “compatibility warning” type of banner to the app or a one-time notification for devices that had a small amount of RAM. Eventually the emails stopped coming in about it though so I figured either the problem ended up resolving itself as updates to the platform occurred, or everyone who was going to run into the issue already ran into the issue. I’ve pretty much considered the app to be feature complete now, short of any Android changes that break it (such as when notification channels was introduced, followed by full-on notification runtime permission requirements).
You said the app is feature complete. But, if you find the time and energy to spend. You can probably try to add a dark theme that utilizes the “follow system” theme setting. And later if desired material you theming support. Otherwise, it does the job and is good as far as it can go.
Dark theming is definitely a fair point, I’ll definitely need to have a look into that.
Material You support is probably going to be out of scope though, as I feel that would be making it complex for the sake of being complex.
I do want to learn more about the Material You API that being said.
Hey, I read the top review of a samsung user. Even in my own testing, the app doesn’t appear to extend the screen timeout on samsung. It locks out after the default timeout.
Interesting, sounds like they’re killing the wakelock that Caffeinate acquires then (which is what actually keeps the screen active), rather than killing the whole app itself.
That’s another one of those issues that I don’t think there’s too many workarounds for. Theoretically I might be able to have the app check to see if the wakelock is still active and if not, re-acquire it… but if there’s no way for the app to “know” that the wakelock has been killed in the first place, the only way around it would be to constantly ask Android “Is the wakelock still active? Is the wakelock still active? Is the wakelock still active?” over and over again, which would definitely lead to battery issues.
I do know it works on some Samsung devices, as I bought an old A2… something to test it on, and couldn’t find any signs of a problem there.
I mean hell, I’d love for there to be a way to not even require a wakelock for Caffeinate, but the only other way is a “soft” wakelock, in which you tell Android “Never turn the screen off while my app’s window is open”, but of course that would mean you’d need to keep the actual app window in the foreground and would defeat the whole purpose (such as my favorite usecase, keeping the screen on while I’m reading a recipe - or keeping the screen on while I’m tracking a delivery from a food delivery application).