If I spawn a thread via AsyncTask from the UI thread, is this thread killed when the UI thread terminates?
My AsyncTask (spawned fom UI) performs operations and then calls the Notification Manager as appropriate (part of my applications functionality). This works well, but notifications cease when the application exits, and I am assuming this is because the UI thread has terminated, therefore so do the children.
I did consider a service (assuming initially it would perform similar to a daemon) but then read that these run on the UI/main thread so would not be persistent across the UI thread termination.
My question really is how can I get the functionality of a daemon spawned from an Android app? I don't need permissions outside the spawning parent process, and it doesn't need to be persistent across reboots.
POSIX API'ish threads through the NDK or am I completely wrong?
Only spent a couple of days with Android so still trying to feel my way around. Many thanks!
Threads execute within a process. Android suspends (for later reuse) or kills an application's process when it's destroyed, which takes all threads with it. So the daemon would have to be a disconnected process, not a thread. Android is deliberately set up to prevent you from starting these (though sub-processes are straightforward with Runtime.exec() and its relatives). I think you can do what you want by fork/exec()'ing in the NDK, but the phone will have to be rooted to run the resulting app, which creates many problems. Not least is that warranty is often voided for a rooted phone.
If I spawn a thread via AsyncTask from the UI thread, is this thread killed when the UI thread terminates?
Not automatically and not immediately. The thread will run to completion, or until Android terminates the process, whichever comes first.
I did consider a service (assuming initially it would perform similar to a daemon) but then read that these run on the UI/main thread so would not be persistent across the UI thread termination.
Services are not really a "daemon" in classic Linux sense. A service is automatically in the background from a UI standpoint. It is not automatically in the background from a threading standpoint. Any work the service does that will take some time should be done on a background thread. The difference is that with a service running, Android will not be as prone to terminate your process quite as quickly.
My question really is how can I get the functionality of a daemon spawned from an Android app?
That depends on what features of a "daemon" you are trying to obtain, which you neglected to describe in your question.
POSIX API'ish threads through the NDK
That will do you no good. Your threads will still be terminated when your process terminates.
I had to implement almost the same functionality: firing notifications form background.
It's rather simple: start a service and spawn a new thread from within the service.
There are many scenario's where Android platform offers some uot-of-the-box goodies where you do not ecessarily have to start threads yourself.
For example:
if your thread should just wait for something you can schedule periodic 'wake up' events with AlarmManager which will take care of running in background
or if you need to synchronize data in background with back-end you can use SyncAdapter API which also takes care of running in background.
As CommonsWare just suggested:
That depends on what features of a "daemon" you are trying to obtain, which you neglected to describe in your question.
Related
If I remove the app from the background/recent app list, the UI thread also stops so that system can reclaim the memory associated with the UI. Now consider a case where a PeriodicWorkRequest is triggered which in turn starts a worker (after the app is removed from the background/recent apps list). The worker implicitly runs on a separate background thread and is performing the assigned tasks. But is the UI/Main thread also created along with the worker thread?
An app can exist with no activity. It can have other components like services etc with no UI. In this case, does the UI/Main thread still exist?
Or in any other scenario, can a process exist with no UI/Main thread, just a worker thread?
In android things get complicated really fast.
Android is a fragmented ecosystem and some OEM perform some device alterations that result in different behaviors across devices for example when you close an app instead of doing a grace shutdown it does a kill to provide an immediate effect. even background workers are not very guaranteed, read some more here
Background workers are you best bet.
In this question: Android: AsyncTask vs Service, someone answered
Service is a daemon, AsynkTask is background thread
and someone replied to that answer with:
A service is not a daemon as it doesn't have its own thread of execution.
QUESTION: Since both operate with threads and work in the background, other than the lifespan of each, what are the key differences between Asynctasks and Daemon processes?
I have not met anywhere term Daemon together with Services or AsyncTask. To me Daemon threads are the ones from java which allow JVM to finish even with unfinished Threads. In terms of Android you have no control over your App process - you at most might kill it.
Android service is a Component - this places it near to Activity component. What does it mean? It is managed by system - it has its lifetime during which life cycle methods are being called. Service can be configured to be recreated, or you can make it a foreground (this way system will be less likely to kill it). Since it is a Component you can configure it to be run under separate process. It does not have its own thread of execution by default - it runs on UI thread.
Now AsyncTask is entirely different thing, it is not a Component, so you cannot do anything from above. One thing it has is a background worker thread. Actually AsyncTask is a wrapper around Exeuctors thread pool with some lifecycle methods - like onPreExecute,onPostExecute,... It should not be compared to services, but rather to Loaders.
According to : http://www.linux.org/threads/android-services-and-daemons.7143/
Service:
A "Service" is special software that runs in the background like a
daemon on GNU/Linux. Services doesn't have GUIs. A "started service"
runs in the background until it completes its task, crashes, or is
explicitly closed by the user or application. A "bound service"
persists until no more apps are attached or bound to the service.
AsyncTasks:
AsyncTasks are designed for once-off time-consuming tasks that cannot
be run of the UI thread. A common example is fetching/processing data
when a button is pressed.
Daemon:
A "daemon" is a process that runs in the background *without owning a GUI. Services are usually daemons, and daemons are typically considered services. However, the exact difference between services and daemons is blurred. In general, they can be considered the same entity. However, some people use “daemon” to refer to a piece of software and “service” to refer to the actions and APIs offered by a daemon.
I was going through Bound Service in Android Developer website. I thought I understood the service enough but I just found another way of connecting service through Using a Messenger class especially for local service. There I got confused. Maybe I got the concept wrong.
Here is my understanding of Android Service. You create a service when
You want to do separate jobs in the background.
You want to make it a separate process.
You want to make it run in a lifecycle that's independent of the component that started it.
Confusion is the first item in the list, the definition of the background. Isn't the background a thread or process? I never thought that it can run on the main thread.
Here is the caution of service in the dev pages about.
Caution: A service runs in the main thread of its hosting process—the service does not create its own thread and does not run in a separate process (unless you specify otherwise). This means that, if your service is going to do any CPU intensive work or blocking operations (such as MP3 playback or networking), you should create a new thread within the service to do that work. By using a separate thread, you will reduce the risk of Application Not Responding (ANR) errors and the application's main thread can remain dedicated to user interaction with your activities.
Questions
Why does one choose to use service if the service function will anyway run on the main thread?
Do we have to write a service only to block ANR even if the time-consuming job is done in the main thread? Assume the service is only for my application.
Are there any practical cases or reasons to use a service as private and running in the same thread?
Application main thread is not always the UI thread. For example, when Activity is stopped, the onStop() is invoked, hence the UI thread is taken away from that Activity and moved to another Activity within the same or a different application. However it doesn't mean the application is no longer active, it can continue working in the background until it is closed either by OS or by user. Then who keeps it running in the background? It is the main thread and not the UI thread.
What are services
In Android, a Service is an application component that can perform
long-running operations in the background on the UI thread. By
background, it means that it doesn’t have a user interface. A Service
runs on the main thread of the calling Component’s process by default
(and hence can degrade responsiveness and cause ANRs), hence you
should create a new Thread to perform long running operations. A
Service can also be made to run in a completely different process.
Unlike Activity components, Services do not have any graphical
interfaces. Also Broadcast Receivers are for receiving broadcast
messages (broadcast, multicast, unicast) and perform short tasks
whereas Services are meant to do lengthy processing like streaming
music, network transactions, file I/O, interact with databases, etc.
When a Service is started by an application component like an Activity
it runs in the background and keeps running even if the user switches
to another application or the starting component is itself destroyed
Why use service
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).
Use IntentService if you don't want to fiddle with managing threads on your own. Otherwise, use AsyncTasks.
Please read this excellent article to understand more in detail and also read this answer.
Service basically runs in UI thread or main thread.But,if we are going to perform long running operations in service,we need to create a background thread and perform that task.
But why we have to use service?
Now let's think of Music Application.We need songs to be played continuously even if we leave music app.If we use activities,we can't achieve above requirement.So,service helps in these kind of scenarios.Even if the app is not in foreground, service keeps on running and we are able to listen to songs.This is why we use service even though it runs on main thread.
In short, Services runs on the background of the UI thread.
You can perform tasks like client-server authentication or write to a database where the tasks are done in the background with no graphical interface.
But if you're doing a really long processing tasks that could freeze the interface, you use a service on a separate thread.
eg of a Service on a separate thread is IntentService
Why android UI runs on main thread and not on other threads?
Why is it only dedicated to UI ?
(Some will say its runs services as well, but i dont buy that.
If that were to happen services will end when application exits, since main thread gets killed with process. According to me it runs in OS space( like windows services, i am guessing))
Why cant i change UI from other threads as well? (NOT posting work on UI thread)
Is it the hardware constraint or what ? Why is it designed this way ?
Why cant i change UI from other threads as well?
Android was designed around the mobile CPUs of 2005-2007, which were about 2% of the power of today's CPUs. The synchronization overhead of trying to allow multiple threads to manipulate the UI was deemed to be too high. They used a common approach in those cases: designating a special thread to be the one for UI updates, and failing updates that are attempted on other threads.
Some will say its runs services as well
In general, objects do not run on threads -- methods run on threads.
Lifecycle methods on all Android components are called on the main application thread. So, for a Service, onCreate(), onStartCommand(), onBind(), and onDestroy() are called on the main application thread.
If that were to happen services will end when application exits
Applications in Android do not "exit".
since main thread gets killed with process
When a process terminates, all components in it also "get killed", and so a service that was in that process will go away.
I am confused with android services and java thread.
Please help me to understand in which scenario i should use them.
As per my understanding
Service run in background ,so do thread.
Service is to be used for activities like network operation or playing mp3 in background,so do threads.
So whats actual difference between them and when to use each of them.
Let me give an analogy.
Activities and Service are like projects.
Activities are like external projects. This is what the clients(users) see.
Services are like internal projects. There might be several internal projects for 1 external project or none at all.
You can "pause" external project but the internal project that supports it can still continue.
Main Thread is like the boss in a company
The boss should never be held up by too much work since he shouldn't be late to meetings (UI freezing) or the client(user) will be unhappy.
Threads are like employees in a company.
The more you have, the more things you can do at the same time provided you have enough equipment(CPU speed) for all of them.
Multiple employees can work on the same project at the same time but the boss should really work only on the Activities.
Always: A service of your application is usable not only by other components of your application, but by other applications, too.
A service is for use in not-GUI parts of program.
Mostly: A service is something more independent, than a thread. Service is something more long-living than a thread. Service is something more complex than a thread.
BTW, threads do not run in background only. What runs in foreground, is a thread, too.
I believe the main difference is about Android system attitude. Service is a part of android infrastructure, so android recognizes service as a working part of application and considers killing service as a last option. Moreover, if your service is killed (e.g. because of memory lack) you can say system to restart it automatically, whenever resources available again. Moreover, you can tune up service priority in order to do it as important as foreground activity. As for threads, android does not recognize a thread as important part which must be kept. So usual threads has much more chances to be killed eventually.
For instance If you have an activity which start a working thread and then go background, as android do not recognize thread as a working part, it may think that application do nothing, because no activity or service running and kill the whole app, including the working thread.
Thus when you start a Service, you are telling system something like: "Hi. I'm doing some business here, don't kill me until I finish, please." and Android pay attention to your request.
Services are more analogous to a headless Activity.
The the important piece to understand is that a Service is about managing application lifetime and the ability to keep work running when your Application is not in the foreground (no UI visible). It is also about providing the ability to expose functionality to other apps.
http://developer.android.com/reference/android/app/Service.html#WhatIsAService
Typically when starting a Service you will also start a worker Thread. There are settings in the manifest that can cause a Service to be started in a new Process but generally you do not need to do this, it makes communication with your service more difficult.
Use a just Thread in your Activity when you need to offload work from the UI thread while the application is in the foreground, but this work can stop when you are no longer in the foreground. (It is possible that your app will continue to run when not it foreground but there is no guarantee depending on a number of factors) Generally speaking Android is free to kill your Activity if it is not in the foreground, and if your App process has no Activities or Services it can be killed.
Use a Service with a Thread to do work that will take place while your app is in the background and you want better guarantee about the lifetime.
Use a Service to expose non-UI functionality to other applications.
Android Service don't run in a separate process (by default) and even don't run in a separate thread! It runs in the main thread(UI thread) of the application, therefore if you would like to do something time consuming task in the Service start a separate thread yourself, or use IntentService.
As per Android Developer Guide (http://developer.android.com/guide/components/services.html#Basics) :
A service is simply a component that can run in the background even when the user is not interacting with your application. Thus, you should create a service only if that is what you need.
If you need to perform work outside your main thread, but only while the user is interacting with your application, then you should probably instead create a new thread and not a service. For example, if you want to play some music, but only while your activity is running, you might create a thread in onCreate(), start running it in onStart(), then stop it in onStop(). Also consider using AsyncTask or HandlerThread, instead of the traditional Thread class. See the Processes and Threading document for more information about threads.
Remember that if you do use a service, it still runs in your application's main thread by default, so you should still create a new thread within the service if it performs intensive or blocking operations.
Why we need service is to avoid resource crunch.
For example you opening an application after opening an another application so at the time your app added to the background task.
While opening multiple application, ur app may killed by android system. So if ur app has service it won't be killed by the system because service is higher priority , even it may killed the app has service so that we using constant return type in onStartCommand(). Method. That's START_STICKY,START_NOT_STICKY and DELIVER_INTENT.