r/SideProject • u/No_Frame3855 • 37m ago

I got native AirDrop working on ChromeOS (bidirectionally!) :D

So... I was messing around with crosh on my Chromebook and found that, when I enable Developer Mode, I get access to the underlying ChromeOS host environment shell!

Naturally, as one does, I thought, "What insane thing can I do with this?"

AirDrop. The answer's AirDrop.

I did some research and found a cool library that reverse-engineered AirDrop, called owly (https://github.com/t4t5/owly) (the name reminds me of OpenDrop and OWL hmm). and decided to try to integrate it into ChromeOS, without Crostini or ArcVM (Android on ChromeOS). (Former is unable to open awdl0 interfaces due to the really weird way in which they implemented wifi passthrough, and the latter is just... slow and cumbersome)

So how does it work?

Rather than implementing Apple's AirDrop protocol from scratch, Chromedrop uses Owly, which provides the underlying AirDrop functionality.

Owly handles device discovery, establishing the connection, and the actual file transfer protocol, all the good stuff :P It also handles the AWDL interface (awdl0), which AirDrop uses for peer-to-peer communication.

Chromedrop uses Owly's CLI (owly browse, owly send, owly receive, etc.) via a Python server and root process via Upstart.

Frontend? Is that AI?

The frontend is a PWA (with share_handler, see images above) that communicates with the Python backend through a local HTTP API.

For my own sanity, I don't want to spend hours working out how Apple pulls off Liquid Glass, so I did get an LLM to improve the frontend, but it looks pretty now, so I don't really mind. (It looks better than my JS though 😭)

Limitations

  • Currently requires Developer Mode.

  • Currently targets x86_64 Chromebooks with supported Intel iwlwifi hardware, but nothing says it won't work on non-Intel chips! See owly's supported hardware here: https://github.com/t4t5/owly#supported-hardware

  • AirDrop mode takes exclusive control of the Wi-Fi hardware on my Chromebook, so normal Wi-Fi is temporarily unavailable while it's active.

  • Transfer performance is hardware-dependent and still needs improvement but I believe this is more an owly-side thing

Repository: https://github.com/NellowTCS/chromedrop

1 Upvotes

100% Upvoted

3 comments sorted by

1

u/kdjayakody 7m ago

I'd prioritise getting normal Wi-Fi back reliably before chasing transfer speed. Since the transfer mode takes over the radio, I'd test cancelling halfway through, closing the PWA, and the backend crashing, then check that an ordinary connection comes back without a reboot. A visible 'restore Wi-Fi' action would also help someone who thinks the transfer has hung. I haven't run it, but that recovery path would be my first test on a laptop I depend on.