Trace a Path Through the Android Stack

From top to bottom: the app (Java/Kotlin on ART), the framework (system services in system_server such as AMS, WMS, Telephony and SensorService), native daemons and vendor HALs (SurfaceFlinger, rild, the Sensors HAL), the Linux kernel (drivers, networking, binder driver) and the hardware and firmware (SoC, modem, sensor hub, display). App and framework talk over Binder, framework and vendor over stable HAL interfaces, and user space and kernel over syscalls, ioctl and interrupts.

system_server is the core system process, forked from Zygote during boot. It hosts most framework services as threads: ActivityManagerService, WindowManagerService, PackageManagerService, PowerManagerService, ConnectivityService, SensorService, InputManagerService and many more. Apps reach these services through Binder. If system_server crashes, the whole framework restarts (a "soft reboot").

A Hardware Abstraction Layer is a versioned interface between the Android framework and vendor-specific code for a piece of hardware (radio, sensors, camera, display, audio). It lets Google update the framework without rewriting vendor drivers, and lets vendors implement hardware support without changing the framework. Since Project Treble, HALs are defined in HIDL or stable AIDL and run in separate vendor processes; VINTF manifests check that versions match.

Signalling is the control conversation that sets up, modifies and ends the call; in VoLTE this is SIP (INVITE, 180 Ringing, 200 OK, ACK, BYE) through the IMS core, with SDP negotiating codecs and ports. Media is the actual voice, carried as RTP packets with RTCP reports. Media runs on a dedicated bearer with guaranteed QoS (QCI 1 on LTE), while signalling uses the IMS default bearer.

Telecom is the call-management layer: it tracks calls from any source (SIM calls, VoIP apps via ConnectionService), routes audio, and talks to the in-call UI. Telephony is the cellular stack: SIM, service state, IMS registration, data connections and the RIL to the modem. A cellular call goes from Telecom through TelephonyConnectionService into Telephony.

The Radio Interface Layer connects Android Telephony to the modem. On the framework side, RIL.java sends requests and receives responses and unsolicited indications. It calls the Radio HAL (HIDL IRadio or, from Android 13, AIDL interfaces such as IRadioVoice and IRadioData), implemented by a vendor process (classically rild). That process talks to the modem using a vendor protocol; on Qualcomm this is QMI, carried on modern SoCs over QRTR (Qualcomm IPC Router) rather than only shared-memory SMD.

It is a cellular data connection to a specific packet network, identified by an APN or DNN, with its own IP address. LTE calls it a PDN connection (anchored at the P-GW); 5G calls it a PDU session (anchored at the UPF). A device often has several at once, for example internet, IMS and emergency, each appearing as a separate network interface.

rmnet is Qualcomm's network driver for modem data. It exposes each data call as a Linux network interface (rmnet_data0, rmnet_data1 and so on) and multiplexes them over one physical link to the modem using QMAP headers, including packet aggregation. The kernel TCP/IP stack sees normal network interfaces.

IPA (IP Accelerator) is Qualcomm's hardware block in the data path between the modem and the AP (and peripherals like Wi-Fi or USB for tethering). It does routing, filtering, NAT, header processing and aggregation in hardware. This reduces CPU load and interrupts, so the AP can stay asleep during transfers, which is a large power win. Other SoCs have the same idea under different names.

The app writes to AudioTrack, MediaPlayer, ExoPlayer, AAudio or Oboe. AudioFlinger in audioserver mixes or hands off the track. AudioPolicyService picks the output device and volume strategy. The Audio HAL (AIDL IAudio, or HIDL on older devices) talks to ALSA or a vendor DSP and codec, which drive the speaker, headset or Bluetooth. Compressed offload and AAudio MMAP let the AP sleep; a FastMixer or VoIP path does not.

The app (CameraX or Camera2) talks over Binder to CameraService in cameraserver. CameraService configures streams and sends HAL3 requests to the Camera HAL. The sensor and ISP fill buffers: the preview Surface goes to SurfaceFlinger, the still goes to an ImageReader as JPEG or YUV, and a video Surface can go to MediaCodec. HAL1's "take picture" API is deprecated; HAL3 is request/result per frame.

