Currently, NET_CAPABILITY_TEMPORARILY_NOT_METERED traffic is
counted as unmetered data usage, and "mobile data usage"
settings screen shows metered data usage which means it doesn't
include TEMPORARILY_NOT_METERED traffic. However, some carriers
show TEMPORARILY_NOT_METERED data usage in customer's bill which
would be confusing if the data usage in the device shows different
results. Thus, revert the change to avoid confusing.
Bug: 183776809
Test: FrameworksNetTests
Change-Id: I4ef25095462adf30b1ecf82134996739f167930d
This commit clear the calling identity before accessing the
DeviceConfig in ConnectivityService#dump().
The calling package of DeviceConfig.getProperties() comes from
ActivityThread.currentApplication(). In ConnectivityService#dump(),
the caller is ConnectivityService. It's OK to access DeviceConfig
from ConnectivityService. The same scenario applies to an app with
proper permission accessing DeviceConfig from its own context.
However, if cts would like to verify design by calling
ConnectivityService#dump(), the calling uid will comes from the
binder but package name will stay as ConnectivityService which
is 'android'. This will result in a SecurityException says that
the package does not match the uid and failed the test.
Bug: 255231779
Test: atest CtsNetTestCases FrameworksNetTests
Change-Id: I257e246b1cbf3b8a93bee2c326055ced9dfde588
- The UidRange getter and dump methods which is to access
mVpnInterfaceUidRanges and mVpnLockdownUidRanges need to guard
with synchronized to ensure the value won't be changed during
accessing.
- Also make getVpnLockdownUidRanges() to be a package-private
method. It's accessed from PermissionMonitorTest only.
Bug: 232048835
Test: FrameworksNetTests CtsNetTestCases
Change-Id: I850f155a01c309f9d75f5143dc0a46a1505415bd
To ensure that permission cannot change while CS is doing works,
scoring networks, sending callbacks, etc. So making all
permission update are running on handler thread.
Bug: 232048835
Test: FrameworksNetTests CtsNetTestCases
Change-Id: I5380ec8ff1282a1056d9063848e0fff8b3a570ec
Most permission update functions are running on the handler
thread. So the startMonitoring() should be running on handler
thread as well to ensure the permission won't change while
processing CS's works.
However, startMonitoring() has a dependency with
MultipathPolicyTracker. It needs to call and complete the
permission update before calling MultipathPolicyTracker#start.
Thus, we need to check the startMonitoring done in the end of
systemReadyInternal because we are processing it on the handler
thread.
Bug: 232048835
Test: atest FrameworksNetTests CtsNetTestCases
Change-Id: I41fef14d6c163eb5676eab3ccd43416ea1fe1414
Currently 5G usage includes both metered and unmetered usage.
To support 5G unmetered usage metrics, unmetered usage should
be separated from the 5G usage. Thus, ConnectivityService needs
to inform NetworkStatsService if TEMPORARILY_NOT_METERED has
changed. Then NSS will count temporarily not metered usage as
unmetered.
Bug: 222339311
Bug: 183776809
Test: FrameworksNetTests:ConnectivityServiceTest
Change-Id: I0c7e1eb98925184f36e322e09b4d3d8c6f056fa6
Some callers (e.g. iwlan) need to learn about system default
network but they cannot have NETWORK_SETTINGS permission.
To allow them to use this API but prevent from misuse by
unprivileged apps, enforce USE_RESTRICTED_NETWORKS for this API.
Test: atest com.android.server.ConnectivityServiceTest#testRegisterPrivilegedDefaultCallbacksRequireNetworkSettings android.net.cts.ConnectivityManagerTest#testRegisterNetworkCallback
Fix: 242456635
Change-Id: I80ab27445af874328c9c0f4814a8fbf035ae5df4
In ConnectivityService, updateLinkProperties calls NetworkStats
even though the ip address or interface name has not changed and
only the tcp buffer size has changed. This is noisy and could
be problematic when RAT change occurs frequently, since when
RAT changes tcp buffer size configuration also changes.
This CL also fixes a wrong nullability annotation where the oldLp
of updateLinkProperties could be null when updateNetworkInfo
is called.
Test: atest ConnectivityServiceTest#testStatsIfacesChanged
Fix: 232048480
Change-Id: Ic226eb4a8aa1f38cba293510813f1cb55f0ea658
This allows clat to initialize properly when VPNs are configured
with "Block connections without VPN", rather than to error out with
"no IPv6 addresses were available for clat".
This issue primarily affects particular mobile networks configured
with NAT64 (without direct IPv4 connectivity).
Bug: 255040839
Change-Id: I4a8ee0295e0f5d1e330f7529856347b8bd10360c
t-m-wauthored and Maciej Żenczykowskicommited 2022-10-25 01:54:51 +00:00
shouldIgnoreValidationFailureAfterRoam will incorrectly return
true in the first few seconds after boot even if the network
never roamed. This is extremely unlikely to happen, but add a
check for that just in case.
Fix: 230450214
Test: new unit test
Change-Id: I0789d9bdaa0bd9e78673e8f4248a2ca610052f1e
Lorenzo Colitticommited 2022-10-24 23:28:56 +09:00
This is not used, and cannot be used: clat v4-* interfaces
are - by virtue of method of creation - always rawip.
This is because they are tun (not tap) devices.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Iaafdd6e471c63668d7fe79b62257255bf98c4fb8
Maciej Żenczykowskicommited 2022-10-24 02:16:18 -07:00
This will be useful for diagnosing default network changes.
Logs may look like, for example :
Update capabilities for net 100 : -NET_CAPABILITY_OEM_PAID+NET_CAPABILITY_TRUSTED
Or :
Update score for net 100 : -POLICY_EVER_EVALUATED+POLICY_IS_VPN+POLICY_IS_DESTROYED
Test: FrameworksNetTests
manual
Change-Id: Ic4788c599573aae9daeca995b8853800aaaba0b8
Information in the dump does not change
....
current ownerMatch configuration: 516 DOZABLE_MATCH OEM_DENY_1_MATCH
....
Bug: 217624062
Test: dumpsys connectivity trafficcontroller, atest BpfNetMapsTest
Change-Id: I5f7b56e4ba03256414f49d0e82d65477fb97f05a
Information in the dump does not change
....
current statsMap configuration: 0 SELECT_MAP_A
....
Bug: 217624062
Test: dumpsys connectivity trafficcontroller, atest BpfNetMapsTest
Change-Id: I42a844227f258b91ba5b368d8e8abf82a773a801
Also remove the dump of mPrivilegedUser because this is not used now and
the information is duplicated with uidPermissionMap dump.
Before this CL
....
mUidPermissionMap:
10049 PERMISSION_NONE
10027 BPF_PERMISSION_INTERNET BPF_PERMISSION_UPDATE_DEVICE_STATS
1041 BPF_PERMISSION_UPDATE_DEVICE_STATS
....
After this CL
....
sUidPermissionMap:
10049 PERMISSION_NONE
10027 PERMISSION_INTERNET PERMISSION_UPDATE_DEVICE_STATS
1041 PERMISSION_UPDATE_DEVICE_STATS
....
Bug: 217624062
Test: dumpsys connectivity trafficcontroller, atest BpfNetMapsTest
Change-Id: I416501d5a28a5443f954f9c8c58ea255e5cdc897
After setting 'avoid unvalidated' the next update of the
score by the agent will set the wrong value for that
flag in the NetworkScore object.
Also have the default behavior on S and T be like the old
one, rather than the new one
Test: manual
Change-Id: I0c161fe7098d3c60827fd50190911b6b762dfa42
Test: FrameworksNetTests
adb shell device_config put connectivity actively_prefer_bad_wifi
+ check that dumpsys updates
Test: at this patchset tests fail with :
Permission denial: reading from settings requires:android.permission.READ_DEVICE_CONFIG
Change-Id: Icfe1e64b8313921ff1dc8e4cbd45f967692e1c4a
This is necessary so that MultinetworkPolicyTracker can see
DeviceConfig. It will also allow removing reflection from
this file to address a long-standing TODO.
Test: build
Change-Id: I968bf67e0e0189b01515242371599c02bc9e2ca2
ClatCoordinator should not rely on the caller Nat464Xlat to
avoid dumping when clat is not started. It is safer to dump
information after ClatCoordinator has checked its status.
Only dumping ClatCoordinator with clatd started reduces the null
pointer check of dumped elements as well.
Test: atest ClatCoordinatorTest
Change-Id: Ia0be9a593cd75fd34f647230d642b0dcf84aaf3b
Hungming Chenauthored and Nucca Chencommited 2022-09-26 10:32:42 +00:00
With this patch and "config_activelyPreferBadWifi=1"
(or SDK level >= U) and bad wifi avoidance turned off,
when the device connects to a bad wifi, after 20
seconds of the wifi not validating the device will
pop up a head-up notification with text
"<SSID> has no internet access".
When tapped, the notification will bring up the existing
Settings dialog :
*Wifi not connected to the internet*
You can switch to mobile whenever Wi-Fi is bad
□ Never show again
<Stay on Wi-Fi> <Switch to Mobile>
If the wifi validates and loses access again, the same
notification/dialog are shown if Settings.Global.
NETWORK_AVOID_BAD_WIFI=PROMPT ; if IGNORE, the device
stays stuck on wifi.
If AVOID, then bad wifi avoidance is turned on in the
first place, so none of this happens.
Behavior in other cases :
- If config_activelyPreferBadWifi=0, then upon connecting
to a wifi without internet, the behavior is unchanged :
the device stays on mobile and after 8 seconds a
notification pops up asking whether to stay connected.
If the network validates, then loses access, the behavior
depends on a few things :
- If config_networkAvoidBadWifi is 0 and Settings.Global.
NETWORK_AVOID_BAD_WIFI = IGNORE, then the device stays
on wifi and says nothing.
- If config_networkAvoidBadWifi is 0 and Settings.Global.
NETWORK_AVOID_BAD_WIFI = PROMPT, then
notification pops up asking whether to switch to mobile.
- If config_networkAvoidBadWifi is 1 (regardless of the
value of Settings.Global.NETWORK_AVOID_BAD_WIFI), or if
Settings.Global.NETWORK_AVOID_BAD_WIFI = AVOID, then
the device switches back to mobile.
- If Mobile is not connected, all the above applies. This
is not great for the messages including "switch to mobile"
but this patch doesn't change it.
Test: manual
Change-Id: Idb05b6a6e5c085f5ef72435d462e14bfd1341f87
If a notification is up and the avoid bad wifi setting
is turned off, the notification should disappear.
This patch also adds some general tests for the bad wifi
notifications.
Test: new tests in this patch
Change-Id: I5bc42afbe0efd93cfb59a759bf0aaba49a4bfc9f
In the previous code, ConnectivityService would mark a network
a captive portal when NetworkMonitor sends it a message to notify
the user for it. Theoretically, this is incorrect ; instead, the
marking should be done upon receiving the message that the network
was tested to be a captive portal.
In practice this hasn't been a problem so far. The captive portal
capability is observable in the app-received callbacks, but for
these purposes the old code and the new code behave the same, in
that in the callbacks, the network used to not have the portal
capability, then later it acquires it.
However, this is only not a problem as long as the captive portal
bit isn't used by network selection, which an upcoming change has
to implement for the "prefer bad wifi" feature. When that is the
case, network selection prefers the wrong result between the time
the network is marked as having been evaluated and the time the
network has been marked a captive portal. It should be marked as
both at the same time to avoid this discrepancy. This is what
this patch is accomplishing.
To do this correctly, this patch also has to disconnect the network
immediately upon it being tested as a captive portal if the old
CAPTIVE_PORTAL_MODE setting is set to CAPTIVE_PORTAL_MODE_AVOID,
instead of keeping it until NM sends the message to notify about
it.
Unfortunately because of the relative timing of the events this
patch has observable impact on what callbacks are sent because of
b/245893397 (the DoubleValidated bug). Before this patch, there
would be an extra useless callback when a captive portal validates
where the capabilities contain both VALIDATED and CAPTIVE_PORTAL,
then a second callback removing CAPTIVE_PORTAL. This patch fixes
this, but unfortunately introduces a symmetrical extra useless
callback when a captive portal network starts matching a callback,
where onCapabilitiesChanged is fired a second time after the
onAvailable sequence with the same capabilities. Fixing this is
very complex ; the best (and simplest) solution is really to
address b/245893397 decisively.
In the mean time, the behavior implemented by this patch is better
than the old one, because there no longer is an observable state
where the network is supposed to be a closed captive portal AND
validated, but instead there is a useless, but correct, caps
callback that mirrors exactly the one from b/245893397. When
b/245893397 is addressed this behavior goes away at the same time,
so this is probably the better behavior.
Test: FrameworksNetTests CtsNetTestCases
Change-Id: I6694db498507860e1d711e2aa0c591dfbfa90be2
Chiachang Wang
authored and
Gerrit Code Review
commited 
Aaron Huang
commited 
Paul Hu
commited 
Treehugger Robot
authored and
Junyu Lai
authored and
Frank Li
authored and
Chalard Jean
commited 
Maciej Żenczykowski
authored and
t-m-w
authored and
Lorenzo Colitti
commited 
Motomu Utsumi
authored and
Hungming Chen
authored and