To ensure that all access to the MdnsServiceTypeClient is done on
the handler thread, a handler thread check must be added to all
public methods in the MdnsServiceTypeClient. This will allow the
synchronized lock to be removed in future changes, and it will
also ensure that MdnsServiceTypeClient can access MdsServiceCache
properly.
Bug: 265787401
Test: atest FrameworksNetTests
Change-Id: I0206874eb0acdf0272b8ad23d29f3e764bfdec38
The MdnsServiceTypeClient is now created using a SocketKey, so
the MdnsServiceCache should also use the SocketKey to deal with
the caching services.
Bug: 265787401
Test: atest FrameworksNetTests
Change-Id: I6165ffd420a39e750c06778b4851142a3ba3cf44
After numOfQueriesBeforeBackoff query, the mDNS discovery logic will
enter backoff mode. In backoff mode, the query frequency will be
updated to max(20, 0.8 * shortest remaining TTL) seconds. It will help
to reduce mDNS query frequency in certain use cases.
Bug: 284480315
Test: atest CtsNetTest FrameworksNetTests
Change-Id: Iac8baaaf58cf9b3b8e67e1cd80402fdecde1d3d4
- 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
In the previous design, the network could be null for some
MdnsServiceTypeClient (tethering interfaces). However, the
MdnsMultinetworkSocketClient is designed to send packets on
specific networks. This means that if there are multiple
tethering interfaces, packets will be sent to unnecessary
sockets. Now, the MdnsServiceTypeClient is created by the socket,
which can identify which socket is the target for sending
packets. Therefore, the design should be updated to send packets
only on the specific socket.
Bug: 278018903
Test: atest FrameworksNetTests android.net.cts.NsdManagerTest
Change-Id: Id87e6d202599c57620281a6761d3c56acd2c929c
Calling reset on mTaskRunner waits for any in progress tasks to finish.
Since Stop takes mMutex, it's possible that in-progress task is waiting
for mMutex in order to finish, resulting in a deadlock.
This breaks the loop by using try_lock to remove the blocking dependency
on the mutex. Since we _always_ want to re-schedule ourselves, the poll
duration and runner are taken as arguments (if rescheduling is also in
the try_lock, any class interactions could stop the polling sequence).
Test: local start/stop stress test and atest libnetworkstats_test
Bug: 285411033
Change-Id: I4b8bea9c5474a37e8c081bcfe542d4fe57f5206c
Add options to control whether only send IPv6 packet on IPv6 only
network. In some use case, IPv6 query should not be sent on a dual
network.
Added a small improvement to send an ANY query if both SRV & PTR
records are needed.
Bug: 284480254
Test: atest CtsNetTest FrameworksNetTests
Change-Id: I8f55db6f5e8ae606ac167fb363bc9b2fb9b5fc14
isCurrentCallback() is a trivial one liner that is more readable
inlined.
This change also renames handleIpEvent() to safelyPostOnHandler() to be
more descriptive.
Test: TH
Change-Id: I9224c9555f0b2ed22ff1cec5ae1c6e870c16820b
* Added logging to track mDNS service type client registrations and
response handling.
* Only shutdown the executor when it is not shutdown.
Bug: 285508143
Test: atest CtsNetTest FrameworksNetTests
Change-Id: Ic6fc0e1e6aef92bf3ee1a7990c4904a06e6db34a
Now, MdnsServiceTypeClient is created using a network. However,
all tether interfaces use the same network (null), which
means they use the same client for the same service type. This is
not the intended behavior, as each interface should have its own
client. Therefore, MdnsServiceTypeClient creation should be
changed to use SocketKey, which includes both the network and
interface index. This will allow each interface to have its own
client.
Bug: 278018903
Test: atest FrameworksNetTests android.net.cts.NsdManagerTest
Change-Id: I34b7d983f00b67198befb5bf71fc511cf0dabae6
Currently, all socket changes are identified using a Network
object. However, the Network object is null for all tethering
interface sockets, which means that the socket cannot be
identified in some places. Therefore, the Network object should
be replaced with a SocketKey object, which includes both the
network and interface index.
Bug: 278018903
Test: atest FrameworksNetTests android.net.cts.NsdManagerTest
Change-Id: Ib49981a4071ecab18c7cf3a8827d1459529492a9
* Only shutdown the executor when it is not shutdown
* Added logging to trace mDNS service type client registrations and
response handling.
Bug: 285508143
Test: atest CtsNetTest FrameworksNetTests
Change-Id: I9350941e63b0c6917f69aa588aaa0f234f93aa08
In case that the task is not canceled successfully, use session ID to
check if this task should continue to schedule more.
Bug: 285260665
Test: atest CtsNetTest FrameworksNetTests
Change-Id: Ic953ae781449a7ebf943999c8c8d3040a97641d9
When the cache flush bit is set on host address records in a response,
known records are cleared and replaced with the contents of the packet.
However even if the response contains the same records as before, this
caused it to be marked as modified, and response modified callbacks are
sent for every incoming packet.
Instead, ensure that the response is only marked as modified if a
previously unknown address record is added, or if a previously known
address record is removed.
The issue wasn't found by the existing testDecodeWithNoChange test,
because it used a service record for testhost2 instead of testhost1, so
the address records were ignored.
Bug: 285997766
Bug: 285084489
Test: atest CtsNetTest FrameworksNetTests
Change-Id: Ic0f19adf5d9bde7cdab766e49cf677b319a2219b
If the MdnsServiceTypeClient was removed when the
SocketCreationCallback#onAllSocketsDestroyed() was called, the
MdnsSocketClientBase#notifyNetworkUnrequested() will not be
called when a listener is unregistered from the
MdnsDiscoveryManager. This is because the serviceTypeClients will
be cleared after the socket is destroyed. However, these dead
listeners will be re-added to the MdnsServiceTypeClient when a
new socket is created. They will then continue to send callbacks
to the NsdService. Therefore, the notifyNetworkUnrequested()
should be moved to the beginning of the handleRegisterListener()
to ensure that the socket unregistration is properly notified.
Bug: 285997766
Test: atest FrameworksNetTests android.net.cts.NsdManagerTest
Change-Id: I31c766305018889f50a7c12c836174c340d01d7f
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
The receipt time in the MdnsResponse need to be updated every time new
packet is received. And then the record refreshing logic could calculate
remaining TTL correctly.
Bug: 285260665
Test: atest CtsNetTest FrameworksNetTests
Change-Id: Ib7a290ea0ea8e552c71c657696397e8114fcee52
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