The app uses the fused location provider (or LocationManager). LocationManagerService combines GNSS (via the GNSS HAL and a duty-cycled, often batched chip), network location (Wi-Fi and cell) and sensors. Fixes are delivered on the requested interval and displacement. High-accuracy 1 Hz GNSS without batching is a classic battery bug; on a watch, Health Services ExerciseClient is the intended API.

The sensor hub is a low-power processor (on Qualcomm, the SLPI or ADSP) that samples sensors such as the accelerometer, gyroscope and PPG while the main application processor sleeps. It runs filtering, sensor fusion and algorithms like step counting, and stores samples in a FIFO. It wakes the AP only when a batch is ready or an important event occurs.

Batching lets sensor events be stored in a hardware FIFO and delivered together instead of one at a time. An app enables it by passing a non-zero maxReportLatencyUs when registering a listener. The AP then wakes once per batch rather than for every sample, which saves a lot of power for continuous sensing.

The touch controller raises an interrupt; the kernel input driver reports events on /dev/input/eventX. In system_server, EventHub reads them, InputReader converts them to MotionEvents, and InputDispatcher finds the target window and sends the event over an InputChannel socket. The app's main thread receives it, ViewRootImpl dispatches it through the view hierarchy via dispatchTouchEvent(), and the view's onTouchEvent() eventually triggers onClick().

Vsync is the periodic signal from the display that marks the start of a new refresh cycle, for example every 16.6 ms at 60 Hz. Android uses it to pace app rendering (through Choreographer) and composition (in SurfaceFlinger), so that frames are produced at a steady rate and never shown half-drawn.

SurfaceFlinger is the system compositor. It receives buffers from every visible surface (apps, status bar, navigation bar, wallpaper), latches the newest buffer of each layer on vsync, and combines them into the final frame, using the Hardware Composer HAL to decide whether display hardware or the GPU does the composition. It then presents the frame to the display.

Zygote is a process started by init at boot that pre-loads the ART runtime and commonly used framework classes and resources. When a new app process is needed, Zygote forks itself. The child starts already warmed up, and unchanged memory pages are shared with other apps through copy-on-write. This makes app start faster and saves RAM compared with starting a new VM for every app.

A cold start has no existing process, so the system must fork from Zygote, bind the application and create the activity. A warm start reuses the process but recreates the activity (for example after it was destroyed). A hot start just brings an existing activity back to the foreground. Cold start is the most expensive and the one usually measured.

An A/B update keeps two copies (slots A and B) of the key partitions. The update is written to the inactive slot while the device keeps running; after reboot the bootloader starts from the updated slot. If the new slot fails to boot several times, the bootloader switches back to the old slot, so a bad update does not brick the device.

It is the API provided by Google Play services for communication between a watch and its paired phone (and other nodes). It offers DataClient for synced, persistent DataItems; MessageClient for one-way messages; ChannelClient for streams and large files; and CapabilityClient for discovering which node offers a feature. It picks the transport (Bluetooth, Wi-Fi or cloud) automatically. Builds without Play services do not have it.

• Voice call: logcat for Telecom, Telephony and IMS, plus modem logs.
• Data: dumpsys connectivity and tcpdump.
• Audio: dumpsys media.audio_flinger.
• Camera: dumpsys media.camera.
• Location: dumpsys location.
• Sensor: dumpsys sensorservice.
• Input: getevent and dumpsys input.
• Frames: dumpsys gfxinfo and Perfetto.
• App start: am start -W.
• OTA: update_engine logs and bootctl.
• Power: batterystats with Battery Historian.

The Dialer calls TelecomManager.placeCall(). Telecom picks the PhoneAccount and asks TelephonyConnectionService to create a Connection. Telephony chooses ImsPhone because IMS is registered, and the ImsService builds a SIP INVITE with an SDP offer. Commands go through RIL and the Radio HAL (IRadioVoice or IRadioIms, depending on where the IMS stack lives) to the vendor RIL and, over QMI (QRTR on modern Qualcomm SoCs), to the modem. The modem sends the INVITE over the IMS bearer to the P-CSCF and IMS core, which routes it to the callee; after 180 Ringing and 200 OK, the network sets up a dedicated QCI 1 bearer and RTP voice flows over it.

