Currently, if a prefix is learned from an RA while prefix
discovery is running, clatd will be correctly started, but
prefix discovery will be stopped.
In order to fix this, make it possible to call
stopPrefixDiscovery without transitioning to IDLE state (which
is obviously necessary in this case), by moving the assignment of
the next state from that method to its callers. For consistency,
do the same for startPrefixDiscovery.
Bug: 150648313
Test: new test coverage
Change-Id: I3803fa3d9806848b331c35ee8bac256934bd1f21
464xlat will never be started on a network that is not connected,
or on a network that has no IPv6 address.
This is a no-op test-only change but it is necessary for an
upcoming change that violates some of the invalid assumptions
currently made by this test and causes it to fail.
Bug: 150648313
Test: test-only change
Change-Id: I41766e9adaa7c24454648b371e6e3cc647693be5
The NAT64 prefix from the RA always takes precedence over the
NAT64 prefix from DNS discovery, because it is detected faster,
and detecting it does not require sending any packets.
Bug: 150648313
Test: new unit test
Change-Id: Ic7452431d2d9aea1ae59b67a9d8383c6cc5b3902
Address comment from aosp/1162443.
Move to FrameworksNetCommonTests so that it can be run in
cts test and presubmit test.
Also change package name from android.net.cts to android.net
Bug: 154299158
Test: atest FrameworksNetTest
atest CtsNetTestCasesLatestSdk:android.net.DhcpInfoTest
Change-Id: I42a965ae5cb748fdd80b4d5c0f8b26f36f74be72
Add network agent to test more situation that could get the
onNetworkRequested callback.
Bug: 153614605
Bug: 153613690
Bug: 153612373
Test: atest CtsNetTestCasesLatestSdk:android.net.NetworkProviderTest
Change-Id: Id494a1697cc1b73e8e56ae585a69faec31c59f52
A test that ensures that NetworkCapabilities.TRANSPORT_* is eaual
to IDnsResolver.TRANSPORT_* for every possible value of each.
Bug: 153267602
Test: atest FrameworksNetTests
Change-Id: I6b23ccc6ce1659fdfd9573dfcd895f2c20fa9417
There are tasks that need to be performed when receiving
LinkProperties directly from a NetworkAgent (either at
registration time or in subsequent updates).
Currently, the only example of such a task is calling
ensureDirectlyConnectedRoutes. This is currently done in
handleUpdateLinkProperties, which is often unnecessary,
because that method iscalled in many other cases than when
receiving properties directly from an agent. Ensuring directly
connected routes only needs to be done when receiving
LinkProperties from the agent, because ConnectivityService does
not directly manipulate routes.
This CL does not do much except remove these superfluous calls
and add the method. A future CL will add more code to the method.
Bug: 150648313
Test: atest ConnectivityServiceTest
Change-Id: Ibeeb5f79e8afd3350c935934713d7882f2e0281f
It will skip whole tests on Q device since NetworkProvider class
is introduced in R.
Result on Q device would be:
[1/1] android.net.NetworkProviderTest#skippedClassForDevSdkMismatch: IGNORED (3ms)
Bug: 153614605
Bug: 153613690
Bug: 153612373
Test: atest CtsNetTestCasesLatestSdk:android.net.NetworkProviderTest
Change-Id: If7bfc7fae503e3497c37754697d0b148ff4cab3b
- Allow an app holds NETWORK_SETTINGS to acess registerNetworkProvier()
and unregisterNetworkProvider().
- To access declareNetworkRequestUnfulfillable(), allow an app holds
MANAGE_TEST_NETWORKS to declare a unfulfillable request that contains
TRANSPORT_TEST transport.
This makes easier to write cts to test.
Bug: 153612373
Bug: 153614605
Test: atest FrameworksNetTests
atest CtsNetTestCases:android.net.NetworkProviderTest
Change-Id: Ic9809e731aa811a51c2f82d189372169d99a5ed9
This cannot (currently) happen with DNS64 detection, but it can
happen with the PREF64 option.
Bug: 150648313
Test: atest ConnectivityServiceTest Nat464XlatTest --rerun-until-failure 100
Change-Id: I789fe9d46d3ac5d074ae697d23013f24a9e0246d
Currently, TestableNetworkStatsProvider is a subclass of
INetworkStatsProvider. This is not very accurate naming after
API council review feedback since now we have
NetworkStatsProvider as a system api interface.
This is the counter-part change of actual renaming CL in
NetworkStack.
Test: atest FrameworksNetTests TetheringTests
Bug: 150643374
Change-Id: Ifa8175dc4e2fe2b907ec13b3bd2eca12974f5ea7
Merged-In: Ifa8175dc4e2fe2b907ec13b3bd2eca12974f5ea7
(cherry-picked from ag/10976522)
- Let any process with NETWORK_SETTINGS register for signal strength
wakeup.
- Allow agents registering test networks to assign them a signal
strength.
Test: NetworkAgentTest
Bug: 139268426
Change-Id: I2b4b89be3e69f4853fd6978d2c8f5c8eb4271f21
Add missing tests to cover all system APIs
Bug: 152280218
Bug: 150640683
Test: atest CtsNetTestCasesLatestSdk:CaptivePortalDataTest on
both Q and R device
Change-Id: I6d3826922f16816d5b18ed3540266442a0ed3e49
Commit has to on top of aosp/1281921 to skip whole test in Q
device since CaptivePortalData class is introduced in R.
Result in Q will be:
[1/1] android.net.CaptivePortalDataTest#skippedClassForDevSdkMismatch: IGNORED
Bug: 152280218
Bug: 150640683
Test: atest CtsNetTestCasesLatestSdk:CaptivePortalDataTest on
both Q and R device
Change-Id: Iddd00e1c85abe767b1a41a1761d3266ba322dba6
For a given network, resolver doesn't know what transport types are.
Therefore, when a new network is created or transport types are changed
in a give network, transport types will be updated and sent by calling
setResolverConfiguration(). In the same time, if link properties or
transport types are null, setResolverConfiguration() won't be called.
The original behaviors of setResolverConfiguration() aren't changed.
Only increasing one new behavior that when a given network has transport
type change, calling setResolverConfiguration() directly and resolver
updates the transport types for that given network.
Bug: 143732914
Test: atest FrameworksNetTests
atest FrameworksNetIntegrationTests
Merged-In: I03fc5c62dfd9a51a78a720860531df282fdecc20
Change-Id: I6527cde0e177ba08c886576131b35fc769c2bb53
