Rework UI of settings wear favorite screen to use Material3

[aishsidya0402-netizen]

Summary

This PR migrates the Wear OS settings "favorites" screen's top app bar (SettingsWearTopAppBar in SettingsWearHomeView.kt) from Material2 to Material3, using the app's existing HATopBar composable (common/compose/composable/HATopBar.kt). This brings the screen in line with the broader Material3 migration effort tracked in #5420.

The screen was still importing androidx.compose.material.IconButton and androidx.compose.material.TopAppBar (Material2), while most of the rest of the app has already migrated to Material3. Rather than manually swapping in androidx.compose.material3 components, this PR delegates to the app's existing HATopBar composable, which already wraps TopAppBar with Material3 theming and supports optional back/close/help buttons. This removes now-unused Material2 and iconics imports, and the public signature of SettingsWearTopAppBar (title, onBackClicked, modifier, docsLink) was kept unchanged, so all 5 existing call sites in LoadSettingsHomeView's nav graph required no changes.

Closes #6300

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.

Screenshots

On-device screenshots are pending; I'll add these as a follow-up comment once local emulator verification is complete.

Any other notes

I added SettingsWearTopAppBarTest.kt covering help-icon visibility (shown/hidden based on docsLink), back-icon click behavior, and title rendering. The test resolves correctly and is recognized by the JUnit test runner, but I haven't been able to execute it locally yet. The wear module's debug build variant requires a google-services.json with a client entry matching the debug-suffixed package name, which isn't included in the public repo. If there's a documented local workaround for this, I'd really appreciate a pointer; otherwise, happy to confirm it passes in CI.

[home-assistant]

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

[Copilot]

Pull request overview

This PR continues the app’s Material3 migration by updating the Wear settings “favorites” screen top app bar to use the existing Material3 HATopBar composable from :common, and adds a Compose UI test intended to validate the app bar behavior.

Changes:

• Replaced the Material2 TopAppBar implementation in SettingsWearTopAppBar with :common’s Material3 HATopBar.
• Added a new Compose test for SettingsWearTopAppBar behavior (help icon visibility, back click, title).
• Added a duplicate Gradle property and introduced a new committed IDE Markdown settings file.

Reviewed changes

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

File	Description
app/src/full/kotlin/io/homeassistant/companion/android/settings/wear/views/SettingsWearHomeView.kt	Migrates the Wear settings top bar to the shared Material3 HATopBar.
wear/src/test/kotlin/io/homeassistant/companion/android/settings/wear/views/SettingsWearTopAppBarTest.kt	Adds Compose tests for the top bar behavior, but currently targets the wrong module/source set and contains an unreliable assertion.
gradle.properties	Adds a duplicate org.gradle.tooling.parallel entry.
.idea/markdown.xml	Adds an IDE-specific Markdown preview provider setting that may not be appropriate to commit.

Files not reviewed (1)

• .idea/markdown.xml: Generated file

Suppressed comments (1)

wear/src/test/kotlin/io/homeassistant/companion/android/settings/wear/views/SettingsWearTopAppBarTest.kt:63

• assert(backClicked) uses JVM assertions, which are typically disabled for Gradle test tasks unless explicitly enabled; this can cause the test to pass even when backClicked is false. Use a JUnit assertion instead so the test reliably fails when the callback isn't invoked.

        assert(backClicked) { "Expected onBackClicked to be invoked after tapping the back icon" }

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[aishsidya0402-netizen]

@home-assistant recheck

[aishsidya0402-netizen]

@home-assistant recheck

[jpelgrom]

👋 Thanks for contributing!

The issue you're referencing involves more work than you're doing now, and in fact a completely different screen. Are you going to expand this PR over time?

You can review the entity widget settings screen for a recent example of our Compose patterns and what is expected. For new Compose work, please make sure to add screenshot testing as well.

The screen you're changing lives in the app module, so the test should live in app as well and not in wear.

The wear module's debug build variant requires a google-services.json with a client entry matching the debug-suffixed package name, which isn't included in the public repo. If there's a documented local workaround for this, I'd really appreciate a pointer

You can copy our mock files for testing, see the developer documentation.

[aishsidya0402-netizen]

Hi Joris, thanks for the detailed feedback!

To clarify scope: this PR focuses specifically on migrating the top app bar (SettingsWearTopAppBar) in the wear settings screen to the shared Material3 HATopBar composable, as part of the broader migration tracked in #5420. I don't currently have plans to expand it to cover the full scope of #6300; if that involves a different screen, I may have scoped this more narrowly than the issue intended. Could you clarify which screen you're referring to? Happy to either adjust this PR's description to reflect the narrower scope, split it into a more accurately-scoped issue, or take a stab at the larger scope if you can point me in the right direction.

Re: the test module, fixed, moved SettingsWearTopAppBarTest.kt to app/src/testFull to match where the production code lives.

Re: google-services.json, I tried running the test locally after the move and confirmed the same blocker exists in :app as well (Execution failed for task ':app:processFullDebugGoogleServices' > File google-services.json is missing). So it's not module-specific seems to be a broader gap in the public repo setup around this config file. I haven't found a documented workaround. Happy to confirm it passes in CI instead once the workflow is approved.

Re: screenshot testing, given I'm on a tight course deadline tonight, I likely won't be able to add this before submission, but I'm glad to follow up with it afterward if that works, following the guide you linked.

Thanks again for taking the time to review!

Stale

[jpelgrom]

Could you clarify which screen you're referring to?

I'm referring to the favorites screen, that is the issue you've linked and mentioned in your PR title.

You're now adjusting the parent which holds the navigation for all Wear OS settings in the phone app, which will also be shown on other screens, doesn't fully change the favorites screen, and results in a combination of Material 2 and 3 components which should be avoided.

Re: google-services.json, I tried running the test locally after the move and confirmed the same blocker exists in :app as well

Did you rename the mock file? I see my link wasn't to the specific page for it, the correct link is: https://developers.home-assistant.io/docs/android/get_started#setting-up-a-mock-firebase-project.

---

For us to consider this, we would need this scoped to the favorites screen and do the full screen, so not a component shared across multiple screens creating a combination of M2 and M3, and also with the updated architecture I pointed out (example: #7007 + #7302).