phone state sensor stopped updating instantly after android 14 update

[ea5522]

Home Assistant Android app version(s): 2023.11.2-full Android version(s): 14 Device model(s): sm-g998u Home Assistant version: latest Last working Home Assistant release (if known): issue happend after update to android 14 Description of problem, include YAML if issue is related to notifications: phone state sensor stopped working after update to android 14

Companion App Logs: not needed

Screenshot or video of problem:

Additional information:

[dshokouhi]

Logs are indeed needed as the sensor works fine on my pixel 8 & 7 pro

[ea5522]

Hi Daniel, I isolated the issue to gsm calls and some apps. Whatsapp and my voip app works but gsm stopped working. Telegram calls never worked. Where do I find companion app logs?

[dshokouhi]

Where do I find companion app logs?

Settings > companion app > troubleshooting > show and share logs

make sure to open the app, reproduce the issue and then get the logs

[ea5522]

Ok, seems like it works when companion app is opened. When minimized, it works 50/50. Possibly an android issue. I did check the battery optimization settings, etc..

[dshokouhi]

Samsung devices are known to add multiple different battery optimization settings under different names like Power Saving, Data Saving etc... check all your device settings to see if a new one was added in Android 14

[ea5522]

Yeah, I checked them all already. Strange, i'll report back if i find something

[ccristal]

Exactly same issue here on a Galaxy S21 after Android14 update. Phone State sensor doesn't get updated until the HA companion app is brought to foreground. I have disabled all the optimizations and enabbled every permission I could find under the Settings->Apps->Home Assistant, to no avail. Here's a log from my companion app. In this case, the "offhook" phone state event was notified immediately, even if the HA app was in background, the "idle" one was not: it was sent only when I put the app in foreground. Keep in mind that events after 12-31 13:19:16.595 are related to when the HA app was put in foreground, not when I hung up the call. This means that absolutely nothing was logged on hangup.

Logs

``` 12-31 13:19:01.884 5320 5320 D SensorReceiver: Received intent: android.intent.action.PHONE_STATE 12-31 13:19:01.889 5320 22204 D ServerConnectionInfo: localUrl is: false, usesInternalSsid is: false, usesWifi is: true 12-31 13:19:02.056 5320 22204 D ServerConnectionInfo: localUrl is: false, usesInternalSsid is: false, usesWifi is: true 12-31 13:19:02.060 5320 22204 D ServerConnectionInfo: localUrl is: false, usesInternalSsid is: false, usesWifi is: true 12-31 13:19:02.473 5320 5320 D Choreographer: CoreRune.SYSPERF_ACTIVE_APP_BBA_ENABLE : stop animation in background states 12-31 13:19:03.532 5320 14074 D TrafficStats: tagSocket(104) with statsTag=0xffffffff, statsUid=-1 12-31 13:19:03.645 5320 22204 D ServerConnectionInfo: localUrl is: false, usesInternalSsid is: false, usesWifi is: true 12-31 13:19:03.683 5320 31580 I SensorReceiver: Sensor updates and sync completed 12-31 13:19:16.595 5320 5320 I ViewRootImpl@9dba75c[SettingsActivity]: handleAppVisibility mAppVisible = false visible = true 12-31 13:19:16.596 5320 5320 I ViewRootImpl@9dba75c[SettingsActivity]: stopped(false) old = true 12-31 13:19:16.596 5320 5320 D ViewRootImpl@9dba75c[SettingsActivity]: WindowStopped on io.homeassistant.companion.android/io.homeassistant.companion.android.settings.SettingsActivity set to false 12-31 13:19:16.617 5320 5320 D IntegrationRepository: isAppLocked(): false. (LockEnabled: false, appActive: false, expireMillis: 1704028727028, currentMillis: 1704028756617) 12-31 13:19:16.646 5320 5320 D InsetsSourceConsumer: applyRequestedVisibilityToControl: visible=true, type=1 12-31 13:19:16.646 5320 5320 D InsetsSourceConsumer: applyRequestedVisibilityToControl: visible=true, type=2 12-31 13:19:16.647 5320 5320 I BLASTBufferQueue_Java: new BLASTBufferQueue, mName= ViewRootImpl@9dba75c[SettingsActivity] mNativeObject= 0xb40000742f8569f0 sc.mNativeObject= 0xb40000737f7a2610 caller= android.view.ViewRootImpl.updateBlastSurfaceIfNeeded:2979 android.view.ViewRootImpl.relayoutWindow:9998 android.view.ViewRootImpl.performTraversals:4056 android.view.ViewRootImpl.doTraversal:3239 android.view.ViewRootImpl$TraversalRunnable.run:11197 android.view.Choreographer$CallbackRecord.run:1650 android.view.Choreographer$CallbackRecord.run:1659 android.view.Choreographer.doCallbacks:1129 android.view.Choreographer.doFrame:1055 android.view.Choreographer$FrameDisplayEventReceiver.run:1622 12-31 13:19:16.647 5320 5320 I BLASTBufferQueue_Java: update, w= 1080 h= 2400 mName = ViewRootImpl@9dba75c[SettingsActivity] mNativeObject= 0xb40000742f8569f0 sc.mNativeObject= 0xb40000737f7a2610 format= -1 caller= android.graphics.BLASTBufferQueue.:89 android.view.ViewRootImpl.updateBlastSurfaceIfNeeded:2979 android.view.ViewRootImpl.relayoutWindow:9998 android.view.ViewRootImpl.performTraversals:4056 android.view.ViewRootImpl.doTraversal:3239 android.view.ViewRootImpl$TraversalRunnable.run:11197 12-31 13:19:16.647 5320 5320 I ViewRootImpl@9dba75c[SettingsActivity]: Relayout returned: old=(0,0,1080,2400) new=(0,0,1080,2400) req=(1080,2400)0 dur=12 res=0x403 s={true 0xb4000072cf7c47c0} ch=true seqId=0 12-31 13:19:16.647 5320 5320 D ViewRootImpl@9dba75c[SettingsActivity]: mThreadedRenderer.initialize() mSurface={isValid=true 0xb4000072cf7c47c0} hwInitialized=true 12-31 13:19:16.648 5320 5320 D ViewRootImpl@9dba75c[SettingsActivity]: reportNextDraw android.view.ViewRootImpl.performTraversals:4658 android.view.ViewRootImpl.doTraversal:3239 android.view.ViewRootImpl$TraversalRunnable.run:11197 android.view.Choreographer$CallbackRecord.run:1650 android.view.Choreographer$CallbackRecord.run:1659 12-31 13:19:16.648 5320 5320 D ViewRootImpl@9dba75c[SettingsActivity]: Setup new sync=wmsSync-ViewRootImpl@9dba75c[SettingsActivity]#0 12-31 13:19:16.648 5320 5320 D ViewRootImpl@9dba75c[SettingsActivity]: Creating new active sync group ViewRootImpl@9dba75c[SettingsActivity]#1 12-31 13:19:16.648 5320 5320 D ViewRootImpl@9dba75c[SettingsActivity]: registerCallbacksForSync syncBuffer=false 12-31 13:19:16.698 5320 5330 I mpanion.android: CollectorTransition concurrent copying GC freed 248398(9310KB) AllocSpace objects, 6(284KB) LOS objects, 49% free, 14MB/28MB, paused 400us,253us total 104.775ms 12-31 13:19:16.708 5320 5331 D InputTransport: Input channel destroyed: 'ClientS', fd=261 12-31 13:19:16.963 5320 6376 D ViewRootImpl@9dba75c[SettingsActivity]: Received frameDrawingCallback syncResult=0 frameNum=1. 12-31 13:19:16.963 5320 6376 I ViewRootImpl@9dba75c[SettingsActivity]: mWNT: t=0xb40000731f7da3d0 mBlastBufferQueue=0xb40000742f8569f0 fn= 1 caller= android.view.ViewRootImpl$8.onFrameDraw:13614 android.view.ThreadedRenderer$1.onFrameDraw:788 12-31 13:19:16.963 5320 6376 D ViewRootImpl@9dba75c[SettingsActivity]: Setting up sync and frameCommitCallback 12-31 13:19:16.973 5320 6353 I BLASTBufferQueue: [ViewRootImpl@9dba75c[SettingsActivity]#79](f:0,a:0,s:0) onFrameAvailable the first frame is available 12-31 13:19:16.974 5320 6353 D ViewRootImpl@9dba75c[SettingsActivity]: Received frameCommittedCallback lastAttemptedDrawFrameNum=1 didProduceBuffer=true 12-31 13:19:16.974 5320 5320 D ViewRootImpl@9dba75c[SettingsActivity]: reportDrawFinished 12-31 13:19:16.974 5320 5320 D SensorReceiver: Received intent: android.intent.action.PHONE_STATE 12-31 13:19:16.976 5320 5320 I Choreographer: Skipped 38 frames! The application may be doing too much work on its main thread. 12-31 13:19:16.976 5320 5320 I ViewRootImpl@9dba75c[SettingsActivity]: registerCallbackForPendingTransactions 12-31 13:19:16.977 5320 6375 I ViewRootImpl@9dba75c[SettingsActivity]: mWNT: t=0xb40000731f7f6570 mBlastBufferQueue=0xb40000742f8569f0 fn= 2 caller= android.view.ViewRootImpl$6.onFrameDraw:5539 android.view.ViewRootImpl$2.onFrameDraw:2103 android.view.ThreadedRenderer$1.onFrameDraw:788 12-31 13:19:16.977 5320 5320 D LocBroadcastReceiver: Received location update. 12-31 13:19:16.977 5320 6353 I BLASTBufferQueue_Java: applyPendingTransactions, mName= ViewRootImpl@9dba75c[SettingsActivity] mNativeObject= 0xb40000742f8569f0 frameNumber= 2 caller= android.view.ViewRootImpl$6.lambda$onFrameDraw$0:5548 android.view.ViewRootImpl$6.$r8$lambda$9ThyGB6fC3mub7oMSjoAoWLhwMM:0 android.view.ViewRootImpl$6$$ExternalSyntheticLambda0.onFrameCommit:4 android.view.ThreadedRenderer$1.lambda$onFrameDraw$0:800 android.view.ThreadedRenderer$1$$ExternalSyntheticLambda0.onFrameCommit:2 12-31 13:19:16.980 5320 22204 D ServerConnectionInfo: localUrl is: false, usesInternalSsid is: false, usesWifi is: true 12-31 13:19:16.984 5320 5320 D ForegrndServiceLauncher: Check if service HighAccuracyLocationService is running. Service running = false 12-31 13:19:16.985 5320 21540 D LocBroadcastReceiver: Last Location: 12-31 13:19:16.985 5320 21540 D LocBroadcastReceiver: Coords:(50.9718053, -1.5854906) 12-31 13:19:16.985 5320 21540 D LocBroadcastReceiver: Accuracy: 100.0 12-31 13:19:16.985 5320 21540 D LocBroadcastReceiver: Bearing: 0.0 12-31 13:19:16.985 5320 5320 I ViewRootImpl@9dba75c[SettingsActivity]: MSG_WINDOW_FOCUS_CHANGED 1 0 12-31 13:19:16.985 5320 5320 D ViewRootImpl@9dba75c[SettingsActivity]: mThreadedRenderer.initializeIfNeeded()#2 mSurface={isValid=true 0xb4000072cf7c47c0} 12-31 13:19:16.985 5320 5320 D IntegrationRepository: isAppLocked(): false. (LockEnabled: false, appActive: false, expireMillis: 1704028727028, currentMillis: 1704028756985) 12-31 13:19:16.985 5320 5320 D IntegrationRepository: setAppActive(): true 12-31 13:19:16.986 5320 5320 D InputMethodManagerUtils: startInputInner - Id : 0 12-31 13:19:16.986 5320 5320 I InputMethodManager: startInputInner - IInputMethodManagerGlobalInvoker.startInputOrWindowGainedFocus 12-31 13:19:16.987 5320 21540 D LocBroadcastReceiver: Begin evaluating if location update should be skipped 12-31 13:19:16.987 5320 21540 D LocBroadcastReceiver: Received location that is 364 milliseconds old, 1704028756623 compared to 1704028756987 with source fused 12-31 13:19:16.987 5320 21540 D LocBroadcastReceiver: Duplicate location received, not sending to HA 12-31 13:19:16.994 5320 5320 D InsetsSourceConsumer: applyRequestedVisibilityToControl: visible=false, type=8 12-31 13:19:16.994 5320 6350 I ViewRootImpl@9dba75c[SettingsActivity]: Resizing android.view.ViewRootImpl@8b12aea: frame = [0,0][1080,2400] reportDraw = false forceLayout = false syncSeqId = -1 12-31 13:19:16.994 5320 5320 I ViewRootImpl@9dba75c[SettingsActivity]: handleResized, msg = 4 frames=ClientWindowFrames{frame=[0,0][1080,2400] display=[0,0][1080,2400] parentFrame=[0,0][0,0]} forceNextWindowRelayout=false displayId=0 dragResizing=false compatScale=1.0 frameChanged=false attachedFrameChanged=false configChanged=false displayChanged=false compatScaleChanged=false 12-31 13:19:17.042 5320 22204 D ServerConnectionInfo: localUrl is: false, usesInternalSsid is: false, usesWifi is: true 12-31 13:19:17.043 5320 22204 D ServerConnectionInfo: localUrl is: false, usesInternalSsid is: false, usesWifi is: true 12-31 13:19:17.095 5320 22204 D ServerConnectionInfo: localUrl is: false, usesInternalSsid is: false, usesWifi is: true 12-31 13:19:17.115 5320 22204 I SensorReceiver: Sensor updates and sync completed 12-31 13:19:17.967 5320 5320 I ViewRootImpl@9dba75c[SettingsActivity]: ViewPostIme pointer 0 12-31 13:19:18.022 5320 5320 I ViewRootImpl@9dba75c[SettingsActivity]: ViewPostIme pointer 1 12-31 13:19:18.039 5320 5320 I BLASTBufferQueue_Java: update, w= 1080 h= 2400 mName = ViewRootImpl@9dba75c[SettingsActivity] mNativeObject= 0xb40000742f8569f0 sc.mNativeObject= 0xb40000737f7a2610 format= -1 caller= android.view.ViewRootImpl.updateBlastSurfaceIfNeeded:2968 android.view.ViewRootImpl.relayoutWindow:9998 android.view.ViewRootImpl.performTraversals:4056 android.view.ViewRootImpl.doTraversal:3239 android.view.ViewRootImpl$TraversalRunnable.run:11197 android.view.Choreographer$CallbackRecord.run:1650 12-31 13:19:18.039 5320 5320 I ViewRootImpl@9dba75c[SettingsActivity]: Relayout returned: old=(0,0,1080,2400) new=(0,0,1080,2400) req=(1080,2400)0 dur=0 res=0x0 s={true 0xb4000072cf7c47c0} ch=false seqId=0 12-31 13:19:18.062 5320 5320 I ImeTracker: io.homeassistant.companion.android:bd1680c0: onRequestHide at ORIGIN_CLIENT_HIDE_SOFT_INPUT reason HIDE_SOFT_INPUT 12-31 13:19:18.062 5320 5320 I InputMethodManager_LC: closeCurrentInput: IInputMethodManagerGlobalInvoker.hideSoftInput 12-31 13:19:18.063 5320 5320 I ViewRootImpl@9dba75c[SettingsActivity]: registerCallbackForPendingTransactions 12-31 13:19:18.066 5320 6376 I ViewRootImpl@9dba75c[SettingsActivity]: mWNT: t=0xb40000731f797fb0 mBlastBufferQueue=0xb40000742f8569f0 fn= 7 caller= android.view.ViewRootImpl$6.onFrameDraw:5539 android.view.ViewRootImpl$2.onFrameDraw:2103 android.view.ThreadedRenderer$1.onFrameDraw:788 12-31 13:19:19.486 5320 5320 I ViewRootImpl@9dba75c[SettingsActivity]: ViewPostIme pointer 0 12-31 13:19:19.540 5320 5320 I ViewRootImpl@9dba75c[SettingsActivity]: ViewPostIme pointer 1 12-31 13:19:19.566 5320 5320 D ScrollView: initGoToTop 12-31 13:19:19.575 5320 5320 I BLASTBufferQueue_Java: update, w= 1080 h= 2400 mName = ViewRootImpl@9dba75c[SettingsActivity] mNativeObject= 0xb40000742f8569f0 sc.mNativeObject= 0xb40000737f7a2610 format= -1 caller= android.view.ViewRootImpl.updateBlastSurfaceIfNeeded:2968 android.view.ViewRootImpl.relayoutWindow:9998 android.view.ViewRootImpl.performTraversals:4056 android.view.ViewRootImpl.doTraversal:3239 android.view.ViewRootImpl$TraversalRunnable.run:11197 android.view.Choreographer$CallbackRecord.run:1650 12-31 13:19:19.576 5320 5320 I ViewRootImpl@9dba75c[SettingsActivity]: Relayout returned: old=(0,0,1080,2400) new=(0,0,1080,2400) req=(1080,2400)0 dur=0 res=0x0 s={true 0xb4000072cf7c47c0} ch=false seqId=0 12-31 13:19:19.576 5320 5320 D ScrollView: onsize change changed 12-31 13:19:19.577 5320 22204 D LogcatReader: Read logcat for pid 5320 12-31 13:19:19.579 5320 5320 I ViewRootImpl@9dba75c[SettingsActivity]: registerCallbackForPendingTransactions 12-31 13:19:19.579 5320 6375 I ViewRootImpl@9dba75c[SettingsActivity]: mWNT: t=0xb40000731f7969b0 mBlastBufferQueue ```

