Android Frameworks Internals

The framework map

When people say "the Android framework" they mean two things together: the system services (Java/Kotlin code that owns activities, windows, packages, power, input and so on) and the SDK API layer that apps call (ActivityManager, PackageManager, PowerManager, ...). Those SDK classes are thin client-side wrappers. The real work happens in other processes, reached over Binder IPC.

The heart of the framework is one privileged process, system_server, which hosts most system services. Around it sit per-app processes forked from Zygote, native daemons (SurfaceFlinger, servicemanager, installd, netd, logd, mediaserver) and, below them, vendor HAL processes that drive the hardware.

Apps (each in its own process, own ART runtime, own Linux UID)
   │  SDK APIs (ActivityManager, PackageManager, PowerManager ...) = thin client proxies
   │  ↕ Binder IPC  (/dev/binder)
system_server  ── AMS/ATMS · WMS · PMS · PowerMS · DisplayMS · InputMS · SensorService · ... (~100 services)
   │  ↕ Binder
Native daemons  ── SurfaceFlinger · servicemanager · installd · netd · logd · mediaserver · lmkd
   │  ↕ stable AIDL HAL (Binder) / legacy HIDL HAL (HwBinder)
Vendor HALs  ── sensors · display (HWC) · audio · power · thermal · radio · camera
   │  ioctl / sysfs / netlink
Kernel drivers  ──▶  hardware

Where the code lives in AOSP

system_server and its key services

system_server is the first Java process Zygote forks at boot. Its SystemServer.run() method creates a SystemServiceManager and starts services in three waves, then tells each service when the system reaches certain boot phases.

1. startBootstrapServices() Services everything else depends on: Installer (connection to installd), ActivityManagerService + ActivityTaskManagerService, PowerManagerService, DisplayManagerService, PackageManagerService, UserManagerService.
2. startCoreServices() Essential but less entangled services: BatteryService, UsageStatsService, WebViewUpdateService, BinderCallsStatsService.
3. startOtherServices() The long tail: WindowManagerService, InputManagerService, AlarmManagerService, ConnectivityService, NotificationManagerService, JobSchedulerService, telephony registry, and many more. Newer releases also have startApexServices() for services shipped in Mainline modules.
4. Boot phases SystemServiceManager.startBootPhase() broadcasts phases such as PHASE_SYSTEM_SERVICES_READY (500), PHASE_ACTIVITY_MANAGER_READY (550), PHASE_THIRD_PARTY_APPS_CAN_START (600) and PHASE_BOOT_COMPLETED (1000). Each service reacts in onBootPhase().
5. systemReady AMS.systemReady() starts persistent apps (SystemUI, the phone process) and launches the Home activity. When Home draws, WMS stops the boot animation and the system user is marked booted: sys.boot_completed=1 is set and ACTION_LOCKED_BOOT_COMPLETED is sent to Direct Boot-aware apps (device-encrypted storage is available). ACTION_BOOT_COMPLETED is sent later, after the user unlocks credential-encrypted (CE) storage. On a device with no lock screen the two broadcasts can fire in quick succession; they are not the same event. See boot and FBE.

How SurfaceFlinger relates

SurfaceFlinger is not inside system_server. It is a native daemon started by init. WMS decides policy (which window is where, which is on top, which gets focus) and sends layer changes to SurfaceFlinger via SurfaceControl.Transaction. Apps render into buffers (via a BufferQueue / BLASTBufferQueue) and SurfaceFlinger composes all layers, using the Hardware Composer (HWC) HAL, onto the display at each vsync.

App RenderThread ──buffers──▶ BufferQueue ──▶ SurfaceFlinger ──▶ HWC HAL ──▶ panel
                                                  ▲
WMS (system_server) ──SurfaceControl transactions─┘  (position, z-order, visibility)

Zygote and how an app process starts

Zygote is a process started by init from init.zygote64.rc (or init.zygote64_32.rc on mixed 64/32 devices) via the app_process64 binary. The init service name is always zygote, even on 64-bit devices; the "64" is the rc file and the binary, not the service. It boots the ART runtime once, preloads the classes listed in /system/etc/preloaded-classes, common resources, shared libraries and graphics drivers, then waits for fork requests on a Unix domain socket (/dev/socket/zygote). On mixed-ABI devices a second service named zygote_secondary runs app_process32 and listens on /dev/socket/zygote_secondary.

1. init starts Zygote app_process → AndroidRuntime.start() → ZygoteInit.main().
2. Preload Classes, resources, libandroid, EGL/Vulkan drivers, WebView resources. This takes seconds, but only once per boot.
3. Fork system_server forkSystemServer() creates the system_server child with UID 1000 (system).
4. Select loop ZygoteServer.runSelectLoop() waits on the socket for "start a process" commands.
5. Fork and specialize For each request, Zygote.forkAndSpecialize() calls fork(), then the child sets its UID/GIDs, SELinux context, seccomp filter, mount namespace, cgroups and nice value, and calls the requested entry class, normally android.app.ActivityThread.main().

init
 └─ zygote (app_process64)          preload ART + classes + resources
     ├─ fork ─▶ system_server        (uid 1000)
     ├─ fork ─▶ com.android.systemui (persistent)
     ├─ fork ─▶ com.android.phone    (persistent)
     └─ fork ─▶ com.example.app      (uid 10xxx)   ...one per app process

Related Zygote features

