Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

phone state sensor stopped updating instantly after android 14 update #4040

Open
ea5522 opened this issue Dec 7, 2023 · 66 comments
Open

phone state sensor stopped updating instantly after android 14 update #4040

ea5522 opened this issue Dec 7, 2023 · 66 comments
Labels
bug Something isn't working sensor-tracking

Comments

@ea5522
Copy link

ea5522 commented Dec 7, 2023

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:

@ea5522 ea5522 added the bug Something isn't working label Dec 7, 2023
@dshokouhi
Copy link
Member

dshokouhi commented Dec 7, 2023

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

image

image

@dshokouhi dshokouhi added question Further information is requested sensor-tracking labels Dec 7, 2023
@ea5522
Copy link
Author

ea5522 commented Dec 9, 2023

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
Copy link
Member

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
Copy link
Author

ea5522 commented Dec 11, 2023

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
Copy link
Member

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
Copy link
Author

ea5522 commented Dec 11, 2023

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

@ccristal
Copy link

ccristal commented Dec 31, 2023

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
Copy link
Member

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
Copy link
Member

jpelgrom commented Jan 5, 2024

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
Copy link
Member

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

image

image

@ccristal
Copy link

ccristal commented Jan 5, 2024

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
Copy link
Member

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
Copy link

ccristal commented Jan 5, 2024

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
Copy link

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

@dshokouhi
Copy link
Member

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.

image

offhook and ringing state both comes in.

image

@matthewgutz
Copy link

matthewgutz commented Jan 27, 2024

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

@jpelgrom
Copy link
Member

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
Copy link

albob75 commented Feb 6, 2024

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
Copy link

albob75 commented Feb 6, 2024

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
Copy link

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).

@dshokouhi dshokouhi removed the question Further information is requested label Feb 12, 2024
@Ragingfire105
Copy link

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
Copy link

Oni159 commented Feb 19, 2024

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
Copy link
Member

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

image

@hatchling
Copy link

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

@hatchling
Copy link

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.
image

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.
app_testing

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

@dshokouhi
Copy link
Member

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
Copy link

siw1973 commented Mar 19, 2024

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
Copy link

siw1973 commented Mar 21, 2024

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
Copy link
Member

dshokouhi commented Mar 21, 2024

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

image
image

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
Copy link

siw1973 commented Mar 21, 2024

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
Copy link
Member

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
Copy link

siw1973 commented Mar 26, 2024

Trialing interactive sensor now 👍

@dshokouhi
Copy link
Member

@siw1973 did the interactive sensor make the situation better?

@siw1973
Copy link

siw1973 commented Apr 9, 2024

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
Copy link

zgbee commented Apr 13, 2024

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
Copy link

zgbee commented Apr 14, 2024

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
Copy link

zgbee commented Apr 17, 2024

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
Copy link
Member

@zgbee did you grant the app background access too?

@zgbee
Copy link

zgbee commented Apr 24, 2024

@dshokouhi as far as I know I've granted the proper background access. In my App battery usage settings, I have Allow background usage on, which has the description of "Enable for real-time updates, disable to save battery"

I went into the app preferences and took a screenshot of the All Permissions screen, in case that's helpful for verifying my settings: https://imgur.com/a/Lnf1Uqi

@siw1973
Copy link

siw1973 commented Apr 24, 2024

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.

I've actually had no drops on my wife's phone after adding the "compelling" element to one of the HA Dashboards and also adding the Interaction Sensor. I can't really validate which is keeping the app from closing in the background, but I don't have the Interaction Sensor on my phone, but of course I access the HA CA frequently.

@zgbee what phone do you have, assuming not a Pixel ?

@zgbee
Copy link

zgbee commented Apr 25, 2024

@siw1973 by the "compelling" element to you mean a card for the Interactive sensor? I had previously added one for the App Importance sensor, but not interaction. I'm not home for a couple days, but I've added an Interaction card to one of my dashboards and will try to test behavior this weekend.

I'm running Android 14 (currently build AP1A.240405.002) on a Pixel 7a

@siw1973
Copy link

siw1973 commented Apr 25, 2024

Hi there. unfortunatley the "compelling" element was actually an Octopus Agile Energy Rate card on my Energy Dashboard. This she is actually interested in and actually opens the HA Companion App at least every couple of days when looking at the optimum time to use the household appliances. We both open this a lot now as it can save upto 90% energy dependent on when we run the washing machine / dishwasher / dryer etc..

I added the Interaction Sensor to both of our Phone "Status" cards as well to see how often that triggers.

The point I was making was that as I added both changes together I can't tell which of the two changes has lead to the stable nature of the HA CA not being closed down by Android. Mine never closed down, but I always look at my HA CA at least 5 times a day so I suspect it's the actual opening of the App in the foreground that retains it running in the background.

With respect to the Pixel 7a, I have a Pixel 7 running the same build and don't see half of the options you show on your screen shot when accessing App Permissions ? Through which route do you access them ?

@zgbee
Copy link

zgbee commented Apr 25, 2024

Ah, ok. Well.. it'll be interesting to see if adding the interaction sensor to my dashboard has any effect.

