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
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
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
Network state is not changed to disconnected when a networkagent
is disconnected and network state is SUSPENDED.
So the function requiresClat return true. Clat is not stoped.
Bug: 277682237
Test: atest FrameworksNetTests
(cherry picked from https://android-review.googlesource.com/q/commit:fd5d3d90e1da7411104902ddfe859ebd0e4a02fb)
Merged-In: I5edfcf64aca5d2d34325d722dd29fab41bcf2600
Change-Id: I5edfcf64aca5d2d34325d722dd29fab41bcf2600
Currently, clatd is not stopped when suspended network is disconnected
and aosp/2583410 fixes this issue.
This CL adds test for current behavior, aosp/2583410 can update
testDisconnectSuspendedNetworkStopClatd to call verifyClatdStop instead
of verifyNeverClatdStop
Test: atest FrameworksNetTests
Bug: 277682237
(cherry picked from https://android-review.googlesource.com/q/commit:4a5b06559fc276a06f53134694a0a6548b36b026)
Merged-In: I345e097ce8e114800d77c5f44d38d7ae4938935c
Change-Id: I345e097ce8e114800d77c5f44d38d7ae4938935c
MdnsServiceTypeClient should stop sending when it is removed due to its
socket being destroyed.
On null networks (downstream interfaces) that may have multiple sockets,
this should only happen once the last socket used by the (null) network
has been destroyed.
Bug: 278635632
Test: atest
(cherry picked from https://android-review.googlesource.com/q/commit:3d66b0432d0f83249d18ffaa757103129359d115)
Merged-In: Ie1808840bd68678f2af7b71bdd8f3be377c14424
Change-Id: Ie1808840bd68678f2af7b71bdd8f3be377c14424
When a SocketCallback is unregistered from MdnsSocketProvider, do not
send socket destroyed callbacks. Callers may not expect getting
callbacks after unregistration, and the current callbacks are also
broken when an unrequested socket is still in use by another requester.
MdnsAdvertiser already does not depend on getting this callback, as it
only unregisters the SocketCallback after it is done using the socket.
This change fixes MdnsMultinetworkSocketClient to destroy the socket by
itself when unrequesting.
Bug: 276177548
Test: atest
(cherry picked from https://android-review.googlesource.com/q/commit:5fe9bacc63c1b6a77878f23d5f53a07fc482f354)
Merged-In: If95f833e293f3aab91128aab1c9852ebfd41995d
Change-Id: If95f833e293f3aab91128aab1c9852ebfd41995d
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
(cherry picked from https://android-review.googlesource.com/q/commit:ce44beb7aa3d17dabab5e596a1b27cb9422e076e)
Merged-In: I09e780af25149162f16bd75410ddc50f160a0dab
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
(cherry picked from https://android-review.googlesource.com/q/commit:f2d064112c34eb703dabdd5a48008ba4b3183a0b)
Merged-In: I21367c66534078667718a9b54dfc858b12ba7103
Change-Id: I21367c66534078667718a9b54dfc858b12ba7103
The ServiceTypeClient should be removed after socket destroyed
because it's no longer used by any request. The requests will be
matched to the newly created ServiceTypeClient.
Bug: 278635632
Test: atest FrameworksNetTests CtsNetTestCases
(cherry picked from https://android-review.googlesource.com/q/commit:f2a51ac5f8cc6b1cfaaa0f8fd5c28af522806ca0)
Merged-In: Ia917b14d3666f3bfe8e874606a34800a4ce65c5a
Change-Id: Ia917b14d3666f3bfe8e874606a34800a4ce65c5a
If a listener request is fulfilled immediately from cache, do not
restart queries immediately, but just schedule the next run.
This avoids doubling the number of queries when discovery, then resolve
is requested.
Bug: 281793453
Test: atest
(cherry picked from https://android-review.googlesource.com/q/commit:58bb0a129a4eb1f19904265104af2a14db248cb3)
Merged-In: Ibe41ee20427068a1ccdbc1f04525988a89a58899
Change-Id: Ibe41ee20427068a1ccdbc1f04525988a89a58899
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
(cherry picked from https://android-review.googlesource.com/q/commit:2f82fcdd6ca82928ae24533cd8616561a4737df1)
Merged-In: I677ee885d1ee8e6a09773f21e4dd53e96faee748
Change-Id: I677ee885d1ee8e6a09773f21e4dd53e96faee748
Currently, native networks for non-VPN networks are created only
when the NetworkAgent goes into the CONNECTED state. This is not
ideal, because until the network is connected:
- Nothing routes to the network, so no IP packets can be sent on
it (except via packet sockets).
- Many network configuration changes (e.g., routes and DNS
servers) fail to apply because the network does not exist yet.
These cause ENONET errors in the logs.
Fix this starting in U by creating the native network as soon as
the agent registers. This should not impact apps because
NetworkCallbacks are not sent until networks are connected.
Bug: 143158421
Test: new coverage in NetworkAgentTest
(cherry picked from https://android-review.googlesource.com/q/commit:4f87aa3f13d8972d7525bb7231cf7ad6aaa0b7eb)
Merged-In: I26bfa8630c085422175558645c47a6c64be96ae6
Change-Id: I26bfa8630c085422175558645c47a6c64be96ae6
Currently, the MTU tests work on networks that have not yet been
connected. This is not very realistic because most MTU changes
(like most LinkProperties changes in general) happen after the
network has connected. Change these tests to use connected
networks instead.
To avoid losing coverage for setting the MTU before the network
is connected, add a test just for that.
Bug: 143158421
Test: test-only change
(cherry picked from https://android-review.googlesource.com/q/commit:b95ca556dbb96e5e839ee1cc3be1dea37b23ac7d)
Merged-In: I7f808249722924a0b1253e402c5580bb104afd8e
Change-Id: I7f808249722924a0b1253e402c5580bb104afd8e
To do this we register a UidFrozenStateChangedCallback with
ActivityManager. The callback then queues up work on the Handler thread
to consume the original callback args and kill appropriate sockets.
Test: atest ConnectivityServiceTests
Bug: 277100090
(cherry picked from https://android-review.googlesource.com/q/commit:7c999d8d4cc4cd092d2de52ae98037ca4861e71f)
Merged-In: I93f174811aef726145a18ea90443ddfc1456478e
Change-Id: I93f174811aef726145a18ea90443ddfc1456478e
* changes:
Fix isFeatureEnabled namespace and overload usage
Add a dependency object in TetheringConfiguration
Use DeviceConfigUtils for ConnectivityResources
Move ConnectivityResources to service-connectivity
Netd is not updatable since it's not mainlined.
To make socket destroy code updatable, the code was re-implemented in
java and moved to Connectivity.
Bug: 270298713
Test: atest FrameworksNetTests
(cherry picked from https://android-review.googlesource.com/q/commit:93a2218e41384d106f1c14c239e1bf4795af43d5)
Merged-In: I5439c0c76c42a9f738a1b25a1f62e701755cbd05
Change-Id: I5439c0c76c42a9f738a1b25a1f62e701755cbd05
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
(cherry picked from https://android-review.googlesource.com/q/commit:278db58bf536551158e8082d3e7572650a908b05)
Merged-In: I2b4b6a13c048c20beef52b1f43b9e21aca0c637a
Change-Id: I2b4b6a13c048c20beef52b1f43b9e21aca0c637a
The ConnectivityResources class is only usable with QUERY_ALL_PACKAGES
permission, so it is not generally usable in framework-connectivity. It
is also backed by the ServiceConnectivityResources APK, which is
intended as resources for service-connectivity.
Move the class to service-connectivity and update callers. CTS needs a
way to determine the supported keepalive count as it used the
resources from KeepaliveUtils as @hide API, so provide a
ConnectivityManager @hide API for testing.
Bug: 279108992
Test: atest
(cherry picked from https://android-review.googlesource.com/q/commit:bee2ee14f34ff028236b393523d1174a375d2a08)
Merged-In: I3c9a77c580b5ab87c922c32778bce15dc33b4d1d
Change-Id: I3c9a77c580b5ab87c922c32778bce15dc33b4d1d
If the network is null in MdnsServiceTypeClient, it should use
MdnsSocketClient for single socket only. So it's expected to
process any response from only the socket (network).
Move the stopDiscovery outside the listener check loop.
Because the stop should only be called once.
Add a test to verify the response processing with a non-null
network MdnsServiceTypeClient
Bug: 265787401
Test: atest FrameworksNetTests
(cherry picked from https://android-review.googlesource.com/q/commit:bdf82a2aa0d7447de75fdcca60734936b926e25e)
Merged-In: I76965302037f050e0ac3b2cfdbaa5a855e2283c7
Change-Id: I76965302037f050e0ac3b2cfdbaa5a855e2283c7
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
(cherry picked from https://android-review.googlesource.com/q/commit:de802c8dc4f59735730fc24b0ca05a73f92e4bb5)
Merged-In: I077d8abdb91071db62b9618d9918e3a12682aaf4
Change-Id: I077d8abdb91071db62b9618d9918e3a12682aaf4
* changes:
[automerge] Refactor the ISocketNetLinkMonitor to AbstractSocketNetlink 2p: 46ab01cce9
Refactor the ISocketNetLinkMonitor to AbstractSocketNetlink
Cellular networks are now supported for marking wakeup packets. As a
result onWakeupEvent now also reports data relevant to the cell
transport.
These unit tests should add coverage for these new behaviors.
Test: atest FrameworksNetTests
Bug: 276498460
Change-Id: I0b8a03fff6255e067b736f3dbfb53de56420f90b
Merged-In: I0b8a03fff6255e067b736f3dbfb53de56420f90b
Currently, the mDns discovery services will clear if no listener
registers to that MdnsServiceTypeClient. If an app does discover,
stop discover, resolve, at this point the listener was
unregistered, so the MdnsServiceTypeClient was deleted, and the
service is gone from cache. So this will actually restart
discovery without returning previous results from cache. Thus,
add MdnsServiceCache to store all services and reduce the
duplicated queries.
Bug: 265787401
Test: atest FrameworksNetTests
(cherry picked from https://android-review.googlesource.com/q/commit:ade3f459561f7dd2e1e66f82111c4e0e33fd3a4a)
Merged-In: If3d4eb4e3dc5455f6f97cb782aa1b99b2a00f6e0
Change-Id: If3d4eb4e3dc5455f6f97cb782aa1b99b2a00f6e0
Phenotype is updating the flags while this test is running
and this DoS'es the device to such an extent that the test
process doesn't get the CPU for more that 300ms. That lets
the lingering timeout run its course and fails the test.
This won't necessarily fix all flakes (after all, if
Phenotype hogs the CPU for 2 seconds the same issue will
continue to happen), but it should help.
Bug: 277555492
Test: FrameworksNetTests
Change-Id: I78ab1573974427b10dd557c011fbbf64942fd09f
* changes:
Revert^2 "Put client logs into SharedLog and dump more logs"
Revert^2 "Record Advertiser history logs for better debugging"
Revert "Revert "Record SocketProvider history logs for better de..."
Revert "Revert "Record DiscoveryManager history logs for better ..."
The setup for the mocking object will be reset when each test
finishs the test. Reset the mocking value is actually no-op
but cause possible threading issue in Mokito.
Bug: 278979735
Test: atest com.android.server.connectivity.VpnTest \
--rerun-until-failure 100
Change-Id: Ib8c3813e5dbcc9b7432a5548766d63e400b4ed0e
