I have a Sticky Service and i'm stress testing the app by filling the phone's RAM. Once the RAM is full, the service is destroyed. Since it's a sticky service, it gets restarted automatically when the system has enough resources.
But this happens only on stock android devices like Moto/Nexus. Devices like Xiaomi or Lava do not restart the sticky service, even on 5.1
Is anyone aware of such problems with heavily customized ROMs? Any workarounds to schedule a restart of my service when the memory gets low?
All stock android devices like works well because they use AOSP ROM's
These devices(HUAWEI,LAVA,XIAOMI) are shipped with pre-installed start managers or energy savers (most of the Huawei devices). If the app is not configured appropriately the services will be killed several seconds/minutes after the screen turns off - or it will not automatically be started after reboot.
Now with the feature called Protected Apps, I tried enabling in my app and still the sticky service is not getting started post the App Kill.
also, furher observation is:-- The HUAWEI device does not even hold a foreground service
Now the possible workaround is:--
We can use Alarm Manager class to make sure that the service is
running when it's necessary. So this Alarm manager can be used to
create a timer which checks from time to time if the service should be
running and restart it. This time interval needs to be set considering
the possible impact on battery consumption.
Related
I have a few questions about certain behavior on Android devices.
I'm using SDK which ask the user to turn-off battery optimization for the app.
I'm also running a foreground service which implements some interfaces from said SDK.
I need the foreground service to run as long as possible with out any other interaction with the app.
What I wanted to know is:
If the user allows to turn off the battery optimization - does it mean that the OS can't kill my foreground service (or it will be killed under some strict conditions).
If the user doesn't allow to turn off the battery optimization - does it mean that the OS will kill my service more easily?
If under some conditions the OS kills my service, the foreground service is also dead, will the service come back to life if I made it START_STICKY and if so, how long does it take it to restart?
Each manufacturer implements Android in a different way, so a specific behaviour seen on (as example) Samsung could not be the same on Xiaomi, and vice-versa. Battery optimization could not involve Services in the way you expect, or maybe yes. It's impossibile to find a fixed rule for this.
(same as 1)
the restart is near-instant, it takes just the time to empty memory, release locks/files and similar things and finally run an "internal startService()" method again.
I'm using a Background Service as the main purpose in my App (it creates some floating windows/interfaces when needed) and I never seen that the OS killed my Service in more than 6 years. However the Service should support to be killed and restarted without FC something.
I have written an VPN using android's VPNService and it works perfectly. When I run it, it creates a foreground service and sends all traffic through my VPN server. It also has an internal reconnecting mechanism to reconnects VPN server if it disconnects for any reason without stopping service itself.
I like to have this VPN service working all the time. But my problem is that this VPN service is stopped occasionally after a completely random period(sometime it takes just 10 minutes, but other times it works for 2-3 days before stopping).
Since the stopping time is completely random and I cannot find any place in code that creates this situation (I have been debugging for weeks), I thought maybe android OS itself stops my VPNService for some reason. I wonder if there is a way to detect if system has stopped my service from outside or not. Any idea?
Unfortunately, Android OS still can terminate the service in low memory and possibly other situations, even if it's a background running service !
It is not only Android, but all Mobile Operating Systems optimize RAM usage by killing background apps.
This is done so that the foreground app can be given top priority. It ensures smooth functioning of the current app and reduces load on the system.
There's are two approaches as mentioned in this post: Background Service getting killed in android
If you are implementing the service, override onStartCommand() and
return START_STICKY as the result. It will tell the system that even
if it will want to kill your service due to low memory, it should
re-create it as soon as memory will be back to normal.
If you are not sure 1st approach will work - you'll have to use
AlarmManager
http://developer.android.com/reference/android/app/AlarmManager.html
. That is a system service, which will execute actions when you'll
tell, for example periodically. That will ensure that if your service
will be terminated, or even the whole process will die(for example
with force close) - it will be 100% restarted by AlarmManager.
I had this issue previously and I've solved it by creating the service running forever even if it's killed manually or from the system it recreates itself.
My Android app activity binds to a service, which connects to a BLE peripheral and receives data. It does this until the user presses a button on the activity to disconnect from the peripheral and stop the service.
Sometimes after running with the screen locked for about ~45 minutes+ the activity and service are terminated. My conclusion was that Android 8.1 was more aggressive than previous operating systems, so I changed the background service to a foreground service, and made sure that once the peripheral is connected I stop scanning.
This didn't work, and every now and then my app is killed in the background, and I don't think it is an uncaught exception. I have read the Android docs on Services and the Application Lifecycle and have added some debugging logs into lifecycle callbacks, which hasn't helped. I have observed this behaviour on Huawei Y5 and Nokia 8 running Android 8.1 - I don't remember it being an issue on an older phone which I no longer have.
I have a few questions about behaviour that aren't clearly documented that might help me figure out this issue. Thanks for your help!
1. If an activity is killed in the background and it is bound to a service, will that kill the service?
2. If a service is killed in the background, will that kill my activity
3. If there are multiple services running and one consumes too many resources, does the OS kill everything, or just the misbehaving service?
4. What sort of things makes an activity or service a target for the OS? Holding on to wakelocks permanently? BLE scanning? Receiving too many BLE packets? Uploading too much data? Any insight here about what might be happening under the hood is appreciated.
5. Does having the phone on charge prevent the OS from killing apps? I believe it occurs in my case regardless.
There are several reasons for Android to kill.your activity. Therefore it is not a good idea to setup you bluetooth in an activity. Set it up in a seperate class or in your Application class and use other ways to send data to your activity, e.g. broadcasting. That way it will keep working even if your Activity is killed or recreated.
Is your application really being killed or is it just your Activiry that is killed?
So I've made an Android video-calling app that tries to be available in the background so that the user may receive calls when the screen is off. I've noticed however that the app would be paused when the device went to sleep.
The solution I've found that worked was to rewrite everything to a service and then request a wakelock so the service wouldn't be paused during sleep.
Surely, since there are so many of these types of apps, there is a more elegant way to do this? A periodic check wouldn't work since you would want to take the call in real-time.
It depends on the Android version, for version older than 6 a partial wakelock is enough to keep the device awake, for Android 6 you also need a foreground service, that's a Service that calls startForeground() and shows a notification, but to keep the device awake has a big impact in battery usage.
You do not necessarily need to transfer all the code to the Service due it is the whole application that stays awake.
A more elegant solution to replace all this would probably be to use Push Notifications, it is what most messaging applications use. Firebase has Push Notifications.
I'm trying to keep a Service alive beyond the Activity lifetime.
On two phones (Samsung Galaxy S6 and Sony Xperia Z3 Compact) starting an activity in a different process than the Activity then swipe remove the app while Service is visible and notification is shown keeps the service alive.
On a third phone, Huawei Honor 8 the exact same code destroys the Service and cancels any alarms scheduled immediately.
I've had alarms scheduled every 10 seconds (they get cancelled at once on Huawei and works on Samsung/Sony). And having a LocationListener active while running the service in the background.
Another difference is that priority MAX and ongoing notifications on working phones are not cancellable by swiping them away or clearing, but that too is possible on Huawei.
I've requested ignore battery optimization and other settings without any difference. I've also tried looking for an option to not kill the app while the screen is off, which Huawei seem to do at once too.
What can be done about this scenario to keep the service running after the activity is killed or just not actively running. If on low memory, the activity goes but never the service since it hardly consumes any memory. But with this settings, the service gets killed instantly.
Am I looking at specific manufacture settings that I possible can't predict or control from code?
The only possible solution I can see for this type of problem is to send silent pushes to the system checking if the service is alive very frequently and then restarting it when it should be active (due to user choosing to do so but system killing it anyhow).
For Huawei Devices there is an issue that you can swipe away the ongoing notifications from the Notification panel. This is registered as an issue as it should not behave like that and has been fixed and would be working fine on the new updates .
Regarding the Service getting killed when you close the task from RecentsActivity, its because Huawei has a System app called HwSystemManager(PhoneManager) which does this task. If you go in PhoneManager and under protected Apps, enable your APP as Protected APP, then it will not kill your services and your App may be alive in the background for a long period of time until and unless there is a Low memory situation.