Add error screen no connection on Automotive by cddu33 · Pull Request #6857 · home-assistant/android

cddu33 · 2026-05-17T11:10:39Z

Summary

Add connection availability monitoring to Automotive

Fixes #6846 — users accessing the app through the Harman Ignite Store were stuck on an infinite loading screen when no internet connection was available, with no error feedback (unlike the standard app).

When the app is running in the car and loses its connection to the Home Assistant server, the user is now shown a dedicated "No connection".

A new ConnectionAvailabilityMonitor polls the Home Assistant WebSocket at a healthy 15 second cadence, switching to a faster 1 second cadence when pings start failing.
To avoid flashing an error screen on transient network blips, the monitor waits for a 10 second grace period before declaring the connection Unavailable; if a ping recovers within that window, no error is surfaced.
Once the connection is back, the monitor emits Available again at the next successful poll and the error screen is dismissed automatically.
When no server is registered yet, the monitor reports Available so the onboarding flow is never blocked by this check.

HaCarAppService observes this state and pushes/pops NoConnectionScreen on the Android Auto screen stack accordingly, keeping the rest of the navigation untouched.

The flow logic (grace period, recovery during grace, healthy→degraded transitions, recovery from unavailable) is covered by unit tests in ConnectionAvailabilityMonitorTest.

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

Copilot

Pull request overview

Adds connection availability monitoring to the Automotive (Android Auto) experience so users see a dedicated “No connection” screen instead of an infinite loading state when connectivity is lost.

Changes:

Introduces a ConnectionAvailabilityMonitor that polls WebSocket pings with a grace period before declaring the connection unavailable
Adds an Automotive NoConnectionScreen and integrates it into HaCarAppService screen stack handling
Adds unit tests covering the monitor’s grace-period and recovery behavior

Reviewed changes

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

Show a summary per file

File	Description
common/src/main/res/values/strings.xml	Adds a new Automotive title string for the no-connection header
app/src/main/kotlin/io/homeassistant/companion/android/vehicle/ConnectionAvailabilityMonitor.kt	Implements connection availability monitoring and Hilt binding
app/src/main/kotlin/io/homeassistant/companion/android/vehicle/HaCarAppService.kt	Observes availability and pushes/pops the no-connection screen
app/src/main/kotlin/io/homeassistant/companion/android/vehicle/NoConnectionScreen.kt	New Automotive error screen UI
app/src/test/kotlin/io/homeassistant/companion/android/vehicle/ConnectionAvailabilityMonitorTest.kt	Unit tests for monitor state transitions and grace period

Comments suppressed due to low confidence (1)

app/src/main/kotlin/io/homeassistant/companion/android/vehicle/HaCarAppService.kt:144

If the user dismisses NoConnectionScreen via the host back action while the connection is still unavailable, no further Unavailable emissions occur (the flow only emits on state transitions), so the screen may never be shown again until connectivity changes. Consider preventing dismissal of NoConnectionScreen while unavailable, or re-check/push the screen when it is not on top even if the availability state hasn’t changed.

                    val screenManager = carContext.getCarService(ScreenManager::class.java)
                    val topIsNoConnection = screenManager.top is NoConnectionScreen
                    when (state) {
                        ConnectionAvailability.Unavailable -> if (!topIsNoConnection) {
                            screenManager.push(NoConnectionScreen(carContext))
                        }
                        ConnectionAvailability.Available -> if (topIsNoConnection) {
                            screenManager.pop()
                        }
                    }

TimoPtr · 2026-05-18T10:16:47Z

@@ -0,0 +1,88 @@
+package io.homeassistant.companion.android.vehicle


Let's not make this specific to vehicle, also it is a public API so I expect to see documentation on the public part of this class (explaining the behavior not the implementation).

TimoPtr · 2026-05-18T10:17:26Z

+internal val GRACE_PERIOD: Duration = 10.seconds
+
+internal val HEALTHY_POLL_INTERVAL: Duration = 15.seconds
+
+internal val DEGRADED_POLL_INTERVAL: Duration = 1.seconds


This probably should only be @VisibleForTesting

TimoPtr · 2026-05-18T10:19:15Z

