← Back to all projects

LEARN ANDROID OS INTERNALS DEEP DIVE

Android is not just Linux with a UI. It is a highly specialized, security-hardened, and performance-optimized system that uses the Linux kernel in unique ways.

Learn Android OS Internals: From Java to Metal

Goal: Deeply understand the Android operating system from the perspective of a systems engineer. You will peel back the Java/Kotlin layers to master Binder IPC, the Zygote process lifecycle, the Hardware Abstraction Layer (HAL), and the native daemons that constitute the “Real Android.” By the end, you’ll be able to interact with Android system services using raw C++ and understand how the OS manages resources at the kernel level.

Why Android Internals Matters

Android is not just “Linux with a UI.” It is a highly specialized, security-hardened, and performance-optimized system that uses the Linux kernel in unique ways.

  • Historical Context: When Google acquired Android, they needed a way to allow apps to communicate safely without giving them full Linux process permissions. This led to the creation of Binder.
  • The Challenge: Standard Linux IPC (pipes, sockets, shared memory) was deemed either too slow or too difficult to secure for a mobile-first, multi-user-per-app environment.
  • Why this unlocks power: Mastering internals allows you to perform deep security research (finding CVEs), optimize performance for embedded hardware, or build custom distributions (AOSP) that go far beyond what the standard SDK allows.

Core Concept Analysis

1. The Binder IPC: The Glue of Android

Binder is the most important part of Android. It is a kernel driver (/dev/binder) that allows for high-performance remote procedure calls (RPC) with identity verification.

      Process A (Client)               Process B (Server)
    ┌──────────────────┐             ┌──────────────────┐
    │  Java/C++ Proxy  │             │ Java/C++ Stub    │
    └────────┬─────────┘             └────────▲─────────┘
             │                                │
    ┌────────▼─────────┐             ┌────────┴─────────┐
    │    libbinder     │             │    libbinder     │
    └────────┬─────────┘             └────────▲─────────┘
             │                                │
    ─────────┼────────────────────────────────┼────────── User Space
             │        Kernel Space            │
    ┌────────▼────────────────────────────────┴─────────┐
    │                Binder Kernel Driver               │
    │         (Memory Mapping & Context Tracking)       │
    └───────────────────────────────────────────────────┘

2. The Boot & Lifecycle: From Init to App

Understanding how a device goes from “Power On” to “Running TikTok” is crucial.

  1. Kernel Init: Standard Linux boot.
  2. Init Process: Reads init.rc, starts native daemons (adbd, servicemanager, logd).
  3. Zygote: A unique Android process that “warms up” the ART runtime and waits to fork new apps.
  4. SystemServer: The process that hosts all the Java services (ActivityManager, PackageManager).
  [init]
    │
    ├─▶ [servicemanager] (The Phonebook)
    ├─▶ [surfaceflinger] (The Screen Composer)
    ├─▶ [zygote]
          │
          ├─▶ [SystemServer]
          │     ├─▶ ActivityManagerService
          │     └─▶ WindowManagerService
          │
          └─▶ [App Process 1] (Forked from Zygote)

3. The HAL (Hardware Abstraction Layer)

The HAL defines a standard interface for hardware vendors (Qualcomm, Samsung) to implement so that the Android framework doesn’t need to know the specifics of a particular camera sensor or WiFi chip.

  • HIDL (HAL Interface Definition Language): Used in older Android versions (8-11).
  • AIDL (Android Interface Definition Language): The modern standard for both apps and HALs.

Project 1: The Raw Binder Transaction (Manual Parceling)

  • File: LEARN_ANDROID_OS_INTERNALS_DEEP_DIVE.md
  • Main Programming Language: C++
  • Alternative Programming Languages: C, Rust
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 1. The “Resume Gold”
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Binder IPC / Systems Programming
  • Software or Tool: adb, ndk-build, gdbserver
  • Main Book: “Android Internals: A Convivial Guide” by Jonathan Levin

What you’ll build: A C++ command-line tool that communicates with an existing Android system service (like power or battery) by manually constructing a Binder “Parcel” and sending it over the libbinder interface, without using any AIDL-generated stubs.

