Google today posted a notice on the Android Developers Blog telling app makers that the Nearby Connections API will stop automatically switching on device radios, a default behavior change scheduled for late 2026 that moves responsibility for enabling Wi-Fi and Bluetooth onto the applications themselves and, ultimately, onto the people using them.

The post, published on July 20, 2026, under the byline of Wei Wang, an engineering manager on the Android team, frames the update as an alignment with privacy and transparency principles. According to Google, the shift is narrow in scope but specific in effect. The API previously held the ability to toggle Wi-Fi and Bluetooth radios into the ON state on its own, without any explicit action from the person holding the phone. That capability is being withdrawn.

What is changing

The mechanism at issue is a piece of plumbing most Android users never see. Nearby Connections is a peer-to-peer networking API that lets applications discover, connect to, and exchange data with other devices in physical proximity, and it does so without needing an internet connection at any point. Under the hood it draws on a combination of Bluetooth, Bluetooth Low Energy, and Wi-Fi, selecting among them to balance range, bandwidth, and power draw. To make that work, the radios have to be on.

Until now, the API could handle that prerequisite quietly. If Wi-Fi or Bluetooth sat in the OFF position when an app tried to begin advertising its presence or discovering other devices, the API could flip the necessary radio on and proceed. According to Google, that automatic behavior is ending for both first-party and third-party applications, described in the documentation as 1P and 3P apps. The distinction matters because it signals that Google is not carving out an exception for its own software; the same constraint applies across the board.

The reasoning Google offers is stated at the top of the notice. The company writes that user privacy and transparency are core to the Android experience, and that the update to the default behavior is meant to better align the API with those principles. A radio switching on without a visible prompt is, in this framing, a transparency gap. Bluetooth and Wi-Fi are not merely connectivity tools; they are also signals that can be used to infer proximity, presence, and in some configurations location. Turning them on silently means a device begins emitting and scanning for those signals without the person necessarily knowing it happened.

What this means for developers

For the engineers who build on Nearby Connections, the change converts an automatic step into a manual one, and it introduces a new obligation to communicate with the user. Google lays out two specific requirements.

The first is manual radio management. Applications must now ensure that the required radio, whether Wi-Fi or Bluetooth, is enabled before initiating any Nearby Connections task. The API will not do this on the app's behalf. In practice, this means an application has to check radio state as a precondition and cannot assume connectivity will be arranged for it.

The second is user notification. If the radios an app needs are disabled, the application must inform the person and request that they enable the radios manually. According to Google, the API will no longer programmatically turn them on. The burden of prompting, explaining, and waiting for a human decision now sits inside the application's own code and interface.

The categories of software affected are broad, because the use cases Nearby Connections supports are varied. Google's own documentation lists examples including collaborative whiteboards where nearby participants jot ideas on a shared virtual surface, local multiplayer gaming sessions where users invite others in the same room to join, multi-screen gaming that turns a phone or tablet into a controller for a game shown on a nearby large-screen device such as an Android TV, and offline file transfers that move photos or videos between devices without any network connection. Each of these depends on the radios being available, and each will now need to account for the possibility that they are switched off and that the user must be asked to switch them on.

The technical footprint of the API extends further than these headline examples. The get-started documentation for Nearby Connections requires developers to declare a substantial set of permissions in the AndroidManifest.xml file, spanning Wi-Fi state access, Bluetooth administration, and location. Several of these, including fine location and the Bluetooth advertise, connect, and scan permissions, are classified as dangerous system permissions and must be requested at runtime rather than merely declared. The API returns nothing useful if the user declines them. The new radio behavior layers an additional gate on top of that existing permission structure: even with permissions granted, the physical radios must be on, and getting them on is now a conversation the app must initiate.

Timing and the transition window

Google states that the changes are scheduled to take effect in late 2026. The company recommends reviewing connection workflows now to ensure what it calls a seamless transition for users. No precise date within that window is given in the notice, and no staged rollout schedule accompanies it. The instruction is to prepare ahead of an effective date that has been signaled but not pinned down.

That imprecision is itself worth noting. Developers are being asked to modify implementations against a deadline described only as late 2026, which leaves the exact moment of enforcement open. For teams maintaining apps that lean heavily on Nearby Connections, the practical consequence is that testing and code changes need to happen on a timeline that assumes the earlier end of that range, since the alternative is discovering at runtime that connections silently stopped working because a radio was off and no one asked to turn it on.

