1131935 - [Woodduck][BT]The icon of mobile device shows headset icon

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Bluetooth, defect, P2)

Description

[sync-1]

Created an attachment (id=1152680)
 log
 
 PR Reporter:欧阳文丽
  contact:0752-2639312(61312)		
 
  DEFECT DESCRIPTION:
 >The icon of mobile device shows headset icon
 
  REPRODUCING PROCEDURES:
 1.Pair MS with remote devices via BT, unpair with MS from remote devices.
 
 2.Send a file to remote devices.
 
 3.Pop-up pair message, click cancle.
 
 4.Check the icon of remote devices, it shows headset icon -- KO.
 
  EXPECTED BEHAVIOUR:
 >The icon of mobile device should show phone icon.
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:

Comment 1

[sync-1]

Attachment: screenshot

Comment 2

[sync-1]

Attachment: screenshot

Comment 3

[sync-1]

Attachment: screenshot

Comment 4

[sync-1]

Attachment: log

Comment 5

[sync-1]

Attachment: screenshot

Comment 6

[[e-mail], [e-mail]]

Hi reporter, What's the build version you are looking for? Could you provide the info here? TIA.

Comment 7

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

This caused by workaround in Bug 1082454 ([bluetooth] Set audio device type if class of device value has a rendering bit).

It used to workaround for Bug 1071392 - [Woodduck][BT]DUT can't be connected with BT Dialer
BT Dialer's cod is 0x7e0204.

I wondered we really need to workaround for this BT Dialer (in fact, I don't know how they fixed this BT Dialer issue or not).

Please let us know BT Dialer is so important, otherwise we prefer to backout the patch.

Comment 8

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Hi Josh,
Could you help to confirm we still need to handle BT Dialer case (Bug 1071392), I don't have any further information how vendor fix their accessory issue. If we don't need to handle it, i prefer to rollback workaround.

Comment 9

[zhensen.su]

Hi Shawn,

I think BT Dialer is important,but this issue seems doesn's contact with Dialer,I think cause by couldn't get device info,so use default audio icon.

Comment 10

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Hi zhensen.su,
Can you attach snoop log? I need to know that COD of device 'g41vw'.
And what's the COD value of BT Dialer finally? I never receive any update for a while.

You can also give a try remove workaround in Bug 1082454.

Comment 11

[zhensen.su]

Hi Shawn,

Do you means sniffer log under @btmtk?I will try to rollback Bug 1082454,any result,i will update at once.

Comment 12

[zhensen.su]

Hi Shawn,

I have rollback the code,but the issue is still exist.I think it must be can't get device info,because remote device doesn't receive the request.Have you any other scheme to handle it?

Comment 13

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Zhensen,
Can you provide snoop log? And tell me which device in your snoop log with wrong icon.

Comment 14

[zhensen.su]

Hi Shawn,

Where could we get it?I remember snoop is change the path.

Comment 15

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to zhensen.su from comment #14)
> Hi Shawn,
> 
> Where could we get it?I remember snoop is change the path.
I don't know anything about path changed. Path controlled by stack not gecko.

AFAIK, snoop default disabled. You can go to Settings->Developer menu->Bluetooth out in ADB to activate hci snoop log.

Then you can find snoop log from btmtk folder (i'm not sure the latest path).

Comment 16

[zhensen.su]

Hi Shawn,

I know you say what's log,this log MTK have change the path,I need to ask MTK about it.In addition,could you call me,i have other issue need your help.I phone num is :0752-2639130(61130) or mobile num:18050236415.

Thanks！

Comment 17

[zhensen.su]

Hi Shawn,

It delete from paired list if remote reject the request on android,so i think we can also do it.

Thanks!

Comment 18

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to zhensen.su from comment #17)
> Hi Shawn,
> 
> It delete from paired list if remote reject the request on android,so i
> think we can also do it.
> 
> Thanks!

I don't understand what you're talking about.

Comment 19

[zhensen.su]

Hi  Shawn,

Our behavior as below:
1.A paired with B and paired success
2.B unpaired A from paired list.
3.A send a file to B from A's paired list.
4.B will prompt pair and receive request,but B reject this request.
5.In android,B will disappear form A's paired list,so it doesn't have this issue.But in FFOS,B still on A's paired list,i think it can't get B's correct info,so it can't display correct icon in list.
Form that,I think we can do as Android's behavior.

Comment 20

[zhensen.su]

Hi Shawn,

Could we do it?

Comment 21

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to zhensen.su from comment #19)
> Hi  Shawn,
> 
> Our behavior as below:
> 1.A paired with B and paired success
> 2.B unpaired A from paired list.
> 3.A send a file to B from A's paired list.
> 4.B will prompt pair and receive request,but B reject this request.
> 5.In android,B will disappear form A's paired list,so it doesn't have this
> issue.But in FFOS,B still on A's paired list,i think it can't get B's
> correct info,so it can't display correct icon in list.
> Form that,I think we can do as Android's behavior.

I feel a bit lost here as you said the icon is not correct, and it's related to paired list. As far as I know, what showed from paired list is to get paired list device information, and that information is retrieved from stack. Icon mapping is based on CoD value and that value was retrieved while doing discovery.

Comment 22

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Another question:
When you discover the device 'g4iv1w', the icon is correct, and after you did pair/unpair/reject opp request, the icon became incorrect?

Comment 23

[zhensen.su]

Hi Shawn,

Yep.you can do it on your build with my step.And could you take a call to me,I will tell you in details.
My home num is:0752-2639130 (61130)

Comment 24

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

APLog_2015_0205_141905/main_log.1:02-05 14:23:24.153   168   703 I bt_gap_hdl.c: [GAP] btmtk_util_update_device_property_name: name = g4iv1w
APLog_2015_0205_141905/main_log.2:02-05 14:22:40.192   168   703 I bt_gap_hdl.c: [GAP] btmtk_get_remote_device_property name:[g4iv1w]!
APLog_2015_0205_141905/main_log.2:02-05 14:22:49.970   168   703 I bt_gap_hdl.c: [GAP] btmtk_update_remote_properties: addr:[0x101754:0x1:0x2015], name = g4iv1w, cod:[5a020c], devtype:[1]!


02-05 14:22:49.970   168   703 I bt_gap_hdl.c: [GAP] remote initiate pairing
02-05 14:22:49.970   168   703 I bt_gap_api.c: [GAP] btmtk_inquired_dev_cache_add: addr=0x101754:0x1:0x2015
02-05 14:22:49.970   168   703 I bt_gap_api.c: [GAP] btmtk_inquired_dev_cache_add: 1 device inquired
02-05 14:22:49.970   168   703 I bt_gap_hdl.c: [GAP] btmtk_update_remote_properties: addr:[0x101754:0x1:0x2015], name = g4iv1w, cod:[5a020c], devtype:[1]!
02-05 14:22:49.970   168   703 D bt_gap_hdl.c: HAL bt_hal_cbacks->remote_device_properties_cb

COD we got from stack is 5a020c.

Comment 25

[zhensen.su]

Hi Shawn,

What's COD mean?whether get icon code?i think you can try repro in your build,it's easy to repro,if you see the behavior,you will clarify about this issue.

Thanks!

Comment 26

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to Shawn Huang [:shawnjohnjr] from comment #22)
> Another question:
> When you discover the device 'g4iv1w', the icon is correct, and after you
> did pair/unpair/reject opp request, the icon became incorrect?

I actually followed your steps. But I still got correct icon (phone). What are device do you use for device 'A' and 'B'? Are A and B both Firefox OS phone?

Comment 27

[zhensen.su]

Hi Shawn,

A is Firefox OS device,B is Android OS device.It is very easy to repro the issue,I also use mozilla build version to repro,it is the same behavior.

Comment 28

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to zhensen.su from comment #27)
> Hi Shawn,
> 
> A is Firefox OS device,B is Android OS device.It is very easy to repro the
> issue,I also use mozilla build version to repro,it is the same behavior.

I tried the following steps:
A is FirefoxOS woodduck device
B is Android Nexus-5 Android 5.0 or HTC One (M7) Android 4.4.3

1. A paired with B
2. B unpaired device A
3. A send file to B
4. B accept pairing request but reject requests
5. Check device A Settings pairing list, and found 'Nexus 5' icon is 'Phone'.

Comment 29

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to zhensen.su from comment #19)
> Hi  Shawn,
> 
> Our behavior as below:
> 5.In android,B will disappear form A's paired list,so it doesn't have this
> issue.But in FFOS,B still on A's paired list,i think it can't get B's
> correct info,so it can't display correct icon in list.
> Form that,I think we can do as Android's behavior.

B will disappear from A's paired list. This is something else. I remember we've talked about general bonding/dedicated bonding previously in Bug 1119642.

But this issue is related to incorrect icon not sure why we need to consider this.

Comment 30

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Not sure this is 2.0m only. Remove 2.0m only tag.

Comment 31

[Pi Wei Cheng [:piwei] (inactive)]

I'm assuming the qawanted tag is to see if this issue is reproducible. We don't have a Woodduck device at QAnalysts so we can only try it on Flame.

Unable to reproduce this issue on Flame 2.0. What I see was:

A = Flame 2.0
B = Flame 2.0 (base image v18d-1)

1) A paired with B
2) B unpaired A
3) A goes to Gallery app and attempted to share a picture to B via Bluetooth
4) B never got the prompt to pair with A, therefore unable to continue the STR. I can't get A to display B as anything other than a phone device icon either.