Telephony cannot place the call over IMS, so it uses the circuit-switched path. On LTE-only networks this means CSFB: the modem moves to 3G or 2G to place the call and returns to LTE afterwards. On 5G standalone without VoNR, the network performs EPS fallback to LTE and uses VoLTE there. If no CS or IMS path exists, the call fails; emergency calls have special rules to try every available domain.

First a data call must exist: ConnectivityService and the Telephony data stack ask the modem, through RIL setupDataCall(), to attach to a PDN or PDU session. The network assigns an IP, and an rmnet_data interface is configured by netd with routes and DNS. Then an app write() goes through the kernel TCP/IP stack to the cellular driver (rmnet plus QMAP on Qualcomm), then through a hardware offload engine (IPA on Qualcomm), which handles routing and aggregation, to the modem, the radio, the base station and the core network. That offload keeps the bulk path off the CPU, which saves power.

ConnectivityService ranks available networks (Wi-Fi, cellular, Ethernet, VPN) by score and validation status and picks a default. netd then uses Linux policy routing: sockets are tagged with a firewall mark (fwmark) based on the app's UID or explicit network binding, and ip rule entries send each mark to the right routing table. Apps can bind to a specific network with Network.bindSocket() or bindProcessToNetwork().

Each data call (PDN or PDU session) gets its own interface. Typical examples are the internet APN, the IMS APN used for VoLTE signalling, an emergency APN, and sometimes an MMS or tethering APN. Keeping them separate lets each have its own IP, QoS and routing, and lets IMS stay up even if the user turns mobile data off.

The PPG sensor is sampled by firmware on the always-on sensor hub, which filters it, computes heart rate and stores results in a FIFO while the AP sleeps. When the batch is full or the report latency expires, the hub wakes the AP. The Sensors HAL pushes events through a Fast Message Queue to SensorService, which delivers them to the app's listener, or Health Services delivers them to a PassiveMonitoringClient or ExerciseClient. Because the AP wakes once per batch instead of per sample, it can stay in suspend for long periods; an app forcing unbatched high-rate reads destroys that.

A wake-up sensor can wake the AP from suspend when it has data (for example when its batch is full or a significant-motion event occurs), and the HAL holds a wake lock until the event is delivered. A non-wake-up sensor never wakes the AP; its events wait in the FIFO until the AP wakes for another reason, and old events may be overwritten if the FIFO overflows. Choosing the right type is a power versus data-loss trade-off.

Input events are delivered to the app's main thread through its Looper, the same thread that runs lifecycle callbacks and drawing. If the main thread is busy (disk I/O, heavy computation, a slow Binder call), the event waits in the queue, so the user sees lag. InputDispatcher waits for the app to acknowledge each event; if it waits longer than about 5 seconds, the system declares an ANR.

The window manager and SurfaceFlinger provide InputDispatcher with a list of windows (InputWindowInfo) with their positions, z-order, flags and focus. For touches, the dispatcher hit-tests the coordinates against visible, touchable windows from top to bottom. For key events it uses the focused window. It then sends the event on that window's InputChannel.

A view is invalidated; on the next vsync Choreographer runs input, animation and traversal (measure, layout, draw into a display list) on the UI thread. RenderThread converts the display list to GPU commands, and the GPU draws into a buffer from the app's BufferQueue. The buffer is queued to SurfaceFlinger, which latches it on its vsync, composes all layers with HWC and presents the frame. Jank happens when any stage misses its deadline (about 16.6 ms at 60 Hz): usually main-thread work, a slow Binder call, heavy layout, overdraw or GPU load, or occasionally SurfaceFlinger or composition delays.

RenderThread is a per-app thread created by the hardware-accelerated renderer (HWUI). The UI thread records drawing operations into display lists and hands them off; RenderThread then issues the GPU commands, uploads textures and manages the buffer. This lets the UI thread start the next frame sooner and allows some animations to run on RenderThread even if the UI thread is briefly busy.