Why it teaches Android: This project breaks the “magic” of Java’s IBinder. You’ll learn that every system call is just a transaction ID and a buffer of bytes. You’ll have to look up the transaction codes in the AOSP source code.

Core challenges you’ll face:

  • Finding Transaction IDs → You’ll have to dig into .aidl files in the AOSP source to find the FIRST_CALL_TRANSACTION + N values.
  • Manual Parcel Construction → Understanding how Parcel.writeInt32, Parcel.writeString16, etc., actually layout bytes in memory.
  • Library Linking → Getting your C++ code to link against libbinder.so and libutils.so which are not part of the NDK’s public API.

Key Concepts:

  • Binder Transaction Codes: AOSP source IPowerManager.aidl
  • Parcel Serialisation: “Android Internals” Chapter 9 - Levin
  • System Service Names: service list command

Difficulty: Advanced Time estimate: 1-2 weeks Prerequisites: Familiarity with C++, memory layouts, and basic ADB usage.

Real World Outcome

You will have a binary that you can push to /data/local/tmp on a rooted (or emulator) Android device. When executed, it will perform a system action (like turning off the screen or querying battery percentage) by talking directly to the system services.

Example Output:

$ adb shell /data/local/tmp/raw_binder_tool power 3
[+] Obtaining ServiceManager...
[+] Found service 'power' at handle 0x...
[+] Constructing Parcel for transaction 3 (reboot)...
[+] Sending transaction...
[+] Transaction result: 0 (SUCCESS)
# The device reboots!

The Core Question You’re Answering

“If the Java framework didn’t exist, how would I tell the Android kernel to do something?”

Most Android developers think context.getSystemService() is where the logic lives. It isn’t. It’s just a wrapper around a file descriptor call.

Concepts You Must Understand First

Stop and research these before coding:

  1. The ServiceManager
    • What is “Handle 0”?
    • How does a process “get” a service by name?
    • Book Reference: “Android Internals” Ch. 9 - Jonathan Levin
  2. Parceling Format
    • How are strings encoded in a Parcel? (Hint: UTF-16)
    • What is the “Interface Descriptor” and why must it be at the start of every Parcel?

Project 2: Service Manager Explorer (The “Phonebook” Tool)

  • File: LEARN_ANDROID_OS_INTERNALS_DEEP_DIVE.md
  • Main Programming Language: C++
  • Alternative Programming Languages: Rust
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 1. The “Resume Gold”
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Systems Discovery
  • Software or Tool: AOSP Source Tree
  • Main Book: “Embedded Android” by Karim Yaghmour

What you’ll build: A tool that iterates through every registered service in ServiceManager and dumps its metadata: its interface descriptor (e.g., android.os.IPowerManager), its binder handle, and its permission requirements.

Why it teaches Android: You’ll understand the discovery phase of Binder. You’ll learn how servicemanager acts as the DNS of the Android OS.

Core challenges you’ll face:

  • Querying ServiceManager → Using the listServices method of the IServiceManager interface.
  • Binder Handle Mapping → Understanding that handles are process-local.
  • SELinux Permissions → Discovering why your tool might be denied access to see certain services even as root.

Real World Outcome

A tool that provides a much more detailed view than the standard service list command.

Example Output:

$ ./sm_explorer
SERVICE NAME         | INTERFACE DESCRIPTOR           | HANDLE
---------------------|--------------------------------|-------
phone                | com.android.internal.telephony | 12
power                | android.os.IPowerManager       | 45
package              | android.content.pm.IPackageMgr | 8
...
[!] Total 184 services found.

Project 3: The Custom Native Service Daemon

  • File: LEARN_ANDROID_OS_INTERNALS_DEEP_DIVE.md
  • Main Programming Language: C++
  • Alternative Programming Languages: Rust
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 4: Expert
  • Knowledge Area: System Daemons / Security
  • Software or Tool: SELinux Policy, init.rc
  • Main Book: “Android Security Internals” by Nikolay Elenkov

What you’ll build: A native C++ process that starts at boot (via init.rc), registers itself with ServiceManager under a custom name (e.g., my.cool.service), and provides a few methods that other processes can call via Binder.

