Also, removed some unused NetworkStateTracker event codes.
The API change was to add context and target to startMonitor, this makes
it easier to document what the actual interface contract is.
Change-Id: If9b52486c3c281fe4794bc78417c8b03888414b1
Add asynchronous API for simplified connect, save
and remove.
Add a SUPPLICANT_CONFIG_CHANGED_ACTION broadcast to
notifiy a supplicant configuration change.
Change-Id: I69ae116246094de4a469cb2af5baf37e5ad4d6dd
When the default network goes down we lose the wake-on-incoming-data capability
until the new net is brought up and apps rebuild their connections. We fixed this
in Wifi, but it's a general connectivity issue, not a wifi issue so moving the
mechanism to connecitivty so other networks can use it.
bug:2734419
Change-Id: I39b5d825eb6b548bd9bb8f179b89254f4db53147
If soft AP bring up does not go through successfully,
dont persist the config. This has the benefit of recovering
from the case where things fail on "=" and "," for SSID since
the IOCTL parsing in driver on broadcom cannot handle it
at this time.
Change-Id: Iaa60fd05972db434500753dcb59092995dab07b1
Tethering should be disabled when
airplane mode is enabled. Additionally,
we should restore Wifi (if it was on
before tethering was enabled) when
airplane mode is disabled.
Bug: 2567099
Change-Id: Iba2031f5ecb207954fd155c47134b39ed0167fa0
Now that wifi start is asynchronous
at the time of bring up, make sure
Wifi is not started if in airplane
mode.
Bug: 2567652
Change-Id: I947b7c8480029973bcbf028f6143aabbc88c9793
Setting the allowed channel count in the
driver can take a long time to potentially
cause ANR in the phone process. Make the call
asynchronous
Bug: 2555117
Change-Id: Ie3c2e6f90aa0ec8ee4b85c989ccae1ca0f2b94f9
Killing the WifiWatchdogService thread from
WifiService can cause messages to be handled on
a dead thread. Quit the thread on the broadcast
instead.
A couple of more fixes:
- Do an asynchronous bring up of Wifi. This will
allow WifiWatchdogServiceThread to be immediately
brought up, instead of relying on an update.
- There is no need to listen on supplicant connection
in wifiwatchdog anymore. We kill the thread when
supplicant connection is no more.
Bug: 2546756
Change-Id: I15a188e031bc79856c55aabdd271287b0df0377d
We add a variable for saving wifi state
to restore after tethering.
Bring up wifi on boot up if the state indicates so.
Bug: 2537983
Change-Id: I9c6548b93df6fcbc0cec1e6b857f7224dc6d1b2c
Previously we only supported a single range - this was inadequate for
multiple interfaces. Adding a second range so we can support
both usb and wifi tethering.
Also moving out of the zero-conf range as our dhcp client won't
accept ip addrs in that range (no nexus to nexus wifi action).
bug: 2537963
bug: 2533491
bug: 2538303
Change-Id: I600b421343c28c2f9839ed2076122ae3d0ff5d3d
Disallow Tethering being disabled by Wifi
and vice versa. We now need to explicitly
disable tethering to enable Wifi.
Bug: 2539071
Change-Id: Id34a5335e70cb7234367b4709882937a4b8cc526
Due to message removal, wakelock could be held forever.
Do a timer only based wakelock release until we do this
more cleanly in ConnectivityService for later release.
Also, add an optimization to prevent use of wakelocks when driver is
already stopped.
Bug: 2529883
Change-Id: Ia1c2ddd44213ef3aa609855613bf155945bef8e4
Driver commands should be issued when driver has started.
Supplicant commands should be issued when Wi-Fi is enabled
Bug: 2339709
Bug: 2371609
Change-Id: I9ba6ddfa0cf4c4b8ca049b0eb7eaaa8edb42bad1
The IP state was not being refreshed when the supplicant transitions
from COMPLETED to ASSOCIATED to COMPLETED. This can lead to
a connected state with no real connection due to old IP settings.
The fix refreshes IP on each connection.
Bug: 2329261
Change-Id: I38cd56369ee2d8ab3e0f06f5c9f5712b9b2f35a0
Some of the native calls were left unsynchronized in the framework. Pre-empted IOCTL call
interrupted by another call from the framework cannot be handled in the driver.
Bug: 2310455
Merge commit '9d3cb9bfc6d7a5f340d2dd8132b201b933687564' into eclair-mr2
* commit '9d3cb9bfc6d7a5f340d2dd8132b201b933687564':
Fix updating Bluetooth icon on status bar and for Wifi.
Status bar uses the SINK_STATE_CHANGE intent to determine the icon.
This intent also has the device. Thus, we can get this intent for any
device and we update the icon wrongly. The same problem is with Wifi.
This was not commonly observed till now, but with the car dock changes
its easy to reproduce as we can get an incoming connection from the
car's bluetooth system. For Wifi, this will cause coexistance issues
especially with desk docks.
Dr No: Eastham
Bug: 2133530
The driver can now report to us that they are hosed and we'll shut
down wifi and restart it - only to be used as a last resort.
Also fixing synch problem with updateWifiState.
bug: 2173119
Merge commit '16cb04ab1cd88d917fdd34a9063fe4a9707aa5b1' into eclair-mr2
* commit '16cb04ab1cd88d917fdd34a9063fe4a9707aa5b1':
Add a little logging to diagnose wifi cycle bug
+ push the double-quote handling down to framework.
wpa_supplicant keeps the ssid in a quoted string in the config file. However,
the UI currently needs to handle the quoted string which makes it difficult
to handle the SSID containing the quotes. The change will move the
supplicant-specific double-quote handling from UI to framework, i.e. to
add/remove doubel-quotes in framework instead of in UI settings.
We already had a delay if we were associated, but we have some race conditions
we think will be masked if we delay the driver stop for the other cases
too. Don't wait as long (2 min instead of 15).
bug: 2147260
The process for starting wifi was using a wakelock around a message-pass and this was causing
an exception for meer mortals (who don't have WAKE_LOCK permission).
bug: 1750535
The supplicant can take up to 15 seconds to start - setting the number of wifi channels
immediately after requested wifi start often will fail.
Changed to set the number of channels when the supplicant is reported as alive.
bug:2083601
This is a large batch, and covers:
-- Bluetooth Device Discovery --
BluetoothAdapter.ACTION_DISCOVERY_STARTED
BluetoothAdapter.ACTION_DISCOVERY_FINISHED
BluetoothAdapter.startDiscovery()
BluetoothAdapter.cancelDiscovery()
BluetoothAdapter.isDiscovering()
-- Bluetooth bonding (pairing) --
BluetoothAdapter.getBondedDevices()
BluetoothDevice.ACTION_BOND_STATE_CHANGED
BluetoothDevice.EXTRA_BOND_STATE
BluetoothDevice.EXTRA_PREVIOUS_BOND_STATE
BluetoothDevice.BOND_NONE
BluetoothDevice.BOND_BONDING
BluetoothDevice.BOND_BONDED
BluetoothDevice.getBondState()
BluetoothDevice.createBond()
BluetoothDevice.cancelBondProcess()
BluetoothDevice.removeBond()
-- BluetoothClass --
BluetoothDevice.ACTION_CLASS_CHANGED
BluetoothDevice.EXTRA_CLASS
BluetoothDevice.getBluetoothClass()
BluetoothClass.Service.*
BluetoothClass.Device.Major.*
BluetoothClass.Device.*
BluetoothClass.getDeviceClass()
BluetoothClass.getMajorDeviceClass()
BluetoothClass.hasService()
-- Misc BluetoothDevice --
BluetoothDevice.ACTION_ACL_CONNECTED
BluetoothDevice.ACTION_ACL_DISCONNECTED_REQUESTED
BluetoothDevice.ACTION_ACL_DISCONNECTED
BluetoothDevice.ACTION_DISCOVERED
BluetoothDevice.ACTION_NAME_CHANGED
BluetoothDevice.EXTRA_DEVICE
BluetoothDevice.EXTRA_NAME
BluetoothDevice.EXTRA_RSSI
-- Misc BluetoothAdapter --
BluetoothAdapter.ACTION_LOCAL_NAME_CHANGED
BluetoothAdapter.EXTRA_LOCAL_NAME
BluetoothAdapter.checkBluetoothAddress()
I deprecated BluetoothIntent and moved each intent into the class it relates
to.
Change-Id: I877b1280428ab46278b2bc25668bb44cda22dc36
If the new system settings value for AIRPLANE_MODE_TOGGLEABLE_RADIOS
contains RADIO_WIFI, then the user will be allowed to enable Wifi
while in airplane mode.
Turning on airplane mode will still disable Wifi, but the user will
be free to reenable it in the Settings app.
Signed-off-by: Mike Lockwood <lockwood@android.com>
Merge commit '356d4a14aa96cf52c16f7a4d381044ce28b01af3'
* commit '356d4a14aa96cf52c16f7a4d381044ce28b01af3':
Add the phase2 field for EAP WiFi configuration.
