Adjust WebsocketManager check to avoid location usage

[jpelgrom]

Summary

Adjust how WebsocketManager checks whether to run to return early if conditions won't be met, instead of getting all possible info for all settings and only then returning. This should reduce the latest Android 16 QPR showing a 'blue location dot' because the app checks internal/external on screen on/off for the app, when there might not be a reason to do so.

Logs showed activity from ServerConnectionStateProviderImpl immediately after the WebsocketManager is started, which this change should avoid.

2026-03-16 12:53:59.678 31288-31324 WM-SystemJobScheduler   io.homeassistant.companion.android   D  Scheduling work ID 0a201fd2-49fd-42f3-ac73-c7211ab20a71Job ID 156605
2026-03-16 12:53:59.681 31288-31324 WM-GreedyScheduler      io.homeassistant.companion.android   D  Starting work for 0a201fd2-49fd-42f3-ac73-c7211ab20a71
2026-03-16 12:53:59.683 31288-31288 WM-SystemJobService     io.homeassistant.companion.android   D  onStartJob for WorkGenerationalId(workSpecId=0a201fd2-49fd-42f3-ac73-c7211ab20a71, generation=0)
2026-03-16 12:53:59.684 31288-31324 WM-Processor            io.homeassistant.companion.android   D  Processor: processing WorkGenerationalId(workSpecId=0a201fd2-49fd-42f3-ac73-c7211ab20a71, generation=0)
2026-03-16 12:53:59.684 31288-31324 WM-Processor            io.homeassistant.companion.android   D  Work WorkGenerationalId(workSpecId=0a201fd2-49fd-42f3-ac73-c7211ab20a71, generation=0) is already enqueued for processing
2026-03-16 12:53:59.687 31288-31288 WM-WorkerWrapper        io.homeassistant.companion.android   D  Starting work for io.homeassistant.companion.android.websocket.WebsocketManager
2026-03-16 12:53:59.693 31288-11554 ServerConn...oviderImpl io.homeassistant.companion.android   D  usesInternalSsid is: true, usesWifi is: true
2026-03-16 12:53:59.694 31288-31318 WM-WorkerWrapper        io.homeassistant.companion.android   I  Worker result SUCCESS for Work [ id=0a201fd2-49fd-42f3-ac73-c7211ab20a71, tags={ io.homeassistant.companion.android.websocket.WebsocketManager } ]

Includes a minor change for !! usage to handle null instead.

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.

Screenshots

n/a

Link to pull request in documentation repositories

n/a

Any other notes

[Copilot]

Pull request overview

This PR refactors WebsocketManager’s per-server run eligibility checks to short-circuit earlier, avoiding unnecessary internal-network detection work (and its side effects, like triggering location-related checks) when the configured WebSocket setting will prevent the worker from running anyway.

Changes:

• Reordered shouldRunForServer to return early for NEVER, no connectivity, and not-registered states before evaluating additional conditions
• Deferred the internal-network (isInternal) evaluation to only when the setting is HOME_WIFI
• Replaced a non-null assertion on PowerManager access with a null-safe check when evaluating the SCREEN_ON setting

[TimoPtr]

If this is the real fix, then I would like a test that verify that we are not calling isInternal in this scenarios, so if we refactor we don't break it again and a small comment.

[jpelgrom]

If this is the real fix, then I would like a test that verify that we are not calling isInternal in this scenarios, so if we refactor we don't break it again and a small comment.

It's not really a 'fix', just being more mindful of unnecessary location usage where it isn't expected or needed, which now stands out more 🔵. I'll try adding tests to make sure it isn't accidentally changed.

[jpelgrom]

Testing WorkManager seems to require instrumentation tests. Useful to learn but more complicated than expected. Please let me know what you think, I tried to avoid refactoring the actual worker.

[TimoPtr]

I'm reluctant to use an instrumentation test here to test the logic. I would like to test the logic in a unit test instead. If Robolectric+mocks doesn't fit then we should extract the logic into a private function and unit test that.

Instrumentation test would be to test the behavior of the worker given some conditions (if we don't find a way to do it in unit tests).

[jpelgrom]

I tried Robolectric but it doesn't seem to like that with the worker. All examples and code from others I could find also do integration tests.

All logic is already in one private function in the worker which returns true/false, so could maybe be used, do you mean other adjustments or how would you test that?

[TimoPtr]

I tried Robolectric but it doesn't seem to like that with the worker. All examples and code from others I could find also do integration tests.

All logic is already in one private function in the worker which returns true/false, so could maybe be used, do you mean other adjustments or how would you test that?

I guess that's the issue you have is because some stuff are initialized in the constructor or within super. You could do it in 2 ways

• Try to mock all the context calls that fails when instantiating the worker from the test
• Simply move the logic into a private function out of the class and test that. (A bit ugly but easier)

[jpelgrom]

With more trying managed to adjust the tests, see the latest commit. Afterwards I rebased and force pushed to resolve a merge conflict before realizing I could have merged upstream into my branch instead, sorry.

[TimoPtr]

Thanks for the extra effort on the tests