我很确定我在AudioServerPlugIn中遇到了同样的问题。我可以查看并使用我尝试过的每一个Mach服务,除了我创建的服务。我创建的那些工作通常来自常规流程。
最后我读了 Daemonomicon 并想通了 coreaudiod (托管HAL插件)使用全局引导命名空间,但我的服务是在每用户引导程序命名空间中注册的。从那以后 “使用全局命名空间的进程只能看到全局命名空间中的服务” 我的插件无法看到我的服务。
coreaudiod
您可以使用 launchctl 通过让它运行注册您的服务的程序来测试它,但具有相同的引导命名空间 coreaudiod 。您可能需要禁用无根。
launchctl
# launchctl bsexec $(pgrep coreaudiod) your_service_executable
运行后,尝试再次从您的插件连接。
从Daemonomicon中的表2可以看出,只有launchd守护进程使用全局引导命名空间。这解释了原因 coreaudiod 使用它。我认为这意味着您的Mach服务需要由launchd守护进程创建。
制作一个,创建一个 launchd.plist 为您服务 /Library/LaunchDaemons 。将其所有者设置为 root:wheel 并使其只能由所有者写入。在其中,设置 MachServices 键并添加您的服务名称:
/Library/LaunchDaemons
root:wheel
MachServices
<key>MachServices</key> <dict> <key>com.mycompany.audio.XPCService</key> <true/> </dict>
然后注册:
# launchctl bootstrap system /Library/LaunchDaemons/com.mycompany.audio.XPCService.plist
这就是我最终得到的结果: com.bearisdriving.BGM.XPCHelper.plist.template 。请注意,没有 UserName / GroupName 密钥你的守护进程将以root身份运行。 (代码为 我的服务 和 插入 也是在那个回购中,如果有帮助的话。)
UserName
GroupName
不幸的是,我最终不得不使用XPC,但我首先尝试了CFMessagePort并且工作正常。
无论插件是否签名,似乎一切正常。虽然,正如你所说,你确实需要 AudioServerPlugIn_MachServices 密钥在您的Info.plist中。
AudioServerPlugIn_MachServices