Android 2021.12: Wear OS Beta!

Hey Everyone! It’s time for the December 2021 Android release. It has been a while since the last Android release as the team has been very busy working on many new and exciting features. To kick things off we would like to announce that there is now a Wear OS app that you can find in the Play Store alongside todays phone app release!

Wear OS Beta

For the past couple of months the Android repo has been seeing a lot new contributors coming and bringing in some amazing work. There is now a Wear OS Beta app released in the Play Store! A big thank you to leroyboerefijn, dshokouhi, JBassett, Kisty, apo-mak, SkechyWolf and HunterX86 for all your hard work! A lot of work has been done to share the codebase between the phone and the watch because we wanted the watch to also have a standalone experience in case you are not near your phone. The app will remain as a Beta for several months but we feel in its current state it is ready for you to enjoy. The reason we have decided to keep it with a beta label for now is because there is more work to be done and some of the underlying libraries being used have not received a stable release yet.

As of today you can login to the app using either the watch or you can open up the phone app and head over to App Configuration and login using the new Wear OS settings section! Once you are logged in you will see a brief loading screen while we get your entities ready. To avoid some of the loading delays we have a Favorites feature that will allow you to add your most used entities to appear at the top of the app for quick and easy access. You can add/remove these entities using the Settings screen in the watch app or you can add/remove and change the order using the phone app. We highly recommend setting up your favorite entities as they will be available during the loading process.

Screenshot of Wear OS Home Screen

The Wear OS app also offers a tile for even faster access to execute or toggle your devices without needing to open the app. You can select up to 7 entities to toggle or execute inside the settings portion of the app. We recommend using custom MDI icons to easily distinguish between your entities as the default will make it hard to tell apart when you have 2 lights side by side.

Screenshot of Wear OS Tile

Initial support for sensors has also been added! Upon logging in the default battery sensors will be registered in your Home Assistant server. The app will wait for a network connection to provide an update so you won’t have to worry about it constantly maintaining a connection. Soon we will be looking into adding a UI to enable/disable sensors as well as evaluating all current phone sensors and adding whichever ones we can!

One thing to keep in mind is that its important to ensure both the phone and watch are on the same version in order for some of the features to work as expected. Feel free to join the beta and help development by finding bugs and submitting feature requests! Be on the look out for future updates to the Wear OS app!

Screenshot of Wear OS Settings in Phone app

Websockets and Instant Widget Updates

A very big internal feature was also added to both apps this release and that is the introduction of websockets! Websockets is one of the many APIs that Home Assistant offers. With this new API the app can now do cool things like register for entity updates to have instant widgets! Previous versions of the app relied on the Home Assistant REST API to do things like get an entity state or execute a service call. Now with websockets the app will no longer need to poll the server requesting for entity updates as needed, instead we now get a constant stream of entity updates. This allows us to keep your widgets up to date with the latest state or template and also allows us to keep the Android Power Menu up to date. The Wear OS app also benefits by having instant updates on the home screen.

GIF of instant updates

There is still a lot more to be done with respect to websockets but the good news is that foundation is there for more developers to come and consume the API. We have already seen some interest and PRs so I would expect this feature to improve even further over time! Big thank you to JBassett for getting this done!

Theme and UI Updates

In this release we had a lot of changes being done to the overall theme of the app to better fit with the design of the Home Assistant frontend theme. The status and navigation bar will now match your theme of choice. The overall loading experience has also had some improvements to align more closely to the browser loading experience. Thank you to LasseRosenow for all your hard work here!

With the release of Jetpack Compose we have decided to start migrating all UI elements to Compose. If you are familiar with Android Development then you will remember that the UI is always built with XML and then referenced in your activities/fragments. Now with Compose, XML is no longer needed and bulding robust UI’s becomes a breeze. We find these new libraries to be very easy to use and it has allowed us to improve upon our internal architecture to make things easier for new and upcoming features.

In the phone app the entire onboarding experience has been rewritten in Compose, including a brand new welcome screen to help first time users understand what Home Assistant is all about. The notification detail page found in notification history has also received a compose update. The Wear OS home screen is actually built using compose including the new settings screens found in the phone app.

Screenshot of welcome screen

Other Changes

With so many changes since the last update its impossible to list all of the other cool new features but here is a list of some welcomed improvements:

Screenshot of Media Player Widget

  • Support for cookie based authentication by duncf
  • Setting to always try the internal URL first. This is helpful to those who like to leave location off by dshokouhi
  • Support for entity category and state class in sensors by dshokouhi

