Currently NetworkInfo is used by Apps to get information of
network. However, to get such information, Apps need to poll
NetworkInfo frequently from ConnectivityService.
In order to increase the stability and reduce the maintain
effort, all functionalities provided by NetworkInfo are targeted
to be replaced or removed entirely.
Apps should use ConnectivityManager.NetworkCallback instead, to
get faster and more detailed updates from connectivity changes.
Or, apps could use getNetworkCapabilities or getLinkProperties
to get information synchronously, but should not mix the
callbacks and synchronous methods together.
Bug: 113629330
Test: atest FrameworksNetTests
Change-Id: Ie8faf620958c3fa0a4a2f233b35b825de0e99ffc
These methods are marked to @UnsupportedAppUsage APIs since
Android Q. But some system apps still need them to set/get
necessary network or request information. Hence, make them to be
public or system APIs.
Bug: 120448492
Test: atest FrameworksNetTests
Change-Id: I95a44daef5615e290b40d0796ca183b88ad8a63f
Adds methods needed by app developers to avoid them having to call
non-SDK APIs.
Test: tests added to cts
Bug: 78686891
Change-Id: Ic0eadfdab2b111d5ca4becb753f4fe3557806433
Start tracking default upstream from boot.This is useful for
entitlement refine in following change. EntitlementManager can
decide if it needs to process entitlement provisioning before
tethering started.
Test: -atest FrameworksNetTests
-build, flash, booted
-manually turnoff/on tethering with different upstream
bug: 111490073
Change-Id: I8fdbd64c52f26b5363693bb5bd8050930e8ea961
Currently, PermissionMonitor listen to user add/remove and
package add/remove intent respectively, and so does VPN.
Thus, races might occurr between them.
This commit refactor VPN part by using ConnectivityService to
listen to intents and dispatch events to VPN.
Bug: 118811303
Test: 1. atest FrameworksNetTests
2. manually add/remove package
3. cts-tradefed run cts -m CtsHostsideNetworkTests
Change-Id: Id76fd77c5fcfb2b0e21f211f63f007b1ea1aa53f
Currently, 464xlat counts its ipv6 tx traffic into root uid.
When user is making ipv4 upload over ipv6-only network, ipv4
tx traffic may sometimes be counted faster then ipv6 tx
traffic.
Thus, NetworkStatsService may detect non-monotonic values due
to 464xlat adjustment.
So the solution is that: for clatd, make ipv6 tx traffic counts
into clat uid, and then ignore it in the framework side.
Bug: 118602783
Test: 1. manually verify clatd traffic on clat uid.
2. runtest frameworks-net
Change-Id: Ifb478b79e3e281918c70e16d1f90682c78f33db1
Add a generic transport-specific information container interface and
access methods. These can be used by a network factory to pass transport
(bearer)-specific network parameters to the app.
Bug: 117605977
Test: atest frameworks/base/tests/net/java/android/net (+new unit tests)
Change-Id: Ib7c83b677e1c02a2212265719813e648b0c9cc1b
In follow-up commits, current API would create new NetworkStats
every time when 464xlatAdjustment wants to filtered out some
uids.
This commit refactors it to delete stats in-place to get better
performance.
Bug: 118602783
Test: atest FrameworksNetTests
Change-Id: I858f95d1fa7733111786243b4e261ce8a70a068d
Netd use this parameter to determine which network it should use for
DNS query when VPN is enabled. But it is no more reliable when we have
seamless vpn handover, since the parameter does not make update to
netd if we have DNS configuration change. Netd should call resolver
API to get latest DNS information rather than this one.
Bug: 116539103
Test: runtest frameworks-net passes
Change-Id: I6491114ab6de0ff66322f1da69056e6f3c999b5a
Some applications or services are needed PCSCF address to register IMS server but there is no way to get it on Android Framework.
We have added PCSCF address to LinkProperties like attached diff files.
Test: get Linkproperties and check Pcscf addresses.
atest FrameworksNetTests
Change-Id: Ic2341a4ce2ed88d560325721766fc21f85f7ff86
Signed-off-by: Hongshik <hshik.kim@samsung.com>
When using xt_qtaguid to count per uid stats,
NetworkStatsService needs to adjust the 464xlat traffic since
iptables module would double count for ipv4 and ipv6 packet.
But for eBPF, the per uid stats is collected in a different
hook, so the adjustment on root uid would only be needed in tx
direction.
Bug: 112226716
Test: 1. Make ipv4 traffic in ipv6-only network and check data
usage.
2. Make ipv4 traffic in a client which connect to
ipv6-only hotspot.
3. runtest frameworks-net
4. cts-tradefed run cts -m CtsNetTestCases -t \
android.net.cts.TrafficStatsTest
5. cts-tradefed run cts -m CtsUsageStatsTestCases
Change-Id: Ic9a84f5446eddc943c255d5f3b89dad171f53cac
Merged-In: Ic9a84f5446eddc943c255d5f3b89dad171f53cac
(cherry picked from commit c33ac0d43b594f6154accf03ae7e3fd34dedc79d)
(cherry picked from commit e43ff3e85f)
updateTcpBufferSizes() only need tcp buffer size as its
parameter. Also unify the logic to check default network
outside the function.
Bug: 120119769
Test: 1. Build pass.
2. runtest frameworks-net
Change-Id: Iee9fec3efe7d5be5b590dd1c1f67ec5de636e613
In previous design, it will always assign newLp to nai in
handleUpdateLinkProperties(). And Private dns configuration
will be missing when the same LinkProperties are updated
because the updated LinkProperties is not assigned back to
NetworkAgentInfo.
Bug: 118518971
Test: 1.Build pass.
2.runtest frameworks-net
Change-Id: I405c8f29497fec438082a2cf30eb5c7b9497e1c4
Stable aidl won't support FileDescriptor but ParcelFileDescriptor.
In order to migrate to stable aidl, replace all FileDescriptor in
INdetd.aidl.
Test: runtest frameworks-net passes
Change-Id: Icdf37aed0e0cce0352070a437066e77c0f2fd85a
The system server is controlling the tcp buffer now by writing to
/sys/kernel/ipv4/tcp_{rmem,wmem}_{min,def,max}. Those files are
basically the same as /proc/sys/net/ipv4/tcp_{rmem,wmem} except those
latter ones contain all three values in one file. Netd can directly write
to those files so we no longer need to depend on these android specific
files.
Test: netd_integration_test
Bug: 118572798
Change-Id: I588b48be29ecf61fd5bbf94f97f63738be4eae25
If dns resolver on a network get consecutively timeout then it
is a strong signal that the network is no longer usable.
Reevaluate the network once it's data stall suspected
Test: 1. runtest frameworks-net
2. SettingsBackupTest passes
2. Run on wifi w/o internet capability
Bug: 112653893, 113916551
Change-Id: I74287b174d933f97a91fa1529b1809856ac3b38d
