Android,
inside out.

Your phone is not a black box. It is a collection of programs, interfaces, and security boundaries—and you can learn to read them.

This book starts with the basics, then follows real source code through Android’s framework, boot process, Linux kernel, and rooting mechanisms. You do not need to know Android development to begin. You do need curiosity, patience, and a willingness to try things in a safe lab.

How to use this book#

Read the six parts in order if you are new to systems programming. You will learn the prerequisites here rather than being expected to arrive knowing Linux, C++, Java, or Android Studio. The introductory programming lessons teach enough to read the examples and build small programs; they are not a replacement for sustained programming practice.

Every teaching chapter now has Before you start, Learning goals, Practice, Knowledge check, Answers, and Checkpoint sections. First build the mental model, then follow it into code, then attempt the exercise before reading the answers. Read the code before running the command. Predict what will happen, make an observation, and explain the difference.

Already comfortable with Linux? Start with finding your way around AOSP. Interested in rooting? First understand Android’s security model and Verified Boot. Knowing what a tool changes is more useful than memorizing its installation steps.

Use the search field to find a concept anywhere in the lessons. The glossary gives you a short definition and a link back to the full explanation. Mark chapters as read as you work; progress is saved only in this browser. A reading bookmark is not a passed assessment. The estimated minutes describe reading, not installation, builds, experiments, or mastery.

Choose your learning route#

You do not need to buy a phone or a powerful workstation before you know whether this subject interests you. Choose the route that matches the equipment you actually have:

The workstation lesson explains the host choices. The first emulator lab is different from a full AOSP/Cuttlefish build. Windows, macOS, Linux, WSL, and remote build machines are not interchangeable environments. In particular, a tool installed in WSL does not automatically control an emulator running in Windows. Stop at the environment's stated boundary instead of trying random commands.

If a required tool or target is unavailable, use the source-only alternative and label the runtime portion not yet evidenced. That is a useful, honest result—not a failed learner and not a simulated runtime pass. Return to the practical checkpoint when the environment is available.

The route from zero to advanced practice#

The expanded curriculum has 50 teaching chapters. The sequence is intentional; later source excerpts depend on the earlier bridges. Ten mechanism-level chapters now extend the original maps rather than leaving you at an acronym or a source-search instruction.

1. First principles: learn what Android is, prepare tools, practice the shell and Git, understand Linux identities and files, read C/C++, inspect bytes, and connect to a disposable emulator. You should leave this part able to tell source text from an executable, a process from a user, and a host command from a device command.
2. Work with AOSP: navigate a pinned source tree, check build readiness, understand Soong, and follow a controlled investigation from a symptom to a relevant test and repair. Inspection, compilation, installation, boot, and testing are separate milestones.
3. Inside the operating system: learn Java/native interfaces, boot images, init stages, property writes/control messages, Zygote, ART execution/GC/JNI, security identities, concurrency, and Binder lifetime/deadlocks. Follow a HAL through build, init, VINTF, registration, callbacks, and version evolution before joining it to the framework service.
4. The Linux kernel: follow a system call, examine a build target and its compatibility contracts, trace a driver/binding/lifetime, then work through ioctl validation, user copies, interrupts, DMA ownership, and teardown. The source-only work does not require loading a module or provoking a crash.
5. Security and rooting: distinguish boot authenticity from encryption, interpret SELinux evidence, trace actual root credential transitions, inspect userspace and historical kernel-root implementations, understand boot-image patching/mount views, and evaluate recovery, threats, and OTA state. No universal phone-flashing recipe is part of this route.
6. Advanced investigations: interpret platform and compatibility test results, investigate a native failure, measure performance, explore graphics/storage/network/power cases, deepen the graphics buffer/fence/presentation model, then defend an integrated capstone.

The capstone has a supplied-evidence core and a separate engineering extension. The former assesses reasoning from the given information. The latter requires your own build/test/runtime evidence. Do not describe a supplied example, source walkthrough, or proposed test as something you personally ran.

Where the deeper explanations live#