• USAP pool (Unspecialized App Process, Android 10): Zygote pre-forks a few processes so the fork cost is paid ahead of time.
• WebView zygote and app zygote: separate zygotes for isolated WebView renderer processes and for apps that want to preload their own code for isolated services.
• 64/32-bit zygotes: the primary init service is named zygote and runs app_process64. A 32-bit helper, if present, is the separate service zygote_secondary (not zygote32 and not a second service also called zygote). 32-bit-only devices use a single zygote running app_process32.

From fork to a running app

AMS / ATMS: startActivity()  ─ process for this app exists? ─ no ─▶
  ProcessList.startProcessLocked()
    → Process.start() → ZygoteProcess writes args to /dev/socket/zygote
      → Zygote: forkAndSpecialize()      child pid returned to AMS
        → child: RuntimeInit → ActivityThread.main()
          → Looper.prepareMainLooper()
          → ActivityThread.attach() → IActivityManager.attachApplication(appThread)   (Binder)
            → AMS: bindApplication() back to the app (via IApplicationThread)
              → app: create Application, install ContentProviders, Application.onCreate()
            → ATMS: realStartActivityLocked() → ClientTransaction (LaunchActivityItem, ResumeActivityItem)
              → app: Activity.onCreate / onStart / onResume
          → Looper.loop()   (main thread now serves messages forever)

Two Binder interfaces make this a two-way conversation: the app calls AMS through IActivityManager, and AMS calls back into the app through IApplicationThread, a Binder object the app hands over in attachApplication(). The app's ActivityThread.H Handler turns those callbacks into main-thread messages.

Cold, warm and hot app start

App startup time is a core performance KPI. Android distinguishes three start types based on how much state already exists.

Metrics and how to measure

• TTID (time to initial display): from launch intent to the first frame. Logged by the system as ActivityTaskManager: Displayed com.example/.MainActivity: +480ms.
• TTFD (time to full display): until the app calls reportFullyDrawn() after loading its real content.
• adb shell am start -W -n com.example/.MainActivity prints LaunchState (COLD/WARM/HOT), TotalTime and WaitTime.
• Perfetto has an app-startup track showing bindApplication, activityStart, inflate, Choreographer#doFrame and Binder/lock waits on the main thread.

adb shell am force-stop com.example
adb shell am start -W -n com.example/.MainActivity
# Status: ok
# LaunchState: COLD
# Activity: com.example/.MainActivity
# TotalTime: 612
# WaitTime: 630

What makes startup slow, and fixes

The four app components and their lifecycles

An app is a set of components declared in AndroidManifest.xml. The system, not the app, instantiates them and drives their callbacks, which always run on the app's main thread (except ContentProvider data calls, which run on Binder threads).

Activity

onCreate → onStart → onResume → [RUNNING, in foreground]
                         ▲             │ another activity comes in front
                         │             ▼
                     onResume ◀──── onPause ──▶ onStop ──▶ onDestroy
                                               │    ▲
                                  (user returns)└─▶ onRestart → onStart

• onCreate: inflate UI, restore state. onStart: visible. onResume: in foreground and interactive.
• onPause must be quick: the next activity is not resumed until it returns. onStop: no longer visible; release heavier resources.
• Configuration change (rotation, locale, font size, dark mode): by default the activity is destroyed and recreated. Keep state in a ViewModel (survives config change) and onSaveInstanceState / SavedStateHandle (survives process death).
• Lifecycle is driven from ATMS through ClientTransaction items (LaunchActivityItem, ResumeActivityItem, PauseActivityItem, ...) sent over IApplicationThread.

Service

onStartCommand return values control restart after a kill: START_STICKY (recreate, null intent), START_NOT_STICKY (do not recreate), START_REDELIVER_INTENT (recreate and redeliver the last intent). For deferrable work, WorkManager/JobScheduler is preferred over long-running services.

BroadcastReceiver

• Manifest-declared receivers can start the app; since Android 8.0 most implicit broadcasts can no longer be received this way (exceptions such as BOOT_COMPLETED, LOCALE_CHANGED).
• Context-registered receivers (registerReceiver) live as long as the registering context. Android 14 requires RECEIVER_EXPORTED/RECEIVER_NOT_EXPORTED flags.
• onReceive() runs on the main thread and must finish within the broadcast timeout (10 s foreground queue, 60 s background queue). For longer work, call goAsync() and finish quickly on another thread, or hand off to WorkManager.
• Ordered broadcasts go to receivers one by one by priority, each can modify or abort; normal broadcasts are delivered to all receivers without ordering guarantees.
• A process that is only running a receiver is considered foreground during onReceive, then drops in priority right after.

ContentProvider

• Exposes structured data through content://authority/path URIs with query/insert/update/delete and openFile.
• onCreate() runs on the main thread before Application.onCreate(), during bindApplication. Slow providers slow every cold start.
• Data methods are called on Binder threads, so the implementation must be thread-safe.
• Large results move through CursorWindow backed by shared memory (ashmem), avoiding the Binder transaction size limit.
• Access control: android:readPermission/writePermission, exported, and temporary URI grants (FLAG_GRANT_READ_URI_PERMISSION).
• If a client is using a provider, AMS links their lifetimes: the provider's process priority is raised, and if the provider process dies, a client holding a stable reference is killed too.

Process priority, oom_adj, LMKD and PSI

Android keeps processes alive after the user leaves them, as a cache, so returning to an app is a hot or warm start. When memory runs low, something must be killed. AMS decides how important each process is; LMKD (the Low Memory Killer Daemon) decides when to kill and picks the least important victim.

Importance levels

