https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=Mobile_Apps_2023W_Lecture_13 2026-04-08T03:33:36Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=Mobile_Apps_2023W_Lecture_13&diff=24374&oldid=prev 2023-03-02T04:52:38Z

<p>Created page with &quot;==Notes== &lt;pre&gt; Android Architecture &amp; Security ------------------------------- * I&#039;ve graded all proposals * On Friday, progress report 3 is due * If you have something to demo, please demo in Friday! What is running on an Android device? How does it compare to a regular Linux system? Android documentation uses lots of Android-specific jargon, not at all clear how it maps to more normal concepts. So I&#039;m going to try explaining that here. First, Android runs on L...&quot;</p> <p><b>New page</b></p><div>==Notes==<br /> <br /> &lt;pre&gt;<br /> Android Architecture &amp; Security<br /> -------------------------------<br /> <br /> * I&#039;ve graded all proposals<br /> * On Friday, progress report 3 is due<br /> * If you have something to demo, please demo in Friday!<br /> <br /> <br /> What is running on an Android device? How does it compare to a regular Linux system?<br /> <br /> Android documentation uses lots of Android-specific jargon, not at all clear how it maps to more normal concepts. So I&#039;m going to try explaining that here.<br /> <br /> First, Android runs on Linux. So what does that mean?<br /> <br /> Standard division for most Linux systems:<br /> <br /> Applications<br /> ------------<br /> Linux Kernel<br /> ------------<br /> Hardware<br /> <br /> <br /> Kernel communicates with hardware using hardware APIs (accessing special memory locations, I/O ports, interrupts, etc)<br /> <br /> Applications talk to the Linux kernel using system calls.<br /> <br /> Applications run inside of processes. A process is an address space + one or more execution context. Each address space is separate, processes cannot access the memory of other processes (unless explicitly shared).<br /> <br /> When you run &quot;ps&quot; or &quot;top&quot; on a Linux system, you can see all of the processes that are running.<br /> <br /> You can do the same on Android as well, underneath it is just Linux.<br /> But...Android has a bunch of extra stuff.<br /> <br /> <br /> One key difference is in how processes talk to each other. Standard Linux supports multiple communication mechanisms:<br /> - TCP/IP sockets<br /> - System V IPC<br /> - pipes<br /> - shared memory (using mmap)<br /> <br /> Android adds its own custom IPC mechanism, Binder. Yes, they *patched* Linux to add support for a new IPC mechanism!<br /> - this is the mechanism that facilitates communication in Android<br /> - most Android APIs are built on this when they go between processes<br /> - key feature: it is very fast! (uses shared memory, but with kernel support)<br /> <br /> Originally Binder wasn&#039;t in the main Linux kernel, it was kept &quot;out of tree&quot;, but it has been upstreamed and so modern Linux systems do have support for Binder.<br /> <br /> <br /> On a standard Linux system, permissions are all based on files and users. Devices are special files, and access is granted or not based on the user and group of a process.<br /> <br /> User/group file permissions are not flexible enough for a system like Android, they wanted something else to determine what applications could access what.<br /> <br /> For example, how to control access to a camera? The raw camera would show up as a device in /dev, how can we make sure only one app is using the camera at a time, that permission is only granted when the user says so and the user can withdraw it?<br /> <br /> Well, every app on Android has its own user ID, and that is used to limit the access the app has.<br /> - not per user, per APP!<br /> <br /> This user-ID-per-app thing is part of the Android *application sandbox* - applications have only limited access to files and other resources. They are confined by default.<br /> <br /> Web browsers also implement a sandbox, that&#039;s why each tab cannot access data in another tab (for JavaScript code), but it is implemented using very different technologies and with different levels of access<br /> - remember a sandbox is an aspiration, not a specific set of technologies!<br /> <br /> If a regular Android app asks the Linux kernel for access to the camera, the kernel will just say no because it won&#039;t have the right permissions (it won&#039;t have the right user and group ID for access). But then how does it get access?<br /> <br /> Android has special background processes, &quot;servers&quot;, that wait for requests from Android applications and then do the work on behalf of the app.<br /> - these services perform a role somewhat like that of the Linux kernel,<br /> but in an Android-specific way<br /> - most central one is system_server, this implements the basic plumbing,<br /> but there are others like media_server<br /> <br /> Note that the camera device&#039;s permissions are setup so that an android server process has exclusive access. Applications then ask it (via intents which are Binder-relayed messages) for access to these resources and the server can say yes or no. Because Binder is fast this interaction is also fast.<br /> <br /> <br /> What&#039;s cool about Binder is you don&#039;t have to know which process you want to talk to. You can broadcast a request with specific criteria and the appropriate processes (applications or servers) will get it and respond as they see fit.<br /> - this is all orchestrated by system_server with the help of the Linux kernel&#039;s binder mechanism<br /> <br /> Why does all this matter?<br /> - to some degree it doesn&#039;t, if you&#039;re doing normal application development<br /> - but when things break, it is important to know who is telling you that there is a problem and where you can potentially observe things to try and fix them<br /> &lt;/pre&gt;</div>

Soma