Useful for checking if on a wifi-only device.
Similar to asking for NetworkInfo for a network type and checking for
null, though here the intent is explicit.
bug:5087537
Change-Id: Ia3ddd09b6b735b8b3ceb7a347891e015fd96b218
New broadcast that is dispatched immediately after connectivity
changes have been handled by ConnectivityService, bypassing any
applicable CONNECTIVITY_CHANGE_DELAY.
Also protect CONNECTIVITY_CHANGE broadcasts, since they should only
be sent by system.
Bug: 5198167
Change-Id: I75f1fb44b21da1879f0ab960bcaa481126d70fde
Add policy controls to NetworkStateTracker which are combined with
other user preference and internal flags to decide if data connection
should be established. Better locking around enabled flags.
When data network would be over limit, proactively disable data on
that network. Enable when policy is snoozed or when cycle resets.
Track and dismiss notifications from now-stale policies.
Bug: 4587023, 5178147
Change-Id: Ibfcc9f73cda7c369209af701b46eddd3d1943f2d
When restricting background data, show ongoing notification to give
easy access to re-enable. Deprecate getBackgroundDataSetting() API
to always return true, since NetworkInfo.isConnected() is new source
of truth. Handle upgrade path by reading from existing secure value,
and kick one last broadcast when changing value. Remove background
data code from ConnectivityService.
Remove warning alerts, since they push ifaces into restricted list;
should only happen when iface has limit.
Bug: 5163559, 5129421
Change-Id: I0064d9d643656a4d32aaae51d4a58bce49fe295f
Currently legacy VPN only works on IPv4, and it should always
turn down when the addresses are changed. It assumed that the
interface will be brought down and up, so the event can be
detected via interfaceStatusChanged(). However, the assumption
was incorrect and the event is actually driver-dependent. To
fix this issue, ConnectivityService now tells VPN that the
interface is down when resetting IPv4 addresses.
Change-Id: I76d15e56552d86635c5b274ca980be5da905a6fb
- ConnectivityService interaction and support for running dhcp server
and client
- State machine enhancements for connectivity interaction
Change-Id: Iba3beb8c87554ffd67a7b7e852bbb4dd8666a4f5
Because changes to the route tables take time to propagate
we add a delay when sending out change notifications. This allows
applications, such as GTalk, to create sockets without encountering
a 3 minute timeout.
Bug: 5008488
Change-Id: I0eefb03a5d6358a58ea6ae5b4f697ff302b5511d
Create API to expose quota status derived from underlying network
policy. This is designed to support applications making informed
decisions when performing network requests.
Fix bug with random stats generation, and write policy when changing
restrict background data flag. Deprecate EXTRA_NETWORK_INFO, since
it varies based on UID.
Bug: 4517283, 5088603
Change-Id: Ic6893a8967f69937e466be226ba7bb86ef5a5d2d
This potentially has no impact on mobile due to DNS settings being the same. Seperate this change out of the p2p change
Change-Id: I70fff9b1e13015956793b19732785037adb0af24
Sets the current default interface and sets the dns per interface.
port of changes 23041 and 22098 from opensource.
bug:5060618
Change-Id: I80e7ef88727eeb8ff2b48059f69b270e5a6b5c16
The previous approach no longer works with the new USB drivers, since the usb0
interface is no longer enabled by default.
This introduced a chicken & egg problem - usb0 will not be enabled until the
user tries to start tethering, but Settings will not enable the checkbox unless
usb0 is enabled.
To fix this we add an explicit call to start USB tethering in the connectivity manager.
This will enable RNDIS if necessary and then bring up tethering once usb0 is enabled.
Change-Id: Iae1f733366aa6b0dafa66d4c97207794173ef54b
Signed-off-by: Mike Lockwood <lockwood@android.com>
We'd been doing no-gateway hostroutes for dns servers on secondary nets, but on
some devices (multi-homed stingray) this is a problem. Add gateway-ed hostroutes
instead so the BP can do it's nonstandard "magical" demultiplexing.
bug:5011392
Change-Id: Ia48f69c8ddf2a37cfb8f014f078f96bf601d2ddb
In case infinite restoral timer is used for a network feature,
FeatureUser could be keep added but never released if a user
is keep calling "startUsingNetworkFeature".
This patch will add duplication check when adding a FeatureUser
into the list in case infinite restoral timer is used.
Bug: 5043513
Change-Id: I47e7076e217f201454fae33ce596ecdc63cf7908
On devices with mobile data we were kind of doing this in Telephony.
Devices without could use this.
bug:5030831
Change-Id: I9940561e88e43917bc8e638f5c3b15fced3821ae
Removed redundent log.
Cleaned some logic.
Will try to modify route even if recursive operation had an error.
bug: 5008973
Change-Id: Ie2ca51cc39cfac027a8a2e2eaddcb7d6c378c4da
Changes in ConnectivityService in hc-LTE when merged with changes
happening in Master caused the build to break.
Change-Id: I92a0b782ae58e9789b1e950c94ef966234fa94af