Add end-to-end testing for testing NsdManager advertising and
discovering works fine with downstream tethering interfaces.
Bug: 281639507
Test: atest NsdManagerTest
Change-Id: I5a66423f216cfe0c82db5128502c885980ab264b
The isLegacy field of Nsd metrics should indicate whether the
data was collected from the old backend or not. However, it is
currently only dependent on the ENABLE_PLATFORM_MDNS_BACKEND
compat change value, which is incorrect. This is because the
NsdService always uses the new backend since Android U,
regardless of the compat change value. Therefore, the isLegacy
data should be obtained from each transaction.
Bug: 287546772
Bug: 299880473
Test: atest FrameworksNetTestCases NsdManagerTest
Change-Id: I156abd656b90578d710696a69ccf7dfca97a2c9c
This CL also updates not to use isTetheringFeatureEnabled for
TETHER_FORCE_UPSTREAM_AUTOMATIC_VERSION which is wrongly configured in
Connectivity namespace.
Test: m
Bug: 279108992
Change-Id: If4f3a57c749bbaeb85454c31248c5bc5feaab936
Report more advertising metrics data below when the service is
unregistered.
- Replied request count (sum across interfaces)
- Sent packet count (including announcements and probes)
- Number of conflicts during probing
- Nubmer of conflicts after probing
Bug: 287546772
Test: atest FrameworksNetTestCases NsdManagerTest
Merged-In: I50c54a35dc523422e3a7302c059bbbc38eac5631
Change-Id: I50c54a35dc523422e3a7302c059bbbc38eac5631
For an app to register itself as an offloadEngine, it must have either
of the following permissions: NETWORK_STACK,
PERMISSION_MAINLINE_NETWORK_STACK, NETWORK_SETTINGS,
REGISTER_NSD_OFFLOAD_ENGINE.
Bug: 294777050
Test: atest CtsNetTestCases FrameworksNetTests
Change-Id: I19fe9b996a02b1ae23116c02a1b8406d93b3ecf1
When the OffloadEngine is registered, it should get notice about all the
currently offloaded service.
Bug: 297314970
Test: atest CtsNetTestCases
Change-Id: I1b977a40476a1f5c30a075b559e72656a42865ae
Report the sent query count when the discovery is stopped.
Bug: 287546772
Test: atest FrameworksNetTestCases NsdManagerTest
Change-Id: I47b91c0c530eee2f00920ee5ea99e8d7b6e2e9ee
DeviceConfigUtils has isFeatureEnabled for NetworkStack and Tethering
which were confusing since the difference was only the arguments.
This CL renames isFeatureEnabled for Tethering module to
isTetheringFeatureEnabled to avoid confusion.
Bug: 279108992
Test: m
Change-Id: I05255bb38619afbe621d29524d7910d206a149f1
Collect information on resolution success and failure events,
then use this data to build metrics and report them.
Bug: 287546772
Test: atest FrameworksNetTestCases NsdManagerTest
Change-Id: I373ce91fea9d5a278f53fc0c505be90dd39b2d5b
Collect information on discovery start, failure, and stop events,
then use this data to build metrics and report them.
Bug: 287546772
Test: atest FrameworksNetTestCases NsdManagerTest
Change-Id: I2f6a718024870f9658cfeabe8995624a3ad81f05
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
