LinkHandler better management of params in deep link URI

[TimoPtr]

Summary

Fixes #7263

Shortcuts store their destination in a homeassistant://navigate deep link, and the builder
percent-encoded the path's query into the path itself (?kiosk became %3Fkiosk), so the frontend
never received it. Introduced with the FrontendScreen migration, beta only.

• Build the deep link from path, query and fragment components so the query survives.
• When parsing, rebuild the frontend path from the encoded components and drop the app's
  server_id/server parameters instead of forwarding the whole deep link string.
• Links persisted by the affected betas are not healed; recreating the shortcut fixes them.
• Round-trip tests for query, fragment, encoding and absolute URL cases.

Updated the UI of the shortcut edition to make sure the link is a valid URL to use (does not contains space for instance).

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.
• I have read the Open Home Foundation AI Policy.

Select exactly one option that describes AI usage in this contribution:

• I have not used AI for this contribution.
• AI assistance was used for this contribution.
• AI fully generated the code for this contribution, but I've reviewed and understood it before submitting and will respond without AI during review.

Any other notes

I'm always kind of scared when messing with URL encoding/decoding and hopefully I didn't miss anything. I spent more time challenging Claude on this than fixing the issue itself.

[TimoPtr]

Users that entered the beta 2026.7.4 and 7.5 with % in their shortcut will needs to open back the shortcut and update them manually. I didn't want to include a auto heal there that would increase complexity even more the logic.

[Copilot]

Pull request overview

Fixes shortcut/deep-link URI handling so frontend query/fragment parameters (notably ?kiosk) survive round-trips through homeassistant://navigate links, aligning with the FrontendScreen migration behavior.

Changes:

• Build homeassistant://navigate deep links by splitting path/query/fragment components so queries don’t get percent-encoded into the path.
• When parsing navigate links, reconstruct the frontend raw path from encoded components while dropping app-only server/server_id parameters.
• Add round-trip tests covering query, fragment, encoding preservation, and absolute URL cases.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
app/src/main/kotlin/io/homeassistant/companion/android/launch/link/LinkHandler.kt	Reworks navigate deep link build/parse to preserve query/fragment and strip server-selection params from the forwarded frontend path.
app/src/test/kotlin/io/homeassistant/companion/android/launch/link/LinkHandlerTest.kt	Updates existing expectations and adds coverage for query/fragment round-trips and encoding edge cases.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (2)

app/src/main/kotlin/io/homeassistant/companion/android/launch/link/LinkHandler.kt:62

• isValidFrontendRawPath currently only compares against Uri.encode(...) while allowing % to pass through. This can return true for inputs with invalid percent-escapes (e.g. "...%2G..." or a lone %), but those will fail later when parsing via java.net.URI (see UrlUtil.handle) and may also throw when using Uri.Builder encoded setters. Consider validating the rawPath is syntactically parseable as a URI in addition to the encoding check.

internal fun isValidFrontendRawPath(rawPath: String): Boolean =
    rawPath == Uri.encode(rawPath, "$QUERY_FRAGMENT_ALLOWED_CHARS#")

app/src/test/kotlin/io/homeassistant/companion/android/launch/link/LinkHandlerTest.kt:300

• Consider extending this validation test set with a case for invalid percent-escapes (e.g. %2G or a trailing %). These currently pass the Uri.encode equality check when % is allowed, but will fail when parsed as a java.net.URI later.

    fun `Given compliant and non-compliant raw paths when validating then only compliant ones pass`() {
        assertTrue(isValidFrontendRawPath("lovelace/dashboard-1?kiosk&edit=1#section"))
        assertTrue(isValidFrontendRawPath("dashboard/my%20room"))
        assertFalse(isValidFrontendRawPath("lovelace/my room"))
        assertFalse(isValidFrontendRawPath("lovelace/café"))
    }

[jpelgrom]

If invalid characters are encoded, why disallow them here? If I enter a URL with an invalid character like a space in it in my browser it also encodes it (maybe not in the address bar but it is if you check developer tools), I'd think expecting the app to do the same is valid.

[TimoPtr]

Most of browser these day capture that and make a search request instead of encoding I think. I think it's better to be strict here, since reloading then after might show the encoded version.

[jpelgrom]

Testing in Firefox and Chrome and it replaces spaces with %20 if it's after the TLD. If it's in the TLD part it does suggest searching first.

I do agree with the rationale that it might change after reloading from database so it should be avoided, so OK for restricting it.