The NsdService will throw a NPE if a new client is registered
with a null INsdManagerCallback object. To avoid this, perform
a null check before registering a new client and throw an
IllegalArgumentException if the callback is null.
Bug: 293285797
Test: atest FrameworksNetTests
Change-Id: Id61e27873591031c3fe383879aee0d40eebc08b3
Components that can provide offload like IpClient (packet
filter offloading) can use the API to register a callback to be notified
when offload is necessary.
Bug: 269240366
Test: atest CtsNetTestCases
Change-Id: I8080702f5b530001b88e79e504f4722ac01bc576
Collect information about registration successes, failures, and
unregistrations, then build metrics data from this information
and report it.
Bug: 287546772
Test: atest FrameworksNetTestCases NsdManagerTest
Change-Id: I6324279b479da2e61b7519d96df5ad24a432e54a
Add helper class NetworkNsdReportedMetrics to build and report
nsd metrics data.
Bug: 287546772
Test: m
Change-Id: I8271811c52a88329fd54e8e0f6cc455d3a3d22f7
- This is a no-op change change that only unify the naming of
transaction IDs. Because there are currently different naming
conventions for transaction IDs, which can cause confusion and
lead to errors.
- Also renaming the "client ID" to "client request ID" because
this more accurately reflects how the ID is used.
Bug: 287546772
Test: m
Change-Id: I4fb7255f23754aa720a83a5df282700c59140207
There is no log to show whether the callbacks have been sent to
user. So add some logs on NsdService to at least know whether
the callback was sent to NsdService.
Test: atest FrameworksNetTests android.net.cts.NsdManagerTest
Change-Id: I1940d501ac3f9f56ce440366d0b5214a97d6f6f7
When an mDNS request (discovery, advertising, resolving...) is
registered and gets assigned a socket on a wifi network, take the
multicast lock to ensure that it can reliably receive mDNS responses.
This is limited to when the application has importance
FOREGROUND_SERVICE or higher.
NsdManager is not documented to require usage of the multicast lock,
which has caused various reports about its reliability. Taking the lock
while the app is in the foreground should address the large majority of
cases, while limiting battery impact.
Going forward this should allow developers on U+ to not take the
lock themselves, allowing optimizations on devices supporting APF,
where instead of taking the lock APF would let through only select
mDNS packets.
Bug: 284389438
Test: atest
Change-Id: I1ce85220eac4a1529b6716d50727c1c462356846
Turn on removeExpiredService feature by: 1) Remove the unnecessary
allowSearchOptionsToRemoveExpiredService flag. 2) Turn on the
removeExpiredService flag in the MdnsSearchOptions.
Bug: 285260665
Test: atest CtsNetTest FrameworksNetTests
Change-Id: Ib115b40e70b0f81a7877deb73af7d61e2e0c385f
In some use cases for the MdnsDiscoveryManager, providing looper as an
argument to the MdnsDiscoveryManager constructor is not feasible. Adding
a constructor without looper can help to match those use cases. If
constructor without looper is used. The shutDown() must be called as a
part of cleanup process.
Bug: 283914408
Test: atest FrameworksNetTests
Change-Id: I0ab04d67bae127628c6d67c4b8c109201612a54b
MdnsDiscoveryManager should use the same thread that create on
NsdService that is used on other mDns components. Thus, pass that
thread loop to MdnsDiscoveryManager.
Bug: 265787401
Test: atest FrameworksNetTests
Change-Id: Icc23994c3ebc99da6043ed2d93540c44f53a150b
Implement subtype advertising by advertising an additional PTR record if
subtype advertising was requested.
For an advertiser a subtype is just an additional PTR record, so this
just involves plumbing the subtype down to MdnsRecordRepository, which
includes the additional record in the service registration.
Bug: 266167702
Test: atest
Change-Id: I09e780af25149162f16bd75410ddc50f160a0dab
Apps may want to discover a particular subtype, such as
_color._sub._printer._tcp.local, which may return services like
Printer1._printer._tcp.local. The previous code was trying to discover,
and would return service types named _color._sub._printer._tcp.local,
even though the actual service type is still _printer._tcp.local. This
is a regression compared to S/T.
Fix this by passing the subtype to MdnsDiscoveryManager in its options
instead of the service type, and ensure that MdnsDiscoveryManager only
sends callbacks to callers that have requested the given subtype (a
color that asked for _color._sub._printer._tcp.local should not receive
BlackAndWhite._printer._tcp.local).
Bug: 266167702
Test: atest
Change-Id: I21367c66534078667718a9b54dfc858b12ba7103
Historical behavior of onServiceFound is to include a dot at the end of
the service type. To avoid inconsistencies between behavior of new and
older backend, which would be hard to predict/handle for apps, ensure
that the same format is used. This means a dot must be added when using
the new backend.
Implement this by creating the callback service types based on
MdnsServiceInfo obtained from MdnsDiscoveryManager, rather than the
service type that was provided by the calling app. This avoids
inconsistencies as the calling app may or may not include dots
originally, and it may use subtypes ("_sub._type._tcp.local" or even
"_type._tcp.local,_sub"), which would result in callbacks giving invalid
service types, or inconsistent with S/T behavior.
Fixes: 281776253
Test: atest
Change-Id: I677ee885d1ee8e6a09773f21e4dd53e96faee748
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
From service-connectivity, NAMESPACE_TETHERING must be used, as
NAMESPACE_CONNECTIVITY is used for the NetworkStack module. Also the
isFeatureEnabled with module name must be used, otherwise the "android"
package version is queried instead of the tethering module version.
BpfNetMaps is using flag value 1 to workaround this issue.
flags in NsdService, AutomaticOnOffKeepaliveTracker, and ConnectivityFlags
were not pushed currently.
So, this change has no effect to devices.
Bug: 279108992
Test: TH
Change-Id: I2b4b6a13c048c20beef52b1f43b9e21aca0c637a
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
