NearShare reimplements Project Rome so Android can join Windows sharing

The protocol, not the feature

The repository describes itself precisely, and the precision matters for understanding what it is. It contains a fully functional implementation of the MS-CDP and NearShare protocols, and those protocols are what power the Windows 10 and newer built-in sharing functionality, which is also known as Project Rome.

So this is not a wrapper around something Microsoft provides. It is a from-scratch implementation of the wire protocols, on the Android side, for a feature that Microsoft ships only on Windows. The topic tags reflect the same picture, with nearby, nearby-sharing, nearshare, project-rome, airdrop, bluetooth and wifi listed.

The project is called NearShare. The README links an Android app on Google Play, an F-Droid repository hosted for this project, the GitHub releases, and a download page for other platforms, so the repository is the source for a shipped application rather than a library another team would import.

The interesting question for an engineer is where the boundary of the work is. The MS-CDP specification is a Microsoft open specification for the Connected Devices Platform, and the NearShare protocol sits on top of it. Implementing them means reimplementing the discovery, negotiation and transfer behaviour that a Windows PC expects from a participant, which is why the repository is a protocol implementation with a mobile app on the front rather than a set of reusable pieces.

The audience is therefore narrower than the topic suggests. Someone who wants a file on their Windows laptop and does not want to install a file-sharing app that asks for broad storage access has a real use case here, and the F-Droid listing suggests the project is aimed squarely at people who care about that.

Building it needs the .NET and Android toolchains

The project consists of a .NET 9 library and Android projects, and there are two routes to a build. The README points at the Visual Studio solution and at the dotnet command line tool, and the command line route is two lines:

cd src
dotnet run

That is short, but the repository layout shows what is behind it. There is a NearShare.slnx solution file, and the newer XML-based solution format, alongside a src directory for the app, a lib directory, a utils directory, a tests directory and a docs directory. There are also Directory.Build.props and Directory.Build.targets for shared build settings, a dockerfile.test, a testenvironments.json, and a toc.yml and docfx.json for the documentation site.

The .NET side and the Android side are separate projects, so a build needs both the .NET SDK and the Android tooling, which is what the Visual Studio route provides out of the box. The dotnet run form assumes the Android project and its workload are already configured.

A few other files are worth noticing because they describe how the project is run rather than what it does. A crowdin.yml means the user-facing strings are translated through Crowdin, which is a sensible arrangement for an app with an international audience. CREDITS.md at the root records attribution, and the .gitmodules file means some dependencies arrive as git submodules, so a clone without recursion will not build.

The docs directory holds the documentation and a contributing guide, and the README points contributors at docs/CONTRIBUTING.md for the specifics of getting a change merged.

Three ways to get the app, and what each one costs you

The README links four destinations, and the differences between them are about trust and platform rather than about features.

There is the Google Play listing, the F-Droid repository hosted on the project's own domain, the GitHub releases, and a download page for other platforms. The Play listing is the ordinary route and the one most people will take.

The F-Droid repository is the interesting one. F-Droid is a free software app repository that builds from source, and hosting a repository for this project means the maintainers publish the build recipe rather than a prebuilt binary. For a user who does not want to install an app from an unknown store, that is the whole point, and it also means the build is reproducible from the repository rather than trusted on the maintainer's word.

The other-platforms page suggests the protocol work is not Android-only in principle. The README says this repository holds the Android implementation, and the topics list includes xamarin, so the codebase has been used from a .NET cross-platform stack as well. A .NET 9 library and an Android app in the same repository is consistent with that.

The releases are the GitHub ones, and the most recent published versions are v1.11.1 on 2026-05-21, v1.11.0 on 2026-02-25 and v1.10.1 on 2025-10-21, so the line moves on a scale of weeks or months rather than days. The last push to the repository was on 2026-10-13, which means the branch carries work that is not in the newest packaged build.

GPL-3.0, and what that means beyond the app

The project is licensed under GPL-3.0, with the terms in LICENSE.md at the root, and the README says so directly. The licence file on GitHub resolves to a file named LICENSE.md, and the README also links CREDITS.md, which is the attribution file that usually accompanies a copyleft project with third-party code.

For an end user installing the app on a phone, GPL-3.0 has no practical effect. You install it, you use it, nothing is asked of you.

For anyone thinking of building on the code, the effect is significant. GPL-3.0 is a strong copyleft licence: if you take this code and produce a derivative work, that derivative has to be distributed under the same terms, with the corresponding source available. For a company shipping a product that includes this implementation, that is a real constraint, and it is a different kind of decision from choosing MIT for a small library.

The counterweight is that the licence is what makes the project usable at all in the way it is intended. A protocol implementation only has value if both sides can speak it, and the Windows side of nearby sharing is Microsoft's own implementation, which is why the Android side has to be an independent reimplementation in the first place. The copyleft keeps the improvement work in the open, where the next person who needs an Android participant can find it.

None of that is legal advice. It is the shape of the trade: the licence protects the ecosystem that makes the project worth using, and it is the reason a commercial embedder should think twice.

What this cannot do

The limits here are structural, and they follow from the protocol being a Windows feature.

The first is that a Windows machine has to be involved. This is a reimplementation of what Windows 10 and 11 do natively, so there is no Apple equivalent to talk to and no Linux peer. The multi-platform download page suggests the library can be reused, but the ecosystem it plugs into is Microsoft's.

The second is that Windows nearby sharing has to be present and configured on the other side. The protocol assumes a PC with the feature turned on, discoverable, and willing to accept. A PC with the feature disabled, or on a network where discovery cannot reach it, is a transfer that never starts, and the failure is on the Windows side rather than in this implementation.

The third limit is the discovery and transport substrate. The topic list names bluetooth and wifi, which are what the Windows implementation uses to find and connect to nearby participants. Those are the parts most sensitive to firmware, drivers and network configuration, and they are the parts a reimplementation cannot make behave better than the original. A transfer that fails on a corporate wifi or a machine with a broken Bluetooth stack fails for everyone.

The practical consequence is that this project removes the need for a third-party file transfer app on the phone, and it does not remove the constraints of nearby sharing itself. If the problem is that you do not want to give a file-sharing app broad access to your storage, this is a good answer. If the problem is that nearby sharing is unreliable on your particular setup, no Android implementation will change that.

Editorial conclusion

nearby-sharing/android suits an Android user who wants to send a file to a Windows machine over the same nearby sharing the PC already has, and who is willing to install an app outside the Play Store if F-Droid is not an option. It is the wrong tool for a person with no Windows device in the loop, since the whole protocol is a Windows-side feature, and the wrong tool for a team that needs an iPhone to take part, because the protocol is implemented against the Windows behaviour specifically. Before you adopt it, check the platform the app builds for and the release cadence, since the most recent release is v1.11.1 from 2026-05-21 while the last push was on 2026-10-13, and read the GPL-3.0 terms before you consider shipping any part of it inside a product.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. nearby-sharing/android on GitHub
3. Project website
4. README
5. Releases