Why it teaches Android: This is how the “real” parts of Android work (like vold or netd). You will have to deal with the Linux lifecycle, the Binder loop, and—most importantly—SELinux policies.

Core challenges you’ll face:

  • Writing an init.rc script → Learning the syntax of the Android Init Language.
  • The Binder Thread Pool → Using ProcessState and IPCThreadState to start the listener loop.
  • SELinux “Permissive” vs “Enforcing” → You will likely spend 50% of your time writing .te (Type Enforcement) files so the system doesn’t kill your service.

Real World Outcome

You’ll see your service listed in service list and be able to call it from a standard Java app using ServiceManager.getService("my.cool.service").

Example Output:

# Logcat output showing service startup
12-28 10:00:01.123 I MyNativeService: Starting binder thread pool...
12-28 10:00:01.125 I MyNativeService: Registering 'my.cool.service' with SM...
---

## Project 4: The Zygote Simulator (Clone & Fork)
- **File**: LEARN_ANDROID_OS_INTERNALS_DEEP_DIVE.md
- **Main Programming Language**: C++
- **Alternative Programming Languages**: C
- **Coolness Level**: Level 4: Hardcore Tech Flex
- **Business Potential**: 1. The "Resume Gold"
- **Difficulty**: Level 4: Expert
- **Knowledge Area**: Linux Process Management
- **Software or Tool**: `fork()`, `unshare()`, Linux Namespaces
- **Main Book**: "Operating Systems: Three Easy Pieces" by Arpaci-Dusseau

**What you'll build**: A C++ program that mimics the behavior of the Android Zygote. It will pre-load a shared library (simulating the ART runtime), then enter a loop waiting for commands to "spawn" an app. When commanded, it will `fork()` itself and "specialize" the child process by changing its UID/GID and setting up namespaces.

**Why it teaches Android**: You'll understand why Android apps start so fast and how the OS uses Linux `setuid` and namespaces to sandbox every app.

**Core challenges you'll face**:
- **Address Space Sharing** → Understanding what is copied and what is shared during `fork()`.
- **Security Specialization** → Using `setresuid()` and `setgroups()` to drop privileges.
- **Signal Handling** → Managing `SIGCHLD` so you don't end up with zombie app processes.

---

## Real World Outcome

You will run a "Master" process. You can then send it a command (e.g., via a socket) to "Spawn App 10123". A new process will appear with UID 10123, but it will already have your "Heavy Library" loaded in memory.