Leaving qawanted tag for others to attempt, preferably with a Woodduck device.

A's environmental variables:
Device: Flame 2.0 (shallow flash 319MB)
BuildID: 20150212161454
Gaia: ecb1bbc3b9c00f82df172427f65d6f67e34ed533
Gecko: daa5bb38f519
Version: 32.0 (2.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 32

[zhensen.su]

(In reply to Shawn Huang [:shawnjohnjr] from comment #28)
> (In reply to zhensen.su from comment #27)
> > Hi Shawn,
> > 
> > A is Firefox OS device,B is Android OS device.It is very easy to repro the
> > issue,I also use mozilla build version to repro,it is the same behavior.
> 
> I tried the following steps:
> A is FirefoxOS woodduck device
> B is Android Nexus-5 Android 5.0 or HTC One (M7) Android 4.4.3
> 
> 1. A paired with B
> 2. B unpaired device A
> 3. A send file to B
> 4. B accept pairing request but reject requests
> 5. Check device A Settings pairing list, and found 'Nexus 5' icon is 'Phone'.

Hi Shawn,

From these step,you have do one wrong,In step 4:you need reject pairing request,then form A,you can see B is in A's paired list.I will make a vedio with you.

Thanks!

Comment 33

[zhensen.su]

Hi Shawn,

I have upload the repro vedio in baidu cloud,the path and pwd as follow:
path: http://pan.baidu.com/s/1sjocYUp pwd: buyt

Thanks!

Comment 34

[Paladin]

Reproduce this issue according to video you uploaded, and the STR is as follow.

Device A:Flame 2.0  Device B:Woodduck 2.0
1. B piared A.
2. When successfully paired,Unpair device B from device A.
3. Deveice B Open Gallery and view an image.
4. Tap Share button and select bluetooth.'
5. Tap A's name under Paired devices 
6. Device A tap Cancel button in Bluetooth Request page.
7. Device B tap Pair button in Bluetooth Request page.
8. Device B came back to View image page.
9. Tap Share button again and select Bluetooth.

** The device A name is in B's paired list and there is a headset icon on the Right Side.

If we take Flame 2.0/2.1/2.2 as Device B and Woodduck 2.0 as Device A, this issue can't be reproduced.

Device Info:
Woodduck 2.0 build:
Build ID               20150216050313
Gaia Revision          a1b5959728c8bc2a82354e197bb161922d419866
Gaia Date              2015-02-13 09:00:02
Gecko Revision         917050ccd94ab32278090e3d3fdf33e62096d449
Gecko Version          32.0
Device Name            jrdhz72_w_ff
Firmware(Release)      4.4.2
Firmware(Incremental)  1424034320
Firmware Date          Mon Feb 16 05:05:46 CST 2015
--------------------------
Flame 2.0 build:
Build ID               20150215000240
Gaia Revision          ecb1bbc3b9c00f82df172427f65d6f67e34ed533
Gaia Date              2015-02-11 20:40:33
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/3051696eafcc
Gecko Version          32.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150215.040455
Firmware Date          Sun Feb 15 04:05:06 EST 2015
Bootloader             L1TC000118D0
----------------------------------
Flame 2.1 build:
Build ID               20150215001204
Gaia Revision          e8eba437af02820f74d122aec83b6001df6f89e3
Gaia Date              2015-02-13 05:26:11
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/9d04f9149ca4
Gecko Version          34.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150215.040742
Firmware Date          Sun Feb 15 04:07:53 EST 2015
Bootloader             L1TC000118D0
---------------------------------
Flame 2.2 build:
Build ID               20150215002504
Gaia Revision          ea64caf6d4ab03fc4472eca9f41f20d651d55fa9
Gaia Date              2015-02-13 05:27:43
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/62c80c92b39e
Gecko Version          37.0a2
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150215.040852
Firmware Date          Sun Feb 15 04:09:03 EST 2015
Bootloader             L1TC000118D0

Comment 35

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Thanks a lot for everyone. Now I can reproduce it.

Comment 36

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Please see my analysis. Following the reproduced steps, I found the stack pass invalid paired device properties. I can see error logs showing from bt stack, it said fail to find device cache for address addr=0x5CE719:0xEF:0x34FC.
Later we can see
"02-16 18:33:32.184 I/GeckoBluetooth( 1134): RemoteDevicePropertiesCallback: Name :
02-16 18:33:32.184 I/GeckoBluetooth( 1134): RemoteDevicePropertiesCallback: Remote device, cod: 1165181102"
There is no name, and invalid COD returned. The reason you can see name but wrong icon because at the same time, entering that select bluetooth device page, it will automatically start discovery and the name was updated later. But there are chances, name cannot be queried due to no response.
Zhensen, I think this is related to stack behaviour.


02-16 18:33:32.183 I/bt_gap_hdl.c( 1134): +++[GAP] btmtk_handle_gap_message msg:[EV_BT_CB_READ_REMOTE_PROPERTY_ALL]+++!
02-16 18:33:32.183 I/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find: addr=0x5CE719:0xEF:0x34FC
02-16 18:33:32.183 W/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find not found
02-16 18:33:32.183 I/bt_ext_apis.c( 1134): [JNI] send ind success : 28
02-16 18:33:32.183 I/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find: addr=0x5CE719:0xEF:0x34FC
02-16 18:33:32.183 I/bt_gap_api.c( 1134): [GAP] btmtk_gap_ev_discovery_starting return:1!
02-16 18:33:32.183 W/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find not found
02-16 18:33:32.183 I/bt_ext_apis.c( 1134): btmtk_util_find_profile_msg_handler search profile_id:[22]
02-16 18:33:32.183 I/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find: addr=0x5CE719:0xEF:0x34FC
02-16 18:33:32.184 W/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find not found
02-16 18:33:32.184 I/bt_ext_apis.c( 1134): [JNI] btmtk_sendmsg(cmd=103, ptr=0xbea07b08, len=52)
02-16 18:33:32.184 I/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find: addr=0x5CE719:0xEF:0x34FC
02-16 18:33:32.184 W/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find not found
02-16 18:33:32.184 I/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find: addr=0x5CE719:0xEF:0x34FC
02-16 18:33:32.184 W/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find not found
02-16 18:33:32.184 I/BT_UTILS( 1134): btmtk_util_convert_bdaddr2array: addr=0x5CE719:0xEF:0x34FC
02-16 18:33:32.184 I/BT_UTILS( 1134): btmtk_util_convert_bdaddr2array: addr=0x34:0xFC:0xEF:0x5C:0xE7:0x19
02-16 18:33:32.184 D/bt_gap_hdl.c( 1134): HAL bt_hal_cbacks->remote_device_properties_cb
02-16 18:33:32.184 I/bt_ext_apis.c( 1134): [JNI] send msg success : 52
02-16 18:33:32.184 I/bt_gap_api.c( 1134): [GAP] btmtk_gap_start_discovery return:1!
02-16 18:33:32.184 I/BTIF_CORE( 1134): ---[btif_dm_start_discovery]---!
02-16 18:33:32.184 I/GeckoBluetooth( 1134): RemoteDevicePropertiesCallback: Address: 34:fc:ef:5c:e7:19
02-16 18:33:32.184 I/GeckoBluetooth( 1134): RemoteDevicePropertiesCallback: Name :
02-16 18:33:32.184 I/GeckoBluetooth( 1134): RemoteDevicePropertiesCallback: Remote device, cod: 1165181102

Comment 37

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Since we cannot hit this bug on flame, I think stack owner shall take a look at this.

Comment 38

[Will Wang [:WillWang]]

Hi reporter

additional info for you:
I ever also encountered same issue if the reproduce step 4 (of the comment 28) is changed to timeout(leave it, not reject immediately)

Comment 39

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Hi Josh,
This bug looks like POVB and need partner to check.

Comment 40

[Josh Cheng [:josh]]

Hi Jason,
Could you please help to find someone to check this issue?
Thanks!

Comment 41

[[e-mail]]

hi all,

    any update of this issue?

Comment 42

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to [e-mail] from comment #41)
> hi all,
> 
>     any update of this issue?

We think this is related to bluetooth stack bug. So need to ask [e-mail] for further investigation, see Comment 36, 38.

Comment 43

[zhensen.su]

Hi Shawn,

Who is [e-mail]?MTK or Mozilla?Has any result?

Thanks!

Comment 44

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to zhensen.su from comment #43)
> Hi Shawn,
> 
> Who is [e-mail]?MTK or Mozilla?Has any result?
> 
> Thanks!

MTK. Comment 40, ask someone called Johnson to answer.

Comment 45

[zhensen.su]

Hi Josh,

Jason seems not action,could you help to push it with other way?

Thanks!

Comment 46

[zhensen.su]

Hi Jason，

Could you help to deliver the issue to corresponding engineer track it?

Comment 47

[woodduck]

Hi Dexiang, Please check it. Thanks.

Comment 48

[zhensen.su]

Hi Dexiang,

Has any update?

Comment 49

[dexiang jiang]

(In reply to Shawn Huang [:shawnjohnjr] from comment #36)
> Please see my analysis. Following the reproduced steps, I found the stack
> pass invalid paired device properties. I can see error logs showing from bt
> stack, it said fail to find device cache for address
> addr=0x5CE719:0xEF:0x34FC.
> Later we can see
> "02-16 18:33:32.184 I/GeckoBluetooth( 1134): RemoteDevicePropertiesCallback:
> Name :
> 02-16 18:33:32.184 I/GeckoBluetooth( 1134): RemoteDevicePropertiesCallback:
> Remote device, cod: 1165181102"
> There is no name, and invalid COD returned. The reason you can see name but
> wrong icon because at the same time, entering that select bluetooth device
> page, it will automatically start discovery and the name was updated later.
> But there are chances, name cannot be queried due to no response.
> Zhensen, I think this is related to stack behaviour.
> 
> 
> 02-16 18:33:32.183 I/bt_gap_hdl.c( 1134): +++[GAP] btmtk_handle_gap_message
> msg:[EV_BT_CB_READ_REMOTE_PROPERTY_ALL]+++!
> 02-16 18:33:32.183 I/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find:
> addr=0x5CE719:0xEF:0x34FC
> 02-16 18:33:32.183 W/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find
> not found
> 02-16 18:33:32.183 I/bt_ext_apis.c( 1134): [JNI] send ind success : 28
> 02-16 18:33:32.183 I/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find:
> addr=0x5CE719:0xEF:0x34FC
> 02-16 18:33:32.183 I/bt_gap_api.c( 1134): [GAP]
> btmtk_gap_ev_discovery_starting return:1!
> 02-16 18:33:32.183 W/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find
> not found
> 02-16 18:33:32.183 I/bt_ext_apis.c( 1134):
> btmtk_util_find_profile_msg_handler search profile_id:[22]
> 02-16 18:33:32.183 I/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find:
> addr=0x5CE719:0xEF:0x34FC
> 02-16 18:33:32.184 W/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find
> not found
> 02-16 18:33:32.184 I/bt_ext_apis.c( 1134): [JNI] btmtk_sendmsg(cmd=103,
> ptr=0xbea07b08, len=52)
> 02-16 18:33:32.184 I/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find:
> addr=0x5CE719:0xEF:0x34FC
> 02-16 18:33:32.184 W/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find
> not found
> 02-16 18:33:32.184 I/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find:
> addr=0x5CE719:0xEF:0x34FC
> 02-16 18:33:32.184 W/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find
> not found
> 02-16 18:33:32.184 I/BT_UTILS( 1134): btmtk_util_convert_bdaddr2array:
> addr=0x5CE719:0xEF:0x34FC
> 02-16 18:33:32.184 I/BT_UTILS( 1134): btmtk_util_convert_bdaddr2array:
> addr=0x34:0xFC:0xEF:0x5C:0xE7:0x19
> 02-16 18:33:32.184 D/bt_gap_hdl.c( 1134): HAL
> bt_hal_cbacks->remote_device_properties_cb
> 02-16 18:33:32.184 I/bt_ext_apis.c( 1134): [JNI] send msg success : 52
> 02-16 18:33:32.184 I/bt_gap_api.c( 1134): [GAP] btmtk_gap_start_discovery
> return:1!
> 02-16 18:33:32.184 I/BTIF_CORE( 1134): ---[btif_dm_start_discovery]---!
> 02-16 18:33:32.184 I/GeckoBluetooth( 1134): RemoteDevicePropertiesCallback:
> Address: 34:fc:ef:5c:e7:19
> 02-16 18:33:32.184 I/GeckoBluetooth( 1134): RemoteDevicePropertiesCallback:
> Name :
> 02-16 18:33:32.184 I/GeckoBluetooth( 1134): RemoteDevicePropertiesCallback:
> Remote device, cod: 1165181102

Hi Shawn, could you help to upload you reproduce log?
From you log comments, it seems stack report error cod to upper layer.it's different with tester's log failed case.
Thanks

I had checked the first "log" in upload files.
From Log steps:
1. Local start OPP share and trigger bond(remote uppair) with 0x20:0x15:0x1:0x10:0x17:0x54,
   remote cancal and bond failed, stack will clear this bond record and notifiy upper layer unbond(but     inquiry cache record not clear).
   also disconnect reported. 
02-05 14:22:53.588   168   703 D bt_gap_hdl.c: HAL bt_hal_cbacks->bond_state_changed_cb
02-05 14:22:53.591   168   703 D bt_gap_hdl.c: HAL bt_hal_cbacks->acl_state_changed_cb

2. Upper layer didn't finished bond flow, since stack already report disconnect and unbond, this 
   behavior is right?
   If Upper layer start ssp reply, stack only found inquiry cache and clear it(bond cache already clear at last step), 
02-05 14:23:15.784   168   168 I BTIF_CORE: +++[btif_dm_ssp_reply] addr:[20:15:01:10:17:54]+++!
02-05 14:23:15.786   168   703 D bt_gap_hdl.c: HAL bt_hal_cbacks->bond_state_changed_cb

3. Then upper layer get device properties again, at this point, bond cache and inquiry cahce both cleared, stack return null, this will cause UI shows "headset" icon with default COD?

02-05 14:23:21.921   168   168 I BTIF_CORE: ---[btif_get_remote_device_properties]---!
02-05 14:23:21.921   168   168 I BTIF_CORE: +++[btif_get_remote_device_properties] addr:[20:15:01:10:17:54]+++!
02-05 14:23:21.921   168   703 W bt_gap_api.c: [GAP] btmtk_paired_dev_cache_find not found
02-05 14:23:21.921   168   703 D bt_gap_hdl.c: HAL bt_hal_cbacks->remote_device_properties_cb

4. After start inquiry again, stack report foiund cod(0x5a020c / 5898764), but no upper layer log, i'm not sure upper's cod update correctly or not.
02-05 14:23:24.153   168   703 I bt_gap_hdl.c: [GAP] MSG_ID_BT_BM_DISCOVERY_RESULT_IND addr:[0x101754:0x1:0x2015]
02-05 14:23:24.153   168   703 D bt_gap_hdl.c: HAL bt_hal_cbacks->device_found_cb

Thanks

Comment 50

[zhensen.su]

Hi Shawn,

Do you think we need clear remote device form list after remote cancel and bond failed?

Thanks!

Comment 51

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to dexiang jiang from comment #49)
> (In reply to Shawn Huang [:shawnjohnjr] from comment #36)
> > Please see my analysis. Following the reproduced steps, I found the stack
> > pass invalid paired device properties. I can see error logs showing from bt
> > stack, it said fail to find device cache for address
> > addr=0x5CE719:0xEF:0x34FC.
> > Later we can see
> > "02-16 18:33:32.184 I/GeckoBluetooth( 1134): RemoteDevicePropertiesCallback:
> > Name :
> > 02-16 18:33:32.184 I/GeckoBluetooth( 1134): RemoteDevicePropertiesCallback:
> > Remote device, cod: 1165181102"
> > There is no name, and invalid COD returned. The reason you can see name but
> > wrong icon because at the same time, entering that select bluetooth device
> > page, it will automatically start discovery and the name was updated later.
> > But there are chances, name cannot be queried due to no response.
> > Zhensen, I think this is related to stack behaviour.
> > 
> > 
> > 02-16 18:33:32.183 I/bt_gap_hdl.c( 1134): +++[GAP] btmtk_handle_gap_message
> > msg:[EV_BT_CB_READ_REMOTE_PROPERTY_ALL]+++!
> > 02-16 18:33:32.183 I/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find:
> > addr=0x5CE719:0xEF:0x34FC
> > 02-16 18:33:32.183 W/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find
> > not found
> > 02-16 18:33:32.183 I/bt_ext_apis.c( 1134): [JNI] send ind success : 28
> > 02-16 18:33:32.183 I/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find:
> > addr=0x5CE719:0xEF:0x34FC
> > 02-16 18:33:32.183 I/bt_gap_api.c( 1134): [GAP]
> > btmtk_gap_ev_discovery_starting return:1!
> > 02-16 18:33:32.183 W/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find
> > not found
> > 02-16 18:33:32.183 I/bt_ext_apis.c( 1134):
> > btmtk_util_find_profile_msg_handler search profile_id:[22]
> > 02-16 18:33:32.183 I/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find:
> > addr=0x5CE719:0xEF:0x34FC
> > 02-16 18:33:32.184 W/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find
> > not found
> > 02-16 18:33:32.184 I/bt_ext_apis.c( 1134): [JNI] btmtk_sendmsg(cmd=103,
> > ptr=0xbea07b08, len=52)
> > 02-16 18:33:32.184 I/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find:
> > addr=0x5CE719:0xEF:0x34FC
> > 02-16 18:33:32.184 W/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find
> > not found
> > 02-16 18:33:32.184 I/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find:
> > addr=0x5CE719:0xEF:0x34FC
> > 02-16 18:33:32.184 W/bt_gap_api.c( 1134): [GAP] btmtk_paired_dev_cache_find
> > not found
> > 02-16 18:33:32.184 I/BT_UTILS( 1134): btmtk_util_convert_bdaddr2array:
> > addr=0x5CE719:0xEF:0x34FC
> > 02-16 18:33:32.184 I/BT_UTILS( 1134): btmtk_util_convert_bdaddr2array:
> > addr=0x34:0xFC:0xEF:0x5C:0xE7:0x19
> > 02-16 18:33:32.184 D/bt_gap_hdl.c( 1134): HAL
> > bt_hal_cbacks->remote_device_properties_cb
> > 02-16 18:33:32.184 I/bt_ext_apis.c( 1134): [JNI] send msg success : 52
> > 02-16 18:33:32.184 I/bt_gap_api.c( 1134): [GAP] btmtk_gap_start_discovery
> > return:1!
> > 02-16 18:33:32.184 I/BTIF_CORE( 1134): ---[btif_dm_start_discovery]---!
> > 02-16 18:33:32.184 I/GeckoBluetooth( 1134): RemoteDevicePropertiesCallback:
> > Address: 34:fc:ef:5c:e7:19
> > 02-16 18:33:32.184 I/GeckoBluetooth( 1134): RemoteDevicePropertiesCallback:
> > Name :
> > 02-16 18:33:32.184 I/GeckoBluetooth( 1134): RemoteDevicePropertiesCallback:
> > Remote device, cod: 1165181102
> 
> Hi Shawn, could you help to upload you reproduce log?
> From you log comments, it seems stack report error cod to upper layer.it's
> different with tester's log failed case.
> Thanks
> 
> I had checked the first "log" in upload files.
> From Log steps:
> 1. Local start OPP share and trigger bond(remote uppair) with
> 0x20:0x15:0x1:0x10:0x17:0x54,
>    remote cancal and bond failed, stack will clear this bond record and
> notifiy upper layer unbond(but     inquiry cache record not clear).
>    also disconnect reported. 
> 02-05 14:22:53.588   168   703 D bt_gap_hdl.c: HAL
> bt_hal_cbacks->bond_state_changed_cb
> 02-05 14:22:53.591   168   703 D bt_gap_hdl.c: HAL
> bt_hal_cbacks->acl_state_changed_cb
> 
> 2. Upper layer didn't finished bond flow, since stack already report
> disconnect and unbond, this 
>    behavior is right?
>    If Upper layer start ssp reply, stack only found inquiry cache and clear
> it(bond cache already clear at last step), 
> 02-05 14:23:15.784   168   168 I BTIF_CORE: +++[btif_dm_ssp_reply]
> addr:[20:15:01:10:17:54]+++!
> 02-05 14:23:15.786   168   703 D bt_gap_hdl.c: HAL
> bt_hal_cbacks->bond_state_changed_cb
> 
> 3. Then upper layer get device properties again, at this point, bond cache
> and inquiry cahce both cleared, stack return null, this will cause UI shows
> "headset" icon with default COD?
> 
> 02-05 14:23:21.921   168   168 I BTIF_CORE:
> ---[btif_get_remote_device_properties]---!
> 02-05 14:23:21.921   168   168 I BTIF_CORE:
> +++[btif_get_remote_device_properties] addr:[20:15:01:10:17:54]+++!
> 02-05 14:23:21.921   168   703 W bt_gap_api.c: [GAP]
> btmtk_paired_dev_cache_find not found
> 02-05 14:23:21.921   168   703 D bt_gap_hdl.c: HAL
> bt_hal_cbacks->remote_device_properties_cb
> 
> 4. After start inquiry again, stack report foiund cod(0x5a020c / 5898764),
> but no upper layer log, i'm not sure upper's cod update correctly or not.
> 02-05 14:23:24.153   168   703 I bt_gap_hdl.c: [GAP]
> MSG_ID_BT_BM_DISCOVERY_RESULT_IND addr:[0x101754:0x1:0x2015]
> 02-05 14:23:24.153   168   703 D bt_gap_hdl.c: HAL
> bt_hal_cbacks->device_found_cb
> 
> Thanks

Device A:Flame 2.0  Device B:Woodduck 2.0
1. B piared A.
2. When successfully paired,Unpair device B from device A.
3. Deveice B Open Gallery and view an image.
4. Tap Share button and select bluetooth.'
5. Tap A's name under Paired devices 
6. Device A tap Cancel button in Bluetooth Request page.
7. Device B tap Pair button in Bluetooth Request page.
8. Device B came back to View image page.
9. Tap Share button again and select Bluetooth.

I think if the stack's behavior is to clear cache when the remote device deleted link key. The stack shall not list the remote device in the paired device. Do you agree this point?
Upper layer will query paired devices again when entering Bluetooth Settings.

We shall not base on an another inquiry again, this new inquiry was made due to another discovery when entering 'Selecting target device' UI page. What if the remote device is already disabled discoverable? You can get the latest update.

Comment 52

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Transfer this bug to Will for clarification.

Comment 53

[dexiang jiang]

Hi Shawn,

Stack will clear this paired cached due to remote cancel pairing and authentication failed.
the linkey is invalid then stack clear it.(The stack shall not list the remote device in the paired device => current stack behavior)
6. Device A tap Cancel button in Bluetooth Request page.

Even stack clear paird device cache at step6, stack also has inquiry cache, But if step7 happend, it will clear stack inquiry cache. step7 call ssp_reply is right bevior(disconnect reported)?
7. Device B tap Pair button in Bluetooth Request page.

Stack had reported unbond to uppler, upper layer need update device state, upper layer shold do inquiry again.

Thanks

Comment 54

[zhensen.su]

Hi Shawn,

What do you think about dexiang says?

Comment 55

[Wesly Huang (EPM)]

Hi Will:

As just discussed, would you help check and follow? This is one of the left issues in the list for the SW to be released on Wednesday. Thank you!

Comment 56

[Will Wang [:WillWang]]

I am currently trying to check the items in comment 53, 
some log points are identified and I will update asap.

Comment 57

[Will Wang [:WillWang]]

Attachment: ww-cod-icon.log

Hi Dexiang

(In reply to dexiang jiang from comment #53)
> Hi Shawn,
> 
> Stack will clear this paired cached due to remote cancel pairing and
> authentication failed.
> the linkey is invalid then stack clear it.(The stack shall not list the
> remote device in the paired device => current stack behavior)

For your reply above, we found log (as attachment)shows that, when the issue occurs(wrong icon), current stack behavior still didn't clear the paired remote device(unpaired in fact) in the end,
therefore this result in gecko think the device is still paired

15851 03-19 20:41:24.967 I/GeckoBluetooth(10206): SetPropertyByValue: wwww----------------------------------------------- paired device = listing mDeviceAddresses...have [1] device
15852 03-19 20:41:24.967 I/GeckoBluetooth(10206): SetPropertyByValue: wwww- mDeviceAddresses[0]: [d8:e5:6d:1b:ff:6d]

May you help to comment for this?
thanks!


> 6. Device A tap Cancel button in Bluetooth Request page.
> 
> Even stack clear paird device cache at step6, stack also has inquiry cache,
> But if step7 happend, it will clear stack inquiry cache. step7 call
> ssp_reply is right bevior(disconnect reported)?
> 7. Device B tap Pair button in Bluetooth Request page.
> 
> Stack had reported unbond to uppler, upper layer need update device state,
> upper layer shold do inquiry again.
> 
> Thanks

Comment 58

[dexiang jiang]

Hi Will,

From you comments #57, based on(ww-cod-icon.log):

1. Current OPP bond device is [0x1BFF6D:0x6D:0xD8E5], after remote cancel pairing, local stack clear its paird cache and callback unbond to upper layer; 
03-19 20:41:08.702 I/bt_gap_hdl.c( 9819): [GAP] MSG_ID_BT_BM_BONDING_RESULT_IND addr:[0x1BFF6D:0x6D:0xD8E5], result=1, cod:[0], devtype:[1]
03-19 20:41:08.702 I/bt_gap_api.c( 9819): [GAP] btmtk_paired_dev_cache_del: addr=0x1BFF6D:6D:D8E5
03-19 20:41:08.702 D/bt_gap_hdl.c( 9819): HAL bt_hal_cbacks->bond_state_changed_cb

2. You comments is "gecko think the device is still paired", but stack had already reported unbond with "AUTH FAIL" reason at 20:41:08.702.
15852 03-19 20:41:24.967 I/GeckoBluetooth(10206): SetPropertyByValue: wwww- mDeviceAddresses[0]: [d8:e5:6d:1b:ff:6d]

Please help to double confirm it, thanks a lot.

Comment 59

[Will Wang [:WillWang]]

Hi Dexiang


(In reply to dexiang jiang from comment #58)
> Hi Will,
> 
> From you comments #57, based on(ww-cod-icon.log):
> 
> 1. Current OPP bond device is [0x1BFF6D:0x6D:0xD8E5], after remote cancel
> pairing, local stack clear its paird cache and callback unbond to upper
> layer; 
> 03-19 20:41:08.702 I/bt_gap_hdl.c( 9819): [GAP]
> MSG_ID_BT_BM_BONDING_RESULT_IND addr:[0x1BFF6D:0x6D:0xD8E5], result=1,
> cod:[0], devtype:[1]
> 03-19 20:41:08.702 I/bt_gap_api.c( 9819): [GAP] btmtk_paired_dev_cache_del:
> addr=0x1BFF6D:6D:D8E5
> 03-19 20:41:08.702 D/bt_gap_hdl.c( 9819): HAL
> bt_hal_cbacks->bond_state_changed_cb
> 
> 2. You comments is "gecko think the device is still paired", but stack had
> already reported unbond with "AUTH FAIL" reason at 20:41:08.702.
> 15852 03-19 20:41:24.967 I/GeckoBluetooth(10206): SetPropertyByValue: wwww-
> mDeviceAddresses[0]: [d8:e5:6d:1b:ff:6d]
> 
> Please help to double confirm it, thanks a lot.

thanks for your comment,

In my opinion, our question is still about the out-dated paired device info from stack

from above log you mentioned, we are still confused, why "local stack clear its paird cache" in advance(20:41:08.702),
and found unbond already,
but stack still use callback function to report one device paired after many seconds(20:41:24.967),
that's why gecko think one device paired

Gecko will get the latest paired devices info from stack's callback function, and will not maintain another redundant and possibly un-sync info in itself. This is currently working well for all other bluetooth stacks, or you can suggest us to do more process if you consider needed for mtk stack,

thanks!

Comment 60

[dexiang jiang]

Hi Will,

"
but stack still use callback function to report one device paired after many seconds(20:41:24.967),
that's why gecko think one device paired
"
Could you help me to point out this case in logs, i didn't found stack callback one device paired around (20:41:24.967).
Thanks a lot.

Comment 61

[Will Wang [:WillWang]]

Attachment: ww-run.0324-2.log

(In reply to dexiang jiang from comment #60)
> Hi Will,
> 
> "
> but stack still use callback function to report one device paired after many
> seconds(20:41:24.967),
> that's why gecko think one device paired
> "
> Could you help me to point out this case in logs, i didn't found stack
> callback one device paired around (20:41:24.967).
> Thanks a lot.

Hi Dexiang

FYI,
Once stack use callback function to report every paired devices update, then gecko will get a notification and always use function |SetPropertyByValue| to print latest paired devices(mDeviceAddresses), such as following log:

I/GeckoBluetooth(10206): SetPropertyByValue: wwww----------------------------------------------- paired device = listing mDeviceAddresses...have [1] device


(You can find that mDeviceAddresses still have one device paired after unbond)

However, same as your observation, it seems that stack (for some reasons) does not print out every callback function when reporting paired devices update, while gecko actually did it as above

To locate corresponding callback function in mtk stack more precisely, in my opinion mtk better enable more callback log if possible, however, to speedup issue resolving, I also collected a full reproduced log (as attachment) which every stack callback in gecko will print "stack callback called" for your information.

Comment 62

[dexiang jiang]

Hi will,

I still has some confused that stack will print all callback log in currect solution, could you help to share which callback will cause upper layer print this log?

03-24 21:50:04.024 D/bt_gap_hdl.c(12864): HAL bt_hal_cbacks->acl_state_changed_cb
03-24 21:50:04.847 D/bt_gap_hdl.c(12864): HAL bt_hal_cbacks->remote_device_properties_cb
03-24 21:50:04.848 D/bt_gap_hdl.c(12864): HAL bt_hal_cbacks->bond_state_changed_cb //bonding
03-24 21:50:04.848 D/bt_gap_hdl.c(12864): HAL bt_hal_cbacks->ssp_request_cb
03-24 21:50:11.066 D/bt_gap_hdl.c(12864): HAL bt_hal_cbacks->bond_state_changed_cb //unbond
03-24 21:50:11.239 D/bt_gap_hdl.c(12864): HAL bt_hal_cbacks->acl_state_changed_cb  //disconnect
// there are no callbacks under this gap
I/GeckoBluetooth(10206): SetPropertyByValue: wwww----------------------------------------------- paired device = listing mDeviceAddresses...have [1] device
03-24 21:50:16.647 D/bt_gap_hdl.c(12864): HAL bt_hal_cbacks->remote_device_properties_cb

Thanks

Comment 63

[dexiang jiang]

Hi Will,

Another point, each stack callback=>upper layer will both print related log, such as:
RemoteDevicePropertiesCallback: wwww- stack callback called.

Thanks

Comment 64

[Will Wang [:WillWang]]

Attachment: 1131935-WIP-patch-0325.diff

Hi Dexiang

It seems that mtk stack print all callback log, sorry for making confusion!

May you help to confirm one thing:
Is there any mtk callback function can provide current full paired devices info?
In my current observation, stack seems not have one and gecko did some processes to fit this design,
If gecko can get current full paired devices info from stack once needed, many potential issue may avoid

However, before confirming above, we have made a quickly WIP patch (as attachment) which can fix this issue,
you can take this for further verification, and I will provide a refined patch later on

thanks a lot!

Comment 65

[Will Wang [:WillWang]]

Attachment: 1131935-WIP-patch-0326.diff

Hi Zhensen

For your test, please use this attached WIP patch which many non-related (even sensitive) logs are removed, 
and I will provide another refined patch later

thanks!

Comment 66

[[e-mail]]

(In reply to Will Wang [:WillWang] from comment #65)
> Created attachment 8583639 [details] [diff] [review]
> 1131935-WIP-patch-0326.diff
> 
> Hi Zhensen
> 
> For your test, please use this attached WIP patch which many non-related
> (even sensitive) logs are removed, 
> and I will provide another refined patch later
> 
> thanks!

I have test this patch.It works Ok.

Comment 67

[dexiang jiang]

(In reply to Will Wang [:WillWang] from comment #64)
> Created attachment 8583037 [details] [diff] [review]
> 1131935-WIP-patch-0325.diff
> 
> Hi Dexiang
> 
> It seems that mtk stack print all callback log, sorry for making confusion!
> 
> May you help to confirm one thing:
> Is there any mtk callback function can provide current full paired devices
> info?
> In my current observation, stack seems not have one and gecko did some
> processes to fit this design,
> If gecko can get current full paired devices info from stack once needed,
> many potential issue may avoid
> 
> However, before confirming above, we have made a quickly WIP patch (as
> attachment) which can fix this issue,
> you can take this for further verification, and I will provide a refined
> patch later on
> 
> thanks a lot!

Hi Will, 
MTK stack interface follow google default interface, each callback triggered by specified actions, such as discovery/service search/bond..., if upper later has requirments, we can do further discussions. 
Thanks

Comment 68

[Will Wang [:WillWang]]

Attachment: 1131935-The-icon-of-mobile-device-shows-headset-icon.patch

Hi Shawn

Per discussion, may you help to review this refined patch?

thanks!

Comment 69

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Comment on attachment 8584434 [details] [diff] [review]
1131935-The-icon-of-mobile-device-shows-headset-icon.patch

Review of attachment 8584434 [details] [diff] [review]:
-----------------------------------------------------------------

nit: Please fix your "if" coding style.

Comment 70

[sync-1]

Hi wei.deng,
 
 该问题已解，请帮忙close。
 
 Thanks！

Comment 71

[Will Wang [:WillWang]]

Attachment: 1131935-The-icon-of-mobile-device-shows-headset-icon-v2.patch

Hi Shawn

May you help to review this style refined patch?

thanks!

Comment 72

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to sync-1 from comment #70)
> Hi wei.deng,
>  
>  该问题已解，请帮忙close。
>  
>  Thanks！

Per Comment 70, we will land for v2.0m.

Comment 73

[Will Wang [:WillWang]]

Attachment: Bug 1131935 - remove cached paired device once Bond state was changed to BT_STATUS_AUTH_FAILURE, r=shuang

Attachment is the same patch of hg version.

Comment 74

[Josh Cheng [:josh]]

Hi Kai-Zhen,
Could you help to land this on 2.0M? Thanks!

Comment 75

[Kai-Zhen Li [:seinlin][:kli]]

https://hg.mozilla.org/releases/mozilla-b2g32_v2_0m/rev/e5ffcbd115cd