Track apps going in and out of idle in the NetworkPolicyManagerService.
Apply DROP rules in firewall controller if app is to be blacklisted
for network access.
Firewall can now be in whitelist (old) or blacklist mode. When in
blacklist, it allows all by default and we can selectively DENY
some uids.
Track app idle in UsageStats and update periodically.
Track charging/discharging states.
TODO: Check for appidle temporary parole state
Bug: 20066058
Change-Id: Ia65d7544204b3bcb78a517310ef4adcc05aac6fb
The compatibility measure introduced in bug 20081183 for apps
that connect to a Wi-Fi network without Internet access and then
expect to be able to use that network requires that such apps
register a NetworkCallback so that their WifiManager can pin them
to whatever wifi Network connects.
Currently, registering the callback requires ACCESS_NETWORK_STATE
and the app may not have that permission. Allow registering wifi
(only) callbacks if the app has ACCESS_WIFI_STATE.
If the app does not have ACCESS_WIFI_STATE (unlikely, since
CHANGE_WIFI_STATE is not very useful without ACCESS_WIFI_STATE),
then don't enable the compatibility measure.
Bug: 20081183
Bug: 20423580
Change-Id: Iad328d30c2d170dead883868fece3d922da68f6f
Lorenzo Colitticommited 2015-04-22 12:01:35 +09:00
Since the demise of the connectivity change delay,
CONNECTIVITY_ACTION_IMMEDIATE has been sent out back to back with
CONNECTIVITY_ACTION.
Interested parties should watch for CONNECTIVITY_ACTION.
Bug: 20013379
Change-Id: I072dddf95adb3bbd17fa1f7159d4ea848ade8f19
This API allows apps other than the system's CaptivePortalLogin
to handle signing in to captive portals.
bug:19416463
Change-Id: I27fce5856b635233e6ff66396d50ccabedd76cf5
Currently, CALLBACK_PRECHECK is never fired, because we attempt
to send it just after a network has connected, before matching
requests to that network. So notifyNetworkCallbacks scans the
list of requests for the network, finds none, and does nothing.
Bug: 20038463
Change-Id: Ib0c6377c45990e358f926217d7c7defa74c1d59b
Lorenzo Colitticommited 2015-04-16 17:11:09 +09:00
When a network is explicitlySelected, keep it connected but do
not automatically switch to it. Instead, attempt to validate it,
and if 8 seconds have passed and the network is not yet
validated, prompt the user asking whether to switch to it anyway.
Bug: 20081183
Change-Id: I03a8459eb39979e3dc8e94662b85a44605dd7e69
Lorenzo Colitticommited 2015-04-15 13:38:22 +09:00
557d2f5 Merge "Add ConnectivityManager.reportNetworkConnectivity() API" into m-wireless-dev
ab5267a Fix onLost/onFound logic in isSettingsAndFilterComboAllowed
7aac1b3 Add ConnectivityManager.reportNetworkConnectivity() API
238e0f9 OBEX Over L2CAP + SDP search API for BT profiles
c256943 Add ConnectivityManager.getActiveNetwork(). Rework NetID allocation in ConnectivityService so registerNetworkAgent() can return the allocated NetID.
bf18bed Merge "Non-functional code cleanup of ConnectivityService." into m-wireless-dev
db8784e Merge "Cleanup of Video Call pause functionality." into m-wireless-dev
71299dd Non-functional code cleanup of ConnectivityService.
e593d0a Onfound onlost feature.
0326f58 Merge "API for config app." into m-wireless-dev
e9b056f API for config app.
d5351e7 RTT framework interface update
a3dfc6b Unhide Network.openConnection(URL, Proxy).
a9208b9 Fix typos in ConnectivityManager documentation.
Change-Id: Ib4c88f6d7ad1b24227b032555c62a5804194384b
This new API allows reporting networks that are perceived to provide Internet
connectivity and networks that are not. This allows the framework to avoid
needlessly reevaluating networks where the apps perception matches the
framework's perception. This was not possible with the prior API,
reportBadNetwork.
Bug: 16214361
Change-Id: Id4409bd7538854bd837231fb50e693c10a62b4f2
Rework NetID allocation in ConnectivityService so registerNetworkAgent() can
return the allocated NetID.
Bug: 19416463
Change-Id: I68e395552cf27422c80b4dfae5db5d56a0d68f5d
1. Remove ConnectivityService.findConnectionTypeForIface() as this can be done
just as easily with supported APIs now.
2. Avoid making copies of Network objects as this precludes reuse of Network
internals (e.g. socket factory, connection pool).
Change-Id: I52f92e35d769d8350471f485e408169608630082
This CL is breaking the clockwork settings app in master. Reverting
until Adam has a chance to investigate.
This reverts commit 22bb76b1b7.
Change-Id: Ieb11423c11cf9874a6175dce49843d0e1080c590
Upon crash of com.android.phone process, NetworkFactoryInfo is
not getting removed from HashMap and will get accumulated on
every start of the process.
Change-Id: Iafde28daddfc82728c03208522682b1efc85a121
* Creates a new Parcelable class VpnInfo to hold required
parameters for VPN stats adjustments.
* ConnectivityService to collect infomation and provide
a list of VpnInfo, one for each user.
* NetworkStatsService passes the VpnInfo array to
NetworkStatsRecorder.
* NetworkStatsRecorder calls NetworkStats.migrateTun()
to do the math.
* Poll NetworkStats when the vpn application calls
setUnderlyingNetworks().
Bug: 19536273
Change-Id: I7a4c7726b8243fead10416f7ec6eb5cf95f20183
1. If reportInetCondition says the network is not working, and
the network is already marked not validated, don't revalidate
it. This was superfluous and should save battery.
2. If reportInetCondition says the network is working, and the
network is not marked as validated, revalidated. This will
allow us to get out of a validated state quickly based on app
input (e.g., allowing GCM's exponential backoff timer to drive
revalidation instead of our 10-minute timer).
Bug: 19258761
Bug: 19209043
Change-Id: Iaa4bac82d117ed1f4088dab106e6f6ce46b34bc3
Lorenzo Colitticommited 2015-02-11 11:03:50 +09:00
If a user is subject to a VPN, getActiveNetworkInfo() will return
the VPN's underlying network (e.g., TYPE_WIFI), so that apps that
call getActiveNetworkInfo to answer questions like "is the device
connected to wifi?" will continue to work. Make getNetworkInfo
do this as well: if the query is for a network type that is
underlying the current user's VPN, then return that network.
Bug: 19196545
Change-Id: Ic5a651735b927c758594a26d26a03fbd704b52e6
Lorenzo Colitticommited 2015-02-11 10:21:01 +09:00
Don't say we're disconnected from a legacy type until there are no outstanding requests for it.
bug:18946574
Change-Id: I8e45c4a7558f7ced0840b71c50081989ba13c1c7
Robert Greenwaltcommited 2015-01-16 16:06:39 -08:00
These networks may be on their way to becoming validated at which point
they could satisfy the default NetworkRequest. This change unifies the
is-this-network-needed code into a single function.
bug:18652378
Change-Id: Ia511d5c66be79b47dd7c9348ec02784ab30b960c
When WiFi's score drops and then comes back up we would previously linger
WiFi but forget to cancel the linger timeout, so 30s later WiFi would
unexpectedly tear down. This was not completely fixed in 935ceef.
bug:18826162
Change-Id: I7bb4b99ec969099e9815f46d4c09253be71a29be
A legacy network type request would generate a bcast before the network
notification was sent - the legacy startUsingNetworkFeature API requires
the notification so it can bind your dns queries to the new network.
Fast-moving clients could try to use the network before it was ready.
bug:18792871
Change-Id: I24c46ef15c249c50bfc321f62756d1f66dc3a6a9
Robert Greenwaltcommited 2014-12-19 11:54:27 -08:00
When we switched the way the status bar determines if a
connection is validated from using INET_CONDITION_ACTION
broadcasts to calling getDefaultNetworkCapabilitiesForUser(),
the statusbar stopped displaying ! when a network stopped having
working Internet connectivity. This is because the validated bit
is never set to false once a network is validated.
Fix this, hopefully temporarily, by introducing a new validated
bit that does go back to being false when a network no longer
has working connectivity, and use that bit in
getDefaultNetworkCapabilitiesForUser().
Bug: 18777225
Change-Id: I991c068be50252391d0e64c647fcf2e053dc82f9
Lorenzo Colitticommited 2014-12-19 19:10:42 +09:00
This is a straight rename and thus a complete no-op from a
functionality perspective.
Bug: 18777225
Change-Id: I140d7640f1460c869a311294873772819a7a7059
Lorenzo Colitticommited 2014-12-19 19:10:42 +09:00
Now that the delay between connectivity changes and CONNECTIVITY_ACTION
has been removed (ag/599650) races between CONNECTIVITY_ACTION and
the setting of the default network become more evident.
In http://crbug.com/441818 Chrome is calling getaddrinfo()
immediately after a device goes from no connectivity to cellular
connectivity, and Chrome is erroneously getting back EAI_NODATA
because netd hasn't yet set the default network for DNS resolutions.
bug:18757162
Change-Id: Ib607dcb3697403272a8c838713a9cb602e9c6820
1. Send PROXY_CHANGE_ACTION broadcast when any network's proxy changes,
not just the default network.
2. When a process is bound to a particular Network, update the proxy
system properties to those for the bound Network, and keep them
updated when PROXY_CHANGE_ACTION broadcasts are received.
3. Make Network.openConnection() use the proxy for the Network.
bug:17905627
bug:17420465
bug:18144582
(cherry-pick of https://android-review.googlesource.com/#/c/115170)
Change-Id: Ia2819985e6108a8c121e74c683a5646becfd0a97
Paul Jensen
commited 
Sanket Padawe
commited 
Amith Yamasani
commited 
Etan Cohen
commited 
Lorenzo Colitti
commited 
fenglu
authored and
Android (Google) Code Review
commited 
Robert Greenwalt
authored and
Erik Kline
commited 
Stuart Scott
commited 
Vinit Deshpande
authored and
Adam Lesinski
commited 
Bart Sears
commited 
Android Git Automerger
commited 
Maunik Shah
commited 
Alan Viverette
commited 
Andreas Gampe
commited 
Wenchao Tong
commited 
John Spurlock
commited