AMS recomputes these values in OomAdjuster.updateOomAdjLocked() whenever something relevant happens (activity resumed, service bound, broadcast delivered) and writes them to /proc/<pid>/oom_score_adj. Bindings propagate importance: if a foreground app binds to your service with BIND_AUTO_CREATE, your process is raised close to the client's level. AMS also tracks a separate process state (PROCESS_STATE_TOP, FOREGROUND_SERVICE, CACHED_EMPTY, ...) used for scheduling groups, network and background restrictions.

LMKD and PSI

• The old in-kernel lowmemorykiller driver (static free-memory thresholds) was removed from mainline Linux in 4.12. Android moved killing to userspace lmkd.
• Since Android 10, lmkd uses PSI (Pressure Stall Information) monitors on /proc/pressure/memory. PSI measures the share of time tasks are stalled waiting for memory (reclaim, refaults), which is a much better signal than "free pages below X".
• When stall time crosses thresholds, lmkd picks a victim with the highest oom_score_adj (and largest footprint within that band) and kills it with SIGKILL (via pidfd). Tuning is via ro.lmk.* properties (for example ro.lmk.psi_partial_stall_ms, ro.lmk.swap_free_low_percentage).
• The kernel OOM killer is the last resort if lmkd fails to free memory in time.
• zRAM (compressed swap in RAM) and kswapd reclaim soften pressure before kills.
• Cached apps freezer: introduced in Android 11 as an opt-in feature and turned on by default later (around Android 12L/13, via cached_apps_freezer). Cached processes are frozen with the cgroup v2 freezer so they use no CPU. A synchronous Binder call to a frozen process fails immediately (the driver returns BR_FROZEN_REPLY; the caller sees a frozen or dead-object style error). The call does not unfreeze the target. Oneway (async) transactions are queued in the driver until AMS unfreezes the process because it became important again (activity, broadcast, bind).

adb shell dumpsys activity processes     # oom_adj, procstate, LRU list
adb shell dumpsys activity lru            # compact LRU with adj values
adb shell cat /proc/pressure/memory       # some avg10=0.52 ... full avg10=0.10 ...
adb logcat -b events | grep am_kill       # AMS kills
adb logcat -s lowmemorykiller             # lmkd kill reports

Handler, Looper and MessageQueue

Almost every framework thread that handles events (the app main thread, and most system_server threads) runs the same pattern: a Looper loops forever, pulling Messages from a MessageQueue and dispatching each one to its target Handler. This keeps UI code single-threaded and event-driven, so views need no locks.

// Simplified Looper.loop()
for (;;) {
    Message msg = queue.next();        // blocks in nativePollOnce() → epoll_wait()
    if (msg == null) return;           // queue quit
    msg.target.dispatchMessage(msg);   // target is the Handler
    msg.recycleUnchecked();            // back to the global Message pool
}

// Handler.dispatchMessage order:
// 1. msg.callback (the Runnable from post())
// 2. Handler's mCallback.handleMessage()
// 3. Handler subclass handleMessage()

How the queue sleeps without busy-waiting

MessageQueue.next() calls nativePollOnce(ptr, timeout), which runs epoll_wait() on an eventfd (older releases used a pipe). The timeout equals the delay until the next message is due, or infinite if empty. Enqueueing a message that becomes the new head calls nativeWake(), which writes to the eventfd and wakes the thread. The same epoll set can also watch other file descriptors, which is how input events (the InputChannel socket) and vsync signals are delivered into the main Looper.

Why Looper.loop() does not itself cause an ANR

The main thread sits in an infinite for (;;) loop for the life of the process. That is not a busy-wait and it is not an ANR. While the queue is empty (or the next message is in the future) the thread is asleep in the kernel inside epoll_wait, using no CPU. An ANR is raised only when the system handed the app a specific piece of work (input, broadcast, service start, provider publish) and that work was not acknowledged before a deadline. The idle loop is waiting to do that work; it is not failing to do it. What does cause an ANR is a single message that runs too long, so later messages (including "I finished this input event") never run in time.

Advanced queue features

• Sync barrier: a message with a null target. While it is at the head, normal (synchronous) messages are held back and only asynchronous messages run. ViewRootImpl.scheduleTraversals() posts a barrier so the next frame's traversal, posted as async by Choreographer, runs before other queued work.
• IdleHandler: queue.addIdleHandler() runs a callback when the queue is empty, useful for deferred low-priority init.
• HandlerThread: a ready-made Thread with its own Looper, used widely in system_server (android.fg, android.io, etc.) and for serial background work in apps.
• Choreographer: receives vsync from SurfaceFlinger (via DisplayEventReceiver) and runs input, animation, traversal and commit callbacks on the main Looper, once per frame (16.6 ms at 60 Hz, 11.1 ms at 90 Hz).
• Looper.setMessageLogging() and Looper slow-dispatch logs ("Slow dispatch took ...ms") help find long messages; tools like BlockCanary use the same hook.

Binder threads are different

Incoming Binder calls do not run on the main Looper. Each process has a Binder thread pool (by default up to 15 extra threads plus the main Binder thread; system_server raises the limit to 31). A service implementing a Binder method must therefore be thread-safe and fast, and must post to a Handler if it needs to touch main-thread state. Details are in Binder IPC & AIDL.

ANR detection and debugging

An ANR (Application Not Responding) is raised when an app fails to finish a specific piece of work within a deadline, almost always because its main thread is blocked. The framework arms a timer when it hands work to the app and disarms it when the app reports completion. If the timer fires first, the ANR path runs.

What happens when an ANR fires

