You Have Mail stops running after app restart from GrapheneOS system update
Closed this issue · 8 comments
The You Have Mail app stops running in the background after a system-wide app restart on GrapheneOS.
I have noticed this after a GrapheneOS (GOS) system update. For examples of other apps that will restart running in the background on my Pixel 5a after an app restart (after GOS optimizes third-party apps after a GOS system update) are: Signal, Cheogram, FairEmail, and Mullvad VPN (but I'm not sure if Mullvad really counts).
I'm not sure if this is always consistent after every single GOS update that optimizes apps, but I do. If I've forgotten to check after a GOS app restart to ensure You Have Mail is still running in the background, then I'll probably noticed my Proton Mail alerts have been unusually quiet within a few hours.
Is there a way to make sure You Have Mail starts running again after an app restart after a GOS update that optimizes apps?
Thanks for the report.
I am using GrapheneOS on a Pixel 6 and so far I have never seen the app not recover correctly after the update process.
I will keep an eye on it just in case.
I forgot to mention that I'm using the Pixel 5a (barbet
).
Perhaps the SoC on the Pixel 6 series and newer devices are simply more powerful, but that is only a guess at this point. I haven't set up You Have Mail on my Pixel Tablet (tangorpro
) to test this hypothesis out yet.
This happened again with the 2024042100
release.
I'll try to remember to save a system log if this happens again. as I only saw my phone auto-restarted after a GOS update about 6 hours later.
This is the app's log after restarting from a GOS update yesterday: You Have Mail log 4ec3c2cc57fb.txt
This is the log after a restart on June 23rd: You Have Mail log 05f9adcc3b68.txt
Thanks for the logs, this is definitely not something I was expecting would happen.
I will investigate as soon as I am able.
Preliminary investigation and this thread leads to believe this is related to some limitation in Android 12 that no longer allow this sort of behavior.
Personally, I have never seen this before and I don't think the difference in hardware should haven any impact on this, but never say never.
In any case, I was planning on doing some changes so that the polling mechanism only runs from the worker job, which should help with this situation. I don't have any ETA for this, but it will arrive when it is ready.
This should be fixed with the 0.16.0. If it is not, feel free to reopen the issue.
Thank you! As v0.16.0 hasn't made it onto F-Droid yet, I don't have anything to report; but hopefully this issue was fixed with this release.