Hi corntin,

We can't pass the discovery case of 
BluetoothDiscoverDevicesSuccessCallback_ondevicedisappeared.

The root reason should be the discovery event of " ondevicedisappeared" isn't 
implemented.

Therefore, can you help check it and implement it?

So that we can pass BluetoothDiscoverDevicesSuccessCallback_ondevicedisappeared.

Best Regards
Zheng Wu

>-----Original Message-----
>From: Dev [mailto:[email protected]] On Behalf Of Zheng, Wu
>Sent: Thursday, August 14, 2014 5:10 PM
>To: [email protected]
>Cc: [email protected]; Jia, Pei P
>Subject: Re: [Dev] FW: some issues in the process of TCT Bluetooth testing
>
>Hi Corentin,
>
>We test some sockets cases.
>
>Some issues exits in recordHandler.unregister();
>
>Please check the following cases.
>
>1. BluetoothServiceHandler_unregister_unregisterServiceRecord
>2. BluetoothServiceHandler_unregister_with_errorCallback
>3. BluetoothServiceHandler_unregister_with_successCallback
>
>It can't pass.
>
>The root reason is that after invoking bt_socket_destroy_rfcomm,
>socket_connected_map_[socket] != false.(in bluetooth_instance_capi.cc)
>
>It results in that no response for recordHandler.unregister();
>
>Can you check the above three test cases? Thanks.
>
>Best Regards
>Zheng Wu
>
>-----Original Message-----
>From: Dev [mailto:[email protected]] On Behalf Of Zheng, Wu
>Sent: Tuesday, August 12, 2014 5:25 PM
>To: [email protected]
>Cc: [email protected]; Jia, Pei P
>Subject: Re: [Dev] FW: some issues in the process of TCT Bluetooth testing
>
>HI corentin,
>
>We are testing them.
>
>Later we will give you some response.
>
>Best Regards
>Zheng Wu
>
>-----Original Message-----
>From: [email protected]
>[mailto:[email protected]]
>Sent: Tuesday, August 12, 2014 5:16 PM
>To: Zheng, Wu
>Cc: [email protected]; Xu, Martin; Jia, Pei P; Le Foll, Dominique
>Subject: Re: FW: some issues in the process of TCT Bluetooth testing
>
>Hi Zheng Wu,
>
>Thanks for your feedback on bluetooth classes. I will fix that asap.
>
>Btw, I'm not able to make rfcomm socket work. Is this feature available or
>not ?
>
>Best regards,
>Corentin
>
>
>On 08/12/2014 10:19 AM, Zheng, Wu wrote:
>> Hi corentin,
>>
>> Please check the cases of BluetoothDevice_isConnected_attribute :139
>line and BluetoothDevice_uuid_attribute +163 line.
>>
>> The issues are the same with BluetoothClass.
>>
>> Please fix them. Thanks.
>>
>> Best Regards
>> Zheng Wu
>>
>>> -----Original Message-----
>>> From: Zheng, Wu
>>> Sent: Tuesday, August 12, 2014 3:25 PM
>>> To: '[email protected]'
>>> Cc: '[email protected]'; Xu, Martin; Jia, Pei P; Le Foll, Dominique
>>> Subject: some issues in the process of TCT Bluetooth testing
>>>
>>> Hi Corentin,
>>>
>>> Do you come back for Bluetooth tasks today? Welcome back.
>>>
>>> We still are testing Bluetooth TCT testing.
>>>
>>> We are using
>>> https://review.tizen.org/git/?p=platform/framework/web/tizen-extensio
>>> ns- crosswalk.git;a=shortlog;h=refs/heads/sandbox/clecouve/tizen to
>>> test.
>>>
>>> Some issues are related with tizen-extensions-crosswalk and please
>>> check them.
>>>
>>> 1. BluetoothManager_deviceMajor_attribute
>>> 2. BluetoothManager_deviceMinor_attribute
>>> 3. BluetoothManager_deviceService_attribute
>>>
>>> Bluetooth CAPIs are not used in the three test cases. Therefore,
>>> please check the related source code of tizen-extensions-crosswalk.
>>>
>>> 4.in the case of BluetoothClass.
>>>
>>> It failed in 104 and 105 line:
>>>
>>> 101:devService = device.deviceClass.services[0];
>>> 102:device.deviceClass.services[0] = null;
>>> 103:device.deviceClass.services = [];
>>>
>>> 104:assert_type(device.deviceClass.services[0], "unsigned short",
>>> "device.deviceClass.services[0] is type number.");
>>> 105:assert_true(devService === device.deviceClass.services[0],
>>> "device.deviceClass.services[0] readonly");
>>>
>>> 104 line : It means that device.deviceClass.services[0] is not
>>> "unsigned short" and in fact,  the type of device.deviceClass.services[0]
>is object.
>>> 105 line: It means that device.deviceClass.services[0] should be
>>> readonly and 102 and 103 line can't modify the value of
>>> device.deviceClass.services[0].
>>>
>>> However, it can be modified.
>>>
>>> Can you check the related source codes of tizen-extensions-crosswal
>>> and fix them?
>>>
>>> Thanks.
>>>
>>> Best Regards
>>> Zheng Wu
>
>_______________________________________________
>Dev mailing list
>[email protected]
>https://lists.tizen.org/listinfo/dev
>_______________________________________________
>Dev mailing list
>[email protected]
>https://lists.tizen.org/listinfo/dev
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev

Reply via email to