Google Cloud SDK - GAE 1.9.18 produces docker error on Windows [35906206]

Obsolete

Bug

Status Update

No update yet.

Description

al...@gmail.com

created issue #1

Apr 2, 2015 10:54AM

What steps will reproduce the problem?
Installed latest version of Google Cloud SDK on Windows 7 (and same issue on Windows 8.1 PC too). Trying to launch via GAE Launcher using Cloud SDK on local system does not work.

What is the expected output? What do you see instead?
2015-04-02 11:44:06 Running command: "['C:\\Python27\\pythonw.exe', 'C:\\Program Files\\Google\\Cloud SDK\\google-cloud-sdk\\platform\\google_appengine\\dev_appserver.py', '--skip_sdk_update_check=yes', '--port=8082', '--admin_port=8003', 'C:\\Users\\acollins\\workspace\\src\\goandgiveuk']"
Traceback (most recent call last):
File "C:\Program Files\Google\Cloud SDK\google-cloud-sdk\platform\google_appengine\dev_appserver.py", line 83, in <module>
_run_file(__file__, globals())
File "C:\Program Files\Google\Cloud SDK\google-cloud-sdk\platform\google_appengine\dev_appserver.py", line 79, in _run_file
execfile(_PATHS.script_file(script_name), globals_)
File "C:\Program Files\Google\Cloud SDK\google-cloud-sdk\platform\google_appengine\google\appengine\tools\devappserver2\devappserver2.py", line 36, in <module>
from google.appengine.tools.devappserver2 import dispatcher
File "C:\Program Files\Google\Cloud SDK\google-cloud-sdk\platform\google_appengine\google\appengine\tools\devappserver2\dispatcher.py", line 29, in <module>
from google.appengine.tools.devappserver2 import module
File "C:\Program Files\Google\Cloud SDK\google-cloud-sdk\platform\google_appengine\google\appengine\tools\devappserver2\module.py", line 71, in <module>
from google.appengine.tools.devappserver2 import vm_runtime_factory
File "C:\Program Files\Google\Cloud SDK\google-cloud-sdk\platform\google_appengine\google\appengine\tools\devappserver2\vm_runtime_factory.py", line 25, in <module>
from google.appengine.tools.devappserver2 import vm_runtime_proxy
File "C:\Program Files\Google\Cloud SDK\google-cloud-sdk\platform\google_appengine\google\appengine\tools\devappserver2\vm_runtime_proxy.py", line 29, in <module>
from google.appengine.tools.devappserver2 import log_manager
File "C:\Program Files\Google\Cloud SDK\google-cloud-sdk\platform\google_appengine\google\appengine\tools\devappserver2\log_manager.py", line 34, in <module>
from google.appengine.tools.docker import containers
File "C:\Program Files\Google\Cloud SDK\google-cloud-sdk\platform\google_appengine\google\appengine\tools\docker\containers.py", line 47, in <module>
import docker
ImportError: No module named docker
2015-04-02 11:44:12 (Process exited with code 1)

What is the output of 'gcloud info'?
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\acollins>cd\

C:\>gcloud info
Google Cloud SDK [0.9.54]

Platform: [Windows, x86]
Python Version: [2.7.9 (default, Dec 10 2014, 12:24:55) [MSC v.1500 32 bit (Intel)]]
Site Packages: [Disabled]

