am skip reason: Change-Id I37dd459d08b57b14f72f3b28ea80fa231b152f10 with SHA-1 bfd3c75dce is in history
Change-Id: Ie3884e88a5e1b7e8997da346c7984a6bf02b186f
am skip reason: Change-Id I37dd459d08b57b14f72f3b28ea80fa231b152f10 with SHA-1 b645699cdb is in history
Change-Id: I0ea68069cd9e07bf2d95b14452046fdb63613782
am skip reason: Change-Id I37dd459d08b57b14f72f3b28ea80fa231b152f10 with SHA-1 b645699cdb is in history
Change-Id: I439913a4195cea16832b3ec6c19a3cfaa63dfdb8
am skip reason: Change-Id I37dd459d08b57b14f72f3b28ea80fa231b152f10 with SHA-1 b645699cdb is in history
Change-Id: Ib9aaf9091937ae27f35a389cc3de696567cefe1b
am skip reason: Change-Id I1959f3080946267243564459ff4207647922566e with SHA-1 6ee2b93ed3 is in history
Change-Id: Id31a417c7a4204bd646400e90456424d12d2d9d0
am skip reason: Change-Id I37dd459d08b57b14f72f3b28ea80fa231b152f10 with SHA-1 b645699cdb is in history
Change-Id: I0b5556bcaa27ca0a379f910bfba80aec506348c9
As NetworkAgent is in a transition where all agents need
to include the NOT_SUSPENDED capability as part of their
migration to the system API, ConnectivityService adds it
forcefully to all agents that don't have the CELLULAR
transport. This doesn't include VPNs when VPNs have some
cellular network as their underlying network.
The best way to solve this is to make sure the VPN
capabilities reflect those of the underlying networks as
far as the NOT_SUSPENDED capability is concerned. This
is how they work for other similar capabilities.
This also happens to contain a drive-by fix for an issue
with a spurious capabilities callback is triggered when
a VPN connects and it has any underlying network (which
means almost always, because it will take the default
network if it doesn't declare any). Fixing this was
necessary to have a cogent test of this issue, but it
could be moved to another patch or it could stay unfixed
with some minor ajustment to the tests if judged too
dangerous to include in R at this point.
Test: New tests in this patch. Also manually tested with
tcpdump as described in b/150570873.
Bug: 150570873
Change-Id: I3e4ff990c0d4825b21c7679be29a482a2d1324ec
Set the parcelSensitiveFields bit when sending LinkProperties to
NetworkMonitor, so that the captive portal API URL is not lost.
Test: atest ConnectivityServiceIntegrationTest (see followup change)
Bug: 156062304
Change-Id: Ifd4e9c02a6b9a2b2b8b254fc4da7bfb9e0a84550
This change adds tests to validate that both transport and tunnel mode
transforms continue to work even after the SPI resource has been
released. Specifically, since SPI resources are effectively subsumed by
the creation of a Transform, the SPI resource is still "alive", but
removed from the user-tracking sparse arrays.
Bug: 142072071
Test: Added these new tests. Failing prior to aosp/1133555, passes with.
Change-Id: I37dd459d08b57b14f72f3b28ea80fa231b152f10
Merged-In: I37dd459d08b57b14f72f3b28ea80fa231b152f10
(cherry picked from commit 4d3f871a944d24cd7cbe3aa51a789a71020eafb5)
IpSecService.applyTunnelModeTransform() currently does not take an
SpiRecord instance, yet implicitly requires that the SpiRecord instance
is still alive based on the stored SpiRecord resourceId in
the TransformRecord's IpSecConfig.
This check is unnecessary, as the SpiRecord has been subsumed into the
TransformRecord, and the kernel resources are kept alive whether or
not the SpiRecord is still held by the user.
This allows users of the IpSecManager API to allocate short-lived SPIs
during the creation of an IpSecTransform, without having to keep track
of both of them (even though the SPI is no longer usable).
The TransformRecord.getSpiRecord() call is already used in
multiple other places in the same method.
Bug: 142072071
Test: New tests added, passing.
Change-Id: I1959f3080946267243564459ff4207647922566e
Merged-In: I1959f3080946267243564459ff4207647922566e
(cherry picked from commit 5258b1b82f39bf17e0751bcb94479464250aaec5)
am skip reason: Change-Id I10e26cb0852e67f614e7b9c4e49f95e078602e21 with SHA-1 71863e9604 is in history
Change-Id: I4d8faea3916fe55ca25d4162893f22d004176116
am skip reason: Change-Id I10e26cb0852e67f614e7b9c4e49f95e078602e21 with SHA-1 71863e9604 is in history
Change-Id: I56c31471f54180a6e49cf1a72a1793618c5bec1c
am skip reason: Change-Id I10e26cb0852e67f614e7b9c4e49f95e078602e21 with SHA-1 71863e9604 is in history
Change-Id: Ie43cc7dbddd5497dfa069fac5570a7a64eddb2a1
When a VPN connects and it has any underlying network (which
means almost always, because it will take the default network
if it doesn't declare any), it has default capabilities and
will only take the capabilities of its underlying network
as part of an update happening after making the network
available but before the rematch can take place. This in turn
causes the capabilities callback sent as part of the rematch
to be spuriously sent.
Test: FrameworksNetTests. Also tested together with a
followup that adds tests with drive-by coverage for this.
Bug: 150570873
Change-Id: Id7d8bba486bada1a7ba5b0f152d2aa02e407f249
Added a new network capability TEMOPORARILY_NOT_METERED to support
the case that a network can temporarily become unmetered. This
allows carriers to deploy unmetered 5G network. When devices
camp on 5G network, this capability will be dynamically added
to the network and will be removed once leaving 5G coverage.
Bug: 153081494
Test: Manual
Change-Id: I10e26cb0852e67f614e7b9c4e49f95e078602e21
Merged-In: I10e26cb0852e67f614e7b9c4e49f95e078602e21
am skip reason: Change-Id I45c3aa9046b316c8cd0943543d620a22e4afefd1 with SHA-1 c6081f9c50 is in history
Change-Id: I61304a3c61ea7c76a3012a27f8a0964abd32cc0a
am skip reason: Change-Id I45c3aa9046b316c8cd0943543d620a22e4afefd1 with SHA-1 c6081f9c50 is in history
Change-Id: Ia28361c12804065aa4e0729f3e6283a7f4049101
am skip reason: Change-Id I45c3aa9046b316c8cd0943543d620a22e4afefd1 with SHA-1 c6081f9c50 is in history
Change-Id: I44a2ee47f6a88286b28d5165c67cfd4fdbdd0152
