使用sdbus-c++监听Linux蓝牙DBus属性变更时回调未触发的问题排查

你的代码逻辑框架是对的，但有一个关键细节导致信号回调没被触发：在订阅信号后，需要确保DBus daemon已经处理完你的订阅请求，再触发会产生信号的操作。

下面是具体的修正方案和原因分析：

1. 修正代码：添加processPendingCalls()确保订阅生效 #

在调用connection->addMatch(...)之后，新增一行代码强制处理pending的DBus调用：

connection->addMatch( pattern, [](const auto &message) {
    auto objectPath = message.getPath();
    std::cout << "PATH: " << objectPath << std::endl;
});
// 新增这一行，确保AddMatch请求被DBus daemon处理完成
connection->processPendingCalls();
adapter ->callMethod("StartDiscovery")
    .onInterface("org.bluez.Adapter1")
    .dontExpectReply();

2. 原因解释 #

当你调用addMatch时，sdbus-c++会向DBus daemon发送一个AddMatch方法请求，这个请求是异步处理的。如果直接紧接着调用StartDiscovery并进入事件循环，有可能DBus daemon还没完成你的订阅注册，此时StartDiscovery触发的PropertiesChanged信号就已经发出了，你的连接自然收不到。

调用processPendingCalls()会阻塞直到所有pending的DBus请求（包括AddMatch）的回复被处理，确保你的订阅已经在DBus daemon上生效，之后再触发信号源操作，就能正常捕获到信号了。

3. 额外排查点 #

如果添加上述代码后仍然无法捕获信号，可以检查以下几点：

• 尝试简化match规则：比如去掉sender限制，用type='signal',interface='org.freedesktop.DBus.Properties',member='PropertiesChanged'测试，看是否能收到信号，排除规则匹配的问题。
• 手动触发信号：去掉StartDiscovery调用，手动操作蓝牙（比如打开/关闭蓝牙、连接设备），看回调是否触发，排除信号源的问题。
• 确认系统DBus权限：虽然dbus-monitor能运行说明权限没问题，但可以确认你的程序是否有访问系统总线的权限（默认普通用户是具备的）。

内容的提问来源于stack exchange，提问作者Marcus Hampel