Introduce a stable AIDL parcel class, DhcpServingParamsParcel, and
methods to convert to and from that class to DhcpServingParams.
This will be used to move DhcpServer to the NetworkStack app.
Test: atest FrameworksNetTests
Bug: b/112869080
Change-Id: I276b7affccb938059769c90a53f0f6beb26e6ede
This change does a first pass to introduce RcsThread querying. We can
now insert threads and query them back.
Test: Added unit test
Bug: 109759350
Change-Id: Ib116cd533a19ce4d099864a095f585ac47cdc9f6
The current code only uses InterfaceParams#name, and InterfaceParams is
defined in services/net which DhcpServer cannot depend on once moved to
a separate app.
Test: atest FrameworksNetTests
Bug: b/112869080
Change-Id: I94c7dce33200c111666a9dddde82ac2e66a6794f
This is due to being compatible with other RCS related changes by by other engineers.
Test: Existing tests pass
Bug: 109759350
Change-Id: Id56df22e9c313c5e0700eda3b2c489d2f84ea0cd
Merged-In: Id56df22e9c313c5e0700eda3b2c489d2f84ea0cd
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
Some network re-writing packet from broadcast MACs to unicast,
result in this kind of packets cannot be dropped by APF filter.
Thus, drop ARP reply if source IP is 0.0.0.0.
Note: Linux kernel always ignores such replies in the function arp_process().
Bug: 118044271
Test: runtest frameworks-net -c android.net.apf.ApfTest
Change-Id: Id293bf231913d9b483ce7d8dd909e05fa927ccd7
Read a pcap file and runs it through APF filter, then checks whether all
packets in the file are dropped.
Test: runtest frameworks-net -c android.net.apf.ApfTest
Change-Id: I7fc59864608762cd2bc84131817183846b0bf5b5
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
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
Make ball updates time based instead of based on number of onDraw calls.
Also adding fps count to see how often frames are being updated, make
the color of the ball based on fps. This helps notice when there are
possible janks or change in refresh rate.
Test: gradlew build and run manual test of TouchLatency app
Change-Id: Ic2c2eb0fbd9fb31dddeee3228d6ab971a4f7f5e8
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
