utils: bdaddr: start the set_bdaddr service in the boot trigger
the same as the other core class services.
Othewise starting the set_bdaddr service under the post-fs trigger
might be too early when the BT driver setup might not be fully
completed yet, which would cause Bluetooth related crash, like the issue
reporte here: https://issuetracker.google.com/issues/318404233
Especially for the case that the BT driver needs to load firmware
with the help of the ueventd feature from the usespace side.
As under the post-fs trigger, the firmware loading is not ready yet.
In init.rc, the firmware_mounts_complete trigger is defined
to start the necesary firmware loadings, which will be trigered
after the post-fs trigger, and the boot trigger will be triggered
after the firmware_mounts_complete trigger, it will help to start
the core class services.
So setting the set_bdaddr service to be started as the normal core class
service under the boot trigger could help make sure the set_bdaddr
service is started after the BT device driver setup is fully finished,
and to avoid breaking the BT device driver setup and to avoid causing
any unexpect issues.
Bug: 318404233
Fixes: f70f12a826af("utils: bdaddr: Add service to set Bluetooth device (MAC) address")
Test: bluetooth turned on by default for all kernel versions
Change-Id: Ie7206734f197d258b4e713b44e1fa1b5f15c58c5
Signed-off-by: Yongqin Liu <yongqin.liu@linaro.org>
diff --git a/shared/utils/bdaddr/bdaddr.rc b/shared/utils/bdaddr/bdaddr.rc
index 65706db..d6edb64 100644
--- a/shared/utils/bdaddr/bdaddr.rc
+++ b/shared/utils/bdaddr/bdaddr.rc
@@ -19,8 +19,4 @@
user root
group system
capabilities NET_ADMIN
- disabled
oneshot
-
-on post-fs
- start set_bdaddr