after the commit aosp/1948496, both mMobileIfaces and mWifiIfaces
already contain the stacked interfaces. Hence, the method is not
really useful.
Test: TH
Fix: 215633405
Change-Id: Id132a166e9cf94cab711f417a4f7ffc84eab6185
The running task in MdnsServiceTypeClient would be cancel if the
requests using other networks for the same service type start a
new discovery. Besides, the instanceNameToResponse cache would
be incorrect too. The service attributes may be different on
different networks, so there needs to be a different instance
of the cache. Thus, the MdnsServiceTypeClient needs to be
Network-specific.
Bug: 265787401
Test: atest FrameworksNetTests
Change-Id: Id5ac42f3522a774fe9789c0de4d5357501b63868
The required sockets may not have been created yet when
MdnsServiceTypeClient#startSendAndReceive is called on
MdnsDiscoveryManager#registerListener, so the first send would go
nowhere, and only later retries would be sent. Ideally the code
would wait for some sockets to be created before calling
startSendAndReceive.
Bug: 265787401
Bug: 264634275
Test: atest FrameworksNetTests
Change-Id: Id789d564d125c0192e742d7dd246367afdb93413
matchesWifiNetworkKey expects a non-null value of the
wifiNetworkKey, however, it might be null in practice
and the null wifiNetworkKey will be stored into disk.
And then when the matchesWifiNetworkKey is called, the
requireNonNull will crash the system. Thus, remove the
requireNonNull from matchesWifiNetworkKey to avoid
system crash and handle if the wifiNetworkKey is null
then it should not match a template with non-empty
mMatchWifiNetworkKeys.
Check if WifiInfo contains a null network key then skip it
to prevent adding the identity to the network identity set.
Also, add a Log.wtf when setWifiNetworkKey(info.getNetworkKey()),
this might be useful to catch why the wifiNetworkKey is
null.
Bug: 267815242
Bug: 266598304
Test: FrmeworksNetTests
Change-Id: I9c21f7e3dca9482133c7e331741cf808105414e9
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
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
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
