Re-finalizing some classes. The api/current.txt was updated separately but the change
that made them final got skipped. Also had same issue for some @hide's that were removed.
Change-Id: I423bb7b3029ee03425a3c446bda51ab8191887c1
Applying API council comments.
bug: 15142362
(cherry picked from commit Ie0bde68b72656a676d90c0343b9756fe9268d8d6)
Change-Id: Ie0bde68b72656a676d90c0343b9756fe9268d8d6
This change uses IpPrefix only in the public API and continues
to use LinkAddress for everything else. It does not change the
callers to use the new APIs, with the exception of changing
all current uses of getDestination to getDestinationLinkAddress
to make room for the new getDestination method that returns an
IpPrefix.
Based on Sreeram's earlier change:
https://googleplex-android-review.git.corp.google.com/#/c/477874/
but a bit simplified and with a bit more documentation.
Bug: 15142362
Bug: 13885501
Change-Id: Ib4cd96b22cbff4ea31bb26a7853989f50da8de4e
(cherry picked from commit 7d3b4b9a3d4de9673119632da0ebd583e50126f7)
http://ag/480881 changed RouteInfo.getDestination() to return an IpPrefix
instead of a LinkAddress. This makes the equals() comparison always fail.
So, when ConnectivityService.updateRoutes() is given identical routes, instead
of realizing that there's no diff, it would consider them different, and thus
add and remove the same route. The add would fail, since the route already
existed in netd, but the remove would succeed, leaving the system with no routes
and thus no connectivity.
Bug: 15564210
Change-Id: I2003b0fcb809cc20837dc489c58af37891ca4556
http://ag/480881 changed RouteInfo.getDestination() to return an IpPrefix
instead of a LinkAddress. This makes the equals() comparison always fail.
So, when ConnectivityService.updateRoutes() is given identical routes, instead
of realizing that there's no diff, it would consider them different, and thus
add and remove the same route. The add would fail, since the route already
existed in netd, but the remove would succeed, leaving the system with no routes
and thus no connectivity.
Bug: 15564210
Change-Id: I2003b0fcb809cc20837dc489c58af37891ca4556
- socketFactory() renamed to getSocketFactory()
- Make sure bindProcess() documentation points developers to getSocketFactory() as the preferred approach
- Move bindProcess() and unbindProcess() to ConnectivityManager.setProcessBoundNetwork() -- passing null clears it.
- Move getProcessBoundNetwork() to ConnectivityManager.getProcessBoundNetwork().
Bug:15142362
Bug:13885501
Change-Id: Ia55c59d52e1ec8bf10dd0d9d037bd04c0998bc71
(cherry picked from commit 5ca1e6675bf4182b6e9ca76a7696bf2e38e96c4f)
1. Rename getNetworkPrefixLength to getPrefixLength. Update all
callers in frameworks/base and add a shim method and a TODO
for the rest.
2. @hide isSameAddressAs. It doesn't add much, and it's just
one-liner that callers can implement if they want.
3. Fix the alignment of the initial paragraph (<ul> should have
been </ul>).
4. Remove the documentation that talks about creating
LinkAddresses, since there's no public API for creating them.
With these changes I think LinkAddress is fine as a public API.
Bug: 15142362
Change-Id: Iaf3b1db577745bb68a9e1dd7f96d666dd3f3ec7c
(cherry picked from commit 9ab53650cfcd91a2a151b44b3fd1381841f76269)
1. Rename getNetworkPrefixLength to getPrefixLength. Update all
callers in frameworks/base and add a shim method and a TODO
for the rest.
2. @hide isSameAddressAs. It doesn't add much, and it's just
one-liner that callers can implement if they want.
3. Fix the alignment of the initial paragraph (<ul> should have
been </ul>).
4. Remove the documentation that talks about creating
LinkAddresses, since there's no public API for creating them.
With these changes I think LinkAddress is fine as a public API.
Bug: 15142362
Change-Id: Iaf3b1db577745bb68a9e1dd7f96d666dd3f3ec7c
This change uses IpPrefix only in the public API and continues
to use LinkAddress for everything else. It does not change the
callers to use the new APIs, with the exception of changing
all current uses of getDestination to getDestinationLinkAddress
to make room for the new getDestination method that returns an
IpPrefix.
Based on Sreeram's earlier change:
https://googleplex-android-review.git.corp.google.com/#/c/477874/
but a bit simplified and with a bit more documentation.
Bug: 15142362
Bug: 13885501
Change-Id: Ib4cd96b22cbff4ea31bb26a7853989f50da8de4e
The change is specific to AT&T as they want no signaling from device during provisioning.
I've tested following cases:
- expired AT&T SIM to make sure provisioning flow works as expected.
- airplane mode on/off with both active and expired AT&T SIM.
- wifi <-> mobile transitions work okay.
- LTE with Verizon SIM (basic sanity).
bug: 13190133
Change-Id: I215963174ae6000ae71d1dda693f95413f3d6e81
- socketFactory() renamed to getSocketFactory()
- Make sure bindProcess() documentation points developers to getSocketFactory() as the preferred approach
- Move bindProcess() and unbindProcess() to ConnectivityManager.setProcessBoundNetwork() -- passing null clears it.
- Move getProcessBoundNetwork() to ConnectivityManager.getProcessBoundNetwork().
Bug:15142362
Bug:13885501
Change-Id: Ia55c59d52e1ec8bf10dd0d9d037bd04c0998bc71
Need to realized that the NOT_RESTRICTED bit is set by
default, so if looking at what bits are set to decide if
we want NOT_RESTRICTED cleared, we need to ignore the
bit itself.
bug:15456019
Change-Id: Iecae598f47ec7306d475e2262bb1c452ddf0fc75
This is a first order approx of what we want - should probably be good enough in most cases.
bug:15277751
Change-Id: I10e3b25f6ad5c7e022ba966ed514d4e6a999180d
(cherry picked from commit 94a5c61cb82401dd777d0a7ac43183d92d955323)
This is a first order approx of what we want - should probably be good enough in most cases.
bug:15277751
Change-Id: I10e3b25f6ad5c7e022ba966ed514d4e6a999180d
When guessing whether a network is restricted or not (e.g., when
constructing a NetworkCapabilities object from an APN type, or
when constructing a request using startUsingNetworkFeature),
only assume the network is restricted if all the capabilities it
provides are typically provided by restricted networks (e.g.,
IMS, FOTA, etc.).
Previous code would conclude a network was restricted even if it
supported one "restricted" capability, so for example an APN
that provides both Internet connectivity and FOTA was marked as
restricted. This caused it to become ineligible to provide the
default Internet connection, because that must be unrestricted.
Also expand the list of restricted APN types a bit.
Bug: 15417453
Change-Id: I8c385f2cc83c695449dc8cf943d918321716fe58
Currently, calling startUsingNetworkFeature for a restricted APN
type (e.g., IMS or FOTA) will create a request that requires
NET_CAPABILITY_NOT_RESTRICTED. Because these APNs are restricted,
when we bring them up we conclude that it does not match the
unrestricted requirement, and we tear them down.
1. Clear the NET_CAPABILITY_NOT_RESTRICTED capability when
creating requests in startUsingNetworkFeature.
2. Refactor the code to a common function so this cannot happen
again.
Bug: 15191336
Change-Id: Id1ec79c58ff79b1a83457ffaecc57d50b61ed4e4
Two fixes. First make sure we mark the request as handled by the network handling it.
Second, convert ensureRouteToHostForAddress to use the new legacyNetworkForType.
bug:14993207
Change-Id: I230968938ca0ed91f834b36a2af60caff2eab682
Make the connectivity changed broadcasts send correct NetworkInfos.
Also update the results of getNetwork.
bug:15290306
bug:15191336
bug:14993207
Change-Id: Ie99ad25f3ebb90d18348e7013761b139e7481866
(cherry picked from commit 16fe1c18289de200d2249e51db8c0986619f487b)
