- move BroadcastReceiver info to developer guide. see cl/140402421
- add usage note to CONNECTIVITY_ACTION broadcast
bug:32533262
bug:33106411
Change-Id: Ic2aa517831d29418e0c42aa6fc1e7f9aeb50f802
Dependent on ag/1550196 where API is defined.
Bug: 31015360
Bug: 26545374
Test: runtest --path
frameworks/base/core/tests/coretests/src/android/net/NetworkStatsTest.java,
other test classes.
(cherry picked from commit 7581e6d766)
Change-Id: I46da93ba4afa968facf98f7c3d844fd0c469095a
Properly account for VPN apps that make heavy use of the tun
interface. Prior to this change a VPN app could be incorrectly charged
for more data than it actually used if it sent more traffic through
the tun interface than the underlying interface.
This change excludes VPN app traffic on the tun interface from the
adjustment pool and doesn't redistribute traffic to the VPN app.
Instead all of the redistributed traffic is deducted from the VPN app
which effectively represents any overhead incurred by the VPN app.
BUG: 30557871
(cherry picked from commit 52a7d52cc5)
Change-Id: I06f01aa8fe5fdc06b2d36cfb9c68feb244c2e5de
This patch changes the way that the ConnectivityThread is lazily
instantiated by using the "lazy initialization holder class idiom".
The first code point that tries to obtain a reference to the unique
ConnectivityThread instance will trigger the creation of the Singleton
class, which will guarantee a thread-safe initialization of the static
INSTANCE field inside Singleton according to the language specs.
This is the Item #71 of Effective Java.
The unique static instance of ConnectivityThread is not stored directly
inside ConnectivityThread class but is stored in a static nested class.
This is to avoid triggering the creation of that unique instance when
Zygote does class preloading at phone startup. Otherwise this would lead
to Zygote creating a new OS thread during preloading, which is a fatal
error.
Test: frameworks-wifi tests pass
Bug: 26749700
Bug: 28537383
Bug: 32130437
(cherry picked from commit f8ddba2cbd)
Change-Id: If13b363889a8e9396273a90c3d9f9421a48aecbc
This patch removes the static singleton looper used by
ConnectivityManager and instead uses the common ConnectivityThread.
This allows to removes the static atomic counter used to track
the number of registered NetworkCallback in ConnectivityManager, because
the looper is not turned off anymore when no callbacks are registered.
Also an overloaded version of sendRequestForNetwork is added taking as a
new parameter a Handler. This will allow to overload various callback
and request related API calls with user provided Handlers.
Test: ConnectivityServiceTest passes
Bug: 26749700
Bug: 28537383
Bug: 32130437
(cherry picked from commit 3a54555e85)
Change-Id: If956addbf8e7b11b36a4b966de7fca00e8f362c1
This patch simplifies CallbackHandler in the following way:
- CallbackHandler directly uses the static references to
sNetworkCallback and sCallbackRefCount. This allows to remove
instance fields in CallbackHandler.
- CallbackHandler does not have a reference to ConnectivityManager
anymore
- CallbackHandler.getObject() is now generic in a type-safe way.
Test: ConnectivityServiceTest passes
Bug: 28537383
Bug: 32130437
(cherry picked from commit fe3325f2a5)
Change-Id: I1b5fe2a361b5f623a8310ae698497c83d72f3034
This avoids a NullPointerException when trying to call the callback
and gives a more readable error message.
(cherry picked from commit 49a5795ef0)
Change-Id: Ia419ff68ef10f308f9e44be47420e27099ee6070
~Rename only (and any reformatting needed to pass lint) - no
functional changes!
Remove android.net.wifi.nan.STATE_CHANGED from manifest:
redundant/remnant of an older configuration.
(cherry-pick of commit a61b9fb569153917a650f1d48efa20ba8846a9f3)
Bug: 32263750
Test: All unit tests and integration (sl4a) tests pass.
Merged-In: Ie4ff675fa61041e8fcf6a9bf9900ea835d0a7614
Change-Id: I4206d2fd722dc7dec9df4aee5c818101d7f9dccc
Properly account for VPN apps that make heavy use of the tun
interface. Prior to this change a VPN app could be incorrectly charged
for more data than it actually used if it sent more traffic through
the tun interface than the underlying interface.
This change excludes VPN app traffic on the tun interface from the
adjustment pool and doesn't redistribute traffic to the VPN app.
Instead all of the redistributed traffic is deducted from the VPN app
which effectively represents any overhead incurred by the VPN app.
BUG: 30557871
Change-Id: I62a75a0c0c0111e052b7903baa9f5d6d94ef57fd
When a network goes into the background, tell netd to set the
network's permission to NETWORK. Also, close all TCP sockets on
that network, to prevent long-lived TCP connections from staying
on it and possibly continuing to use metered data.
Bug: 23113288
Change-Id: Ie89c1940b6739160e25c6e9022b8b977afb3e16e
This contains the following changes:
1. Make NETWORK_AVOID_BAD_WIFI a tristate: 0 means never avoid
bad wifi, unset means prompt the user, 1 means always avoid.
2. Look at NETWORK_AVOID_BAD_WIFI only if the carrier restricts
avoiding bad wifi (previously, we relied on the setting being
null and defaulting to the value of the config variable).
3. Add an avoidUnvalidated bit to NetworkAgentInfo to track
whether the user has requested switching away from this
unvalidated network even though avoiding bad wifi is generally
disabled. This is set to true when the user selects "switch"
in the dialog without setting the "Don't ask again" checkbox.
4. Add a hidden setAvoidUnvalidated API to ConnectivityManager to
set the avoidUnvalidated bit.
5. Additional unit test coverage.
Bug: 31075769
Change-Id: I1be60c3016c8095df3c4752330149ce638bd0ce1
Like a normal (foreground) request, a background request is only
satisfied by one network and will keep that network up. Unlike a
foreground request, when a network only has background requests,
it will linger, and after lingering is complete, it will become
a background network.
Future CLs will cause the system to treat background networks
differently, e.g., by requiring different permissions.
Bug: 23113288
Change-Id: I40f735269dad1042eb04fea15e64584fc903ccb3
Add TRANSPORT_WIFI_NAN - specifies a peer-to-peer Wi-Fi NAN data
connectivity request.
While NAN uses Wi-Fi L1 PHY and part of the MAC - it is a different
protocol and constitutes a different transport.
(cherry-pick of commit 5b2641ee62)
Bug: 26564277
Change-Id: I975ebc72d8f97a592d18038b3d6465b7a40efa75
Add an IPv6TetheringCoordinator to TetheringMaster StateMachine, which
receives and processes NetworkState updates and passes the necessary IPv6
information to the revelant TetherInterfaceStateMachine.
Add an IPv6TetheringInterfaceServices to TetherInterfaceStateMachine, which
is responsible for adding local network routes and managing an IPv6
RouterAdvertisementDaemon.
Bug: 9580643
Change-Id: I3eaae460b80752e2115359d7bde873a1e9ea515a
This patch partially undoes ag/869831 (Change-Id:
Ia42ed7aefaebd8caf3eada8e42b6cb7a940d7647) so that ConnectivityManager
does not remove callbacks from its internal request-to-callback map at
unregistration, but instead let the singleton CallbackHandler do it when
receiving a CALLBACK_RELEASED from ConnectivityService.
ag/869831 was thought to fix b/26749700 that reported a callback leak
from sNetworkCallback, but a finer analysis of the code shows that
callbacks were correctly removed by the CallbackHandler before
ag/869831. There was therefore no callback leak.
Bug: 26749700
Bug: 28537383
Change-Id: I421d889d0e225c0e3d1eebea664f44a1cc0f3191
http://ag/1194313 broke unregisterNetworkCallback because the
system does not parcel the type of the request back to the app.
So when the app calls unregisterNetworkCallback, the
NetworkRequest that's passed in does not have a type and thus
doesn't match the request in mNetworkRequests.
Fix this by parceling over the type as well.
This was not caught by the unit test because the unit test all
runs in the same process with no parceling.
Bug: 23113288
Change-Id: I58b2ed651b9bf5cbdcca5b25c3ca24db53cffdf1
This will allow us to simplify code that deals with
NetworkRequests outside ConnectivityService.
Bug: 23113288
Change-Id: I9b3a859d0c68cad73d7f6baa4b584d13ffd2ae36
- Use com.android.okhttp.Dns in place of com.android.okhttp.internal.Network
- Specify TimeUnit.MILLISECONDS for timeouts which 2.7.5 allows and
brings us closer to 3+
Change-Id: I95b5d72a94ebe1389f7c2e8d95903aa1aadd944b
- add a new field: provisioningNotificationEnabled from NetworkMisc. set
to false if we want to hide "sign in" notification and placed
carrier-specific notification instead. it is set on connect, once set,
it is carrier-app's responsibility to post new UI to users
- rework on the interaction between carrier app and framework
- code cleanup
- unit test support
Bug: 28567303
Change-Id: Ic84db7ffbb920d15344717f104496d3cb82e1a85
am: 19e2f49181
* commit '19e2f49181b209d790f551b374d6d24002de7c9b':
API council feedback: hide and document.
Change-Id: I3715fc6e824f2a55517788299afe36145db597d7
