• Replies 59 replies
  • Subscribers 26 subscribers
  • Views 19588 views
  • Users 0 members are here
Options
Related

FAILURE_DURING_TRANSFER issue again (now using Comm sample )

ArtaudAntonin / Jiri Richter
over 7 years ago
Environment:
- Ubuntu 16.04
- Vivoactive V4.40, CIQ1.4.2
- Android 6.0.1
- Android Studio 2.3.2
- CIQ SDK 2.2.5
- CIQ Android Mobile SDK v1.4

A detailed description of the issue:

Using modified Comm samples from CIQ SDK 2.2.5 and CIQ Android Mobile SDK v1.4, I can get to the point where any attempt at communication phone => watch results in FAILURE_DURING_TRANSFER, while in the other direction messages go through normally.

Steps to reproduce the issue:

1. Install both apps from the following repository: https://github.com/Artaud/CIQ-Comm-failure-sample and run them.
2. On Android, tap on your connected device to select it. The app will now start receiving messages from watch.
3. Try to send any message to the watch and check the Android log. You'll get FAILURE_DURING_TRANSFER very early.
4. Turn off the app on watch and try to send any message from the phone now. Normally, you should get SUCCESS even if the app is not running, but now you get FAILURE_DURING_TRANSFER forever.


Additional information:

The bug makes any serious two-way communication impossible.

Code sample to reproduce the issue:

https://github.com/Artaud/CIQ-Comm-failure-sample
  • over 7 years ago
    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.
  • over 7 years ago
    Hey Jiri,

    Sorry for the delay in response. I've been working on trying to reproduce this one for the past couple of days along with a few others. Some machine issues got in the way along the way. I'm creating a ticket to try and investigate anyway. Do you think you could send me a build of each of these apps at [email][email protected][/email] to help speed the process along?

    Thanks,
    -Coleman
  • over 7 years ago
    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
  • over 7 years ago
    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
  • over 7 years ago
    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)

  • over 7 years ago
    It might also be helpful to post which version of GCM you are using PedlarStudios, if the issue turns out to be within GCM.
  • over 7 years ago
    Great point. I am running GCM 3.2.2 on an Android 5.1.1 phone (Nexus 4).
  • over 7 years ago
    @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.
  • over 7 years ago
    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