What actually is Android?

Android is not one app, one company's phone skin, or just the Linux kernel. It is a software platform: operating-system components, application frameworks, APIs, tools, and compatibility rules that let software run across many devices. A phone sold as “Android” combines pieces with different owners and licenses. Learning Android from source starts by learning where those pieces meet—and where they do not. AOSP overview

This is a reading lesson. You need no phone or development tools. The implementation examples use Android 14 tag android-14.0.0_r1; that is a historical teaching baseline, not a recommendation to run an unpatched release. Vendor behavior and later Android releases may differ.

Before you start#

• Start here — how this book uses version-pinned sources and separates reading from experiments.

Learning goals#

By the end, you can distinguish AOSP from Android products and Google Mobile Services; draw a simplified app-to-hardware path; explain why a framework API may cross a process boundary; and identify which release or vendor context is needed before making a source claim.

Four names that are easy to mix up#

Android is the platform and family of compatible products built around it. AOSP, the Android Open Source Project, is the publicly available source code and associated project through which much of the platform is developed. AOSP does not promise that every component on every retail phone is open source: hardware support, proprietary firmware, and optional services may be distributed separately. “Open source” describes particular code and its license, not a guarantee that a commercial phone can be reproduced from public source. AOSP overview · AOSP FAQ

An OEM (original equipment manufacturer), or device maker/vendor, adapts Android to a product. It can add system apps, visual design, drivers, and device-specific services. A SoC (system-on-chip) maker supplies the main processor and often related components; the device needs suitable low-level software for them. Boundaries vary: a vendor may integrate code from several suppliers. A phone's system image is therefore not necessarily a generic AOSP build.

Google Mobile Services (GMS) is a collection of Google apps and APIs that may be preinstalled under separate arrangements. It is not synonymous with AOSP; an AOSP build can omit GMS. Compatibility is evaluated against published requirements and tests; it does not mean every device has identical apps or interface. AOSP terminology and compatibility

Keep this small model in mind:

Android app
    ↓ public APIs and framework services
Android platform (AOSP-based system + device-maker adaptations)
    ↓ hardware interfaces and drivers
Linux kernel + vendor hardware support
    ↓
physical device

Optional ecosystem: Google Mobile Services and other licensed apps

This is a map, not a promise that every request follows exactly these layers. Some app functions use libraries or device-specific components. AOSP includes much more than the kernel; the kernel alone does not provide the familiar Android app environment. AOSP overview · Android architecture

Layers, without memorizing every acronym#

An application is software installed for a user-facing function or background capability. Most third-party apps use the public SDK: documented APIs intended for app developers. A framework API is a callable interface—such as a class or service—that helps an app perform platform tasks without directly operating hardware. Public APIs have compatibility expectations; internal or privileged interfaces can be restricted and change. Application fundamentals

Many Kotlin or Java apps run managed code using ART, Android Runtime. “Managed” means the runtime participates in executing code and managing memory; apps may also contain native C/C++ libraries. These are two ways to execute app logic, not separate operating systems. ART

A system service performs shared platform work, often outside the app's process. For example, an app typically asks framework components to arrange display work rather than directly controlling display hardware. Permissions and identity checks help control access; the exact route depends on the feature. Android architecture

Below the framework are native libraries and hardware-facing interfaces. A HAL (hardware abstraction layer) is an interface through which Android software communicates with hardware implementations. Vendor code and kernel drivers support product-specific devices. The Linux kernel handles low-level mechanisms such as process scheduling, virtual memory, and device access. Android uses a Linux kernel but adds its own runtime, framework, services, policies, and app model. AOSP architecture · Android kernel overview

Separate programs need a way to exchange requests and replies; that is inter-process communication (IPC). Android's Binder is a platform IPC mechanism. An app's framework call can cross into another process, such as a system service. It is not always an ordinary function running inside the app. Binder overview

Read a small piece of source (optional)#

In Android 14 tag android-14.0.0_r1, Activity.java declares android.app.Activity. An activity is a framework component commonly used for a focused interaction surface in an app. This code excerpt is actual version-pinned AOSP source, not a general documentation example:

