android

Both platforms sandbox apps and require signing; they differ in who decides what runs and how fast fixes arrive. Interviewers want the shared model first, then the differences that change a threat model.

The sandbox is a Linux user ID, SELinux and a signature that decides who you are. Get those three right and most Android security questions become reasoning rather than recall.

Every exported component is an API that any app on the phone can call. The vulnerabilities are the same ones you know from web APIs: missing authorization, trusted input, and a confused deputy.

Both platforms let an app declare its transport rules in a file the reviewer can read in seconds. Knowing which lines are dangerous makes you fast in a mobile review.

On a phone, the signing key is the app's identity: it decides who can ship updates, which data the app can share, and what it is entitled to do. Lose it, or let someone else sign, and that identity changes hands.

Rooting is not one trick. It is a decision about the boot chain: either the owner unlocks it, or an exploit breaks it. Everything an app can detect follows from which.

Most mobile findings do not need root at all. The ones that do usually point to the same conclusion: the server must not trust the client.

Taking over a modern Android phone takes several bugs in a row. Each link targets a different layer, and Android's design adds a defence at every one.

Most mobile malware never breaks the sandbox. It persuades the user to hand over the permissions that let it read the screen and act as them.

Your app can be fully patched on a phone whose kernel is two years old. The answer separates what you control, what the platform controls, and what you can only measure.