1. Detection InputDispatcher or AMS notices the deadline has passed and calls into AnrHelper / ProcessErrorStateRecord.appNotResponding().
2. Evidence capture The system sends SIGQUIT (signal 3) to the app and to key processes (system_server, related native processes). ART's signal catcher thread dumps all Java thread stacks; native stacks are collected via debuggerd.
3. Trace files Stacks are written to /data/anr/anr_<timestamp> files (older releases used a single /data/anr/traces.txt). CPU usage is logged to logcat, and the event goes to am_anr in the events log and DropBox (data_app_anr).
4. User handling A foreground app shows the "App isn't responding" dialog; background ANRs are usually killed silently.

Debug flow

1. Get the evidence adb bugreport (includes ANR files, logcat, dumpsys) or adb pull /data/anr/. Note the ANR reason line, e.g. "Input dispatching timed out" or "executing service".
2. Read the main thread first Find "main" prio=5 tid=1. Its state tells you the class of problem: Blocked (waiting for a monitor held by another thread), Waiting/TimedWaiting, Native (often inside a Binder call or I/O), Runnable (busy computing).
3. Follow the chain If blocked on a lock, the dump says "waiting to lock <0x...> held by thread N". Read thread N. If in BinderProxy.transact, find which process and thread served the call (system_server stacks are in the same dump, or use /sys/kernel/debug/binder/ state).
4. Check the environment CPU load at the time ("CPU usage from ..." in logcat), memory pressure and lmkd kills, iowait, thermal throttling. An idle main thread with high system load points to starvation, not app code.
5. Fix and prevent Move I/O and heavy work off the main thread, avoid synchronous Binder calls to slow services from the UI thread, shrink lock scopes, and add StrictMode and ANR-rate regression gates.

"main" prio=5 tid=1 Blocked
  | group="main" sCount=1 ucsCount=0 flags=1 obj=0x72f1a0c8 self=0xb400...
  | sysTid=4821 nice=-10 cgrp=top-app sched=0/0 handle=0x7f...
  at com.example.cache.Store.get(Store.java:88)
  - waiting to lock <0x0a1b2c3d> (a java.lang.Object) held by thread 23
  at com.example.ui.MainActivity.onResume(MainActivity.java:52)
  ...
"DiskWriter" prio=5 tid=23 Native
  at java.io.FileOutputStream.write(Native method)
  at com.example.cache.Store.flush(Store.java:120)
  - locked <0x0a1b2c3d> (a java.lang.Object)

Here the main thread waits for a lock that a background thread holds while doing disk I/O. The fix is not "make the disk faster" but "never hold the shared lock during I/O".

The system_server watchdog

ANRs protect against unresponsive apps. The Watchdog (com.android.server.Watchdog) protects against an unresponsive system_server. If a core service thread or lock is stuck, the whole device would freeze, so the watchdog kills system_server and forces a framework restart instead.

1. Checkers The watchdog thread owns a list of HandlerCheckers, one per critical thread (main, android.fg, android.ui, android.io, android.display, android.anim, ...). Services can also register monitors (Watchdog.Monitor) whose monitor() method simply grabs and releases their main lock (AMS, WMS, PowerManager, InputManager do this).
2. Probe Every half-timeout (30 s by default) it posts a check message to each thread. The foreground checker also runs all monitors.
3. Half-way dump If a checker has not completed after 30 s, the watchdog dumps stacks as an early warning.
4. Kill After the full timeout (60 s by default), it dumps stacks of system_server and important native processes to /data/anr, logs WATCHDOG KILLING SYSTEM PROCESS: Blocked in handler on ... / Blocked in monitor ..., writes a DropBox entry, and kills system_server.
5. Recovery Because system_server is Zygote's child and critical, Zygote restarts, all apps die, and the framework boots again (a soft reboot). Repeated crashes of critical processes during boot can trigger rescue party / recovery mode.

W Watchdog: *** WATCHDOG KILLING SYSTEM PROCESS: Blocked in monitor
    com.android.server.am.ActivityManagerService on foreground thread (android.fg),
    Blocked in handler on main thread (main)
W Watchdog: foreground thread stack trace:
W Watchdog:     at com.android.server.am.ActivityManagerService.monitor(...)
W Watchdog:     - waiting to lock <0x0c3a...> (a com.android.server.am.ActivityManagerService)
    held by thread 112 (Binder:1234_7)

Triage is the same as an ANR: find the thread named in the message, find the lock it waits for, find the owner thread (often a Binder thread stuck in an outgoing call to a HAL or another process, or a deadlock between two service locks such as AMS and WMS), and fix the lock ordering or move the slow call out of the locked region.

PackageManager, the app sandbox and permissions

PackageManagerService (PMS) knows every installed package: its components, intent filters, signatures, permissions, UID and code paths. At boot it scans /system/app, /system/priv-app, /product, /vendor, /system_ext, APEX modules and /data/app, then restores state from /data/system/packages.xml. A slow scan shows up directly in boot time.

Install flow

1. Session An installer (Play Store, adb install, pm install) opens a PackageInstaller session and streams the APK(s) into a staging directory.
2. Parse PMS parses AndroidManifest.xml (PackageParser2): package name, version, components, permissions, SDK levels, native ABIs.
3. Verify Checks the signature (APK Signature Scheme v2/v3/v4 over the whole file). An update must be signed by the same certificate (or a rotated one via v3 lineage) or it fails with INSTALL_FAILED_UPDATE_INCOMPATIBLE. Package verifiers may also run.
4. Assign identity A new app gets an app ID (10000+). Its Linux UID is userId * 100000 + appId, so the same app has a different UID per Android user or work profile.
5. Prepare files Through installd (a privileged native daemon) PMS creates /data/data/<pkg> (really /data/user/<id>/<pkg>), extracts native libs, and triggers dexopt (dex2oat, now via artd) guided by profiles.
6. Commit Components are registered for intent resolution, permissions are granted as appropriate, packages.xml is written, and ACTION_PACKAGE_ADDED/REPLACED is broadcast.

