Bluez only starts up with system-services. See this, from /etc/init/bluetoothd.conf:

start on starting system-services
stop on stopping system-services

Contrast this with, e.g., shill which has:

start on started network-services  and started wpasupplicant
stop on starting pre-shutdown

(network-services is 'start on started boot-services')

And note the only documentation I have for these layers:

https://www.chromium.org/chromium-os/chromiumos-design-docs/boot-design


Depending on 'system-services' means that it won't start up if the system doesn't reach the login prompt. This may never happen for boards that, e.g., are in early bringup (and don't have a running display driver). It seems reasonable to improve this situation.

Possible solutions:
(a) 'start on started boot-services' + 'stop on stopping boot-services'
(b) 'start on starting failsafe' + 'stop on stopping failsafe'

Problem with (a): this would start bluetooth in parallel with Chrome (I think?). This might be considered an unnecessary boot time risk, since bluetooth is not considered "critical" for UX?

Problem with (b): not much? It triggers fairly late by default (30 seconds) [1], if the UI doesn't come up. But that's probably OK, since if we're relying on failsafe already, then we must be doing something "advanced" (e.g., board bringup).

[1] Personally, I always decrease this to around 10 seconds on my builds; "ain't nobody got time for that" meme/5883442327977984