The current utilities map the higher-order bytes of ints to the
lower-order bytes of IPv4 addresses, which makes applying masks and
generating series of addresses confusing.
For example, the current utilities would convert 1.2.3.4 to 0x04030201,
or generate 0x0080ffff for a /17 subnet mask. The utilities in this CL
convert 1.2.3.4 to 0x01020304, and a /17 subnet mask is represented as
0xffff8000.
Includes tests for all the above methods and migration of
NetworkUtilsTest to JUnit4.
Test: added tests pass
Change-Id: I5f5aa2e6e3b054b66b9dc507dab64f41be9139b1
To debug power drain due to modem wakeups,
one of the signals we'd like to track is
requests for bandwidth estimate to see which
apps are making requests and how often. This
patch keeps a simple count per-UID when an
app requests a bandwidth update, and that
count is made available in dumpsys.
Bug: 77498849
Test: runtest frameworks-net
Change-Id: I30d2ce85f9fa6747030cf4039d1080113a32e386
With recent performance degradations on apct, the current timeouts are
too short and some requests trigger onUnavailable() before networks are
validated.
Test: runtest -x ConnectivityServiceTest.java
Bug: b/111778226
Change-Id: I083f529787f108065637a0aff3e5bb88e05e6510
Fix some timeouts that were forgotten in parent CL.
Bug: b/111778226
Test: runtest --no-hidden-api-checks -x ConnectivityServiceTest.java
Change-Id: Ib848eaba8c69c07ac596aa4386a741c9a2a87fc9
Tests appear to have become much slower on apct in recent runs, although
local runs do not seem to be affected. As a first measure, increase our
timeouts to eliminate flakyness.
Bug: b/111778226
Test: runtest --no-hidden-api-checks -x ConnectivityServiceTest.java
Change-Id: I7a3bfb646eb554bcd9d50d026142f2a2cff74beb
The current timeout is short enough that lingered networks are torn down
before assertions can be run, causing flakyness in testMultipleLingering.
This CL sets the timeout to 300 in that particular test.
Verified that 300ms is enough with 500 successful runs on Sailfish.
An alternative would be to mock firing of the lingering timer, but
keeping the WakeupMessage logic realistic has already proven useful in
detecting races.
Bug: b/110673602
Test: runtest --no-hidden-api-checks frameworks-net
Change-Id: I6f9a656190bcff0b071ae2584d0f5fa74158472b
Rather than use the crufty config.xml list of upstream transport types,
use ConnectivityService's notion of the default network for the upstream.
In cases where a DUN network is required and the default network is
currently a mobile network, look for a DUN network (code in Tethering
is currently responsible for requesting one).
Test: as follows
- built, flashed, booted
- runtest frameworks-net
- tethered via mobile, joined captive portal network, maintained
laptop access via mobile until captive passed (then used wifi)
- disabled client mode wifi, disabled mobile data, plugged in
ethernet adapter, observed connectivity via ethernet
Bug: 32163131
Bug: 62648872
Bug: 63282480
Bug: 109786760
Bug: 110118584
Bug: 110260419
Merged-In: I9cddf1fb7aa3b8d56bf048c563556244e74808c2
Merged-In: Icac3e5e20e99093ddb85aae1ca07ed7b5cf309fd
Change-Id: I925b75994e31df8046f3ef9916a2457b4210485e
(cherry picked from commit 359d4c6d61)
Rather than use the crufty config.xml list of upstream transport types,
use ConnectivityService's notion of the default network for the upstream.
In cases where a DUN network is required and the default network is
currently a mobile network, look for a DUN network (code in Tethering
is currently responsible for requesting one).
Test: as follows
- built, flashed, booted
- runtest frameworks-net
- tethered via mobile, joined captive portal network, maintained
laptop access via mobile until captive passed (then used wifi)
- disabled client mode wifi, disabled mobile data, plugged in
ethernet adapter, observed connectivity via ethernet
Bug: 32163131
Bug: 62648872
Bug: 63282480
Bug: 109786760
Bug: 110118584
Bug: 110260419
Change-Id: I925b75994e31df8046f3ef9916a2457b4210485e
Change access level of getNetworkAgentInfoForNetwork in ConnectivityService to get
better testability. And add test case to verify clat state transition and make sure
linkProperties are updated correctly.
Bug: 80261579, 109913107
Test: runtest frameworks-net -c com.android.server.ConnectivityServiceTest \
-m testStackedLinkProperties
Change-Id: I72fce594d74bd349f65557edca03640e1b86317c
Add finals and annotations. Remove comments that have lost their
context (they were in the context of disabling a permission check
that had been added, but constituted an API change that would not
serve any real purpose).
Test: runtest
Change-Id: I1f879b2c105d2127072b88233d72097a0d78fe14
No logic changes. Only changes are adding nullability annotations,
final modifiers, and adding an s in a comment.
Test: runtests
Change-Id: If4986a25bb36819de8ff459c4c0439c56d4e5a50
The goal of this is to simplify ConnectivityService by reducing
the amount of code it contains. This is small enough to be obviously
correct and followup changes will move code into this class.
Test: runtest
Change-Id: Ic5ab19b521e98ae397c9bf657856820304362fbb