Installation Root: [C:\Program Files\Google\Cloud SDK\google-cloud-sdk]
Installed Components:
app-engine-python: [1.9.18]
gae-java: [1.9.18]
app-engine-python-extras: [1.9.18]
gsutil: [4.11]
gcutil: [1.16.5]
core-win: [2015.03.10]
gcloud: [2015.04.01]
gsutil-win: [4.6]
dns: [2015.03.23]
app-engine-go-windows-x86: [1.9.18]
gae-go-win: [2014.10.14]
core: [2015.04.01]
gae-python: [2014.05.06]
gae-java-win: [1.9.15]
windows-ssh-tools: [2015.03.13]
bq: [2.0.18]
gae-go: [2015.04.01]
sql: [2015.03.23]
bq-win: [2.0.18]
compute: [2015.04.01]
gcutil-win: [1.16.5]
gae-python-launcher-win: [1.9.18]
System PATH: [C:\Program Files\Google\Cloud SDK\google-cloud-sdk\bin\..\bin\sdk;C:\Program Files\NVIDIA Corporation\Phys
X\Common;C:\ProgramData\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\system32\wbem;C:\Python33;C:\Wind
ows\System32\WindowsPowerShell\v1.0;C:\Program Files\Intel\WiFi\bin;C:\Program Files\Common Files\Intel\WirelessCommon;C
:\Program Files\Intel\OpenCL SDK\2.0\bin\x86;C:\Program Files\WIDCOMM\Bluetooth Software;C:\Program Files\Java\jre7\bin;
C:\msysgit\bin;C:\Program Files\Git\cmd;C:\Program Files\nodejs;;C:\Program Files\NTP\bin;C:\Program Files\TortoiseGit\b
in;C:\Program Files\Mercurial;C:\MinGW\bin;C:\MinGW\msys\1.0\bin;C:\Program Files\QuickTime\QTSystem;C:\Program Files\To
rtoiseSVN\bin;C:\Program Files\QuickTime\QTSystem\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program File
s\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files\MiKTeX 2.9\miktex\bin\;C:\Program Files\Intel\WiFi\bin\;C:\Progr
am Files\Common Files\Intel\WirelessCommon\;C:\Program Files\Google\Cloud SDK\google-cloud-sdk\bin;C:\Program Files\Goog
le\Cloud SDK\google-cloud-sdk.staging\bin;C:\Go\bin;C:\Program Files\Scrivener;C:\Program Files\Java\jre7\bin;C:\Program
Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\]
Cloud SDK on PATH: [True]

Installation Properties: [C:\Program Files\Google\Cloud SDK\google-cloud-sdk\properties]
User Config Directory: [C:\Users\acollins\AppData\Roaming\gcloud]
User Properties: [C:\Users\acollins\AppData\Roaming\gcloud\properties]
Current Workspace: [None]
Workspace Config Directory: [None]
Workspace Properties: [None]

Account: [alistaircollins21@gmail.com]
Project: [None]

Current Properties:
[core]
account: [alistaircollins21@gmail.com]
disable_usage_reporting: [False]

Comments

al...@gmail.com <al...@gmail.com> #2Apr 2, 2015 10:54AM

I can confirm this on Android 4.4.4 with Cyanogen Oneplus.

[Deleted User] <[Deleted User]> #3Apr 10, 2015 08:33PM

Still present in Android Lollipop 5.0.1 on Nexus 5 and Nexus 6. Is anyone at Google actually reading the bug reports? This one is quite old and should be very easy to fix...

sj...@blinkfire.com <sj...@blinkfire.com> #4May 9, 2015 11:32AM

I have also faced this issue in lollipop nexus 5: Here is the bug I logged regarding this in stack overflow

http://stackoverflow.com/questions/27280402/every-connection-request-is-being-treated-as-direct-connect-request-android-bl

sj...@blinkfire.com <sj...@blinkfire.com> #5May 9, 2015 11:32AM

In what way is this obsolete?
As you can see, this is still present in the master branch at

https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/bluetooth/BluetoothGatt.java.

Why not just fix it by moving "mAutoConnect = autoConnect;" above "if (!registerApp(callback)) {"?

dl...@google.com <dl...@google.com> #6May 9, 2015 07:48PM

I just got 5.1.1 update on Samsung Galaxy S6 and it triggered the same error. Cant connect to BLE devices, always getting GATT 133 error.

sj...@blinkfire.com <sj...@blinkfire.com> #7May 9, 2015 08:59PM

Same problem here, cannot send data to BLE device, return status code 133. However my app works fine on android 4.3.

je...@gmail.com <je...@gmail.com> #8May 12, 2015 02:01AM

If you get status 133 from onConnectionStateChange() it means that the connection attempt timed out. This happens to direct connections (autoConnect = false) after 10 seconds if I recall correctly.

al...@gmail.com <al...@gmail.com> #9May 21, 2015 09:53AM

Thanks for your comment, I'm actually get a 133 error/status code on "onCharacteristicWrite()", connection to the BLE device does not have any problem. Regards, J.

pa...@gmail.com <pa...@gmail.com> #10May 25, 2015 01:38AM

On S6 the old api's does not workm try with new scan api's

je...@gmail.com <je...@gmail.com> #11May 30, 2015 05:11PM

