Quick Share: A comprehensive deep dive into AirDrop’s rival

Lasan Mahaliyana

26 Feb 2026 — 7 min read

Let’s face it. AirDrop is amazing. It works flawlessly to share files, photos, videos, whatever across the apple ecosystem. For years, us Android folk have been missing an alternative. I really hate writing unless I have something interesting to talk about and I figured this would be worth sharing with people. Let’s get into how it works.

This write-up was inspired by the open source git repo of google’s nearby share. I’ve been following the repo’s development and am currently developing a Linux implementation on my own fork. So I’d say I know a few things about the darn thing.

The Main Components

Quick share (formerly known as Nearby Share) is primarily broken into 4 parts.

Nearby Connections
Fast Pair
Nearby Presence
Nearby Sharing

Nearby Connections

This is the brains of the operation( this sounds so corny like chatgpt wrote it ). But that’s the best way to explain it. All the other components are actually built on top of this. It handles all the wireless radios, encrypting the connections, advertising and discovering services, and the actual transmission of data packets (or frames. hmmm… I dunno how the OSI model relates to this. Who cares ¯\_(ツ)_/¯ )

The star of the show (I just had the unsettling thought that either I’m starting to write like chatgpt or chatgpt is writing like me ). This is an abstraction layer over Nearby Connections. It tells Nearby Connections what kind of advertisements to send to other devices and what kind of advertisements to listen to ( we call this discovering ). It also handles identification of remote devices and some closed source magic around sharing with only your contacts. This is the closed source part is the source of many headaches for me.

Fast pair and Nearby Presence

Fast pair is the handy dandy popup you get when you open up a fresh pair of earbuds that we’re previously paired to your devices. I’ve seen fast pair in the repo and I know it works on top of Nearby Connections but apart from that I haven’t looked too far into it.

Nearby Presence is also built on top of Nearby Connections, and the only difference with Nearby Presence and Nearby Sharing is that it doesn’t form any long lasting connections with remote devices to share data. Only listens for other devices and occasionally screams “IM HERE” so that other devices can here it.

My work currently revolves around Nearby Connections and Nearby Sharing so we’ll not talk too much about these two.

The Mediums

The Nearby Connections library provides platform-level abstractions over several mediums ( this just means that other programs using Nearby Connections don’t have to worry about the platform specific implementations for the underlying radio hardware and such )

BLE
Bluetooth Classic
Wifi LAN
Wifi Direct
Wifi Aware (aka. Wifi NAN. Super cool tech. The standard isn’t new by any means but only recently getting widespread attention by the tech community )
Wifi Hotspot
UWB ( Ultra Wide Band. Ohh yeah. This bad boy is supported as well. Although you’d have to have a pretty recent device to take advantage of this )
WebRTC ( Experimental at this stage from what I can see. But Android supports it I think)
NFC
USB
AWDL ( Apples own proprietary thing. That’s what AirDrop works over )

How it works

There are 3 main parts.

Advertising
Discovery
Connection Initiation and Bandwidth Upgrade

Advertising

This is basically saying “Hey, I’m a quick share capable device. You can share stuff with me”. There are multiple advertising mediums (we’re going to focus on the ones implemented on android here, as it represents the full capabilities of the library). You have BLE ( Bluetooth Low Energy ), Bluetooth classic and WiFi LAN. Each different advertising medium handled advertising in their own unique way. The library contains abstractions for interfacing with these different mediums.

Okay then. We advertise we’re capable of quick share. But there’s a LOT of devices that are quick share enabled these days. It wouldn’t be super helpful if whenever you wanted to share a file, every device around you popped up saying “Hi hi Hi Hi Hi hI hi hI hi hI Hi Hi”. So, every advertisements include some sort of metadata announcing what they’re device names are and exactly What sort of service they provide. Because what you have to know is that Nearby Sharing is an abstraction layer over nearby connections. And since nearby connections acts as a sort of framework for discovering and communicating with nearby devices, the nearby sharing abstraction puts a bunch of nearby sharing specific metadata into advertisements so that they we know which is which and who can share with whom.

