TL;DR: Each Android app is installed with its own Linux user ID, so the kernel's ordinary file and process isolation keeps apps apart, and SELinux adds a mandatory policy on top that confines apps even further. The app's signing certificate is its identity: updates must be signed with the same key, and signature-level permissions are granted only to apps signed by the same key as the app that defined them. Permissions gate access to sensitive platform resources: normal ones are granted at install, dangerous ones (camera, location, contacts) need the user's consent at runtime, and signature ones only go to apps from the same signer. An app's private files, its exported components and its signing key are therefore the three things to get right.
How to approach it
Explain isolation (UID plus SELinux), identity (signing) and authority (permissions) as three separate mechanisms, then show how they combine when one app talks to another. Finish with what breaks each one: a leaked signing key, an exported component with no permission, and a rooted device.
A strong answer
- 1
1 · Linux UID per app
Kernel file and process isolation
- Private data directory readable only by that UID
- 2
2 · SELinux
Mandatory policy over every app domain
- Confines apps even where file permissions would allow
- 3
3 · Permissions
Normal, dangerous (runtime), signature
- Signature-level permissions only for apps with the same signer
- 4
4 · Signing certificate
The app's identity
- Updates must match it or follow its rotation lineage
Isolation by user ID. At install, the package manager assigns the app a unique UID. Its private directory (/data/data/<package>, or the per-user equivalent) is owned by that UID with permissions that exclude others, and its processes run as that UID. Another app cannot read those files or attach to those processes without root. Android layers SELinux in enforcing mode over this: apps run in confined domains (such as untrusted_app) whose policy limits what even a compromised app process can touch in the system. Native code in an app runs in the same sandbox; writing in C does not escape it.
Identity by signature. An APK is signed with the developer's key (with Play App Signing, Google holds the app signing key and the developer signs uploads with a separate upload key). The platform uses the certificate to decide:
- whether an update may replace an installed app (same signer, or a valid key rotation),
- whether a signature-level permission may be granted,
- whether two apps may share data through mechanisms restricted to the same signer.
A stolen signing key lets an attacker ship an "update" that inherits the app's data and trust, which is why release keys belong in hardware-backed storage with tight access.
Authority by permission.
| Level | Granted | Example |
|---|---|---|
| Normal | Automatically at install | Internet access |
| Dangerous (runtime) | User prompt, revocable | Camera, location, contacts, microphone |
| Signature | Only to apps signed by the same key as the defining app | A company's own apps sharing a private service |
| Special | Settings screens, high friction | Draw over other apps, accessibility service, install unknown apps |
Special permissions such as accessibility and overlay are what Android banking malware typically asks users for, because they allow reading screen contents and drawing fake interfaces.
Crossing the boundary on purpose. Apps talk through intents, bound services, broadcast receivers and content providers. A component that other apps may call must be exported, and since Android 12 an app that declares intent filters must state android:exported explicitly. The receiving component should require a permission (often signature-level for internal use) and validate everything it receives, because the caller may be any app on the device.
What breaks the model.
- Exported components without permission checks: another app invokes privileged functionality or reads data.
- Data written outside the sandbox: shared storage, logs, the clipboard, or backups that include sensitive files.
- A rooted device: the owner (or malware with root) can read any app's files and instrument its process.
- A leaked signing key: forged updates.
What interviewers probe next
- "Does writing the sensitive part in native code protect it?" No. Native code runs in the same sandbox under the same UID; it is only harder to read, not isolated.
- "How would two apps from the same company share a secret safely?" A service or provider protected by a signature-level permission, with the secret released only after checking the caller, or better, each app fetching its own credential from the server.
- "What changes on a rooted device?" The UID boundary no longer holds against the owner, so on-device secrets and checks are readable and modifiable; the server must not rely on them.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
A colleague asks what stops a malicious app on the same Android phone from reading your app's database.
Start here
What isolates apps on Android?
Which user owns your app's files?
Each app is installed with its own Linux user ID, so the kernel's file and process isolation keeps apps apart, and SELinux adds a mandatory policy that confines apps further.
Carry it forwardPer-app UIDs plus SELinux isolate apps.
Weak answerThinking apps share one user.
Constraint changes
What is the app's identity?
What proves an update comes from you?
Its signing certificate. Updates must be signed with the same key, and signature-level permissions let only apps from the same signer access protected components.
Carry it forwardThe signing key is the app's identity.
Weak answerLosing control of the signing key.
Constraint changes
How could the database still leak?
Which doors did your app open itself?
Through your own app: exported components or content providers without permission checks, files written to shared storage, backups, logs or a WebView bridge. Most leaks come from app design, not sandbox escape.
Carry it forwardApps leak through their own exported surfaces.
Weak answerBlaming the sandbox for app-level leaks.
Constraint changes
What about rooted devices?
What can root read?
Root bypasses UID isolation, so a rooted device's owner, or malware with root, can read any app's files. Encrypt sensitive data with Keystore keys and treat the server as the authority.
Carry it forwardRoot defeats the sandbox; plan for it.
Weak answerStoring secrets in plain files.
Constraint changes
How should you protect the database?
What does the device actually need to store?
Keep it in internal storage, do not export providers without signature permissions, exclude it from backups if sensitive, encrypt sensitive fields with Keystore-backed keys, and keep minimal data on the device.
Carry it forwardInternal storage, no unnecessary exports, encrypted fields.
Weak answerWorld-readable files or external storage.
Now defend it
How would you answer and harden the app?
Per-app UIDs and SELinux keep other apps out, and the signing key is the app's identity; leaks usually come through your own exports, shared storage, backups or logs, and root defeats isolation, so keep data minimal in internal storage, protect exports with signature permissions, exclude sensitive files from backup and encrypt with Keystore keys.
How it's scored
Weak: "Apps are sandboxed and need permissions."
Hire: Explains per-app UIDs and private storage, signing as update identity, and normal versus dangerous versus signature permissions.
Strong Hire: Adds SELinux confinement, Play App Signing and key protection, special permissions abused by malware, exported components and the Android 12 exported rule, and lists what breaks each mechanism.
Common mistakes
- Believing native code escapes or strengthens the sandbox.
- Forgetting that signature permissions depend on protecting the signing key.
- Exporting components with intent filters and no permission requirement.
- Treating files on shared storage as private.