I can confirm this issue with the Galaxy S6 and Android 5.1. Any workaround?

je...@google.com <je...@google.com> #12Jun 1, 2015 08:50PM

Assigned to je...@google.com.

You can use

https://github.com/Polidea/RxAndroidBle library which has implemented a workaround for this issue. Dealing with bluetooth on Android is really painful and this library solves many problems - it has a dedicated blocking queue for all ble operations and runs them on ui thread.

If you are curious, you can find the implementation of the workaround here:

https://github.com/Polidea/RxAndroidBle/blob/master/rxandroidble/src/main/java/com/polidea/rxandroidble/internal/util/BleConnectionCompat.java

dl...@google.com <dl...@google.com> #13Jun 1, 2015 09:04PM

[Comment deleted]

je...@gmail.com <je...@gmail.com> #14Jun 1, 2015 09:24PM

@polidea Your library doesn't seem to solve the dreaded status=133, I tried your sample app (using com.polidea.rxandroidble:rxandroidble:1.0.1) from the project. Tried to connect disconnect several times in a row and after some tries ( 4-6 tries ) it started to give me status = 133.

But, Kudos to your simple apis. Thanks

[Deleted User] <[Deleted User]> #15Jun 2, 2015 09:58AM

I'm not the author of the library but i think there's not much that can be done about the dreaded status 133. At the most, close the current gatt and try to reconnect.

vg...@gmail.com <vg...@gmail.com> #16Jun 5, 2015 12:13PM

CL here :)

https://android-review.googlesource.com/#/c/146535/

ar...@gmail.com <ar...@gmail.com> #17Jun 6, 2015 06:52AM

[Comment deleted]

ar...@gmail.com <ar...@gmail.com> #18Jun 6, 2015 08:55AM

Stupid question maybe, but this fix will be backwards compatible i hope?

da...@gmail.com <da...@gmail.com> #19Jun 10, 2015 06:28PM

What is needed to be done to add this fix to our applications?

ni...@gmail.com <ni...@gmail.com> #20Jun 30, 2015 07:27AM

There is a similar race condition as well.
If you call device.connectGatt(...) and shortly after call gatt.disconnect() to abort the connection attempt, the connection attempt will NOT be aborted.

The root cause is that after device.connectGatt(...) is called there will soon be an onClientRegistered callback which will set mClientIf to some nonzero value. But the disconnect method returns directly if mClientIf is 0, which happens if the callback has not arrived yet.

sk...@gmail.com <sk...@gmail.com> #21Jun 30, 2015 06:29PM

Same problem on Nexus 6P running Nougat.

Also GATT_MAX_PHY_CHANNEL seems to be still set at 6 (max clientIf = 6), which is less than half the connections that BLE chips typically support (leading to status 133 error as connections are exhauasted).

al...@wtvision.com <al...@wtvision.com> #22Jul 3, 2015 02:06PM

Any update or workaround on this issue? Still experiencing it

[Deleted User] <[Deleted User]> #23Jul 9, 2015 04:41PM

It has been fixed in the latest Android. Which device/Android version do you experience it on? On older devices you need to use reflection to workaround the issue.

at...@gmail.com <at...@gmail.com> #24Jul 9, 2015 05:04PM

The workaround is explained in my original message.

Let me give further context:
With BLE there are two ways to create a connection, either directly to the device using the "LE Create Connection" command or by adding the device or devices to a whitelist and requesting a connection to the whitelist.

Android's BLE stack, at least at the time I found this bug, used the former method when autoConnect=false (they call this "direct") and the latter when autoConnect=true (they call this "background").

A "direct" connection will time out in short order with 133 if it does not complete, mitigation of that is to call the connect() on the BluetoothGatt after the failure, this causes a background connection which either does not time out or has a much longer timeout.

Now, another difference between direct and background connection is that the direct connection attempt is more "aggressive" (scan window is larger) than the background connection. This may lead the background connection to take longer to complete.

The scan window size varies by device, at the time I found this bug it was 50% for a direct connection and 0.9% for a background connection on one device, but 50% and 50% on another so YMMV.

TL;DR;

Always call BluetoothDevice#connectGatt() with autoConnect=false (the race condition does not affect that case). If that connection times out you will get a callback with status=133. Then call BluetoothGatt#connect() to initiate a background connection.

