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
If the mDNS service has multiple IPv4 / IPv6 addresses, only the
last added address will be present on the response. Since the
NsdServiceInfo supports multiple host addresses in Android U, the
MdnsResponse should also support multiple IPv4 / IPv6 addresses
in favor of providing accurate service info to clients.
Check cache flush flag on the response when adding a new address
record. Per RFC6762 10.2, clear all address records if the
cache-flush bit set.
Bug: 268586836
Test: atest FrameworksNetTests
Change-Id: I04548a3f16837939f3131b84c1033377ff81d521
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
Remi NGUYEN VANauthored and Gerrit Code Reviewcommited 2023-03-03 07:45:24 +00:00
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
Previously resolve queries for SRV/TXT/A/AAAA were only sent when there
was a known but incomplete MdnsResponse for the service.
Allow sending the resolve queries when there is no known MdnsResponse,
so no known PTR record, but the client specified the resolveInstanceName
in the MdnsSearchOptions. This is achieved by adding the serviceName as
an additional field in MdnsResponse, as it is always known when
constructing the MdnsResponse. The serviceName can either be set from a
discovered PTR record, or from the client-specified resolveInstanceName.
Bug: 267570781
Test: atest NsdManagerTest#testResolveWhenServerSendsNoAdditionalRecord
(see separate change).
Change-Id: Icb9ed7ae44179a5df5b69a1e6a0486ffc2d8e42c
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
MdnsResponses were only updated through
MdnsResponse.mergeRecordsFrom(MndsResponse), meaning that MdnsResponse
cannot be updated unless a MdnsResponse can be built from the update
packet.
Because a PTR record is required to build a MdnsResponse, this means
that it was not possible to add records to a MdnsResponse unless the
update packet contains a PTR record.
Fix this by having MdnsServiceTypeClient augment its current known
responses in addition to creating new responses from incoming
MdnsPackets.
Bug: 267570781
Test: atest NsdManagerTest#testPtrOnlyResponse with
mdns_discovery_manager_version set to 1.
Change-Id: Iba293b4772fcd79e94ee6412c9af8225a3349f12
MdnsResponse would not replace records if the TTL changed, but this is
necessary in particular in case of exit announcements (RFC6762 10.1)
where the TTL is updated to zero.
Update MdnsResponse to update records if the TTL changed. The
receiptTimeMillis is still not considered to update records, but doing
so would generate service change notifications every time a reply is
received, so this is not covered here.
Bug: 267570781
Test: atest MdnsResponseTests
Change-Id: Ied55829cba6b043d13603a8230bda457c07de42f
When calling MdnsResponse.setInet4AddressRecord with null, the record
was removed from the records list, but not from the inet4AddressRecord /
inet6AddressRecord fields.
Fix that, and update the MdnsResponseDecoder test that missed the bug
because it modified the same incomplete MdnsResponse multiple times
(so isComplete keeps returning false), instead of using a copy of
a complete MdnsResponse.
This requires using a copy constructor, which will be useful for future
changes, so add it with a test.
Bug: 267570781
Test: atest
Change-Id: I199a8e4bc9a54a142c1fec1acee2ab6b1baa7efb
In case a host has two interfaces (e.g. wifi and ethernet) that are
bridged on the router side, hosts on the network would receive service
advertisements for both interfaces. If each interface uses a different
hostname, this creates a problem where service SRV records would point
to two different hostnames. Generating a hostname for all interfaces can
fix this problem. The hostname will be regenerated if all the clients
for NsdService are disconnected.
Test: atest FrameworksNetTests CtsNetTestCases
Bug: 268153179
Change-Id: Icdd2991233729b7f90e65984ca0381e32ab4ce93
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
Instead of building MdnsResponse lists in MdnsSocketClient and sending
each one to ServiceTypeClient, only parse packets in MdnsSocketClient,
and let each ServiceTypeClient build the MdnsResponse from them.
MdnsResponseDecoder already implements the same filtering that
MdnsDiscoveryManager#onResponseReceived did on the service types so this
is a no-op.
This will be useful to allow MdnsServiceTypeClient to update its
responses using records that are not necessarily part of a full
MdnsResponse; for example if a reply packet only contains address
records, or only SRV/TXT records without a PTR record.
Bug: 267570781
Test: atest
Change-Id: I8157c3732c425aae497d44c44c64b640859c13dc
This is useful in the system server for better attribution of wakeup
events.
The logic for encoding the data in the prefix is still maintained ad-hoc
and should be standardized in the future.
Test: Builds, boots. Manually triggering a wifi wakeup doesn't result
in anything unexpected.
Test: atest FrameworksNetTests
Bug: 265742148
Change-Id: I7ef8a606459bb9f0630f629c01d3b34643ae5319
When the application wants to request network with
NET_CAPABILITY_PRIORITIZE_BANDWIDTH or
NET_CAPABILITY_PRIORITIZE_LATENCY, it has to declare
PackageManager.PROPERTY_NETWORK_SLICE_DECLARATIONS property and also
adds the declaration in a separate XML files. Otherwise, the request
will fail with a SecurityException being thrown.
Test: atest FrameworksNetTests CtsNetTestCases
Bug: 266524688
Change-Id: I6affc857b803211517368da288e1b2fdc06a955b
Test: 1. Patch local built module on T device
2. atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.ConnectivityServiceTest
Fix: 267968887
Change-Id: I86e5be9a0cee0621ff9ef0996d56a51fc5f408c2
File a VPN request to prevent the VPN network being lingered.
The VPN network will be lingered and onCapabilitiesChanged()
will be fired when the linger timer is expired, which will
cause the test receiving an unexpected onCapabilitiesChnaged()
and make the test failed eventually.
Bug: 265396507
Bug: 265510523
Test: atest FrameworksNetTests
Change-Id: Id9ad810d46cb2bbb13fa5c602520635ae8e73e31
lucaslinauthored and Lucas Lincommited 2023-02-18 02:59:05 +00:00
Print state and keepalive information in the dump.
Also update ConnectivityService and the corresponding test to
create AutomaticOnOffKeepaliveTracker from a Dependencies class.
ConnectivityService#dump() will require READ_DEVICE_CONFIG
permission because of the new dump() in AutomaticOnOffKeepaliveTreacker.
ConnectivityServiceTest should focus on verifying design in
ConnectivityService, so skipping the DeviceConfig check via a fake
Dependencies class in the unit test.
Sample dump:
AutomaticOnOff enabled: true
AutomaticOnOffKeepalive [KeepaliveInfo [ type=1 network=100 startedS ... ], state=STATE_ENABLED ]
Bug: 259000745
Test: m ; atest FrameworksNetTests CtsNetTestCases
Change-Id: I9ac725bcef7daec1d1a12bad592b7fa6856a1707
registerSystemDefaultNetworkCallback is required by WifiTrackerLib to
detect the system default network for UI purposes. Currently this API is
allowed for holders of the NETWORK_SETTINGS permission, but not
NETWORK_SETUP_WIZARD. Since SUW also uses WifiTrackerLib, we should
allow this API for NETWORK_SETUP_WIZARD as well.
Bug: 230643853
Test: atest ConnectivityServiceTest
Change-Id: Ic01a186f91ed67b4603b6b8964921be7473a483a
ConnectivityCompatChanges.java becomes the centralized place for all the
CompatChanges used in the Connectivity module. By putting all the
CompatChanges here, we are able to manage them under a single
platform_compat_config.
Bug: 268440216
Test: atest FrameworksNetTests
Change-Id: I3e17af545718073d7d1c96e27298e7790563fd33
It's a reason, so it's a lot clearer this way
Bug: 157405399
Test: ConnectivityServiceTest NetworkStaticLibTests
Change-Id: I1cfcdb291f46205141d5d40322d5a8e3b178db20
expect() is simpler to do the same thing
Bug: 157405399
Test: ConnectivityServiceTest NetworkStaticLibTests
Change-Id: I4d992fd7ea57d36a38afc33eaebcf2f7ce05aa80
This is a back-pocket solution only, to ensure that VpnManager
privileged clients can temporarily rely on IPv6 UDP encap if on
certain carriers IPv4 UDP and IPv6 ESP cannot provide acceptable
performance and battery life.
For these reasons IPv6 UDP encap is not a public or system API
and is triggered by passing a port greater than 65535 to the
existing openUdpEncapsulationSocket API.
Bug: 259001350
Test: new CTS tests
Change-Id: I02e0566ba910a300dda6a589cd265a3360add40c
Lorenzo Colitticommited 2023-02-08 15:05:07 +09:00
The base method is capable of doing this in a clearer manner,
so this redundant method is no longer needed.
Test: ConnectivityServiceTest FrameworksNetIntegrationTests
Bug: 157405399
Change-Id: I5f801d3c66374096fe7be7be21ee8d80264cd693
Paul Hu
commited 
Gerrit Code Review
commited 
Remi NGUYEN VAN
commited 
Yuyang Huang
authored and
Ahmad Khalil
authored and
Suprabh Shukla
commited 
Treehugger Robot
authored and
Junyu Lai
commited 
Chiachang Wang
authored and
Chalard Jean
commited 
Lucas Lin
authored and
Motomu Utsumi
authored and
Quang Luong
authored and
Lorenzo Colitti
authored and