Test extra info sent to NetworkMonitor correctly if network
agent is created through new NetworkAgent constructor without
legacy network info taken as parameter.
Bug: 156173829
Test: atest FrameworkNetTests
Merged-In: I4f827664c528bea30cc957a0a617dd37693f4460
Change-Id: I4f827664c528bea30cc957a0a617dd37693f4460
Some developers have been surprised by this limitation and had trouble
figuring out what the issue was. Add documentation to address this.
This also includes a drive-by removal of a duplicate check.
Bug: 149867479
Test: doc-only change
Original-Change: https://android-review.googlesource.com/1313813
Merged-In: I5911d01984695550b6c9afe7a8eb535bf5e320a1
Change-Id: I5911d01984695550b6c9afe7a8eb535bf5e320a1
config_mobile_hotspot_provision_app would be move out of framework and
only private for tethering only.
enforceTetherChangePermission is no longer needed because its only
caller PanService already gate by other privileged permission
(BLUETOOTH_PRIVILEGED).
Bug: 146918263
Test: m
Change-Id: I030871c2bc46bc09c4e52970b4995f98d31bb90e
Merged-In: I030871c2bc46bc09c4e52970b4995f98d31bb90e
Avoid using the "iff" abbreviation in our Javadoc.
Bug: 158092978
Test: m doc-comment-check-docs and check the generated doc
Merged-In: I41bf8a6ddad200f00524d9b2dd1bf169810ee460
Change-Id: I41bf8a6ddad200f00524d9b2dd1bf169810ee460
The extra info is taken into NetworkMonitor from while creating
it. The NetworkMonitor is created when a new agent is registered
but the extra info is not available at that time. Make sure the
field is set in the NetworkInfo when registering.
Bug: 156173829
Test: adb shell dumpsys network and check the apn in the extra
info shown correctly
Test: atest FrameworkNetTests
Merged-In: Ieaad8cbf1a28af3b97c7f98f74358e417fcad661
Change-Id: Ieaad8cbf1a28af3b97c7f98f74358e417fcad661
This consumes ~3.5% system logs, however it is not very useful
when debugging since similar information could be obtained from
dumpsys {connectivity|netpolicy}. Thus, remove the log.
Test: manual
Bug: 135504481
Change-Id: I04d2b7402f892546722fe6868c521afd9534f183
Merged-In: I04d2b7402f892546722fe6868c521afd9534f183
(cherry picked from commit 21a352f761ce558bea6fa9ab2a4e49a164228b56)
Ethernet networks using tap interfaces should have TRANSPORT_TEST so
they are not considered by network selection.
Test: atest CaptivePortalApiTest FrameworksNetTests
Bug: 156319532
Original-Change: https://android-review.googlesource.com/1317238
Merged-In: I0d9477977c88aa055625ab4046577a41e76b05ff
Change-Id: I0d9477977c88aa055625ab4046577a41e76b05ff
This change adds the @RequiresFeature annotation to Ikev2VpnProfile
Builder methods, and checks before provisioning VPN profiles.
Bug: 156681625
Test: New tests added, passing.
Change-Id: I125d8fbe5d67fb877ad7d0636c007cb3e1a9f59b
Merged-In: I125d8fbe5d67fb877ad7d0636c007cb3e1a9f59b
(cherry picked from commit e84a17dd1706f4c8373047b2023a1ec4b7cf4bf3)
This should no longer be needed after all the cleanups.
Test: atest NetworkStatsTest NetworkStatsFactoryTest
Bug: 150738490
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I289d935f84b616ed857ef4c5a7427d57c282d00c
Merged-In: I289d935f84b616ed857ef4c5a7427d57c282d00c
No clat app uid 0 rx stats on base iface due to ip6tables raw prerouting drop
(so just copy over the rx stats from the before file)
Test: atest NetworkStatsTest NetworkStatsFactoryTest
Bug: 150738490
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ie73ba0586dafde67bc2726db26e07f7268c18be3
Merged-In: Ie73ba0586dafde67bc2726db26e07f7268c18be3
No clat app uid 0 rx stats on base iface due to ip6tables raw prerouting drop
Test: atest NetworkStatsFactoryTest
Bug: 150738490
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I4393afcbe8e1bb886ecf4f5c1573f6ac8a0e29f5
Merged-In: I4393afcbe8e1bb886ecf4f5c1573f6ac8a0e29f5
No clat app uid 0 rx stats on base iface due to ip6tables raw prerouting drop
Test: atest NetworkStatsFactoryTest
Bug: 150738490
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ifebd946e06b5fa2eeb7ff4fc0b1c423097021692
Merged-In: Ifebd946e06b5fa2eeb7ff4fc0b1c423097021692
This change adds a comment to CS#simulateDataStall to explain why the
Data Stall is wrapped in a DataStallReportParcelable before being passed
to the ConnectivityDiagnostics handler. This approach is taken to ensure
that simulated data stalls are handled the exact same as Data Stalls
received directly from NetworkMonitor (including Data Stalls detected by
methods that the platform does not understand).
Bug: 156294356
Test: atest ConnectivityDiagnosticsManager
Change-Id: I751054418bf328c72b977a1cc99c27cb9b8ab7ba
Merged-In: I751054418bf328c72b977a1cc99c27cb9b8ab7ba
(cherry picked from commit c86db7497a27cfbac5c662911a295598b1335bc0)
This is only necessary when learning the NAT64 prefix from the
RA, because if the NAT64 prefix is learned from DNS, the DNS
resolver already knows the prefix and automatically enables
DNS64 synthesis.
The DNS resolver needs to be informed of the prefix any time
clat is running on a prefix learned from an RA. This is simple to
implement: just set the prefix when starting clat if prefix
discovery is not running, and clear the prefix when stopping clat
if prefix discovery was not running. This ensures that the prefix
is cleared iff it was set.
Bug: 156914456
Test: new unit test coverage
Original-Change: https://android-review.googlesource.com/1315578
Merged-In: If8ad2d30712a6df3e207c8d3e8a129705242191e
Change-Id: If8ad2d30712a6df3e207c8d3e8a129705242191e
This is not particularly likely to happen unless the pref64 RA is
sent by a different router than the main RA. But more tests are
always good, and this additional coverage will be more useful
in an upcoming change.
Bug: 150648313
Test: test-only change
Original-Change: https://android-review.googlesource.com/1316094
Merged-In: I3316d49d42100800740afadc4edf0a13a4d8377c
Change-Id: I3316d49d42100800740afadc4edf0a13a4d8377c
This CL forwards suspected Data Stall events detected with unknown
detection methods to ConnectivityDiagnostics.
Currently, ConnectivityService drops any data stall events with unknown
detection methods, which leads to false negatives for Connectivity
Diagnostics registrants. This change ensures that registrants will still
be notified as NetworkStack is updated to use new detection methods.
The documentation for ConnectivityDiagnosticsManager#DataStallReport is
also updated to reflect that the detection methods included in the
report are a bit mask of detection methods used. Implicitly, this means
that data stalls detected via unknown methods will have an empty bit
mask (0x00).
Bug: 156294356
Test: atest ConnectivityDiagnosticsManager
Change-Id: I62d0bf91fcc17c7921afd519c72551399906bd6b
Merged-In: I62d0bf91fcc17c7921afd519c72551399906bd6b
(cherry picked from commit a1d9d811a05bf3447ebb90a39343b53eee79f0db)
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
Original-Change: https://android-review.googlesource.com/1301317
Merged-In: I3e4ff990c0d4825b21c7679be29a482a2d1324ec
Change-Id: I3e4ff990c0d4825b21c7679be29a482a2d1324ec
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
Original-Change: https://android-review.googlesource.com/1305393
Merged-In: Id7d8bba486bada1a7ba5b0f152d2aa02e407f249
Change-Id: Id7d8bba486bada1a7ba5b0f152d2aa02e407f249
This change moves the logic for handling Data Stall notifications from
NetworkMonitorCallbacks to ConnectivityService. This avoids duplicate
logic for managing data stall simulation requests from
ConnectivityManager. This also puts all of the logic for proxying Data
Stall notifications to the ConnectivityDiagnosticsHandler into one
place.
Bug: 148032944
Test: atest ConnectivityDiagnosticsManagerTest
Change-Id: Ie2f6a1a2376c5c452750ab417cb5e8c24fc44fc3
Merged-In: Ie2f6a1a2376c5c452750ab417cb5e8c24fc44fc3
(cherry picked from commit 745eaa39a3c9bcaaa61671f66d8c1180195c84c4)
This change adds the ability for IKEv2/IPsec VPN profiles to run on Test
Networks. If enabled, the IKEv2/IPsec VPN profiles will request ONLY
test networks.
Bug: 148582947
Test: FrameworksNetTests passing
Test: Added for testing
Change-Id: I2511b39b27a1e29ae97907cdb12728d13fb1628f
Merged-In: I2511b39b27a1e29ae97907cdb12728d13fb1628f
(cherry picked from commit 9e18eeb4a676ef3afc4bc510f18f81213b8edc55)
