> unless the user manually slides the "wifi" slider to on.

Hmm, does this mean that maybe Chrome is getting confused if it comes up before shill does?

I'm not sure why the proposed cause would affect resume (as in system suspend/resume). It could affect boot though. If it's only the former that's a problem, consider changing the subject.

s/former/latter/

(Sorry)

The following revision refers to this bug:
  https://chromium.googlesource.com/aosp/platform/system/connectivity/shill/+/d9cd68b36b0f66083b608d035e6c2794de4564bd

commit d9cd68b36b0f66083b608d035e6c2794de4564bd
Author: Kirtika Ruchandani <kirtika@google.com>
Date: Thu Mar 22 03:48:35 2018

shill: network-services: no wait for udev-trigger

For release R66, we've resolved the issue of two entities on the system
providing cfg80211 functionality by getting rid of stock cfg80211 on boards
with Intel wifi. We no longer need to worry about the wrong cfg80211 being
loaded on the system, so no need to wait for a wifi device driver (for which
udev-trigger was a proxy) before starting network-services (and hence shill).

This should resolve boot time performance regressions seen post-Core31 :
making shill start-up dependent on udev-trigger meant the network
wouldn't come up in the UI until a good 8-10 seconds after boot.
On some devices, this was user-visible: user would find wifi turned off
in the GUI because shill hadn't started up by the time the login screen
came up, and turning the wifi slider to on manually wouldn't work until
shill did start up.

This partially reverts commit 6455013e3b00 ("init: Get rid of load_cfg80211").

BUG= chromium:810696 ,  chromium:822485 , b:74171245
TEST=Build and boot on Soraka, check that wifi is up on the login screen.

Change-Id: I5f8e25942c27b28a9dc64c891d2ccf1df0adc2fa
Reviewed-on: https://chromium-review.googlesource.com/972764
Commit-Ready: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>

[modify] https://crrev.com/d9cd68b36b0f66083b608d035e6c2794de4564bd/init/network-services.conf

Fixed in 67. Merge request for 66 is in:

https://bugs.chromium.org/p/chromium/issues/detail?id=807315

The following revision refers to this bug:
  https://chromium.googlesource.com/aosp/platform/system/connectivity/shill/+/ea3c60b0987369d5cec8dac2ee2a675bed7ca029

commit ea3c60b0987369d5cec8dac2ee2a675bed7ca029
Author: Kirtika Ruchandani <kirtika@google.com>
Date: Sat Mar 24 00:49:16 2018

shill: network-services: no wait for udev-trigger

For release R66, we've resolved the issue of two entities on the system
providing cfg80211 functionality by getting rid of stock cfg80211 on boards
with Intel wifi. We no longer need to worry about the wrong cfg80211 being
loaded on the system, so no need to wait for a wifi device driver (for which
udev-trigger was a proxy) before starting network-services (and hence shill).

This should resolve boot time performance regressions seen post-Core31 :
making shill start-up dependent on udev-trigger meant the network
wouldn't come up in the UI until a good 8-10 seconds after boot.
On some devices, this was user-visible: user would find wifi turned off
in the GUI because shill hadn't started up by the time the login screen
came up, and turning the wifi slider to on manually wouldn't work until
shill did start up.

This partially reverts commit 6455013e3b00 ("init: Get rid of load_cfg80211").

BUG= chromium:810696 ,  chromium:822485 , b:74171245
TEST=Build and boot on Soraka, check that wifi is up on the login screen.

Change-Id: I5f8e25942c27b28a9dc64c891d2ccf1df0adc2fa
Reviewed-on: https://chromium-review.googlesource.com/972764
Commit-Ready: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
(cherry picked from commit d9cd68b36b0f66083b608d035e6c2794de4564bd)

[modify] https://crrev.com/ea3c60b0987369d5cec8dac2ee2a675bed7ca029/init/network-services.conf

Fixed? We probably want to make sure this gets some additional testing for M66.

Dinesh / Ramya, please use M66 10452.27.0 or newer to test / verify this (also test on ToT). I cc'd you on another related bug b/74171245

Tried to verify this on M66 build on DUT - Soraka, observed there was no delay in connecting to wifi after booting the device, across both the M66 builds below.  
Time taken for network_wifi_ready in bootstat_summary is definitely better on M66-10452.30.0.

#bootstat_summary on M66-10452.24.0 ( before the fix) 

 time %cpu       dt  %dt  event
    1040  23%     1040  23%  pre-startup
    1820  27%      780  33%  post-startup
    4430  16%     2610   8%  lockbox-cache-start
    4440  16%       10  75%  lockbox-cache-end
   10880  10%     6440   6%  chrome-exec
   11140  11%      260  48%  chrome-main
   15730  22%     4590  49%  login-prompt-visible
   15750  22%       20  75%  mini-android-start
   16710  25%      960  79%  arc-setup-for-mini-android-end
   16790  25%       80  56%  boot-complete
   19500  32%     2710  75%  shill-start
   33530  31%    14030  30%  network-wifi-association
   33760  32%      230  64%  network-wifi-configuration
   34320  31%      560  25%  network-wifi-ready
   34320  31%        0 100%  network-wifi-online
  207000  13%   172680  10%  network-wifi-association
  207040  13%       40  63%  network-wifi-configuration
  207830  13%      790  11%  network-wifi-ready
  207840  13%       10  80%  network-wifi-online


#bootstat_summary on M66-10452.30.0 ( with the fix )
    time %cpu       dt  %dt  event
    1020  23%     1020  23%  pre-startup
    1430  28%      410  38%  post-startup
    4400  19%     2970  15%  lockbox-cache-exec
    4400  19%        0 100%  lockbox-cache-start
    4430  19%       30  83%  lockbox-cache-end
    5440  18%     1010  15%  shill-start
    8840  14%     3400   6%  network-wifi-association
    9120  15%      280  67%  network-wifi-configuration
    9400  15%      280   8%  network-wifi-ready
    9590  15%      190  18%  network-wifi-online

Please let me know if I have to check any additional details apart from the above, for further verification of this defect.

Marking this as verified as per c#15 above.