Merge commit 'c58e9bff10200daaad6d06d57745edcc33314325'
* commit 'c58e9bff10200daaad6d06d57745edcc33314325':
Maybe fix#3076572: phone process crashes in SipService, trying to get wifi lock
WifiService needs to keep the calling identity cleared while
it is doing all of its internal work.
Change-Id: I2bd720e26efcf5ad5839693307d61e51f0658ace
When an entity (NLP for example) acquires
a WifiLock and initiates a scan, scan can
get blocked until driver starts.
scan returns no useful info, scan results
are broadcast when obtained.
Bug: 2964633
Change-Id: Iaefc32bb6b82f0718285a18ac600e6bbbb096e77
We now distribute "wifi started" time across all apps that are
holding WIFI locks that cause it to be started. But only when
WIFI would not normally be running. Also have a mechanism to
distribute other WIFI work that has happened across those processes
based on their use.
Also fixed a bug where we were not retaining the CPU speed step
stats across boots...!
Change-Id: I00e3153b98429166273750512cc37e7975211ab9
This fixes a problem where applications could ask the location
manager to do very heavy-weight things (like... say... update
location every minute), which would get accounted against the
system instead of the application because ultimately it is the
system making the heavy calls (wake locks, etc).
To solve this, we introduce a new class WorkSource representing
the source of some work. Wake locks and Wifi locks allow you
to set the source to use (but only if you are system code and thus
can get the permission to do so), which is what will be reported
to the battery stats until the actual caller.
For the initial implementation, the location manager keeps track
of all clients requesting periodic updates, and tells its providers
about them as a WorkSource param when setting their min update time.
The network location provider uses this to set the source on the
wake and wifi locks it acquires, when doing work because of the
update period.
This should also be used elsewhere, such as in the GPS provider,
but this is a good start.
Change-Id: I2b6ffafad9e90ecf15d7c502e2db675fd52ae3cf
We dont plan to have asynchronous versions of the existing
synchronous calls since we have added more powerful
asynchronous calls. Remove functionality to check for
synchronous calls.
Also, remove unused sync call for fetching status
Change-Id: I2982cb7b2aabc88a63289d49686a6e3645085263
Connectivity to a disabled network never happens.
An old dhcp issue for example prevents
connectivity again in future. Allow connectivity
on all networks on screen on.
Bug: 2129037
Change-Id: I42afc17ddb5cd238e46d7e50f1b6e708e107b35d
Make some of the common driver commands scan/disconnect/reconnect/reassociate
asynchronous. We already have broadcasts to indicate results.
Change-Id: I343c6be077fb11a3d488e586ab10ab2373b269d8
The refactor with the new state machine had introduced
a bug with writes to secure settings in public API for
which apps might not have permission.
Bug: 2895750
Change-Id: I7d236253201a47b836996859aa3de2806ad8a800
Add extension to WifiLock to allow apps to operate
in high performance mode (high power & disable suspend
optimizations for battery consumption).
Bug: 2834260
Change-Id: I8b33d307f3d569bc92ba2139b9ed224ffc147547
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
