There is no shortage of material on Android internals. AOSP, official docs, blog posts, papers, trace discussions — it is all findable. The annoying part is that every piece speaks for a different version: this post concludes something about Android 12, that one does not say which version it tested, a third describes what happened on one particular device.
That gap is what AIW is for. The full name is Android Internal Wiki; the Chinese book title is 《Android 技术内幕：系统机制、性能优化与工具实战》 — five parts, twenty-six chapters, with the content pinned to Android 17. The repository is about to be open-sourced:
https://github.com/Gracker/android-internals-wiki
What the repository gives you is twenty-six chapters of content, a full table of contents, and an EPUB rebuilt every week.
Those twenty-six chapters are now far enough along to put in front of people. If you read a passage that does not match the source, an issue or a pull request is welcome.
The diagrams in this post are in Chinese, the same as the book itself.
What this book is for
Anyone doing Android performance or systems work has probably run into this: official docs describe APIs and platform behavior, a blog post describes one investigation, a source walkthrough hands you a call chain. Each is useful on its own, and together they still do not add up to one path you can follow from app code down to the kernel with every step checkable against source.
Each chapter tries to answer four things: why the mechanism exists, how it runs today, what tool to observe it with, and which versions and conditions the conclusion holds under.
The readers it is written for are these three groups:
- App engineers: slow startup, janky scrolling, ANR, memory churn, abnormal power draw — anyone who wants to trace from the app layer down to a system-level cause.
- Systems engineers: anyone who needs Framework, Native, HAL, and Kernel in one view.
- Performance engineers: anyone who needs a stable knowledge frame for reading traces, judging bottlenecks, and explaining both the gain and the risk of an optimization.
This book is not an introductory course. It also has no conclusions about Android 18 or later; the content stops at Android 17.
Where it stands now
Five parts, twenty-six chapters, plus a small appendix. The full table of contents is in src/SUMMARY.md. Here is what each chapter covers — just take the ones relevant to you.
Part 1: How the Android system runs
How the system gets an app running, and which layer the screen, input, memory, scheduling, and storage each wait on.
- Ch 1, System architecture overview: process model, Zygote, Binder, cgroups, and system service boundaries. For slow startup, ANR, or a native crash, first establish which process the code runs in and which IPC hop it crosses.
- Ch 2, Rendering: from the main thread, RenderThread, BufferQueue, and SurfaceFlinger through to HWC and the panel. For dropped frames, a late first frame, or a misplaced SurfaceView, first work out which production and composition path the frame takes.
- Ch 3, Input: taps that do nothing, scrolling that does not track the finger, a back animation that lands one beat late. A healthy frame rate does not prove the input reached the app on time — put the event and the frame that answers it on the same timeline.
- Ch 4, Memory management: GC, page faults, direct reclaim, zram, process freezing, and graphics buffers. OOM is only one possible ending; memory pressure also shows up as jank and background rebuilds.
- Ch 5, CPU scheduling and power management: runnable but queued, big/little placement, DVFS, thermal limits, and background execution policy. CPU utilization alone cannot tell these apart.
- Ch 6, Storage and I/O: page faults,
fsync, block device contention, and MediaProvider / FUSE on shared storage. Looking only at the Java stack, storage waits get mistaken for compute.
Part 2: Performance problems and optimization
The jank, slowness, unresponsiveness, battery drain, and poor networking users actually feel, and which class of system behavior each maps to.
- Ch 7, Smoothness: dropped frames, input latency, composition fallback, and thermal limits. Two cases of “jank” that feel alike can need fixes in completely different places.
- Ch 8, Responsiveness: the time from an action to visible feedback or to being interactive again. Kept separate from smoothness: one looks at first response, the other at the interval between consecutive frames.
- Ch 9, ANR: the system deciding an app did not finish an input, broadcast, or service callback within the limit. Mechanism, joint diagnosis with kernel traces, and the common paths.
- Ch 10, Memory performance: OOM, frequent GC, paging, and graphics memory from an app performance angle. First separate which kind of memory is growing, who holds it, and how it turns into latency a user can feel.
- Ch 11, Power: the rate of power draw versus the energy used over a window. WakeLocks, Bluetooth scanning, background execution, and user settings — the time window is usually much longer than for jank.
- Ch 12, Network performance: queueing, DNS, connection reuse, TLS, and
netdafter a request enters the network stack. - Ch 13, Rendering pipelines: View, SurfaceView, Vulkan, Compose, Flutter, WebView, Camera, video overlay, game engines, and XR. First establish who produces the buffer, which Surface it is written to, and which layer does the composition.
Part 3: Performance tools and methodology
How to collect evidence, how to read the tools, and how to write an investigation down so it can be rechecked.
- Ch 14, Perfetto: putting rendering, input, scheduling, Binder, I/O, and power on one timeline. The goal is capturing enough data, reading tracks and slices correctly, and writing SQL someone else can verify.
- Ch 15, Other analysis tools: Android Studio Profiler, simpleperf, HPROF, dumpsys, Battery Historian, GPU capture, Winscope, and eBPF. The forms of evidence Perfetto does not cover live here.
- Ch 16, Methodology: how to define the symptom, what the existing evidence actually proves, which part the app, the system, and the test environment each account for, and how to verify a fix.
- Ch 17, APM tools and the monitoring ecosystem: Firebase, Matrix, KOOM, LeakCanary, Benchmark, and the collection mechanisms behind crash / ANR / power data. Aimed at selection and implementation; it does not replace the offline analysis in chapters 14 through 16.
Part 4: System and vendor optimization
What can still be changed on the platform and on shipping devices, and why an AOSP baseline is not the behavior of any particular device.
- Ch 18, AOSP performance optimization: system services, build and debug, Kernel 6.18, AutoFDO, profile-guided install-time compilation, and boot time. Written for people who can change system code.
- Ch 19, OEM and device differences: Power HAL, SoC, game mode, Media Performance Class, and product forms such as Private Space and automotive. Shipping devices stack their own kernel, firmware, and thermal differences on top.
Part 5: App performance in practice
The startup, rendering, memory, I/O, power, and production observability an app team can actually change.
- Ch 20, App stability: Java / native crashes, ANR, OOM, FD and thread leaks. Keep the logs, stacks, and version information that let you pin down the responsible module.
- Ch 21, Startup optimization: process creation, initialization, first frame, and background work. Cold / warm / hot start, page visible, and business-ready should be timed separately.
- Ch 22, Rendering in practice: layout, lists, Compose, animation, images, WebView, CameraX, and Media3. Verify each change inside the frame budget of the current refresh cycle.
- Ch 23, Memory in practice: Java heap, leaks, native heap, bitmaps, and on-device model budgets. Object leaks, allocation rate, and graphics buffer buildup are handled differently.
- Ch 24, I/O and network optimization: files, databases, serialization, connections, and caching. Measure main-thread blocking, syscalls, protocol round trips, and retries separately instead of filing them all under “the API is slow.”
- Ch 25, Power and app size: background work, location, audio, ADPF, thermal throttling, plus DEX / SO / resource size. Compare before and after on the same device under the same test conditions.
- Ch 26, App observability: crash reporting, performance collection, production triage, and release quality gates. Chapter 17 covers how APM is implemented; this one covers how an app team puts the evidence to use.
The appendix currently holds a performance analysis checklist.
The conclusions in the book cover Android 17 / API 37, corresponding to the public AOSP tag android-17.0.0_r1. Anything above that is not in the content: preview APIs and platform behavior not yet merged are marked, at most, as “not yet a conclusion of this book.”
The version label is still alpha: the table of contents will keep being adjusted, errors found will keep being fixed, and an English edition has to wait until after v1.0.
Every week the content is built into an EPUB and published to GitHub Releases, stripped down to chapter text with the YAML tags and navigation pages removed.
https://github.com/Gracker/android-internals-wiki/releases
Where the material comes from
The judgments in the book rest on a few kinds of basis: AOSP source, official documentation, reproducible experiments, and engineering discussion that is already public.
The material coming in day to day falls into roughly these categories:
- Long-collected technical articles and notes
- RSS, the Android section of Juejin, public technical discussion
- Papers and single-topic research
- Link sweeps from things like Android Weekly
- AOSP and tooling docs read for one specific chapter
More material does not mean usable material. Outdated conclusions, experience with no version conditions, and anything that does not line up with a target chapter never make it into the content.
Material reaches the content by having its facts extracted, rewritten in my own structure, and attributed to the original source — never lifted wholesale. AOSP source follows Apache License 2.0; other people’s content is used only for technical explanation. Where something is my own judgment, the conditions and boundaries are written out alongside it.
How a chapter actually gets written
Of the 8,327 commits, only 467 wrote a draft. The other forty-nine hundred-odd were review, rework, and spot checks — roughly ten rounds of review and repair per draft.
Early on this ran on OpenClaw, with a batch of scheduled tasks taking in material, filing it, drafting, and checking every day. Many tasks at high frequency: throughput went up and so did the problems. Several tasks could edit the same chapter at once, state files overwrote each other, and the commit log no longer showed what a given run had changed. It later moved to Hermes Agent, high-frequency parallel writing was dropped in favour of one chapter at a time — collection and classification still run daily from scripts, while writing, technical review, Chinese review, spot checks, and rework are split into serial lanes.
Here is the path a section takes now. Once a draft exists, it goes through a deep technical review that scores six dimensions and records problems under each separately: do the class names and paths in the text exist in the tag it was checked against; is the mechanism explained or is only a conclusion stated; which versions changed this behavior; where will the reader still be stuck; do the numbers carry units and a baseline; does this agree with the other chapters. Problems come in three levels — P0 for a factual error, P1 for an important gap, P2 for a suggested improvement. A section with an open P0 does not reach finalized. Reaching finalized is not the end either: an idle spot check runs every four hours, grabs a finalized section at random, reads it again, and drops it back for repair if something is wrong.
Those reviews have recorded 1,894 P0s in total. What they mostly stop falls into three kinds: references to classes and paths that have been removed or never existed; illustrative snippets labelled as real source; and premises that only held in an older version being used to explain current behavior. All three share a trait — nothing looks wrong in the sentence itself, and judging it means going back to the source and the version.
A model does not slow down where it is unsure — it states the uncertain and the certain with the same fluency. So the model that writes is not the model that reviews: Chinese review runs through DeepSeek, and on the technical side another 862 external review passes were run.
What was checked is recorded in each file’s header: last_verified_against says which source snapshot the section was checked against, sources says where the basis came from — 283 of the 314 files fill in the first, 281 the second. What those fields buy is locating: when something is wrong, you can find which section it is in, which tag it was checked against, and which source it rests on.
What AI does here is the repeatable work: collection, first drafts, format checks, rework. Where to take it, what to keep and what to cut, and who answers for an error — that is still a person’s job. Finalized only means the current version passed its checks; it can still be overturned later.
Current boundaries
The book records confidence section by section, and 122 sections are not yet solid enough to stand behind without qualification, mostly stalling on the same causes: no measured data, no reproduction on a real device, or vendor-side behavior with no public basis to cite.
The thinnest part is data. How a mechanism runs is covered in detail, but a lot of places cannot give a number: how long a given stage actually takes, how much more one path costs than another. The book can point you in a direction there, not hand you a measurement. That kind of gap does not close by reading the source again; it needs measurement on real devices. The mechanism half of this book is sturdier than the numbers half, and that gap is still there.
One more thing that affects looking something up: sources are listed per section, not marked per sentence. Tracing where one particular sentence came from means working through that section’s source list yourself; there are no inline citations in the text.
How contributing works
The review process above stops most factual errors, not all of them. For a system the size of Android, across twenty-six chapters spanning App, Framework, Native, and Kernel, there will always be devices I have not run and vendor changes I have not seen. Open-sourcing lets those spots be checked again by people who have the real hardware and have hit the real problems.
There are four ways to take part; details are in CONTRIBUTING.md:
- Corrections: factual errors, outdated descriptions, broken links, inaccurate class and method names. Pull requests are welcome directly, no issue needed first.
- Adding material: good articles, trace cases, source analysis, official docs, or papers. Saying which chapter it belongs in and which statement it supports is more useful than pasting the original.
- New chapters or large rewrites: open an issue first. The current focus is polishing the existing twenty-six chapters, so the table of contents is not being extended for now.
- Translation: the English edition starts after v1.0, with the plan in
i18n/TRANSLATION-PLAN.md. Anyone interested can claim chapters in an issue ahead of time.
Merged pull requests are recorded in the contributors list in the README and in the book’s acknowledgements. Issues and PRs are reviewed in tiers by chapter priority — core chapters fastest, appendices slowest — with the exact windows written in CONTRIBUTING.md.
The corrections I can act on fastest carry a version and a path: “On Android 17 this InputDispatcher path does not match the text; the AOSP path is frameworks/native/..., and the behavior I saw on version X was …”. With something like “this chapter is too shallow” I cannot tell which sentence to change, so it takes another round of asking.
When filing an issue or a PR, this information makes it much faster to handle:
- The Android version, ideally matched to an AOSP tag
- A source path or an official documentation URL
- Expected behavior and actual behavior
- Where possible, an observation point that can be rechecked in Perfetto, dumpsys, or logcat
Vendor-specific behavior and general AOSP behavior are kept apart in the book; Part 4 covers vendor differences and states its conditions up front.
Repository and ebook
- Repository: https://github.com/Gracker/android-internals-wiki
- Ebook: https://github.com/Gracker/android-internals-wiki/releases
- Contributing: https://github.com/Gracker/android-internals-wiki/blob/master/CONTRIBUTING.md
Licensing runs on two tracks: community use under CC BY-NC-SA 4.0, commercial use by separate written permission. Downloading the repository or the ebook does not grant a commercial license. Quoted AOSP code stays under Apache License 2.0.
If the book is useful to you, star the repository. More stars put it in front of more people working on Android, and give anyone who wants to correct something or add material a place to find it.
The book will keep being updated, and its conclusions can be overturned by later versions. If you read a passage that does not match the source, open an issue — the Android version and the source path are enough.
