[android] unreliable notifications

[personaingrata]

• [ x ] This is not a feature request (existing functionality does not work, not missing functionality).
• [ x ] I've searched and did not find a similar issue. I did! but the reports were all closed but didn't fix the issue

Bug in mobile app

Describe the bug no notifications about incoming mails

To Reproduce Steps to reproduce the behavior:

1. open the Tutanota app
2. suddenly you see new important mails, that you didn't get notified for

Expected behavior i would like to be notified about incoming mails

Smartphone (please complete the following information):

• Device: Pixel 6
• OS: GrapheneOS
• Version Android 14

** 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

[charlag]

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

[personaingrata]

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.

[charlag]

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 [email protected], mentioning this issue? Thank you!

[personaingrata]

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:

• they seem to start the moment i opened the app, but the first email i received and didn't get notified about was ~30 hour ago
• i remembered that i disabled "Native code debugging" in GrapheneOS security settings, since it slightly weakens the app sandbox.

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?

[charlag]

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

[personaingrata]

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

[Nach0Kai]

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

[SSJPKXL]

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.

[personaingrata]

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 [email protected], mentioning this issue?

[personaingrata]

maybe these logs can help to nail the issue down?

Tuta log 020f810278b2.txt Tuta log 0248ba6bb2c2.txt Tuta log e72566ec9cca.txt

[charlag]

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

[pappasadrian]

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

[mo-st]

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.

tuta-log.txt

[charlag]

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.

tuta-log.txt

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