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
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
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
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
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
Combine registerPacProxBroadcastThat and registerConnectiviyBroadcastThat
into one method since they are highly similar.
Test: FrameworksNetTests:ConnectivityServiceTest
Change-Id: If0605a94208478399375a43c1ef92782d26cb805
If the screen is off while running the test, it will
cause test fail because the test cannot verify the
launcher is shown. Thus, wake up the device first to
verify if the launcher is shown or not.
Bug: 261860642
Test: this
Change-Id: Icda8a2c6fdc97caf1986bb812ca366d9c9fde03f
Upcoming CLs use this method to add chain status to failure log of
ConnectivityManagerTest#testFirewallBlocking which is a flaky test
Test: atest BpfNetMapsTest
Bug: 262141231
Change-Id: Ib130a28c708f675c79b889bf293dfe6b0f8d7f60
Rename the method onResolveStopped(NsdServiceInfo) to
onResolutionStopped(NsdServiceInfo) for consistency as API
review feedback.
Bug: 266811051
Test: atest FrameworksNetTests CtsNetTestCases
Change-Id: I788b5903ecaf78a9aa960dd3b7413a22f171c72f
getVpnLockdownUidRanges acquire lock and access internal state of a
Handler-based class (PermissionMonitor), which is bad practice in
general.
getVpnLockdownUidRanges returns keySet of mVpnLockdownUidRanges.
PermissionMonitor call updateUidLockdownRule and update the bpf map
based on mVpnLockdownUidRanges.
PermissionMonitorTest verifies the args of updateUidLockdownRule call.
So, It's not necessary to verify the mVpnLockdownUidRanges which
is internal states of PermissionMonitor.
Test: atest PermissionMonitorTest
Bug: 262199762
Change-Id: I85b39ab2aff44dcbe809b39560d6bb87fbb0c084
getVpnInterfaceUidRanges acquire lock and access internal state of a
Handler-based class (PermissionMonitor), which is bad practice in
general.
getVpnInterfaceUidRanges returns mVpnInterfaceUidRanges.
PermissionMonitor call add/removeUidInterfaceRules and update the bpf
map based on mVpnInterfaceUidRanges.
PermissionMonitorTest/ConnectivityServiceTest verifies the args of
add/removeUidInterfaceRules call.
So, It's not necessary to verify the mVpnInterfaceUidRanges which
is internal states of PermissionMonitor.
Test: atest ConnectivityServiceTest PermissionMonitorTest
Bug: 262199762
Change-Id: I31cbb9b1dd43eaf0354799a81c9df292fb5f6445
Allow toggling MdnsAdvertiser and MdnsDiscoveryManager at runtime, by
always creating them in NsdService constructor, but only using them when
the flag is on when starting discovery, resolve or registration.
When stopping, based on the type of the stored request, stop the
corresponding backend.
Bug: 265891278
Test: atest NsdServiceTest
Change-Id: I7cb2f9fe9e1ed3dc77616689a8e3ffa00f5bc269
When registering and advertising a service on the same device, it is
possible for NsdService to find the service on the dummy0 interface. It
is however unusable and not resolveable.
Skip callbacks on the dummy0 interface as they would confuse apps and
tests.
Bug: 266176036
Test: atest NsdServiceTest
Change-Id: I98cca0135e0f6936187d45707cbdad7a7f263ff1
Even if there are no preferences, the allow list needs
to be updated upon adding a new user, because it's set
unconditionally when the network connects.
Adding all existing UIDs would address this issue too
and we probably want to do it, but immediately this
seems simpler.
Bug: 266136779
Test: new test for this
Change-Id: I77091a6c3d3ccf2b80ab0aaa01d09ef0df922501
Add a flag to control dynamic keepalive mode so that this
feature could be dynamically enabled via flag push. Default
is enabled in KeepaliveTracker.
Bug: 259000745
Test: atest FrameworksNetTests
Change-Id: I438de9aefd22229669a9ae4da5fd109fdfa73b10
On each received packet, query MdnsRecordRepository to detect any
conflicting service, and report it though onServiceConflict.
Implement restartProbingForConflict and renameServiceForConflict which
may be called when that callback is dispatched.
Bug: 266151066
Test: atest MndsInterfaceAdvertiserTest MdnsRecordRepositoryTest
Change-Id: I5434b00879e0c8f7fc1e4769455b688c3bd7a9b5
Currently, the resolution is a one shot query, it only notifies
the first finding service information. There is no way to listen
the service update. Thus, add a new API that can register a
callback to listen to the service updates continuously.
Bug: 245369943
Test: atest FrameworksNetTests CtsNetTestCases
Change-Id: I0e9d92b9028375feb3e344ab6c4acb515c5b2be9
Add a new AutomaticOnOffKeepaliveTracker class between
ConnectivityService and KeepaliveTracker to handle the automatic
on/off keepalive. This commit only creates this new class and
move the TCP polling code to the new class as a preparation for
the following commit.
The original test file was created for testing the TCP polling
mechanism, so rename it to match the new class.
Bug: 259000745
Test: m ; atest FrameworksNetTests
Change-Id: I1b229f906283c0f5ef7a3efdb0572fcbfc5df72b
