bluetooth-service: early API call to 'power' verb fails

Duplicate of

Ok yeah agreed usleep() delays aren't idea. Ran into this issue with the rpi3 and if the BT adapter wasn't on a powered hub (race condition disappeared when it was).. 

I'll have to look into the BlueZ API a bit more for a solution.. One issue is when there are more than one adapters on a system, but that isn't usually a big issue if there isn't onboard BT or it has one that works.

Yes, at startup. When 4A or Homescreen start, systemd resolves the dependencies (requires/after/wants/...) and starts the depending services: agl-service-bluetooth is started and a few milliseconds later, the requiring service starts too. But as things are not well initialized yet, then initial requests will fail.

The solution is to do initialization and wait for a stable state in preinit/init hooks of the binding, as systemd activation happens after all bindings have been initialized. Adding a delay is a bad workaround, as this varies from one board to another (I hit the issue 100% of the time on H3, but you may get it only 10% of the time  or never on M3 or RPI

Clearly a race condition with the on-board bluetooth + BlueZ stack.  Assuming by "early" API calls you mean on startup?

At boot, 4A BT plugin asks for existing HCI controllers to the Bluetooth-Manager by using the verb 'power' (query powered devices).

Due to current bug, 4A BT plugin assumes that there are no BT controller on the target and disable BT support in 4A.

 This can be easily tracked by running this command: