MdnsSocketClient doesn't support requesting specific network. As a
result, when processing the response, all the MdnsServiceTypeClient
should be called.
Bug: 285064577
Test: atest CtsNetTestCases FrameworksNetTests
Change-Id: Id95f1e78d60063ccee7f5855a21fa6b5a48fbd3e
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.
Original change: https://r.android.com/2600006
Change-Id: I412157f184decd8af8343977d59a2215fe8ca51e
Fixes: 283914408
Test: atest FrameworksNetTests
Merged-In: 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
(cherry picked from https://android-review.googlesource.com/q/commit:7f0af78c5ee0b783faec38ab4dd7afe0f8a393ec)
Merged-In: Icc23994c3ebc99da6043ed2d93540c44f53a150b
Change-Id: Icc23994c3ebc99da6043ed2d93540c44f53a150b
Add tests where NATT keepalives are stopped and cleaned up within
KeepaliveTracker in these scenarios:
1. startNattKeepalive is called with an invalid interval.
2. The state is STARTING and the network agent returns an error event.
3. The keepalive started successfully but becomes invalid and
handleCheckKeepalivesStillValid is called on the network.
Bug: 281646074
Test: atest FrameworksNetTests
Change-Id: Iadf9f06030cae20f36d950f520c8dcc4181924ad
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
This patch mocks the SDK level and/or change IDs to help
developing functionality that depends on these without
having to flash a new device every time.
Test: TH
Change-Id: I1011193c99e123a0e5501ed313c9cecbceebdae6
NsdManagerTest need to be updated because the older check was incorrect,
the new behavior should be observed on T when the compat flag is enabled
as well.
Test: m
Change-Id: I5d2e87b1ab5a114005a223e7ccd865540c0fdb78
Packets received from the "null" networks are packets received from
tethering downstream interfaces. They should not be processed by all
MdnsServiceTypeClients; instead they should be processed by
the MdnsServiceTypeClient for the null network.
Bug: 283708537
Test: atest
(cherry picked from https://android-review.googlesource.com/q/commit:0ba206cbd168f5627da84911c0d7e5307e55c431)
Merged-In: Ifef59eca7a24bdfe3650067445d2565869dfa852
Change-Id: Ifef59eca7a24bdfe3650067445d2565869dfa852
When sendMulticastPacket or sendUnicastPacket is called with the null
network, only send the packets to interfaces indexed with null, instead
of all interfaces.
When using MdnsMultinetworkSocketClient sending packets on the null
network means sending on tethered downstream interfaces. When
MdnsSocketClient is used (not used in the Android tree), sending on the
null network sends on all interfaces as MdnsSocketClient does not
support specific networks. This is clarified by explicitly throwing
when a non-null Network is attempted to be used with MdnsSocketClient
(but MdnsSocketClient is only used for tests in the Android tree).
Bug: 283708537
Test: atest
(cherry picked from https://android-review.googlesource.com/q/commit:87c374a37ac8698a98d0c35a3196922c69549cc7)
Merged-In: Ia0186bf8aa2e0fc5878d6071fd23599df8488616
Change-Id: Ia0186bf8aa2e0fc5878d6071fd23599df8488616
Instead of the network specified in the MdnsSearchOptions, which is
often null to request searching on all networks, use the
MdnsServiceTypeClient Network to build the queries.
When MdnsSearchOptions.network is null, one MdnsServiceTypeClient is
created for each mDNS-compatible Network. Each MdnsServiceTypeClient
schedules queries with a Network selector. If the Network selector is
null, each MdnsServiceTypeClient will post its queries to all networks.
Instead, it should be the Network of the MdnsServiceTypeClient.
There is one remaining problem when a tethered interface is up: in that
case, there will be one MdnsServiceTypeClient for tethered interfaces
with a null network, which will still broadcast its queries to all
networks. This should be addressed in a follow-up by having
MdnsMultinetworkSocketClient only send queries to interfaces that have a
null network, when the network selector is null (and not all
interfaces).
Bug: 283708537
Test: atest
(cherry picked from https://android-review.googlesource.com/q/commit:404c1bf7877316df27389aa8a1ac855a25a86c20)
Merged-In: If571d7a59c5e55d809eeb1f3d1c4b58684612cdd
Change-Id: If571d7a59c5e55d809eeb1f3d1c4b58684612cdd
Check that advertised subtypes can be found by matching discoveries and
discoveries for the base type, and that discoveries for different
subtypes do not find the service.
Bug: 266167702
Test: atest
(cherry picked from https://android-review.googlesource.com/q/commit:eae8529fc6542691ba2f0c1262f3ab8732e4434b)
Merged-In: I0a8249cca22c1d30baad12bb4e8351a65ce87cb1
Change-Id: I0a8249cca22c1d30baad12bb4e8351a65ce87cb1
ServiceTypeClients will store/access services on MdnsServiceCache
in subsequent changes. And MdnsServiceCache can be accessed from
looper thread only. So ensure MdnsDiscoveryManager calls to
ServiceTypeClients on the looper thread.
Bug: 265787401
Test: atest FrameworksNetTests
(cherry picked from https://android-review.googlesource.com/q/commit:bd4140ea913ad031057ff37bea8c2556b4970463)
Merged-In: I05e73140da58c029b49057bb0ccfdb8ed7818dfc
Change-Id: I05e73140da58c029b49057bb0ccfdb8ed7818dfc
Packets received from the "null" networks are packets received from
tethering downstream interfaces. They should not be processed by all
MdnsServiceTypeClients; instead they should be processed by
the MdnsServiceTypeClient for the null network.
Bug: 283708537
Test: atest
Change-Id: Ifef59eca7a24bdfe3650067445d2565869dfa852
When sendMulticastPacket or sendUnicastPacket is called with the null
network, only send the packets to interfaces indexed with null, instead
of all interfaces.
When using MdnsMultinetworkSocketClient sending packets on the null
network means sending on tethered downstream interfaces. When
MdnsSocketClient is used (not used in the Android tree), sending on the
null network sends on all interfaces as MdnsSocketClient does not
support specific networks. This is clarified by explicitly throwing
when a non-null Network is attempted to be used with MdnsSocketClient
(but MdnsSocketClient is only used for tests in the Android tree).
Bug: 283708537
Test: atest
Change-Id: Ia0186bf8aa2e0fc5878d6071fd23599df8488616
• Remove unused private methods
• Build files have this test in FrameworksNetTests, which
by TEST_MAPPING is not run on T and below. It is not in
the targets that do run on T and below like
ConnectivityCoverageTest.
Test: VpnTest
Change-Id: I198e5b3571e34e41611f71d351501d3f98f78caa
