The WireGuard and tailscale apps work great for me without a persistent notification.
WireGuard doesn’t support notifications at all.
Tailscale does and by default it shows a persistent notification but you can just silence it or turn it off in the apps notification settings.
Persistent notification thus seems to be unnecessary for VPNs to function, Google/Android dev documentation recommends a persistent notification for the UX but it’s not needed.
https://developer.android.com/guide/topics/connectivity/vpn
In conclusion it appears that third party apps can indeed provide a VPN service without a notification.
Unfortunately, that will mean your app can be killed on many smartphones from device makers like xiaomi, Oppo, and huawei, which have aggressive battery optimization. I had this issue on a redmi device where background apps would be killed unless a permanent notification was present.
The WireGuard and tailscale apps work great for me without a persistent notification.
I haven’t tried wireguard. But, I should give them a try and see how it goes in samsung.
The ranking may make it sound like samsung is the worst. But that’s not been the case since android 12. I do not have app reload or app killing issues on this one and find it much better than what I used to experience on miui.
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).
I was under the impression that the “Disable battery optimisations” feature was to prevent exactly this. Maybe I misunderstood what it does, but a bunch of apps designed to run in the background tell you to disable this functionality for their app for this very reason.
That is for applications that need access to a LOCAL_SERVICE while not in foreground. That’s like Geolocation or screen orientation. VPN is not one of those. You can kill the foreground application from the recent apps by sliding up.
No real VPN app needs to have an application window and a background service (same thread) running to provide a VPN. If it does, it is doing something else not related to VPN.
If you want to add a pause button, applications can add custom tiles.
The WireGuard and tailscale apps work great for me without a persistent notification.
WireGuard doesn’t support notifications at all. Tailscale does and by default it shows a persistent notification but you can just silence it or turn it off in the apps notification settings.
Persistent notification thus seems to be unnecessary for VPNs to function, Google/Android dev documentation recommends a persistent notification for the UX but it’s not needed. https://developer.android.com/guide/topics/connectivity/vpn
In conclusion it appears that third party apps can indeed provide a VPN service without a notification.
Unfortunately, that will mean your app can be killed on many smartphones from device makers like xiaomi, Oppo, and huawei, which have aggressive battery optimization. I had this issue on a redmi device where background apps would be killed unless a permanent notification was present.
I haven’t tried wireguard. But, I should give them a try and see how it goes in samsung.
Ah, I have a pixel which apparently is pretty nice on the not killing your app side
https://dontkillmyapp.com/google
The ranking may make it sound like samsung is the worst. But that’s not been the case since android 12. I do not have app reload or app killing issues on this one and find it much better than what I used to experience on miui.
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).
Clicking on Samsung makes it sound like it’s still a problem on Android 13 at least.
I’m glad it works for you at least, I have never used a Samsung phone so I might be fixed altogether but idk.
You could if you want, add an issue or something on their GitHub
I do not feel too strongly about it, so I will refrain. But, if I find the time and energy to spend, I may open an issue later.
deleted by creator
I was under the impression that the “Disable battery optimisations” feature was to prevent exactly this. Maybe I misunderstood what it does, but a bunch of apps designed to run in the background tell you to disable this functionality for their app for this very reason.
Some phone’s battery optimization goes beyond the native Android stuff, so even with that step, apps without a notification may get killed.
I see! Fun…
WireGuard works fine on my samsung
That is for applications that need access to a LOCAL_SERVICE while not in foreground. That’s like Geolocation or screen orientation. VPN is not one of those. You can kill the foreground application from the recent apps by sliding up.
No real VPN app needs to have an application window and a background service (same thread) running to provide a VPN. If it does, it is doing something else not related to VPN.
If you want to add a pause button, applications can add custom tiles.