Reviewing Silent Bluetooth Uplink after a Seamless Update

Good morning. Marcus and Nadia are here from Audio Platform, Owen represents Device Quality, and Ravi joins from Connectivity Quality. We are reviewing build R17, which entered the five-percent employee rollout yesterday. The release dashboard shows no increase in crashes, but twelve users reported that the other party could not hear them on the first Bluetooth call after a seamless update. Speakerphone and handset calls still worked. We need to decide whether this is a release blocker, define the evidence needed today, and assign a recommendation before the rollout window closes at six this evening.

I have the audio service logs from nine affected sessions and four clean controls. In every affected session, the framework selected the Bluetooth communication device and opened the expected input stream. The application received silence rather than an error, so our health counter stayed green. The first technical difference appears below the framework: the audio hardware abstraction layer requested DSP route profile seven, while the firmware acknowledged profile five. I am not yet calling that the root cause, because the acknowledgment field may be stale. We need a direct signal from the DSP before we change release status.

Device Quality reproduced the symptom twice in thirty controlled updates. Both failures occurred when the phone installed the inactive slot overnight, rebooted with Bluetooth already connected, and placed a call within ninety seconds. We have not reproduced it after a cold flash or after toggling Bluetooth. That pattern makes the user path narrow, but it also makes ordinary regression testing likely to miss it. I want the meeting record to distinguish reproduction rate from severity. A silent microphone during a call is severe even if the path is uncommon, because the user receives no warning and may assume the network failed.

Connectivity Quality checked three headset families and two car kits. The failures are not tied to one accessory vendor or Bluetooth codec. However, all observed failures used the wideband speech path; narrowband calls recovered correctly. I also found that disconnecting and reconnecting the accessory clears the symptom without rebooting the phone. That recovery points toward route initialization, but it does not tell us whether Bluetooth, audio policy, or DSP state owns the defect. I can run a matrix today, provided we freeze the build variants and agree on which timestamps must be captured.

Let us establish one timeline from the update to the silent call. Please separate facts from assumptions and identify where our telemetry is blind. The release decision cannot rest on twelve user descriptions alone, but it also cannot ignore them because a dashboard lacks a microphone-content metric. Marcus, start with slot activation. Nadia, then explain the firmware packaging change in R17. Owen and Ravi, map your test observations onto those events. By the end of this section, I want a single list of timestamps that every experiment will collect.

R17 is the first candidate that delivers the audio DSP image through a versioned vendor package instead of the shared firmware bundle. The package manager activates the new metadata with the Android slot, but the DSP image is loaded later by a boot service. Our intended contract says both pieces become usable before user unlock. The logs show that the metadata reports version 17 at fifty-two seconds, while the DSP driver reports version 16 until seventy-eight seconds. That twenty-six-second gap overlaps the failed calls. The packaging change is suspicious, although timing overlap alone does not prove that the older image caused silence.

There is conflicting evidence. One clean control also placed a wideband call during that version gap, yet its uplink worked. In that run, the headset connected after user unlock, so the audio policy service rebuilt the route when version 17 was already available. My current hypothesis is not simply mixed versions. It is a route created from new metadata while the old DSP image is active, then retained after the image changes. We can test that by recording route creation, firmware-ready notification, stream start, and the first nonzero microphone buffer. Those four markers should expose the ordering.

My video and automation timestamps support that ordering, with one caveat. The automation considers the device ready when the launcher accepts input, not when vendor services finish their work. In both failures, the call began less than fifteen seconds after that readiness marker. In passing runs, the delay was usually longer because the script waited for accessory discovery. We accidentally changed two variables at once. I will revise the script so the headset is paired beforehand and the call starts at fixed offsets of five, twenty, forty, and ninety seconds after unlock. Each run will preserve the raw boot log.

One telemetry gap is the accessory state before reboot. The Bluetooth database tells us that a device was bonded, but our upload does not say whether it was actively connected when slot activation began. I will add connection-state transitions, profile registration, and audio-gateway readiness to the shared timeline. We should also record whether the accessory initiated reconnection or the phone did, because those paths register callbacks in a different order. This does not expand the release gate; it prevents us from grouping two boot paths under one label and drawing a false conclusion from a small sample.

I agree with the ordering experiment, but I challenge the assumption that the first nonzero buffer proves a healthy call. We have seen buffers with comfort noise while speech is still absent. Connectivity can capture the SCO packet stream and compare energy before and after the handset audio gateway. We should also force narrowband and wideband modes under the same timing offsets. If only wideband fails with identical route ordering, the codec-specific DSP configuration becomes more likely. If both fail, the broader route-retention theory gains weight. I will make the codec choice explicit rather than infer it from the accessory name.

There are three candidate remedies, and they carry different risks. We could block user unlock until the DSP image is ready, reject stream creation during the version gap, or rebuild affected routes when the ready notification arrives. Blocking unlock adds boot latency for every user. Rejecting the stream gives applications an error they may not recover from. Rebuilding is less visible, but changing an active route can create an audible pop or drop the first second of speech. Before choosing, I want an instrumented build that deliberately holds version 16 for sixty seconds. A controlled mismatch will give us a clearer signal than waiting for a rare race.

I support the controlled mismatch, but it must remain a diagnostic build. For a shippable change, I favor invalidating only communication routes built during the version gap and recreating them before the first stream opens. That preserves media playback routes and avoids touching a call already in progress. The difficult case is a stream that opens one millisecond before the ready notification. I can protect the transition with a generation number: stream creation reads the generation, builds the route, and verifies that the generation did not change before activation. If it changed, the operation retries once.

