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
* changes:
ethernet: cleanup updateConfiguration tests
ethernet: fix callbacks for running interfaces
ethernet: test callbacks when adding running interface
ethernet: ensure EthernetOutcomeReceiver receives only one result
ethernet: fix enable/disableInterface result
ethernet: remove enable/disable interface unit test
Patrick Rohrauthored and Gerrit Code Reviewcommited 2022-09-21 19:08:02 +00:00
This unit test is not particularly useful and there is already coverage
in EthernetManagerTest.
Test: test only change.
Change-Id: I6f9d19d9603229553f44d562ff0276567cb0e26d
- Fix the wrong MOBIKE value set in
testStartPlatformVpnHandlesNetworkLoss_mobikeEnabled.
- Verify the networkAgent is unregistered when the default
network is lost
Bug: 231749077
Test: atest FrameworksNetTests:VpnTest
Change-Id: Idc6ebd42090eff1135dc5f96af4bc2fb268dd340
lucaslinauthored and chiachangwangcommited 2022-09-21 11:30:49 +00:00
This converts the key, which is an index in an array, of sConfigurationMap from U32 to S32.
Since the array has exactly 2 elements, there's no real difference.
In addition while the kernel does indeed index arrays with U32s,
it doesn't matter, because you'd need to have over 2 billion
elements in the bpf map (at which point you'd need GBs of ram for
the bpf map itself)...
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: If17efc25d910af642e519f9ecb6d0e8695c38d42
Maciej Żenczykowskicommited 2022-09-17 06:16:34 +00:00
This converts the key, which is a uid, of sUidOwnerMap & sUidPermissionMap from U32 to S32.
The kernel is actually not consistent in whether uids & gids
are signed or unsigned, and neither is our Java code, which
also commonly uses just 'int' for uid. In practice values
greater or equal to 2**31 often don't quite work right.
For example icmp sockets are enabled via a sysctl that
takes a minimum and maximum gid - and these are signed int32s.
It's worth pointing out that these functions already accept int's
as arguments, so when converting them to U32 (and thus long) they
technically previously did the wrong thing (though it's unlikely
it ever mattered).
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I7b389a1cf822c56134b20df5ded269963f5bf69f
Maciej Żenczykowskicommited 2022-09-17 06:06:23 +00:00
The kernel is actually not consistent in whether uids & gids
are signed or unsigned, and neither is our Java code, which
also commonly uses just 'int' for uid. In practice values
greater or equal to 2**31 often don't quite work right.
For example icmp sockets are enabled via a sysctl that
takes a minimum and maximum gid - and these are signed int32s.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ia309eb99f71765e30510d6a253c1329c20719f21
Maciej Żenczykowskicommited 2022-09-17 01:54:19 +00:00
These are allocated in order by the kernel, if we go
over 2 billion, we've got other problems... besides
U32 to S32 conversion will work just fine anyway.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I6e1da81c03bd36d8c6e7bd2b33f535d1fabfad0a
Maciej Żenczykowskicommited 2022-09-16 18:34:39 +00:00
This patch removes the 8-second unvalidated prompt timer
and replaces it with a 20-second timer that does the
same thing in addition to signalling the stack that the
concerned network has now undergone evaluation once.
Test: FrameworksNetTests
Change-Id: I806f2bdfbf35243fa7cdb1cd1f0a5d549cfcd9c8
continuation of
https://android-review.googlesource.com/c/platform/packages/modules/Connectivity/+/2184446/
replace U32 ifindex with S32
These are allocated in order by the kernel, if we go
over 2 billion, we've got other problems... besides
U32 to S32 conversion will work just fine anyway.
Bug: 245472520
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I48df3bf86f0590fbd0e21b7cf9f19d1a6bbacd31
Maciej Żenczykowskicommited 2022-09-16 04:46:10 +00:00
The ro.radio.noril system properties is not used anymore. Tests
that require to check if device supports wifi but not telephony
should verify it via PackageManager.hasSystemFeature(). Also
remove the systemProperties mocking since the only need for the
mocking is removed.
Bug: 242647857
Test: atest FrameworksNetTests CtsNetTestCases
Change-Id: Ie34e87394458e64a9363678a863d6d977834958f
* changes:
Move Interface index name map dump to NetworkStatsService
Move stats map A/B dump to NetworkStatsService
Add BpfInterfaceMapUpdater#getIfNameByIndex
Motomu Utsumiauthored and Gerrit Code Reviewcommited 2022-09-14 01:27:49 +00:00
A wifi network that is still evaluating, i.e. that doesn't know
yet if it's behind a captive portal, should not be preferred
to a network that yields to bad wifi because the stack doesn't
know yet if it's bad.
To rank the networks correctly, the ranker will therefore need
to know whether a network is still being evaluated. This patch
adds the time when this happened first to the NAI (as a
timestamp for debuggability) and the corresponding flag in
FullScore.
This doesn't have new tests because it doesn't yet expose
new behavior. Tests will come with the behavior.
Test: FrameworksNetTests
Change-Id: I737f314760356926fc07e6eef52f3c8abba2248b
Map status dump will do access check if map is null.
This could show different message from the current dump output.
Information in map content dump does not change
$ dumpsys connectivity trafficcontroller
....
mIfaceIndexNameMap:
ifaceIndex=5 ifaceName=ip6_vti0
ifaceIndex=19 ifaceName=r_rmnet_data3
ifaceIndex=17 ifaceName=r_rmnet_data1
ifaceIndex=18 ifaceName=r_rmnet_data2
ifaceIndex=23 ifaceName=wifi-aware0
....
$ dumpsys netstats
....
BPF map content:
ifaceIndex=5 ifaceName=ip6_vti0
ifaceIndex=19 ifaceName=r_rmnet_data3
ifaceIndex=17 ifaceName=r_rmnet_data1
ifaceIndex=18 ifaceName=r_rmnet_data2
ifaceIndex=8 ifaceName=rmnet_ipa0
....
Bug: 217624062
Test: dumpsys netstats, atest
com.android.server.net.BpfInterfaceMapUpdaterTest
Change-Id: If182bd97f72713b6347028668cf7bd4676b8aea4
This flag conflates these two things, but it's a lot clearer
if they are separate and evaluated at the end.
Moreover, a new policy will make use only of one of them,
so having them separate is also useful going forward.
Test: FrameworksNetTests
Change-Id: Ia47b3974277cf76153a53d7e8a0e969c90ba78f4
The system feature depends on device, it will not change at runtime
basically. So do the system feature check once on NetworkAgentInfo
constructor.
Test: FrameworksNetTests CtsNetTestCases
Change-Id: I03fb8b87f5fda93286bd68ccbb23210066b0611b
Upcoming CL will update BpfNetMaps to pull NetworkBpfMapInfo atom that
contains the cookieTagMap size field.
Test: m, atest BpfNetMaps
Bug: 217624062
Change-Id: I84bb0aa56e3916fc6fc0ca31ba5962f3b9be4b6f
Switch existing C SkDestroyListener and new Java SkDestroyListener based
on the experiment flag.
Bug: 217624062
Test: atest SkDestroyListenerTest
Change-Id: I7031ba7c155edb43e0e7b77449587058d6ba38fb
This will address flakiness issues arising from the use of
when() in multithread context.
Fix: 243658074
Test: atest com.android.server.net.NetworkStatsServiceTest#testDataMigration_differentFromFallback \
--rerun-until-failure 1000
Change-Id: I047050ef14cb60658098ff7803c6773907a92919
Chalard Jean
commited 
Patrick Rohr
authored and
Gerrit Code Review
commited 
Chiachang Wang
authored and
lucaslin
authored and
Treehugger Robot
authored and
Maciej Żenczykowski
commited 
Motomu Utsumi
authored and
Paul Hu
authored and
Junyu Lai
commited 
Aaron Huang
authored and