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.
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.
Im a bit confused on background limitations of apps, and I could use an explanation. So, starting from android 8 we have limitations on services and sending broadcasts. As for now, we can only make service run in background if it has the foreground notification, otherwise it will be killed. The app is considered to be in background if none of it's activities are visible, and my questions are: 1. For how long can the app-process itself live without foreground service? For instance, if I go to home screen, thereby putting app in background my app can still play sounds for hours, but I expected it will be killed by system in a couple of minutes. 2. Is foreground service somehow related to application lifecycle? For instance,maybe if I start the foreground service then my app won't get killed or less likely to be killed by the system.
I'm asking all this because my app is using c++ libs to make VOIP calls and do other stuff in background and I'm wondering what would happen if I just open the home screen and leave my app working, so far I've never seen the system kill the app while the call is active.
For how long can the app-process itself live without foreground service?
Android low memory killer daemon monitors the system constantly. If there is high memory pressure, least essential process gets killed. If there is not a memory problem, your app might live in the background for a long time. However vendors might limit the number of background processes. If this limit is 3 and your app falls to 4th place, it gets killed even if there is no memory pressure. And some vendors just kill the unvisible apps and there is nothing you can do about it. You can check this answer for a similar problem on OnePlus devices.
Is foreground service somehow related to application lifecycle? For instance,maybe if I start the foreground service then my app won't get killed or less likely to be killed by the system.
According to Android Processes and Application Lifecycle documentation foreground services have the 2nd highest priority in the system. So the answer is yes, if you are running a foreground service, your app is less likely to be killed even if you do not have a visible Activity.
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.
My application has got two services, ServiceA and ServiceB. ServiceA is a foreground service, ServiceB will be started when the device's screen is on and will be stopped when the device's screen is off.
These two services are collecting information, which we cannot afford to loose. But, on Android 4.4*, when the device's screen is turned off for a while and then turned back on, I can notice 0 processes and ServiceA running in the running section.
I've seen the reports on this version, where they claim that this scenario appears when the user swipes out our application from recent tasks. But, I'm noticing this when the screen is turned off for a while.
Note that ServiceA and ServiceB returns sticky and also, ServiceA is a foreground service.
Any definition will be very helpful.
As reference, this is on Android, and this is the Titanium Forum Post
I'm noticing this issue with several applications I've done with Appcelerator, all of them: no matter if they are simple apps or complex apps, but is more frequent in larger apps.
For example, I'm working on an application that needs to notify its location (GPS location) every 5 minutes. The application works perfectly when working in foreground, however, every time I put the app on the background (if I minimize the app by using the Home button) the application just crashes and all the services are stopped.
For notifying the application, here's the flow I'm using:
When I start the application, I start an Alarm, using the AlarmManager module.
This AlarmManager, adds a new Alarm Service, which will be triggered every 5 minutes.
Every 5 minutes, the AlarmManager starts the service and notifies the server with the current location.
This works great.
If I hit the "Home" button, the application just crashes (on the Application Manager) sometimes, but is more frequent when using other applications on the foreground while leaving this app on the background.
I thought this was because the main Activity was stopped, so I decided to maintain the main activity / task state by using android:alwaysRetainTaskState="true"
If I reopen the application, the application just restarts. This happens more on low-end devices than on high-end devices, which makes me think that this is a memory issue.
I have some questions:
Is this the expected behaviour?
If so, how can I mitigate this (maybe a native module/service?)?
Is my current flow the best flow for doing this or is there a better approach?
Any thoughts are more than appreciated.
For answering my own question: After a lot of tests, we saw that the problem was more frequent on older devices.
By reviewing the components, elements and doing an extense memory research, we discovered that this actually has to do on how Android manages Applications and the memory.
If OS decides your application is consuming too much memory on the background, it's able to remove it by any time. No matter if it's executing an Alarm or not.
With devices with more memory (newer devices), the problem just disappears.