Optionally if you want a direct connection, close() and get rid of the BluetoothGatt and create a new one with autoConnect=false.

zj...@google.com <zj...@google.com> #25Jul 9, 2015 05:12PM

#23 What do you mean by ~"use reflection to workaround the issue"? Can you provide a code sample.

at...@gmail.com <at...@gmail.com> #26Jul 9, 2015 05:16PM

Hello All,

I am using below method to connect the BLE device with android mobile bluetooth.

mBluetoothGatt = device.connectGatt(this, false, mGattCallback);

But this is only worked for first time connect

If I take out the ble device away beyond the range then come in range again then it is not reconnect the ble device autometically.

Can any one know how to auto reconnect the ble device when come in range.

I am using "ITUS key" ble device to work on.

Thanks.

er...@gmail.com <er...@gmail.com> #27Jul 9, 2015 05:18PM

I have met this condition before, it looks like the android device has "forgot" the bonding information it holds, hence the second time connection fails. Try to remove old bonding then bond again see if it works.

zj...@google.com <zj...@google.com> #28Jul 9, 2015 05:20PM

Hello,

I have used below mGattCallBack method and when device is DISCONNECTED, i unpaired it.

private final BluetoothGattCallback mGattCallback = new BluetoothGattCallback() {
@Override
public void onConnectionStateChange(BluetoothGatt gatt, int status, int newState) {
String intentAction;
switch (newState) {
case BluetoothProfile.STATE_CONNECTED: {
Preferences.AppLog("Connected to GATT server.");
intentAction = ACTION_GATT_CONNECTED;
broadcastUpdate(intentAction);
mBluetoothGatt.discoverServices();
break;
}
case BluetoothProfile.STATE_DISCONNECTED: {
Preferences.AppLog("Disconnected from GATT server.");
intentAction = ACTION_GATT_DISCONNECTED;
broadcastUpdate(intentAction);

if (gatt.getDevice() != null) {
unpairDevice(gatt.getDevice());
}
break;
}
}
}
}

public static void unpairDevice(BluetoothDevice device) {
try {
Method m = device.getClass().getMethod("removeBond", (Class[]) null);
m.invoke(device, (Object[]) null);
} catch (Exception e) {
Log.e(TAG, e.getMessage());
}
}
But still it is not auto reconnect when I bring the device in range.

zj...@google.com <zj...@google.com> #29Jul 13, 2015 06:26PM

Status: Won't Fix (Obsolete)

You still need to call BluetoothDevice.connectGatt() to connect to the device. The approach we had to get around this problem is like this:
1. Once BLE is disconnected (You are out of range), do not remove bond at this point, call getBluetoothLeScanner().startScan() to keep on scanning for your desired device.
2. When you are in range, the desired device BluetoothDevice is found in onScanResult callback.
3. Connect to it, if it fails and give you error code 22 or 133 (some other codes may apply, google didn't document this very well). go to step 4.
3. Now check bonding for this BluetoothDevice whether is bonded or not, always remove old and create a new bonding to it.
4. Now connect to it again.
Problem: phones may pop up bonding dialogue everytime it reconnects.

ji...@google.com <ji...@google.com> #30Jul 24, 2015 03:05AM

ja...@topsinfosolutions.com: Set the second parameter (autoConnect) to true. That way it will automatically try to reconnect when the device comes back in range. Or use mBluetoothGatt.connect() to also enable autoConnect.

zj...@google.com <zj...@google.com> #31Jul 24, 2015 03:13PM

Status: Assigned (reopened)

em...@gmail.com: I have already tried with autoConnect to true but when device comes back in range it call the method , mBluetoothGatt = device.connectGatt(this, true, mGattCallback); but mGattCallback did not return any thing.

vi...@google.com <vi...@google.com> #32Jul 24, 2015 03:57PM

I'm trying to do the same thing.

What am I missing? Why is it necessary to remove the old bonding if that should be used to identify the device? What is the purpose of bonding then?

[Deleted User] <[Deleted User]> #33Aug 12, 2015 08:04PM

Hi, any luck on this? am also working on the same case. Please update the thread.

zj...@google.com <zj...@google.com> #34Aug 12, 2015 10:16PM

Seems other systems have similar issue:

http://en.miui.com/thread-5569358-1-1.html

dl...@google.com <dl...@google.com> #35Oct 8, 2015 06:43PM