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

RESOLVED FIXED in Firefox OS v2.0M

Status

Firefox OS
Bluetooth
P2
normal
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: sync-1, Assigned: WillWang)

Tracking

(Blocks: 1 bug)

unspecified
2.2 S9 (3apr)

Firefox Tracking Flags

(blocking-b2g:2.0M+, b2g-v2.0 unaffected, b2g-v2.0M fixed, b2g-v2.1 unaffected, b2g-v2.1S unaffected, b2g-v2.2 unaffected, b2g-master unaffected)

Details

(Whiteboard: [2.0m_Only][blueangel])

Attachments

(8 attachments, 4 obsolete attachments)

(Reporter)

Description

3 years ago
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:
(Reporter)

Comment 1

3 years ago
Created attachment 8562602 [details]
screenshot
(Reporter)

Comment 2

3 years ago
Created attachment 8562603 [details]
screenshot
(Reporter)

Comment 3

3 years ago
Created attachment 8562604 [details]
screenshot
(Reporter)

Comment 4

3 years ago
Created attachment 8562609 [details]
log
(Reporter)

Comment 5

3 years ago
Created attachment 8562610 [details]
screenshot
Hi reporter, What's the build version you are looking for? Could you provide the info here? TIA.
Flags: needinfo?(sync-1)
Component: Gaia::Bluetooth File Transfer → Bluetooth
Assignee: nobody → shuang
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.
Summary: [BT]The icon of mobile device shows headset icon → [BT][2.0m]The icon of mobile device shows headset icon
Summary: [BT][2.0m]The icon of mobile device shows headset icon → [BT][2.0m only]The icon of mobile device shows headset icon
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.
Flags: needinfo?(jocheng)

Comment 9

3 years ago
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.
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

3 years ago
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

3 years ago
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?
Zhensen,
Can you provide snoop log? And tell me which device in your snoop log with wrong icon.
Flags: needinfo?(zhensen.su.hz)

Comment 14

3 years ago
Hi Shawn,

