[Android] Background service can crash and then the app becomes unusable

[jrainville]

Bug Report

Description

I've been testing RC5 with my main account and out of nowhere, just by navigating, I see the background service icon at the top flashing and the app lagging.
Then, if I try to do any action in the app, nothing happens or I get an error like this one:

Clearly, the background service (status-go) died. Because if I close the app, which would normally just close the front-end, I need to re-login.

Here is one of the app logs where it happened:

app_20260604_170453.log

0xad..888e-2026-06-04T21-07-15Z.log

Steps to reproduce

Not clear. I have a big account where I'm admin in multiple communities and I have multiple groups and 1-1 chats.
It happened 3 times by just messaging people and navigating from channel to channel.

Expected behavior

No stoppage

Actual behavior

Backend dies and the app becomes unusable

Additional Information

• Status app version: 2.38.0 RC5
• Operating System and version: Android 16
• Mobile Device: Samsung S23

[jrainville]

I restarted my phone and now it seems to be working better. So maybe I was having too much garbage in my memory, or maybe it was because I opened the app after a day of not using it, so it had to fetch a lot of data and it overloaded, or it's just some random problem my phone had because I was using it to debug over the day.

If it's one of the two first, we should do something about it, because for the first one, someone with a less powerful phone will run into the same issue. If it's the second, anyone could experience it if they just stop using the app for a day.

I'll keep monitoring.

[jrainville]

It just happened again, but this time the whole app died.

I think it happens when I click on an OS notification. It opens the app and it kinda lags then dies

[jrainville]

I just did a new test and clicking on the OS notification didn't make the app crash, but it did make it go super slow for a second. I think it's because it triggers a mailserver fetch each time it comes back from the background plus does the re seeing of the new message?

[saledjenic]

@jrainville I don't know too much about that part, but if the reason is a mailserver fetch, should we postpone (if we don't do that already) it for 1-2 seconds when the app becomes active again (goes from background to foreground)? And/or fetch messages in chunks if possible?

[jrainville]

I was able to reproduce the bug again by using Status on a release and PR build at the same time on my phone.

The background services both died, clearly because of lack of memory. The Release app was the one with the UI active and it stayed alive, but the bg was dead, so I got the error when trying to send a message
The PR build, when I switched to it, asked me to login again

[jrainville]

I'll start fixing the issue in steps, starting by making sure the app restarts if backend is killed.

Here is the rationale and steps:

Best approach is a layered one, with resilience first:

1. Ship a fast failover path now (detect dead backend, force clean relogin flow).
2. Then reduce resume-time pressure (stagger/heavy-work deferral on foreground).
3. Profile memory and optimize longer term.

Why this order:

• You can’t guarantee Android won’t kill even a foreground service under pressure.
• Right now there is already partial dead-binder retry, but no strong user-facing state recovery when backend is gone mid-session.
• So reliability UX should not depend on memory optimization landing first.

What I found in your code confirms this:

• UI foreground/background is sent on activity resume/pause in StatusQtActivity.java and StatusQtActivity.java.
• Service client already retries once on dead binder in StatusGoServiceClient.java.
• On foreground, backend services are resumed immediately via ResumeServices in StatusGoService.java.
• Startup login gating is based on active account from backend in app_controller.nim and service.nim.
• ADR explicitly says service live state is authoritative and service-kill should lead to onboarding/re-auth in 0001-android-status-go-as-a-service.md.

So the bug is likely a runtime transition gap, not just missing architecture.

Opinionated recommendation

• Primary fix: implement explicit “backend unavailable / restarted” handling while app is already open.
• Secondary fix: on app foreground, do staged resume (critical first, heavy sync later).
• Parallel: memory profiling and reductions, but don’t block reliability fix on it.

Concrete behavior to aim for

• If backend call returns disconnected/dead twice or active-account is empty while UI is in logged-in state:
  • show one blocking recovery screen,
  • clear volatile UI session state,
  • route to login/onboarding cleanly (or force cold restart if simpler/safer on Android).
• On resume:
  • resume only essential messaging path immediately,
  • delay heavy sync/mailserver/history by 1-3s and/or chunk it,
  • cancel/debounce duplicate resume-triggered work.

Risk tradeoff

• “Restart frontend + relogin” is acceptable and should exist regardless of memory tuning.
• Memory work alone won’t eliminate this class of failure.
• Staged resume reduces chance of re-triggering OOM exactly at unpause/notification open, where you’re seeing repros.