API council has requested that the recently added BroadcastOptions
APIs be modified to better match API guidelines.
Bug: 267646347
Test: treehugger
Change-Id: Ia701ae31079476d0cc05079d62cd90ba81279cdd
Although case should not matter when comparing attributes,
converting all keys to lowercase breaks NsdServiceInfo APIs which
provide the original case to the caller.
Use a TreeMap with a case-insensitive comparator to ignore case when
querying keys, while keeping case information in the map.
Bug: 270885892
Test: atest MdnsServiceInfoTest
Change-Id: Id15947b1e8650eb6b59126c5d2dc8624ae4f8100
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
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
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
Add and update tests for automaticNattKeepaliveTimerEnabled
and automaticIpVersionSelectionEnabled fields.
Test: atest Ikev2VpnProfileTest VpnProfileTest
Change-Id: I4e424abd2197d9099a2efe0bd8c4b9120bfcfe3a
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
mSubscriberId was removed from NetworkTemplate and equals/hashCode
does not check the mMatchSubscriberIds. This will cause tempates
with different subscriber ID matching that are equal now. Thus
adding the check for mMatchSubscriberIds to fix it.
Bug: 267968247
Test: FrameworksNetTests:NetworkTemplateTest
Change-Id: I2956bf4c8cf2c4d73ebe102d53e755fbcc5d7642
