Applying API council comments.
bug: 15142362
(cherry picked from commit Ie0bde68b72656a676d90c0343b9756fe9268d8d6)
Change-Id: Ie0bde68b72656a676d90c0343b9756fe9268d8d6
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
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
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)
Make the connectivity changed broadcasts send correct NetworkInfos.
Also update the results of getNetwork.
bug:15290306
bug:15191336
bug:14993207
Change-Id: Ie99ad25f3ebb90d18348e7013761b139e7481866
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)
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
Currently, if a network goes from CONNECTED to some other "live"
state (e.g., CONNECTING, because it's VERIFYING_POOR_LINK) and
back, ConnectivityService treats it as if a new network had
connected. This causes it to attempt to create the network
(which fails, since a network with that netid already exists), to
trigger verification, and if the verification succeeds, to tear
down the network because the request it's satisfying is already
satisfied by the network itself.
Instead, if creating the network fails, assume it's because the
network had already been created, and bail out.
Also, when validation completes, ignore NetworkRequests that were
being served by the same NetworkAgent as before.
Bug: 15244052
(cherry picked from commit cfff026ec47afc7e31f60f80e3deea7f4e2f9be5)
Change-Id: I52c2220e8f1d98fca765880be3040593e92722ed
Currently, if a network goes from CONNECTED to some other "live"
state (e.g., CONNECTING, because it's VERIFYING_POOR_LINK) and
back, ConnectivityService treats it as if a new network had
connected. This causes it to attempt to create the network
(which fails, since a network with that netid already exists), to
trigger verification, and if the verification succeeds, to tear
down the network because the request it's satisfying is already
satisfied by the network itself.
Instead, if creating the network fails, assume it's because the
network had already been created, and bail out.
Also, when validation completes, ignore NetworkRequests that were
being served by the same NetworkAgent as before.
Bug: 15244052
Change-Id: Ifd73558e5be452d9ef88c64cca429d5f302bf354
ConnectivityService doesn't do this anymore.
bug:15077247
Change-Id: I3208c91b2c0369b594987f39ca29da7478435513
(cherry picked from commit 53013c87496980b534e447e717a32698fbd4bca0)
- Improve monitoring of level changes to not be confused
when it goes up while draining or down while charging.
- Put back in connectivity service code to tell battery
stats about the interfaces.
- Turn back on reporting of mobile radio active state
from the RIL.
- Fix bug in marshalling/unmarshalling that would cause
the UI to show bad data.
Change-Id: I733ef52702894cca81a0813eccdfc1023e546fce
- Improve monitoring of level changes to not be confused
when it goes up while draining or down while charging.
- Put back in connectivity service code to tell battery
stats about the interfaces.
- Turn back on reporting of mobile radio active state
from the RIL.
- Fix bug in marshalling/unmarshalling that would cause
the UI to show bad data.
Change-Id: I733ef52702894cca81a0813eccdfc1023e546fce
Code search says these are the only two files that use it. The
tracker will be resurrected in a slightly different form in
frameworks/opt/net/ethernet.
Bug: 14993642
Bug: 14981801
Change-Id: I2477668ca78dfe46661dda1d97c7f786fd7eba35
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
If a runtime restart happens while clatd was running, we try to
start clatd, which causes a fatal exception because netd returns
a 400 error (clatd already started.
Bug: 13450716
Bug: 15012035
Change-Id: I102a06d6193fb5f4a1ebe5ad52e5647ff72ca0da
These are due to changes to ConnectivityService that were made
after master-multinetwork-dev branched off. They mostly didn't
cause merge conflicts because they were in different parts of
the file from the multinetwork changes, but they cause compile
errors now. These particular changes should be fine - they are
all in dead code anyway, and their functionality had already
been re-implemented in the new code.
Change-Id: I0ac9e39c3c975c8e8dc04ad11b6b85366693865c
At present the network evaluation / captive portal detection
is disabled pending addition of API to bind socket to network.
Change-Id: I5d1f5dc86d4dd9481d52dd45d6da0732054c8315
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
