Instead of sharing the constant from LinkProperties, use the already
defined constant in the NetworkConstants class.
This allows Ikev2VpnProfile to allow depending on non-public
LinkProperties APIs, as LinkProperties is planned to move to
framework-connectivity.
Bug: 174436414
Test: m
Change-Id: I594bb7e81bc7681799c16eff621a5ffd1b29624c
On top of being a cleanup this is useful for the S Network
Selection project that will need to enrich the Network
Agent API, and as such should not have to support legacy
agents.
Test: FrameworksNetTests NetworkStackTests
Bug: 167544279
Change-Id: Id3e5f6e19829c64074cd6a52c5f950cee56b860b
ConnectivityService may not be available in a NetworkProvider
constructor, if it is created (but still unused) before
ConnectivityService starts.
As ConnectivityManager is only necessary in
declareNetworkRequestUnfulfillable, which should not be called often,
just query ConnectivityManager at that point.
This is necessary for VcnManagementService, which is started before
ConnectivityService and creates its NetworkProvider in its constructor.
Fortunately VcnManagementService does not call
declareNetworkRequestUnfulfillable at this point.
ConnectivityManager may be migrated to classic service getters that
cache "null" when the service was not available the first time it is
queried, so no system service must query it before it starts.
Bug: 171540887
Test: atest FrameworksNetTests:NetworkProviderTest
Change-Id: I8dadcd0e1360a9464192f330493e13aa69dd9fe2
This CL allows an app that has the MANAGE_TEST_NETWORKS
permission to create test VPN networks.
The code enforces that such networks can never apply to any UIDs
and thus will never carry any traffic.
Bug: 173331190
Test: passes existing tests, moved tests pass
Change-Id: I5befea0e3b4b6dce4ca0c6a04471a055186b644c
Add support to ConnectivityService to track underlying networks
directly instead of through the Vpn class.
1. Communicate all information necessary to propagate underlying
network capabilities to ConnectivityService via NetworkAgent.
This includes:
a. Underlying networks:
- Add SystemApi for NetworkAgent to declare its underlying
networks to ConnectivityService, and use it in Vpn.
- Add a new declaredUnderlyingNetworks member to
NetworkAgentInfo and store the underlying networks in it.
Move propagation of underlying network capabilities to
mixInCapabilities, which is a natural place for it.
b. "Always metered" bit:
- Communicate this to ConnectivityService via the existing
NOT_METERED capability. Store it in a new declaredMetered
boolean in NetworkAgentInfo to separate it cleanly from
the NOT_METERED bit in the capabilities, which depends on
whether the underlying networks are metered or not. In
order to ensure that this is only ever changed when a NC
update is received from a NetworkAgent, define a new
processCapabilitiesFromAgent similar to the existing
processLinkPropertiesFromAgent.
2. Ensure that propagating underlying network capabilities does
not read the VPN's NetworkCapabilities. In order to do this,
ensure that all relevant information on underlying networks
and metering is sent to ConnectivityService at NetworkAgent
registration time. CS still calls Vpn#updateCapabilities when
a user is added/removed, but that is deleted in a future CL.
3. Slightly generalize propagating underlying network
capabilities because there may be other network types that
also have underlying networks that aren't VPNs (e.g., VCN).
- Introduce a new supportsUnderlyingNetworks() boolean method
in NetworkAgentInfo.
- Rename updateAllVpnsCapabilities to
propagateUnderlyingNetworkCapabilities.
This commit does not move the actual logic of calculating the
underlying capabilities out of Vpn.java. That can be done in a
subsequent change once CS stops calling getUnderlyingNetworks().
This commit also does not modify any of the other code in CS that
directly accesses VPNs' underlying networks.
Bug: 173331190
Test: passes existing tests in ConnectivityServiceTest
Test: CTS test in r.android.com/1511114
Test: atest CtsNetTestCases:Ikev2VpnTest HostsideVpnTests
Change-Id: I5f76cb1aa4866efed3d5c4590e931fdb0e994f8d
MIN_MTU_V6 is increasingly used, and the LinkProperties version is used
as a source of truth for the constant.
Bug: 163602123
Test: atest FrameworksNetTests
Change-Id: I67134cd4fb7e2cf59c36947b62f681ac9b94ea4a
1. The current code only prints the array of administrator UIDs
if it's empty. This is clearly an oversight. Print it only if
it's non-empty.
2. Only print requestor UID and package name if they are set.
This makes output shorter in the common case that they are
unset.
3. Reorder the output at the end: group all UIDs together, and
place SSID and private DNS broken bit after that.
4. Make the private DNS broken indication a single word instead
of a sentence. This saves space and makes it easier to write
regexps.
New format:
... SignalStrength: -72 OwnerUid: 1000 AdminUids: [1000] SSID: ...
... Uid: 1000 RequestorUid: 1000 RequestorPkg: android ...
Test: manual
Change-Id: I2f5ccc1d9e4af6ddacc4d193185a17723822972b
Updating comments for network preferences to better clarify that
preferences which include more than one network type will then rely on
scoring to determine which of those networks are chosen.
Bug: 171795464
Test: atest FrameworksNetTests
Change-Id: I9eb5683f2cd69281bbee9fb70028d45f07720914
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
Bug: 170729553
Test: Treehugger
Merged-In: I626caf7c1fe46c5ab1f39c2895b42a34319f771a
Change-Id: I54e5ecd11e76ca1de3c5893e3a98b0108e735413
Modern network agents are supposed to have the following
lifecycle :
• Construct the agent
• Declare itself to connectivity by calling #register()
• Possibly do some setup
• Declare connected by calling #markConnected()
• Declare disconnected by calling #unregister()
Internally ConnectivityService still manages the state
with deprecated NetworkInfo, which has a lot of possible
detailed states, most of which are now unused. Internally,
the steps above translate to the states below :
• When the agent calls #register() it starts in state
CONNECTING
• When it calls #markConnected() it goes to CONNECTED
• When it calls #unregister() it goes to DISCONNECTED which
triggers the flow that disconnects it immediately
• ConnectivityService also synthesizes the SUSPENDED state
under some situations, but that's not relevant here.
The translation above is done by the NetworkAgent class,
which translates #register(), #markConnected() and
The only valid lifecyle for new agents is thus :
CONNECTING → CONNECTED → disconnect
↕ ↑
SUSPENDED ───┘
Note that in the above scheme, there is no space for the
UNKNOWN state, which is only used by legacy network agents.
However, the constructor for NetworkInfo still starts with
UNKNOWN. Ideally the constructor for NetworkInfo would set
the info to CONNECTING instead, but this would be a very
visible change in behavior affecting many apps (especially
their tests), so for backward compatibility we can't do
that.
New network agents however don't expose their NetworkInfo
to the client code, so they can just be made to start in
CONNECTING the way it was meant.
Note that this didn't really have a concrete impact beyond
printing some logs as by and large the ConnectivityService
code handles UNKNOWN and CONNECTING the same way, or more
exactly it handles transitions to CONNECTED from UNKNOWN
and CONNECTING in the same way. The exception to this is
VPNs, which are not using the new agent API yet, and the
upcoming conversion is why this fix is actually needed now.
Bug: 170904131
Test: FrameworksNetTests NetworkStackTests
Test: new test in aosp/1460705
Change-Id: Ib7d906a7b29a0b9f000b90bc78558a7402852fa3
Adding network capability to be used with networks to be only used by
OEM apps.
Bug: 171505922
Test: atest CtsNetTestCasesLatestSdk:NetworkCapabilitiesTest
Change-Id: Ib55ebec0e178b6317d92f17e1aff060dacdfb2b1
Create a new target service-connectivity to split
ConnectivityService from services.core.
Add ConnectivityServiceInitializer for initializing
ConnectivityService and add systemReady() in
ConnectivityManager so that SystemServer can call systemReady()
through ConnectivityManager which won't change current behavior.
Bug: 158268939
Test: make target-java, make host-java
atest FrameworksNetIntegrationTests
atest FrameworksNetTests
make, device can boot,
atest CtsStrictJavaPackagesTestCases
wifi and mobile data work.
Change-Id: I99401772ba9c1c34adca20040da3c7c72d86ddd9
Merged-In: Ie732bfaf381404af0bb599ca2f421a96e7aa4257
LinkProperties.compare{Dnses,ValidatedPrivateDnses,AllRoutes,
AllInterfaceNames} actually have no users.
Test: LinkPropertiesTest
Change-Id: Ic54ab3c5520fbbc2be1309aeaf1e5a7857dbd194
The utility classes are useful for mainline modules and their tests, for
example IpClientIntegrationTest.
Bug: 168868607
Test: m && atest NetworkStaticLibTests
Change-Id: If2b1613aa18a7990391e2d31cc2951ca93f1cf3c
Currently, the callbacks of stopping were fired when stop procedure
is started, because the upper layer apps only care about the reason
of stopping instead of stopping result. Thus, there is no need to
wait for the result comes back. However, this behavior generates
races if apps want to re-start keepalive immediately since the
resources are not released yet.
Fix: 134891441
Fix: 140305589
Test: atest com.android.server.ConnectivityServiceTest#testPacketKeepalives \
--rerun-until-failure 1000
Change-Id: I987776a9211a50e964c4675b747bc10e203750f1
This patch is still needed and should go in now that the
error is fixed.
The patch was submitted into rvc-dev and is already in
rvc-dev-plus-aosp (patch in in ag/11923559, revert
skipped in ag/12072199). A follow-up will remove the
unused services.net-module-wifi target.
Test: originally tested in aosp/1324109
Test: m; manual: flashed, wifi and telephony working
Test: atest NetworkStackCoverageTests
Change-Id: I1074eedb0b0f156a1135e11210ec102de15ea674
Merged-In: Icd141a992c46290c74929785e261a1cd57bc001b
For non-telephony networks, this was always set to 0 before R.
In R, it is currently set to the same value as the network type.
This is incorrect because the two have different namespaces.
or example, currently, any network of type WIFI (==1) will have
a subtype of NETWORK_TYPE_GPRS (==1). Similarly, all ETHERNET
networks will have subtype NETWORK_TYPE_1XRTT, all VPN networks
will have a subtype of NETWORK_TYPE_TD_SCDMA, etd.
Bug: 161653721
Test: builds, boots
Change-Id: I07e111c1762e0021c931cefc27f193f78578748b
(cherry picked from commit a40ff70cad00a6c298e07c2c38e95d58074a7157)
For non-telephony networks, this was always set to 0 before R.
In R, it is currently set to the same value as the network type.
This is incorrect because the two have different namespaces.
or example, currently, any network of type WIFI (==1) will have
a subtype of NETWORK_TYPE_GPRS (==1). Similarly, all ETHERNET
networks will have subtype NETWORK_TYPE_1XRTT, all VPN networks
will have a subtype of NETWORK_TYPE_TD_SCDMA, etd.
Bug: 161653721
Test: builds, boots
Change-Id: I07e111c1762e0021c931cefc27f193f78578748b
Avoid recording negative data by doing integer-based
math as much as possible, but switch to double-based
math if we detect that we'd end up causing an overflow.
Test :
- Builds, Boots
- High data throughput scenarios
- NetworkStatsHistoryTest, NetworkStatsCollectionTest,
NetworkStatsTest
Bug: 119527458
Change-Id: I55d4aa649bea3ae201ad513074ff2b71cb918dad
Update all callers to use ProxyInfo(Uri) and remove ProxyInfo(String).
Bug: 160557668
Test: build pass
atest FrameworksNetTests
Change-Id: I4c980764c8839c48acf03208bb68cd53eb910121