[dshokouhi]

I have disabled all the optimizations and enabbled every permission I could find under the Settings->Apps->Home Assistant, to no avail.

have you checked things like power saving, data saving etc...? Those are Samsung specific settings and they will not be found under the HA app.

your device is indeed getting intents as expected so looks like the OS is not sending them when screen is off so most likely there is another new setting added that needs to be disabled.

12-31 13:19:01.884 5320 5320 D SensorReceiver: Received intent: android.intent.action.PHONE_STATE

[jpelgrom]

your device is indeed getting intents as expected so looks like the OS is not sending them when screen is off

Which could be explained by an Android 14 behavior change, nothing you can do about that.

[dshokouhi]

your device is indeed getting intents as expected so looks like the OS is not sending them when screen is off

Which could be explained by an Android 14 behavior change, nothing you can do about that.

yup and that points again to battery optimizations or some kind of power saving setting. One should expect the app to remain in foreground_service state when in the background to avoid it being in the cached state. Here is the graph of the app importance sensor when the app has proper background access there shoudl be 2 states foreground_service and foreground

[ccristal]

I have disabled all the optimizations and enabbled every permission I could find under the Settings->Apps->Home Assistant, to no avail.

have you checked things like power saving, data saving etc...? Those are Samsung specific settings and they will not be found under the HA app.

