(and also on parceling, which is not really essential, but
still feels better)
This will avoid issues with NC objects unparceled by processes
when the sender was malicious.
Test: FrameworksNetTests
Bug: 246542132
Bug: 246542330
Change-Id: I8b40eb0c11e39b98bce23dc4e3df037c04639000
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
This change enables R8 shrinking, and R8 full mode of standalone system
server jar service-connectivity. Keep rules are specified based on the entries in
frameworks/base/services/java/com/android/server/SystemServer.java. Keep rules of classes extending SystemServer is inherited from "standalone-system-server-module-optimize-defaults", https://cs.android.com/android/platform/superproject/+/master:packages/modules/common/proguard/Android.bp, which is a set of common rules for standalone system server jar. Keep rules of proto is inherited from "proguard_basic_keeps", https://cs.android.com/android/platform/superproject/+/master:build/make/core/proguard_basic_keeps.flags, which is the common set of keep rules for all dex target.
The
size of service-connectivity will be reduced by 31% from 2094301B to 1426485B.
Test: Presubmit and MTS. Run MTS locally with command `mts-tradefed run` with `mts-tethering`, `mts-network`, `mts-cellbroadcast` on Pixel 4 with sunfish-userdebug image.
Bug: 233746531
Change-Id: I291c9d880a1ffc7dc87f932f9d27ce3740b9dc36
When NetworkAgent unregisters, it invokes destroyNativeNetwork() which
deletes all routes. This process is not synchronized with IpClient. So
on an IpClient restart, it can happen that destroyNativeNetwork()
executes after the IpClient has restarted, which causes the new routes
to be deleted.
Moving NetworkAgent#unregister() to before stopping IpClient hopefully
improves this situation.
Test: atest EthernetManagerTest
Bug: 240323229
Change-Id: I68f5b35ba48d5892db0e03fa34b1884b4612485a
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
* changes:
Add unit tests for preferring bad wifi
Add the notification for actively prefer bad wifi
Clear notif upon bad wifi off + tests for bad wifi notif
Detect captive portals as they are tested, not upon notifying
Implement the "actively prefer bad wifi" feature
This test has been broken for a while. It tested:
- adding a listener triggers an interface state changed callback and an
ethernet state changed callback.
- setEthernetEnabled calls back the correct listeners and removes / adds
the interface.
Interface state listeners are already well covered in
EthernetManagerTest. I am currently working on adding tests for
setEthernetEnabled (there is partial coverage in setUp and tearDown of
EthernetManagerTest).
Bug: 242671512
Test: atest EthernetTrackerTest
Change-Id: Id1325a9056384444affb5c096cbc19d200ae0c4e
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
* 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
Unfortunately, TestableNetworkCallback.expectCapabilitiesWith cannot be
used as it expects to be passed a HasNetwork object.
Test: atest EthernetManagerTest
Change-Id: I0b88bc8b51711db4464608a5075dec32a1fc8ef7
updateInterfaceState(true) changes the interface state and triggers an
interface state callback. In addition, maybeTrackInterface() always
sends out a callback (which is correct, as for an interface that is
being added, maybeTrackInterface() would send the initial DOWN
callback). setTetheringInterfaceMode() (the other caller of
addInterface) also already sends its own callback.
Test: atest EthernetManagerTest
Change-Id: I60d884db5e788639b035cad1dd0d6c316e5836f7
Sending multiple callbacks to one receiver is an easy trap to fall into.
Asserting that the future has not completed in EthernetOutcomeReceiver
should catch this mistake.
Test: atest EthernetManagerTest
Change-Id: Iaaace0e6604558bfc2fc1ae58c2744185e0b13ca
Calling enableInterface() / disableInterface() for an interface already
in the correct state used to return an error which is incorrect
according to the API specification in EthernetManager. onError() is now
only returned for untracked and server mode interfaces.
This change also fixes the updateInterfaceState() function signature.
Test: atest EthernetManagerTest
Change-Id: Ie7ee84c3756a8a0c489a38548214fd524352c8da
This unit test is not particularly useful and there is already coverage
in EthernetManagerTest.
Test: test only change.
Change-Id: I6f9d19d9603229553f44d562ff0276567cb0e26d
- Delete test case from CTS. This would be moved to unit test
- Use reasonable key value in DataElementTest
Test: -m CtsNearbyFastPairTestCases
Bug: 244133414
Change-Id: Ia476c64ad5ebedd8eb007f7e0cb5b30a1d12dee5
- 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
