It seems to me that when you’re using an app on the phone, the HF or A2DP BT profiles are connected to the HA. When you switch to using the app in the car, it’s going to use the car audio resources, making the assumption that you’re in the car you want to use the car audio resources rather than your headphones.
If you think about it, the average BT headphone user is not allowed to use their headphones in the car. It may be different with using a BT one-eared headset, but the audio assumption in a mapping program is that it’s going through the standard audio which would be A2DP in BT which would mean a 2-ear headphone which would be illegal to use in the car.
I sincerely don’t think it’s a limitation of BT; the app or the system could decide to use whatever audio routing it wanted, assuming it had the OS resources to make that decision. But most designers don’t want to screw around with considering the extra use cases and extra GUI issues to support this.
All the apps that I’ve seen use the default audio connection when running on the phone, and use the car audio when running in/with the car.
The one exception I’ve seen is my Android Phone app for phone calls. Once you’re in a call it lets you select manually between BT car, BT headset (or HA as the case may be), handset, or phone speakerphone.
So I agree with mwsumner: working as designed. It’s too bad they don’t have more options. The options may have been available (since the Android Phone app can do it), but the developers just didn’t want to go to that level of effort, largely IMO because the only use case they could envision would have been illegal (2-ear headphone).
