This patch does some light refactoring in MacAddress to prepare for
exposing MacAddress in the public api:
- documention is improved
- some method names are renamed
- a toSafeString method is added
- a padding bug in the conversion methods outputting strings for
mac addresses is fixed
Bug: 69390696
Test: runtest frameworks-net
Change-Id: I399a97dabc2dfa8df9c5518c8b12484e43ca05c9
Update public docs to hide the fact that NetworkCapabilities is only
used inside NetworkRequest as an implementation detail.
Take up less room on the wire when passing NetworkCapabilities around
via NetworkRequest.
Sanity check that the roaming state between NetworkInfo and
NetworkCapabilities is in agreement.
Test: bit FrameworksNetTests:android.net.,com.android.server.net.,com.android.server.connectivity.,com.android.server.ConnectivityServiceTest
Bug: 67040695
Change-Id: I982b4c3c41a140934bbad3b8ca8f12dc3814e86c
Also includes:
- SettingsLib strings used in PrivateDnsModeDialogPreference
interaction in the Settings app
- rename ContentResolver "resolver" in methods working with
DNS resolvers (too confusing)
Test: as follows
- built
- flashed
- booted
- runtest frameworks-net
- no new failures in SettingsBackupTest nor in SettingsProviderTest
- manual interaction with developer option works
Bug: 34953048
Bug: 64133961
Change-Id: Ia7502916db9ffa0792e1e500a35e34d06a88e79d
The "roaming" state of a network really belongs on NetworkCapabilities
instead of being published through NetworkInfo.isRoaming(). One major
reason is to support developers creating NetworkRequests for a
non-roaming network.
Watch for any capability changes that network statistics are
interested in (either metered or roaming) and notify it to perform
an update pass; fixes bug where we previously only triggered on
roaming changes.
Fix bug in VPNs where metered/roaming capabilities of underlying
networks weren't being propagated; this was probably preventing
some jobs from running over unmetered networks, and causing other
jobs to run over roaming networks! Also passes along link bandwidth
information from underlying networks, and propegates any changes
to underlying networks.
Fix race condition by reading prevNc inside lock. Utility methods
correctly calculate min/max link bandwidth values.
Test: bit FrameworksNetTests:android.net.,com.android.server.net.,com.android.server.connectivity.,com.android.server.ConnectivityServiceTest
Bug: 68397798, 16207332
Change-Id: I3e1a6544c902bf3a79356b72d3616af1fd2b0f49
Another CL in this topic moves the classes from
libcore.net.http
to
com.squareup.okhttp.internalandroidapi.
In jarjar'ed build targets, this becomes
com.android.okhttp.internalandroidapi.
This facade constitutes the API via which non-libcore parts
of the Android platform (currently framework) may access
OkHttp. It's moving because libcore.net.http is already
part of libcore, and the overlap of packages is problematic
for builds with EXPERIMENTAL_USE_OPENJDK9 set to true.
Bug: 68220880
Test: Treehugger
Change-Id: Ia79966563cc0b5ab0923d54c21e54b6192d8c990
Exempt-From-Owner-Approval: Jeff Sharkey is an owner, but only one of his accounts is listed as an owner (@android.com vs. @google.com)
Add IntDef for constants, and rely on new auto-documentation feature
to expand all of them at usage sites.
Test: docs-only change
Bug: 64133169
Change-Id: I8a6b5f54c8eb9d4fc7ae3d0d3fb673d52320664b
This patch changes describeImmutableDifferences in NetworkCapabilities
to ignore differences in NET_CAPABILITY_DUN, so that updateCapabilities
in ConnectivityService to not report wtf errors when a NetworkAgent
degrades its NetworkCapabilities object by removing NET_CAPABILITY_DUN.
Bug: 65257223
Test: runtest frameworks-net
Change-Id: I115ed1b366da01a3f8c3c6e97e0db8ce995fd377
...just return false instead.
Test: Made an app to test this. Made sure it doesn't have
Test: the required permission. Checked it crashes with
Test: SecurityException without this change. Checked that it
Test: doesn't with it.
Merged-In: Ib5b17a7f68c1327f47fe1f54c0454c51f4226907
Change-Id: Id20d3c240ec5d70d085e0366b92ab3a514f3e7c8
(cherry picked from commit ffacaef813)
adds privileged permission for getCaptivePortalServerUrl
adds tether privileged permission for
startTethering,isTetheringSupported
bug:62348162
Test: make and manual testing
Change-Id: I8eb8e3c9dcd7201abe9ea303ee57fe99073d67eb
...just return false instead. This will change in P.
Test: Made an app to test this. Made sure it doesn't have
Test: the required permission. Checked it crashes with
Test: SecurityException without this change. Checked it
Test: doesn't with it.
Bug: 65404184
Change-Id: Id20d3c240ec5d70d085e0366b92ab3a514f3e7c8
Move all corner case logic from call sites to CompareResult's implementation,
add a constructor to directly do the comparison.
Test: runtest frameworks-core -c android.net.LinkPropertiesTest
Change-Id: I95bba82ec38d295b18c49c025dffab5f17271cbd
Rename the opt-out flag in AndroidManifest to
SERVICE_META_DATA_SUPPORTS_ALWAYS_ON
as directed by the API Council.
Bug: 64331776
Bug: 36650087
Test: runtest --path java/com/android/server/connectivity/VpnTest.java
Change-Id: I24326fad7a89083a2409134640bda81ee0359d08
Merged-In: I24326fad7a89083a2409134640bda81ee0359d08
(cherry picked from commit d681363fd1)
Always-on VPN is a feature introduced in N. Since then, all VPN apps
targeting N+ are assumed to support the feature, and the user or the DPC
can turn on / off always-on for any such VPN app. However, a few VPN
apps are not designed to support the always-on feature. Enabling
always-on for these apps will result in undefined behavior and confusing
"Always-on VPN disconnected" notification.
This feature provides a new manifest meta-data field through which a VPN
app can opt out of the always-on feature explicitly. This will stop the
always-on feature from being enabled for the app, both by the user and
by the DPC, and will clear its existing always-on state.
A @hide API is provided to check whether an app supports always-on VPN.
Documentation is updated to reflect the behavior change.
Bug: 36650087
Test: runtest --path java/com/android/server/connectivity/VpnTest.java
Test: cts-tradefed run cts --module CtsDevicePolicyManagerTestCases --test 'com.android.cts.devicepolicy.MixedDeviceOwnerTest#testAlwaysOnVpnUnsupportedPackage'
Test: cts-tradefed run cts --module CtsDevicePolicyManagerTestCases --test 'com.android.cts.devicepolicy.MixedDeviceOwnerTest#testAlwaysOnVpnUnsupportedPackageReplaced'
Test: cts-tradefed run cts --module CtsDevicePolicyManagerTestCases --test 'com.android.cts.devicepolicy.MixedProfileOwnerTest#testAlwaysOnVpnUnsupportedPackage'
Test: cts-tradefed run cts --module CtsDevicePolicyManagerTestCases --test 'com.android.cts.devicepolicy.MixedProfileOwnerTest#testAlwaysOnVpnUnsupportedPackageReplaced'
Test: cts-tradefed run cts --module CtsDevicePolicyManagerTestCases --test 'com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testAlwaysOnVpnUnsupportedPackage'
Test: cts-tradefed run cts --module CtsDevicePolicyManagerTestCases --test 'com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testAlwaysOnVpnUnsupportedPackageReplaced'
Change-Id: I477897a29175e3994d4ecf8ec546e26043c90f13
Merged-In: I477897a29175e3994d4ecf8ec546e26043c90f13
(cherry picked from commit 9369e61e2d)
For some networks such as mobile data connections, its LinkProperties
does not contain routes for the local subnet so no such route is added
to the interface's routing table. This can be problematic especially
if the device is in VPN lockdown mode where there exists high-priority
PROHIBIT routing rule which in turn blocks the network's default gateway
route from being added (next hop address hitting the prohibit rule).
We fix this by patching LinkProperties to always include direct connected routes
when they are received by ConnectivityService. This has the added advantage that
when apps get LinkProperties, they see the directly connected routes as well.
Bug: 63662962
Test: runtest frameworks-core -c android.net.LinkPropertiesTest
Test: runtest frameworks-services -c com.android.server.ConnectivityServiceTest
Test: Start with device with mobile data, set up ics-OpenVPN in always-on
lockdown mode. Turn off mobile data then turn it back on, observe
mobile data connectivity is restored and VPN successfully reconnects.
(cherry picked from commit 1bb5c0818f0c4fb426e13b65a3ba3db7f36c3d88)
Change-Id: Ia14f88bcf49d37286519c26dff6b7180303e2cbe
For some networks such as mobile data connections, its LinkProperties
does not contain routes for the local subnet so no such route is added
to the interface's routing table. This can be problematic especially
if the device is in VPN lockdown mode where there exists high-priority
PROHIBIT routing rule which in turn blocks the network's default gateway
route from being added (next hop address hitting the prohibit rule).
We fix this by patching LinkProperties to always include direct connected routes
when they are received by ConnectivityService. This has the added advantage that
when apps get LinkProperties, they see the directly connected routes as well.
Bug: 63662962
Test: runtest frameworks-core -c android.net.LinkPropertiesTest
Test: runtest frameworks-services -c com.android.server.ConnectivityServiceTest
Test: Start with device with mobile data, set up ics-OpenVPN in always-on
lockdown mode. Turn off mobile data then turn it back on, observe
mobile data connectivity is restored and VPN successfully reconnects.
Change-Id: I35b614eebccfd22c4a5270f40256f9be1e25abfb
Also moving relevant test files into tests/net as part of runtest
framworks-net.
Also removes testHashCode in LinkAddress() because this test relies on
the assumption that hashCode() is stable across releases or jdk
versions, which is absolutely not true.
This creates maintenance work for little benefit since hashCode is
already tested as part of the equality test.
For instance this test is now broken because hashing for InetAddress
changed.
Bug: 62988545
Bug: 62918393
Test: runtest frameworks-net, added coverage in tests
Merged-In: I695bc3f0e801bf13bc4fc0706565758f12b775b4
Merged-In: I6d3f3c50eaec44e3a0787e849ab28e89f6f4a72d
Merged-In: Iddfec82a08f845e728adadfa6ec58a60a078d6af
Merged-In: I8d6dd5efd226a8b1c4b05d1e1102362b58e094a1
Merged-In: Ied0cc53ac34c7c5f5539507b1979cbf9c215262e
Merged-In: I3b2b7dcb1a9a194fc08643b27bbb5a0e84e01412
(cherry picked from commit 1dfb6b67555d04973dfb9d1100dfc1c6a5200633)
Change-Id: I9a17094bfdc54b9dec671306618e132a4beb59fc
This patch loosens the validation checks when a NetworkAgent updates it
NetworkCapabilities: instead of checking that capabilities labeled as
"immutable" stay identical across updates, it is now accepted to change
immutable capabilities in a way that the new NetworkCapabilities
satisfies the old NetworkCapabilities.
This allows a NetworkAgent to update itself in order to match more
requests, but will still catch NetworkAgents that sends degradation
updates causing potentially requests to not match anymore.
Bug: 64125969
Test: runtest frameworks-net
Merged-In: I2a1b3f9c0be6415e40edc989d0c1b03b5631f7b1
Merged-In: I0ab76de59e87c46a6961229399ff7200bce49838
Merged-In: Ied592bf6112574399a1e808da337004e1c35f244
Merged-In: I01e287b4df82a53a522566d33b3166f7801badca
Merged-In: I7ee60daa9c4266e9b9179032815dd7267e06377f
Merged-In: I31ef741eb83d64c476e5930d5762514b5d4cb16f
(cherry picked from commit bae105a5ccd11430bab14721d1325e2303a673da)
Change-Id: I9d630d63336f4db69f3eb52faa8483f1b1e35d16
Also moving relevant test files into tests/net as part of runtest
framworks-net.
Also removes testHashCode in LinkAddress() because this test relies on
the assumption that hashCode() is stable across releases or jdk
versions, which is absolutely not true.
This creates maintenance work for little benefit since hashCode is
already tested as part of the equality test.
For instance this test is now broken because hashing for InetAddress
changed.
Bug: 62988545
Bug: 62918393
Test: runtest frameworks-net, added coverage in tests
Change-Id: I695bc3f0e801bf13bc4fc0706565758f12b775b4
This patch loosens the validation checks when a NetworkAgent updates it
NetworkCapabilities: instead of checking that capabilities labeled as
"immutable" stay identical across updates, it is now accepted to change
immutable capabilities in a way that the new NetworkCapabilities
satisfies the old NetworkCapabilities.
This allows a NetworkAgent to update itself in order to match more
requests, but will still catch NetworkAgents that sends degradation
updates causing potentially requests to not match anymore.
Bug: 64125969
Test: runtest frameworks-net
Change-Id: I2a1b3f9c0be6415e40edc989d0c1b03b5631f7b1