your device is indeed getting intents as expected so looks like the OS is not sending them when screen is off so most likely there is another new setting added that needs to be disabled.

12-31 13:19:01.884 5320 5320 D SensorReceiver: Received intent: android.intent.action.PHONE_STATE

Yes, the "offhook" event was notified immediately, as I explained in my post. The called ended at 13:19:10, but the "idle" event was notified only when the app was brought back to foreground (i.e. at 13:19:16). And we're not talking about the screen being off here, just the HA app not being in foreground.

Does the HA app do this?

[dshokouhi]

Does the HA app do this?

no we do not target android 14 yet

Based on the description and the link that jpelgrom posted it looks like the OS is limiting the broadcasts sent to your device as offhook needs to be sent before idle and theres probably some type of cached queue its hitting. I think it may be worth it to check device settings more.

dontkillmyapp.com usually has some good tips but not sure it was updated with most recent Samsung changes.

[ccristal]

Based on the description and the link that jpelgrom posted it looks like the OS is limiting the broadcasts sent to your device as offhook needs to be sent before idle and theres probably some type of cached queue its hitting. I think it may be worth it to check device settings more.

The behaviour is completely random. Sometimes offhook is sent and idle is not, sometimes it's the other way round. Most often neither is sent. And yes, I have checked all the settings I could find, to no avail. Those are the following:

• Power saving
• Protect battery
• Adaptive battery
• Put unused apps to sleep

Curiously, I can't find the HA app in the list of those that can be added to "Never auto sleeping apps".

[TPMunster]

Just wanted to pitch in saying that I'm having the same issues with my Pixel 8 Pro ✌️

[dshokouhi]

Just wanted to pitch in saying that I'm having the same issues with my Pixel 8 Pro ✌️

did you make sure to grant the app background access?

my pixel 8 pro is working as expected with battery optimizations disabled.

offhook and ringing state both comes in.

[matthewgutz]

Running into the same issue on S22 (SM-S901U) android 14.

[jpelgrom]

Doing some research, could this be the issue? If your app targets Android 14, it must specify appropriate foreground service types.

The app does not yet target Android 14, nor does it use a foreground service for this sensor, so that seems unlikely.

[albob75]

For info, I'm having similar issues with my Samsung Galaxy S23 Ultra, and my wife's Pixel 6a. Both were working great for a good few months, but a while back the Pixel became "un-reliable" updating it's sensors, and now my S23 ultra is doing the same. Both are now on Android 14, so possibly the issues started when they updated.

Seems I now have the same behaviour as @ea5522, if the HA android app is open the sensors update immediately, but as soon as I minimize it or switch to another app it's hit or miss as to whether the sensors update or not.

