Tracing Binder Delays After Android User Unlock

Good morning. I can see Daniel from Framework, Sora from Performance, and Elias and Priya from Device Quality. Before we begin, please confirm that everyone has the same capture from build L42. We are looking at a slow first unlock after a warm reboot, not a slow boot animation. The screen accepts the PIN promptly, then the launcher remains unresponsive for several seconds. I want us to leave with a defensible owner and a narrow experiment, because the current issue tracker blends that delay with unrelated fingerprint failures.

I have the trace, the bug report, and the framework event log with matching boot identifiers. I also checked the device clock against the trace clock, so the timestamps are comparable within a few milliseconds. There is one correction to the invite: the problem reproduces after both warm reboot and user switch, but not after every unlock. I will keep those paths separate. If we mix them now, a change that helps a freshly started process could look like a general fix when it only moves the work elsewhere.

Performance has twelve paired runs on the same four devices, six with the feature flag enabled and six without it. Three of the flagged runs exceed the proposed response budget; none of the unflagged runs do. That is a useful clue, not proof of causation. The flag also changes when a companion service starts, and thermal history differs between runs. I would like us to compare thread states at the first missed frame rather than argue from a single summary percentile.

Quality can reproduce it in the lab, but the field report is much less precise. The affected group submitted a screen recording and a wall-clock estimate, not a trace. I have asked support to avoid calling it a freeze until we know whether input is queued, rejected, or delivered to a busy launcher. That distinction matters for user impact. We should define what the user can and cannot do during the pause, then use exactly that criterion for the verification pass.

I have the device matrix and the proposed test script. Two products share the framework branch but use different memory configurations, while the third has a different launcher build. We should not assume the common framework branch makes all three failures identical. For today's decision I can run a controlled matrix on one reference product first, then repeat the winning configuration on the others. That keeps our evidence readable and prevents a long overnight run from hiding which variable actually changed.

Let us put the events in order. The PIN acknowledgment is at zero, the user-unlocked broadcast is at about forty milliseconds, and the first responsive launcher frame arrives much later. Daniel, tell us which call chain is on the critical path, and identify anything you are inferring rather than observing. I want a shared timeline before we discuss fixes. In particular, the system server may be busy during the interval without being the component that makes the launcher wait.

The trace shows the launcher waiting on a synchronous Binder reply while it initializes the workspace model. That reply enters the system service quickly, but its worker does not run for roughly eight hundred milliseconds. The worker pool is occupied by callbacks from the newly started companion service. I can point to the queueing gap; I cannot yet say the callback itself is defective. The framework change added one lookup at unlock, and that lookup happens to land behind several longer operations already in the pool.

I agree with the queueing observation, but I do not agree that it explains the whole pause. The launcher main thread wakes after the reply and then performs nearly a second of local model work. The trace slice ends before the first touch response, so the visible delay could have two contributors. We need to separate queueing time from post-reply work. Otherwise a Binder adjustment may produce a beautiful service metric while the person holding the phone still sees an inert home screen.

That distinction changes the acceptance test. I would record three markers: successful credential entry, first drawn launcher frame, and first accepted tap that opens an app. A drawn frame is not sufficient if the input queue remains blocked. I can instrument the test with an external camera and the existing UI automation, then compare the timestamps without modifying production code. We also need a negative control on an ordinary unlock, because a test harness that always waits for launch could exaggerate the regression.

For repeatability, I will freeze the setup before each run: the same account state, the same set of pinned apps, battery above the agreed threshold, and a cooling interval. I will capture device temperature rather than discard a run merely because it looks inconvenient. Any exclusion must be recorded with a reason before we inspect the latency. That gives us an audit trail if the result changes between products. I can publish the raw timestamps alongside a short chart, so nobody has to trust a colored dashboard alone.

We have two hypotheses on the table: worker contention delays the synchronous response, and launcher work after that response extends the user-visible pause. Is there a third explanation we could falsify cheaply? I am particularly concerned that we might misread normal initialization as a regression because we changed the trace boundary. Please keep proposals reversible. We are one week from the branch decision, and a broad threading change is harder to validate than a targeted reduction in work.

There is another possibility: the service cache is cold only on the first unlocked user. A cache miss calls into package metadata and holds a pool worker longer than our steady-state measurements suggest. I can add temporary trace points around cache population and compare the same build with warm and cold cache. That would tell us whether queue depth is the cause or simply a symptom. I would not increase the pool size yet; more workers may increase memory pressure and merely make the race less visible.

I would run that experiment, but please preserve the baseline trace untouched. When trace points are dense, they can shift scheduling on a borderline device. I can calculate the interval from the PIN event to Binder enqueue, enqueue to worker start, worker execution, and reply to accepted tap. The sum must reconcile with the camera measurement within our tolerance. If it does not, we have a missing interval, and optimizing one slice would be premature. We should measure the experience, not just the convenient subsystem.

One objection to a cache-only fix: after a user switch, the service process can stay alive, yet we still see an occasional pause. That may be a separate trigger, or it may mean the cache is keyed by user and becomes cold again. We need the test script to capture both paths without pretending they are interchangeable. I can label each result by trigger and build rather than merging the distributions. If the treatments diverge, we will split the issue instead of forcing one explanation onto two symptoms.

I can make that distinction visible in the run sheet. For each trigger we will record whether the companion service starts, whether package state was previously queried, and whether the launcher process survives. The matrix will be smaller than a full factorial test because some combinations are impossible on the device. I will mark those cells as impossible rather than leaving them blank. The key question is whether we can reproduce a delay with the feature flag off after matching these conditions; that would weaken the simple flag explanation.

