Android Os. Is there a way to start Location Manager in background Thread with WorkManager(ex)?
WorkManager is for background work that's deferrable and requires guaranteed execution:
Deferrable means that the work is not required to run immediately. For example, sending analytical data to the server or syncing the database in the background is work that can be deferred.
Guaranteed execution means that the task will run even if the app exits or the device restarts
You should check this list and see what fits for your needs. I would recommend you start your Location Manager with a Foreground Service
Related
Android documentation does not clearly tells about what and how a work manager runs a work.
1. Does Work Manager start the application class so that initialization for some classes can be done or i have to manually initialize them in my Worker class.
2. Does It run on application process or it runs on another process?
3. Periodic work is not running if my application is killed. Why is that?
It store the jobs in a local database and tells the OS to run them using JobScheduler or gcmNetworkManger or AlarmManger depending on the API.
The OS wakes the app when the constraints are met to run the scheduled job.
Yes! if the user choice to force stop the app, the OS deletes all the scheduled job and the WorkManger won't be able to reschedule them until you open the app.
I have an application with background service (important tasks run in background always).
What is your offer for handle important tasks?
my application may be close but these tasks must be done.
If your service is doing important task and the application mustn't be close you should use Foreground Service as it will inform the user that you're doing some work.
If you don't need immediate execution you can use WorkManager. WorkManager offers deferrable but guaranteed execution, it'll run even if you're application is killed.
In my app, the user can start a background process that makes long running API calls to the backend. The user will also have the ability to pause the background thread and resume at any point.
If the app restarts, the background process should resume from where it left off. Once the background process has completed, the process should terminate.
Even when the background process is running, if the user hits the device's home button, I still want the background process to keep running. It is not necessary for any UI to be shown while it is running.
Reading up on the Android docs, it would seem that using WorkManager is probably the best choice since my minSdkVersion is 19. Is this true?
The process can run for hours
WorkManager work cannot run that long. You could still use WorkManager for the scheduling aspect, but then the "work" would need to be starting a foreground service, where the service then does the actual network I/O.
It is not necessary for any UI to be shown while it is running.
On Android 8.0+, you cannot have something running for hours without UI showing, at least in the form of a Notification associated with a foreground service.
I have been reading lately about how background jobs are done in Android (using Service, AlarmManager, JobScheduler, etc) and learned that these background task can go indefinitely even the app has already closed or device has screened off. I understand that the only they stop if they stop themselves or other components stop them.
Questions:
If I have a background job or an alarm that goes every 1 hour. Does it really runs forever until a component stop them? Is there an instance that the system will stop them?
What if I have periodic job or alarm that goes every 1 hour. Will they stop if I uninstall the app that started them? Cos I never read this part in any documentation.
Is there a way to check any running or pending background jobs/alarms in my device?
The explanation that is given about background tasks in your question only applies to Background Services, that to only in Android API Levels below 26.
Google recommends using JobScheduler or Foreground Service to do some work in background even when app is not in foreground.
Coming to you questions
No, If your using JobScheduler or Alarm manager the system will trigger your job to do your work depending on device idleness and conditions mentioned by you but the system can anytime come and stop your work in between when the conditions are no longer met.
If your are using JobScheduler it will inform you when system wants to stop by force so that you can handle it properly and reschedule if needed
When the App is uninstalled every job or alarm that is scheduled or in-Progress will be destroyed.
Yes, JobScheduler does provide a function 'getAllPendingJobs'
Note :
For works that should be scheduled or completed even when app is closed then try avoiding the use of Background Services or Alarm Managers.
JobScheduler is much more better replacement.
If you want to do some simple background work when the app is in foreground then try using HandlerThreads or AsyncTasks
I have read many posts state that doze mode killed a running service at a particular moment e.x link or that they want to execute a long running thread.
I can't understand why you should use a service to do a background job that you know that in some point it will stop eventually.
For instance:
You could use a simple Thread:
new Thread(new Runnable).start()
and do some work in it. Using this:
In combination with a wake lock, device wont sleep and thread will keep running.
No doze mode restriction (except network but lets say we do local stuff)
So you can do background work with no restriction whatsoever. Although you should use services for these reasons link.
Is this another way (not better of course but a way nonetheless) of doing a background work? Am I wrong?
There are a lot of ways to do a background job aside of services check this link it may help you pick the best option for your work :
Job Scheduler vs Background Service
And services as #TheWanderer said will continue to work event after the app is closed for a period of time unlike a simple thread that will end immediately when the app is closed.
Read this part in the link that you linked
Services are given higher priority than other Background processes and
hence it’s less likely that Android will terminate it. Although it can
be configured to restart once there is ample resources available
again. You should go through the different processes and their
priority/important level in the documentation on processes and
threads. Assigning them the same priority as foreground activities is
definitely possible in which case it’ll need to have a visible
notification active (generally used for Services playing music).
If you are running a background thread that you start from an Activity, Android does not know that you are doing background work in the OS Process that is hosting your Activity. Android can kill the OS Process hosting your Activity at pretty much any time. If the user presses the HOME button or takes a phone call or opens a notification and goes to another application, Android can kill off the OS Process at any time. When the user returns to your application, Android will create a new OS Process and recreate all the relevant activities, but your background thread is hopelessly lost. This is the reason that Android has services.
If you start a Service to perform your background processing, the Service will also start background threads, but these are controlled. Your Service tells Android what to do if it kills the Service while it is processing an Intent. Your Service can therefore be informed and restart (or continue) the background processing as necessary. You can also run the Service in a different OS Process from the OS Process running your activities. This will prevent Android from killing the Service if the user removes your app from the list of recent tasks.
With newer Android SDKs there are other mechanisms you can use, like JobScheduler.