I've checked on both phones and battery access for HA is set to un-restricted, and no power savings modes are activated. I have also tried turning off adaptive battery, but nothing seems to work.

FYI - sometimes I can see that the app importance has gone into cached, which shouldn't happen with un-restricted battery, is that correct?

[albob75]

Based on the description and the link that jpelgrom posted it looks like the OS is limiting the broadcasts sent to your device as offhook needs to be sent before idle and theres probably some type of cached queue its hitting. I think it may be worth it to check device settings more.

The behaviour is completely random. Sometimes offhook is sent and idle is not, sometimes it's the other way round. Most often neither is sent. And yes, I have checked all the settings I could find, to no avail. Those are the following:

• Power saving
• Protect battery
• Adaptive battery
• Put unused apps to sleep

Curiously, I can't find the HA app in the list of those that can be added to "Never auto sleeping apps".

@ccristal - I think when you set the app battery access to "un-restricted" it removes the app from the "Never auto sleep apps" list, and doesn't let you select it. So possibly they are doing the same thing?

[hatchling]

I want to echo a basically identical experience to what @albob75 is reporting. In my case the phones involved are a Pixel 5 and Pixel 6, Android 14. I did similarly notice that app state is going to "cached" when not opened despite removing all restrictions I could find.

My automation was very reliable with either phone previously, and tracked charging state and type (it turns off all my lights when either phone is placed on a Pixel charging stand).

[Ragingfire105]

Having similar sensor update issues on my Pixel 7. Charging type is being used to trigger a scene and isn't updating unless I open the app.

[Oni159]

Same issue on my side, with my phone (Pixel 7) and wife's phone (Pixel 8); Android 14. When I unplug the phone, home assistant can take 10 minutes to understand the phone is unplugged.

[dshokouhi]

Although I am unable to reproduce the issue I have an idea for a potential fix but it requires end user testing. Please install the debug APK from the link below by downloading the artifact and extracting the zip. Run both production and debug side by side for a few days, the apps can run in parallel and the debug one will have a red icon to help distinguish it. Make sure to give the device a different name so you can remove the entry when the test is done. Make sure to grant the app background access but also keep the debug app usage minimal, use the blue icon to access your dashboards. We want to test how well it does when the app is in teh background untouched, like what has been described in this issue. Also please check the Phone State and Battery Charging sensors for this test. If possible in a few days show us a bar chart/graph like below to help show its updating better or the same. Keeping production and debug running at the same time will help us see if its behaving better or not.

https://github.com/home-assistant/android/actions/runs/8010690680

[hatchling]

I am trying the debug app out and will report back in a few days with the results.

[hatchling]

Unfortunately I'm still experiencing long delays with the "instant" sensors, like battery state. This first image is similar to what you posted earlier, and may or may not be directly helpful because of the long duration.

This second image shows a specific test. I plugged into AC at 6:21, and noticed it took 5 mins to reflect on the dev app, and 10 mins on the normal app. I suspect (without looking at code) that they are just on their own independent 15 minute update interval. The main thing is that the sensor wasn't reported instantly. Maybe worth noting that the app state seems to like going into cached state for 15 mins after plugging in, then it returns to foreground_service. I did not touch the phone at all during this time, and the screen was off when I plugged it in.