Intent resolution

Explicit intents name the component class directly. Implicit intents describe an action, data URI/type and categories; PMS matches them against registered intent filters (queryIntentActivities) and the system shows a chooser or uses a default. Since Android 11, package visibility rules filter what an app can even see unless it declares <queries>.

Sandbox and permission model

• UID sandbox (DAC): each app is its own Linux user, so its files and processes are isolated by normal kernel permission checks.
• SELinux (MAC): every process has a domain (untrusted_app, platform_app, system_server, hal_radio_default, ...). Policy decides which files, sockets and Binder services each domain may use, including binder_call and service_manager find rules. Denials appear as avc: denied in logcat/dmesg and are a very common integration snag.
• Android permissions are checked in the framework, usually in the service's Binder method with the caller's UID.

// Typical enforcement inside a system service Binder method
@Override
public void setSomething(int value) {
    mContext.enforceCallingOrSelfPermission(
            android.Manifest.permission.MODIFY_PHONE_STATE, "setSomething");
    final int uid = Binder.getCallingUid();
    final long token = Binder.clearCallingIdentity();
    try {
        doWorkAsSystem(value);   // now runs with system_server's identity
    } finally {
        Binder.restoreCallingIdentity(token);
    }
}

Permission grant state and runtime checks were split out of PMS into PermissionManagerService gradually across Android 10–12 (the service exists from 10; more of the store and the check path moved in 11–12). PMS remains the entry point for package state. Missing entries in the privapp allowlist are a frequent boot failure on new builds: the device logs "Privileged permission ... not in privapp-permissions allowlist" and may refuse to boot if enforcement is on.

The framework to HAL boundary: Treble, HIDL, AIDL and VINTF

Before Android 8.0, the framework loaded vendor HAL libraries directly (hw_get_module() opening .so files in-process). Upgrading Android meant the SoC vendor had to rebuild every HAL for the new framework. Project Treble (Android 8.0) split the OS into a system side (AOSP framework, updatable) and a vendor side (SoC/OEM HALs and kernel), connected only by stable, versioned HAL interfaces over IPC.

system partition (framework, updated by Android release)
   system_server services, e.g. SensorService, RIL.java in the phone process
        │  stable AIDL HAL (versioned, frozen, declared in VINTF)
        │  ↕ /dev/binder  (legacy HIDL: /dev/hwbinder via hwservicemanager)
vendor partition (SoC / OEM, updated on its own schedule)
   HAL service process, e.g. android.hardware.sensors-service, vendor radio daemon
        │  ioctl / sysfs / QMI / shared memory
kernel driver ──▶ hardware / DSP / modem

Evolution of HAL interfaces

The three Binder domains

The wire-level details of these domains are covered in Binder IPC & AIDL.

VINTF: checking that system and vendor fit together

• The device manifest (/vendor/etc/vintf/manifest.xml plus fragments) lists which HALs and versions the vendor image provides, e.g. android.hardware.radio.voice.IRadioVoice/slot1, version 2.
• The framework compatibility matrix lists which HALs and versions the framework requires or can use.
• Symmetrically, the framework manifest and device compatibility matrix describe what the system provides and what the vendor needs.
• VintfObject checks compatibility at build time, during OTA and at boot. servicemanager also refuses to register a @VintfStability service that is not declared in the manifest.
• VNDK is the set of system libraries vendor code may link against with a stable ABI; GSI (Generic System Image) plus VTS tests prove a vendor image works with a pure AOSP system image.

Starting HAL services

HAL services are declared in vendor init.rc files with an interface line. Many are lazy: servicemanager asks init to start them on first lookup (ctl.interface_start) and they may exit when unused. A classic bring-up bug: VINTF declares a HAL but no matching init.rc service exists, so the lookup waits forever and the framework sees a null proxy ("no radio", "no sensors"), which looks like a hardware fault but is a configuration error.

# vendor init.rc fragment
service vendor.radio-default /vendor/bin/hw/android.hardware.radio-service.example
    class hal
    user radio
    group radio inet misc
    interface aidl android.hardware.radio.voice.IRadioVoice/slot1
    interface aidl android.hardware.radio.data.IRadioData/slot1

dumpsys and the framework debugging toolbox

dumpsys asks a Binder service to write its internal state: it looks the service up in servicemanager and calls its dump() method (protected by the DUMP permission). Knowing which dump answers which question is how you localize a systemic issue quickly.

Beyond dumpsys

• Perfetto (and legacy systrace): timeline of CPU scheduling, thread states, Binder transactions, main thread and RenderThread slices, memory counters. The best tool for jank, startup and ANR root cause.
• bugreport: adb bugreport bundles logcat, all dumpsys output, ANR/tombstone files, kernel log and system properties.
• logcat buffers: main, system, events (am_proc_start, am_kill, am_anr, wm_on_resume_called), crash, radio.
• Stack dumps on demand: kill -3 <pid> for Java stacks, debuggerd -b <pid> for native backtraces.
• am / cmd: am start -W, am force-stop, am kill, cmd package, cmd activity.
• Tombstones in /data/tombstones/ for native crashes; DropBox (dumpsys dropbox) for system_server crashes, ANRs and watchdogs.

Launch modes, tasks and task affinity

