android
android copied to clipboard
home-assistant
Wear OS app gets put to sleep
Home Assistant Android version: 2022.3.0-full (phone) 2022.3.0 (watch)
Android version: 10 (phone) Wear OS 2.34
Phone model: Samsung Galaxy S9+ TicWatch Pro 2020
Home Assistant version: 2022.4.7
Last working Home Assistant release (if known): n/a
Description of problem: Watch sensors (especially battery levels) stop being sent overnight while watch is not on wrist. This means that battery level info is not sent, so HA automations to switch on/off a USB charging outlet do not work. This behaviour is not consistent, leading me to believe that the Wear OS app is not setting the appropriate wake-locks or requesting the correct power modes in order to ensure data is sent.
Traceback (if applicable, to get the logs you may refer to: https://companion.home-assistant.io/docs/troubleshooting/faqs/#android-crash-logs): n/a
Screenshot of problem:
Additional information: There is a developer-mode option "stay awake while charging" which I have enabled, that provides some relief for the issue. However the HA companion app still appears to be put to sleep by Wear OS in some situations.
Edit: I should add that this is not always an "overnight" issue - sometimes the battery level info is not updated during the day while the watch is being worn. Opening the HA app on the watch then causes the sensor data to be updated immediately. This is expected if Wear OS is putting the app to sleep while it is not "active" however the app needs to remain in-memory in order to send updated sensor data to HA periodically.
Implementing #1898 may assist as a workaround, if the complication then causes the app to be kept in memory?
can you try giving the app background permissions by disablign battery optimizations?
I've looked for such an option but not found one on the watch (but yes, this is how I'd approach such an issue on the phone). Do you have specifics of how to do this in Wear OS?
I've not been able to find a gui method of disabling battery optimization for Wear OS devices, but I've done similar things via adb previous so I went digging:
# adb shell am get-standby-bucket io.homeassistant.companion.android
40
Despite being a frequently-used app, including a shortcut tile that gets used a few times a day, the power bucket is 40 = "rare"? That doesn't seem right. Is this something the app developer can influence, or is it based solely on user activity? Ref: https://pancake.coffee/2020/02/14/check-app-standby-bucket-using-adb-command/
According to https://developer.android.com/topic/performance/power/power-details that could mean that wakeups are deferred up to 24 hours (assuming I''m reading this right).
I've set the power bucket to active which should be the same as disabling battery optimization:
# adb shell am set-standby-bucket io.homeassistant.companion.android active
# adb shell am get-standby-bucket io.homeassistant.companion.android
10
I've also set the deviceidle whitelist (I suspect this is the more correct way to achieve disabling optimization):
# adb shell dumpsys deviceidle whitelist +io.homeassistant.companion.android
Added: io.homeassistant.companion.android
I'm unsure of whether these commands survive reboots, and am aware that they will likely impact battery life of the watch, but right now I'm just trying to prove out the theory that the Home Assistant companion app is being killed or at least put to sleep which is undesirable to me.
The below screenshot shows the HA companion app sending battery level sensor updates at varying intervals, which is part of the issue:
The left-hand side of this image also shows my main issue: between 22:00 (10pm) and 8:30am, only one update was sent at just after 4am - despite the watch being on charger from about 10:30pm and fully charged from around 11:15pm.
It doesn't look like battery optimizations are supported but I don't think that is the issue here as the sensor worker is not killed, its still there just seems to be waiting for the next data connection. It is respecting the wear OS connection guide.
So are you certain the device still had a data connection while on the charge? Are you able to look at the on device logs to see if any failure showed up during those gaps? The worker that we have gets put on a schedule and it seems like that schedule is being respected as long as the device has its data connection. I suspect the gaps you are seeing is when the watch does not have that connection and next time the screen turns on it does have the connection and then it reports the next status.
I would imagine more users would have this issue but this is the first report we have seen.
So are you certain the device still had a data connection while on the charge?
My phone and my watch charge beside each other in my home office, so BLE range isn't an issue (maybe 20cm/8" apart) and the watch has the default setting of enabling wifi when charging, so in theory both are on wifi (I say theory because when I check the watch is on wifi, but the screen drops to ambient mode after a few minutes and I'm unsure it stays on wifi).
it is respecting the wear OS connection guide.
What is "it" here? The watch, or the sensor worker?
I can see what you're saying and the observed transitions between reporting behaviours do match with network/connectivity transitions for either the watch, the phone, or both. However the outcomes don't quite make sense - referencing my earlier screenshot, the transition around 9:45am from 100% to 96% happened when I left home so phone came off wifi to 4g. The watch should have been on BLE-to-phone already, although was maybe still on wifi from when charging. That's the beginning of a consistent 15-minute reporting cycle that then ends at 11am/92% when I returned home and connected to home wifi for the phone - the watch should have had good network access the entire time. Is the watch aware of the phone/piggy-back data connection moving from 4g to wifi? But even if it was, why reduce the frequency of network data connections when the phone is on wifi?
In summary - yes the transitions between behaviours matches with transitions between networks / connection types, but some definite network transitions do not trigger behaviour changes, and the nature of the behaviour transitions don't make sense (to me - maybe "watch connected via bluetooth, phone on wifi" is considered inefficient and a reason to do some power saving).
the sensor worker is not killed, its still there just seems to be waiting for the next data connection.
Are you certain that the sensor worker is still awake/waking at the correct interval? In my head, the same outcome would be observed if the worker was sleeping "deeper" and the network was fine - if possible we should try to prove that the network is the blocker here.
Since I whitelisted the companion app yesterday evening, the data reporting interval dropped immediately from ~90 minutes to exactly 15 minutes and the overnight charging cycle has reported well. I consider it a win but I note that my only change recently is to "disable battery optimization" by whitelisting the companion app.
Are you able to look at the on device logs to see if any failure showed up during those gaps?
Happy to, but I have no idea what logs you're referring to. Let me know how to grab them, and if I need to enable debug somewhere?
Following up on this after a couple of days of usage;
All sensors are reporting in more consistently, most noticeable is the battery level:
This is the sort of consistent sensor updates I assumed I would experience from the Wear OS companion app as standard - based on the phone app knowing about and asking for permission to disable battery optimization. Given the lack of GUI options and permissions around battery optimization on Wear OS I guess that is not the case.
Is there a Google-sanctioned way to mandate or hint at the standby power bucket, or better yet to white-list the package so that the equivalent of battery optimization disablement can be achieved? I'm not suggesting this be the default, but similar to the phone companion app it should be offered to the user as an option in the Wear OS app settings - I say this because I believe users should expect similar functionality between the Android app and the Wear OS app, without enabling developer mode and using adb commands to achieve it.
Just facing quite the same issue for another app. Have you figured out how to solve that or have you found a workaround yet ? I have tested with several versions of WearOS and indeed no one is able to whitelist the application with ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS.
What is "it" here? The watch, or the sensor worker?
the sensor worker, which has a constraint of a valid network connection. It will not run if it doesn't believe it is connected.
Is the watch aware of the phone/piggy-back data connection moving from 4g to wifi? But even if it was, why reduce the frequency of network data connections when the phone is on wifi?
This is actually something Wear OS does and the app does not have much control. The app will set the work manager schedule and the device will support it however it does. Things like doze may have an impact on the scheduled worker.
Happy to, but I have no idea what logs you're referring to. Let me know how to grab them, and if I need to enable debug somewhere?
you will need to connect to the watch and inspect logcat here, there is no easy way to get the logs here. https://developer.android.com/training/wearables/get-started/debugging
You might find it easier to install android studio and connect the watch to use its logcat viewer.
Is there a Google-sanctioned way to mandate or hint at the standby power bucket, or better yet to white-list the package so that the equivalent of battery optimization disablement can be achieved? I'm not suggesting this be the default, but similar to the phone companion app it should be offered to the user as an option in the Wear OS app settings - I say this because I believe users should expect similar functionality between the Android app and the Wear OS app, without enabling developer mode and using adb commands to achieve it.
You can see in android settings on a phone a user can disable battery optimizations with ease, those settings are missing from the watch. As you were able to enable the whitelist using ADB commands that is probably only possible because its android. Judging by this stackoverflow post Google has deliberately removed this ability in the code.
Just facing quite the same issue for another app. Have you figured out how to solve that or have you found a workaround yet ? I have tested with several versions of WearOS and indeed no one is able to whitelist the application with ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS.
See https://github.com/home-assistant/android/issues/2511#issuecomment-1120369861 for the ADB command to whitelist.
Issue is also applicable for Galaxy Watch 4, where all sensors from Watch OS died, but I can still control entities in my house (and see their status)
@jeremysherriff any updates on your end regarding the battery impact and if the adb commands persist over a reboot? Looking at the upcoming Pixel Watch it seems there are even more battery optimizations underway.
https://9to5google.com/2022/10/08/google-pixel-watch-save-battery/
one thing I did notice is that apps can register for passive health sensor updates, that may or may not be a better way for us to go about things.
https://developer.android.com/training/wearables/health-services/passive
Yeah it's been working really well. I think battery life is affected a little, I have difficulty quantifying the impact though - so maybe something like 2-5% extra drain across the course of a 17-hour day (7am - 10pm).
Sorry, missed a part of the question; yes the settings persist across restarts.
Given that Google has removed the prompt to enable background permissions in Wear OS I am not sure what the app will be able to do. Our sensor worker still goes on schedule and updates properly. This does not mean the OS is killing the app or its scheduled jobs, it is just respecting doze mode on the device. The battery should also get an update triggered when the system alerts that is low.
For reference here is the graph from my pixel watch for the past 24 hours, I did not use any ADB commands to add to the whitelist.
There's a good possibility that the issue is my older Android version on my watch, and a bit of sub-standard optimisation by Mobvoi. These TicWatches don't have a great reputation for performance, even for their system apps. Forums are full of people saying the heartrate/sleep/SPo2 monitoring stops working and I'll take a bet that they're being pushing into the background.
I am going to close this issue as we have seen the worker itself does not stop and does update just at an infrequent interval. Some devices will indeed be more restrictive than others when it comes to battery optimization. For example Samsung watches have the option to allow background access to certain apps but this feature is not available on all smart watches, not even the Pixel Watch. Supporting ADB commands to whitelist the app and/or change its standby bucket is not something we should do either.