AOSP & Android Internals

1. Android Architecture

Q: Explain the Android system architecture.

Android is a layered system stack:

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. Boot Process

Q: Describe the Android boot sequence.

1. Boot ROM: First code, loads bootloader
2. Bootloader: Initializes hardware, loads kernel
3. Kernel: Initializes drivers, mounts filesystem, starts init
4. Init: First user process, parses init.rc, starts daemons
5. Zygote: Preloads classes, spawns app processes
6. System Server: Starts all system services (AMS, PMS, WMS)
7. Launcher: Home screen app starts

Q: What is Zygote and why does it exist?

Zygote is the parent of all app processes. It:

• Preloads ~4000 common classes
• Preloads common resources
• Forks to create new app processes

Benefits:

• Fast app startup (classes already loaded)
• Memory sharing (Copy-on-Write)
• Consistent runtime environment

Q: What does System Server do?

Starts and manages all system services:

• ActivityManagerService (AMS): Manages activities, apps
• PackageManagerService (PMS): Installs, queries packages
• WindowManagerService (WMS): Manages windows, input
• 100+ other services

Each service runs in a Binder thread pool within System Server process.

3. Binder IPC

Q: What is Binder and why does Android use it?

Binder is Android's inter-process communication mechanism. Apps run in isolated processes; Binder allows them to communicate with system services and each other.

Why not traditional IPC?

• Security: Built-in caller UID/PID verification
• Performance: Single copy (not two like pipes)
• Object-oriented: RPC semantics, pass object references
• Reference counting: Automatic cleanup

Q: How does a Binder call work?

1. Client calls method on Proxy object
2. Proxy marshals parameters into Parcel
3. Binder driver transfers to server process
4. Stub unmarshals and calls real implementation
5. Result marshaled back through Binder
6. Proxy returns result to client

All app-to-system communication uses Binder (getSystemService → Binder).

Q: What is AIDL?

Android Interface Definition Language. Generates Proxy/Stub code for Binder communication. You define the interface, AIDL generates the IPC boilerplate.

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?

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

Q: How does the Android window system work?

WindowManagerService (WMS) manages:

• Window creation and positioning
• Z-ordering of windows
• Input routing to correct window
• Surface allocation

SurfaceFlinger (native):

• Composites surfaces from apps
• Sends to display hardware
• Handles VSync timing

Q: What is a Surface?

Buffer that apps draw to. Each window has a Surface:

• App draws to Surface via Canvas or OpenGL
• Surface is shared memory with SurfaceFlinger
• SurfaceFlinger composites all Surfaces
• Result sent to display

Q: How does hardware acceleration work?

• App builds display list (recording of draw operations)
• RenderThread processes display list on GPU
• Canvas operations translated to OpenGL
• Frees main thread for other work

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?

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