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:

  1. Boot ROM (The Architect): The very first instruction. It knows purely how to find the blueprints.
  2. Bootloader (The Contractor): Checks the hardware (foundation) and starts the main OS.
  3. Kernel (The Wiring & Plumbing): The Linux Kernel. It wakes up the CPU, Memory, and Drivers.
  4. Init (The Foreman): The first actual process. It reads the instructions (init.rc) and starts the workers.
  5. Zygote (The Template): A "base" Android app process. Every new app is a copy of this.
  6. System Server (The Utilities): Starts critical services (Power, WiFi, Window Manager).
  7. 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 .aidl file.
  • 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?

  1. Launcher calls startActivity(Intent)
  2. Intent goes to AMS via Binder
  3. AMS resolves Intent to target Activity
  4. AMS checks if process exists
  5. If not, asks Zygote to fork new process
  6. New process starts ActivityThread.main()
  7. App attaches to AMS, AMS schedules Activity creation
  8. ActivityThread creates Activity, calls onCreate()

Q: How does AMS decide which processes to kill?

Maintains LRU list with process importance:

  1. Foreground (visible Activity)
  2. Visible (partially visible)
  3. Service (background service)
  4. Cached (background activities)
  5. 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?

  1. APK copied to staging area
  2. Signature verification
  3. Manifest parsing
  4. Native library extraction
  5. DEX optimization (dex2oat)
  6. Package added to PMS database
  7. Broadcast PACKAGE_ADDED

Q: How does Intent resolution work?

  1. App calls startActivity(intent)
  2. PMS scans registered IntentFilters
  3. Matches action, category, data against filters
  4. Returns matching components
  5. If multiple, shows chooser
  6. 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)

  1. 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.
  2. Window: A container for Views. An Activity typically has one PhoneWindow.
    • Analogy: The piece of paper holding all the text.
  3. 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:

  1. Android builds a DisplayList (A recording of commands: "Draw Red Circle at 10,10").
  2. This list is handed to the RenderThread.
  3. RenderThread executes these commands using OpenGL/Vulkan on the GPU.
  4. 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

results matching ""

    No results matching ""