Pixel Take a Message Bug: What Google Confirmed and What It Didn't

Google confirmed in January 2026 that the Pixel Take a Message bug had caused ambient audio from owners' surroundings to be transmitted to incoming callers on some Pixel 4 and 5 devices, with no dedicated alert that the microphone was active. The company responded by remotely disabling Take a Message and next-generation Call Screen on those devices, according to 9to5Google. Based on the research available, that is the only Pixel call failure Google has publicly confirmed.

It is not the only way a Pixel can silently miss a call. Community reports and developer issue threads point to at least two other failure modes, each sitting at a different layer of how modern smartphones handle voice. One involves IMS registration dropping during idle periods. Another involves how Pixel devices send keepalive packets on carriers running a network translation protocol called 464XLAT. Each produces the same user experience: a call arrives, the phone does nothing, the caller gives up.

Same symptom, three different layers

Layer 1, feature behavior: Call Assist tools like Call Screen and Take a Message answer calls before the phone rings. When they malfunction, the consequences can include privacy harms. This layer has a confirmed bug, addressed by disabling the feature on affected devices.

Layer 2, IMS registration: Every VoLTE and VoWiFi call depends on a protocol stack called IMS (IP Multimedia Subsystem) staying continuously registered with the carrier. When that registration lapses during an idle period and fails to recover, the phone appears connected data and SMS may continue working but voice calls go nowhere, with no error to show for it. This layer has substantial community documentation and a credible mechanism, but Google has not publicly confirmed a root cause, per Android Authority.

Layer 3, network translation: On carriers using 464XLAT to bridge IPv6 and IPv4 networks, a developer-reported flaw in how Pixel devices send VoLTE keepalive packets may cause the carrier's server to silently drop the voice session. This is the most technically specific and least broadly confirmed of the three, documented in a developer-level bug report with one corroborating observation on stock Android, per GrapheneOS issue #4389.

Each section below maps to one of these layers. The diagnostic section at the end helps identify which may apply.

Pixel Take a Message bug: what Google confirmed

Take a Message works like this: when a Pixel owner declines or misses a call, the feature answers on their behalf, prompts the caller to leave a message, and delivers a live transcript to the owner. The caller hears a prompt and records a message. The owner gets a transcript instead of a ringing phone. This is intentional behavior, described in Google's own support documentation.

The bug inverted that design. On a subset of Pixel 4 and 5 devices, Take a Message activated and then relayed ambient audio from the phone's surroundings back to the caller, as if the call had been answered normally. The microphone was live. Apart from the system microphone status icon, there was no dedicated in-app alert that this was happening, 9to5Google reported in January 2026.

Google said the issue affected "a very small subset of Pixel 4 and 5 devices under very specific and rare circumstances" and disabled both Take a Message and next-generation Call Screen on those devices as a precaution. Because Pixel 4 and 5 no longer receive Android updates, a server-side feature disable was the available mechanism. Affected users retain access to manual and automatic Call Screening and carrier voicemail, according to 9to5Google. The underlying bug has not been publicly described as fixed.

Several Call Screen behaviors that look like bugs are actually documented design choices. Automatic screening does not activate when headphones or a Bluetooth device are connected on some models, does not function during international roaming, and will not forward screened calls if call forwarding is enabled. Call Screen also uses saved contacts to decide what to screen: numbers not in contacts get screened silently, while saved contacts ring through, per Google's support documentation. Any of these can produce the experience of a missed call without anything actually being broken.

The call-assist layer sits invisibly between an incoming call and the owner's attention. A caller can hear ambient audio from a room the owner considers private, with no indication on either end that anything has gone wrong.

IMS registration failures and the 2024 missed-call wave

Every voice call on a modern Pixel travels over LTE or Wi-Fi via IMS, the protocol stack managing VoLTE and VoWiFi. IMS must maintain a continuous registration with the carrier. When that registration fails or lapses during an idle period, the device can appear fully connected data works, SMS delivers but it is effectively unreachable for voice, with no error message to indicate why.

A developer-filed issue on the GrapheneOS tracker documented the failure in detail on Pixel 7 Pro and Pixel 8 hardware: setting the network mode to "LTE only" causes IMS to stop registering entirely, making both incoming and outgoing calls fail while data and SMS continue normally. Switching to "5G + LTE" allows IMS to register and restores voice. One commenter in that thread reported that after every reboot or eSIM activation, their Pixel 8 reverted to an unregistered IMS state and required manual mode-switching before calls would work again.

The 2024 complaint wave adds broader context. Following the March 2024 software update, Pixel owners across multiple carriers worldwide reported calls routing straight to voicemail, with SMS and RCS messages including bank security codes arriving in delayed batches. Forum analysis named IMS as the likely culprit, pointing specifically to VoWiFi and VoLTE regressions introduced by that update. The April 2024 update did not resolve the problem for affected users, Android Authority reported in early 2024.

