Now that we also handle supplicant state change to identify that
a network is disconnected (in case CTRL-EVENT-DISCONNECTED goes missing),
it is dangerous to defer all supplicant state change messages
while in DisconnectingState.
It may happen that the CTRL-EVENT-DISCONNECTED goes missing while in
DisconnectingState resulting in a supplicant state change of 0 (disconnect)
getting deferred.
Eventually after a connection completes, the supplicant state change events
get handled and the state machine goes into DisconnectedState.
Fix by having state machine switch out of DisconnectingState once we
do not immediately see a CTRL-EVENT-DISCONNECTED state.
Bug: 5490789
Change-Id: Ia2263795e53c51da0a2bfeefecfeb6256d6c5267
This allows a carrier app to authenticate before we notify the user.
For future, we will provide an API that allows app to disable
the walled garden check.
Bug:5398921
Change-Id: Iff98ddaaa9fa38def4f43b1995f4b2c36f93a919
Handle a supplicant state change indicating disconnection
even if we have missed the CTRL-EVENT-DISCONNECTED notice
Bug: 5437924
Change-Id: I28e314f47f17359926c091b2015cd1fb7422fb22
Reconnecting to a bad network can be expensive (network down time wise and for the device as well).
Add a minimum threshold.
Bug: 5234206
Change-Id: I5ef1fe06038db73c29a3e95b6229506555f36c77
WEXT on crespo has an issue where the interface up/down events
can happen in an unexpected fashion.
At a driver start, we can go from interface disabled to interface enabled,
back to interface disabled and then eventually into an interface enabled state.
Earlier, we were just expecting a single interface enable event that would trigger
driver specific commands. Now, we just handle these events as individual driver
stop and driver start situations so that we do appropriate things eventually
Bug: 5239853
Change-Id: I6bd5d844edf9fadfdca4e8eb753c2ba738aa6ad5
- The pings are delayed async messages that were getting handled
after a disconnect as well
- Increase poll time to 200 ms, so we block on a receive for 1ms every 200ms for a
sent packet
Bug: 5361564
Change-Id: I1931a1c4146e78a87407d541d8c3934ff8232604
When framework fails to get a notice of supplicant shut down,
timeout and proceed with a forced terminate
Also, avoid killing supplicant immediate upon stop and use the
timeout for recovery
Bug: 5337272
Change-Id: Id8971c673dc3082a5f15a6d5cef907bebe1e0fa0
For wifi, track ECM and shut down and restart when device
goes in ECM and out
For p2p, simply turn off when in ECM mode
Bug: 5185246
Change-Id: I5f5bf75fac3e27db1d7c412135c796f2b137263d
- Reduce DNS counts from 15 to 5. 15 was for debug.
- Keep success scenario as atleast 1 being successful
- Wait for a second to start checks (for some setups)
- Use one bar as a start for doing periodic DNS checks
- Do a DNS check every hour (instead of half hour)
Bug: 5284337
Change-Id: Ie64d8cac48318a0c4c59f91ad21f8c6712b71338
A previous change missed out a function that accepts an
integer argument as arg1. Instead, it was being passed as
parcelable which causes a fatal exception
Bug: 5271220
Change-Id: I3b78d9ce9ab742aa89ceaae17116fb7245187863
For the purpose of exposing the class as a storage for Wps
info with p2p, it is better to just call it Wps
Bug: 5247957
Change-Id: Iaebef958dd8f08fdbeb4b9d7fa5ad5527400710d
- Update the WifiP2pGroup class
- Add reason code response for all failures
- Fix display of self in peer list
- Retain p2p group when explicitly created by API and fix join behavior
Bug: 5247957
Change-Id: Ibd9b163887db1c8a9dd8213253fda20c436a49e3
First part of documentation and cleanup before we can unhide
the p2p API for review by API council.
Bug: 5247957
Change-Id: Idb52f0b699d23e22aa829f60cfac2c98451d2e22
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
Until we figure out a good way to do it from both group owner
and client, remove persistent behavior
Bug: 5241839
Change-Id: I31bda672edaa17e6a500f185b6b879dcfdbd069d
When we first ported wpa_supplicant 0.8, we had a work around
to fix the supplicant state change behavior from the driver.
Remove the work around since the driver behavior is fixed.
Bug: 5195278
Change-Id: I320f21ab01704931a3def6214b0cc40f214a688e
And fix associated changes from the settings.
With p2p_reconnect setting turned on, it means the p2p group can be
started without a group negotiation. Hence, handle p2p group started in
the P2pEnabledState
Also, reinvocation results in supplicant not reporting device address correctly.
Handle that until supplicant fix is fixed.
Bug: 5002384
Change-Id: I335f6e854acd6839f54da9b460b17ad7505b1098
- Space was truncated on 'disabled' notification
- Disable reason was getting wiped out on subsequent disabled
- disable reason was not propogating to WifiSettings
Change-Id: I2e57ee33d285aad39aabe1b048e7436d364b02f3
- Simplify the API with minimal needed functionality
- Fix responses for all async messages from the framework
- Fix state machine handling of connection setup and supplicant communication
Change-Id: I2724c83760b2aaa2068f9cd81ca0754753f83220
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
