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.<init>: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 <bottom of call stack> 
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 <bottom of call stack> 
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.