I am working on an application related to Voip & IM (chatting application). Till android OS 5.0 it is working good and no issues from client also. But from android OS 5.1.1 onwards we are facing issues.
Issues:
If the app is in foreground and if device goes to sleep mode it is working good.
If the app is in background and if device goes to sleep mode after 10 minutes all the services are stopping automatically.
Testing:
For testing I created one timer task to print logs for every 1 minute. So when I close the application (means if the app is in background)
Till android OS 5.0 logs are printing continuously.
From android OS 5.1.1 onwards after going to sleep mode, after 10 minutes logs are not printing. Timer task is stopping
Same problem I am facing for my application also.
After doing some R&D I came to know regarding doze mode and app optimization. Is it anyhow related to stop services automatically running in background.
If yes, can anyone please let me know how to overcome this issue.
This is new thing which google done to prevent unwanted battery usage.
For new versions the background services are restricted for better battery life. The android service consumes almost same as the application running in foreground. So even though app is not running its services may be running and using memory and battery.
If you have to use any kind of background process try to use Job Scheduler which may be something useful for you.
The Job Scheduler groups the task and execute the background task based on the constraints we provide in the implementation.
This have a limitation it support on minimum API 21
To support on lower version you can use Firebase JobDispatcher which support from API 9.
I personally prefer Firebase JobDispatcher
This link help you to understand more about scheduler and its implementation.
Related
I wrote a periodic worker that runs just fine when the app is at the front or in the background (recents) but when I clean it from the recents it does not run anymore.
I have heard people saying requests should run even when the app is killed, but I've also seen cases where developers of famous applications had to write a Service instead just because of similar complaints from users.
My WorkManager library version is androidx.work:work-runtime:2.4.0.
I tested on both a physical Android 10 Xiaomi device and a Android 10 Nexus 5X API 29 (x86_64) device.
I know that Xiaomi's MIUI has battery optimizations that might interfere and I even tried with the Autostart setting set for the app to no avail, but why would it happen on a fresh AVD image then ?
"WorkManager is intended for work that is deferrable—that is, not required to run immediately—and required to run reliably even if the app exits or the device restarts."
That being said the Android system can instruct your app to stop the WorkRequest for a number of different reasons. Ex. A WorkRequest will be stopped if it exceeds the execution deadline by 10 minutes.
Work manager of course can run if the phone is runing and the app is in the background.
But what if I killed the APP, or switch off the screen of the phone? What is it affect to the WorkManager?
Yes. That's the reason why WorkManager has been designed.
Even if your device off and have a periodic work request, the system will take care of you worker once the device has been restarted.
This is well tested by the Android team, no need to test it.
However, there are 2 scenarios when the Worker doesn't get triggered:
Low memory, Android forces stop your app.
You force stop the app on your own.
For both scenarios, in order for the WorkManager to be started you need to re-launch the closed app.
Take a look at the docs for more: https://developer.android.com/topic/libraries/architecture/workmanager
In my current application for a company Im having a ForegroundService that is running while the workers are on duty (logged in to the app).
It is important to keep that foreground service running while users are logged in. To recover from cases where this foreground service gets killed somehow (User task swipe accidently or System kill) ive implemented a periodic JOB with Jobscheduler which reactivates the ForegroundService in case it gets shut down. This technique works well pre Android 8 OREO. START_STICKY and other techniques alone did not do the trick for me.
In Android 8, as soon as the foreground service gets killed, the periodic job gets killed as well. Im getting the notification in logcat that the job is not allowed to run. To my understanding, Jobs schould be able to run even when app is in background or killed. And its working on pre OREO devices the way it should.
To my knowledge, I can fix that by enable the option "autostart" in app settings. But since there is no way to know if employees tunred that on, its not a reliable thing as well.
So my questions:
- Why does the Job scheduler stops working as it should in Android 8?
- Are there any other reliable techniques I could use to let my ForegroundService recover from shutdowns in ANDROID OREO?
Ive read https://medium.com/exploring-android/exploring-background-execution-limits-on-android-oreo-ab384762a66c but that did not answer my questions
Thank you very much
did you try to put
.setPersisted(true)
Note: Requires the RECEIVE_BOOT_COMPLETED permission.
you can also see this question.
Job Scheduler not running on Android N
reading some references:
1- The services in andreo oreo if posses a buggle oreo will kill it for energy loss in 7 is a warning but in 8 applies more strict
2 - The jobs scheduler has a time of 15 minutes and avaces is not executed in the precise time debit that they look for the precise moment to execute the event without that the battery of the cellular one is descaste
I recommend that you use this library that provides evernote that is very good and very specific:
https://github.com/evernote/android-job
My app has a background service running that gets users current location and update it to a server every five minutes. To run this location update process continuously, I use alarm manager to set its next execution time from the service itself. However, when I install the app in my Nokia 6 running Android 8.1 it works for some time and if I keep the phone idle for some time, my service will get killed with the next alarms by the application also being cleared from system alarm manager. My guess was that the idle time makes the phone enter doze mode. However, I don't understand why the alarm managers got cleared. To my understanding, the doze mode should open up maintenance windows periodically to execute any pending tasks.
To mitigate this issue, I tried to apply a JobScheduler service on top of AlarmManager, which runs every 15 minutes. Purpose of this jobscheduler was to re-start the service which has the alarmmanager in it, so even if it gets killed and the alarm is cleared, jobscheduler would re-up the service.
After I tested this patch and keeping it for some time to go into idle mode, it resulted in getting both JobScheduler Service and Service which has the alarm in it killed with the scheduled jobs and alarms getting cleared from the system.
It is said in the Android documentation that we can use JobScheduler to mitigate its background execution limitations. And to test this out I forced killed the two services when I tested the app, but the already scheduled job did not get cleared, and it made the service with the alarm run again successfully. I don't understand the reason for this behavior, although the Evernote guys give an explanation that could match this scenario in here Android Job by Evernote
Any ideas for this abnormal behavior?
Test Environment Details
Device : Nokia 6 (TA-1021)
OS : Android 8.1.0
You would not be able to run background services long running in Oreo as there are behaviour changes, now Oreo to optimise system memory, battery etc, it kills background service, to solve your issue you should use foreground service.
Have a look at Background execution limits https://developer.android.com/about/versions/oreo/android-8.0-changes
A suggestion from me, if you can use FCM then go for it, becasue apps like WeChat, Facebook uses it, to deliver notifications and they don't face any problem...
Hope this helps in understanding the issue....
In Doze more, the alarms do not get reset, but get deferred to a later time. You have two mainstream options here:
Use either setAndAllowWhileIdle() or setExactAndAllowWhileIdle(). However, these too can fire at the maximum frequency of 1 time per 9 minutes. So you'll have to decrease the frequency at which you get location in your app.
Use a foreground service by way of showing a foreground notification. Everyone does that (apps like Uber, Google Maps etc). That way, your service won't get killed, and be treated as though you have an app open.
I'm currently facing the same issue and doing the same workaraound like you do. That is, setting the Jobscheduler to a periodic job to launch my Foreground Service every 15 min in case it is getting killed for whatever reasons like a killed task. This works like a charm on pre Oreo Versions.
For Oreo the only solution I am awared of at the moment is, to allow the app to autostart in the settings. Under installed apps that is. Then it should work like pre Oreo again.
What Ive heard but not tested yet, is to set the setPersisted(true) option in the Job Scheduler.
Let me know if that helps
I assumed currently DOZE mode not allowed to background service so you need to find a way that DOZE mode will not affect on your app.To solve your issue you should use foreground service. or make some battery setting. Any way my better option is you should go with Firebase Cloud Messaging
I'm developing Android app with background service. Service is running in its own process (like com.example.app:extProccess). Service creating WebSockets connection. But after less than 1 min after service started there is a disconnection on WebSockets, but service is alive (not killed by Android). After 20-30 min a connection is recovering.
Seem like device entered in Doze, but very soon.
This is observed only on some Nougat devices.
If I prevent battery optimization (android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS) for this app service and websockets working correctly without disconnects.
My question is why Android limits network so quickly if my app in foreground? So how to hold networking for background service in this case without using android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS?
Starting from Android API 21(Lollipop), Google started giving more focus on battery optimisations. The problem comes is any service. One way to overcome this is to use Job Schedulers for your background tasks(documentation available here). Also, any task that uses android resources a lot will be terminated by the Android Framework. The only solution for your particular use case is to either optimise your code or use "IGNORE BATTERY OPTIMISATIONS" as done by you.