**Example Output:**
```bash
$ ./zygote_sim
[Zygote] Pre-loading heavy_runtime.so (100MB)... Done.
[Zygote] Waiting for spawn commands on /tmp/zygote.sock...

# In another terminal:
$ echo "spawn:10123" > /tmp/zygote.sock

# Back in Zygote:
[Zygote] Forking child for UID 10123...
[Child] I am alive! My UID is now 10123. 
[Child] Memory for heavy_runtime.so is already here: 0x7f...

The Core Question You’re Answering

“Why doesn’t Android just use execve() to start apps like a normal Linux distro?”

Before you code, consider the cost of loading the entire Java runtime for every single app. Zygote is a “warm” process that stays in RAM so you don’t have to wait 2 seconds for every app launch.

Project 5: Custom AIDL HAL (The Hardware Bridge)

  • File: LEARN_ANDROID_OS_INTERNALS_DEEP_DIVE.md
  • Main Programming Language: C++
  • Alternative Programming Languages: Rust
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 4. The “Open Core” Infrastructure
  • Difficulty: Level 3: Advanced
  • Knowledge Area: HAL / Hardware Integration
  • Software or Tool: aidl, AOSP VINTF
  • Main Book: “Embedded Android” by Karim Yaghmour

What you’ll build: A custom Hardware Abstraction Layer using modern AIDL. You’ll define a hardware interface (e.g., IFakeLed.aidl), implement the C++ backend that writes to a virtual /sys/class/leds file, and register it in the VINTF (Virtual Interface) manifest.

Why it teaches Android: This is the barrier between “The Framework” (Google) and “The Hardware” (Vendors). You’ll learn how the system locates and loads hardware drivers at runtime.

Core challenges you’ll face:

  • AIDL for HALs → Learning the differences between app-level AIDL and stable HAL AIDL.
  • The VINTF Manifest → Debugging the XML files that tell Android “Yes, this device has a FakeLed HAL version 1.”
  • Hardware Permissions → Ensuring the system_server process has permission to talk to your HAL via SELinux.

Real World Outcome

You’ll be able to use the hal_check tool or a small C++ client to toggle a “LED” (even if it’s just a file on disk) through a standard Android service interface.

Example Output:

$ lshal | grep fakeled
android.hardware.fakeled@1.0::IFakeLed/default   running

$ ./test_hal --on
[+] Calling IFakeLed::setLedStatus(true)...
[+] Success. (Check /sys/class/leds/fake/brightness)

Project 6: Android Property Monitor

  • File: LEARN_ANDROID_OS_INTERNALS_DEEP_DIVE.md
  • Main Programming Language: C++
  • Alternative Programming Languages: C, Python (via shell)
  • Coolness Level: Level 2: Practical but Forgettable
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: System Configuration
  • Software or Tool: libcutils, __system_property_wait
  • Main Book: “Android Internals: A Convivial Guide” by Jonathan Levin

What you’ll build: A high-performance native monitor that uses the __system_property_wait API (not polling!) to detect when specific system properties change.

Why it teaches Android: System properties are the “global variables” of Android. Understanding how they are shared via memory-mapped files and how the init process manages them is fundamental.

Core challenges you’ll face:

  • Non-polling architecture → Using the futex-based property wait API correctly.
  • Property Contexts → Understanding why setprop fails for some properties but works for others (SELinux again).
  • Mmap’d memory → Seeing how properties are actually just a shared memory area between init and every other process.

Project 7: The Native BufferQueue Visualizer

  • File: LEARN_ANDROID_OS_INTERNALS_DEEP_DIVE.md
  • Main Programming Language: C++
  • Alternative Programming Languages: Rust
  • Coolness Level: Level 5: Pure Magic (Super Cool)
  • Business Potential: 1. The “Resume Gold”
  • Difficulty: Level 5: Master
  • Knowledge Area: Graphics Stack / SurfaceFlinger
  • Software or Tool: libgui, libui, IGraphicBufferProducer
  • Main Book: “Android Internals: A Convivial Guide” by Jonathan Levin

What you’ll build: A C++ tool that bypasses View, Activity, and WindowManager to create a Surface directly via SurfaceComposerClient, obtains a GraphicBuffer, draws into it (via software or OpenGL), and queues it to SurfaceFlinger.

Why it teaches Android: This is the “Holy Grail” of Android UI. You’ll learn exactly how pixels move from an app process to the system’s display compositor. You’ll understand the Producer-Consumer model of BufferQueue.

Core challenges you’ll face:

  • Bypassing the Framework → Finding and using the private libgui.so headers.
  • GraphicBuffer Allocation → Understanding how gralloc allocates memory that both the CPU and GPU can see.
  • SurfaceComposer Secret → Interacting with SurfaceFlinger via its Binder interface.

Real World Outcome

You will run a command-line binary that suddenly draws a spinning triangle or a red square on the screen, floating above all other apps, without any Java Activity being started.

Example Output:

$ ./native_draw --color red
[+] Connecting to SurfaceFlinger...
[+] Creating Native Surface (100x100)...
[+] Dequeuing buffer...
[+] Rendering to buffer...
[+] Queuing buffer...
# A red square appears on the phone screen!

The Core Question You’re Answering

“How does a game engine like Unreal or Unity actually put a pixel on an Android screen?”

They don’t use Button or TextView. They talk to BufferQueue. This project shows you the raw pipe.

Project 8: Input Event Sniffer (Direct Dev Node)

  • File: LEARN_ANDROID_OS_INTERNALS_DEEP_DIVE.md
  • Main Programming Language: C
  • Alternative Programming Languages: C++
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Input Subsystem
  • Software or Tool: /dev/input/event*, struct input_event
  • Main Book: “Embedded Android” by Karim Yaghmour

What you’ll build: A tool that reads raw bytes from /dev/input/eventX, decodes the Linux input protocol, and identifies touch coordinates, button presses, and sensor data before the Android InputReader service even touches them.

Why it teaches Android: You’ll see the raw Linux foundation of Android’s touch system. You’ll understand how “Hardware Events” become “MotionEvents.”

Core challenges you’ll face:

  • Device Identification → Figuring out which /dev/input/eventX corresponds to the touchscreen vs the power button.
  • Bitmask Parsing → Using ioctl(EVIOCGBIT) to determine what a device is capable of.
  • Root Permissions → Understanding why regular apps can never do this (and why it’s a security feature).

Real World Outcome

A real-time stream of your touch coordinates in the console.

Example Output:

$ sudo ./input_sniff
[+] Monitoring /dev/input/event2 (Touchscreen)
[Touch] X: 540, Y: 1280, Pressure: 45
[Touch] X: 542, Y: 1285, Pressure: 48
[Release] Finger lifted.

Project 9: Native Seccomp Sandbox

  • File: LEARN_ANDROID_OS_INTERNALS_DEEP_DIVE.md
  • Main Programming Language: C++
  • Alternative Programming Languages: C
  • Coolness Level: Level 5: Pure Magic (Super Cool)
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 4: Expert
  • Knowledge Area: Security / Kernel
  • Software or Tool: prctl, libseccomp, BPF
  • Main Book: “Android Security Internals” by Nikolay Elenkov

What you’ll build: A wrapper for native binaries that applies a strict Seccomp (Secure Computing) policy. You will restrict a process so it can only write to stdout and read from a specific file, crashing if it tries to open() a network socket or fork().

Why it teaches Android: Android uses Seccomp to sandbox the media codecs and the Chrome renderer. This project shows you how the OS enforces “Defense in Depth” at the syscall level.

Core challenges you’ll face:

  • BPF Filter Generation → Writing the rules that the kernel uses to check every syscall.
  • Library Dependencies → Discovering that even a “simple” printf might call mmap or brk under the hood.
  • Syscall Auditing → Using strace to find the exact list of syscalls your program needs to survive.

Project 10: VOLD Explorer (Volume Daemon)

  • File: LEARN_ANDROID_OS_INTERNALS_DEEP_DIVE.md
  • Main Programming Language: C++
  • Alternative Programming Languages: Rust
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Filesystems / Storage
  • Software or Tool: Netlink Sockets, vold
  • Main Book: “Embedded Android” by Karim Yaghmour

What you’ll build: A tool that listens to the vold (Volume Daemon) events. You’ll connect to the native Netlink socket and parse the messages sent when a SD card is inserted, an OTG drive is connected, or a partition is encrypted.

Why it teaches Android: You’ll understand how Android manages external storage and the complex dance between the Linux kernel’s uevent system and Android’s vold daemon.

Project 11: DEX Bytecode Disassembler

  • File: LEARN_ANDROID_OS_INTERNALS_DEEP_DIVE.md
  • Main Programming Language: C++
  • Alternative Programming Languages: Python
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 1. The “Resume Gold”
  • Difficulty: Level 4: Expert
  • Knowledge Area: Compilers / Runtime
  • Software or Tool: dex file format specification
  • Main Book: “Android Security Internals” by Nikolay Elenkov

What you’ll build: A C++ program that reads a .dex file (from an APK) and disassembles the Dalvik bytecode into human-readable instructions, showing the registers, constants, and method lookups.

Why it teaches Android: You’ll understand exactly what the ART (Android Runtime) is executing. You’ll learn about register-based VMs (Dalvik) vs stack-based VMs (JVM).

Project 12: Logcat Mimic (The Log Sink)

  • File: LEARN_ANDROID_OS_INTERNALS_DEEP_DIVE.md
  • Main Programming Language: C
  • Alternative Programming Languages: C++
  • Coolness Level: Level 2: Practical but Forgettable
  • Business Potential: 1. The “Resume Gold”
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Logging / IPC
  • Software or Tool: /dev/socket/logdw, logd
  • Main Book: “Android Internals: A Convivial Guide” by Jonathan Levin

What you’ll build: A tool that writes logs directly to the logd socket without using __android_log_print. You’ll manually format the binary log message (priority, tag, message) and send it over the Unix domain socket.

Why it teaches Android: You’ll discover that Log.d() isn’t a standard printf to stdout. It’s a structured message sent to a central logging daemon.

Project Comparison Table

Project Difficulty Time Depth of Understanding Fun Factor
Raw Binder Trans. Level 3 1 week ★★★★☆ ★★★☆☆
Zygote Simulator Level 4 2 weeks ★★★★★ ★★★★☆
Native BufferQueue Level 5 3 weeks ★★★★★ ★★★★★
Custom AIDL HAL Level 3 2 weeks ★★★★☆ ★★★★☆
Input Sniffer Level 2 Weekend ★★★☆☆ ★★★★☆
DEX Disassembler Level 4 2 weeks ★★★★☆ ★★★☆☆

Recommendation

If you are new to Systems Programming: Start with Project 8 (Input Sniffer). It’s the most “standard” Linux-style project and gives you immediate visual feedback from the touchscreen.

If you are an experienced Java Android Dev: Start with Project 1 (Raw Binder). It will fundamentally change how you view the Framework APIs you use every day.

Final Overall Project: The “Native-Only” Android System

Goal: Build a “mini-OS” that runs inside Android.

What you’ll build: A system that consists of:

  1. A Native Service (Project 3) that manages a “Security Vault.”
  2. A Custom HAL (Project 5) that simulates a hardware crypto-chip.
  3. A Native GUI (Project 7) that displays a PIN-entry screen.
  4. All running under a Seccomp Sandbox (Project 9).

Success Criteria: You can reboot the phone, see your service start via init, and interact with your custom GUI to “unlock” a file stored in your native service, all without a single line of Java or Kotlin code running in your process.

Summary

This learning path covers Android OS Internals through 12 hands-on projects. Here’s the complete list:

# Project Name Main Language Difficulty Time Estimate
1 Raw Binder Transaction C++ Level 3 1-2 weeks
2 Service Manager Explorer C++ Level 2 Weekend
3 Custom Native Service C++ Level 4 2 weeks
4 Zygote Simulator C++ Level 4 2 weeks
5 Custom AIDL HAL C++ Level 3 2 weeks
6 Property Monitor C++ Level 2 Weekend
7 Native BufferQueue C++ Level 5 3 weeks
8 Input Event Sniffer C Level 2 Weekend
9 Native Seccomp Sandbox C++ Level 4 1 week
10 VOLD Explorer C++ Level 3 1 week
11 DEX Disassembler C++ Level 4 2 weeks
12 Logcat Mimic C Level 2 Weekend

For beginners: Start with projects #8, #12, #6 For intermediate: Jump to projects #2, #1, #5, #10 For advanced: Focus on projects #3, #4, #7, #9, #11

Expected Outcomes

After completing these projects, you will:

  • Understand the binary wire format of Binder IPC.
  • Be able to build and deploy native system daemons and HALs.
  • Know how the Zygote process manages app sandboxing and memory.
  • Be capable of bypassing the Java SDK to optimize performance or security.
  • Have a deep, first-principles understanding of how Android is built on top of Linux.

You’ll have built 12 working projects that demonstrate deep understanding of Android OS Internals from first principles.

Deep Dive Reading by Concept

Foundational Internals

Concept Book & Chapter
Android Architecture Embedded Android by Karim Yaghmour — Ch. 2: “Internals Preview”
Binder Internals Android Internals: A Convivial Guide by Jonathan Levin — Ch. 9: “The Binder Framework”
Process Startup Android Security Internals by Nikolay Elenkov — Ch. 1: “Android Security Architecture”

System Services & HAL

Concept Book & Chapter
Hardware Layer Embedded Android by Karim Yaghmour — Ch. 4: “Hardware Abstraction Layer”
Graphics Stack Android Internals: A Convivial Guide by Jonathan Levin — Ch. 11: “SurfaceFlinger and the UI”

Essential Reading Order

  1. The Big Picture (Week 1):
    • Embedded Android Ch. 2 (Overview of the system stack)
    • Android Security Internals Ch. 1 (The security model and UID/GID separation)
  2. The IPC Engine (Week 2):
    • Android Internals (Levin) Ch. 9 (Binder driver and libbinder)