Instead of classifying interfaces by network type in BatteryStats,
classify them based on the transports array provided by the
NetworkAgent.
Network types are deprecated and transports should be used instead. This
change allows BatteryStats to stop depending on unstable APIs such as
isNetworkTypeMobile.
This change also updates nullability annotations in ConnectivityService
and NetworkAgentInfo to show that the NetworkCapabilities are non-null
(as provided by the network agent) when calling
noteNetworkInterfaceTransports.
This is rolling forward a previously reverted change. The new change
also fixes MobileRadioPowerCalculatorTest that was broken when
submitting the previous change.
Bug: 174436414
Test: atest
atest ConnectivityServiceTest#testBatteryStatsNetworkType \
--rerun-until-failure 40
Merged-In: I4e928fac8a57a9b1fc758a44af2a5719b8c871b8
Change-Id: I4e928fac8a57a9b1fc758a44af2a5719b8c871b8
(cherry picked from commit 2d17d202bc709c205506c03149d847f00f92d78d)
As a preparation of exposing system API. This patch does some
harmless refactoring, which includes:
1. Move VpnInfo to android.net
2. Add nullability annotations
3. Make members final
Bug: 174123988
Test: TH
Change-Id: I1530bb45d0e84c28c6deac33596bc686058afc0d
In follow-up patches, the network type will be derived from
transport types, which officially doesn't support wimax.
Thus, remove the test which rely on it first since it is
not needed and will not be needed.
Test: atest FrameworksNetTests
Bug: 174123988
Change-Id: I713bc2ec39e3a4fa19ed13d2e9ff9ae35477d726
This allows subsequent patches to remove the need of exposing
SSID in NetworkState.
Test: atest NetworkStatsServiceTest
Bug: 174123988
Change-Id: Ib9ab07c9610954c9a5de035a3aefbf6d0bb0b53b
* The match method is only for local address and port since we have
no other use case.
Bug: 155176305
Test: Added new test
Change-Id: I7b45f9912af6a192fc60606f5e0b4cc479aea93f
* Provide App Developers Qos related info associated to
a bound socket through ConnectivityManager
* Qos sessions are generated and filtered by Network Agents
and sent back through the Connectivity Service to the
API consumer.
* The structure of the code within com.android.server
is designed to support different types of filters in the
the future.
* The first type of Qos Attributes are related to EPS
Bearers in order support RCS.
Bug: 155176305
Test: Added to cts/NetworkAgentTest
Test: Added to ConnectivityServiceTest
Change-Id: I145dd065d9deeee449eb9695ab3f6c8556ee7c09
Instead of classifying interfaces by network type in BatteryStats,
classify them based on the transports array provided by the
NetworkAgent.
Network types are deprecated and transports should be used instead. This
change allows BatteryStats to stop depending on unstable APIs such as
isNetworkTypeMobile.
This change also updates nullability annotations in ConnectivityService
and NetworkAgentInfo to show that the NetworkCapabilities are non-null
(as provided by the network agent) when calling
noteNetworkInterfaceTransports.
Bug: 174436414
Test: atest
atest ConnectivityServiceTest#testBatteryStatsNetworkType \
--rerun-until-failure 40
Change-Id: Icc912473d97a42eef73eb953607c9161fdbeb794
Currently, when the VPN underlying network changes from a
network that is not suspended to one that is suspended (or vice
versa), some of the legacy APIs return incorrect results.
This is because the VPN's NetworkInfo can get into SUSPENDED
state even though the capabilities have the NOT_SUSPENDED
capability. This happens because the code in updateCapabilities
that checks for changes in NOT_SUSPENDED and NOT_ROAMING (which
are the capabilities that can affect the NetworkInfo state) is
only run when the capabilities change in a certain way.
Fix this by always checking for changes in these capabilities,
regardless of what else has changed.
This results in sending a lot more SUSPENDED and RESUMED
callbacks than the code sent previously. This should hopefully
not impact apps because those callback methods have never been
public API, though because they're just callbacks, it's possible
that apps found out via code inspection that the callbacks
existed and implemented them.
Bug: 172870110
Test: changes to existing tests in ConnectivityServiceTest
Change-Id: I6ec246a6a4e61f634956a165797fbb80296efd6a
Lorenzo Colitticommited 2021-01-20 11:32:51 +09:00
* changes:
Address comments on aosp/1539753, aosp/1542487 and aosp/1547496.
Fix propagating underlying caps when a network disconnects.
Test for bugs with suspended VPN underlying networks.
Treehugger Robotauthored and Gerrit Code Reviewcommited 2021-01-19 04:19:56 +00:00
aosp/1513052, which generalized support for underlying networks,
broke default network switching when the network underlying a VPN
disconnects.
This is because it calls propagateUnderlyingNetworkCapabilities
in the middle of the bookkeeping operations needed when a
network is disconnected (specifically, after all satisified
requests are removed from the disconnecting network, but before
mDefaultNetworkNai is updated). This is completely incorrect
because propagateUnderlyingNetworkCapabilities can trigger a
network rematch, and running a rematch when the request data
structures are inconsistent is obviously wrong. See the test
changes in this CL for an example of the damage.
Fix this by moving propagateUnderlyingNetworkCapabilities to
before the bookeeping operations begin. It must be before
mDefaultNetworkNai is updated, because otherwise it will not know
that the default network is disconnecting, and it will not be
able to propagate capabilities to VPNs that set underlying
networks to null (i.e., to the default network). It must be
after the nai is removed from mNetworkForNetId because
otherwise it will think that the underlying network is still
connected.
Bug: 173331190
Test: accompanying unit test shows lots of bugs removed
Change-Id: Ibf376a6fa4b34d1c96f8506fa8abbb7595a8c272
Lorenzo Colitticommited 2021-01-19 09:40:53 +09:00
This will be mainly used by VCN management service which will
need to hold the networks but preserve the backgrounded-ness
of the networks.
Test: android.net.ConnectivityManagerTest#testRequestType
Test: android.net.cts.ConnectivityManagerTest#testRequestBackgroundNetwork /
--rerun-until-failure 100
Test: ConnectivityServiceTest#testBackgroundNetworks
Test: m -j doc-comment-check-docs
Bug: 175662146
Change-Id: If9aaa87b7e71c2b695ac7b08858850e975b28bb6
This test flakes about 1% of the time on my device. This is due
to the test calling expectNetworkRejectNonSecureVpn() before the
handler thread has processed the call to setAlwaysOnVpnPackage.
Fix this by waiting for callbacks where it is possible to do so,
and by calling waitForIdle where it is not.
Test: test-only change
Change-Id: Ic5750d4fdf9e7e3654a2b6ade74da6bc5de18fb6
Lorenzo Colitticommited 2021-01-18 17:28:52 +09:00
Code review comments have suggested that this test is too long
and difficult to understand. Split it into two tests and put some
of the common setup into setup methods and statics.
Bug: 173331190
Test: test-only change
Change-Id: I9fa888c940d7048f1ba6836a5706fbdb84b5f5c9
Lorenzo Colitticommited 2021-01-18 17:28:52 +09:00
These fields have been recently audited, confirmed never to be
null, and annotated @NonNull. Ensure that they can never become
null by throwing exceptions in the codepaths that set them.
Also remove some null checks.
Test: atest FrameworksNetTests
Change-Id: I6ce5bb4d69a990f1c857c599b7e50e372352eb87
Lorenzo Colitticommited 2021-01-18 07:49:26 +00:00
This is a port of the exemption that exists in WifiPermissionsUtil.
Settings, sysui, network stack needs to be able to access all network
state regardless of location toggle. If we want to move sysui, etc to
retrieve WifiInfo via NetworkCapabilities (which is the current plan),
this exemption is essential since UI should reflect wifi state
regardless of location toggle state.
Bug: 162602799
Test: atest LocationPermissionCheckerTest
Change-Id: I49ce465eccce27bb7a860d882360436fd9ec19c6
We currently test CONNECTIVITY_ACTION broadcasts by directly
registering BroadcastReceivers with BroadcastInterceptingContext,
and making the receivers unregister themselves when all the
broadcasts they expect have been received.
This works for current test cases, but does not work if anything
registers another receiver for CONNECTIVITY_ACTION. In that case,
when we unregister the receiver in the receiver's onReceive
method, BroadcastInterceptingContext will throw a
ConcurrentModificationException because the list of receivers is
being modified during iteration.
Fix this by adding an ExpectedBroadcast class that stores the
receiver and unregisters the receiver only when the test checks
that the broadcast was received, which happens after the receiver
runs. This is easier to use and also guarantees that the receiver
is unregistered even if the test is expecting that the broadcast
is never fired. Accordingly, remove mRegisteredReceivers and the
code that uses it; it's no longer necessary now that
ExpectedBroadcast always unregisters its receivers.
Also add a convenience expectConnectivityAction method to expect
a CONNECTIVITY_ACTION broadcast with specific contents. This
makes the test easier to read and more detailed. Convert some
existing tests to this method.
While I'm at it, fix a test that was using "mCellNetworkAgent" to
represent a wifi network.
Bug: 173331190
Test: test-only change
Change-Id: Ibada8b4215625e1016d9fd170526206920af76f5
Lorenzo Colitticommited 2021-01-15 20:04:57 +09:00
Lorenzo Colitti
authored and
Automerger Merge Worker
commited 
Gerrit Code Review
commited 
TreeHugger Robot
authored and
Android (Google) Code Review
commited 
Remi NGUYEN VAN
commited 
junyulai
commited 
Daniel Bright
authored and
Chalard Jean
authored and
Paul Hu
authored and
Roshan Pius
authored and
James Mattis
authored and