Comment 2 for bug 1474296

I agree that most cases when a pairing handler is required happen during the initial searching/pairing process, which is when system-settings is running anyways. However, Bluetooth allows some flexibility there. For example a device could just remember the BT MAC address and try to do the pairing later. Or a device is also allowed to invalidate the link key and reinitiate the pairing sequence at any time. If bluez has no agent registered at that time it will fail. I could well imagine some of the car connectivity issues we have are related to this. Can't tell for sure without reproducing.

In any case, from a user point of view it's not really obvious that one can only receive the Bluetooth PIN entry dialog while the system-setting's bluetooth page is open. Even if the car kit would be able to deal with this, I'm sure some users just don't manage to pair it because they're not aware of that fact. Even if the system-settings app is running, but not focused it will be frozen, which causes bluez's D-Bus connection to get stuck and will definitely confuse the other device with timeouts etc.

Kinda related to this, but probably justifies a separate bug report is that when having the bluetooth page open we do a continuous Inquiry. An Inquiry uses up about 20% of the available bandwidth. Having the car and the phone doing those constant inquiries causes half of the bandwidth to be jammed which decreases likelyhood of a successful pairing too. Having the pairing handler separated from the "scan for devices" should help too.