[Dev] FW: FW: some issues in the process of TCT Bluetooth testing

Zheng, Wu wu.zheng at intel.com
Thu Aug 14 10:18:29 GMT 2014


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:dev-bounces at lists.tizen.org] On Behalf Of Zheng, Wu
>Sent: Thursday, August 14, 2014 5:10 PM
>To: corentin.lecouvey at open.eurogiciel.org
>Cc: dev at lists.tizen.org; 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:dev-bounces at lists.tizen.org] On Behalf Of Zheng, Wu
>Sent: Tuesday, August 12, 2014 5:25 PM
>To: corentin.lecouvey at open.eurogiciel.org
>Cc: dev at lists.tizen.org; 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: corentin.lecouvey at open.eurogiciel.org
>[mailto:corentin.lecouvey at open.eurogiciel.org]
>Sent: Tuesday, August 12, 2014 5:16 PM
>To: Zheng, Wu
>Cc: dev at lists.tizen.org; 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: 'corentin.lecouvey at open.eurogiciel.org'
>>> Cc: 'dev at lists.tizen.org'; 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
>Dev at lists.tizen.org
>https://lists.tizen.org/listinfo/dev
>_______________________________________________
>Dev mailing list
>Dev at lists.tizen.org
>https://lists.tizen.org/listinfo/dev


More information about the Dev mailing list