ATMS does not start a new activity in isolation. It places the activity in a task (a back stack the Recents screen shows as one card) according to the launch mode on the activity, the flags on the incoming Intent, and android:taskAffinity. Getting this wrong is a frequent source of "two copies of my activity" and "Back does not do what I expect" bugs.

Intent flags that override the manifest

• FLAG_ACTIVITY_NEW_TASK: start in a new task (required when starting an activity from a non-Activity context).
• FLAG_ACTIVITY_CLEAR_TOP: if the activity already exists in the task, finish everything above it and reuse it (onNewIntent).
• FLAG_ACTIVITY_SINGLE_TOP: same as singleTop for this launch only.
• FLAG_ACTIVITY_CLEAR_TASK + NEW_TASK: replace the whole task with this activity (common from notifications and shortcuts).
• FLAG_ACTIVITY_REORDER_TO_FRONT: bring an existing instance forward without clearing what is above it in the stack history.

Task affinity

android:taskAffinity is a string (default: the package name) that names which task an activity wants to belong to. It matters when combined with allowTaskReparenting, FLAG_ACTIVITY_NEW_TASK, or singleTask: ATMS can move the activity into (or start) a task whose affinity matches. Two activities with different affinities can therefore live in two Recents cards even though they are in the same app. A common OEM bug is giving a system activity the wrong affinity so it appears as a stray Recents entry or steals the back stack of another app.

Launcher starts MainActivity (standard, affinity = com.example)
  → task T1: [Main]
Main starts SettingsActivity (standard)
  → task T1: [Main, Settings]
Notification fires with NEW_TASK | CLEAR_TASK → MainActivity
  → task T1 replaced: [Main]     (Settings finished)
singleTask RootActivity already exists under T2
  → T2 brought forward; activities above Root cleared; onNewIntent()

Activity vs Application context, window tokens and BadTokenException

A Context is not "the app". There are several implementations with different lifetimes and different abilities. Using the wrong one is a classic source of leaks and of WindowManager$BadTokenException.

Window tokens

Every window WMS will accept must be associated with a window token (IBinder) that WMS already knows about: an activity's token (created when ATMS starts the activity), an application token, or a special token for system windows (TYPE_APPLICATION_OVERLAY and friends, gated by SYSTEM_ALERT_WINDOW). The token is how WMS ties a ViewRootImpl / SurfaceControl to a task, decides focus, and knows when to remove the windows (activity finish → token removed → windows gone).

BadTokenException: Unable to add window -- token null is not valid (or "token is not valid; is your activity running?") means you asked WindowManager.addView() (a Dialog, a PopupWindow, a Toast on older releases, a custom overlay) with a token WMS does not accept: typically an Application context, or an Activity that has already finished / whose window is not yet attached (onCreate before onAttachedToWindow, or after onDestroy).

• Show dialogs from the Activity, after it is resumed, and dismiss them in onDestroy.
• Never store an Activity in a static field or a long-lived singleton; that leaks the whole window.
• For process-wide work use getApplicationContext(). For UI that needs a theme or a token, use the Activity.
• LayoutInflater from the Application context will not apply the activity theme; inflate from the Activity (or a ContextThemeWrapper).

Background restrictions and PendingIntent mutability

Each recent Android release tightened what a background app may do. Interviewers expect the timeline, not a vague "background is restricted".

PendingIntent.FLAG_IMMUTABLE (Android 12+)

A PendingIntent is a token another process (NotificationManager, AlarmManager, App Widget host, another app) can send later, acting as your app. Until Android 12 the extras and component on that Intent could be filled in by the holder. That is a confused-deputy hole: a malicious app that received your mutable PendingIntent could retarget it. From Android 12, creating a PendingIntent without FLAG_IMMUTABLE or FLAG_MUTABLE throws IllegalArgumentException on apps targeting 12+.

• Use FLAG_IMMUTABLE unless you genuinely need the holder to fill in extras (inline reply on a notification, a mutable widget click). Almost all notification and alarm PendingIntents should be immutable.
• Immutability is about the Intent identity (component, action, extras the sender is allowed to change), not about whether the PendingIntent can be sent more than once.
• Combine with FLAG_UPDATE_CURRENT or FLAG_CANCEL_CURRENT as needed; those flags are orthogonal.

PendingIntent pi = PendingIntent.getActivity(
        context, 0, intent,
        PendingIntent.FLAG_UPDATE_CURRENT | PendingIntent.FLAG_IMMUTABLE);

How to add a system service

A platform interview often asks you to add a first-party service that apps reach through a manager class. The pieces are always the same; missing any one of them is a bring-up failure.

1. AIDL Define IFooService.aidl under frameworks/base/core/java (or an APEX). The build generates Stub and Proxy. Hide it from the public SDK if it is privileged (@hide or a SystemApi).
2. SystemService subclass Implement com.android.server.foo.FooService extending SystemService (or a raw Binder if it is a very old-style service). In onStart() construct the Binder implementation and call publishBinderService("foo", mBinder), which is ServiceManager.addService() with extra bookkeeping.
3. SystemServer Start it in the right wave: bootstrap only if something in bootstrap needs it; otherwise startOtherServices(). Optionally react to boot phases in onBootPhase().
4. Manager and Context.getSystemService Add a public FooManager that looks up the Binder (ServiceManager.getService("foo") / IFooService.Stub.asInterface) and caches it. Register the manager in SystemServiceRegistry so apps call context.getSystemService(FooManager.class).
5. SELinux Add a service name in service_contexts (label e.g. foo_service), allow system_server to add it, and allow client domains (platform_app, priv_app, untrusted_app as appropriate) to find and binder_call. Without this, addService or getService fails with avc: denied.
6. Permission and identity In every Binder method, enforceCallingPermission (or AppOps) and wrap privileged work in clearCallingIdentity / restoreCallingIdentity.
7. Dump and tests Implement dump() for dumpsys foo, and add CTS or unit tests against the AIDL.