A BufferQueue is a small pool of graphic buffers shared between a producer (an app's Surface, a camera, a video decoder) and a consumer (SurfaceFlinger, a video encoder). The producer dequeues a free buffer, fills it and queues it; the consumer acquires it, uses it and releases it. Buffers are shared by handle, not copied, and fences say when each side has finished. This decouples rendering from display timing, so the app can prepare the next frame while the current one is shown. Since Android 10 most app surfaces use BLASTBufferQueue, which keeps this model but uses a cheaper SurfaceFlinger transaction path.

The usual Android 10+ path for app surfaces. The app still produces graphic buffers and SurfaceFlinger still consumes them; the change is how buffer state is sent to SurfaceFlinger (a BLAST transaction rather than the older BufferQueue-only setup). Interviewers want you to know the producer-consumer and fence story did not go away.

QMI is the message protocol between AP software and Qualcomm subsystems (modem and others). QRTR (Qualcomm IPC Router) is the modern socket-style transport those messages ride on, replacing older shared-memory SMD channels. Saying "QMI over shared memory" is the historic picture; on current SoCs, say QMI over QRTR.

Policy picks the route and the strategy: speaker versus earpiece versus Bluetooth versus USB, media versus voice versus alarm volumes, ducking and focus. AudioFlinger runs the tracks and talks to the HAL streams that policy selected. A "no sound" bug can be either: a mixing/HAL problem (Flinger) or a routing/focus problem (policy).

With device composition, the Hardware Composer assigns layers to hardware overlay planes in the display processor, which blends them while scanning out, using little power. With client composition, SurfaceFlinger first uses the GPU to combine some or all layers into one buffer, then hands that to the display. HWC falls back to client composition when there are too many layers or unsupported features, which costs power and can cause jank.

The client calls a method on an AIDL-generated proxy, which marshals the arguments into a Parcel. The proxy calls transact(), which issues ioctl(BINDER_WRITE_READ) on /dev/binder. The driver looks up the target, records the caller's UID and PID, and copies the Parcel once into a buffer that the target process has mapped. It wakes a thread in the target's Binder thread pool, which runs Stub.onTransact(), unmarshals the data and calls the real method. The reply comes back the same way, and the client thread unblocks; oneway calls return immediately.

A oneway call is asynchronous: the caller returns as soon as the driver accepts the transaction, without waiting for the method to run or return a result. Calls to the same object are queued and delivered in order. Use them for notifications and callbacks where the caller must not block, such as a system service calling back into an app. The trade-off is no return value and no exceptions reported to the caller.

The launcher calls startActivity() over Binder. ActivityTaskManagerService resolves the intent, creates the activity record and shows a starting window. If the app has no process, AMS asks Zygote to fork one. The new process runs ActivityThread.main(), starts the main Looper and calls attachApplication(); AMS replies with bindApplication, which installs ContentProviders and runs Application.onCreate(). The activity goes through onCreate, onStart and onResume, ViewRootImpl performs the first traversal, RenderThread draws, the buffer goes to SurfaceFlinger, and the first frame appears. That moment is TTID.

Use adb shell am start -W, which reports TotalTime and WaitTime; logcat's "Displayed" line gives TTID. Call reportFullyDrawn() when content is ready to get TTFD. For detail, capture a Perfetto trace with the app-startup track to see bindApplication, activity start, inflation and the first frame. Use Macrobenchmark for repeatable measurements in CI.

Use a DataItem for small state that both devices should eventually agree on, such as settings or the latest workout summary; it is persisted and synced even if the devices are disconnected now. Use a message for a quick command that only matters if the other side is connected right now, such as "start playback." Use a channel for large or streaming data such as audio or log files. Attach Assets to DataItems for images and binary blobs.

With A/B updates, update_engine verifies the payload signature and writes the new images to the inactive slot while the device runs normally. It verifies the written data, then the boot control HAL marks the new slot active with a limited retry count. On reboot the bootloader starts the new slot, AVB verifies it, and once boot completes the system marks the slot successful. If the new slot fails to boot within its retry count, the bootloader falls back to the old slot.

AVB (Android Verified Boot) is the boot-time chain of trust: the bootloader checks the signed vbmeta structure, which contains hashes or hash-tree descriptors for each partition, and refuses to boot or warns the user if they do not match. dm-verity is the kernel feature that enforces those hash trees at runtime, checking each block of a read-only partition such as system or vendor as it is read. AVB decides whether to boot; dm-verity catches tampering or corruption afterwards.

Each process that receives Binder transactions maps a region of kernel-managed memory into its address space. The driver copies the sender's data directly from user space into pages that are mapped in the receiver, so the receiver reads it without a second copy. The limit is that this buffer is small (about 1 MB per process, shared by all in-flight transactions, and less for oneway calls), so large payloads throw TransactionTooLargeException. For big data, pass a file descriptor, SharedMemory, or a HardwareBuffer through Binder instead.

The driver stamps each transaction with the caller's real UID and PID, which cannot be forged from user space. Services call Binder.getCallingUid() or checkCallingPermission() to enforce permissions. SELinux adds another layer: policy controls which domains may call, transfer to, or find which service managers and services. Services should use clearCallingIdentity() carefully when acting on their own behalf.

Every process has a fixed maximum number of Binder threads. If all of them are blocked (for example waiting on a lock, slow I/O, or a nested Binder call to another stuck process), new incoming transactions have to wait, so every caller of that process stalls. In system_server this looks like a system-wide freeze and can trigger the watchdog. Detect it with ANR or watchdog stack dumps showing many binder: threads blocked in the same place, Perfetto traces showing binder transactions with long durations, or debug entries under /sys/kernel/debug/binder.

HIDL HALs use the hwbinder driver and a separate hwservicemanager, with interfaces versioned like android.hardware.radio@1.6. Stable AIDL HALs (Android 11 onwards, and the default for new HALs) use the normal binder driver or vndbinder, are registered with servicemanager, and are versioned by integer with frozen API snapshots. Both marshal data into parcels and support FMQ for high-rate data. Google has been migrating HALs from HIDL to AIDL, so a platform upgrade often includes a HAL interface migration.

An FMQ is a ring buffer in shared memory set up once between two processes over a HAL call. Afterwards the writer and reader exchange data directly through the shared memory, using atomic read and write pointers and optionally an event flag to wake the reader. There is no Binder transaction per item. The Sensors HAL 2.x and AIDL use one FMQ for events and another for wake-lock acknowledgements, which cuts the overhead of delivering thousands of sensor events per second.

Android derives two software vsync signals from the hardware vsync. Vsync-app wakes Choreographer in apps to start a frame; vsync-sf wakes SurfaceFlinger to compose. They are offset so that apps have time to render before SurfaceFlinger latches their buffers, and SurfaceFlinger has time to compose before the display scans out. Tuning these offsets trades latency against the chance of missing a frame; high refresh rates make the windows tighter.

With two buffers, if the app misses a frame deadline, both buffers may be in use (one displayed, one still being drawn), so the app must wait and may miss the next deadline too. A third buffer lets the app start the next frame while one buffer is on screen and another is waiting to be composed. This smooths occasional long frames at the cost of more memory and up to one extra frame of latency.

When the app queues a buffer, the GPU may still be drawing it; an acquire fence signals when the drawing finishes, so SurfaceFlinger or HWC waits only on that fence rather than the CPU waiting for the GPU. When the display releases a buffer, a release fence signals when scan-out has finished, so the producer can safely overwrite it. Present fences report when a frame actually reached the screen. This removes the need for blocking handshakes at every stage.

IPA sits between the modem and the AP memory. On downlink, the modem hands packets to IPA, which applies filter and routing rules, aggregates packets with QMAP headers and writes them to AP memory via DMA, raising one interrupt per aggregated batch. The rmnet driver de-aggregates and hands packets to the kernel network stack. On uplink the reverse happens. For tethering, IPA can forward between USB or Wi-Fi and the modem entirely in hardware, so packets never reach the AP's network stack.

IMS uses its own APN (usually "ims"), which is a separate PDN connection that the "mobile data" toggle does not control. Telephony keeps the IMS data call up while the device is registered on LTE or NR, so SIP registration, incoming call INVITEs and SMS over IMS continue to work. Only the internet APN is brought down when data is disabled.

When the HAL writes a wake-up event into the event FMQ, it holds a wake lock so the AP cannot suspend before the framework has read it. SensorService reads the event, delivers it to clients, and writes an acknowledgement to a separate wake-lock FMQ; the HAL then releases its wake lock. If this handshake is broken (for example a client that never acknowledges), the device can be kept awake, which shows up as a sensor wake lock in batterystats.

After fork(), the child shares all of Zygote's memory pages with the parent, marked read-only. Only when a page is written does the kernel copy it for the writing process. This lets every app share preloaded classes and resources. It is undermined when writes touch many shared pages, for example garbage collection moving objects in the preloaded heap or apps modifying preloaded objects; ART mitigates this by placing preloaded objects in a separate, rarely collected space.

Classic A/B keeps two full copies of every updatable partition, doubling storage. Virtual A/B keeps one copy of dynamic partitions (system, vendor, product) inside the super partition and writes the update as a copy-on-write snapshot that stores only changed blocks (compressed from Android 12). After reboot, the new slot is assembled from the base partition plus the snapshot using device-mapper and, with compression, snapuserd. Once boot is marked successful, a background merge writes the snapshot into the base partition; until then rollback is possible. The merge is designed to be resumable if power is lost.

Each image in vbmeta has a rollback index. The bootloader stores the highest index it has booted in tamper-resistant storage (for example RPMB or fuses) and refuses to boot images with a lower index. This prevents attackers from flashing an older, vulnerable but validly signed build. The stored index is only increased after the new build has booted successfully, so A/B rollback to the previous slot still works during the trial period.

DataItems are identified by a URI path including the node that created them; the latest write to a path replaces the previous value and is propagated to all connected nodes, so it behaves like last-writer-wins eventual consistency. Messages have no persistence or conflict resolution. For state edited on both sides, design the data so each device writes its own paths, include timestamps or version numbers in the payload, and make handlers idempotent so re-delivered updates do no harm.

• The FrameTimeline track, to see whether the frame was late on the app side or on SurfaceFlinger side, and the jank type.
• The app's UI thread: long Choreographer#doFrame, inflation, layout, or binder transaction slices.
• RenderThread: long draw, texture upload, or waiting on a GPU fence (dequeueBuffer blocked means no free buffer).
• CPU scheduling: was the thread runnable but not running (CPU contention, wrong core, frequency too low)?
• SurfaceFlinger: long composition or client composition fallback.

The system shows a starting window (splash screen) immediately, so the user sees feedback before the app draws. The top app is placed in the top-app cgroup with higher CPU priority and access to big cores, and the performance HAL may boost CPU and memory frequencies during launch. Features like Baseline Profiles and cloud profiles make sure start-up code is compiled ahead of time, avoiding interpretation and JIT during the first frame.

Use Perfetto as the backbone: enable scheduling, binder, frame timeline, input, power rails and relevant atrace categories, plus app-level trace sections you add with Trace.beginSection(). Capture logcat in the same trace, and align modem or sensor-hub logs by timestamp with a known event (for example a SIP INVITE or a sensor batch). Record a clear marker when the user action happens. The goal is one timeline where every hop in the flow can be seen with its duration.

This is the render flow. Start with dumpsys gfxinfo <package> framestats to confirm and quantify missed frames. Then capture a Perfetto trace while scrolling and look at the UI thread and RenderThread against vsync and FrameTimeline. Typical root causes are heavy onBindViewHolder() work, layout inflation during scroll, image decoding on the main thread, a synchronous Binder call, or GPU overdraw; check dumpsys SurfaceFlinger for client composition. Fix by moving work off the main thread, pre-computing, caching, and flattening layouts, then re-measure.

1. Check IMS registration state (dumpsys telephony.registry, IMS logs); if not registered, calls fall back to CS.
2. If registered, capture logcat for Telecom, Telephony and ImsService plus modem logs for the failing call.
3. Look at the SIP ladder: does the INVITE go out, and what response comes back (403, 488 codec mismatch, 503, timeout)?
4. Check whether the dedicated bearer is set up and whether preconditions succeed.
5. Compare with a known-good build or SIM and check carrier configuration (CarrierConfig VoLTE flags, IMS APN settings).

Then hand off to the owning layer (framework, IMS stack, modem or network) with the exact failing step.

1. Confirm the data call: dumpsys telephony.registry and the interface in ip addr (does rmnet_dataX have an IP?).
2. Check routes, rules and DNS: ip route show table all, ip rule, dumpsys connectivity (is the network validated? is it the default?).
3. Test from the shell: ping an IP address, then a hostname, to separate routing from DNS problems.
4. Check firewall and per-app restrictions (Data Saver, background restrictions, VPN).
5. If packets leave the AP (tcpdump shows them) but nothing returns, collect modem logs and IPA stats to see whether the modem or network drops them; check MTU if small requests work but large ones hang.

Reproduce with a fixed overnight profile and compare drain per hour against the previous build. Take a bug report and load batterystats into Battery Historian: look for frequent wakeups, sensor wake locks and low suspend residency. Check dumpsys sensorservice for active connections, their sampling rate and whether batching (max report latency) is used; look for a client that registered a wake-up sensor with zero latency. Check /sys/kernel/debug/wakeup_sources for sensor-related wake sources. Once the client and change are identified, fix the batching or wake-up usage, then add standby drain as a regression gate.

Pull the ANR trace from /data/anr or the bug report and look at the main thread stack at the time of the ANR. Common patterns: blocked on a lock held by another thread, doing disk or network I/O, waiting on a synchronous Binder call (check what the remote side was doing), or a long loop. Also check dumpsys input for the pending event queue and the CPU load section in the ANR log; a system-wide overload can make any app ANR. Fix the specific blocking work and use StrictMode to catch main-thread I/O in testing.

Measure where the latency is. Use getevent -lt to see the timestamps of raw events and whether the touch controller reports at the expected rate; a low report rate or firmware filtering points to the touch driver or firmware. Use Perfetto input tracks to see time from kernel event to InputDispatcher to app delivery. Check whether the touch IRQ is threaded and pinned to a slow or sleeping core, whether CPU frequency is low during interaction (touch boost missing in the power HAL), and whether display refresh or vsync configuration is wrong.

Measure with am start -W or Macrobenchmark on both builds under the same conditions (cache dropped, same thermal state). Capture Perfetto traces with the app-startup track on both and compare phases: process fork, bindApplication, activity start, inflation, first frame. If the gap is before bindApplication, look at AMS, Zygote or system load; if inside, look at class loading, dex compilation state (dumpsys package for compiler filter), or I/O. Also check CPU frequency and scheduling differences. Bisect the build change list if the phase is not obvious.

Collect the watchdog dump and ANR traces from the bug report. The watchdog reports which monitor or handler thread was blocked; look at its stack and at the lock it is waiting for, then find the thread holding that lock. Very often it is a Binder call out of system_server to a slow HAL or app while holding a service lock, or Binder thread-pool exhaustion. Check kernel logs for I/O stalls or memory pressure too. Fix by not holding locks across outgoing Binder calls, adding timeouts, or making the call oneway.

Check whether the delay correlates with transport changes (Bluetooth to Wi-Fi to cloud) or with the watch being in Doze. Collect Bluetooth HCI snoop logs and Data Layer and companion logs on both devices with synced timestamps. Duplicates often come from both the phone bridge and a standalone watch app posting the same notification, or from retries after a transport switch without de-duplication. The fix is usually to use bridging rules or dismissal IDs correctly and make the handling idempotent.

The new slot most likely failed to boot and the bootloader rolled back after exhausting its retry count, or the boot was never marked successful. Check bootctl for slot states (unbootable, successful), bootloader and kernel logs from the failed attempts (last kernel log, pstore), and whether update_verifier found dm-verity errors. Other causes include a vbmeta or AVB failure, a rollback index problem, or a service that crashes during boot so boot never completes. Reproduce by flashing the new slot directly and capturing a UART or serial log.

No, if the implementation is correct. The merge is designed to be resumable: progress is tracked in metadata, and on the next boot the device assembles the partitions from the base plus remaining snapshot and continues merging. During the merge, rollback to the old slot is no longer possible because the base has been partly overwritten, which is why the merge only starts after the new slot is marked successful. Verify with snapshotctl dump and update_engine logs.

Check whether the IPA offload and aggregation are working: IPA statistics, interrupt counts on the data path (/proc/interrupts), and CPU usage in network softirq processing. If aggregation is off or misconfigured, the AP handles every packet and cannot sleep. Also compare modem power and radio state (for example the device staying in a high-power connected state because of frequent small transfers) and check for apps keeping sockets busy. Compare the IPA and rmnet configuration against the last good build.

Find which transaction is too large, usually from the stack trace and by logging parcel sizes. Common culprits are large Bundles in onSaveInstanceState(), big bitmaps in intents, or long lists returned from a service. Fix by sending less data (IDs instead of objects), paging results with ParceledListSlice, or passing a file descriptor or SharedMemory for bulk data. Remember the 1 MB buffer is shared by all in-flight transactions, so many concurrent medium calls can also trigger it.

Likely causes are FIFO overflow with non-wake-up sensors (the AP slept too long and old samples were overwritten), the app being killed or restricted in the background, Doze deferring delivery, or the sensor hub pausing the sensor (for example off-wrist detection). Check dumpsys sensorservice for the registration and FIFO settings, the app's standby bucket and process state, and sensor-hub logs. Using Health Services passive monitoring, which buffers data on the hub and handles delivery, usually fixes this.

Break it into flows you know. Capture: the app calls CameraX or Camera2, CameraService talks to Camera HAL3 with a request/result, the ISP produces frames into buffers (preview goes to SurfaceFlinger, the still goes to an ImageReader), and the JPEG is written to storage. Upload: the app opens a socket on the default network, the packet path goes through the kernel, the cellular interface (rmnet on Qualcomm), the vendor offload engine and the modem to the internet, after the data call is set up. Name one tool per stage. This shows you can compose known flows into a new one.

Decide whether decode and mix are on the AP or offloaded. dumpsys media.audio_flinger shows track types (compressed offload, deep buffer, fast) and whether the mixer thread is in standby. If offload never engaged, the AP stays awake mixing PCM. Also check Bluetooth A2DP versus a speaker, a wakelock held by the media session, and whether a visualization or MediaStyle notification is forcing a fast path. On a watch, playing through the phone over Bluetooth is often cheaper than a local speaker plus LTE.

The location flow. dumpsys location and dumpsys gnss show the client, interval, displacement, batching and whether high accuracy is on. Compare against Health Services ExerciseClient, which batches GNSS on the hub or chip. Also check whether the screen stayed interactive and whether LTE was up. Fix: longer interval, batching, displacement, and stop updates when the exercise ends.

Capture a Perfetto trace with binder tracing enabled and find the slow transactions. Check the server side: was a Binder thread available (thread-pool exhaustion shows as waiting to start), and what was the server thread doing (waiting on a lock, I/O, or its own outgoing Binder call)? Check CPU scheduling for both threads: runnable but not running points to CPU contention or priority problems. Fix the server-side bottleneck, or make the client call asynchronous if the result is not needed immediately.

Several: the input or wake gesture (wrist-raise or button) is detected by the sensor hub or input subsystem; PowerManagerService changes display state; the display HAL moves the panel from low-power mode to normal; SurfaceFlinger and the watch face must produce a new interactive frame. Capture Perfetto with display, power and SurfaceFlinger tracks, and measure wake-to-first-frame. Common causes are the watch face taking too long to render its interactive frame, display power-mode transitions, or CPU still being at a low frequency after resume.

Say the method out loud: identify which flow is involved, reproduce it reliably, and add a measurement. Then walk the layers from top to bottom and name the tap for each (app logs, framework dumpsys, HAL logs, kernel dmesg or ftrace, firmware or modem logs). Find the last layer where the data is correct and the first where it is wrong; if it is a regression, bisect builds too. Finally hand the evidence to the owning team and add a test so the problem cannot come back silently.