|
|
Descriptionbluetooth: android: Initial Low Energy Discovery Sessions.
Add ability to start a low energy scan, though do nothing with the
results for now besides log that they are found.
Rename hasBluetoothPermission -> hasBluetoothCapability because the
permissions, SDK version, and hardware feature must all be present.
BUG=488575
Committed: https://crrev.com/649ce43ef16cd8c4a3315f2ebfa5823dcc06585e
Cr-Commit-Position: refs/heads/master@{#337924}
Committed: https://crrev.com/bc23b56f1e087dc89d087d37c4bf76decf749422
Cr-Commit-Position: refs/heads/master@{#338571}
Patch Set 1 #
Total comments: 11
Patch Set 2 : ortuno's comments addressed. #
Total comments: 6
Patch Set 3 : addressed tedchoc's comments #
Total comments: 8
Patch Set 4 : tedchoc comments addressed. #
Total comments: 8
Patch Set 5 : Add tests #
Total comments: 7
Patch Set 6 : armansito comments addressed. #Patch Set 7 : Fix static final members in FakeBluetoothDevice. #Patch Set 8 : ScanSettings moved into Wrappers #Patch Set 9 : Fakes no longer depend on ScanCallback, fixes runtime crash on older versions. #Patch Set 10 : https://codereview.chromium.org/1231883004 fixs runtime error. #Depends on Patchset: Dependent Patchsets: Messages
Total messages: 58 (30 generated)
scheib@chromium.org changed reviewers: + ortuno@chromium.org
lgtm https://codereview.chromium.org/1150833002/diff/1/device/bluetooth/android/ja... File device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java (right): https://codereview.chromium.org/1150833002/diff/1/device/bluetooth/android/ja... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:67: Log.i(TAG, "Bluetooth API disabled; SDK version (%d) too low.", You are logging a lot of stuff. We should probably ask tedchoc if this is OK. https://codereview.chromium.org/1150833002/diff/1/device/bluetooth/android/ja... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:138: private boolean addDiscoverySession() { nit: Add a comment for this function. https://codereview.chromium.org/1150833002/diff/1/device/bluetooth/android/ja... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:151: ScanSettings.Builder scanSettingsBuilder = new ScanSettings.Builder(); I would refactor this a bit: ScanSettings scanSettings = new ScanSettings.Builder() .setScanMode(ScanSettings.SCAN_MODE_LOW_LATENCY) .build(); https://codereview.chromium.org/1150833002/diff/1/device/bluetooth/android/ja... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:157: if (mLeScanCallback == null) mLeScanCallback = new DiscoveryScanCallback(); I think you need braces here: https://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s4.1.1-brac... https://codereview.chromium.org/1150833002/diff/1/device/bluetooth/android/ja... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:166: switch (--mNumDiscoverySessions) { nit: I think it would be clearer this way: if (mNumDiscoverySessions == 0) { assert false; Log.w(TAG, "removeDiscoverySession: No scan in progress."); return false; } if (mNumDiscoverySessions == 1) { mAdapter.getBluetoothLeScanner().stopScan(mLeScanCallback); } --mNumDiscoverySessions return true;
scheib@chromium.org changed reviewers: + tedchoc@chromium.org
Thanks. tedchoc: Comment on appropriateness of current logging in device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java please? https://codereview.chromium.org/1150833002/diff/1/device/bluetooth/android/ja... File device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java (right): https://codereview.chromium.org/1150833002/diff/1/device/bluetooth/android/ja... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:67: Log.i(TAG, "Bluetooth API disabled; SDK version (%d) too low.", On 2015/05/21 16:48:53, ortuno wrote: > You are logging a lot of stuff. We should probably ask tedchoc if this is OK. I've moved the verbose bits to .d and .v, which aren't enabled by default and also removed included in release builds: https://chromium.googlesource.com/chromium/src/+/master/base/android/java/src... https://codereview.chromium.org/1150833002/diff/1/device/bluetooth/android/ja... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:138: private boolean addDiscoverySession() { On 2015/05/21 16:48:53, ortuno wrote: > nit: Add a comment for this function. Done. https://codereview.chromium.org/1150833002/diff/1/device/bluetooth/android/ja... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:151: ScanSettings.Builder scanSettingsBuilder = new ScanSettings.Builder(); On 2015/05/21 16:48:53, ortuno wrote: > I would refactor this a bit: > > ScanSettings scanSettings = new ScanSettings.Builder() > .setScanMode(ScanSettings.SCAN_MODE_LOW_LATENCY) > .build(); Done. https://codereview.chromium.org/1150833002/diff/1/device/bluetooth/android/ja... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:151: ScanSettings.Builder scanSettingsBuilder = new ScanSettings.Builder(); On 2015/05/21 16:48:53, ortuno wrote: > I would refactor this a bit: > > ScanSettings scanSettings = new ScanSettings.Builder() > .setScanMode(ScanSettings.SCAN_MODE_LOW_LATENCY) > .build(); Done. https://codereview.chromium.org/1150833002/diff/1/device/bluetooth/android/ja... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:157: if (mLeScanCallback == null) mLeScanCallback = new DiscoveryScanCallback(); On 2015/05/21 16:48:53, ortuno wrote: > I think you need braces here: > > https://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s4.1.1-brac... Done. https://codereview.chromium.org/1150833002/diff/1/device/bluetooth/android/ja... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:166: switch (--mNumDiscoverySessions) { On 2015/05/21 16:48:53, ortuno wrote: > nit: I think it would be clearer this way: > > if (mNumDiscoverySessions == 0) { > assert false; > Log.w(TAG, "removeDiscoverySession: No scan in progress."); > return false; > } > > if (mNumDiscoverySessions == 1) { > mAdapter.getBluetoothLeScanner().stopScan(mLeScanCallback); > } > > --mNumDiscoverySessions > > return true; Done.
lgtm w/ a couple comments https://codereview.chromium.org/1150833002/diff/20001/device/bluetooth/androi... File device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java (right): https://codereview.chromium.org/1150833002/diff/20001/device/bluetooth/androi... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:34: private int mNumDiscoverySessions = 0; 0 is the default do you don't need to put that here. https://codereview.chromium.org/1150833002/diff/20001/device/bluetooth/androi... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:64: final boolean hasLowEnergyFeature = I would include Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN_MR2 since FEATURE_BLUETOOTH_LE requires that. https://codereview.chromium.org/1150833002/diff/20001/device/bluetooth/androi... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:216: // NEED ISSUE NUMBER. Hmm...maybe i'm confused, but it looks like it does say the callback for startDiscovery can get a callback to be told of failure. https://developer.chrome.com/apps/bluetooth#method-startDiscovery No idea if this is different from what you're saying above.
tedchoc: Thanks. BTW, is usage of Log.v, Log.d, Log.i seem fine too you? Not too much usage? Also, I added in the nativeCPPObject as I need to call back to C++ now, PTAL. armansito: PTAL. Particularly discuss if it's OK to generally start discovery sessions with success and then MarkDiscoverySessionsAsInactive() if the error callback happens. ortuno pointed out that errors seem fairly common on Android devices. https://codereview.chromium.org/1150833002/diff/20001/device/bluetooth/androi... File device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java (right): https://codereview.chromium.org/1150833002/diff/20001/device/bluetooth/androi... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:34: private int mNumDiscoverySessions = 0; On 2015/05/22 20:11:46, Ted C wrote: > 0 is the default do you don't need to put that here. Done. https://codereview.chromium.org/1150833002/diff/20001/device/bluetooth/androi... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:64: final boolean hasLowEnergyFeature = On 2015/05/22 20:11:46, Ted C wrote: > I would include Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN_MR2 > since FEATURE_BLUETOOTH_LE requires that. Done. https://codereview.chromium.org/1150833002/diff/20001/device/bluetooth/androi... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:216: // NEED ISSUE NUMBER. On 2015/05/22 20:11:46, Ted C wrote: > Hmm...maybe i'm confused, but it looks like it does say the callback for > startDiscovery can get a callback to be told of failure. > > https://developer.chrome.com/apps/bluetooth#method-startDiscovery > > No idea if this is different from what you're saying above. Acknowledged.
scheib@chromium.org changed reviewers: + armansito@chromium.org
armansito: PTAL. Particularly discuss if it's OK to generally start discovery sessions with success and then MarkDiscoverySessionsAsInactive() if the error callback happens. ortuno pointed out that errors seem fairly common on Android devices.
logging choices looks fine to me. If we see it is too spammy in the logs then we can clean it up. https://codereview.chromium.org/1150833002/diff/40001/device/bluetooth/androi... File device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java (right): https://codereview.chromium.org/1150833002/diff/40001/device/bluetooth/androi... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:32: private final long mNativeCPPObject; Normally, we'd do mNativeBluetoothAdapter https://codereview.chromium.org/1150833002/diff/40001/device/bluetooth/androi... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:78: + "required."); this is indented too much...should be 8 https://codereview.chromium.org/1150833002/diff/40001/device/bluetooth/androi... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:97: private native void nativeOnScanFailed(long nativeBluetoothAdapterAndroid); We typically put native ones at the bottom since they don't have any content https://codereview.chromium.org/1150833002/diff/40001/device/bluetooth/androi... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:183: private boolean removeDiscoverySession() { is this guaranteed to be called if during the destructor of the native side? If not, we might have a scan active while the native side is deleted. Then a scan failed would call a method on a now dead native object. We either need to ensure this is cleaned up when destroying the native side, or the native side needs to notify the java side it is destroyed, we set our pointer to 0, and we check it in the scan callback. Ideally, we do the cleanup to avoid the pointer check, but if it is too burdensome then that is the other route we go.
Thanks, https://codereview.chromium.org/1150833002/diff/40001/device/bluetooth/androi... File device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java (right): https://codereview.chromium.org/1150833002/diff/40001/device/bluetooth/androi... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:32: private final long mNativeCPPObject; On 2015/05/27 01:13:39, Ted C wrote: > Normally, we'd do mNativeBluetoothAdapter Done. https://codereview.chromium.org/1150833002/diff/40001/device/bluetooth/androi... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:78: + "required."); On 2015/05/27 01:13:39, Ted C wrote: > this is indented too much...should be 8 This is enforced by 'git cl format', and reset if adjusted manually. https://codereview.chromium.org/1150833002/diff/40001/device/bluetooth/androi... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:97: private native void nativeOnScanFailed(long nativeBluetoothAdapterAndroid); On 2015/05/27 01:13:39, Ted C wrote: > We typically put native ones at the bottom since they don't have any content Done. https://codereview.chromium.org/1150833002/diff/40001/device/bluetooth/androi... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:183: private boolean removeDiscoverySession() { On 2015/05/27 01:13:39, Ted C wrote: > is this guaranteed to be called if during the destructor of the native side? If > not, we might have a scan active while the native side is deleted. > > Then a scan failed would call a method on a now dead native object. > > We either need to ensure this is cleaned up when destroying the native side, or > the native side needs to notify the java side it is destroyed, we set our > pointer to 0, and we check it in the scan callback. > > Ideally, we do the cleanup to avoid the pointer check, but if it is too > burdensome then that is the other route we go. Done. The scan will now be stopped upon C++ object destruction.
btw, what will be you unit testing strategy for Android? https://codereview.chromium.org/1150833002/diff/60001/device/bluetooth/androi... File device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java (right): https://codereview.chromium.org/1150833002/diff/60001/device/bluetooth/androi... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:71: mHasBluetoothCapability = hasMinAPI && hasPermissions && hasLowEnergyFeature; The code is self explanatory but can you add a comment explaining why BT classic won't be supported? https://codereview.chromium.org/1150833002/diff/60001/device/bluetooth/androi... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:174: return startScan(); If startScan() fails, won't you need to decrement the count? https://codereview.chromium.org/1150833002/diff/60001/device/bluetooth/androi... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:264: nativeOnScanFailed(mNativeBluetoothAdapterAndroid); I'm fine with this, as long as you're updating the all the discovery sessions AND setting the reference count to zero (though I don't see the latter part here). https://codereview.chromium.org/1150833002/diff/60001/device/bluetooth/blueto... File device/bluetooth/bluetooth_adapter_android.cc (left): https://codereview.chromium.org/1150833002/diff/60001/device/bluetooth/blueto... device/bluetooth/bluetooth_adapter_android.cc:162: const ErrorCallback& error_callback) { Add TODO about filters (and link to the bug) here.
Patchset #7 (id:120001) has been deleted
Patchset #5 (id:80001) has been deleted
Patchset #5 (id:100001) has been deleted
Patchset #5 (id:140001) has been deleted
Patchset #5 (id:160001) has been deleted
Patchset #5 (id:180001) has been deleted
Patchset #5 (id:200001) has been deleted
Patchset #5 (id:220001) has been deleted
armansito, PTAL. I've updated this patch to add tests. There's some churn based on adding the additional code needed in other changes, and patch-vs-patch diffs are poor for the ChromeBluetoothAdapter.java file because of the file rename. https://codereview.chromium.org/1150833002/diff/60001/device/bluetooth/androi... File device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java (right): https://codereview.chromium.org/1150833002/diff/60001/device/bluetooth/androi... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:71: mHasBluetoothCapability = hasMinAPI && hasPermissions && hasLowEnergyFeature; On 2015/05/28 04:04:11, armansito wrote: > The code is self explanatory but can you add a comment explaining why BT classic > won't be supported? Done. https://codereview.chromium.org/1150833002/diff/60001/device/bluetooth/androi... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:174: return startScan(); On 2015/05/28 04:04:11, armansito wrote: > If startScan() fails, won't you need to decrement the count? Done. https://codereview.chromium.org/1150833002/diff/60001/device/bluetooth/androi... device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothAdapter.java:264: nativeOnScanFailed(mNativeBluetoothAdapterAndroid); On 2015/05/28 04:04:11, armansito wrote: > I'm fine with this, as long as you're updating the all the discovery sessions > AND setting the reference count to zero (though I don't see the latter part > here). Done. https://codereview.chromium.org/1150833002/diff/60001/device/bluetooth/blueto... File device/bluetooth/bluetooth_adapter_android.cc (left): https://codereview.chromium.org/1150833002/diff/60001/device/bluetooth/blueto... device/bluetooth/bluetooth_adapter_android.cc:162: const ErrorCallback& error_callback) { On 2015/05/28 04:04:11, armansito wrote: > Add TODO about filters (and link to the bug) here. Done.
lgtm https://codereview.chromium.org/1150833002/diff/240001/device/bluetooth/andro... File device/bluetooth/android/java/src/org/chromium/device/bluetooth/ChromeBluetoothAdapter.java (right): https://codereview.chromium.org/1150833002/diff/240001/device/bluetooth/andro... device/bluetooth/android/java/src/org/chromium/device/bluetooth/ChromeBluetoothAdapter.java:38: * @param nativeBluetoothAdapterAndroid Is the paired C++ I'd say "coupled" or "associated" rather than paired, to avoid ambiguities with Bluetooth pairing. https://codereview.chromium.org/1150833002/diff/240001/device/bluetooth/andro... device/bluetooth/android/java/src/org/chromium/device/bluetooth/ChromeBluetoothAdapter.java:138: } else { No need for else since you have an early return https://codereview.chromium.org/1150833002/diff/240001/device/bluetooth/andro... device/bluetooth/android/java/src/org/chromium/device/bluetooth/ChromeBluetoothAdapter.java:157: return stopScan(); no need for else
nit https://codereview.chromium.org/1150833002/diff/240001/device/bluetooth/bluet... File device/bluetooth/bluetooth_adapter_unittest.cc (right): https://codereview.chromium.org/1150833002/diff/240001/device/bluetooth/bluet... device/bluetooth/bluetooth_adapter_unittest.cc:469: #endif #endif // defined(OS_ANDROID)
Thanks https://codereview.chromium.org/1150833002/diff/240001/device/bluetooth/andro... File device/bluetooth/android/java/src/org/chromium/device/bluetooth/ChromeBluetoothAdapter.java (right): https://codereview.chromium.org/1150833002/diff/240001/device/bluetooth/andro... device/bluetooth/android/java/src/org/chromium/device/bluetooth/ChromeBluetoothAdapter.java:38: * @param nativeBluetoothAdapterAndroid Is the paired C++ On 2015/06/30 20:37:22, armansito wrote: > I'd say "coupled" or "associated" rather than paired, to avoid ambiguities with > Bluetooth pairing. Done. https://codereview.chromium.org/1150833002/diff/240001/device/bluetooth/andro... device/bluetooth/android/java/src/org/chromium/device/bluetooth/ChromeBluetoothAdapter.java:138: } else { On 2015/06/30 20:37:22, armansito wrote: > No need for else since you have an early return Done. https://codereview.chromium.org/1150833002/diff/240001/device/bluetooth/andro... device/bluetooth/android/java/src/org/chromium/device/bluetooth/ChromeBluetoothAdapter.java:157: return stopScan(); On 2015/06/30 20:37:22, armansito wrote: > no need for else Done.
The CQ bit was checked by scheib@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from ortuno@chromium.org, tedchoc@chromium.org, armansito@chromium.org Link to the patchset: https://codereview.chromium.org/1150833002/#ps260001 (title: "armansito comments addressed.")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1150833002/260001
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: android_clang_dbg_recipe on tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/android_clang_d...)
The CQ bit was checked by scheib@chromium.org
The CQ bit was unchecked by scheib@chromium.org
The CQ bit was unchecked by scheib@chromium.org
The CQ bit was checked by scheib@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from tedchoc@chromium.org, ortuno@chromium.org, armansito@chromium.org Link to the patchset: https://codereview.chromium.org/1150833002/#ps280001 (title: "Fix static final members in FakeBluetoothDevice.")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1150833002/280001
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: linux_android_rel_ng on tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_android_r...)
The CQ bit was checked by scheib@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from tedchoc@chromium.org, ortuno@chromium.org, armansito@chromium.org Link to the patchset: https://codereview.chromium.org/1150833002/#ps300001 (title: "ScanSettings moved into Wrappers")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1150833002/300001
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: android_chromium_gn_compile_dbg on tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/android_chromiu...) android_chromium_gn_compile_rel on tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/android_chromiu...) android_clang_dbg_recipe on tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/android_clang_d...) android_compile_dbg on tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/android_compile...) cast_shell_android on tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_andr...) linux_android_rel_ng on tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_android_r...) linux_chromium_chromeos_compile_dbg_ng on tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) linux_chromium_chromeos_ozone_rel_ng on tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) linux_chromium_chromeos_rel_ng on tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) linux_chromium_clobber_rel_ng on tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) linux_chromium_gn_rel on tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) (exceeded global retry quota)
The CQ bit was checked by scheib@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1150833002/300001
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: linux_android_rel_ng on tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_android_r...)
The CQ bit was checked by scheib@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from tedchoc@chromium.org, ortuno@chromium.org, armansito@chromium.org Link to the patchset: https://codereview.chromium.org/1150833002/#ps320001 (title: "Fakes no longer depend on ScanCallback, fixes runtime crash on older versions.")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1150833002/320001
Message was sent while issue was closed.
Committed patchset #9 (id:320001)
Message was sent while issue was closed.
Patchset 9 (id:??) landed as https://crrev.com/649ce43ef16cd8c4a3315f2ebfa5823dcc06585e Cr-Commit-Position: refs/heads/master@{#337924}
Message was sent while issue was closed.
A revert of this CL (patchset #9 id:320001) has been created in https://codereview.chromium.org/1226103005/ by scheib@chromium.org. The reason for reverting is: Downstream Chrome build encountered runtime errors: java.lang.NoClassDefFoundError: org/chromium/device/bluetooth/ChromeBluetoothAdapter 6a6b6: 07-08 23:04:48.277 3034 3054 W System.err: at org.chromium.base.library_loader.Linker.nativeLoadLibrary(Native Method) 6a6b6: 07-08 23:04:48.277 3034 3054 W System.err: at org.chromium.base.library_loader.Linker.loadLibrary(Linker.java:747) 6a6b6: 07-08 23:04:48.277 3034 3054 W System.err: at org.chromium.base.library_loader.LibraryLoader.loadLibrary(LibraryLoader.java:304) 6a6b6: 07-08 23:04:48.277 3034 3054 W System.err: at org.chromium.base.library_loader.LibraryLoader.loadAlreadyLocked(LibraryLoader.java:241) 6a6b6: 07-08 23:04:48.277 3034 3054 W System.err: at org.chromium.base.library_loader.LibraryLoader.ensureInitialized(LibraryLoader.java:123) 6a6b6: 07-08 23:04:48.277 3034 3054 W System.err: at org.chromium.chrome.browser.init.NativeInitializationController$1.run(NativeInitializationController.java:83) 6a6b6: 07-08 23:04:48.287 3034 3054 W System.err: Caused by: java.lang.ClassNotFoundException: Didn't find class "org.chromium.device.bluetooth.ChromeBluetoothAdapter" on path: DexPathList[[zip file "/system/framework/android.test.runner.jar", zip file "/data/app/com.google.android.apps.chrome.tests-1.apk", zip file "/data/app/com.google.android.apps.chrome-1.apk"],nativeLibraryDirectories=[/data/app-lib/com.google.android.apps.chrome.tests-1, /data/app-lib/com.google.android.apps.chrome-1, /vendor/lib, /system/lib]] 6a6b6: 07-08 23:04:48.287 3034 3054 W System.err: at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:56) 6a6b6: 07-08 23:04:48.287 3034 3054 W System.err: at java.lang.ClassLoader.loadClass(ClassLoader.java:497) 6a6b6: 07-08 23:04:48.287 3034 3054 W System.err: at java.lang.ClassLoader.loadClass(ClassLoader.java:457).
Patchset #10 (id:340001) has been deleted
The CQ bit was checked by scheib@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from tedchoc@chromium.org, ortuno@chromium.org, armansito@chromium.org Link to the patchset: https://codereview.chromium.org/1150833002/#ps360001 (title: "https://codereview.chromium.org/1231883004 fixs runtime error.")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1150833002/360001
Message was sent while issue was closed.
Committed patchset #10 (id:360001)
Message was sent while issue was closed.
Patchset 10 (id:??) landed as https://crrev.com/bc23b56f1e087dc89d087d37c4bf76decf749422 Cr-Commit-Position: refs/heads/master@{#338571} |