public class Activity extends ContextThemeWrapper
        implements LayoutInflater.Factory2,
        Window.Callback, KeyEvent.Callback,
        OnCreateContextMenuListener, ComponentCallbacks2,
        Window.OnWindowDismissedCallback,
        ContentCaptureManager.ContentCaptureClient {

If you have not seen Java, read this as a label rather than a coding exercise: class Activity names a class; extends names a base class; implements lists interfaces/contracts. The declaration does not explain how an activity launches or how a device schedules it. To answer that, follow a call path in the matching revision and consult API documentation. The excerpt is lines 756–761 of core/java/android/app/Activity.java at tag android-14.0.0_r1, checked against that linked source; newer pages or releases may differ.

Compatibility is a contract, not sameness#

Android-compatible devices are expected to meet the applicable Compatibility Definition Document (CDD) requirements and pass the Compatibility Test Suite (CTS). The CDD states requirements; CTS helps check compatibility. These do not make devices visually identical or require optional apps. A maker can customize a product and meet the relevant compatibility bar. AOSP overview: CDD and CTS · Compatibility program

Thus “AOSP build,” “Android-compatible device,” and “phone with Google apps” are not interchangeable. AOSP is a source project; compatibility is requirements plus tests; Google apps and APIs are separately licensed. A product may combine all three, or use Android-derived software without the same services or certification status.

Think like a source reader#

When investigating behavior, ask which layer owns it? A screen layout may belong to an app; permission handling may involve framework APIs and services; a camera may involve a HAL, vendor implementation, and kernel driver. Record Android release, device model, build variant, and whether evidence is public AOSP or vendor-specific. Otherwise, a similar function name can lead to the wrong version or layer.

An AOSP build is compiled platform artifacts for a selected target (device/configuration). An emulator runs a virtual Android device on a development computer. Cuttlefish is a configurable virtual device for platform development and testing; it is not a retail phone or the same tool as the Android Emulator. AOSP terminology · Cuttlefish

Practice#

Context: source-only reading; no host command or device change. Draw the path for a hypothetical app asking to use the camera: app/API → possible framework or system service → hardware-facing interface/vendor implementation → kernel driver/hardware. Mark it “simplified”: a real camera path has more components and is device-specific. Then classify each statement: (a) AOSP includes every retail phone component; (b) GMS is required to call something Android; (c) an app API must execute entirely in the app process. Check your diagram against the explanations above. There is no single camera path asserted here; do not treat this exercise as runtime evidence.

Expected reasoning: (a) false, (b) false, (c) false. If your diagram presents all requests as identical or says a HAL is a driver, revise it. Failure branch: if a term is unfamiliar, use the glossary or linked architecture source; do not infer a device's implementation from this generic diagram.

Knowledge check#

Try to answer before reading Answers.

1. A phone has AOSP-derived code but no Play Store. Is that a contradiction? Explain.
2. An app calls a framework API. What evidence would tell you whether work crosses a process boundary?
3. You find a class with the same name on a newer branch. What context must you check before treating it as the implementation described here?

Answers#

1. No. AOSP and GMS are distinct; GMS is separately licensed and may be absent.
2. Follow the feature's implementation and IPC/service path for the matching release; a framework API call alone does not prove the work runs in-process.
3. Release/tag, device/vendor context, and whether the source is public AOSP or vendor-specific. The Android 14 Activity.java link supports only the pinned declaration, not all runtime behavior.

Checkpoint#

Artifact: your annotated simplified camera-path diagram plus a two-sentence distinction between AOSP, compatibility, and GMS. Ready: the diagram marks where an app request may cross processes and does not claim all phones are identical. Revise: fix any category mix-up using Android architecture. Not yet evidenced: you can repeat definitions but cannot explain a path; revisit “Layers, without memorizing every acronym,” then redraw it. This is a learning check, not device validation.

Sources#

• AOSP overview and terminology — primary AOSP explanation of project scope, compatibility, CDD/CTS, GMS, and terminology.
• Android architecture — primary platform component map; not a trace of every device implementation.
• Android kernel overview — Android's Linux-kernel relationship.
• Binder overview — primary IPC explanation.
• Android Runtime — ART role and runtime concepts.
• AOSP frequently asked questions — open-source scope, Apache 2.0 licensing, and the compatibility program; the FAQ also notes that aosp-main is read-only and new work targets android-latest-release.
• Application fundamentals — app packaging, per-app Linux user IDs, and the sandboxed process model.
• Compatibility program overview — CDD, CTS, and the separate Google Mobile Services licensing context.
• Cuttlefish — configurable virtual device for platform development; compares it with the Android Emulator.
• Android 14 Activity.java — exact source revision for the declaration excerpt (lines 756–761 of the declaration).

Next: Workstation setup.