IFooService.aidl  →  FooService (system_server thread)  →  publishBinderService("foo")
                                                              │
apps / FooManager  ←── ServiceManager.getService("foo")  ←────┘
SELinux: service_contexts + binder_call / service_manager add|find

Vendor HALs are a different path (VINTF + init.rc interface aidl + NDK registration). Do not confuse "add a framework service" with "add a HAL". See Binder registration and the HAL boundary.

trimMemory, onLowMemory and ApplicationExitInfo

The framework does not only kill processes. It also asks them to shrink, and after a death it records why they died so you are not guessing from logcat alone.

onTrimMemory vs onLowMemory

Neither callback runs if the process is frozen or if lmkd sends SIGKILL. Design caches so losing the process is safe, and use onTrimMemory to make a kill less likely.

ApplicationExitInfo (Android 11+)

After a process dies, AMS keeps a ring buffer of ApplicationExitInfo records per package, readable via ActivityManager.getHistoricalProcessExitReasons() (and dumpsys activity exit-info). Each record has a reason, a status, a description, a timestamp, the pid, and sometimes a trace (ANR) or tombstone fd.

This is the first tool for "why did my process die?" — better than scraping am_kill by hand. Combine it with dumpsys activity lru (who was cached) and Perfetto (what memory was doing).

Quick revision

• Stack: apps → (Binder) → system_server services → native daemons → (stable AIDL / HIDL) vendor HALs → kernel drivers.
• system_server hosts AMS, ATMS, WMS, PMS, PowerMS, DisplayMS, InputMS, SensorService and about 100 more; if it dies the framework soft-reboots.
• SystemServer starts services in waves: bootstrap, core, other (and APEX); services react to boot phases up to PHASE_BOOT_COMPLETED (1000).
• ATMS (activities, tasks) was split from AMS (processes, services, broadcasts, providers) in Android 10.
• SurfaceFlinger is a separate native process; WMS sets window policy and sends SurfaceControl transactions to it.
• Zygote preloads ART, classes and resources, then forks every app process; pages are shared copy-on-write.
• Zygote uses a Unix socket, not Binder, because forking a multithreaded process is unsafe.
• New app process runs ActivityThread.main(), prepares the main Looper, calls attachApplication(); AMS calls back through IApplicationThread.
• Cold start = no process; warm = process alive, activity recreated; hot = activity just resumed.
• Measure startup with am start -W, the "Displayed" log (TTID), reportFullyDrawn() (TTFD) and Perfetto.
• ContentProvider onCreate runs before Application.onCreate; provider data calls run on Binder threads.
• Activity lifecycle: onCreate, onStart, onResume, onPause, onStop, onDestroy (onRestart when returning); config change recreates by default.
• Services: started, foreground (must call startForeground() within a few seconds; the timeout is 5 s or 10 s depending on the release), bound (returns an IBinder).
• onReceive() runs on the main thread; use goAsync() for short async work, WorkManager for long work.
• AMS computes oom_score_adj (0 foreground ... 900-999 cached) in OomAdjuster; bindings raise the server's priority.
• lmkd is a userspace daemon using PSI (/proc/pressure/memory) to decide when to kill; kills the highest adj first.
• Cached apps can be frozen with the cgroup v2 freezer (feature in Android 11, default-on later); a sync Binder call to a frozen process fails with BR_FROZEN_REPLY and does not unfreeze it; oneway is queued. The kernel OOM killer is the last resort.
• Looper loops over a time-sorted MessageQueue; next() sleeps in epoll_wait on an eventfd, so no busy-waiting.
• Sync barriers let Choreographer's asynchronous frame messages jump ahead of normal messages.
• Binder calls run on the Binder thread pool (15 + 1 by default, 31 in system_server), never on the main Looper.
• ANR timeouts: input 5 s, broadcast 10 s fg / 60 s bg, service 20 s fg / 200 s bg, provider publish 10 s.
• Input ANRs are detected by native InputDispatcher; broadcast/service ANRs by AMS.
• On ANR the system sends SIGQUIT and writes stacks to /data/anr/anr_* (formerly traces.txt); read the main thread first.
• Main causes of ANRs: main-thread I/O, lock contention/deadlock, slow synchronous Binder calls, system starvation.
• The Watchdog checks key system_server threads and monitor locks every 30 s; blocked 60 s means it kills system_server.
• PMS parses manifests, verifies signatures, assigns UID = userId * 100000 + appId, and uses installd/artd for files and dexopt.
• Permission levels: normal, dangerous (runtime), signature, privileged (allowlisted), special/appop.
• Services check callers with Binder.getCallingUid(); wrap system work in clearCallingIdentity()/restoreCallingIdentity().
• Sandbox = per-app UID (DAC) plus SELinux domains (MAC); avc: denied logs show policy blocks.
• Treble (8.0) separates system and vendor via stable HAL interfaces; HIDL (hwbinder) is legacy, stable AIDL (binder) is current.
• Binder domains: /dev/binder (framework, AIDL HALs), /dev/hwbinder (HIDL), /dev/vndbinder (vendor to vendor).
• VINTF manifests and compatibility matrices must match; lazy HAL declared in VINTF without an init.rc entry gives a null proxy forever.
• Key dumps: activity, window, input, SurfaceFlinger, gfxinfo, package, power, batterystats, meminfo; Perfetto for timelines.
• Launch modes: standard, singleTop, singleTask, singleInstance (plus singleInstancePerTask); Intent flags can override; taskAffinity names the preferred task.
• Application context has no window token; dialogs and addView need an Activity token or you get BadTokenException.
• Background timeline: 8 implicit-broadcast / background-service limits; 12 FGS-from-background and PendingIntent mutability; 13 notification permission; 14 FGS types.
• PendingIntent on apps targeting 12+ must set FLAG_IMMUTABLE or FLAG_MUTABLE; prefer immutable.
• Adding a system service: AIDL, SystemService, publishBinderService, SystemServer start site, manager + SystemServiceRegistry, SELinux service_contexts, permission checks.
• Looper.loop() sleeps in epoll_wait when idle; the infinite loop is not an ANR. ANR is a missed deadline on work the system handed you.
• onTrimMemory is the real cache-trim callback (with levels); onLowMemory is a legacy last-ditch hook and is not guaranteed before a kill.
• ApplicationExitInfo (Android 11+) is the first place to look for why a process died (LMK, ANR, crash, dependency, self-exit).