I'm happy to test any further builds if you find anything else, thanks again for trying to fix this for us.

[ea5522]

I switched to galaxy s24 ultra. Sensor is working fine on android 14.

[Rodin67]

I have the same problem on my Nothing Phone (1) with Android 14. I checked that there was no battery optimization and that the HA app has background access. The HA app goes into cached mode and then the sensors don't update unless I'm launching the HA app.

I managed to solve the problem in part as follows:

• activate the hidden developer options
• going to "suspend execution for cached apps"
• select Disabled (was on "device default")
• restart

Then the sensors update as expected ONLY if I leave HA in the recent app screen. If I clear the recent apps list, I have to launch HA again to update the sensors.

[dshokouhi]

If I clear the recent apps list

this will stop the sensor worker from retaining its schedule and is not recommended

[Rodin67]

Thanks for the information, although even if I'm not clearing the recent apps list, I still need to disable the "suspend execution for cached apps" option for HA to work properly.

[siw1973]

Most master users of HA use the Companion App daily, bringing it to the foreground therefore wouldn't experience a Android 14 "timeout".

For reference and context my wife and child have experienced "location lockout" that seems to occur after 6 days.

This impacts Alarm and automated door lock consequences.

[Rodin67]

In my case, it doesn't work instantly when I'm putting HA in the background.

For example, if I'm charging my phone while the HA app is open, the sensor changed instantly to "plugged". If I'm putting HA in the background and right after this charging my phone, the sensor isn't updated until I open the HA app.

[natebgamer]

Just wanted to add I'm having these same issues posted above on a Samsung s21 and Samsung a52s since they were updated to android 14.

My automations that were using the phones being on charge as a trigger have started being delayed/not running at all/work Instantly if I then bring the app to the foreground just like posted above.

Done all the things already mentioned like turning off all battery saving options and making sure the app has background access etc.

Hopefully this gets fixed soon.

[siw1973]

Is this something the developers need to do with the app classification in Play Store?

https://9to5google.com/2023/05/05/samsung-background-android-14/

[dshokouhi]

Is this something the developers need to do with the app classification in Play Store?

https://9to5google.com/2023/05/05/samsung-background-android-14/

no that is not required for the app, the app also is not targeting android 14

please keep in mind its working for some users but not all.

[siw1973]

When you say the app is not targeting Android 14 what do you mean? Android 14 has been out 5 months.

I have the same settings on two Pixel 7 phones with the same Home Assistant settings across the Apo and Android. The only difference is that my wife opens the app in the foreground it works. Then closes the app after which the sensor services run for a differing amount of time and then die.

I use the App frequently and then close the App. But will open it at least three / four times a day, I've never had the issue.

It's clearly an Android change that breaks Home Assistant on Android 14.

[dshokouhi]

When you say the app is not targeting Android 14 what do you mean? Android 14 has been out 5 months.

Its developer terminology about what SDK version the app is targeting. This is not anything an end user would know about unless they develop android applications.

I think the comment made earlier still stands.

[siw1973]

OK, from a semi laymans terms you are saying that the Home Assistant Companion App does not support Android 14. If that's the case what is on the Product Roadmap for this.

I'm was assuming the Companion App pushes to HA when a Sensor Update is detected, be that WiFi Network, Battery Change or Location. Which is rather different than your earlier test to see if the Companion App accepts OS messages.

[dshokouhi]

OK, from a semi laymans terms you are saying that the Home Assistant Companion App does not support Android 14.

no we are not saying that at all.

I'm was assuming the Companion App pushes to HA when a Sensor Update is detected, be that WiFi Network, Battery Change or Location. Which is rather different than your earlier test to see if the Companion App accepts OS messages.

yes the OS is supposed to fire an intent which the app listens to that triggers the update, as you can see from the troubleshooting above that intent is not reaching these devices. thats what the linked comment is referring to.

[siw1973]

So I had an idea and so far so good.

