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)
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
- 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
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
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)
Make NetworkFactory a concrete class and divide responsibilites between it and NetworkAgent.
Factory will track requests and by default give a single connect/disconnect api for ease
of use. Then NetworkAgent is created and destroyed as needed with very simple logic.
Change-Id: I401c14a6e5466f2fc63b04219b97ff85bb9af291
(cherry picked from commit 9a17b9c5a256cb4bb14821c5ee89b03b99c045e8)
This is implemented by calling through to netd_client.
Included are functions to bind-to-network-for-process strictly for DNS to
facilitate startUsingNetworkFeature() reimplementation.
bug: 13885501
Change-Id: Ib22c7d02ea81d251bdfeeb0f64a47ce32eefcb1b
(cherry picked from commit dbf76f898f1f57eb74722358087c926d2f529bda)
Currently, once a NetworkAgent has decided to connect, there's
no way to disconnect without first connecting and having
ConnectivityService tear down the connection. This is suboptimal
because it causes the transport to keep retrying even if it knows
that it will not be able to connect.
Instead, allow the transport to abort a connection request that's
in progress, as long as the agent is not yet registered with
ConnectivityService.
Also add locking to evalScores. evalScores should already have
been taking a lock, because it accesses member variables that are
also accessed by the send*methods.
Bug: 15295359
Change-Id: I913c341bdfc50be9c23b632399f53168e754c1c0
(cherry picked from commit 081e99c3ac341734467b65458f94adc160f50d6c)
ConnectivityService doesn't do this anymore.
bug:15077247
Change-Id: I3208c91b2c0369b594987f39ca29da7478435513
(cherry picked from commit 53013c87496980b534e447e717a32698fbd4bca0)
Some Factories come and go (Telephony) and so they need to be able to unregister.
Also, debugging is tough when the factories are anonymous, so add names for logging.
Lastly, only send single set of NetworkRequests to a newly registered NetworkFactory
and only send the requests.
Change-Id: I717d63363f25c446f8ecf38d933b1a35d744af6e
Also moved the requestId serial number out of this public class into CS.
Had to leave NetworkRequest hidden for now because the docs refer to things still hidden
in ConnectivityManager.
Change-Id: I14d1fe52d992adf5e4dc197b8f5433e40b0adfe6
Fixing javadoc deprecated tags to fix a checkbuild error breaks the current/api.txt.
We're not ready for the api change yet, so back out the comments.
Change-Id: Ia95e394da7329c1b9e3876e589c3c2137ba18048
NetworkFactory and NetworkAgent. First trying with wifi and
getting rid of WifiStateTracker.
Conflicts:
api/current.txt
services/core/java/com/android/server/ConnectivityService.java
Change-Id: I7f0ec13d7d8988b32f3c6dc71f72012f3349fe02
This is a protocol allowing transports to dynamically register with CS for
Handler to Handler communications.
bug:13885501
Change-Id: Ic7275e3724a15efc7e5f80981560c4cb3106007b
