MeshLive 發佈 Android v0.4.0-beta，並加入 Windows beta 與實驗性 macOS 原生應用程式

A few weeks ago, I started building MeshLive, an open-source app for voice/video calls and live broadcasts over Bluetooth, without internet, SIM cards or servers.

Back then, most of the work was getting real-time video to function between two Android phones.

Now I've released Android v0.4.0-beta, added an experimental Windows beta and a native macOS implementation, and continued work on the iPhone app.

One of the demos now shows a Windows PC making a video call with an Android phone, entirely over Bluetooth.

That was quite a step up from the first two-phone prototype.

What's new in 0.4.0?

The biggest addition is relayed calls.

Previously, direct calling required two devices to be within Bluetooth range. Live broadcasts could already travel through other phones, but private calls were a different problem.

Now Android has experimental call relaying.

If two verified contacts are too far apart to connect directly, intermediate MeshLive phones can forward the call between them.

It's opt-in under Settings > Advanced, and still very much beta.

Other changes include:

• Better call setup and reconnection.
• Lower audio delay on slower Bluetooth links.
• Improved handling of unknown callers before media transmission.
• Blocking that also applies to livestreams and relaying.
• A fix for Mac calls prompting Bluetooth pairing when Hide phone name is enabled.

But the release notes are only a small part of the work.

The problem with video over Bluetooth

The biggest constraint has always been bandwidth.

On Android, MeshLive supports three media transports:

Bluetooth discovery happens over BLE regardless of the selected media transport.

The Android app uses VP9 or AV1 video and Opus audio. Its conservative video default is 240p at 15 FPS and 200 kbps.

That doesn't sound impressive next to an ordinary internet video call.

But on Bluetooth, especially when both devices are sending video simultaneously, even that can be difficult to sustain.

One video frame could delay the audio by almost a second

This was one of the more frustrating issues.

A large encoded video frame could occupy the GATT writer while smaller audio packets waited behind it.

The first fix was giving audio separate queue headroom.

That addressed the overflow, but not the underlying problem: the transport was still busy writing video.

So I experimented with splitting larger video frames into roughly 2 KB authenticated fragments and giving audio opportunities to transmit between them.

I also tested speech-led playback, because solving the send-side queue wasn't enough if late video could still increase the receiver's shared buffering delay.

In one recorded Samsung M31 ↔ ASUS GATT comparison:

The separate fragments-plus-speech-led test reduced median shared playout delay from 459 ms to 364 ms on the same phone pair.

These are measurements from specific development-build experiments, not complete mouth-to-ear latency measurements or proof that every device now passes the quality checks.

Still, they helped identify why simply increasing buffers wasn't the answer.

The fixed-fragment and speech-led approach became the default for compatible direct GATT calls. More adaptive, airtime-sized fragments remain experimental.

The technical comparison is documented in Call head-of-line A/B.

Relaying calls is harder than relaying broadcasts

For a broadcast, the source produces a stream and nearby viewers receive it.

A viewer can also forward that stream to another device.

Importantly, the forwarder doesn't need to re-encode the video for the next hop. It forwards the existing encrypted media, avoiding another encode/decode cycle for transmission.

But Bluetooth still has an airtime cost.

A relay receives packets and sends them again using its radio. Every additional viewer and hop competes for limited capacity.

Private calls make this harder because both endpoints produce audio and video simultaneously.

The relay has to move traffic in both directions while preserving the authenticated session and its timing.

MeshLive's relayed-call design keeps the intermediate phones out of the media content. They forward end-to-end encrypted packets rather than decrypting the conversation.

The endpoints retain the content keys.

There are also admission and overload protections, so a phone shouldn't keep accepting connections it cannot reasonably serve.

This is why relayed calls are still behind an experimental setting rather than being enabled for everyone.

Then came Windows and Mac

Another challenge was taking the app beyond Android.

Android, Windows and Apple's operating systems don't expose identical Bluetooth capabilities. Discovery, advertising, connection roles and permissions differ.

On Android, MeshLive uses a compact BLE announcement to advertise call and stream availability.

The Apple implementation has to handle different advertising restrictions, including representing discovery information through service UUIDs.

Desktop support also meant dealing with different connection roles instead of assuming every device could behave like an Android phone.

The protocol still needs to agree on the important things: authenticated connections, media framing, encryption and call signalling.

The Windows beta is now available, with the attached video demonstrating a call to an Android phone.

For Mac, I've added an experimental native application. It can be built from source and has working bidirectional voice/video calling with Android in the project's current implementation.

The iPhone app has also received more development, although it's still at an earlier validation stage.

I wanted the same basic idea to extend across the devices people already own, rather than requiring a separate piece of networking hardware.

Privacy also needed work

MeshLive doesn't require accounts or central servers to establish its local communication sessions.

Its security design uses signed handshakes, ephemeral key agreement and authenticated encryption. Calls and streams also have an end-to-end media encryption layer, separate from the encryption on each Bluetooth hop.

On Android, discovery identifiers rotate every 15 minutes by default, while unknown callers initially encounter a temporary identity.

In 0.4.0, the protocol also requires an unknown caller to prove possession of its claimed identity before the callee sends media. That isn't the same as proving someone's real-world identity.

Blocking now extends to broadcasts and relaying as well.

None of this makes Bluetooth communication invisible. Nearby scanners can still observe advertisements, connection metadata and traffic patterns. There is no independent security audit yet.

The full limitations are in the project's privacy documentation.

Why testing is still the biggest problem

I've tested the Android app across seven reference phones from Samsung, Xiaomi, ASUS and OPPO.

The results vary enormously depending on the phone combination.

Different chipsets, Bluetooth implementations, Android versions, codecs and connection behaviour can all change what happens.

Something working on one phone pair doesn't mean the same code will behave properly on another.

That's also been an interesting part of using AI coding tools on this project.

Most of the implementation was written with Claude Code, but the difficult part has often been reproducing failures on hardware, collecting measurements and deciding which changes actually helped.

The repository has a public device compatibility table, benchmark results and engineering decision records rather than treating a successful build as proof of reliability.

Where it stands now

MeshLive is still experimental, but it's made quite a bit of progress since the first Android beta.

There's now a Windows beta, a native Mac implementation, continued iPhone development and opt-in multi-hop calls on Android.

The long-term goal is better compatibility, lower latency and more practical communication between nearby devices without depending on internet infrastructure.

Try it or inspect the code:

• Android v0.4.0-beta and APKs
• Windows beta
• macOS and iOS source
• Technical architecture
• Engineering decisions and benchmarks

If you try it, I'd especially appreciate reports with the device models, OS versions, transport and exactly where things worked or failed.

The project is free and open source under GPL-3.0-or-later. Contributions and technical feedback are welcome.