this is what an advertisement frame looks like over BLE

If you direct your attention to the second image, you can see the 16 bit service class UUIDs and the service data fields for those respective Service IDs. The 0xfef3 service UUIDis specific to the Quick Share protocol. Anything else built on nearby connections may have other UUIDs. And the service data encodes all the metadata required ( Squint hard enough on the first image and you can make out Device-09487 . This was taken when I was testing my own implementation but if you’re actively advertising with quick share, you’ll see something like “Someone’s S23”.

And below is an example of how advertisements happen over wifi lan. You can see the _quickshare._tcp service name when I look for mDNS advertisements. ( Dude I swear to god the service name on wifi lan was an encoded mess the entire time I was working on this library and now its just cleartext? wtf happend? I go about my life for 5 days and this happens )

Discovering

Since you now know about advertising, discovery is easy. Its just looking for these specific ‘tags’ in advertising packets (frames?) they stumble upon on the airwaves. For example, if you’re looking on BLE, you’ll look for 0xfef3 service UUIDs (that is if you’re looking for quick share devices. Different services may have different service IDs ) and try decoding the service data. ( There’s an agreed upon protocol for encoding the service data so everyone who’s Nearby Connection compatible knows how to decode it ).

Forming a connection

This is where it gets complicated. Each medium has it’s own method of forming connections. We’re going to skim over how each medium does it and focus on what happens when a connection is initiated. Basically, one device listens for incoming connections and one device initiates the connection. And depending on the nature of the medium, a decision is made to either encrypt the link or not. Encryption happens on inherently insecure links like Wifi Lan and Bluetooth Classic but isn’t encrypted on links like Wifi Direct or Wifi hotspot, where a threat actor would need a passkey to even join the network. (I’m no cybersecurity expert and you should take what I say about network security with a grain of salt. All I wanted was to share files between devices. Whether attackers want to see my university lecture notes and my half naked gym progress pics is entirely up to them )

Of course initiating a connection normally happens over an “open” medium like bluetooth classic, BLE, or Wifi lan. This is because you’d need to share credentials to form a Wifi Direct or Wifi Hotspot connection. Once a connection is formed over a shared medium, keys are exchanged using ukey2 , Google’s own take own Diffie-Hellman based authentication key exchange protocol.

Next, there’s two seperate paths this link could take. Either

Link could remain as is
Link could be upgraded

Bandwidth Upgrading

The library defines several tiers of link qualities. Wifi based mediums ( Wifi Lan, Hotspot, Wifi direct are high quality links. They support the highest bandwidth ) and Bluetooth based links are generally lower quality (BR/EDR, LE L2CAP )

After forming the initial connection, the library automatically exchanges information on what each device is capable of. Using that information, either one of the devices calculates their shared capabilities and sends a BANDWIDTH_UPGRADE_NEGOTIATION frame over their shared medium. They go back and forth and exchange a bunch of data and credentials, initiate the new connection and then close the old connection.

And voila! The bandwidth is upgraded.

So much trouble. So much work just to share a simple file. That’s the thing. It doesn’t have to be this way. That’s the promise of Wifi NAN ( aka Wifi Aware ). Wifi Aware is a supported medium of Nearby Connections BTW. Although I don’t think its supported as an advertising/discovering medium for some reason. On android, it’s used as an upgrade medium.

Wifi NAN supports discovering, advertising and sharing data through NDP ( Neighbour datapath protocol or something that rhymes with it ). This isn’t a new idea either. Wifi Direct had similar ambitions when it was first introduced. There are differences sure, but the fundamental operating principle is kind of the same. I’m not well-versed enough in either of these technologies to comment on this though.

There’s a lot I can’t say about this absolute behemoth of a software library without littering it with even more unintelligible technical jargon so I’ll leave this as is for now. Feel free to reach out if you want to know more about this.

Ciao

This article was also published on Medium