The pattern across complaint threads on Reddit, X, and Google's support forums was telling: Pixel phones ignoring incoming calls and delayed texts occurred most often when the device had been sitting idle. That lines up with an IMS session dropping during inactivity and failing to re-register before the next call attempt arrives, as Android Authority noted. Voice falls out of sync while packet data stays up the two systems use different registration paths, and only one keeps failing.

Google has not publicly confirmed a root cause or issued a documented fix for these broader IMS reliability complaints.

The 464XLAT keepalive flaw (lower confidence, advanced)

This failure mode is the most technically specific and the least broadly confirmed. The evidence comes from a single developer-level bug report, with one corroborating observation on a stock Android device. It is included because the mechanism is coherent and, where it applies, the consequences are severe.

Some carriers run their networks on IPv6 but use a translation layer called 464XLAT, or CLAT, to handle services that still require IPv4. VoLTE and VoWiFi sessions depend on small, periodic keepalive packets to signal to the carrier's server that the phone is still reachable. A developer filing in the GrapheneOS issue tracker found that when CLAT is active on Pixel devices, these keepalive packets are sent with a blank destination address and get dropped at the router. Once the server stops receiving keepalives, it terminates the voice session. Incoming calls then go to voicemail or are dropped, with the phone giving no indication that the session was lost, per GrapheneOS issue #4389.

The same reporter observed the behavior on a Pixel 7 Pro running Google's standard Android software, not an aftermarket OS. That detail matters: it puts the issue in scope for general Pixel users, not just those running alternative firmware, per that same report.

Where carriers have also retired their 3G networks, a dropped VoLTE session that might be a recoverable nuisance elsewhere becomes a hard outage. The reporter noted that Telstra in Australia runs 464XLAT and has fully decommissioned its 3G network, leaving no fallback path for voice calls, per GrapheneOS issue #4389.

What remains unknown: how many Pixel users on stock Android are actually affected is not established. A commenter in the same thread noted that Google appeared to be closing the corresponding entry on its own issue tracker due to lack of response. The developer's assessment that this affects "all Google Pixels" on 464XLAT networks is not a verified finding, per GrapheneOS issue #4389.

Diagnosing your situation

The three failure modes are distinguishable by device, symptom pattern, and network configuration.

Pixel 4 or 5, with Call Assist previously active: The confirmed Take a Message bug is the candidate. Google has already disabled the feature remotely; no user action is required. Check whether automatic Call Screen remains enabled and review its documented limitations around headphone use and roaming, per Google's support page. Also confirm that expected callers are saved as contacts Call Screen uses the contacts list to decide what to screen, so unsaved numbers get handled silently while saved contacts ring through.

Pixel 6 through 8, calls fail while data and SMS work, problem worsens after idle periods: The IMS registration layer is the most likely culprit. Voice and data use separate registration paths in the calling stack; when IMS loses its session during inactivity and fails to recover, data keeps working while the phone becomes unreachable for calls. If the network mode is set to "LTE only," switching to "5G + LTE" and rebooting has resolved the failure in documented cases. Toggling Wi-Fi calling off and then on was reported to temporarily restore call reception for some affected users, per Android Authority, though the fix does not always hold.

Calls fail intermittently, carrier has retired 3G, problems occur particularly on Wi-Fi calling: The 464XLAT keepalive issue may be relevant. When CLAT is active and keepalive packets go nowhere, the carrier's server eventually drops the voice session and the phone has no way to signal that this happened. This is difficult to diagnose without packet-level tools, and there is no confirmed user-side fix. The underlying problem requires a software or carrier-configuration correction.

For anyone experiencing missed calls on current Pixel hardware, a practical sequence:

1. Check the network mode. If it reads "LTE only," switch to "5G + LTE" and reboot.
2. Toggle Wi-Fi calling off, then back on. A temporary measure, but worth trying if calls are failing intermittently.
3. Confirm that contacts you expect calls from are saved. Call Screen will not automatically screen saved contacts, per Google's documentation.
4. If failures persist on a carrier with no 3G fallback, file a bug report with Google. The 464XLAT issue requires a platform-level fix and is unlikely to be resolved through settings changes alone.

Where things stand

The Take a Message bug is confirmed and contained to older hardware. Google disabled the feature on Pixel 4 and 5 devices; it has not publicly described the underlying bug as fixed. On the IMS reliability complaints that surfaced across multiple Pixel generations and carriers starting in early 2024, and on the 464XLAT keepalive flaw documented by developers later that year, there is no equivalent public acknowledgment or confirmed resolution from Google for either.

The gap matters more as 3G disappears. On Telstra in Australia, where 3G has been fully decommissioned and 464XLAT is active, a dropped IMS session leaves a phone genuinely unreachable: no ring, no voicemail pickup, no indication that anything went wrong, per GrapheneOS issue #4389. As more carriers complete their own 3G shutdowns, the same condition will apply elsewhere. Google responded to the Take a Message bug within days of public reporting. How it responds to the IMS and 464XLAT complaints or whether it responds at all is the question worth tracking.