Certain carriers have requested the ability to disable the warning,
limit, and rapid data usage notifications shown by the OS, so give
them that ability on a per-subId basis. (The notifications are still
enabled by default.)
Unhide NOT_CONGESTED to match setSubscriptionOverrideCongested().
Fix bug in getPrimarySubscriptionPlanLocked() to find the first
currently active plan; the first non-recurring plan may be no longer
active. Fix bug in SubscriptionPlan which allowed invalid negative
or zero-length Period objects.
Bug: 77851691, 77506882, 77662747
Test: atest com.android.server.NetworkPolicyManagerServiceTest
Test: atest android.telephony.cts.SubscriptionManagerTest
Exempt-From-Owner-Approval: SDK deadline, responding to API feedback
Change-Id: Ib6e6dbadd5022937c3f0661ab4b66aa617f0b5af
We've traced down all code paths where NetworkInfo.isRoaming() and
NET_CAPABILITY_NOT_ROAMING can disagree, so we're only left with
noise that happens from NetworkAgent race conditions when someone
asks for a NetworkState between pending NetworkInfo and
NetworkCapabilities updates.
We can look at adding a way for a NetworkAgent to update these
two objects atomically, but not for this release.
Bug: 70174865
Test: builds, boots
Change-Id: I830e1fc6dc922e9eb7f8c2698d75181e00aaf7fb
Per API council feedback remove unwanted capaibility from public API
java docs
Bug: 77601789
Test: make docs
Test: build and flash
Change-Id: Ia7fd6d79546bf99448f8f2bda0370c7230ea4527
The addition of hasUnwantedCapability was late in the release
cycle and does not simplify the API enough to be worth it. The
recommendation is, in a future release, to do something more
complete: not just add something like addUnwantedCapability, but
also deprecate all the NET_CAPABILITY_NOT_xxx constants and add
opposite NET_CAPABILITY_xxx constants for use with it.
Fix: 77601789
Test: builds, boots
Test: atest android.net.cts.NetworkRequestTest
Test: atest android.net.cts.ConnectivityManagerTest
Change-Id: Ib98fb01da4a4a0bae464787b589ad88f45002eb8
If you put values into the Builder, you should be able to observe
those values on the built object.
Test: atest android.net.cts.NetworkRequestTest
Bug: 74945408
Bug: 72828388
Change-Id: Ib4026b8d7370d570f1b606f0d221d00fed6e787d
Bug: 68762530
Exempt-From-Owner-Approval: OWNERS have approved, but gerrit doesn't see it
Test: runtest -x frameworks/base/tests/net/ -c android.net.NetworkCapabilitiesTest
Change-Id: Ieadef7c42634d890281543226203530fb18eb0a3
This is the counterpart to Network.getNetworkHandle() and facilitates
native code calling back to Java with network handle values from
getNetworkHandle.
Bug: 77210159
Bug: 64148938
Test: make CtsNetTestCases
Change-Id: I032b959d84180c063a79ddd97c35e7384b0f50a1
Allow apps to specify a list of capabilities that network must not have
in order to satisfy the request.
Bug: 72828388
Test: m -j
Change-Id: I91ee54963f7b92899c7a107b3a450b268c62fd8d
If you put values into the Builder, you should be able to observe
those values on the built object.
Test: atest android.net.cts.NetworkRequestTest
Bug: 74945408
Change-Id: I9aacceb82c98f7881f0eb5e1106d89d469b816a7
Some system apps should be able to request OEM_PAID networks. This
makes a lot of sense when Android is used as in-vehicle infotainment
systems.
Bug: 68762530
Test: runtest -x frameworks/base/tests/net/ -c android.net.NetworkCapabilitiesTest
Change-Id: Ic916de7522a9f803a2410bc4e3e82101fd9d0dbd
