Issue metadata
Sign in to add a comment
|
startCharacteristicNotifications returns 'Operation failed' after disconnect
Reported by
j...@zode64.com,
May 8 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.96 Safari/537.36 Platform: 9334.58.0 Steps to reproduce the problem: Steps to reproduce the problem: 1. Install an app that functions with a bluetooth device. I am using the Pocketlab app and Pocketlab device (we can send you a device). 2. Start the app connect 3. Load the services and start a notification 4. Call disconnect 5. Reconnect to the same device 6. After a 5000 delay, load services 7. Try start the same notification What is the expected behavior? I can restart the notifications What went wrong? startNotificationCharacteristic fails with 'Operation failed'. Did this work before? Yes 57 Does this work in other browsers? Yes Chrome version: 58.0.3029.89 Channel: stable OS Version: 58.0.3029.89 Flash Version: This error is exclusively seen immediately after a disconnect. Only a system restart will resolve this issue. This is a regression issue that was introduced in 57 (it's possible it was 56 but I don't think this is the case). For similar issues I have been directed to the new web-bluetooth api. We are currently investigating this api but in the meantime we need to resolve this issue with chrome.bluetooth so our users can continue to use our devices. We will be happy to send you a device if it would help. I created a new report from https://bugs.chromium.org/p/chromium/issues/detail?id=718144#c1 as I wanted to refer specifically to the startNotificationCharacteristic problem. I have tried a 20 second delay before loading services and still see the same issue. Some code like this might replicate it. chrome.bluetooth.getDevice('<device mac address>', function(device) { chrome.bluetoothLowEnergy.connect(device.address, {persistent:false}, function() { chrome.bluetoothLowEnergy.getServices(device.address, function(services) { chrome.bluetoothLowEnergy.getCharacteristics(services[<index with notification characteristic>].instanceId, function(characteristics) { chrome.bluetoothLowEnergy.startCharacteristicNotifications(characteristics[<index of notification characteristic>], {}, function() { if(!chrome.runtime.lastError) { console.log('Notifications started'); chrome.bluetoothLowEnergy.disconnect(device.address, function() { chrome.bluetoothLowEnergy.connect(device.address, {persistent:false}, function() { chrome.bluetoothLowEnergy.getServices(device.address, function(services) { chrome.bluetoothLowEnergy.getCharacteristics(services[<index with notification characteristic>].instanceId, function(characteristics) { chrome.bluetoothLowEnergy.startCharacteristicNotifications(characteristics[<index of notification characteristic>], {}, function() { console.dir(chrome.runtime.lastError); }); }); }); }); }); } else { console.log('Notifications failed to start'); } }); }); }); }); }); --------------- Comment 50 has a minimized reproduction: --------------- I've attached a HTML file which illustrate the problem I am seeing. The problem involves the removeEventListener. When a disconnect is called after a removeEventListener the same listener can't be re-added on the Chromebook but can on the MacOSX. If you 'Connect' and 'Start Sensor and Notifications' you can see readings coming in in the console. Then if you 'Remove Event Listener and Disconnect', 'Connect' again and 'Start Sensor and Notifications' then the readings aren't received. Any subsequent connection attempts will fail if no other action is taken. If you refresh the page, 'Connect' and 'Start Sensor and Notifications' then readings will begin to come in again. If you 'Connect', 'Start Sensor and Notifications', 'Stop Sensor and Remove Event Listener' then 'Start Sensor and Notifications' then it works fine which leads me to believe it related to the disconnect. If you change the listener to be anonymous it works.
,
May 8 2017
Assigning to rkc for triage.
,
May 8 2017
,
May 9 2017
@ortuno, This is an issue with the Chrome Apps API
,
May 10 2017
I cannot reproduce this bug. In the first place why did the disconnect happen? Was it because bad noise?
,
May 11 2017
I see this issue if the target BLE device is switched off or I call
chrome.bluetoothLowEnergy.disconnect(device.address, function() {})
,
May 11 2017
What happens when you do the same thing with WebBluetooth? I am not quite sure how we expect startNotification to work if the target device is turned off or disconnected.
,
May 11 2017
What about a delay between disconnecting and reconnecting? rkc: I don't think john@ is calling startNotification when disconnected but rather he's calling startNotification after a device disconnects and reconnects. This sounds similar to Issue 718237.
,
May 11 2017
With web bluetooth everything works. The problem is unique to chrome.bluetooth. I see the 'Operation failed' after the device has become available again and there has been an apparent successful reconnect. Previous to version 57 after a disconnect or switch off I was able to connect to the device again and start up notifications as if it was the first time. I have tried adding a delay of up to 20 seconds and it doesn't improve the situation. It appears I am unable to view this issue at https://bugs.chromium.org/p/chromium/issues/detail?id=718237 so can't confirm it is related.
,
May 12 2017
Are you able to reproduce it every time or is it intermittent problem? I am not able to reproduce the problem. If you are able to reproduce it every time, you can help us by sending the /var/log/ui/ui.LATEST when the problem happens, also add this line to /etc/chrome_dev.conf: --vmodule=*blue*=1 --log-level=0
,
May 12 2017
From #9 it seems like if you turn of your BLE peripheral off and turn it on again, this bug repros a 100% of the time? Would it be possible for you get this device to Sonny for testing?
,
May 15 2017
I'm now able to reproduce this and found the root cause to be this: https://crrev.com/2625013003. It seems that that CL does not solve its bug properly ( issue 680099 ). But I do not understand what that CL is actually doing since I can't even reproduce issue 680099 . ortuno/rkc, do you have any idea?
,
May 15 2017
Why does the CL cause this issue? (I find the CL odd, and don't think it is correct, but it would be useful to know how clearing GATT services/UUIDs is causing the startNotifications to fail)
,
May 16 2017
Clearing gatt_services_ makes Chrome forget that there is already an active notification. So when .startCharacteristicNotification() is called from Chrome API, Chrome asks bluez to StartNotify and bluez returns org.bluez.Failed with error message "Already notifying". So Chrome has reached a deadlock state where it cannot startCharacteristicNotification because bluez says it's already notifying, and chrome cannot stopCharacteristicNotification either because chrome believes that there is no active notification for that characteristic.
,
May 16 2017
This is a complex problem that is being made harder by BlueZ not following the spec... I think we have a couple of options here: 1. We could stop all notifications when a device disconnects. Nothing would be sent to the device but at least we would clear BlueZ's cache, thus forcing it to follow the spec. This would go against the spec since we would be clearing the cache for Paired devices but we don't yet support keeping this information for paired devices anyway. 2. Change SubscribeToNotifications[1] to check if the characteristic's 'notifying' property is set to true and if so just call its success callback. I think in the long term we need to redesign our notifications system with Paired devices in mind but I think 2. would be a good solution in the short term.
,
May 16 2017
Forgot links: 1. SubscribeToNotifications: https://cs.chromium.org/chromium/src/device/bluetooth/bluez/bluetooth_remote_gatt_characteristic_bluez.cc?sq=package:chromium&dr=C&l=215 2. 'notifying': https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/gatt-api.txt#n128
,
May 16 2017
,
May 16 2017
It sounds like the CL is definitely wrong. We should revert the CL at a minimum.
,
May 16 2017
I think it wrong to the extent that it doesn't directly address the bug. A benefit of that CL is that it makes the behavior on BlueZ match other platforms: all attributes are deleted when a device disconnects since they are no longer valid.
,
May 16 2017
Sorry for the delay, I have been working with web-bluetooth to try resolve the issue. I will ask the product owner if I can send a device if you still think it would be helpful? Once I have completed the web-bluetooth fix I will try add the line to the config and post the results. As for the suggested cause it sounds very plausible that this is it however I the error message being sent when a startNotificationCharactertic fails is 'Operation failed' and not 'Already notifying'.
,
May 16 2017
,
May 16 2017
@john, "Operation failed" is the error code from Chrome, but behind that the error message from bluez is likely to be "Already notifying" as I reproduced. You can verify this by setting --vmodule=*blue*=1 in chrome_dev.conf, reproduce, and look at /var/log/ui/ui.LATEST.
,
May 16 2017
Issue 680099 has been merged into this issue.
,
May 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/acfce3dfacf54420df8a3118e9433dbb36d70177 commit acfce3dfacf54420df8a3118e9433dbb36d70177 Author: sonnysasaka <sonnysasaka@chromium.org> Date: Wed May 17 02:30:07 2017 Revert "bluetooth: bluez: Fixed issue with missing notifications after reconnect." Doesn't fix the original issue of notifications failing after reconnect https://crbug.com/680099 correctly. Introduces new issue: startCharacteristicNotifications returns 'Operation failed' after disconnect https://crbug.com/719581 This reverts commit db61493317991225f05f657bc5c78db7f96d55a7. originally from https://codereview.chromium.org/2625013003/ TBR=ortuno@chromium.org,rkc@google.com,scheib@chromium.org,perja@opera.com BUG= 680099 , 719581 Review-Url: https://codereview.chromium.org/2888663002 Cr-Commit-Position: refs/heads/master@{#472290} [modify] https://crrev.com/acfce3dfacf54420df8a3118e9433dbb36d70177/device/bluetooth/bluetooth_device.cc [modify] https://crrev.com/acfce3dfacf54420df8a3118e9433dbb36d70177/device/bluetooth/bluetooth_device.h [modify] https://crrev.com/acfce3dfacf54420df8a3118e9433dbb36d70177/device/bluetooth/bluetooth_device_android.cc [modify] https://crrev.com/acfce3dfacf54420df8a3118e9433dbb36d70177/device/bluetooth/bluetooth_low_energy_device_mac.mm [modify] https://crrev.com/acfce3dfacf54420df8a3118e9433dbb36d70177/device/bluetooth/bluez/bluetooth_device_bluez.cc
,
May 26 2017
,
May 26 2017
This bug requires manual review: We are only 10 days from stable. Please contact the milestone owner if you have questions. Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 26 2017
I'm not sure why we would like to merge the patch? It doesn't really address the bug...
,
May 26 2017
We want to merge the revert, not the patch.
,
May 26 2017
Right, the revert just makes the code better it doesn't actually address the problem. Calling StartNotifySession after reconnecting will still cause an error.
,
May 26 2017
@ortuno, actually the error is different. Before the revert, calling startCharacteristicNotification returns error and we reach a deadlock state where we cannot start nor stop the notification and the notification doesn't appear at all. After the revert, calling startCharacteristicNotification will just say 'Already Notifying' but the notification is really on, so the caller may ignore this 'Already Notifying' error because it is really on.
,
May 26 2017
Thanks for the explanation. If that's the case then I think it makes sense to try to merge. I'm curious as to why the deadlock happened. If startNotifySession failed why wasn't the error callback called?
,
May 26 2017
Oh nvm. I understand now. The error callback was being run. The deadlock is on the user side as they will not be able to start or stop notifications.
,
May 26 2017
Issue 718237 has been merged into this issue.
,
May 30 2017
Bug 680099 is no longer reproducible according to perja@opera.com. So the revert crrev.com/2888663002 is enough to fix this bug. I'm marking this as Fixed.
,
May 30 2017
According to #30 we would still get a "Already notifying" error if we call statCharacteristicNotification after disconnection, right? If so then I don't think this should be marked as fixed.
,
May 30 2017
Responding with "Already notifying" because the notification is really currently notifying is not a bug, is it? Or perhaps the bug should be "Chrome should reset all notifications after disconnect/reconnect for unpaired devices"?
,
May 30 2017
Correct. For both Chrome Apps and Web Bluetooth the fact that notification state is remembered even after disconnection is a bug.
,
May 30 2017
,
May 31 2017
http://marc.info/?l=linux-bluetooth&m=149623385617581&w=2 With that is just a matter of setting the KeepCache=yes, or KeepCache=no, then no attribute is remembered by BlueZ. In case someone is wondering why BlueZ always cache GATT attributes there were many reasons, for instance in many cases the where intermittent connections which interrupt the discovery prematurely, on top of that doing service discovery takes an awful long time and there still exists devices that loose the service changed and CCC after flashed or when the battery is removed. So all of this has lead BlueZ to implement a cache validation on *every connection. Also note that BlueZ only behaves differently for peripherals with public addresses since devices using random addresses are automatically removed after disconnected if not bonded.
,
Jun 2 2017
,
Jun 5 2017
,
Jun 5 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/cb16911775ae92e1464b37dc3ca1ce98e832bca1 commit cb16911775ae92e1464b37dc3ca1ce98e832bca1 Author: Grace Kihumba <gkihumba@google.com> Date: Mon Jun 05 18:33:27 2017 Revert "bluetooth: bluez: Fixed issue with missing notifications after reconnect." Doesn't fix the original issue of notifications failing after reconnect https://crbug.com/680099 correctly. Introduces new issue: startCharacteristicNotifications returns 'Operation failed' after disconnect https://crbug.com/719581 This reverts commit db61493317991225f05f657bc5c78db7f96d55a7. originally from https://codereview.chromium.org/2625013003/ TBR=ortuno@chromium.org,rkc@google.com,scheib@chromium.org,perja@opera.com BUG= 680099 , 719581 Review-Url: https://codereview.chromium.org/2888663002 Cr-Original-Commit-Position: refs/heads/master@{#472290} Review-Url: https://codereview.chromium.org/2923643002 . Cr-Commit-Position: refs/branch-heads/3071@{#747} Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641} [modify] https://crrev.com/cb16911775ae92e1464b37dc3ca1ce98e832bca1/device/bluetooth/bluetooth_device.cc [modify] https://crrev.com/cb16911775ae92e1464b37dc3ca1ce98e832bca1/device/bluetooth/bluetooth_device.h [modify] https://crrev.com/cb16911775ae92e1464b37dc3ca1ce98e832bca1/device/bluetooth/bluetooth_device_android.cc [modify] https://crrev.com/cb16911775ae92e1464b37dc3ca1ce98e832bca1/device/bluetooth/bluetooth_low_energy_device_mac.mm [modify] https://crrev.com/cb16911775ae92e1464b37dc3ca1ce98e832bca1/device/bluetooth/bluez/bluetooth_device_bluez.cc
,
Jun 7 2017
,
Jun 16 2017
,
Jun 16 2017
,
Jul 25 2017
,
Jul 25 2017
This issue is caused by the caching mechanism of GATT server for the unpaired device after disconnection. In the repro scenario, a Chromebook acts as a GATT server while a remote phone acts as the GATT client. https://chromium-review.googlesource.com/c/506779/ was submitted for clearing out the GATT database for GATT server after disconnecting from an unpaired device. But since some platforms depends on the persistent caching between connections in order to eliminate the time needed for re-explore the GATT server database, https://www.spinics.net/lists/linux-bluetooth/msg70570.html was proposed to customize the caching behavior by adding options. So I plan to abandon https://chromium-review.googlesource.com/c/506779/, apply https://www.spinics.net/lists/linux-bluetooth/msg70570.html and submit corresponding change.
,
Oct 11 2017
Due to this bug and another one I moved to web-bluetooth and for 6 months everything worked well. That is until yesterday when what appears to be the same bug appeared in web bluetooth. Could it be that changes related to this bug have worked there way into web bluetooth? An important point to note is that the same behavior isn't visible with web-bluetooth running on Mac OSX. I am using version 60.0.3112.114 of Google Chrome on the chromebook.
,
Oct 11 2017
John, this seems to be an issue at a lower level than the Web Bluetooth or chrome.bluetooth implementations -- though perhaps there's a side effect of their use of the lower level bluetooth library that's causing one to work when the other doesn't. This is an issue specific to ChromeOS and our use of BlueZ. I just failed to reproduce interactively with the console and the BLE Simulator app health thermometer https://play.google.com/store/apps/details?id=io.github.webbluetoothcg.bletestperipheral&hl=en It would help if you had a sketch of web bluetooth code attached here or e.g. on https://jsfiddle.net/.
,
Oct 17 2017
I've attached a HTML file which illustrate the problem I am seeing. The problem involves the removeEventListener. When a disconnect is called after a removeEventListener the same listener can't be re-added on the Chromebook but can on the MacOSX. If you 'Connect' and 'Start Sensor and Notifications' you can see readings coming in in the console. Then if you 'Remove Event Listener and Disconnect', 'Connect' again and 'Start Sensor and Notifications' then the readings aren't received. Any subsequent connection attempts will fail if no other action is taken. If you refresh the page, 'Connect' and 'Start Sensor and Notifications' then readings will begin to come in again. If you 'Connect', 'Start Sensor and Notifications', 'Stop Sensor and Remove Event Listener' then 'Start Sensor and Notifications' then it works fine which leads me to believe it related to the disconnect. If you change the listener to be anonymous it works.
,
Oct 20 2017
,
Oct 20 2017
,
Oct 31 2017
Issue 773842 has been merged into this issue.
,
Oct 31 2017
,
Oct 31 2017
,
Jan 9 2018
,
Mar 26 2018
Issue 825936 has been merged into this issue.
,
Mar 27 2018
,
Mar 28 2018
Hi John, I have a Pocketlab One. I pushed the top button. The LED indicator just stayed steady RED without flashing alternating red and green as described in the user guide http://www.thepocketlab.com/assets/pocketlabchromemanual.pdf. I am not able to make it start advertising and hence not able to discover it from a chromebook. I even took the CR 2032 battery out and put it back hoping to reset it. But the LED just stayed steady RED. Do you have any idea I can put it into advertising mode? After staying RED for about one day, the pocketlab sensor's LED now becomes rather weak. Any advice? Thanks!
,
Apr 2 2018
Hi Joseph, are you sure the battery has charge? If so it might be that you have an issue with the device. If so we can send you another one out.
,
Apr 2 2018
Hi John, I will replace a new battery and see how it works. Thanks!
,
Apr 12 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/bluez/+/8af344a336b1dbec19625ebeb1205ace1f0e7673 commit 8af344a336b1dbec19625ebeb1205ace1f0e7673 Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Date: Thu Apr 12 17:00:58 2018 UPSTREAM: core/gatt: Add GATT.Cache config option This adds GATT.Cache config option to main.conf which can be used to adjust the cache expected behavior of attributes found over GATT. BUG= chromium:719581 TEST=build Change-Id: I8353fe2d2c6625249106cec63c1b282fe7aff0ce Reviewed-on: https://chromium-review.googlesource.com/584854 Commit-Ready: Shyh-In Hwang <josephsih@chromium.org> Tested-by: Miao-chen Chou <mcchou@chromium.org> Reviewed-by: Shyh-In Hwang <josephsih@chromium.org> [modify] https://crrev.com/8af344a336b1dbec19625ebeb1205ace1f0e7673/src/device.c [modify] https://crrev.com/8af344a336b1dbec19625ebeb1205ace1f0e7673/src/main.conf [modify] https://crrev.com/8af344a336b1dbec19625ebeb1205ace1f0e7673/src/hcid.h [modify] https://crrev.com/8af344a336b1dbec19625ebeb1205ace1f0e7673/src/main.c
,
Apr 12 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/bluez/+/0718693bb1113f5ac2c12ebece629a077aac4591 commit 0718693bb1113f5ac2c12ebece629a077aac4591 Author: Miao-chen Chou <mcchou@chromium.org> Date: Thu Apr 12 17:00:59 2018 CHROMIUM: Change GATT.Cache config option from always to yes By adopting "yes" for the Cache configuration, the behavior of GATT caching changes for the unpaired devices where the GATT server database will be cleared after disconnection. BUG= chromium:719581 TEST=Register a notification on a unpaired device after re-connection, and the operation succeeds. Change-Id: I9af78e16bc2332fa52bd0ca0924f05f624eb37dc Reviewed-on: https://chromium-review.googlesource.com/584855 Commit-Ready: Shyh-In Hwang <josephsih@chromium.org> Tested-by: Miao-chen Chou <mcchou@chromium.org> Reviewed-by: Shyh-In Hwang <josephsih@chromium.org> [modify] https://crrev.com/0718693bb1113f5ac2c12ebece629a077aac4591/src/main.conf
,
Apr 13 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/85c13c8eabc82c506c85a02304ec217a2a79fd99 commit 85c13c8eabc82c506c85a02304ec217a2a79fd99 Author: Joseph Hwang <josephsih@chromium.org> Date: Fri Apr 13 08:43:24 2018 bluez: install main_common.conf This config file is needed to specify common config options for all boards. BUG= chromium:719581 TEST=emerge and deploy bluez and observe the existence of the /etc/bluetooth/main_common.conf file. CQ-DEPEND=CL:989355 Change-Id: Ic58a939896fab9473273eb097450cec6bcff50db Reviewed-on: https://chromium-review.googlesource.com/989592 Commit-Ready: Shyh-In Hwang <josephsih@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> [modify] https://crrev.com/85c13c8eabc82c506c85a02304ec217a2a79fd99/net-wireless/bluez/bluez-9999.ebuild
,
Apr 13 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/bluez/+/4faccf5f0553e6b0c35d2f1f461f54113cda579f commit 4faccf5f0553e6b0c35d2f1f461f54113cda579f Author: Joseph Hwang <josephsih@chromium.org> Date: Fri Apr 13 08:43:24 2018 CHROMIUM: Load multiple config files Currently, bluez only takes config options from the board specific config file. However, there is a need to be able to specify common config options for all boards. In order not to populate the common config options to all board overlays, it is desirable to load both the common config file and the board specific config file. GATT.Cache is an example. We would like to set "yes" as a common setting for all boards. This is achieved by setting the following lines in main_common.conf in bluez package. [GATT] Cache = yes With "Cache = yes", a gatt client would remove all cache attributes when an unpaired gatt server disconnects. Note that if an option exists in both config files, the one in the board specific config file has precedence. BUG= chromium:719581 TEST=Cherry-pick the following 4 patches. third_party/bluez: CL 584854: UPSTREAM: core/gatt: Add GATT.Cache config option CL 584855: CHROMIUM: Change GATT.Cache config option from always to yes CL 989355: CHROMIUM: load multiple config files third_party/chromiumos-overlay/net-wireless/bluez CL 989592: bluez: install main_common.conf Emerge and deploy bluez to a reef chromebook. Add the debug flag "-d" in /usr/bin/start_bluetoothd.sh Restart bluetoothd daemon. Now, a simple check or a full verification could be performed. [Simple Check] Observe the existence of deviceid and cache in /var/log/messages as follows. $ grep parse_config /var/log/messages The deviceid option is provided by the board specific config file. 2018-03-31T17:30:01.537435+08:00 DEBUG bluetoothd[26813]: src/main.c:parse_config() deviceid=bluetooth:00E0:2458:0400 The Cache option is provided by the common config file. 2018-03-31T17:30:01.537612+08:00 DEBUG bluetoothd[26813]: src/main.c:parse_config() GATT.Cache=yes [Full Verification] To fully verify crbug.com/719581 , perform the following steps to verify. (1) Connect the chromebook to a gatt server device. Make sure that the gatt server device advertises with a "public" address. If the gatt server device advertises with a "random" address, bluez will always delete the cache attributes no matter whatever "Cache" option is set. (2) Enable notification on the gatt server device and observe that it starts notification. (3) Power off the gatt server device to terminate the connection. Observe that all cached attributes are removed from the gatt client side, i.e., the chromebook. (4) Power on the gatt server device again after a few seconds. (5) Connect the chromebook to the gatt server device again. Observe that the notification does NOT take effect yet. (6) Start notification on the gatt server device and observe that the operation succeeds. The server starts notification again at this time. Change-Id: Ia221128b077274c4fb1943017934aa4e68d5ced8 Reviewed-on: https://chromium-review.googlesource.com/989355 Commit-Ready: Miao-chen Chou <mcchou@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Shyh-In Hwang <josephsih@chromium.org> [modify] https://crrev.com/4faccf5f0553e6b0c35d2f1f461f54113cda579f/src/main.c [rename] https://crrev.com/4faccf5f0553e6b0c35d2f1f461f54113cda579f/src/main_common.conf
,
Apr 13 2018
,
Apr 17 2018
,
Sep 18
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by ortuno@chromium.org
, May 8 2017