Glossary

ActivityThread

The class whose main() is the entry point of every app process; owns the main Looper and handles lifecycle messages from the system.

AMS (ActivityManagerService)

System service managing processes, services, broadcasts, providers, oom_adj scoring and several ANR types.

ANR

Application Not Responding: raised when an app misses a deadline for input, a broadcast, a service or a provider.

ApplicationExitInfo

Per-package record of why a process died (reason, status, optional ANR/tombstone), from Android 11.

APEX

Container format for updatable system components (Mainline modules), mounted at boot.

ATMS (ActivityTaskManagerService)

Service managing activities, tasks and the back stack; split from AMS in Android 10.

BadTokenException

WMS rejected addView because the window token is null, finished, or not an Activity/system token.

Binder thread pool

Threads in each process that execute incoming Binder calls; default maximum 15 plus the main Binder thread.

Choreographer

Per-thread coordinator that runs input, animation and drawing callbacks once per vsync.

Cold / warm / hot start

App starts that need a new process, a new activity in an existing process, or only a resume, respectively.

Copy-on-write (COW)

Memory pages shared after fork until one side writes, at which point that page is copied.

dexopt

Ahead-of-time compilation of app dex code to native code (dex2oat), guided by profiles.

dumpsys

Tool that calls a Binder service's dump() to print its internal state.

eventfd

Linux kernel object used as a lightweight wake-up signal; MessageQueue sleeps on it through epoll.

FLAG_IMMUTABLE

PendingIntent flag (required to choose mutability from Android 12) that prevents the holder from changing the Intent.

Handler

Object bound to a Looper that enqueues Messages/Runnables and handles them on that Looper's thread.

HandlerThread

A Thread that creates its own Looper, used for serialized background work.

HIDL

HAL Interface Definition Language (Android 8-12), carried over hwbinder; now deprecated in favour of stable AIDL.

IApplicationThread

Binder interface an app gives AMS so the system can call back into the app (bind, launch, pause, trim memory).

InputDispatcher

Native thread in system_server that sends input events to windows and detects input ANRs.

installd

Privileged native daemon that performs file operations for PMS (create data dirs, dexopt triggers, delete).

Launch mode

Manifest (or Intent-flag) rule for whether ATMS creates a new activity instance and which task it joins.

lmkd

Low Memory Killer Daemon; userspace process that kills apps under memory pressure using PSI signals.

Looper

Per-thread loop that takes Messages from a MessageQueue and dispatches them.

MessageQueue

Time-ordered list of Messages for one Looper, with native blocking via epoll.

oom_score_adj

Per-process value (-1000 to 1000) in /proc/<pid>/ set by AMS; higher means killed sooner.

PMS (PackageManagerService)

Service that installs, parses and tracks packages, components, signatures and UIDs.

PowerManagerService

Service owning wakelocks, screen state and doze/suspend decisions.

PSI

Pressure Stall Information: kernel metric of time tasks stall on memory, CPU or I/O.

SELinux

Mandatory access control in the kernel; every process runs in a domain with explicit allow rules.

servicemanager

Binder context manager that maps service names to Binder handles.

Soft reboot

Restart of the framework (system_server and Zygote) without restarting the kernel.

SurfaceFlinger

Native compositor process that combines window buffers and sends them to the display via HWC.

Sync barrier

Special message that blocks synchronous messages so asynchronous ones (frame work) run first.

system_server

The privileged Java process hosting most Android system services.

Task affinity

String naming the task an activity prefers to live in; default is the package name.

Treble

Android 8.0 architecture that separates the framework from vendor code with stable HAL interfaces.

TTID / TTFD

Time to initial display (first frame) and time to full display (reportFullyDrawn()).

USAP

Unspecialized App Process: a pre-forked Zygote child waiting to become an app.

VINTF

Vendor Interface object: manifests and compatibility matrices that declare and check HAL versions.

VNDK

Vendor Native Development Kit: system libraries vendor code may use with a stable ABI.

Watchdog

system_server thread that kills system_server if critical threads or locks are stuck for 60 s.

Window token

An IBinder WMS already knows (usually the activity token) that authorizes adding windows.

WMS (WindowManagerService)

Service managing windows, focus, z-order, rotation and transitions.

zRAM

Compressed swap device in RAM that delays memory pressure.

Zygote

Preloaded process that forks system_server and every app process. The init service is named zygote; a 32-bit helper is zygote_secondary.

Interview questions