I've added a simple entity state widget to the home screen which seems to stop Android from terminating Home Assistant Processes as it will need to continously keep the HA connection open even if I have closed the HA Companion App.

Will continue to monitor and report back in a week.

[siw1973]

This failed yet again.

Honestly not sure what to do here or if anyone is actually going to pick this up.

Makes the Companion App pretty useless for Android initiated routines for people who don't regularly go into the app.

[dshokouhi]

Makes the Companion App pretty useless for Android initiated routines for people who don't regularly go into the app.

FWIW my wife hardly ever opens the app and the sensor works fine for her and the intents are always received

just a thought but on most devices when the phone starts ringing the screen turns on, does enabling the interactive sensor make the situation better?

[siw1973]

Hi, I'll set it up and have a try. Thanks for the suggestion.

Is this an Android initiated trigger to the Home Assistant Companion App? Therefore Android will insist on keeping the connection open.

The location sensor is set up to update every minute due to arrival routines but I think that's an HA Companion App initiated trigger that Android may not "care" about.

That's the reason I thought that the Widget approach would have worked as it was an Android "owned" process that it wouldn't shut down the HA "connection"

[dshokouhi]

Is this an Android initiated trigger to the Home Assistant Companion App? Therefore Android will insist on keeping the connection open.

the interactive sensor uses native android intents much like the phone state sensor to push updates

The location sensor is set up to update every minute due to arrival routines but I think that's an HA Companion App initiated trigger that Android may not "care" about.

location tracking uses Gogles Fused Location provider that is native to android devices that are play store certified, the app provides an intent that updates come to

That's the reason I thought that the Widget approach would have worked as it was an Android "owned" process that it wouldn't shut down the HA "connection"

so widgets like template and entity state subscribe to a websocket connection when the screen turns on and closes the connection when the screen turns off in an effort to keep the widgets as up to date as possible. Its tough to say whats happening here honestly.

One other thing you may try is looking at logcat from an app like logcat reader or android studio to see if there are additional logs at the time of occurrence something there may help shed a light to the issue.

[siw1973]

Trialing interactive sensor now 👍

[dshokouhi]

@siw1973 did the interactive sensor make the situation better?

[siw1973]

It seems to have as I've had no lost location tracking, but I've introduced an Octopus Energy Agile tab on our Energy Dashboard that my wife is more engaged with so I'm unsure as to whether it is the interactive sensor or the introduction of an HA Dashboard that she is actually checks.

Will report back later, but ir's a start.

[zgbee]

So I just tried to enable a sensor yesterday for the current WiFi network, and also noticed this problem that many other people seem to have where the sensor only updates if I bring the Home Assistant companion app to the foreground. I have a Pixel 7a running Android 14.

After seeing the discussion here, I enabled the app importance sensor and put a little test widget on a dashboard. I also turned on the interactive sensor (but am not monitoring anywhere). After the initial Unknown from when App Importance was first added to my dashboard but hadn't received an update yet - I have 2 statuses: cached (which lasted for 10 seconds), and then perceptible (where it's been for the past 10 minutes).

I've already double-checked the background usage/etc settings.. is it expected that I should only ever see foreground or foreground_service statuses?

Edit: adding that after leaving my phone untouched for about 20 mins, I unlocked and went into my wifi settings without launching the HA app, and disconnecting/reconnecting to my WiFi seemed to instantly update the phone device in home assistant. So maybe the interactive sensor helped (the phone also briefly left the perceptible state to become a foreground_service before returning to cached

[zgbee]

I think I spoke too soon.. I didn't verify with the logs at the time, but yesterday it seemed like my automation tied to the "instant" WiFi sensor was triggered 10-15 minutes after I rejoined the network.

[zgbee]

So in looking at the history for my phone's App Importance, it looks like just now when I arrived home it was in a state of foreground, and about 10 minutes later when I was off doing something else, the same second the state changed to foreground_service, the automation I have set to trigger on my phone's wifi sensor logged an execution.

I did not open the Home Assistant app, but it's possible the change to foreground_service occurred while unlocking my phone. It may have been in foreground before that as when I arrived home, I used a companion app widget on my Android phone's home screen to unlock the building's front door (which is out of my wifi range).

[dshokouhi]

@zgbee did you grant the app background access too?