Big thank you to everyone involved. Please keep those bug reports and feature requests coming! Be sure to watch the State of the Open Home address for what to expect in 2022 and a live demo of some of the features above!


This is a companion discussion topic for the original entry at

Awesome job! Faster and prettier :heart_eyes:

That’s awesome!

Could this be the foundation for notifications without signing a contract with google or apple (and using their servers) for the future? :grinning_face_with_smiling_eyes:

Thats my personal hope. Only concern being is the battery drain we may get by keeping that constant connection. It will need to be thoroughly beta tested once its ready, whenever that is

1 Like

I have no ideas about the technical side but remember (from a user perspective) that signal (messenger app) suffered from heavier battery drain with their first “roll out” of their websocket version (compared to gms at that time). In anyway I didn’t had any (unusal) battery drain and the “issue” was also solved (for others :P) with an update. :battery:

Awesome! Maybe it could be rolled out only in the minimal flavor in the beginning (kind of a public beta if you would like). Good thing is that yummy flavor has no notification at the moment and it will be essentially a new feature to test. I also would call this - maybe mostly gapps free user base - the most interested group for a websocket based notification. :nerd_face:

1 Like

We will not be splitting up the rollout, if you want to test the feature just join the beta and the APK will be ready once its ready. Otherwise both versions will stick to the same release schedule. The idea here is that once we switch both flavors will use it for notifications.

Makes totally sense :bulb:

While I was reading about this solved websocket battery issue in signal I’m came across that my (not to unpopular) k9 mail app also uses permanent websocket connections for the imap push (idle) function. And I can only (once again) tell that it works without any abnormal battery drain. In my case k9-mail (and signal) when only idling without any real usage it will give around 1-2% battery drain in a day. The same drain (1-2%) does my phone also shows for 7 minutes voice calls or 6 mininute gallery app usage.

In the best case your concerns were unfounded, in the worst you (all the devs) will figure it out anyhow :wink:

Hi. Thanks for the hard work on this. Looking forward to test the WearOS app.

Unfortunately, I’m unable to render my dashboard.

I have tried with my regular Lovelace Dashboard and Dwayne Dashboard but both failed to load with the following screen.

This doesn’t seem to be related to the app, possibly related to a custom card? This looks more than just the dashboard as even the sidebar is missing.

Side board is hidden but working :wink:

It might be the custom button card which I’m using in both dashboards.

As a custom card user your first step in troubleshooting should always be to disable them all and try again

I have a MiWatch, it’s a chinese watch without playstore, is there any chance we can get the Wear OS Apk posted separately to the main app somewhere please?

Can not connect my Fossil Gen 5 with my instance. The mobile App is connected, also the right IP of the HA Instance is discoverd. On the watch i only got “Connecting…” and ater short time: can not connect. Try with the app “Wear Device Settings”, watch is shown, welcome screen, right HA instance URL is shown and selected. Enter username and password, go to finsh. Open App on watch but still get only “Connecting…” and ater short time: can not connect , are ther some logs to check?

check github

Thank for the hint. Turn out it was Supervisor crashing unexpectedly. Nothing related to android companion app

yes please get us the on device logs, some users reported that the app allows them to login once they disable BT for initial login.

BT does not help:

12-21 14:54:18.060 25214 3669 D WearOnboardingListener: onMessageReceived: MessageEventParcelable[17600,/request_home_assistant_instance, size=0]
12-21 14:54:18.060 25214 3669 D WearOnboardingListener: sendHomeAssistantInstance: 86ba4570
12-21 14:54:18.063 25214 3669 D UrlRepository: localUrl is: false and usesInternalSsid is: false
12-21 14:54:18.063 25214 3669 D UrlRepository: Using external URL
12-21 14:54:18.069 25214 25214 D WearOnboardingListener: sendHomeAssistantInstance: success
12-21 14:54:33.209 25214 3676 D WearOnboardingListener: onMessageReceived: MessageEventParcelable[17601,/request_home_assistant_instance, size=0]
12-21 14:54:33.210 25214 3676 D WearOnboardingListener: sendHomeAssistantInstance: 86ba4570
12-21 14:54:33.214 25214 3676 D UrlRepository: localUrl is: false and usesInternalSsid is: false
12-21 14:54:33.214 25214 3676 D UrlRepository: Using external URL
12-21 14:54:33.222 25214 25214 D WearOnboardingListener: sendHomeAssistantInstance: success

That’s what mine was doing, and it magically fixed itself after I had charged the watch, because by default, WearOS does not update apps until you are charging it. (as @dshokouhi said - phone app and watch app MUST be the same version)

these are logs from the phone and not the wearable so they wont be of much help here