Using B2G with the handsfree kit in the 2011 Toyota Sienna (see bug 813845), when I place a call, the call is initiated, the stereo then resumes playing the radio/cd/other music until the phone starts to ring when the audio returns to be the stream for the call. In this situation is appears as though the call was disconnected. In fact, the first time this happened I attempted to dial again. STR 1. Click bluetooth button and say "dial NUMBER" (replacing NUMBER with an actual phone number. 2. Click the bluetooth button and say "confirm". 3. The phone initiates the call. At this point the stereo exits out of the call mode (no longer displays the number) and returns to the radio/cd/other music that had previously been playing. 4. When the phone begins to ring the stereo once again enters the call mode and displays the number along with shutting off the music to use the audio stream from the call. Expected outcome: The car's audio system should stay silent after placing the call before an audible ring is heard. Actual outcome: The car's audio system returns to playing whatever music had been playing in the short time (up to 5 seconds in my tests) between placing a call and initiating the audible ring. The display also shows the radio during this time and does not display the dialed number as is typical when used with Android phones. Note, the manifestation of this bug seems very similar to bug 819849 and bug 815322, both of which are related to the audio policy.
Hi Lawrence, This looks like AT commands (probably call status) affected Toyota stereo system. As you mentioned Music played by stereo system not from phone. So I think it's not related to audio policy. I guess call-status from HFP AT commands screw up, and it leads Toyota stereo system switch to Multimeida mode (CD/DVD/Radio) and switch back again.
Summary: [b2g-bluetooth] Bluetooth handsfree returns to playing radio/music after call is initiated and before dialing/ringing is heard → [Bluetooth] [BT-IOP]Bluetooth handsfree returns to playing radio/music after call is initiated and before dialing/ringing is heard
Shawn, are we expecting car kits to work for v1? I thought we were just doing handsfree kits. Chris?
Andrew, yes, we're expecting car kits to work for v1, since this car kit supports Handsfree profile. bug 828518 is just meta bug for easy tracking any of Bluetooth Handsfree car kit issue. About Bug 828810, I don't think it's bb+ issue unless there are many car kits with same problem. We shall track this issue to improve interoperability with car kits for v1.
Minusing per Shawn's comment 3, thought we'd take a patch. Chris: please renom if you feel otherwise.
blocking-basecamp: ? → -
tracking-b2g18: --- → +
Hi Lawrence, Any chance to get hcidump log? Unfortunately, we don't have this car kit due to Toyota Asia region does not build into. Steps: hcidump logs Step 1. Turn on Bluetooth Step 2. Type "adb shell hcidump --ascii -t > hcidump.txt" in your command line. Step 3. Perform the test procedure After you finished test, you can press Ctrl+C to stop and provide hcidump.txt via: "adb pull hcidump.txt ."
I am happy to help out with an hcidump log. I just tried to run this again but running the command exactly as you provided it above results in the command returning immediately. The log file contains: /system/bin/sh: hcidump: not found which I confirmed by browsing to that location on the phone. Is there some other setup/config that I need to do before running hcidump on my unagi? Note, I am on the stable channel.
Hello, Maybe you took pvt build which removed "hcidump". If you have root permission. I attached hcidump util again. Please do the following: 1. adb remount 2. adb push hcidump /system/bin 3. adb shell chmod 777 /system/bin/hcidump 4. Then previous commands again.
Created attachment 701662 [details] hcidump util binary file Please do the following: 1. adb remount 2. adb push hcidump /system/bin 3. adb shell chmod 777 /system/bin/hcidump
Created attachment 702645 [details] hcidump log file I was able to successfully capture a log, which I have attached in case it is useful in further debugging with this hands-free system. With the 20120114 stable build, I am no longer able to reproduce this issue on my unagi. I think this bug can be resolved as fixed.
I'm marking as resolved fixed as I can no longer reproduce this issue. Please comment if you know of a change that may have fixed this issue.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Which version do you use for capturing logs?
Sorry, I'm not able to comment on based on logs which actually worked. Bug 813845 you mentioned you used 20130108070203 stable build to test. Is it possible to get the log when failed? I have reviewed recent changes and cannot confirm why this issue get resolved. Gina, do you have any comment?
Hello Lawrence, sorry for nagging. Can you help to use 20130108070203 stable build to test for fail case log?
Unfortunately, I was unable to reproduce this issue using an unagi with the 20130104070203 and 20130108070203 stable builds. (I borrowed a phone that was still on the 0104 build and flashed it to the 0108 build.)
You need to log in before you can comment on or make changes to this bug.