Go async for TileReceiver on the watch

[TimoPtr]

Summary

In order to attempt to reduce the number of ANR, I'm proposing to move the TileReceiver action to a dedicated coroutineScope and lauchAsync to make sure it complete under 30s.

I suppose that the current ANRs are caused by server not accessible for multiple reason

• watch bad network
• server not reachable
• ...

In any case not being able to perform the action under 30s is probably something that we should stop.

⚠️ this is quite a change since today it would simply wait that the whole process finish, meaning potentially test all the webhook URLs.

I decided to move the haptic after the success so it gives an idea to the user if it succeed or not. But that might be a bad idea since now he doesn't know that the action was took in consideration. I was thinking about adding an error vibration pattern but it is not something users are used too.

I'm open to discussion on this.

(For the last 7 days) (For the last 60 days)

Checklist

• New or updated tests have been added to cover the changes following the testing guidelines.
• The code follows the project's code style and best_practices.
• The changes have been thoroughly tested, and edge cases have been considered.
• Changes are backward compatible whenever feasible. Any breaking changes are documented in the changelog for users and/or in the code for developers depending on the relevance.

Any other notes

Based on #6467

[jpelgrom]

I decided to move the haptic after the success so it gives an idea to the user if it succeed or not. But that might be a bad idea since now he doesn't know that the action was took in consideration.

At least in my testing, this resulted in a worse UX. The haptics is as feedback to indicate the app registered your touch (it's a small watch screen, nice to get confirmation). Networking on Wear OS can take a while and waiting seconds before getting haptic feedback feels disconnected.

I was thinking about adding an error vibration pattern but it is not something users are used too.

Maybe not used to it but there is a constant (default haptic pattern) for REJECT "A haptic effect to signal the (...) failure of a user interaction.", and iOS has similar patterns for warning/error.

[Copilot]

Pull request overview

This PR aims to reduce Wear OS ANRs by moving Tile action execution off the BroadcastReceiver.onReceive thread and improving coroutine cancellation correctness in entity press handling.

Changes:

• Update TileActionReceiver to execute the entity press action asynchronously (instead of runBlocking) and only trigger haptic feedback after a successful call.
• Update onEntityPressedWithoutState to rethrow CancellationException and log failures when fetching lock entity state.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
wear/src/main/kotlin/io/homeassistant/companion/android/tiles/TileActionReceiver.kt	Moves tile action handling to an async coroutine-based approach intended to avoid ANRs
common/src/main/kotlin/io/homeassistant/companion/android/common/data/integration/Entity.kt	Ensures coroutine cancellation is not swallowed and adds warning logging for lock entity fetch failures

[jpelgrom]

@TimoPtr I see multiple pushes but think you haven't addressed (any reply: agree or disagree) my comment on moving the haptic feedback yet.

[TimoPtr]

@TimoPtr I see multiple pushes but think you haven't addressed (any reply: agree or disagree) my comment on moving the haptic feedback yet.

Not yet, that was one of my next thing. I didn't focus on this one since it was not a high priority TBH.

[TimoPtr]

I decided to bring it back to what it was so we don't introduce a change here (even if the change of Dispatcher might introduce a very small delay).

[jpelgrom]

I decided to bring it back to what it was

I don't follow - previously haptic happened before the network call but now it waits for the network call to complete? onEntityPressedWithoutState is a suspending function while network is happening.