A Rust implementation of Android's Binder

All D-Bus implementations support peer-to-peer channels that don't go through the D-Bus server/broker. You set up the channel through the shared bus, and then talk to the peer using the same wire protocol.

The main advantage of D-Bus is, unsurprisingly, the shared bus, so you get multicast; the other advantage is the service activation—though that got kind of superseded by systemd though a similar mechanism: talk to a well-known name on the bus, the service that provides the name gets activated if it's not already running. For that, you need a central broker.

There are a couple of ways D-Bus can be used without a message bus (broker). There is nothing magic about D-Bus from the kernel's perspective: it's just an application-layer protocol over AF_UNIX sockets, like X11, Wayland, Pulseaudio and Pipewire.

Many of the conveniences that are reasons to use D-Bus are really message bus features - distributed naming, broadcast/multicast signals, authentication, service activation with auto-starting, imposing a total order on messages to make them easier to reason about - and bypassing the message bus means reduced access to those conveniences. It's up to an individual application/interface author whether that's a worthwhile tradeoff or not.

The other big reason to use D-Bus is not needing significant incremental work to add more communication with some other component that already uses D-Bus (network effect): in the freedesktop.org ecosystem, if components can agree on using D-Bus for multiple forms of communication that don't have particularly demanding latency or throughput requirements, then that avoids reinventing too many wheels for those forms of communication, allowing the time saved to be re-invested in places where it matters more. Again, that's really more of a message bus feature than a protocol feature. I assume that in Android, there's a similar pressure to use Binder as a "default" IPC mechanism in any situation where there's no particularly good reason to do otherwise.

For situations where the message bus would be a problem, one way to bypass it is that the D-Bus wire protocol can be used as message framing for a simple client/server protocol over AF_UNIX or even TCP, with clients talking directly to the server. systemd does this, over AF_UNIX (the server listens on /run/systemd/private), so that its components can communicate during early boot before the message bus is available. This lets services reuse the D-Bus message framing and type system, which is particularly useful if they already needed that code for some other reason (for example systemd provides more normal D-Bus services over the message bus after it becomes available, so it would have needed access to a D-Bus implementation anyway).

Another way to bypass the message bus without abandoning D-Bus completely is that two peers initially communicating via the message bus can use it to negotiate a side channel, either via fd-passing (using SCM_RIGHTS to attach file descriptors to a D-Bus message) or by sharing the address of a socket in the filesystem, and then do their latency- or throughput-sensitive communication through that side channel, either reusing the D-Bus message framing and type system or switching to some other protocol that is more optimal for what this particular application wants. They can either move their entire communication into the side channel, or continue to use the message bus for "control" messages that are less sensitive to latency/throughput.