hci: support multi-adv (5/~6) - AndroidVendor methods
The 5th patch in the advertising corpus. This adds the "Android
Vendor" method for advertising (multiple sets, 4.0 spec + android
extensions) and implements it when chip support is present. Misc
fixes included for build reasons. Test app updated to demonstrate
multi-adv, reading power level, and using random addressed. This
method of doing multi-adv is a bit weird, some explanation is due
here to clarify the logic: Android Vendor Extensions for BT provide
for multi-adv, but caveats exist. If the chip says it supports X
slots, in reality it supports X - 1 slots with this custom API
(indexed at 1) and the default 4.0 API (slot 0). "but," you might
say - "default API has no TX power control!" Yes. Slot 0 has no
tx power control. this makes our logic here a bit more complex
since we can at times enable an adv if it has no power request,
but cannot if it does. We could try to be clever and relocate an
existing adv to slot 0, but really it is not worth the trouble.
Adnroid, for example, will entirely ignore slot 0. thus we are
already doing better. This code will try to allocate slot 0 to an
adv if it has no TX power requirements though, through the
nature of how it is written. Any further cleverness is IMHO not
worth it. So, what should you take away from all this? If you do
not care for setting TX power, use HCI_ADV_TX_PWR_LVL_DONT_CARE.
Usually this *WILL* be max TX power (likely what you want
anyways) and will not use up one of the desirable
configurable-power slots if slot 0 is available.
TEST=runs as expected on minnie. advs observed
Change-Id: I1810981cd3c97c05e814f7d0479d691ebbf426d6
5 files changed
