App frequently killed by Android while in background

[ilmotta]

Problem

Summary

Status is frequently killed by Android while in background for 1-2 mins, forcing re-authentication and slow startup to get back to the screen the user originally was. The UX is also affected by the loss of in-memory state (e.g. drafted, but not sent message in composer).

Reporter: IFT member.
Devices: Samsung Galaxy Fold 5 and Pixel 9 Pro Fold with GrapheneOS.
App Version 2.33.2

Environment

Build	2.33.2
Devices	Samsung Galaxy Fold 5 (12 GB RAM), Pixel Fold 9 Pro (GrapheneOS)
Android	14
Battery saver	off
Background process limit	Standard (default)
Status profiles	3, only 1 active
Dataset size	9 contacts, 1 community (Status), ~500 msgs, 62 images

How does the problem affect the UX?

Users are experiencing frequent and rapid termination of the Android application process when it's placed in the background. This occurs consistently after only 1-2 minutes of using other applications. Upon returning to the app, Status restarts completely, forcing the user to:

1. Re-select their profile, even if only one profile is primarily used (this problem will be resolved separately by Auto select last profile on app start - Biometric #22447).
2. Re-authenticate using biometrics or password.
3. Endure a slow startup sequence (measured at ~7-10 seconds average, including an initial black screen) before reaching their previous screen (e.g. a specific chat).

This behavior introduces significant friction, making multitasking or briefly checking other apps highly disruptive. The issue is not believed to be an application crash (confirmed by lack of Sentry crash reports during reproduction) but rather the Android OS aggressively killing the process, likely due to high resource consumption, specifically memory.

Steps to reproduce

The bug is likely not deterministically reproducible, otherwise we would have caught it in our testing and personal usage. @ilmotta has also experienced this problem, but very rarely after creating a new profile and with NO data.

It is clear that the app can be terminated by the OS even with small DB sizes.

• The user does NOT have push notifications enabled.
• User confirmed battery saver modes or non-standard background process limits were NOT enabled in Android Developer options.

1. Launch and use the Status app on an affected Android device.
2. Switch away from Status to another application (e.g. Discord, Browser).
3. Use the other application(s) for approximately 1-2 minutes (switching between 2-3 apps during this time also triggers it). Consider waiting more than 3 minutes.
4. Switch back to the Status app.
5. Observe the app re-initializing. In practice, you will see the profiles list screen, as if you logged out.

Expected behavior

The app process should remain alive in the background for a reasonable duration on modern devices with ample RAM (like a 12GB Fold 5), especially after only 1-2 minutes. Background termination should not happen after hours of leaving Status in the background.

Actual behavior

• Frequent process kills.

Analysis and root cause investigation

The Desktop Core team has prioritized and started profiling status-go memory usage. Reach out to @jrainville or @osmaczko for more details.

• High memory usage (the primary suspect): User provided meminfo dumps showing the app's Resident Set Size (RSS) hovering around ~850MB during normal foreground usage on a device with 12GB RAM. This relatively high footprint likely makes it a prime candidate for Android's Low Memory Killer (LMK) when backgrounded, even on high-spec devices and even with a relatively small user data profile.
• Memory spike at login: a significant jump in memory was observed: ~370MB on the profile selection screen jumping to ~850MB immediately after login/initialization.
• Evidence strongly points to the OS terminating the process (likely LMK) rather than an application crash.

Recommendations

• Use Android Studio to profile the app, or Go pprof to find top allocators.
• Investigate how the frontend code (excluding status-go) is affecting the total memory consumption.
• Function ActivityManager#gethistoricalprocessexitreasons might prove to be helpful if we log its results.
• Investigate if we could reduce large memory allocations during initialization, for example by lazy loading more aggressively, both in status-go and frontend.
• Investigate potential memory leaks.
• Investigate if the Android API can help us mitigate the LMK daemon, for example by using onTrimMemory (see https://developer.android.com/topic/performance/memory).
• Check how we can aggressively release resources when the app is backgrounded, e.g. image or data caches.
• Check if we can reduce CPU usage while the app is backgrounded by reducing the number of active go routines.

[osmaczko]

Hey @ilmotta, the 2.33.2 mobile app version points to this commit, which doesn't include the memory leak fix. I've just cherry-picked it into the release/10.7.x branch, which seems to be the one mobile is using for 2.33.2.

Yesterday, I tested the scenario with a new account that only joined the Status community — memory spikes rapidly. The release with the fix performs much better.

Would you mind testing the app with this fix applied?

[churik]

Thank you @ilmotta for a very detailed description, we'll try to reproduce it and let you know about results on builds without fix and with fix;

as far as I understand this is not a new issue, but rather it exists since 2.30?

[churik]

Adding for references:

#20697 (comment)

#20697 (comment)

#10095

[ilmotta]

Hey @ilmotta, the 2.33.2 mobile app version points to this commit, which doesn't include the memory leak fix. I've just cherry-picked it into the release/10.7.x branch, which seems to be the one mobile is using for 2.33.2.

Yesterday, I tested the scenario with a new account that only joined the Status community — memory spikes rapidly. The release with the fix performs much better.

Would you mind testing the app with this fix applied?

Thank you @osmaczko. I just approved the cherry-pick PR. We should be able to test and release another hotfix with that. cc @churik

Although I hope the urgent fix is just that single cherry-pick commit, the root problem I believe still exists because the problem existed before (and for years). The issue seems to vary a lot per device or OS. The high memory usage while the app is in the background may require special handling from mobile (not status-go) code. And there's a chance that we might need to work on reducing the memory footprint of the mobile app (esp. in status-go) using different strategies (but this can get complex very quickly). We might also improve observability of such problems, for example to log Android's exit reasons when the app starts.

[churik]

@ilmotta

Tested Devices:

• Google Pixel 7a (Graphene OS)
• Samsung Galaxy S24 (Android 14)

Tested from various states:

• Chat screen with typed text in composer
• Wallet screen
• Home chat screen

Time in background:

• from 5–10 minutes up to 1 hour

Actions during background:

• Switched between multiple apps
• Locked/unlocked the phone
• With/without updates (so updates for communities / 1-1 chats / from synced devices have been received ot not)

Observations:

• No sync issues observed
• Messages in 1-1 and community chats were received properly
• App was not killed, except for one single case (right after opening an account). It never happened again after that.
• Push notifications were disabled during tests
• After 1 hour of backgrounding, app successfully restored full functionality when brought to foreground

Additional note:
Please ensure Settings > Advanced is properly configured — possible misconfig during migration could affect behavior. (Light client: enabled, Store confirmations: disabled, Peer syncing: disabled)

. I just approved the cherry-pick PR. We should be able to test and release another hotfix with that. cc @churik

@ilmotta if you think a hotfix can make things better, happy to assist in that

[pavloburykh]

@ilmotta here are investigation results from my side:

Tested device/OS:

• Device: Samsung Galaxy A52 (Physical device)
• OS Version: Android 12

Builds tested:

• Release build (2.33.2)
• Nightly build (Apr 8, 2025)

What has been tested:

• leaving Status app in the background for 2-10 minutes with different screens opened (i.e. Home screen, Wallet screen, 1-1 chat, Status community home screen, Status community channels etc.)
• using other apps while Status is backgrounded
• locked device state

Results:

• Could not reproduce the described behavior when app is killed after reopening it from background.
• The Status app was not force-killed by the system even after 5 - 10+ minutes in the background.
• App restored correctly to previous screen and state upon returning to foreground.
• No unexpected logout, authentication prompt, or memory loss observed.

Additional Investigation: CPU and Memory usage (Foreground vs Background)

Tools Used:

• adb shell top -n 1 | grep status
• adb shell ps | grep status
• adb logcat
• Manual app lifecycle control (foreground → background)
• Monitored process states and memory footprint in real-time

Release Build Findings:

• CPU Spikes:
  • Upon return to foreground, CPU briefly spiked to ~210%, indicating heavy processing (likely wallet sync, data pulls etc).
• Memory (RES):
  • Ranged between 680MB–850MB in foreground.
  • Gradually reduced in background (~470MB)
• D (Uninterruptible Sleep) State:
  • After some idle time in background, the app process entered D state.
  • From what I have read it might Indicate a thread is blocked on I/O (e.g., disk, DB, socket) and cannot be interrupted. @ilmotta I am not sure if this behaviour is expected, so maybe we need to take a deeper look at this.

Pavlos-MacBook-Pro:AndroidStudioProjects pavloburykh$ adb shell ps | grep status
u0_a3465 8398 858 33825576 874184 0 0 D im.status.ethereum

Nightly Build Findings:

• CPU usage behaved similarly:
  • Foreground: frequent spikes during wallet interaction (100–230%)
  • Background: fluctuated between 10–90% for several minutes
• Eventually entered D state in the background, just like the release build.
• RAM usage peaked higher (up to 1.2 GB) in nightly build

[ulisesmac]

Tried to reproduce it with no luck on my Galaxy Z Fold 6, that has the same Android version and RAM amount, the specs are very similar.

Given that on a Galaxy A52 (tested by @pavloburykh ) it can't be reproduced, I'd discard the amount of memory used - an A52 has up to 8GB of RAM. Do user's installation has any custom config set? How other super apps behave? Very hard to solve since we can't reproduce it.

On our side (mobile), we could lazy-load some modules to improve memory consumption and perform syncing tasks until the screens are visited (chats, wallet, communities) and, as we talked about before @ilmotta , explore options to keep the session always alive, but the user is online only when the app is opened (like other messaging apps).

[ilmotta]

Tried to reproduce it with no luck on my Galaxy Z Fold 6, that has the same Android version and RAM amount, the specs are very similar.

Given that on a Galaxy A52 (tested by @pavloburykh ) it can't be reproduced, I'd discard the amount of memory used - an A52 has up to 8GB of RAM. Do user's installation has any custom config set? How other super apps behave? Very hard to solve since we can't reproduce it.

On our side (mobile), we could lazy-load some modules to improve memory consumption and perform syncing tasks until the screens are visited (chats, wallet, communities) and, as we talked about before @ilmotta , explore options to keep the session always alive, but the user is online only when the app is opened (like other messaging apps).

Thanks a lot for trying to replicate the problem @ulisesmac. So far, it seems to not be so much about the total memory consumption, although that can be a factor. When the app is backgrounded, the OS may decide to kill the app because it may prefer to reserve the cache for other active apps. Spikes in memory growth I imagine could also make the LMK daemon think the app should be killed. We are also not handling onMemoryTrim, which is a way for the OS to talk to Status and request that we purge data (e.g. caches). Perhaps before the app is backgrounded, we should consider a more aggressive purge of cached data. I mentioned these points in the issue description above.

On our side (mobile), we could lazy-load some modules to improve memory consumption and perform syncing tasks until the screens are visited (chats, wallet, communities) and, as we talked about before @ilmotta , explore options to keep the session always alive, but the user is online only when the app is opened (like other messaging apps).

After the mobile app is better profiled and we mitigate or resolve the low-hanging fruits (if there are any) I think it might come down to exploring lazy-loading as you said, both in status-go & frontend. Unfortunately, if we go that route it's going to be complex and likely introduce breaking changes that will require coordination between Desktop & Mobile.