As for the permissions, it was a hidden screen. I went into App info (via the press-hold icon and selecting App info from the menu), then Permissions, and then using the 3-dot menu icon in top-right to select All permissions (didn't realize that existed till yesterday, ha)

@siw1973
Copy link

siw1973 commented Apr 25, 2024

Found it thank you 🤣 Learnt something new today!

I have exactly the same permissions, good to know.

@natebgamer
Copy link

natebgamer commented Apr 25, 2024

I added the interactive card to my dashboard. At first it was working every time even when my phone was locked but on. It would report "On" but like the issues above, after a while it seems all sensors just stop updating due to the app being put to sleep or whatever. I recently moved to a newer phone (S21>S22) so redid all permissions etc and still have the same issues with sensors stopping working after a while if the app hasn't been opened recently.

EDIT: By saying "stopped working" I don't mean stop working completely just delayed sensor updates even when on charge with "fast updates" enabled when on charge.

@dshokouhi
Copy link
Member

I added the interactive card to my dashboard. At first it was working every time even when my phone was locked but on. It would report "On" but like the issues above, after a while it seems all sensors just stop updating due to the app being put to sleep or whatever. I recently moved to a newer phone (S21>S22) so redid all permissions etc and still have the same issues with sensors stopping working after a while if the app hasn't been opened recently.

no the issue is not that all sensors stop updating, thats definitely a background access issue. The issue here is that some intents do not arrive in order to update the phone state sensor quickly. Your issue is unrelated here. Please file a new issue and make sure to go through all device settings to turn off any and all battery /power/data savings.

@natebgamer
Copy link

I added the interactive card to my dashboard. At first it was working every time even when my phone was locked but on. It would report "On" but like the issues above, after a while it seems all sensors just stop updating due to the app being put to sleep or whatever. I recently moved to a newer phone (S21>S22) so redid all permissions etc and still have the same issues with sensors stopping working after a while if the app hasn't been opened recently.

no the issue is not that all sensors stop updating, thats definitely a background access issue. The issue here is that some intents do not arrive in order to update the phone state sensor quickly. Your issue is unrelated here. Please file a new issue and make sure to go through all device settings to turn off any and all battery /power/data savings.

Sorry yes I misspoke with saying "Stop working" instead of delayed, but my issues are definitely the same as all those listed above where sometimes it can take a while for the sensors to update.

@dshokouhi
Copy link
Member

but my issues are definitely the same as all those listed above where sometimes it can take a while for the sensors to update.

That's really not the same here. One state that does not appear long is ringing. If the phone misses that intent then indeed the state will be missing. As far as I know the other states are working. Your issue described still sounds like background access if it impacts all sensors for a while.

@siw1973
Copy link

siw1973 commented May 2, 2024

I had this go down on the wife's phone last week. Looks like what was shiny, new and compelling is no longer compelling......

I know this is annoying, but is it possible to force the app into the foreground once a week from Home Assistant to ensure it does not close ? I know this is a total hack, but I'd like to have this reliably working.

@dshokouhi
Copy link
Member

I know this is annoying, but is it possible to force the app into the foreground once a week from Home Assistant to ensure it does not close ? I know this is a total hack, but I'd like to have this reliably working.

https://companion.home-assistant.io/docs/notifications/notification-commands#webview

this command will open the app

@dshokouhi dshokouhi changed the title phone state sensor stopped working after android 14 update phone state sensor stopped updating instantly after android 14 update May 2, 2024
@hatchling
Copy link

Just to add a data point:

After migrating from my affected Pixel 5 to a new Pixel 7 Pro (which is on Android 14) I no longer experience this issue. The Pixel 7 charger type state updates instantly.

My wife's Pixel 6 is still affected.

I suspect there is more to this issue than strictly the Android version but unfortunately don't have hard data to back this up.

@zgbee
Copy link

zgbee commented May 3, 2024

fwiw, adding a card for the interaction sensor to my dashboard didn't seem to have any effect. I'm travelling right now so it has to wait a few days, but I'm actually not sure if I've tried manually opening the home assistant app just before I expect the automation to trigger - i.e. if the app is in foreground and phone is unlocked, will the sensor update instantly?

@siw1973
Copy link

siw1973 commented May 3, 2024

@dshokouhi Unfortunately I don't agree with the title change. I have the Companion App stopping sending any information to HA, not instantly, but full stop.

Of course if the App is brought to the foreground that is a separate "hack" and is something that never used to have to be done when I was on Android 13.

If you want me to open up a separate issue then fine, but a number of us are having this issue which has been discussed here.

@dshokouhi
Copy link
Member

Unfortunately I don't agree with the title change. I have the Companion App stopping sending any information to HA, not instantly, but full stop.

Of course if the App is brought to the foreground that is a separate "hack" and is something that never used to have to be done when I was on Android 13.

Then that is not the same issue and you should create a new one with logs. This issue is about a device with missing intents that are used to update instantly. Full stop means there is something else at play. Every 15 minutes the sensor worker runs and that does not use intents and will pull the actual data unless there is an error. So full stop is not the same issue here. I think some users are conflating the actual issue with other similar issues here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working sensor-tracking
Projects
None yet