Where could we get it?I remember snoop is change the path.
Flags: needinfo?(zhensen.su.hz)
(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

3 years ago
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

3 years ago
Hi Shawn,

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

Thanks!
Flags: needinfo?(shuang)
(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.
Flags: needinfo?(shuang)

Comment 19

3 years ago
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.
Flags: needinfo?(shuang)

Comment 20

3 years ago
Hi Shawn,

Could we do it?
(Assignee)

Updated

3 years ago
Flags: needinfo?(wiwang)
(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.
Flags: needinfo?(shuang)
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

3 years ago
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)
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

3 years ago
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!
(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

3 years ago
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.
(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'.
(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.
Not sure this is 2.0m only. Remove 2.0m only tag.
Summary: [BT][2.0m only]The icon of mobile device shows headset icon → [BT]The icon of mobile device shows headset icon
Keywords: qawanted
Flags: needinfo?(sync-1)
Flags: needinfo?(jocheng)
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
Flags: needinfo?(ktucker)
Flags: needinfo?(ktucker)

Comment 32

3 years ago
(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

3 years ago
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

3 years ago
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
status-b2g-v2.0: --- → unaffected
status-b2g-v2.0M: --- → affected
status-b2g-v2.1: --- → unaffected
status-b2g-v2.2: --- → unaffected

Updated

3 years ago
Keywords: qawanted
Thanks a lot for everyone. Now I can reproduce it.
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
Flags: needinfo?(zhensen.su.hz)
Since we cannot hit this bug on flame, I think stack owner shall take a look at this.
(Assignee)

Comment 38

3 years ago
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)
Whiteboard: [POVB]
Hi Josh,
This bug looks like POVB and need partner to check.
Flags: needinfo?(jocheng)

Comment 40

3 years ago
Hi Jason,
Could you please help to find someone to check this issue?
Thanks!
Flags: needinfo?(zhensen.su.hz)
Flags: needinfo?(wudduc)
Flags: needinfo?(jocheng)

Updated

3 years ago
Blocks: 1054172
Summary: [BT]The icon of mobile device shows headset icon → [Woodduck][BT]The icon of mobile device shows headset icon
(Assignee)

Updated

3 years ago
Flags: needinfo?(wiwang)
hi all,

    any update of this issue?
(In reply to jiabin.zheng@tcl.com from comment #41)
> hi all,
> 
>     any update of this issue?

We think this is related to bluetooth stack bug. So need to ask wudduc@gmail.com for further investigation, see Comment 36, 38.

Comment 43

3 years ago
Hi Shawn,

Who is wudduc@gmail.com?MTK or Mozilla?Has any result?

Thanks!
Flags: needinfo?(shuang)
(In reply to zhensen.su from comment #43)
> Hi Shawn,
> 
> Who is wudduc@gmail.com?MTK or Mozilla?Has any result?
> 
> Thanks!

MTK. Comment 40, ask someone called Johnson to answer.
Flags: needinfo?(shuang)

Comment 45

3 years ago
Hi Josh,

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

Thanks!
Flags: needinfo?(jocheng)

Updated

3 years ago
Flags: needinfo?(chien-hao.li)

Comment 46

3 years ago
Hi Jason,

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

Comment 47

3 years ago
Hi Dexiang, Please check it. Thanks.
Flags: needinfo?(wudduc)
Flags: needinfo?(dexiang.jiang)
Flags: needinfo?(chien-hao.li)

Comment 48

3 years ago
Hi Dexiang,

Has any update?

Comment 49

3 years ago
(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
Flags: needinfo?(dexiang.jiang)

Comment 50

3 years ago
Hi Shawn,

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

Thanks!
Flags: needinfo?(shuang)
(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.
Flags: needinfo?(shuang)
Transfer this bug to Will for clarification.
Assignee: shuang → wiwang

Comment 53

3 years ago
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

Updated

3 years ago
Flags: needinfo?(shuang)

Comment 54

3 years ago
Hi Shawn,

What do you think about dexiang says?
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!
Flags: needinfo?(wiwang)
(Assignee)

Comment 56

3 years ago
I am currently trying to check the items in comment 53, 
some log points are identified and I will update asap.
Flags: needinfo?(wiwang)
(Assignee)

Comment 57

3 years ago
Created attachment 8580052 [details]
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

Updated

3 years ago
Flags: needinfo?(dexiang.jiang)

Comment 58

3 years ago
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.
Flags: needinfo?(dexiang.jiang)

Updated

3 years ago
Flags: needinfo?(wiwang)
(Assignee)

Comment 59

3 years ago
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!
Flags: needinfo?(wiwang)

Updated

3 years ago
Flags: needinfo?(jocheng) → needinfo?(dexiang.jiang)

Updated

3 years ago
status-b2g-v2.1S: --- → unaffected
status-b2g-master: --- → unaffected

Comment 60

3 years ago
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.
Flags: needinfo?(dexiang.jiang)
(Assignee)

Comment 61

3 years ago
Created attachment 8582402 [details]
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.
(Assignee)

Updated

3 years ago
Flags: needinfo?(dexiang.jiang)

Comment 62

3 years ago
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
Flags: needinfo?(dexiang.jiang)

Comment 63

3 years ago
Hi Will,

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

Thanks
(Assignee)

Comment 64

3 years ago
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!
(Assignee)

Comment 65

3 years ago
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!
Attachment #8583037 - Attachment is obsolete: true
Flags: needinfo?(sync-1)

Updated

3 years ago
Flags: needinfo?(shuang) → needinfo?(zhensen.su.hz)
(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.
Flags: needinfo?(zhensen.su.hz)
Flags: needinfo?(sync-1)

Comment 67

3 years ago
(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
(Assignee)

Comment 68

3 years ago
Created attachment 8584434 [details] [diff] [review]
1131935-The-icon-of-mobile-device-shows-headset-icon.patch

Hi Shawn

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

thanks!
Attachment #8583639 - Attachment is obsolete: true
Attachment #8584434 - Flags: review?(shuang)
Attachment #8584434 - Flags: review?(shuang) → review+
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.
(Reporter)

Comment 70

3 years ago
Hi wei.deng,
 
 该问题已解,请帮忙close。
 
 Thanks!
Whiteboard: [POVB] → [2.0m_Only][blueangel]
(Assignee)

Comment 71

3 years ago
Created attachment 8585396 [details] [diff] [review]
1131935-The-icon-of-mobile-device-shows-headset-icon-v2.patch

Hi Shawn

May you help to review this style refined patch?

thanks!
Attachment #8584434 - Attachment is obsolete: true
Attachment #8585396 - Flags: review?(shuang)
Attachment #8585396 - Flags: review?(shuang) → review+
blocking-b2g: --- → 2.0M?
(In reply to sync-1 from comment #70)
> Hi wei.deng,
>  
>  该问题已解,请帮忙close。
>  
>  Thanks!

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

Updated

3 years ago
blocking-b2g: 2.0M? → 2.0M+
(Assignee)

Comment 73

3 years ago
Created attachment 8585437 [details] [diff] [review]
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.
Attachment #8585437 - Attachment description: 0001-Bug-1131935-remove-cached-paired-device-once-Bond-st.patch → Bug 1131935 - remove cached paired device once Bond state was changed to BT_STATUS_AUTH_FAILURE, r=shuang
Attachment #8585396 - Attachment is obsolete: true

Comment 74

3 years ago
Hi Kai-Zhen,
Could you help to land this on 2.0M? Thanks!
Flags: needinfo?(kli)
https://hg.mozilla.org/releases/mozilla-b2g32_v2_0m/rev/e5ffcbd115cd
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: needinfo?(kli)
Resolution: --- → FIXED
status-b2g-v2.0M: affected → fixed
Target Milestone: --- → 2.2 S9 (3apr)
You need to log in before you can comment on or make changes to this bug.