These are sequenced chapters, not permission to skip their prerequisites. Each includes why the mechanism exists, a worked path or failure, and a checkpoint. The examples distinguish pinned source, synthetic models, host checks, and untested Android behavior.

Before you run a command#

Make these five checks every time, even when a command is short:

1. Where am I typing? Your computer's terminal and an Android device shell are different places. An adb command starts on the host even when the operation runs on the device.
2. What does it need? Check the lesson's prerequisite links, tool, shell, target image/build variant, and selected serial. Do not substitute a personal phone for a disposable target.
3. What changes? Reading a property is different from copying a file, creating a process, changing policy, or modifying a boot image. Commands that create teaching files should act only in your own newly created practice directory.
4. What result should I expect? Command blocks are instructions; output blocks and source excerpts are not commands. Quoted source fragments can be incomplete. Do not paste a fragment into a compiler unless the lesson calls it a complete program.
5. What if it differs? Record the exact command and first meaningful error. A missing command, permission denial, unsupported target, and failing test have different causes. Do not add sudo, disable SELinux, delete build output, or change devices as a reflex.

On your first pass, run one command at a time. A new shell prompt usually means the command has finished; a command can succeed without printing anything. The terminal lesson explains prompts, exit status, stopping a foreground command, and safe restarts.

How checkpoints work#

A checkpoint asks for an artifact you can inspect: an annotated diagram, a predicted-versus-observed transcript, a source/call table, an interpreted failure packet, a test result, or a small reviewed diff. It should answer “What can I now do without copying the answer?”

• Ready: your artifact meets the stated criteria and you can explain it without the model answer. For a practical claim, attach actual output from your own environment.
• Revise: you tried, but the model or evidence has a specific gap. Follow the checkpoint's remediation link, explain the misconception, and retry with a different example.
• Not yet evidenced: you have not performed the required observation, build, test, or independent reproduction. Reading a solution does not fill that gap.

Use this short record in a notebook of your choice:

Question and prediction:
Learning mode: source-only / host / virtual platform
Source tag or commit; file and symbol:
Host, tools, target, build type, selected device (if used):
Exact steps and observed result, or supplied artifact identifier:
What this evidence establishes:
What remains unknown; an alternative explanation:
Next check that could falsify my explanation:
Checkpoint result and what I will revise:

For example, a line in an AIDL file establishes that an interface operation is declared in that source revision. It does not establish that a service is running on your emulator. A service list entry is runtime registration evidence; it does not establish that a physical vibrator works. The HAL lesson practices this distinction.

What you will need#

• To read: just this site and somewhere to keep notes. No phone, SDK, or prior programming experience is required. A phone browser can support reading, but does not supply a desktop development environment.
• For the first labs: a computer, a terminal, Git, and Android SDK Platform-Tools. The chapters explain those names before asking you to use them. Download tools from the official Android developer site, not a random “one-click root” bundle.
• For platform builds: a capable Linux workstation, substantial free disk space, and hardware virtualization for a Cuttlefish lab. Building Android is much heavier than building an app; check the official build requirements and the version-specific build chapter before downloading the source.
• For experiments: a disposable virtual device. Nothing in the early lessons requires modifying your everyday phone. Cuttlefish is designed for Android platform development.

A source baseline, not a moving target#

The source walkthroughs use Android 14, tag android-14.0.0_r1, unless a chapter explicitly says otherwise. This is a historical teaching baseline, not a recommendation to run an unpatched Android release on a personal device. A stable tag makes it possible for you to open the same file and compare the same code. The tagged platform manifest records the projects in that release.

Official documentation may describe newer releases. For example, current AOSP guidance directs new work to android-latest-release, and the AOSP FAQ says aosp-main has been read-only since March 27, 2025; the walkthroughs here still use the pinned tag. Kernel branches, third-party root projects, vendor firmware, build targets, and boot-image layouts have their own versions. Each walkthrough should tell you which one it is discussing. A source excerpt is evidence for that implementation—not a promise that every phone behaves identically. Android’s architecture overview is the starting map.

Learning root without gambling with your phone#

