All boards failing are 3.8 kernel which is related to the ble advertising interval bug.

I don't believe there are any plans to merge this into the 3.8 kernels - all devices that are using this should be EoL'ed by now.

We should disable this test for older kernels that we don't plan on supporting.

Agreed we should disable the test for unsupported devices, but there are many 3.8 devices that are not set to EOL until 2019 (wolf, pit, skate, etc.)

The 3.8 kernel will need to be supported into early 2020 :(

Assigning to myself to fix logging/error messages since we now know the origin of the consistent failures. 

AFAIK, only multi-advertising and/or setAdvertisingInterval are not supported in the older kernels. Neither of these are must-have features for these old boards, so we should be fine dropping them.

We should break the advertising tests into more granular tests so we can continue to run basic single-advertisement tests on older devices.

The advertising tests are currently broken down into multi, single, SR, and reboot (so we can do stress SR and reboot testing). 

What we can do is add the SR/reboot tests into the corresponding multi/single buckets, remove the non-stress SR/reboot control files, and add a flag to check for the older kernels before we kick off test cases for multi-advertising. 

setAdvertisingInterval is called in all of the single advertisement tests and therefore fails on all the 3.8 kernels, so we need some way to test a basic LE advertising on these boards.

We should then break down the single advertising test in a simple and advanced - with the advanced calling set advertising interval.

In fact, multi-advertising also 'should' just work on older boards. It really is just setAdvertising interval (and multi-advertising with non-default advertising intervals) that should be broken.

In that case, we can add simple test cases to test some combination of register advertisement -> check duration -> unregister advertisement -> reset advertising.

@josephsih to confirm. We can add this to the doc (go/ble-advertising)

I tested registering a single advertisement on a 3.8 kernel board (link) and received a failure. Setting advertisement intervals "passed" but this may be due to no errors being thrown as checking the duration of the new intervals failed. Will sync with Joseph. For now, I've uploaded a change which raises testNA error when a 3.8 kernel board is encountered.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/766aee37797093db75ba93b3f1c1940c540bd9dd

commit 766aee37797093db75ba93b3f1c1940c540bd9dd
Author: Ruchi Jahagirdar <rjahagir@google.com>
Date: Wed Oct 25 22:44:13 2017

[Bluetooth] Modifying bt_AdapterLEAdvertising test

Modifying bluetooth_AdapterLEAdvertising test to skip over boards with 3.8 kernels due to crbug/729648. Also, removing bt_AdapterLEAdvertising.suspend_resume/.reboot in favor of having all multi-advertising and all single-advertising together. We are, however, keeping the stress files (suspend_resume.stress_50, reboot.stress_50).

BUG= chromium:753611 
TEST=test_that <ip> bluetooth_AdapterLEAdvertising.{single,multiple}

Change-Id: Idc26ddbaa26839e94163cfca7c1a6b43d4883782
Reviewed-on: https://chromium-review.googlesource.com/737050
Commit-Ready: Ruchi Jahagirdar <rjahagir@chromium.org>
Tested-by: Ruchi Jahagirdar <rjahagir@chromium.org>
Reviewed-by: Ruchi Jahagirdar <rjahagir@chromium.org>

[delete] https://crrev.com/6201c7ddb5b66d809776d01d40e852b9e90f2454/server/site_tests/bluetooth_AdapterLEAdvertising/control.suspend_resume
[modify] https://crrev.com/766aee37797093db75ba93b3f1c1940c540bd9dd/server/site_tests/bluetooth_AdapterLEAdvertising/bluetooth_AdapterLEAdvertising.py
[delete] https://crrev.com/6201c7ddb5b66d809776d01d40e852b9e90f2454/server/site_tests/bluetooth_AdapterLEAdvertising/control.reboot