Re-remove CONNECTIVITY_CHANGE_DELAY and supporting functions.
Since optimistic addresses are useable upon kernel notification there is no need for this extra connectivity delay. --- This functionality was originally submitted in ag/572619. Owing to issues with bind()ing to optimistic addresses (see b/18609055) this was reverted in ag/598673. This reverts the revert. :-) Bug: 17769720 Change-Id: Ibee490b2af72050693b6bd748193f51e312ca527
This commit is contained in:
parent
6e39f696b7
commit
b883659514
1 changed files with 4 additions and 50 deletions
|
|
@ -100,7 +100,7 @@ public class ConnectivityManager {
|
|||
|
||||
/**
|
||||
* Identical to {@link #CONNECTIVITY_ACTION} broadcast, but sent without any
|
||||
* applicable {@link Settings.Global#CONNECTIVITY_CHANGE_DELAY}.
|
||||
* historic {@link Settings.Global#CONNECTIVITY_CHANGE_DELAY}.
|
||||
*
|
||||
* @hide
|
||||
*/
|
||||
|
|
@ -427,18 +427,6 @@ public class ConnectivityManager {
|
|||
@Deprecated
|
||||
public static final int DEFAULT_NETWORK_PREFERENCE = TYPE_WIFI;
|
||||
|
||||
/**
|
||||
* Default value for {@link Settings.Global#CONNECTIVITY_CHANGE_DELAY} in
|
||||
* milliseconds. This was introduced because IPv6 routes seem to take a
|
||||
* moment to settle - trying network activity before the routes are adjusted
|
||||
* can lead to packets using the wrong interface or having the wrong IP address.
|
||||
* This delay is a bit crude, but in the future hopefully we will have kernel
|
||||
* notifications letting us know when it's safe to use the new network.
|
||||
*
|
||||
* @hide
|
||||
*/
|
||||
public static final int CONNECTIVITY_CHANGE_DELAY_DEFAULT = 3000;
|
||||
|
||||
/**
|
||||
* @hide
|
||||
*/
|
||||
|
|
|
|||
Loading…
Reference in a new issue