Why this matters for the marketing and advertising community

The change sits inside a longer pattern that trade coverage has documented across the mobile ecosystem, in which platform owners progressively remove implicit data-adjacent behaviors and replace them with explicit, user-visible steps. The direction of travel is consistent, and it has direct implications for anyone whose business depends on device signals.

Bluetooth and Wi-Fi are not advertising tools in the way a cookie or a mobile identifier is, but proximity and presence signals derived from them have long been of interest to the marketing technology field, particularly in retail and location contexts. When a platform makes it harder to activate those radios without a person's knowledge, it constrains the raw material available for any downstream use, whether that use is a legitimate file transfer or a proximity-based measurement scheme. The Android team's stated rationale, that silent radio activation is a transparency problem, aligns the API's default with the same logic regulators have applied to tracking more broadly.

That regulatory logic has been visible in adjacent enforcement. Apple's App Tracking Transparency framework drew a €150M fine from the French competition authority, with the regulator concluding that the ATT prompt did not collect valid consent under GDPR and French data protection law and that its asymmetric design undermined truly informed consent. The Nearby Connections change is not a consent-framework overhaul of that magnitude, but it moves in the same direction: away from behaviors that happen invisibly and toward behaviors a person must knowingly authorize.

Google and Apple have also collaborated directly on proximity-signal safety, jointly developing an industry standard called Detecting Unwanted Location Trackers, which alerts users on both iOS and Android when an unknown Bluetooth device appears to be traveling with them. That effort addressed the misuse of Bluetooth trackers such as AirTags; the Nearby Connections update addresses a different vector, the silent activation of the radios themselves, but both reflect a platform-level concern about Bluetooth as a channel that can operate without a person's awareness.

The change also fits the broader tightening of Google's own developer surface. On the advertising side, Google has been consolidating and constraining its developer tools in parallel, taking IP addresses into Customer Match through the Data Manager API while carving out the EEA, UK, and Switzerland, and blocking new offline conversion imports through the Ads API for tokens that cannot demonstrate active use. Google Play developers face a 25 percent fee under a restructured pricing model that split the service fee from the billing fee. Each of these is a distinct policy, but together they describe a platform owner actively reshaping what developers can and cannot do by default, and on what terms.

For product and engineering teams inside marketing technology vendors, the operational point is concrete rather than strategic. Any application in a portfolio that uses Nearby Connections for device-to-device features, whether for content sharing, in-store experiences, or event-based interactions, will need code changes before late 2026. The API will no longer paper over a disabled radio, and the user-facing prompt to enable it becomes part of the product experience that has to be designed, not an implementation detail that the platform handles out of sight.

The transparency framing in context

What Google is describing is a small default change with an outsized symbolic weight. The company is not removing Nearby Connections, not altering its data-transfer capabilities, and not changing the permission model that governs it. It is removing one specific automatic behavior, the ability to turn a radio on without asking, and replacing it with a requirement to ask.

According to Google, the goal is alignment with privacy and transparency principles that the company positions as core to Android. Whether that alignment produces meaningful privacy gains or simply relocates a friction point onto users and developers is a question the notice does not address. What the notice does make clear is the mechanism, the affected parties, and the rough timeline: automatic radio activation ends, first-party and third-party apps alike must manage radios manually and prompt users when they are off, and the change takes effect in late 2026.

Timeline

Summary

Who: Google, through its Android team and under the byline of Wei Wang, an engineering manager, issued the notice affecting every developer who builds on the Nearby Connections API, spanning first-party and third-party applications.

What: The Nearby Connections API will stop automatically switching Wi-Fi and Bluetooth radios into the ON state. Developers must instead ensure the required radios are enabled before starting connection tasks and must prompt users to enable radios manually when they are disabled.

When: Google published the notice on July 20, 2026. The behavior change is scheduled to take effect in late 2026, with no more precise date specified.

Where: The change applies at the Android platform level, inside the Nearby Connections peer-to-peer networking API that operates over Bluetooth, Bluetooth Low Energy, and Wi-Fi for offline device-to-device communication.

Why: Google states the update aligns the API with privacy and transparency principles it positions as core to the Android experience, ending the silent activation of radios that can emit and scan for proximity and presence signals without a person's explicit knowledge.