As per RFC 1034/1035, the max size of the label is 63 bytes. It should
also be guaranteed when the serviceName is renamed due to the conflict.
Bug: 265865456
Test: atest FrameworksNetTests
Change-Id: I077d8abdb91071db62b9618d9918e3a12682aaf4
MdnsSocketProvider currently does not fill addresses of downstream
tethering interfaces in its callbacks. The interface addresses should be
properly updated by listening to the Netlink messages.
Test: atest FrameworksNetTests CtsNetTestCases
Bug: 267980538
Change-Id: I753e547a1b092703fe59c6c9e922ee8aca245f67
INetd.LOCAL_NET_ID cannot be referred to by system SDK. To make the
MdnsSocketProvider built with system SDK, the reference to
INetd.LOCAL_NET_ID must be removed.
This network is created in MdnsSocketProvider.java and propagated
through MdnsSocketProvider.java -> MdnsMultinetworkSocketClient.java ->
MdnsDiscoveryManager.java -> MdnsServiceTypeClient.java ->
NsdService.java. In NsdService.java, it was used in
handleMdnsDiscoveryManagerEvent() -> buildNsdServiceInfoFromMdnsEvent()
-> setServiceNetworkForCallback(). The setServiceNetworkForCallback() is
updated to handle the NETID_UNSET the same as LOCAL_NET_ID.
Test: atest CtsNetTestCases FrameworksNetTests
Bug: 272392042
Change-Id: I07c573948e9dc6249325f0733807bb7a7ffc281c
Link local Inet6Address cannot be used without scope id being set
properly. NsdService should set the Inet6Address scopes everywhere
NsdServiceInfo.setHost or NsdServiceInfo.setHostAddresses is used.
Test: atest CtsNetTestCases:android.net.cts.NsdManagerTest
Bug: 273391977
Change-Id: I45da6aebeba4e2e398e0b58ce3b88470fb60863b
Apps targeting sdk < U are considered to use a legacy native
daemon as NsdManager backend, but other apps use a
platform-integration mDNS implementation as backend. So add a
CompatChange flag to enable platform backend for non-legacy
apps.
Bug: 270306772
Test: atest FrameworksNetTests CtsNetTestCases
Change-Id: I7ba58f8a5186fb49ad5f8aeacc8b8234bef1eabe
Instead of using the old mdnsresponder backend, U+ uses
MdnsDiscoveryManager and MdnsAdvertiser.
Bug: 272197605
Test: atest NsdManagerTest
Change-Id: I53ebf1bbba24972e4db87eb4097497329b05caa9
Now, the multiple addresses is supported in resolution service
with the new java backend. Thus, fill in all resolved addresses
into NsdServiceInfo.
Bug: 268586836
Test: atest FrameworksNetTests
Change-Id: I499a749255429df9fe9fbad678074ad383159240
registerServiceInfoCallback currently only sends updates for
addresses added, but does not handle removes (expiration) and
TXT/SRV record updates. Thus, migrate its backend to
MdnsDiscoveryManager which can support the expiration update.
Bug: 266030646
Test: atest FrameworksNetTests CteNetTestCases
Change-Id: I72add213935dc1beacb6277007868ad30bd89c00
The flags allow enabling MdnsDiscoveryManager or MdnsAdvertiser for
specific service types only. For example:
mdns_type_allowlist_flags = "_type1._tcp:flag1,_type2._tcp:flag2"
mdns_discovery_manager_allowlist_flag1_version = 1234
mdns_advertiser_allowlist_flag2_version = 2345
will enable MdnsDiscoveryManager when discovering/resolving services of
type _type1._tcp, and MdnsAdvertiser when advertising services of type
_type2._tcp.
Test: atest NsdServiceTest
Bug: 270885892
Change-Id: I75c31a28472210bf8777409ea7aff1e3d8bf0a0d
The service type that found from NsdManager#discoverServices()
with old backend(mDnsResponder) has an extra dot at the end. And
the previous API accepted both formats, so we need to keep
backwards compatibility with both formats. Thus, drop that extra
dot when constructing the service type for the new backend.
Bug: 266030646
Test: atest FrameoworksNetTests
Change-Id: I987ab866f6a3a7cff654f96978057fdd93b859d6
* changes:
Return ERROR_NO_ANSWERS for replies with no answer
Allow resolving previously undiscovered services
Use resolveInstanceName in NsdService
Add missing SRV/TXT/address records to responses
Update record TTL in set/add methods
Clear inetaddress fields when removing the record
The resolveService() uses new mdns backend if the
MdnsDiscoveryManager feature is enabled. So the new API
stopServiceResolution() should have new mdns backend
implementation as well.
Test: atest FrameworksNetTests
Change-Id: I73fa9ca71c0afc5db99db9252f4c030d4f2b8066
For resolve requests, specify the resolveInstanceName in
MdnsSearchOptions.
This will cause discovery to send followup queries when TXT/SRV/A/AAAA
records are missing; for example if only a PTR record is returned
following the discovery probes, or if no discovery probe is sent at all.
Test: atest NsdServiceTest
Bug: 267570781
Change-Id: Ib18c3afbd1533ada7a78dd8ccac993adb439d014
The resolveService() uses new mdns backend if the
MdnsDiscoveryManager feature is enabled. So the new API
stopServiceResolution() should have new mdns backend
implementation as well.
Test: atest FrameworksNetTests
Change-Id: I591e78180f530daa701e0970860f7471f5f5fb9a
Now MdnsSocketProvider is stopped when there is no client request
left in NsdService, but this does not trigger
SocketCallback.onInterfaceDestroyed callbacks. If the network of
the socket is then lost while MdnsSocketProvider is not
monitoring, no callback will be fired. Users of the socket
(MdnsDiscoveryManager and MdnsAdvertiser) may keep using it
without ever getting notified. So ignore the stop and wait until
all sockets are unrequested. Then the socket destroy should be
notified to all users.
Bug: 267978487
Test: atest FrameworksNetTests
Change-Id: I7a8bb0550262fe397b91f1236a8dbca1cf2c7518
Allow toggling MdnsAdvertiser and MdnsDiscoveryManager at runtime, by
always creating them in NsdService constructor, but only using them when
the flag is on when starting discovery, resolve or registration.
When stopping, based on the type of the stored request, stop the
corresponding backend.
Bug: 265891278
Test: atest NsdServiceTest
Change-Id: I7cb2f9fe9e1ed3dc77616689a8e3ffa00f5bc269
Instead of using three mClientIds, mClientRequests, mListeners
SparseArrays, use one array containing different subclasses of
ClientRequest.
This avoids having three arrays with mostly the same keys, and makes it
easier to differentiate requests for mdnsresponder, MdnsAdvertiser and
MdnsDiscoveryMaager.
It will also allow supporting having some requests using mdnsresponder,
and some other requests using MdnsAdvertiser or MdnsDiscoveryManager.
This is necessary to allow enabling/disabling the MdnsAdvertiser and
MdnsDiscoveryManager features without reboot.
There is a slight change in logging when DBG=true for ClientInfo:
Before:
Exceeded max outstanding requests mResolvedService null
mIsLegacy false
clientId 2 mDnsId 2 type 1
After:
Exceeded max outstanding requests mResolvedService null
mIsLegacy false
clientId 2 mDnsId 2 type NsdService$LegacyClientRequest
Bug: 265891278
Test: atest NsdServiceTest
Change-Id: Ibfb9bb5a61960ca635126b4a492fa0441484aa95
When registering and advertising a service on the same device, it is
possible for NsdService to find the service on the dummy0 interface. It
is however unusable and not resolveable.
Skip callbacks on the dummy0 interface as they would confuse apps and
tests.
Bug: 266176036
Test: atest NsdServiceTest
Change-Id: I98cca0135e0f6936187d45707cbdad7a7f263ff1
Currently, the resolution is a one shot query, it only notifies
the first finding service information. There is no way to listen
the service update. Thus, add a new API that can register a
callback to listen to the service updates continuously.
Bug: 245369943
Test: atest FrameworksNetTests CtsNetTestCases
Change-Id: I0e9d92b9028375feb3e344ab6c4acb515c5b2be9
Based on a flag, use MdnsAdvertiser for advertising instead of the
legacy mdnsresponder implementation.
Bug: 241738458
Test: atest NsdServiceTest
Change-Id: I2d5069097c11f2959e3792cac326d179a3116479
Resolve service may take long time due to network issue or
using wrong service information, but users are not able to stop
it. They can only wait for the callback of resolveService to end,
which sometimes takes a long time. Thus, add the new API that
users can stop the service resolution.
Bug: 245369943
Test: atest FrameworksNetTests CtsNetTestCases
Change-Id: I6b6183c8c73f8db981b9afa51fbc73bf886d9ed3
Service resolved should be notified when receive the
onServiceFound callbacks from MdnsServiceBrowserListener
Bug: 254166302
Test: atest FrameworksNetTests CtsNetTestCases
Change-Id: I681720065084bf3449c5b1ab44cd4ed6a659dcdb
Service lost should be notified when receive the
onServiceNameRemoved callbacks from
MdnsServiceBrowserListener.
Bug: 254166302
Test: atest FrameworksNetTests
Change-Id: I298816ac186efeda85cea4cd11f3beab6b341bc5
Service found should be notified when receives the
onServiceNameDiscovered callbacks from
MdnsServiceBrowserListener.
Bug: 254166302
Test: atest FrameworksNetTests CtsNetTestCases
Change-Id: I3f41b4fe85cd85ad356fa764663187a88914412c
Create the MdnsDiscoveryManager for mdns discovery and resolution
if the feature is enable.
Bug: 254166302
Test: atest FrameworksNetTests CtsNetTestCases
Change-Id: I4d7591b50cb06f0efcc0dde9834b775c513cceff
If the binder death notification for a INsdManagerCallback was
received before any calls are received by NsdService, the
clientInfo would be cleared and cause NPE. Thus, add a null check
to prevent crash.
Bug: 241741274
Test: atest FrameworksNetTests
Change-Id: Iebe761cd579bf3ee46ead389620bed60a21e3154
In order to increase the line coverage for the Connectivity
module, remove the DisabledState from NsdService which is
uselss for a while.
Bug: 234315786
Test: atest FrameworksNetTests CtsNetTestCases \
ConnectivityCoverageTest
Change-Id: I29c7ef608d97037084b25daa70ad5829f474e20a
Tethering downstreams do not have NetworkAgents, and although they have
a netid of 99, Networks with netId 99 are not usable by apps for most
connectivity APIs.
Recent refactoring in NsdService adds the Network of a found service
into its NsdServiceInfo, and uses that network to resolve the service.
In that case the Network has netId 99 and resolving the service fails.
Avoid that problem by:
- Keeping the Network field null when a service is found on a tethering
downstream; this avoids giving apps a confusing and unusable Network
with netId 99
- Using the interface index found during discovery to resolve the
service, if the app uses the NsdServiceInfo that was obtained from
discovery to resolve. If not, all interfaces will be used to resolve,
as per legacy APIs.
Bug: 233979892
Test: atest NsdServiceTest
Also manual test with 2 devices connected via hotspot
Change-Id: Idd176153b67ccbd1d4f1b1fd66dafaa2f3a9e27a
The service name can include non-ASCII characters. So
NsdService need to have specific handling for these non-ASCII
characters that make resolution working properly.
Note: The unescape() method is the same one that was used in S,
but was removed by mistake.
Bug: 230698801
Test: atest FrameworksNetTests CtsNetTestCases
Change-Id: I42fc5618aa2d549ceae25f516ad17c78930ea41d
Currently, NsdManager registers services on all interfaces when
one network was specified in NsdServiceInfo. It's unexpected
behavior. The service should be only advertised on specified
network. Thus, correct the behavior on NsdService and add cts
test to verify it.
Bug: 220070737
Test: atest CtsNetTestCases:android.net.cts.NsdManagerTest
Change-Id: Ief3bfa110bfa340c53edec561eb5376f6bd305e6
- NsdService isn't using NativeDaemonConnector to connect to
mdnsresponder after aosp/2049246, so NsdService#create
won't throw InterruptedException.
- Also no need to catch InterruptedException in
ConnectivityServiceInitializer.
Bug: 209894875
Test: atest FrameworksNetTests CtsNetTestCases
Merged-In: I1d0b973f9dac0f1d4f9d4d03faef66f05edde3fc
Change-Id: I1d0b973f9dac0f1d4f9d4d03faef66f05edde3fc
- Use MDns aidl to communicate with mdns service and register
event listener to receive callback.
- Remove all NDC relevant code on NsdService.
- Use MDns aidl on NsdServiceTest.
Bug: 209894875
Test: atest FrameworksNetTests CtsNetTestCases
Change-Id: I65929dee3838fef753396e86c665abd66b6fec81
This adds a Network member to NsdServiceInfo, allowing discovered
services to report which network they were discovered on, and clients to
specify which network to resolve the service on. If clients use the
discovered NsdServiceInfo to resolve a service, it will be resolved on
the network where it was discovered instead of an unspecified network.
Also add a network parameter to a new overload of
NsdManager#discoverServices, so that clients can discover on specific
networks.
Bug: 190249673
Test: atest NsdManagerTest
Change-Id: Idc4bf9fde0f4b0328204a8cd2eedc12fffbbbdba
When discover two different host with same host name
from different network interface, specify on what
interface to getAddrInfo.
Bug: 203453164
Test: build & manual
Signed-off-by: hepengtao <hept.hept.hept@gmail.com>
Change-Id: Ifaccb7f3fac6b1dd789cc9ce7c8d964102754508
