Mateusz Pachulski

Android from the foundation · Puzzle 7 of 16

Letters between apps

Apps can't reach into each other, but they can ask the town hall to deliver a request. For some requests, the town hall first checks whether the app is allowed.

The problem

In puzzle 6, the sandbox kept every app inside its walls. But a link in a chat opens the browser, and a chat app can start a phone call. If apps can't reach each other, how do they work together?

See it

A chat app sends an Intent to start a call; Binder carries it to system_server, which checks the phone-call permission and delivers it to the phone app; a game without the permission is refused kernel Binder system_server Chat Game Phone Chat ✓Game ✗ call Intent ✗ no

  1. The chat app wants to call a friend. It can't reach into the phone app: they're in separate sandboxes. So it writes an Intent, a request to the town hall: "open the Phone app's call screen and call this number".

    Step 1 of 5

  2. The Intent goes to the town hall, system_server, by Binder, like every message to it.

    Step 2 of 5

  3. A call can cost money, so it needs a permission: a right an app must be granted, here by the user tapping Allow. The town hall checks its list: has Chat been granted the phone-call permission? Predict: what if it hadn't?

    Step 3 of 5

  4. Chat is allowed, so the town hall delivers the request, again by Binder, and the call starts in the phone app.

    Step 4 of 5

  5. A game without the permission asks the same: the town hall refuses.

    Step 5 of 5

Save this diagram as a GIF

The building block

An app sends an Intent: a message to system_server asking it to open a screen, in another app or in your own. It travels by Binder, like every message to the town hall.

Opening another app's screen often needs nothing special: a link in a chat opens the browser for anyone. But some actions need a permission: a right the app has to be granted. Placing a call straight away needs the phone-call permission, because calls can cost money. Some permissions are granted at install; risky ones, like this one, the user grants by tapping Allow in a prompt. system_server checks them before it acts. It knows which app sent the Intent from the app's UID, which Binder tells it (puzzle 13 shows how).

The analogy

You can't walk into the neighbour's house, but you can send the town hall a letter: "please put a call through for me". The town hall checks its list of who's allowed what, then passes it on, or sends it back.

Check yourself

A game sends an Intent asking to start a phone call, but the user never granted it the phone-call permission. What happens?

Right. system_server checks the sender's permissions before acting.

Not quite. The kernel guards files and memory. Permissions for actions are checked by system_server.

Not quite. Delivery isn't automatic: the town hall checks permissions first.

Why does an Intent go to system_server instead of straight to the other app?

Not quite. Size has nothing to do with it: the sandbox means only the town hall can deliver.

Right. Only the town hall can deliver between sandboxes, and it checks the sender on the way.

What's the difference between the sandbox and a permission?

Not quite. The sandbox is walls the kernel enforces for every app; permissions are rights system_server grants per action.

Right. Walls by the kernel; rights by the town hall.

Sources

What you now know

An Intent is a letter to the town hall: "open this screen". system_server checks the sender's permissions, then delivers it, or doesn't.