I'm a bit confused about the difference between a task and a process in Android.
If I understand correctly a task is just a stack of activities. From what I read so far I think a task could look like this:
| Activity A running in Process P1 |
| Activity B running in Process P2 |
| Activity C running in Process P3 |
So basically activities from different processes can be contained in the same stack. Am I correct?
Another question: What is the real meaning of "application context"? The process or the task?
And final question: The application class (which is basically a singleton) represents the process or the task?
Everything I've ever learned about it, I've learned on this page.
Edit: I also just stumbled upon Activity and Task Design Guidelines. It looks to cover the exact topic you asked about. I learned a lot :)
So basically activities from different
processes can be contained in the same
stack. Am I correct?
Based on my understanding, you are correct. My grasp is that Processes are the units of actual execution while Tasks are about association to get things done. As an example from the aforementioned page, if you create an intent that opens a webpage, the Activity that it creates is created on the web browsers process but is associated with your applications Task. A task, therefore, becomes a virtual stack of Activities running on different processes depending on the application that provided the Activity.
Another question: What is the real
meaning of "application context"? The
process or the task?
This is a good question. Based on reading the page above, my understanding is that an Applications context is associated with the process. I'm basing that on the interpretation of this line from that page, but there may be other info:
Normally, a new instance of an
activity is launched into the process
of the application that defined it, so
all instances of the activity run in
the same process
And final question: The application
class (which is basically a singleton)
represents the process or the task?
With the same interpretation as above, my guess as to why an Application object represents a Singleton is because all of your applications activities get run on a single process and that process is tied to the Application. I don't know that this is a design point, but it appears to be, at the least, a consequence of the current design.
Edit: There are some caveats to this. It appears that your application can be spread across multiple processes so, my guess is that the Application Object and context act as a mechanism for tethering all the processes together. I'm pretty sure your mental model already allowed for this, assuming the processes were from different applications, so its only a small difference to allow it inside a single process.
The manifest element has the attribute android:process with the description as follows:
The name of the
process in which the activity should
run. Normally, all components of an
application run in the default process
created for the application. It has
the same name as the application
package. The element's
process attribute can set a different
default for all components. But each
component can override the default,
allowing you to spread your
application across multiple processes.
If the name assigned to this attribute
begins with a colon (':'), a new
process, private to the application,
is created when it's needed and the
activity runs in that process. If the
process name begins with a lowercase
character, the activity will run in a
global process of that name, provided
that it has permission to do so. This
allows components in different
applications to share a process,
reducing resource usage.
Process:
When an application component starts and the application does not have any other components running, the Android system starts a new Linux process for the application with a single thread of execution. By default, all components of the same application run in the same process and thread (called the "main" thread).Every application runs in its own process and all components of the application run in that process, by default.
for detail process: http://developer.android.com/guide/components/processes-and-threads.html
Tasks:
A task is a collection of activities that users interact with when performing a certain job. The activities are arranged in a stack (the "back stack"), in the order in which each activity is opened.
An activity can even start activities that exist in other applications on the device. For example, if your application wants to send an email, you can define an intent to perform a "send" action and include some data, such as an email address and a message. An activity from another application that declares itself to handle this kind of intent then opens. In this case, the intent is to send an email, so an email application's "compose" activity starts (if multiple activities support the same intent, then the system lets the user select which one to use). When the email is sent, your activity resumes and it seems as if the email activity was part of your application. Even though the activities may be from different applications, Android maintains this seamless user experience by keeping both activities in the same task.
for detail task-http://developer.android.com/guide/components/tasks-and-back-stack.html
An important note from Android Developer :
A common misunderstanding about Android multitasking is the difference
between a process and an application. In Android these are not tightly
coupled entities: applications may seem present to the user without an
actual process currently running the app; multiple applications may
share processes, or one application may make use of multiple processes
depending on its needs; the process(es) of an application may be kept
around by Android even when that application is not actively doing
something.
Related
What is the difference between all the above?
I found various posts which were helpful but also quite confusing. According to my understanding in short this is what I came upto:
Threads are tasks that share same resources
Processes are tasks which have independent rersources. A process can
have multiple threads.
Tasks are the instructions being executed
Now this is where I get confused. How is an activity related to all
these three in android. Activity can have multiple tasks so it must be something like a process. But then what is the difference between activity and process. Moreover I read somewhere that tasks are stack of activities. It got me all confused. Ive also read that all activities run on UI thread which just make the distinction a little more confusing.
You should differentiate between Processes & Threads vs. Activities vs. Task. They aren't even really in the same category.
Let's start with the simplest one, Task's. Assuming you are not talking abouy any actual class, i.e. TimerTask, the basic concept of a Task is the following.
When a user starts your app for the first time, a new Tasks is created. You can see this by pressing the "OverviewButton", represented by a Square for the software buttons. (on Android 5.0 an higher)
A Task will not get disposed of, unless the User actually removes(swipes left/right) it from the Overview screen.
So a Task is really just a high-level abstraction for the user.
Like you alluded to, a Tasks has an Activity backstack, which is just a normal stack that is used to keep track of the "history" for the user. For example, your App is launched, your MainActivity will be at the bottom of the stack, the User enters some values and then goes on to a new Activity. Now this new Activity is above the previous one, and the user can press the "back button" at -hopefully- any time to get back to the previous activity.
Now for Processes &Thread's, a Processes under Android is very similar to a linux process, your app will usually only be working within one single process. A process gets assigned a certain part of the memory by the OS, if you're familiar with languages like C, attempting to acess memory that does not belong to your process wil cause a
"segmentation fault".
Like you said, a process may have any number of Threads, assuming the OS can manage the required Overhead.
A process will at least have one Thread, under android this is called Main-Thread or UI-Thread. Threads, very basically, allow you to do some work in parallel. You will most likely need to make use of them, for example when performing network operations.
Now for Activities, they have no direct relationship to multithreading. The currently "active Activity" is the one that is run on the UI-Thread. So all of its callbacks will be run on the UI-Thread, unless specifically documented not to.
An Activity is an abstraction used by the android framework, it exists at a fundamentally different level than a Processes & Thread's. You can call a method defined in a Activity, from any Thread you want.
A really nice question, from my little experience with android development, I'd like to contribute. Let's start from..
Processes
Ever opened task manager on windows to see open apps? Those are processes. On android, when an app is launched, a new process is opened and allocation of memory etc is given.
The activity classes,imports and threads all make a process in the Android system. sometimes you see an error message when an app crashes "unfortunately com.android.bakerapp has stopped."
This means an error causes the whole process of threads, imports, activities to close. So basically processes are parts of an app or an app in general that's running.
Activity
An activity is the heart and soul of all android apps, all Threads, preferences, views and layouts are opened by android activity class. It is the container object that holds views, passes information around and runs threads too. Activities communicate with each other through intents, objects in the class extends and methods.
Activity is the piece of code that creates and communicates UI and everything a user sees and uses. It is used to create threads. Which is discussed below.
Threads
This one is easy, a thread is basically a process to get something done, it lives and dies after its work. Imagine you have an activity with a view of picture on the screen and you want to automatically set your apps theme color to the most common color on the picture using a library.
The best method to do this without the user knowing and also confusing the main thread responsible for loading the picture into a view from a website is to open a thread using an Asynchronous task (something that runs in background) is an example of a thread.
So a thread is basically a life cycle of a task to be done, it can be continuous (Main activity views and list views) or short (Find a dominant color in a picture) or fun and multitasking (downloading a picture from a group chat while at thesame time chatting with your girlfriend on WhatsApp).
Threads are the most essential part of all activities and processes and can send,receive and process data.
Activities cannot work without threads because the setContentview and UI itself is just another thread, you can have multiple threads in one activity.
Happy coding!
https://developer.android.com/guide/components/processes-and-threads.html
I know this is old, but you can also say that a thread is the smallest unit of execution of code. Threads are scheduled to run on the CPU. A process can have one or more threads.
I am trying to understand conceptually what a task is in Android. So is it correct that a task can have multiple activities and can run one activity at a time? But is a task like a unix process? And each activity can be thought of as a thread within the process? Looking to clarify my somewhat weak understanding.
A task, unlike a Unix process, is basically an UI concept.
From the documentation - Tasks and Back Stacks
A task is a collection of activities that users interact with when
performing a certain job. The activities are arranged in a stack (the
"back stack"), in the order in which each activity is opened.
The activities that make up a task can belong to different applications (and hence, to different processes). That's why inter-activity communication in Android is done via Intents (basically, messaging objects than can be serialized) and not via direct method calls -- even when the called activity is part of the same application as the caller.
A user can switch freely between tasks (with the "Recents" button) but cannot move arbitrarily between the activities that make up a task. Normally they can only go one step back, via the "Back" button.
You should take a look at the documentation -- it's quite well explained there.
An Android application maps to a Unix process (more or less, since an app can run more than one process if it so desires) . But there is not a one-to-one mapping with tasks -- a task can contain activities from multiple applications, and a single application can have activities in multiple tasks.
I have read the following statements here
By default, all components of the same application run in the same process and most applications should not change this. However, if one needs to control which process a certain component belongs to, he can do so in the manifest file. The manifest entry for each type of component element—<activity>, <service>, <receiver>, and <provider>—supports an android:process attribute that can specify a process in which that component should run. One can set this attribute so that each component runs in its own process or so that some components share a process while others do not.
I want to know in which scenarios a developer would like to do so and run different components in different processes and what advantage will he get by doing so?
Another statement that I have read is
The <application> element in the manifest file also supports an android:process attribute, to set a default value that applies to all components
Regarding the above statement I want to know Why would a developer do that, there is already one process associated with one application by default and all the components run inside that process.
Can anyone clarify these things for me as I am not getting any details on this anywhere else
thanks
Let us take the example of Google Chrome browser which has made best use of android:process attribute. Before that let us understand why multi-process architecture was considered.
Remember those age old days, when we were using co-operative multi-tasking operating system. There was one single process and applications used to run in that single process turn by turn. Problem with that architecture was, if one application misbehaves that single process dies off there by bringing entire system down.
Now a days modern operation system, run applications in their own processes. If one application misbehaves, the process hosting it dies off and does not affect rest of the system.
Same applies to the browser. If one web-page misbehaves, it brings down the entire browser there by making web-pages opened in other tabs unavailable. Hence multi-process architecture was built.
Separate processes are used for browser tabs to protect the browser application from bugs in the rendering engine. Each render process is run as an android service in separate process. This is done by using android:process tag of <service> element. Another important flag used for rendering engine process is android:isolateProcess. This flag ensures render process does not have access to the system resources like network, display and file system, there by making the browser application highly secure.
Here is the snippet of chrome's manifest file:
<service android:name="org.chromium.content.app.SandboxedProcessService0" android:permission="com.google.android.apps.chrome.permission.CHILD_SERVICE" android:exported="false" android:process=":sandboxed_process0" android:isolatedProcess="true" />
Here is the output of adb shell:
USER PID PPID VSIZE RSS WCHAN PC NAME
u0_a14 12926 317 694380 102828 ffffffff 00000000 S com.android.chrome
u0_i16 26875 317 590860 59012 ffffffff 00000000 S com.android.chrome:sandboxed_process5
u0_i17 27004 317 577460 47644 ffffffff 00000000 S com.android.chrome:sandboxed_process6
The element in the manifest file also supports an
android:process attribute, to set a default value that applies to all
components
By default the name of the application process will be the package name specified in <manifest> tag. This can be overridden by specifying the name in the android:process attribute of the <application> tag. One use case : if multiple applications want to run in the same process, provided those applications are signed by same certificate and share the user ID.
If the name of <android:process> starts with :, it becomes private to that application, as in case of chrome's rendering engine (com.android.chrome:sandboxed_process5). It implies applications except com.android.chrome cannot communicate with this rendering engine.
If the name of <android:process> starts with lowercase character, it becomes global process. From docs:
This allows components in different applications to share a process,
reducing resource usage.
Summary of benefits:
To improve overall application stability (crashes / hangs). One service process crash does not bring down entire application.
Security by preventing access to the rest of the system.
Reduce resource usage, by running component in a process and sharing it among different applications.
Basically you should be able to separate the concerns and decide whether it makes sense to apply multi-process architecture.
Update 1: Adding #Budius comment
Each process have only a certain amount of memory available. In the app I work at, we do computational intensive processing in large memory arrays. Those computational we always fire in a separate process to make sure we'll have enough memory for the whole thing to happen and not crash with OutOfMemory.
The reason one might want to do this is because Android can shut down your application process to free up memory in the system any time it wants to, and you may want to mitigate the situation.
Suppose you have a really, really important piece of code that takes a long while to complete that would be very bad to kill in the middle of it working (for instance, a financial transaction in bank software). Putting this piece of code in a Service that runs in a separate process from the rest of the application code will ensure Android doesn't kill your Service that is potentially still running after the user exited your application.
From the docs:
When deciding which processes to kill, the Android system weighs their
relative importance to the user. For example, it more readily shuts
down a process hosting activities that are no longer visible on
screen, compared to a process hosting visible activities. The decision
whether to terminate a process, therefore, depends on the state of the
components running in that process.
You can read more here
In general, a Service is used when you expect a non-UI task to take a fairly long time to complete. An Activity that does not remain in the foreground can in all probability be terminated by the OS, while a Service can continue to run indefinitely.
A Service is created in a separate process when you don't want the garbage collector to affect its working. The garbage collector will, in that case, affect only the application process. Moreover, a Service in a separate process has the added advantage that it will consume slightly less memory than what it would if it were in the main application process.
The Service that you declare in a separate process can be either private to the application:
<service android:process=":my_private_process"
or it can be global:
<service android:process="my_global_process"
In the latter case there is no colon prefix. A Service in a private process can only interact with your application, while a Service in a public process can deal with other applications as well. This is mainly when a Service should be used in a separate process: when you want your application to share data or functionality with other applications, and to do it in the background without being disturbed by the OS or the GC. To quote the documentation:
This allows components in different applications to share a process, reducing resource usage.
I've been reading quit a lot on the subject and I'm still confused. In order to apply the correct flags and attributes to my application I need confirmation on the mental picture I have right now.
Can / will someone please conform or falsify following statement:
1.
A device runs multiple applications; true.
2.
An application contains multiple activities; true.
3.
An application holds one and only one stack (back-stack or task); true.
4.
An activity can (but not must) run in multiple applications, so the activitu in question can be part of multiple but very different stacks; true.
5.
Stack, back-stack and task are just different words for one and the same thing; true.
If false please explaine.
Everything you list is more or less true except for your understanding of "application". This applies to statements 1, 2 and 3 and 4.
In Android, an application represents a package of components (ie: activities, broadcast receivers, services and content providers) that are stored together. During runtime, the concept of application is pretty loose, and only relevant regarding security and permissions (which components can access which other components and data). Android doesn't run applications.
When a user starts an application, what really happens is that Android launches a single activity into (usually) a new task or an existing task (Note: this is a simplification, there are certain cases where a new activity isn't created).
Android runs components, and the components run inside a Virutal Machine (VM) inside a process. A process is an OS entity.
In Android, a task is a sequence of activities that are started and are bound together. A task may contain activities from multiple applications, or may contain activities all from the same application. The activities within a task are in a specific sequence and this is referred to as the task stack, activity stack, back stack or just stack. These activities can be running all in the same process, or they can be running in different processes. It is important to understand that a task and a process and an application are very different things.
I have an application with two Broadcast Receivers, one of them to receive data and the other one to send it. I've seen that they have an attribute android:process to make them run on the application's default process or in another one. In the examples I found using google, receivers were set to run in the process ":remote".
My question is, what are the advantages and disadvantages of using each option?
Using a different Process than the Default Process of the Application is handy when you want to share ressources with another Application.
Todo so you need to arrange two Applications with the same processname, if your processname begins with an lowerchar a global process is spawned. If it begins with a colon : than the process is private.
Keep in mind that to share a process between two apps you need the same userID and the same app certificate.
You also have to load ressources only once and get benefits in memory consumption.
for more information
A process has its own main thread. So, when using different processes i.e. :remote, then it means the code defined in that process will run on a separate thread. You don't usually need to do this for an ordinary workflow.