| aab02df1957927797ba745e5a2b42df0722f076b |
|
20-Sep-2016 |
Lorenzo Colitti <lorenzo@google.com> |
Support "don't ask again" in the avoid bad wifi dialog.
am: 165c51c0eb
Change-Id: Ic6a1917a83e2d847bd673790e2c36f7316ca7acd
|
| 165c51c0eb9834a3d95ce0b31b07c7c8975a54d7 |
|
18-Sep-2016 |
Lorenzo Colitti <lorenzo@google.com> |
Support "don't ask again" in the avoid bad wifi dialog.
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
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| c53b5964f8ef8a583dfa0f7bf537804b8d84ea65 |
|
15-Sep-2016 |
Hugo Benichi <hugobenichi@google.com> |
Support ignoring penalty for bad wifi networks
am: c8e9e1229a
Change-Id: I6666ee45e9a08c02444c6268b2232bbe8aa2adec
|
| b8167f6b7efe723e495f6fa84a641cd66364cfc3 |
|
15-Sep-2016 |
Lorenzo Colitti <lorenzo@google.com> |
resolve merge conflicts of f15b282 to nyc-mr1-dev
Change-Id: Ib1294563c6ae20454e44bfa5fc9fb2797864b8f5
|
| c8e9e1229a91e22d6ab32d491d4c60086fbc9199 |
|
15-Sep-2016 |
Hugo Benichi <hugobenichi@google.com> |
Support ignoring penalty for bad wifi networks
This patch adds a way to configure devices so that a validated network
that becomes unvalidated is not penalized in the network scoring and
selection logic.
The intent is to prevent devices configured to do so from switching to a
lower scoring network such as cellular networks when a higher scoring
network such as wifi networks loses internet connectivity.
Bug: 31075769
Change-Id: Ie7e0f2607d214a178367fedfbef6c44768fa00a4
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| f15b2824b6f954e3a8b039a0836530f571d663d0 |
|
15-Sep-2016 |
Hugo Benichi <hugobenichi@google.com> |
Explicitly pass old score to updateCapabilities
This allows simplification of getCurrentScore function in
NetworkAgentInfo and its return value to depend on everValidated and
lastValidated.
Bug: 31075769
Change-Id: I0b3c85e3a61b006733e900e0a231424878317476
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| f0e9a33435c02001836a359a37aae56a7eeee2ad |
|
18-Jul-2016 |
Lorenzo Colitti <lorenzo@google.com> |
Add a NET_CAPABILITY_FOREGROUND capability.
Bug: 23113288
Change-Id: I90cb9ffb5751f0d9ec822933f37680c401e49966
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| 3d4a10617c6d967aa0f07e129264e07320e99073 |
|
09-Sep-2016 |
Lorenzo Colitti <lorenzo@google.com> |
Add a background NetworkRequest type for mobile data always on.
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
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| 5526f9c78c6fcad500c272ef14b7403e3395525e |
|
22-Aug-2016 |
Lorenzo Colitti <lorenzo@google.com> |
Support notifying network switches via notifications and toasts.
Bug: 31025214
Change-Id: If1578f422f38a1dcfaec529882aed01ae5e8d53c
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| b57578ca4f0fa64406ffad09ad9250391e3bbfa5 |
|
30-Jun-2016 |
Lorenzo Colitti <lorenzo@google.com> |
Rewrite lingering.
The two major changes here are:
- Move lingering out of NetworkMonitor. The fact that lingering
is currently its own state in NetworkMonitor complicates the
logic there: while a network is lingering it cannot be in any
other state, we have to take care not to leave LingeringState
for the wrong reason, etc.
- Instead of keeping a single per-network boolean to indicate
whether a network is lingered or not, keep a linger timer for
every request. This allows us to fix various corner-case bugs
in lingering.
The changes in behaviour compared to the current code can be seen
in the unit test changes. Specifically:
1. Bug fix: when a network is lingered, and a request is added
and removed to it, the existing code tears the network down
immediately. The new code just sends another CALLBACK_LOSING
and resumes lingering with the original timeout.
2. Bug fix: if cell is unvalidated and wifi comes up and
validates before cell does (as might happen on boot), the
existing code immediately tears down cell. The new code
lingers cell, which is correct because unvalidated cell was
the default network, so an app might have been using it.
3. Correctness improvement: always send CALLBACK_AVAILABLE for
the new network before sending CALLBACK_LOSING. This was not
really an issue in practice, because the usual flow is:
- Network A is the default.
- Network B connects, CALLBACK_AVAILABLE.
- Network B validates, CALLBACK_LOSING.
Bug: 23113288
Change-Id: I2f1e779ff6eb869e62921a95aa9d356f380cf30a
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| 767708db54edbdb26e166157fa05966769a629cc |
|
30-Jun-2016 |
Lorenzo Colitti <lorenzo@google.com> |
Make the NetworkRequest list private to NetworkAgentInfo.
This allows us to keep track of how many live requests a network
is satisfying without having to count them every time.
Bug: 23113288
Change-Id: Ic4756676491e09071dbf80b7c48da3be028d68eb
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| 585e24889455d1d70d14a9c89a8acef922994898 |
|
02-May-2016 |
Robin Lee <rgl@google.com> |
Split network agent created state from connected state
Network creation setup sometimes involves extra steps after actually
calling into netd to create the underlying network, rules & routes &
to begin allowing sockets bound to it.
For example, VPN networks can set a UID whitelist or blacklist. This
should happen:
- AFTER there is a netID & network created in netd as
network-specific rules will need to be tied to / point at it. Those
rules are tied to the lifecycle of netd's network which is tracked
by `NetworkAgentInfo.created` on the frameworks side.
- BEFORE the CONNECTED broadcast and network callbacks have been sent
out so that we don't create a race condition between clients that
want to use the network and the server actually having the network
ready
The race condition existed prior to this change and required any client
making use of network callbacks to sleep for a short amount of time after
receiving to actually be able to use the network.
Among other things, that race condition is now fixed.
Bug: 26694104
Change-Id: Ied92f5588a98c3e97f456bc98b676bf201ab5472
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| f07c7b9fd0a640bff4bf7690373613da217fe69b |
|
22-Apr-2016 |
Jeff Sharkey <jsharkey@android.com> |
API changes for DownloadManager and JobScheduler.
To support moving DownloadManager, add new JobScheduler network type
constraint that matches "any network except roaming." Also add an
API to get a specific JobInfo by ID.
Since the default network can be different on a per-app basis, and
individual apps may be blocked due to app standby, evaluate job
connectivity constraints on a per-UID basis. To implement this
cleanly, add NetworkInfo.isMetered() to match the isRoaming() API.
Add new DownloadManager APIs to support charging and device idle
constraints, which are plumbed through to JobScheduler under the
hood when scheduled.
Add filtering to JobScheduler dumpsys to omit noisy details for
packages the caller isn't interested in.
Bug: 28098882, 26571724, 19821935
Change-Id: I09ca7184ef7ce6adba399f579d415a5fb2ea6110
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| f21b4dc1d6e9cc3fc164828e9eba33445c0801d0 |
|
18-Mar-2016 |
Paul Jensen <pauljensen@google.com> |
Move ApfFilter from ConnectivityService to IpManager
There's a few advantages to having ApfFilter in IpManager:
1. If things go wrong, crashing a particular transport is less bad then
crashing ConnectivityService. We also don't want to use
ConnectivityService as a dumping ground for transport-specific logic.
2. This makes implementing WifiManager.MulticastLock a lot simpler and
safer because enabling/disabling it doesn't have to go through the
NetworkAgent, which could risk various races (e.g. installing a filter
into the wrong WiFi network).
3. IpManager is the ultimate source for LinkProperties for a particular
transport and since ApfFilter uses the LinkProperties it's better to
have it closely paired with the IpManager. Likewise, ApfFilter needs
to know the APF capabilities of the transport, so having it in
the transport avoids having to parcel this information through the
NetworkAgent.
Bug: 26238573
Change-Id: I99b85f2b64972f0e7572170ec5d1926081aa3429
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| 978c80b474e4b390e62da3e13b5e7e11667005bb |
|
03-Mar-2016 |
Paul Jensen <pauljensen@google.com> |
Have ConnectivityService install packet filters when possible
am: 578a76e7de
* commit '578a76e7de77492ac33e407fff4fb9a2f5550d8a':
Have ConnectivityService install packet filters when possible
|
| 578a76e7de77492ac33e407fff4fb9a2f5550d8a |
|
14-Jan-2016 |
Paul Jensen <pauljensen@google.com> |
Have ConnectivityService install packet filters when possible
Listen for ICMP6 router advertisements on networks that support
packet filters. Construct packet filters and install them to
ignore redundant future ICMP6 router advertisements.
Bug: 26238573
Change-Id: If78300b9fda257c21f3ee6533e1da7de9f897cb4
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| 230d5ca49821bd7a10bb1b3e61d10f534f687772 |
|
25-Jan-2016 |
Erik Kline <ek@google.com> |
Add the network handle to the NetworkAgentInfo#toString() output.
This will make it possible to find nethandles via, e.g.
"dumpsys connectivity --short".
Without this, native multinetwork API debugging requires running
"dumpsys connectivity --diag" in order to see the nethandle values.
Bug: 19537384
Change-Id: Icdd2b112523d4ecf88d5339f229e714a56d248f8
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| 682fd6aedea87e345f033b489ef9f6008bd19c30 |
|
30-Jul-2015 |
Paul Jensen <pauljensen@google.com> |
am a991c66c: Merge "Fix missing onLost NetworkCallbacks when network loses capability" into mnc-dev
* commit 'a991c66c12da30d0240ac6c98736edee93d95977':
Fix missing onLost NetworkCallbacks when network loses capability
|
| cf4c2c637268b1a2979e20a8b5644916777a02a4 |
|
01-Jul-2015 |
Paul Jensen <pauljensen@google.com> |
Fix missing onLost NetworkCallbacks when network loses capability
If a network no longer satisfies a NetworkRequest, send the onLost
NetworkCallback. If it was a real request (not listen) then update
the NetworkFactories.
To test this change I created a little infrastructure to fake
different Internet connectivity probe results during tests. This
allowed me to rewrite some of ConnectivityServiceTest's logic for
validating networks. This brought to light a couple issues that
I had to address to keep tests passing:
1. testUnlingeringDoesNotValidate was relying on a bad side-effect
of my old method of ConnectivityServiceTest's logic for
validating networks, so I rewrote the test.
2. ConnectivityService was not sending out NetworkCallbacks for
WiFi when Cellular was validated. I'm including a fix for this
in this CL also.
Bug:22220234
Change-Id: I29314f38189817f8b2561a213c4f9e8522696663
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| c3f21f3b8b01508f5dc01b2e5fa4c3d652bb67bb |
|
06-Jul-2015 |
Lorenzo Colitti <lorenzo@google.com> |
Support NetworkCallbacks based on signal strength.
Bug: 21405941
Change-Id: I2ed8a5aeb8dac464a4305671ed22abcacb485bc9
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| e098854c41a72b22f4174bc623e8e93cde8d7331 |
|
25-Jun-2015 |
Paul Jensen <pauljensen@google.com> |
Fallback to Cellular if WiFi fails to validate
Previously, once a network validated, for the purposes of comparing networks
to select the default network, we always considered it validated.
With this change if a network later fails to validate, we'll take this latest
validation result into account. This means if WiFi and cellular are up
(e.g. if we recently switched from cellular->WiFi, and cellular is now
lingering) and both are validated, but for some reason WiFi fails a validation,
cellular will become the default network connection.
Bug:20896761
Change-Id: I858aa10c1aaec5cd9032067f960963409107bdb1
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| 85cf78edc92b85ec90e91de42b14b84e202260f3 |
|
25-Jun-2015 |
Paul Jensen <pauljensen@google.com> |
Prepare some ConnectivityService logic for fallback to Cellular change
Reduce the duplication of some logic so when falling back to Cellular
when WiFi fails to validate is enabled, there's less chance for bugs
and failures:
1. De-duplicate several Network vs NetworkRequest matching functions
2. Remove the very tricky nascent logic by adding a simple "lingering" bit.
Bug:20896761
Change-Id: I21da9e827eec9cfd6835fcaa650192b9186ed053
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| 1c7ba0285b3fe8de479d6c09b2ff45572913c2cb |
|
16-Jun-2015 |
Paul Jensen <pauljensen@google.com> |
Fix missing NetworkCallbacks for NET_CAPABILITY_VALIDATED changes
Without this fix if a listening NetworkRequest with NET_CAPABILITY_VALIDATED
is submitted after a network has been validated but failed the most recent
validation attempt, the NetworkRequest will never receive callbacks.
Bug: 21343774
Change-Id: I6fa6d563c9a6f278b20e645776b707559033b249
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| 3d194eae6f658ed865b2d3b748f8b83834c877ab |
|
16-Jun-2015 |
Paul Jensen <pauljensen@google.com> |
Add NetworkCapabilities.NET_CAPABILITY_CAPTIVE_PORTAL
Bug: 21343774
Bug: 20898908
Change-Id: I23069a6cba346999d1b2eeaa445023bd6bf4ef94
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| 3d911469a190437fe936103e861bfa171841fbd6 |
|
12-Jun-2015 |
Paul Jensen <pauljensen@google.com> |
Don't send spurious onAvailable NetworkCallbacks when rematching
Bug:21762680
Change-Id: Ia701045dffc666fe75fba0e1771872147e37179a
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| d49159f4e997faae6ef4141b667ad6fef74a6724 |
|
14-May-2015 |
Lorenzo Colitti <lorenzo@google.com> |
Don't display the "no Internet access" prompt on captive portals.
Bug: 20081183
Bug: 21066461
Change-Id: Idc71844a604f9ca655411c6916de256780ea4586
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| cb43ebb3604d45da8677b8d19c935f0ace08ea53 |
|
16-Apr-2015 |
Vinit Deshpande <vinitd@google.com> |
Merge "am b5e0cfb..557d2f5 from mirror-m-wireless-internal-release"
|
| e03c3c7edf54854ed22adf1e55b27b2408c4c66a |
|
03-Apr-2015 |
Lorenzo Colitti <lorenzo@google.com> |
Prompt if a network without an Internet connection is selected
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
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| 31a94f48bf8014cf6a1127bd23cf9a8541a9abed |
|
13-Feb-2015 |
Paul Jensen <pauljensen@google.com> |
Add ConnectivityManager.getActiveNetwork().
Rework NetID allocation in ConnectivityService so registerNetworkAgent() can
return the allocated NetID.
Bug: 19416463
Change-Id: I68e395552cf27422c80b4dfae5db5d56a0d68f5d
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| 7b42f399430d5d4ace4efbee225bbd3ecd2d4146 |
|
17-Dec-2014 |
Lorenzo Colitti <lorenzo@google.com> |
Add a lastValidated bit and use it when reporting capabilities.
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
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| d3b8a3e77696ecd90ce59a869aaadf1e7804a9c8 |
|
17-Dec-2014 |
Lorenzo Colitti <lorenzo@google.com> |
Rename validated to everValidated.
This is a straight rename and thus a complete no-op from a
functionality perspective.
Bug: 18777225
Change-Id: I140d7640f1460c869a311294873772819a7a7059
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| b10e37fd1c3a95f7e621eed234c2491eb71241e2 |
|
25-Nov-2014 |
Paul Jensen <pauljensen@google.com> |
Reap unvalidated networks that have no chance of becoming highest scoring.
These networks are unneeded and waste battery. We won't bring up these
networks in the first place if they have no chance of becoming highest scoring.
This change handles the case where these networks are already up and
transition to a state where they have no chance of becoming highest scoring.
This happens when another network validates with a score higher than this
network can ever hope to attain.
bug:18489123
Change-Id: I77a96a72e250e25e44e0c50e7a928af8b35bb6ab
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| 0cc1732cfb9d68779449b4c12661b4df6bfc720b |
|
25-Nov-2014 |
Paul Jensen <pauljensen@google.com> |
Remember to cancel lingering when a network again satsifies a NetworkRequest.
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. Also, make sure this is only done for created
Networks as "created" is the signal to initialy match Networks and requests.
bug:18169560
Change-Id: Ia69b110f6473371e556c60b950253758e023b7aa
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| be3736d38774210549deb2999bb226d83a29f1ee |
|
26-Nov-2014 |
Paul Jensen <pauljensen@google.com> |
Merge "Don't let NetworkMonitor state stop user-initiated transitions." into lmp-mr1-dev
|
| 71b645fe9cb8106dfcbf025a3fd7f58698c051bb |
|
13-Oct-2014 |
Paul Jensen <pauljensen@google.com> |
Don't let NetworkMonitor state stop user-initiated transitions.
GCM can call reportInetCondition() at any time which can cause
the NetworkMonitor to transition states to reevaluate at any time.
Previously we were only listening for users clicking the sign-in
notificaiton or completing sign-in when in the appropriate state.
With this change NetworkMonitor's state does not stop us from
listening for the user's actions.
bug:17917929
Change-Id: Ic1da31d90f7090e5fc111874cb7c37d505aaf590
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| 2c311d61eaf331818e601f97485f88c4cf26384d |
|
17-Nov-2014 |
Paul Jensen <pauljensen@google.com> |
Don't bother validating networks that don't satisfy the default request.
The only immediate change in behavior is not validating untrusted networks.
bug:18299572
bug:18394654
Change-Id: I8d626baf37db0bd0f55ddf3af8a0abf094a12369
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| 954394653dad05838235f48244a4320893e0f0cf |
|
09-Oct-2014 |
Lorenzo Colitti <lorenzo@google.com> |
Support more than one clatd at a time.
1. Make Nat464Xlat a per-network object, one for every network
requiring clat, instead of a ConnectivityService singleton.
2. Make the NetworkManagementService clatd commands take an
interface.
3. When we attempt to start clatd on a network, store its
Nat464Xlat object in the NetworkAgentInfo, so we have an
authoritative way of knowing whether clat is running on a
given network.
4. Rework Nat464Xlat, hopefully simplifying it.
Bug: 12111730
Change-Id: I1fa5508ef020cd1c3d1c7a1f7b06370ac5fc2ae2
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| e73cc4646bed3926024c9f54ca59e3a82a97b56c |
|
08-Sep-2014 |
Robert Greenwalt <rgreenwalt@google.com> |
Add NetworkAgent event for ExplicitlySelected
Lets Wifi tell us when the user selected this AP vs auto-connected.
bug:17396168
Change-Id: I6e067ab62ed49040629aa31fe07ff880d3d542f0
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| 2161a8ea123134ee3f9a10c0f8f56aabd8289f69 |
|
11-Sep-2014 |
Paul Jensen <pauljensen@google.com> |
Better handling of unvalidated networks.
Give unvalidated networks penalized scores and allow them to satisfy
requests.
Previously unvalidated networks were never allowed to satisfy
NetworkRequests and so never caused CONNECTIVITY_ACTION broadcasts.
Previously if there were no other networks present an unvalidated
network would still be made the default. This change formalizes
this behavior using our existing network score logic by assigning
unvalidated networks a highly penalized score.
bug:16358003
bug:17364306
Change-Id: I28fcd6f5ac4b52a4d1c234c472cfa8ba998bcc6f
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| 7ccd3dfd53d8d45c447398ff137f052865dfd3b3 |
|
29-Aug-2014 |
Paul Jensen <pauljensen@google.com> |
Implement ConnectivityManager.reportBadNetwork() to trigger network validation.
Network traffic used to perform the network validation is billed to the UID of
the caller of reportBadNetwork. This change does not change the actions taken
upon validation failing or succeeding: NetworkMonitor will show the sign-in
notification if a captive portal is found. NetworkMonitor will inform
ConnectivityService if a network tests functional. NetworkMonitor will not
take action if a network lacks any connectivity.
Also, remove an unused Thread that was confusing bandwidth billing.
bug:17326268
Change-Id: I7fea23480af54211004a0a1c535a71c2793f21bb
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| 60061a6ebf4ef758c4a47d210de0e5be2484be5b |
|
05-Aug-2014 |
Paul Jensen <pauljensen@google.com> |
Avoid reusing a currently active NetID.
There are only a limited number (65526) of NetIDs so the chance for reusing
one exists. Reusing a currently active NetID will cause problems like netd
failures and overwriting entries in mNetworkForNetId.
bug:16815182
Change-Id: Ib75302beae3179c3f3b90c345cf4d2cf5f4ad2be
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| eec75412a971a5ccb769364120c769c331946eb3 |
|
04-Aug-2014 |
Paul Jensen <pauljensen@google.com> |
Stop ConnectivityService from talking to netd about uncreated networks.
This avoids logged netd errors that are red-herrings.
bug:16667349
Change-Id: I5d6f1681f1d38dab0af4c535573a0c45c0216603
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| 8cd33ed84e94036a5e1201485af7603dc6fb0d9b |
|
24-Jul-2014 |
Sreeram Ramachandran <sreeram@google.com> |
Implement support for bypassable VPNs.
Bypassable VPNs grab all traffic by default (just like secure VPNs), but:
+ They allow all apps to choose other networks using the multinetwork APIs.
If these other networks are insecure ("untrusted"), they will enforce that the
app holds the necessary permissions, such as CHANGE_NETWORK_STATE.
+ They support consistent routing. If an app has an existing connection over
some other network when the bypassable VPN comes up, it's not interrupted.
Bug: 15347374
Change-Id: Iaee9c6f6fa8103215738570d2b65d3fcf10343f3
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| 6bc2c2c34f2b23eae79ad733c97a691734055c4f |
|
07-May-2014 |
Paul Jensen <pauljensen@google.com> |
Convert Vpn from NetworkStateTracker to NetworkAgent.
This eliminates the need for the ConnectivityService.VpnCallback class.
This requires shifting VPNs to the new "network" netd API.
VpnService.protect() is modified to no longer go through ConnectivityService.
NetworkCapabilities is extended to add a transport type for VPNs and a
capability requiring a non-VPN (so the default NetworkRequest isn't satisfied
by a VPN).
bug:15409918
Change-Id: Ic4498f1961582208add6f375ad16ce376ee9eb95
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| 2c7bf2cb46024eb87aec4b5ac0fa15477cc14f7a |
|
24-Jun-2014 |
Robert Greenwalt <rgreenwalt@google.com> |
Clean up and add some Network logging.
Dumps the netid for the Network and adds that to the NetworkAgentInfo.
Change-Id: Id9fbcc55ca55bf1a020f747f0c44902efb1b5f87
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| b90b20b5d57809da5c91bac9ff45c2ac323d9637 |
|
03-Jun-2014 |
Robert Greenwalt <rgreenwalt@google.com> |
Fix Legacy NetworkInfo API
Make the connectivity changed broadcasts send correct NetworkInfos.
Also update the results of getNetwork.
bug:15290306
bug:15191336
bug:14993207
Change-Id: Ie99ad25f3ebb90d18348e7013761b139e7481866
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| 71bf33a02f49444fbfa35b267c70592f3b07a07d |
|
16-May-2014 |
Robert Greenwalt <rgreenwalt@google.com> |
Rewrite startUsingNetworkFeature for new API
bug:14993207
Change-Id: I041a80faa07bf3094af13a6c606f3b15aa03f789
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| 9258c64bef1a01fe89bc7c1fa402c44c0e6a1255 |
|
27-Mar-2014 |
Robert Greenwalt <rgreenwalt@google.com> |
Add Multinetwork API
Change-Id: I3a9cef0d416db96d05098dd989ee3fef3b1e9274
(cherry picked from commit cc5e6afa1ba0bef099bcb21a64a36bc2bf7951db)
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| ca8f16ad14819ba17f5ff3d2e2bf6fbc9bbaa9f7 |
|
09-May-2014 |
Paul Jensen <pauljensen@google.com> |
Add NetworkMonitor.
At present the network evaluation / captive portal detection
is disabled pending addition of API to bind socket to network.
Change-Id: I5d1f5dc86d4dd9481d52dd45d6da0732054c8315
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|
| 7b81602f3c18df8a4ca0342c514af8f7e394c0d7 |
|
19-Apr-2014 |
Robert Greenwalt <rgreenwalt@google.com> |
Enabling internal msg apis
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
/frameworks/base/services/core/java/com/android/server/connectivity/NetworkAgentInfo.java
|