AOSP & Android Internals
1. Android Architecture
Q: Explain the Android system architecture.
Android is a layered system stack:
| Layer | Components | Language |
|---|---|---|
| Applications | System apps, third-party apps | Kotlin/Java |
| Framework | ActivityManager, PackageManager, WindowManager | Java |
| Native Libraries | libc, SSL, SQLite, Media | C/C++ |
| Android Runtime | ART, core libraries | C++/Java |
| HAL | Camera, Audio, Sensors | C/C++ |
| Linux Kernel | Drivers, Binder, power management | C |
Q: What does each layer do?
- Framework: Provides APIs developers use (Activities, Views, Services)
- ART: Executes app code, manages memory, garbage collection
- HAL: Abstracts hardware differences—same API for different devices
- Kernel: Core OS—process scheduling, memory, drivers
2. The Boot Process (The House Analogy)
Imagine Android booting up is like building a house:
- Boot ROM (The Architect): The very first instruction. It knows purely how to find the blueprints.
- Bootloader (The Contractor): Checks the hardware (foundation) and starts the main OS.
- Kernel (The Wiring & Plumbing): The Linux Kernel. It wakes up the CPU, Memory, and Drivers.
- Init (The Foreman): The first actual process. It reads the instructions (
init.rc) and starts the workers. - Zygote (The Template): A "base" Android app process. Every new app is a copy of this.
- System Server (The Utilities): Starts critical services (Power, WiFi, Window Manager).
- Launcher (The Front Door): The Home Screen appears.
Deep Dive: Zygote
Q: Why is it called Zygote?
In biology, a zygote is the initial cell. In Android, Zygote is the template process that contains the entire Core Library and ART pre-loaded.
How it speeds up launch:
- Without Zygote: Every time you open Instagram, the phone would have to load the entire Android Framework framework from hard disk to RAM (Takes 5-10 seconds).
- With Zygote: The framework is already in RAM in the Zygote process. Android just says "Fork (Clone) Zygote". The new process starts with everything pre-loaded.
- Copy-on-Write: The RAM is shared until the app writes to it. 4000 apps share the same system class memory.
Deep Dive: System Server
The "Mother" of all services. If this process dies, the phone reboots. It houses:
- ActivityManager (AMS): The "Manager" (Starts apps).
- PackageManager (PMS): The "Librarian" (Installs apps).
- WindowManager (WMS): The "Decorator" (Draws windows).
3. Binder IPC
3. Binder IPC (The Specialized Waiter)
Q: What is Binder? Android apps run in isloated sandboxes (processes). App A generally cannot touch App B's memory. Binder is the magical door between these sandboxes.
The Waiter Analogy:
- Client (Your App): You are sitting at a table. You want a Burger (System Service). usage:
getSystemService(). - Proxy Object: You don't talk to the Kitchen directly. You talk to a Menu (Proxy). You point at "Burger".
- Binder Driver (The Waiter): The Menu (Proxy) hands the order to the Waiter (Kernel Driver). The Waiter walks through the secure door to the Kitchen.
- Stub (The Kitchen): The Waiter hands the order to the Chef (Stub). The Chef cooks the Burger (Executes the method).
- Result: The Chef gives the Burger to the Waiter, who brings it back to your table.
Why is this important?
- Security: The Waiter checks your ID (UID) before taking the order.
- Performance: The Burger is passed efficiently (Memory mapping), not copied byte-by-byte unnecessarily.
Q: What is AIDL? The Recipe Card. Since the Client and Kitchen are in different worlds, we need a common language to define the order.
- You write an
.aidlfile. - Android generates the Java/Kotlin code for the Proxy (Menu) and Stub (Kitchen).
4. Activity Manager Service
Q: What is ActivityManagerService (AMS)?
The core system service managing:
- Activity lifecycle and task stacks
- Process lifecycle and LRU management
- App launch and Intent resolution
- Recent apps list
- Foreground/background state
Q: How does app launch work internally?
- Launcher calls
startActivity(Intent) - Intent goes to AMS via Binder
- AMS resolves Intent to target Activity
- AMS checks if process exists
- If not, asks Zygote to fork new process
- New process starts
ActivityThread.main() - App attaches to AMS, AMS schedules Activity creation
- ActivityThread creates Activity, calls
onCreate()
Q: How does AMS decide which processes to kill?
Maintains LRU list with process importance:
- Foreground (visible Activity)
- Visible (partially visible)
- Service (background service)
- Cached (background activities)
- Empty (no components)
Kills from bottom up when memory needed.
5. PackageManagerService
Q: What does PackageManagerService (PMS) do?
- Installs/uninstalls packages
- Parses and stores package metadata
- Resolves Intent to components
- Manages permissions
- Maintains package database
Q: What happens during APK installation?
- APK copied to staging area
- Signature verification
- Manifest parsing
- Native library extraction
- DEX optimization (dex2oat)
- Package added to PMS database
- Broadcast
PACKAGE_ADDED
Q: How does Intent resolution work?
- App calls
startActivity(intent) - PMS scans registered IntentFilters
- Matches action, category, data against filters
- Returns matching components
- If multiple, shows chooser
- AMS launches chosen component
6. Android Runtime (ART)
Q: What is ART and how does it differ from Dalvik?
| Dalvik | ART |
|---|---|
| JIT (Just-In-Time) | AOT + JIT (Ahead-Of-Time) |
| Compiled at runtime | Compiled during install |
| Slower startup | Faster runtime |
| Less storage | More storage (compiled code) |
ART also has:
- Better garbage collection (concurrent)
- Improved profiling and debugging
- Profile-guided compilation
Q: What is DEX and why is it used?
DEX (Dalvik Executable) is Android's bytecode format:
- Optimized for memory-constrained devices
- More compact than Java bytecode
- Register-based (not stack-based)
- Single DEX = all classes (vs separate .class files)
dex2oat compiles DEX to native code during install.
Q: How does garbage collection work in ART?
- Concurrent: Most work while app runs
- Generational: Young objects collected more often
- Compacting: Reduces fragmentation
- Card marking: Track cross-generation references
GC pauses are minimal (<5ms typically).
7. Window System
7. The Windowing Hierarchy
Q: View vs Window vs Surface (The Confusion)
- View: A UI widget (Button, TextView). Millions of these exist. They calculate their own size (
onMeasure) and draw themselves (onDraw) on a Canvas.- Analogy: A single line of text on a piece of paper.
- Window: A container for Views. An Activity typically has one PhoneWindow.
- Analogy: The piece of paper holding all the text.
- Surface: The actual pixels buffer in RAM.
- Analogy: The table the paper sits on.
Q: Putting it all together (SurfaceFlinger)
- Your App (Window) draws all its Views onto a Surface.
- The System Bar is a separate Window (separate Surface).
- The Navigation Bar is a separate Window (separate Surface).
- SurfaceFlinger is the System Compositor. It takes all these Surfaces (App, System Bar, Nav Bar), stacks them according to Z-order, and flattens them into one image to send to the Screen.
Q: Hardware Acceleration Instead of the CPU drawing every pixel:
- Android builds a DisplayList (A recording of commands: "Draw Red Circle at 10,10").
- This list is handed to the RenderThread.
- RenderThread executes these commands using OpenGL/Vulkan on the GPU.
- GPU is much faster at drawing pixels than CPU.
8. HAL and Treble
Q: What is HAL?
Hardware Abstraction Layer—interface between Android framework and device hardware. Standardized API regardless of underlying hardware:
- Camera HAL: Same API, different camera chips
- Audio HAL: Same API, different audio hardware
- Sensor HAL: Same API, different sensors
Q: What is Project Treble?
Architecture change in Android 8.0:
- Separates vendor implementation from framework
- HAL implementations become HIDL services
- Framework can update without touching vendor code
- Enables faster Android updates on devices
Before: HAL directly linked into framework After: HAL as separate processes, communication via HIDL/AIDL
9. Security Architecture
Q: How does Android's security model work?
App Sandbox:
- Each app runs as separate Linux user
- Private data directory per app
- Can't access other apps' data
- SELinux provides mandatory access control
Permissions:
- Declared in manifest
- User grants at install or runtime
- System enforces at API level
Verified Boot:
- Each boot stage verifies next stage
- Detects system modification
- Rollback protection
Q: What is SELinux on Android?
Mandatory Access Control—even root can't bypass:
- Policies define what each domain can access
- Apps run in app domain, limited access
- System services have specific domains
- Blocks many exploit techniques
10. Common Interview Topics
Q: What's asked in AOSP/internals interviews?
| Topic | Focus Areas |
|---|---|
| Boot Process | Sequence, Zygote role, System Server |
| Binder | How IPC works, AIDL, Parcelable |
| AMS | App launch, process management, task stack |
| PMS | Installation, Intent resolution, permissions |
| ART | DEX, AOT/JIT, garbage collection |
| Window System | WMS, Surface, SurfaceFlinger |
| Security | Sandbox, permissions, SELinux |
Q: Why do companies ask about internals?
- Platform engineering roles require it
- Debugging complex issues needs system knowledge
- Performance optimization requires understanding internals
- Security work needs deep knowledge
- Shows depth of understanding beyond SDK
Quick Reference
| Topic | Key Points |
|---|---|
| Architecture | Apps → Framework → Native/ART → HAL → Kernel |
| Boot | (House Analogy) ROM -> Bootloader -> Kernel -> Init -> Zygote -> System Server -> Launcher |
| Binder | (The Waiter) IPC mechanism; Proxy/Stub pattern; single-copy, secure |
| Zygote | (The Template) Preloads 4000+ classes; Copy-on-Write RAM sharing |
| AMS | (The Manager) Manages activities, processes, app lifecycle; LRU killing |
| PMS | (The Librarian) Installs packages, resolves intents, manages permissions |
| ART | AOT+JIT compilation; concurrent GC; DEX bytecode format |
| Windows | Window=Container, Surface=Canvas(Table); SurfaceFlinger composites all |
| Security | App sandbox (Linux users); SELinux; verified boot |