Open personaingrata opened 10 months ago
It's a known fact that the Android OS will sooner or later kill processes without notifications, even when their battery usage is set to unrestricted.
The notification service should be restarted every 15 minutes.
As-is I'm afraid this is not actionable. We would need to get the logs from adb or check the scheduler from adb to know what doesn't happen for you. It might be also Android 14 related: #6045
thank you for looking into this!
The notification service should be restarted every 15 minutes.
what i observed in Developer options --> running services is that the PushNotificationService was still up and running. i opened the tuta app and was (not so) suprised that there's again an email which i didn't get notified about. i can't remember if the :pushprocess was running, needs further investigation.
We would need to get the logs from adb or check the scheduler from adb to know what doesn't happen for you.
this is a production device that i daily use, i'm not comfortable activating usb debugging and to connect it to a (untrusted) computer, get the logs and share it in public. but since this is a long lasting, deal breaking issue, i'll consider setting up a fresh minimal vm to pull the logs out, if you provide me a discrete way to to share the logs with you and the tuta devs. this would also be way less pain than migrating away from tutanota.
It might be also Android 14 related:
i'm in doubt, i'm having issues with notifications a couple years already and i'm not alone.
Ah thank you for the info! If you see that PushNotificationService
it means that the push process should be running as well and the situation is then very puzzling.
Could you please after running into such a situation get the logs via Settings -> About -> Send logs and then them to hello@tutao.de, mentioning this issue? Thank you!
hi charlag, today it happened again and i did what you say and send the logs via the about screen. there's now two issues with these logs:
i enabled native code debugging (ptrace) now for the time being in order to get anything useful out of the logs but the issue with the capturing only since app start remains. seems like ADB is the way to go?
ptrace
doesn't have anything to do with these logs I believe.
adb
would be ideal but we will analyze what you've sent us, thank you
i've sent another bugreport + adb log today. the adb log starts 11-09 the mail (i didn't get notified about) was sent 11-11 17:21 and the app was opened shortly after
same issue for me. I'm not receiving any more notifications the past 2-3 updates. I'm using the fdroid version (v. 3.118.30).
Unfortunately tuta is no longer reliable if this keeps happening as I missed some very important email I was waiting for, because I simply forgot (that's what notifications are for). I checked all settings, notifications are enabled (even disabled/enabled them again).
Same issue here, especially behind VPN (such as NordVPN or ProtonVPN), but VPN isn't the issue because apps like Signal work perfectly fine behind it, providing immediate notifications when they are received even on Android devices without Google Play Services. Tuta doesn't rely on Google Play Services just like Signal, but Tuta's notification pushing system is very unreliable.
Quite often, when opening Tuta Android app, up at the top, it says "Offline". I don't know why it goes offline... I know I switch VPN servers sometimes, but other apps like Signal don't have a problem keeping up and reconnecting on their own to provide reliable notification services.
thanks for adding your voice to this issue @Nach0Kai and @GY8VSdYYzvL8-K6T
adding some transparency: it's been a little over two months now since i opened this issue and sent in logs, all i got as a response was that my WebView could be outdated, which is not the case as my phone gets frequent updates on all components... WebView/TriChrome Library 120.0.6099.193.0 + Tutanota app 3.119.10 = issue persists
to accelerate the process, how about you guys send in your logs to hello@tutao.de, mentioning this issue?
maybe these logs can help to nail the issue down?
Tuta log 020f810278b2.txt Tuta log 0248ba6bb2c2.txt Tuta log e72566ec9cca.txt
maybe these logs can help to nail the issue down?
Tuta log 020f810278b2.txt Tuta log 0248ba6bb2c2.txt Tuta log e72566ec9cca.txt
thanks for the logs, doesn't seem look like anything is broken judging by the logs
I have the same issue here for: Nokia XR20 Android 13 (stock) F-droid version of Tutanota
It's kind of random for me, sometimes I get notifications, sometimes I don't
Hi, I experience the same issue. Maybe these logs could help further? I'll send them to the mail mentioned above as well just to be safe.
Hi, I experience the same issue. Maybe these logs could help further? I'll send them to the mail mentioned above as well just to be safe.
this might be the relevant part:
1709240641.408 5678 5678 E AndroidRuntime: FATAL EXCEPTION: main
1709240641.408 5678 5678 E AndroidRuntime: Process: de.tutao.tutanota:pushprocess, PID: 5678
1709240641.408 5678 5678 E AndroidRuntime: android.app.RemoteServiceException$ForegroundServiceDidNotStartInTimeException: Context.startForegroundService() did not then call Service.startForeground(): ServiceRecord{c2baa2e u0 de.tutao.tutanota/.push.PushNotificationService}
1709240641.408 5678 5678 E AndroidRuntime: at android.app.ActivityThread.generateForegroundServiceDidNotStartInTimeException(ActivityThread.java:2136)
1709240641.408 5678 5678 E AndroidRuntime: at android.app.ActivityThread.throwRemoteServiceException(ActivityThread.java:2107)
1709240641.408 5678 5678 E AndroidRuntime: at android.app.ActivityThread.-$$Nest$mthrowRemoteServiceException(Unknown Source:0)
1709240641.408 5678 5678 E AndroidRuntime: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2401)
1709240641.408 5678 5678 E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:106)
1709240641.408 5678 5678 E AndroidRuntime: at android.os.Looper.loopOnce(Looper.java:205)
1709240641.408 5678 5678 E AndroidRuntime: at android.os.Looper.loop(Looper.java:294)
1709240641.408 5678 5678 E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:8279)
1709240641.408 5678 5678 E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
1709240641.408 5678 5678 E AndroidRuntime: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:552)
1709240641.408 5678 5678 E AndroidRuntime: at com.android.internal.os.ExecInit.main(ExecInit.java:49)
1709240641.408 5678 5678 E AndroidRuntime: at com.android.internal.os.RuntimeInit.nativeFinishInit(Native Method)
1709240641.408 5678 5678 E AndroidRuntime: at com.android.internal.os.RuntimeInit.main(RuntimeInit.java:359)
we see that it occurs rarely but have no way to reproduce it at the moment
I'm experiencing this as well. GrapheneOS as well. Could this be an OOM issue? Or should the service have been restarted regardless?
It's a known fact that the Android OS will sooner or later kill processes without notifications, even when their battery usage is set to unrestricted.
The notification service should be restarted every 15 minutes.
As-is I'm afraid this is not actionable. We would need to get the logs from adb or check the scheduler from adb to know what doesn't happen for you. It might be also Android 14 related: #6045
I think there's a misunderstanding here. Newer versions of Android require a persistent notification to be present in order to take advantage of disabled battery optimizations. Since there is no persistent notification showing up from the Tuta app, I strongly suspect this is why I'm also not seeing any notifications from Tuta unless I recently had the app open when the email arrives.
As an example, FairEmail notifications work fine on my system because this notification is always present (I'm on an up-to-date release of GrapheneOS):
I understand how issues like these are hard to debug,especially without any reproducible steps,but wouldn't periodic fetching of emails be an alternate solution?
Make it customizable,like K-9 client.
Another solution would be a persistent notification like @cp289 suggested. Or why not both with means of turning off fetching entirely?
Just some suggestions, as IMO most people would rather sacrifice some battery life to have a reliable way of getting their emails.
Bug in mobile app
Describe the bug no notifications about incoming mails
To Reproduce Steps to reproduce the behavior:
Expected behavior i would like to be notified about incoming mails
Smartphone (please complete the following information):
current Tutanota app: 3.118.22 F-Droid
Additional context The Tutanota Android app doesn't reliable notify about incoming/new mails, in many cases, when i open the Tutanota app, i see a new mail which i didn't get push notified for, once again... This is not a new issue, i have this issue ever since i switched to Tutanota in 2018 and it has followed me over several devices ( Pixel, Galaxy,...) and all phones had no Google Play Services installed, which shouldn't be a problem since Tutanota iirc promoted the Android app with "Googleless Push". Battery Restrictions/Optimizations has always been off for Tutanota - App Battery Usage --> Unrestricted And there's also no other power management app running that could kill the app. None of the closed issues on GitHub solved it and i'm obviously not the only Android user with push notification issues. It's frustrating and what makes this even more frustrating is, i'm paying for a service that doesn't deliver (notifications in this case ;-)) Free solutions can do this task better!
Other apps which rely on their own push never failed on me, just to name a few: Signal, Threema, FairEmail, Element,... They all have one thing in common, they show a persistent notification. It's a known fact that the Android OS will sooner or later kill processes without notifications, even when their battery usage is set to unrestricted.
So please Tutanota Team, take this issue seriously and clutter my notification list with another persistent notification, in order to always get notified about incoming mail!
Thanks for reading