Let us compare remedies against evidence and rollback cost. Daniel, you mentioned making the lookup asynchronous, warming the cache, and adding a dedicated worker. Which one preserves the launcher contract most clearly? A faster result is not useful if the launcher renders stale entitlements or misses a change in user state. I want us to state what correctness means before anyone edits the code. Then we can choose a small patch whose behavior Quality can observe directly.

The synchronous lookup currently guarantees that the launcher receives the current user's policy snapshot before it exposes shortcuts. Turning it asynchronous would require a new invalidation protocol, which is too large for this branch. Cache warming could preserve the same contract if it happens after user identity is established and before the launcher requests the snapshot. However, it must not block the unlock broadcast. I propose a limited prototype that precomputes only the policy key and leaves the final permission check on the existing synchronous path.

That is plausible, but precomputation still consumes CPU at a sensitive moment. I would prefer a bounded experiment rather than calling it a fix. Compare the baseline, policy-key warmup, and a diagnostic build that defers the companion callbacks, using the same test matrix. The diagnostic build will never ship; it tells us whether contention is material. If warmup improves the service wait but worsens first-frame time, we should reject it. My proposed budget is an end-to-end tap response, not a Binder-only target.

We also need correctness checks for a rapid user switch and for a policy change during the pause. The first scenario can expose a cache keyed to the wrong user; the second can expose a stale snapshot. I can write tests that compare visible shortcuts against the policy service after the first accepted tap. A pass requires both the timing threshold and correct content. If either fails, the candidate does not advance to the release branch, even if its median latency looks excellent.

I will add a memory observation to that gate. The warmup must not create a per-user cache that grows with each switch; we can sample proportional set size before and after a sequence of ten switches. I will also check that the trace tags used for the experiment are removed or disabled before the candidate build. Keeping diagnostic hooks accidentally enabled could change power behavior and complicate later analysis. I can deliver one results table that places latency, correctness, and memory side by side.

Here is the decision I am recording. We will not change the public framework contract or increase the Binder pool for this release. Daniel will prepare the policy-key warmup prototype and a separate callback-deferral diagnostic build by Tuesday at noon Seoul time. Sora will publish the timing decomposition and reconcile it with camera observations by Tuesday evening. These are experiments, not an approval to merge. The existing feature flag remains available as the immediate rollback control if our release criteria are missed.

I accept those two builds and will keep them on separate change lists. For the prototype, I will document the exact cache key, its invalidation event, and why the final policy check still uses the existing path. I will include a unit test for two users whose shortcut policies differ. The diagnostic build will only delay companion callbacks behind a test switch, so it cannot be mistaken for a production solution. I will attach both build identifiers and a change summary to the issue before Priya starts her runs.

I will publish the baseline breakdown first, before looking at the prototype result. That order protects us from redefining a favorable metric after seeing the data. I propose a pass threshold of a first accepted tap within two seconds on at least nineteen of twenty controlled trials, with no correctness failure and no material memory growth. That is stricter than the current observation but achievable on the unflagged baseline. I will report every trial and its thermal state, not only the passing subset.

Quality will own the acceptance wording and the user-switch checks. I will send the finalized script by Tuesday afternoon, after Daniel confirms the diagnostic switch name. A failed correctness case is a stop condition even if the aggregate timing passes; there is no averaging away a wrong user's shortcut. I will keep the ordinary-unlock control in every batch. If the reference device passes, we can expand to the other two configurations on Wednesday, but I will not collapse their results into a single green label.

I can begin the controlled runs as soon as the identifiers and script are frozen. I will reserve the reference device for Tuesday evening and the additional configurations for Wednesday morning. Each row will include build, trigger, feature flag, temperature, queue time, first frame, first accepted tap, shortcut correctness, and memory delta. I will stop the batch after any reproducible wrong-user content and notify the group immediately. Otherwise I will post the complete table, including failed and excluded attempts, by Wednesday at four Seoul time.

The follow-up review is Thursday, October fifteenth, at ten in the morning Seoul time. At that meeting we will choose among merging the narrow prototype, leaving the flag off for this release, or holding the branch decision for more evidence. The choice will use the agreed table, not a narrative built around the best run. Daniel, please confirm that the original baseline artifacts stay linked in the issue. I want someone outside this room to be able to reproduce our reasoning next week.

Confirmed. I will keep the original trace, event log, and bug report read-only and link their hashes in the issue. The prototype trace will be a separate attachment with its own build identifier. If the warmup wins only on the first unlock and loses on user switch, I will say so plainly rather than broaden the claim. I will also add a short note explaining how to disable the prototype without changing the existing launcher behavior. That makes rollback a practical option rather than a line in a meeting record.

I will bring a plot that shows the full distribution and each interval, with the camera-based user measure highlighted. I will annotate outliers before discussing the median, because one long pause may matter more to the user than a small improvement in typical cases. If the service wait disappears but the tap delay remains, I will ask us to open a launcher investigation rather than declare this issue closed. The measurement plan should let us make that call without another week of instrumentation.

I will send support a concise status that separates observed behavior from the two unproven causes. They can tell affected users that we are measuring first interaction after unlock, without promising a particular patch or date. For the lab report I will preserve video clips for failing trials and one representative passing control. I will also note whether repeated taps are buffered or lost. That detail may influence the severity assessment even if the measured delay falls just under our numerical threshold.

I have the owners and dates. I will share the run sheet in the issue today, and everyone can comment on missing conditions before the script is locked tomorrow afternoon. After that, any new condition goes into a separate follow-up rather than silently changing the denominator. I will call out incomplete data in the Thursday review, even if the charts look encouraging. We have a clear experiment, an explicit stop condition, and a meeting to decide what ships. That is enough for me to start preparing the devices.