When we call 'dataClient.getDataItem(xyz).await()' do we need to call release on the 'DataItemBuffer' item that gets returned once we're done using it ?

Based on the API documentation: https://developers.google.com/android/reference/com/google/android/gms/wearable/DataClient#public-abstract-taskdataitembuffer-getdataitems-uri-uri Callers must call

AbstractDataBuffer.release()

on the returned buffer when finished processing results. Hence you should release the items.

Should I use the same here?

BT is usually on when available, so you will have a persistent connection. You should assume when BT is not available and you are on Wifi/LTE that you only occasionally have a network. I'm not sure it's what you are seeing, but expect more delays when not on BT.

I'm using it for simple communication, send request to phone, phone sends phone battery back to watch. I'm using setUrgent and also sending system.currentTimeinMillis to ensure every data sending task is different (I assume this is needed for listener to receive event)

Is it just delay/unpredictable behaviour, or does it never arrive?

Arrives when I enable BT. With Wifi / Data it acts unpredictable. Sometimes works, sometimes not at all. I thought that this was an issue of the previous Play Store Services (23.07.14) but this behavior seems to appear back with every other Play Services update

@amoledwatchfaces Yes you should

@louiscad I'm asking because in the link above, it's only mentioned under DataItemBuffer and in my code, I'm only using DataEventBuffer

Oh, then it shouldn't be needed unless you are using the objects beyond the callback (in which case you should also call freeze() first and foremost) @amoledwatchfaces

@louiscad So using it like here, only inside onDataChange, should be fine, yes?

Should be fine

Thanks 🙂

Yeah I find this happens as well; can you try wiping the emulator, starting it back up, install your app fresh, and then see what happens?

@Arjun Achatz I'm using wear os emulator and it is connected to my phone. I think the mobile part is the problem because I'm pretty sure watch app is sending data task successfully. I'll try two emulators then. Any Idea why everything works fine when I install signed apks but not work when I upload aabs to the internal / public release?

I also use a wear emulator paired with a physical device. The same thing happens to me every now and then and it drives me bonkers. What I meant was could you wipe your wear emulator and install the app fresh, and then see what happens

Ok, going to try that

It's definitely something 😅 @louiscad ^

@Arjun Achatz @louiscad wiped also Galaxy Watch4 and communication works fine too. We can't expect from users to do this. When this error occurs it's basically impossible for user to use our apps when their device are not connected with BT. I'll try to wipe cache / force stop play services on my Gen 6. If it helps, then it's definitely some issue between Play Services Updates (Wear OS)

Not sure who the right person is but we definitely need to escalate it. Maybe you can report it as an issue ?

Definitely report an issue, even if you found a workaround, it should obviously work without such effort.

@yschimke I'm new to this. Should I use Google Issue tracker page?

This isn't exactly the right link, but this is probably the best place to start. https://developer.android.com/jetpack/androidx/releases/wear#feedback

Thanks 🙂

I always check the available node from CapacityClient, before i send any data between the wear and android apps. I will inform user to reconnect BT. Sometime, the connection just lost.

Problem is that the node is actually connected. Not nearby, but definitely connected because I even can remotely open play store app on it. (remote activity helper). Also, we're talking about devices connected with WiFi/ mobile data. Via BT, everything works fine