HarmonyOS 鸿蒙Next的mDNS API (addLocalService) 疑似存在Bug，无法广播 serviceAttribute (TXT记录)

HarmonyOS 鸿蒙Next的mDNS API (addLocalService) 疑似存在Bug，无法广播 serviceAttribute (TXT记录) [我的目标]

我正在尝试在HarmonyOS上创建一个兼容AirPlay的投屏服务接收端。为了能被iPhone或Mac发现，我的应用必须广播一个带有特定TXT记录的mDNS服务。

[我的实现方法]

我使用了 @ohos.net.mdns.addLocalService API 来广播 _airplay._tcp 服务。我完全按照官方文档的格式，在 LocalServiceInfo 对象中提供了 serviceAttribute 属性，其中包含了 model, features 等多条TXT记录，并确保所有 value 都按要求转换为了字节数组 number[]。

[遇到的问题]

API调用成功，服务名可以在局域网内被发现，但 serviceAttribute 中提供的所有TXT记录都未能被广播出去。

[我如何验证]

我使用了macOS的原生命令行工具 dns-sd -L “MyService” _airplay._tcp local. 对广播的服务进行详细查询。结果显示，我广播的服务只包含了IP地址和端口信息，没有任何TXT记录数据。作为对比，网络上其他正常的AirPlay设备（如Apple TV）均能通过此命令显示出详细的TXT记录。

[我的结论]

这有力地证明了问题在于 addLocalService API未能正确处理和广播 serviceAttribute 参数。这很可能是一个系统级的API Bug或功能限制，导致所有依赖TXT记录的服务（如AirPlay）无法被正确实现。

请问有没有人遇到过类似问题？或者官方能否确认一下这是不是一个已知的问题？


更多关于HarmonyOS 鸿蒙Next的mDNS API (addLocalService) 疑似存在Bug，无法广播 serviceAttribute (TXT记录)的实战教程也可以访问 https://www.itying.com/category-93-b0.html

5 回复

关于您的反馈的问题，这边用您提供的代码是可以正常发送TXT信息，以下是用wireshark抓包，发现包含TXT，请您再确认一下呢。

Multicast Domain Name System (response)

    Transaction ID: 0x0000

    Flags: 0x8400 Standard query response, No error

    Questions: 0

    Answer RRs: 3

    Authority RRs: 0

    Additional RRs: 0

    Answers

        _airplay._tcp.local: type PTR, class IN, cache flush, CastMaster._airplay._tcp.local

            Name: _airplay._tcp.local

            Type: PTR (12) (domain name PoinTeR)

            .000 0000 0000 0001 = Class: IN (0x0001)

            1… … … … = Cache flush: True

            Time to live: 0 (0 seconds)

            Data length: 13

            Domain Name: CastMaster._airplay._tcp.local

        CastMaster._airplay._tcp.local: type SRV, class IN, cache flush, priority 0, weight 0, port 7000, target localhost1369519539.local

            Instance: CastMaster

            Service: _airplay

            Protocol: _tcp

            Name: local

            Type: SRV (33) (Server Selection)

            .000 0000 0000 0001 = Class: IN (0x0001)

            1… … … … = Cache flush: True

            Time to live: 0 (0 seconds)

            Data length: 28

            Priority: 0

            Weight: 0

            Port: 7000

            Target: localhost1369519539.local

        CastMaster._airplay._tcp.local: type TXT, class IN, cache flush

            Name: CastMaster._airplay._tcp.local

            Type: TXT (16) (Text strings)

            .000 0000 0000 0001 = Class: IN (0x0001)

            1… … … … = Cache flush: True

            Time to live: 0 (0 seconds)

            Data length: 75

            TXT Length: 26

            TXT: deviceid=AA:BB:CC:DD:EE:FF

            TXT Length: 15

            TXT: features=0x39f7

            TXT Length: 16

            TXT: model=AppleTV2,1

            TXT Length: 14

            TXT: srcvers=130.14

    [Unsolicited: True]

更多关于HarmonyOS 鸿蒙Next的mDNS API (addLocalService) 疑似存在Bug，无法广播 serviceAttribute (TXT记录)的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


楼主用的api版本和系统是多少？

官方看估计也需要确认下这个

5.0.5(17)
5.1.0.150 (SP3C00E128R1P1patch05)

针对HarmonyOS鸿蒙Next的mDNS API中addLocalService方法无法广播serviceAttribute（TXT记录）的问题，初步分析可能是SDK内部对TXT记录的处理存在缺陷。具体表现为服务注册过程中属性键值对未正确封装或发送，导致接收端无法解析。建议检查服务配置参数是否符合规范，并确认网络权限配置正确。该问题需通过系统更新修复。

根据你的描述，确实可能是 addLocalService API 在处理 serviceAttribute 时存在问题。TXT记录对于mDNS服务发现至关重要，尤其是在AirPlay这类协议中。建议检查以下几点：

  1. 确认 serviceAttribute 的格式符合RFC 6763标准，键值对需转换为字节数组，例如 "model=AppleTV" 应转为 [109, 111, 100, 101, 108, 61, 65, 112, 112, 108, 101, 84, 86]。
  2. 验证是否所有属性值均为非空且长度正确。
  3. 尝试使用Wireshark抓包分析mDNS报文，确认TXT记录是否在协议层被正确封装。

如果以上均无误，可能是HarmonyOS Next的mDNS实现存在缺陷。建议通过官方渠道提交Bug报告，附上代码片段和抓包结果，以便华为团队排查。目前暂未看到社区有类似反馈，但你的测试方法严谨，结论可信。

回到顶部