That proposal is testable, but I need explicit failure behavior for the retry. If the second attempt also crosses a generation change, do we return an error, fall back to narrowband, or wait? An indefinite wait would violate our call-setup budget. I recommend one retry followed by a bounded wait of two hundred milliseconds, then a visible error counter and normal framework failure. Quality will verify call setup time, uplink speech, pops, and media playback across update and ordinary reboot paths. We should not approve a patch that fixes silence by making calls consistently slow.

Before the experiment starts, document what result would disprove each hypothesis. The mixed-version theory weakens if silence occurs after version 17 is confirmed before route creation. The stale-route theory weakens if rebuilding the route leaves the uplink silent while a full Bluetooth reconnect restores it. The codec theory weakens if narrowband and wideband fail at the same rate with matching packet evidence. Writing those outcomes now keeps us from moving the explanation after we see the data. It also tells leadership why a result may justify more investigation rather than an immediate patch.

Based on the severity and the blind spot in our dashboard, I am pausing the rollout at five percent. This is a hold, not a rollback, because current users recover by reconnecting Bluetooth and we have no evidence of persistent corruption. Marcus owns the route-generation prototype by one this afternoon. Nadia owns the sixty-second mismatch build and firmware-ready trace points by eleven thirty. Owen and Ravi jointly own the fixed-offset matrix, with a preliminary result by four. No one should merge the prototype into R17 until the matrix demonstrates both causation and acceptable side effects.

I accept the prototype and will keep its change list separate from the diagnostic instrumentation. The implementation will invalidate only Bluetooth communication routes created while metadata and DSP versions differ. It will retry once across a generation change and expose counters for mismatch, invalidation, retry, bounded wait, and final failure. I will add unit tests for a route created before, during, and after the version transition. At one o'clock I will attach the build identifier, patch summary, and counter definitions to the release issue so the test results remain interpretable.

Connectivity will run two headsets and one car kit against forced narrowband and wideband modes at every fixed offset. We will capture the selected codec, SCO packet energy, gateway input energy, and remote-end recording. I will label a run as failed only when speech energy is absent at the remote end, rather than relying on a tester's impression. The preliminary table will include every attempt, device temperature, accessory reconnects, and exclusions. If the diagnostic mismatch reproduces silence but the generation prototype prevents it without increasing setup time beyond the budget, I will recommend advancing to the broader regression pass.

Device Quality will preserve the baseline R17 result and test the prototype with the same device state. Our pass gate is twenty consecutive wideband calls at each of the four offsets, zero silent uplinks, no audible pop in recorded samples, and a ninety-fifth-percentile setup increase below one hundred milliseconds. We will also run ten ordinary reboots and ten cold flashes to catch damage outside the seamless-update path. A single wrong route or silent uplink is a stop condition. Timing failures will be reported separately, because averaging them with correctness failures would hide the decision we need to make.

I will add one safeguard to the handoff. Every diagnostic image will carry a visible build suffix and will refuse production signing, while the prototype will use the normal firmware image. That prevents the artificial sixty-second delay from entering a candidate by mistake. I will also archive the package manifest from each run, because a stale test device could otherwise make a clean result meaningless. The manifest, driver version, and DSP-reported version must agree outside the intentional mismatch window. Any unexplained disagreement will invalidate the run before we compare audio behavior.

Before we close, I want to clarify the firmware deliverable. The diagnostic build will hold the old image through a test property; it will not alter the signed production package. I will provide the expected version timeline and a command that confirms which image the DSP actually loaded. For the candidate fix, I will also verify that the ready notification fires once per boot and once after a DSP recovery. Duplicate notifications could cause unnecessary route invalidations. I will post those checks with the build at eleven thirty and remain available while the first matrix completes.

The decision review is today, October thirteenth, at five thirty in the afternoon Seoul time. We will inspect the raw matrix, not only the summary chart. If causation is clear and the prototype meets every gate, I will authorize an R18 candidate and keep public rollout paused until overnight regression finishes. If evidence remains mixed, R17 stays at five percent and tomorrow's release slot is canceled. If the prototype introduces a correctness failure, we will abandon it and evaluate package activation ordering instead. I will communicate the hold to support and program leadership without promising a fix date.

For the review, I will bring a sequence diagram from slot activation through the first captured speech buffer, annotated with the generation counter. I will also compare the prototype against a build that only delays call start, because that control tells us whether the fix works by repairing state or merely waiting for the race to pass. If both behave identically, we should be cautious about merging extra route logic. If the prototype succeeds at the five-second offset while the delay-only build fails, we have stronger evidence that invalidation repairs the stale route.

The owners, gates, and deadlines are recorded. I will publish the test script before nine this morning so each team can challenge the conditions before execution starts. Once the first run begins, we will not change a threshold in response to favorable or unfavorable data. Any newly discovered condition will be added as a labeled follow-up experiment. At five thirty I will present incomplete cells as incomplete, not as passes. That gives the release decision a stable denominator and leaves an audit trail for the overnight team if R18 proceeds.

I will keep the remote-end recording synchronized with device logs by playing a short calibration tone before each call. The tone never enters the microphone path; it gives us a common clock between the packet capture and the recording system. Without that anchor, a one-second offset could make route recovery appear earlier or later than it was. I will publish the synchronization error for each accessory and reject any run above fifty milliseconds. This is especially important for audible-pop review, where reviewers need to hear the exact transition rather than a manually aligned clip.