+            if (!serverManager.isRegistered()) {
+                true
+            } else {
+                serverManager.webSocketRepository().sendPing()


You are only checking the current active server, it needs to be documented, in the class documentation for instance.

TimoPtr · 2026-05-18T10:24:42Z

+            .setTint(CarColor.DEFAULT)
+            .build()
+
+        return MessageTemplate.Builder(carContext.getString(R.string.error_connection_failed_no_network))


You are assuming that when we don't have a WebSocket connection we have no network. It might not be true, the server might simply be down. If you check to the new error screen when we are not able to reach out to the server we show a way to test what is currently wrong check FrontendConnectionErrorStateProvider

We could replicate this or simply change the message to say that the connection to the server is broken maybe?

@jpelgrom might have another opinion on the wording used.

We could replicate this or simply change the message to say that the connection to the server is broken maybe?

@jpelgrom might have another opinion on the wording used.

Replicating the entire screen feels like a bit much for a car, but a general header "unable to connect" and a short sentence describing the reason, like the main app, would be nice I think. We also don't have to discuss the wording in that case ;)

Agree that we don't need to replicate, but the message and the logo should not say that there are no network available that's potentially not the issue, so it should be more generic.

TimoPtr · 2026-05-18T10:25:31Z

+import org.junit.jupiter.api.extension.ExtendWith
+
+@OptIn(ExperimentalCoroutinesApi::class)
+@ExtendWith(MainDispatcherJUnit5Extension::class, ConsoleLogExtension::class)


Suggested change

@ExtendWith(MainDispatcherJUnit5Extension::class, ConsoleLogExtension::class)

@ExtendWith(ConsoleLogExtension::class)

I don't think you need the extension for the MainDispatcher here.

TimoPtr · 2026-05-18T10:26:05Z

+
+    private fun createMonitor(): ConnectionAvailabilityMonitor = ConnectionAvailabilityMonitorImpl(serverManager)
+
+    private fun stubPings(vararg results: Boolean) {


Suggested change

private fun stubPings(vararg results: Boolean) {

private fun mockPings(vararg results: Boolean) {

A stub is something dumb, here it's real mocking.

TimoPtr · 2026-05-18T10:28:06Z

+        val webSocketRepository = mockk<WebSocketRepository>()
+        val iterator = results.iterator()
+        var last = results.last()
+        coEvery { webSocketRepository.sendPing() } answers {


I think you could use returnsMany instead of using the iterator.

TimoPtr

Thanks for taking this bug, we need to check the wording of the error page and after that we are good to merge.

cddu33 added 2 commits May 17, 2026 11:53

add screen error no connection, testui create by claude

dcf0d45

same value connection avaibility and tes; add test nok to ok

16db884

home-assistant Bot added the cla-signed label May 17, 2026

cddu33 had a problem deploying to ui-test May 17, 2026 11:27 — with GitHub Actions Failure

cddu33 marked this pull request as ready for review May 17, 2026 11:46

Copilot AI review requested due to automatic review settings May 17, 2026 11:46

Copilot started reviewing on behalf of cddu33 May 17, 2026 11:46 View session

Copilot AI reviewed May 17, 2026

View reviewed changes

cddu33 added 2 commits May 17, 2026 13:56

correct NoConnectionScreen via the host back action

037591c

correct sticky stub connectivity test

707dba9

cddu33 had a problem deploying to ui-test May 17, 2026 12:26 — with GitHub Actions Failure

TimoPtr reviewed May 18, 2026

View reviewed changes

TimoPtr requested a review from jpelgrom May 18, 2026 10:29

		@@ -0,0 +1,88 @@
		package io.homeassistant.companion.android.vehicle

	@ExtendWith(MainDispatcherJUnit5Extension::class, ConsoleLogExtension::class)
	@ExtendWith(ConsoleLogExtension::class)


		private fun createMonitor(): ConnectionAvailabilityMonitor = ConnectionAvailabilityMonitorImpl(serverManager)

		private fun stubPings(vararg results: Boolean) {

	private fun stubPings(vararg results: Boolean) {
	private fun mockPings(vararg results: Boolean) {

Uh oh!

Conversation

cddu33 commented May 17, 2026

Summary

Checklist

Screenshots

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TimoPtr left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants