How we know: sources and uncertainty

Every page on Zygote makes factual claims: this API arrived at level 33, this file is in that directory, this behaviour changed for apps targeting that version. Each of those claims needs to be checkable, or the site is a very confident rumour.

TL;DR#

Facts are traced to a primary source: AOSP documentation, the Android developer site, the source tree itself, or a launch post from the release.
Every page lists its sources, numbered, with the date each was accessed.
Claims we could not confirm against a primary source are marked inline and never hidden.
Each page carries a last_verified date. Android changes every year; a page without an age cannot be trusted.
We paraphrase and cite. We do not copy text, and we do not hotlink images.

Mental model#

Think of a court case rather than a textbook. A textbook asserts; a court requires that every claim be supported by evidence that the other side can inspect. The numbered citation is the exhibit number, the source list is the evidence bundle, and the uncertainty marker is a witness saying "I did not see that myself."

Where the analogy breaks#

A court must reach a verdict. This site can leave a question open indefinitely, and often should. A gap labelled honestly is more useful than a confident sentence that turns out to be wrong.

The big picture#

Loading diagram…

Text description of this diagram

A treemap of the software on an Android phone, showing why sourcing is non-trivial. The open AOSP platform, the vendor and OEM layer, and Google's proprietary services are maintained by different organisations. A claim about 'Android' may be true of the open platform and false of a particular phone, so the source needs to say which layer it describes.

Deep dive#

The source hierarchy#

Not all sources are equal. When they conflict, the higher one wins.

The source code itself — android.googlesource.com and cs.android.com. If the code says it, it is true of that branch.
AOSP and developer documentation — source.android.com and developer.android.com. Authoritative for behaviour and APIs, and the place where the platform documents intent.
Official release posts and talks — the Android Developers Blog, Google I/O. Authoritative for dates and for "why we did this", which no reference page contains.
Kernel and standards documentation — docs.kernel.org, man pages, specifications.
Reputable engineering writing — well-known engineers' blogs, used for explanation rather than for facts that need a primary source.
Wikipedia — used for dates only, and cross-checked against a primary source.

The full ledger is on the Sources page, and it is the same list every page draws from.

What gets a citation#

A sentence needs a source when it contains:

an API level, version number or release date;
a class, method or constant name that is not obvious from context;
a file path or a structural claim about the source tree;
a number with units — milliseconds, megabytes, threads, percentages;
a claim about the order of events, where order matters.

A sentence does not need one when it is explaining a mechanism that the cited source already covers, or when it is an analogy.

The uncertainty marker#

Here is the whole policy, operationally:

The rule exists because the failure mode of educational content is not being incomplete; it is being confidently wrong. An incomplete page teaches you less. A confidently wrong page teaches you something false that you then act on.

Dates and the version problem#

Android changes every year, sometimes twice. A fact that was true in Android 12 may be false in 17. Two practices manage this:

Every page has a last_verified date, shown under the title. It says when the claims were last checked, not when the page was written.
Version-sensitive claims name their version. "Notification channels are mandatory when targeting API 26" is durable; "notifications require a channel" is not, because it is only true above a threshold.

Where the data comes from#

Much of the site is generated from datasets rather than written by hand:

Dataset	Source	How
Versions	Official release pages and launch posts	Hand-curated, validated for contiguity and dates
Permissions	`Manifest.permission` reference page	Parsed from the page
Behaviour changes	Per-release behaviour-change pages	Hand-curated from those pages
System services	`SystemServiceRegistry.java` and `SystemServer.java`	Extracted from source
Glossary	Multiple sources per term	Hand-written, validated

The point of the datasets is not efficiency. It is consistency: the same API level appears the same way on every page, because every page reads the same record.

How it evolved#

The policy itself has a history worth knowing: the site started by marking uncertainty decoratively and later made it structural, because marking a claim as unverified turned out to be far more useful than omitting it.

day one →Cite everythingEvery fact gets a source or does not ship.

later →Mark uncertaintyClaims that cannot be traced are shown, not dropped.

later still →Date every pageFreshness becomes part of the claim.

Curiosity corner#

The most common wrong fact on Android sites is a version number, usually one release off. It is the easiest thing to check and the easiest to get wrong.
A missing citation is more honest than a vague one. "According to Google" is not a source.

Why is the site called Zygote?Because the zygote is the one process every app descends from — a single point where the whole platform meets the code you write. …Open card →

Try it#

Verify a file path yourself

$ # Open a file on cs.android.com and check the path in the URL
adb shell dumpsys package android | head -20

Then find the corresponding source under frameworks/base/services/core/java/com/android/server/pm/. The path in the source tree is the proof that the mechanism you read about exists.