FAILURE_DURING_TRANSFER issue again (now using Comm sample )

Maybe I didn't stress this out enough, but this bug is practically making any two-way communication between watch and phone impossible. I can easily make an app that is just sending messages to watch, or just getting some data from the watch to phone, but in case I need to constantly get some data to phone, I am not able to send any control messages to the watch.

It's also not just a question of timing. Once the FAILURE_DURING_TRANSFER start to show up, there is no way to get rid of it. Even restarting phone and watch does not help. There is probably some magical time duration after which the message queue in GCM somehow clears up and starts sending the messages again.

Pretty please, someone look at this issue....it has been there from the very start and in my opinion it is very serious. I have a few thousands of customers of my app (Sleep as Android) waiting for this to be fixed. If I can do anything to help, please let me know, either contact me via forum, or email ([email protected]).

Thank you very much
Jiri


P.S. With this fixed, it would be possible to do realtime signal processing of the data from watch on the phone, which is very sensible to do when the watch has limited processing capabilities and uses a less powerful language than the phone does.

For others reading this thread -- the issue has been successfully reproduced by Garmin QA team and right now it seems it might be worked on for CIQ 2.3.2

Thanks for the pointer.

Sorry to dredge up this thread, but I ran into the exact same issue described by ArtaudAntonin, with the same Vivoactive device versions. Can anyone confirm if this has been resolved, and if so, in which version(s) of CIQ and/or the CIQ SDK? Alternatively, if it has not been resolved, are there any known workarounds, such as a delay on communications sent from the phone -> watch?

Thanks,
Brandon

If it's helpful, this is a possibly related exception that shows up in the logs in Android Studio after attempting to send data to the watch:

Key com.garmin.android.connectiq.EXTRA_REMOTE_DEVICE expected Long but value was a com.garmin.android.connectiq.IQDevice. The default value 0 was returned.
Attempt to cast generated internal exception:
java.lang.ClassCastException: com.garmin.android.connectiq.IQDevice cannot be cast to java.lang.Long
at android.os.BaseBundle.getLong(BaseBundle.java:834)
at android.content.Intent.getLongExtra(Intent.java:5011)
at com.garmin.android.connectiq.IQMessageReceiver.onReceive(IQMessageReceiver.java:134)
at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:866)
at android.os.Handler.handleCallback(Handler.java:739)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:135)
at android.app.ActivityThread.main(ActivityThread.java:5254)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:903)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:698)

It might also be helpful to post which version of GCM you are using PedlarStudios, if the issue turns out to be within GCM.

Great point. I am running GCM 3.2.2 on an Android 5.1.1 phone (Nexus 4).

@Coleman this is still an issue today. Is there any update on if this is being worked on? I'd really like to use connect iq's sdk instead of writing my own bluetooth protocol implementation from scratch.

A few things here.

PedlarStudios there should be a newer version of GCM out that could be part of the issue. I would try updating and reporting back.

gallo2fire and ArtaudAntonin, we just found bug that I think is causing the constant failure without a restart. I need to track down the ticket, but the very basics are that we might have a leak in certain cases when a comm error occurs. If we run out of space for calls, then we end up failing every call. I'll keep you posted on the status.

Thank you,
-Coleman