as far as i understand each android process runs in a "sandbox" environment, what happen if an android application is a multi process application? do all processes use the one single sandbox since all the processes use the same user id?
As Android uses the Linux kernel for sanboxing, the real sandbox is per (unix) user id, rather than per process. And the Dalvik VM itself makes no attempt at sandboxing.
Of course proccesses owned by the same user id are somewhat isolated from each other, but tools like kill(), ptrace() and the /proc filesystem which pierce process isolation are available - and governed primarily by user id isolation.
There are a couple of oddities about how code maps to processes however:
Either an Activity or a Service can be designated in the manifest to run in a distinct process, but this will still be a process owned by the package user id
Distinct application packages with the same signing certificate can use the shared user id feature to share a sandbox; in some cases this can result in their code running in the same process.
The multiprocess attribute of the <activity> tag says that the activity could run in the process of whatever starts it - it's not entirely clear if this could mean it would end up running under a foreign userid (an idea that seems more risky for the caller than the callee).
The isolatedprocess attribute of the <service> says that it runs the service in an isolated process with "no permissions of its own" - while it doesn't come out and explicitly say so, I suspect this may mean that this would be a process owned by a distinct, minimally privileged user id.
A more definitive explanation on these last two points would be good. Perhaps I'll look at the implementing code when I have more time.
Each process is associated with a separate runtime (JVM) and sandbox in Android.
For example, if you tune couple of your activities to run on a separate processes (to take advantage of having a distinct memory space) then you end up with having 2 sandboxes when you launch the app and have to manage IPC if needed.
Another example is - if you set two different apps to share the same user id then you won't need IPC since they can see each other's data, but that doesn't mean they run on the same process or sandbox. You need to set process attribute of application element in the manifest.
Out of the context, you can also have multiple components belongs to separate apps to easy sharing and saving memory.
Related
I've got a question about android applications with same android:sharedUserId and android:process attributes.
would you please tell me, when should we use applications in the shared process and how can we access data on other application in that process?
android:sharedUserId - This is deprecated now, you should avoid using this
when should we use applications in the shared process
Ideally whole application process should not be shared with another application and there won't be much use-cases of it as well
Android components such as Activity/Receiver etc should be made to run in a separate process as opposed to application process basis some use-case, like we used separate process for running our FCM service to reduce memory footprints while initialising reducing our ANR's
how can we access data on other application in that process
You can use Android Interface Definition Language (AIDL) for this
https://developer.android.com/guide/components/aidl
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 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.
I am getting started on Android & iOS development and hence links to relevant resources will also be appreciated, just that I couldn't find anything much relevant.
Case Detail: I have to build an app that holds some critical information in a variable that is created, sent over a ssl-encrypted connection and destroyed. This variable shouldn't be read by any other process on the device. So far, I know of two cases that can happen:
[1] a service or program monitors the foreground app(which here would be my app) and then if it can inject some code(getting the foreground to bind to the rogue service for example) to read off the variable contents in question. I know OS safeguards exist, but are there any proofs out in the wild that demonstrate this ability of injecting code?
[2] a service or program monitors the network connections and logs the data being sent over the wire. Is there a possibility of apps reading network data like this? I know apps exist which can log the amount of data exchanged per app, but I have no clue as to whether they read system log files or actually monitor the connection.
It will be appreciated if details could be provided for both the platforms.
I work only with android, so this is valid for android only:
No, a service cannot inject code in foreground up, due to (at least) 2 reasons:
Each installed application gets it's own user id, and each process, and their data is protected by the user id. So one process cannot access the memory of another process. So no process can modify the memory either (by inserting code)
The java bytecode is converted to dalvik code, and stored in a place where only the system process can write. So no other process can inject code by changing the compiled dex files.
That is the protection provided by the system. Of course hackers might find an exploit in a certain library, and using buffer overflow might be able to run some snippet of code, but that's a different story. Also note that the data files of the process are private by default (no other process can see it), but processes could have read access to the code. Which means storing private keys in the code is probably not safe.
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.