Rooting is not one operation. A development build with root-capable ADB, an unlocked device with a patched boot image, and a kernel-based root framework reach privileged execution through different paths. They also have different prerequisites. The rooting methods chapter compares those paths instead of pretending there is one universal recipe.

Only experiment on systems you own or are explicitly authorized to modify. Bootloader unlocking can erase user data. Flashing an incompatible image can stop a device from booting. A backup is not a recovery plan unless you know how to restore it. The official lock/unlock specification explains the state transitions and data-wipe requirements; your device’s manufacturer determines what is actually supported.

We distinguish inspection commands from changes and use development virtual devices for hands-on root observations. Do not copy a command onto hardware because its output looks familiar. In particular, do not relock a bootloader while incompatible or modified images are installed; follow the manufacturer’s exact stock-restoration procedure.

Evidence and honest limits#

Links beside explanations lead to primary documentation or implementation code. Source excerpts identify their file and revision; simplified examples are teaching examples, not verbatim Android code. At the end of each chapter, the source list explains what to read next.

The curriculum has received an AI-assisted beginner-perspective and progression audit using GPT-6 Luna, with per-chapter findings and repair records kept in the project's audits/ directory. That is not a study with actual novice participants, an independent expert certification, or a security audit of Android. Word count, a working link, and a passing web-app test do not establish teaching quality or factual correctness.

Keep these evidence types separate:

• Pinned implementation: what the named source revision does. Follow the linked surrounding code, not only the excerpt.
• Current documentation: published guidance that can change independently of the historical source baseline.
• Illustrative code or synthetic evidence: a teaching program, constructed log, or dataset. Its label is part of the exercise. It is not a captured Android incident.
• Runtime observation: something actually recorded on an identified host/target. Do not generalize beyond the conditions tested.
• Inference or unknown: a conclusion that needs another check, or a boundary for which evidence is unavailable. Saying “unknown” accurately is a technical skill.

Reading source is not the same as testing a system: full Android builds, hardware procedures, and device-specific behavior described here have not been validated by this project. Any host-only example executions are separately identified in the audit record. Check the implementation, record your own version and observations, and treat unexpected output as something to investigate—not something to force into agreement.

Expertise is a portfolio, not a checkbox#

The goal is to take a complete beginner through the prerequisites into advanced Android systems work, not to declare that finishing a book makes someone an expert. Reading the complete path gives you a connected model; doing the exercises gives you practice; repeated independent investigations, tested changes, and critique from experienced maintainers build expertise.

By the end, aim to demonstrate three progressively stronger things:

1. Source-reading competence: independently trace one operation across real files and boundaries, explain identities and validation, cite exact revisions, and acknowledge missing vendor evidence.
2. Engineering competence on a stated target: reproduce a problem, establish a baseline, select and run a relevant test, make a small change, observe the expected before/after behavior, check a negative case, and restore the known baseline. A source-only report cannot establish this level.
3. Advanced practice in a chosen area: investigate an unfamiliar failure or performance/security question, compare plausible explanations, justify measurements and regression tests, and have another person reproduce and review your result. Repeat across more than one change or incident; a single successful lab is not broad expert evidence.

This course includes substantive entry investigations in graphics, storage, networking, power, kernel work, and security. It does not replace specialist experience in ART/compiler development, production driver bring-up, DMA/interrupt handling on real hardware, vendor firmware, cryptographic engineering, or every OEM's recovery system. Choose a specialization and deepen it through real, reviewed work rather than treating those names as covered merely because they appear in a diagram.

The capstone turns this progression into specific artifacts, model reasoning, and readiness criteria. Keep the evidence packet; it is more useful than a completion badge.

Sources#

• Android platform architecture: the official map of the platform’s layers.
• Android 14 release manifest: the release baseline used for source walkthroughs.
• AOSP build requirements: current host requirements; consult the build lesson for the historical baseline.
• Cuttlefish: a virtual device for platform work.
• Bootloader locking and unlocking: the security and data-loss implications of changing lock state.
• AOSP frequently asked questions: current branch policy (android-latest-release; aosp-main read-only since March 27, 2025), which differs from the pinned tag used here.