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:

Re-select their profile, even if only one profile is primarily used (this problem will be resolved separately by https://github.com/status-im/status-mobile/issues/22447).
Re-authenticate using biometrics or password.
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.

Launch and use the Status app on an affected Android device.
Switch away from Status to another application (e.g. Discord, Browser).
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.
Switch back to the Status app.
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.

Apr 08 '25 04:04 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?

Apr 08 '25 06:04 osmaczko

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?

Apr 08 '25 08:04 churik

Adding for references:

https://github.com/status-im/status-mobile/issues/20697#issuecomment-2451709118

https://github.com/status-im/status-mobile/issues/20697#issuecomment-2452948855

https://github.com/status-im/status-mobile/issues/10095

Apr 08 '25 08:04 churik

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.

Apr 08 '25 10:04 ilmotta

@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

Apr 08 '25 12:04 churik

@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

Apr 08 '25 13:04 pavloburykh

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

Apr 09 '25 00:04 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).

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.

Apr 09 '25 03:04 ilmotta

explore options to keep the session always alive, but the user is online only when the app is opened (like other messaging apps).

I think @seanstrom mentioned to me in private that perhaps we could focus on making Status recover from an OS preemption without looking as if it was preempted. If we can fully recover the app state and fast, this should be possible, and might be sufficiently good. Other apps might be doing something like this. Ideally we should try to make the app less enticing for the OS to kill it, and getting there is going to be a large effort.

Apr 09 '25 04:04 ilmotta

@ilmotta here are investigation results from my side:

Thanks @pavloburykh, very insightful results. The total memory consumption in background and foreground more or less match the data reported by the user. If you can share, what data do you have in the profile (e.g. numbers/names of communities)?

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.

This is a good clue for @qfrank when he starts the investigation.

One quick question @churik @pavloburykh although we can't reproduce exactly now, have you ever encountered the situation where the app seemingly logged out when you brought it back to the foreground? I experienced this recently once, but if my memory serves me well it happened other times with me, although rarely.

Apr 09 '25 04:04 ilmotta

have you ever encountered the situation where the app seemingly logged out when you brought it back to the foreground?

I have experienced yesterday when use local develop build on android simulator, I noticed :profile/logout were dispatched and endpoint logout were invoked, but haven't taken time to investigate it yet @ilmotta

Apr 09 '25 06:04 qfrank

Hey @ilmotta

If you can share, what data do you have in the profile (e.g. numbers/names of communities)?

3 communities (1 of them is Status community)
3 wallet accounts (2 of them hold tokens)
1 contact
1 chat (1-1)
1 group chat

One quick question @churik @pavloburykh although we can't reproduce exactly now, have you ever encountered the situation where the app seemingly logged out when you brought it back to the foreground?

Yes, I have definitely encountered this behavior before, though it didn’t happen very often. It seemed to occur sporadically and wasn’t consistently reproducible.

Apr 09 '25 08:04 pavloburykh

I encountered this once when I used “Log in with sync” — after logging in, the app was killed in the background. I assumed it happened because a large amount of data arrived simultaneously, but there’s no consistent pattern to reproduce it.

If you can share, what data do you have in the profile (e.g. numbers/names of communities)?

Tried with different set:

3 communities / 2 contacts / 2 wallet
6 communities (including Status) / around 30 contacts

Also just in case tried on Relay mode, still no success.

Apr 09 '25 09:04 churik

what if it's about hight node activity? let's say some profiles has a bug state or spammed etc. we should try to actively spam some test profile during it's in background, to make hight node activity

Apr 09 '25 10:04 flexsurfer

I did send 60-100 messages in 1-1 chat + in community to the user in background, there was no difference - all messages were fetched when user got back to foreground, app was not killed

Apr 09 '25 12:04 churik

have you ever encountered the situation where the app seemingly logged out when you brought it back to the foreground?

I have also experienced it in the past.

But now trying to reproduce, I have a hard time. I just saw that my phone has this feature called RAM plus that enables to keep more apps in memory in the background using the storage, so maybe disabling or lowering that would help reproduce?

Otherwise, @osmaczko made a nice find on the status-go side and will open a PR soon ™

Apr 09 '25 15:04 jrainville

have you ever encountered the situation where the app seemingly logged out when you brought it back to the foreground?

I have experienced yesterday when use local develop build on android simulator, I noticed :profile/logout were dispatched and endpoint logout were invoked, but haven't taken time to investigate it yet @ilmotta

weird, unable to reproduce :profile/logout today

Apr 10 '25 10:04 qfrank

found something interesting when I run Status on android emulator today:

04-11 16:45:56.846   570  2557 D ActivityManager: freezer override set to true
04-11 16:45:56.868   570  2557 D ActivityManager: freezer override set to false
04-11 16:45:57.007   320  2717 I netd    : trafficSwapActiveStatsMap() <28.23ms>
04-11 16:45:57.008   320  2717 I netd    : tetherGetStats() -> {[]} <0.62ms>
04-11 16:45:57.048   320  2717 I netd    : trafficSwapActiveStatsMap() <36.95ms>
04-11 16:45:57.048   320  2717 I netd    : tetherGetStats() -> {[]} <0.43ms>
04-11 16:45:57.051   320  2717 I netd    : bandwidthRemoveInterfaceQuota(eth0) <0.85ms>
04-11 16:45:57.052   320  2717 I netd    : bandwidthSetInterfaceQuota(eth0, 9223372036854775807) <0.68ms>
04-11 16:45:57.055   320  2717 I netd    : bandwidthRemoveInterfaceQuota(eth0) <0.41ms>
04-11 16:45:57.056   320  2717 I netd    : bandwidthSetInterfaceQuota(eth0, 9223372036854775807) <0.76ms>
04-11 16:45:57.347   570  2557 D ActivityManager: freezer override set to true
04-11 16:45:57.368   570  2557 D ActivityManager: freezer override set to false
04-11 16:45:57.637 21214 21344 D ReactNativeJS: 2025-04-11T08:45:57.635Z DEBUG [utils.re-frame:24] - Handling re-frame event:  :signals/signal-received
04-11 16:45:57.640 21214 21344 D ReactNativeJS: 2025-04-11T08:45:57.637Z DEBUG [status-im.common.signals.events:33] - Signal received {:type "wakuv2.peerstats"}
04-11 16:45:57.642 21214 21344 D ReactNativeJS: 2025-04-11T08:45:57.640Z DEBUG [status-im.common.signals.events:113] - Event  wakuv2.peerstats  not handled
04-11 16:45:57.846   570  2557 D ActivityManager: freezer override set to true
04-11 16:45:57.865   752   877 D EGL_emulation: app_time_stats: avg=40004.87ms min=40004.87ms max=40004.87ms count=1
04-11 16:45:57.869   570  2557 D ActivityManager: freezer override set to false
04-11 16:45:58.074   320  2717 I netd    : trafficSwapActiveStatsMap() <21.22ms>
04-11 16:45:58.075   320  2717 I netd    : tetherGetStats() -> {[]} <0.67ms>
04-11 16:45:58.077   320  2717 I netd    : bandwidthRemoveInterfaceQuota(eth0) <0.57ms>
04-11 16:45:58.077   320  2717 I netd    : bandwidthSetInterfaceQuota(eth0, 9223372036854775807) <0.34ms>
04-11 16:45:58.107   320  2717 I netd    : trafficSwapActiveStatsMap() <28.29ms>
04-11 16:45:58.108   320  2717 I netd    : tetherGetStats() -> {[]} <0.43ms>
04-11 16:45:58.111   320  2717 I netd    : bandwidthRemoveInterfaceQuota(eth0) <0.53ms>
04-11 16:45:58.112   320  2717 I netd    : bandwidthSetInterfaceQuota(eth0, 9223372036854775807) <0.60ms>
04-11 16:45:58.348   570  2557 D ActivityManager: freezer override set to true
04-11 16:45:58.369   570  2557 D ActivityManager: freezer override set to false
04-11 16:45:58.825   570   600 I ActivityManager: Killing 21214:im.status.ethereum.debug/u0a179 (adj 700): excessive cpu 7670 during 300012 dur=1180331 limit=2
04-11 16:45:58.852   570  2557 D ActivityManager: freezer override set to true
04-11 16:45:58.852   570  2557 D ActivityManager: freezer override set to false
04-11 16:45:58.871   570   602 I libprocessgroup: Successfully killed process cgroup uid 10179 pid 21214 in 43ms
04-11 16:45:58.885   570  4397 I WindowManager: WIN DEATH: Window{83fd4af u0 im.status.ethereum.debug/im.status.ethereum.MainActivity}
04-11 16:45:58.885   570   630 D ConnectivityService: ConnectivityService NetworkRequestInfo binderDied(uid/pid:10179/21214, android.os.BinderProxy@6028934)
04-11 16:45:58.885   570  4397 W InputManager-JNI: Input channel object '83fd4af im.status.ethereum.debug/im.status.ethereum.MainActivity (client)' was disposed without first being removed with the input manager!
04-11 16:45:58.885   570   683 D ConnectivityService: releasing NetworkRequest [ REQUEST id=237, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&NOT_VCN_MANAGED Uid: 10179 RequestorUid: 10179 RequestorPkg: im.status.ethereum.debug] ] (release request)
04-11 16:45:58.888   321   321 I Zygote  : Process 21214 exited due to signal 9 (Killed)

especially this line:

04-11 16:45:58.825   570   600 I ActivityManager: Killing 21214:im.status.ethereum.debug/u0a179 (adj 700): excessive cpu 7670 during 300012 dur=1180331 limit=2

explanation from AI which makes me feel running background applications is very limited:

Process Priority: (adj 700) refers to the process's "adjustment" score, a priority metric. A value of 700 corresponds to a "cached" app (running in the background, not visible).

Reason: excessive cpu 7670 during 300012 indicates the process was killed because it used 7,670 milliseconds (or 7.67 seconds) of CPU time over a 300,012-millisecond (5-minute) period.

Duration Stats: dur=1180331 limit=2 suggests the total duration monitored was 1,180,331 milliseconds (~19.7 minutes), and the CPU usage exceeded a threshold (possibly a limit of 2% of total CPU time, though "limit=2" is ambiguous without more context).

What I have done before this log:

create a new profile
set profile log level to debug
leave Status to background

The issue can be reproduced constantly

Apr 11 '25 10:04 qfrank

yeah that was my thought about hight node activity during spam or bug

Apr 11 '25 10:04 flexsurfer

yeah that was my thought about hight node activity during spam or bug

but I was running status backend server separately 🤔 ofc, hight node activity could be a chance in other case

Apr 11 '25 10:04 qfrank

yeah that was my thought about hight node activity during spam or bug

but I was running status backend server separately 🤔 ofc, hight node activity could be a chance in other case

yeah i just meant, hight node activity will lead to high CPU usage etc

Apr 11 '25 11:04 flexsurfer

What I have done before this log:

create a new profile

set profile log level to debug

leave Status to background

The issue can be reproduced constantly

This can be due to logs spam by waku. Please see: https://github.com/status-im/status-go/pull/6164, it should help.

Apr 11 '25 12:04 osmaczko

Hey mobile team, I did some investigation from the status-go side and have a few findings. Please take a look:

https://github.com/status-im/status-go/pull/6517
https://github.com/status-im/status-go/pull/6519 (and the comments, especially this one)
https://github.com/status-im/status-go/issues/6523

Apr 11 '25 19:04 osmaczko

What I have done before this log:

create a new profile

set profile log level to debug

leave Status to background

The issue can be reproduced constantly

This can be due to logs spam by waku. Please see: status-im/status-go#6164, it should help.

I'm sure it's not since I tried disable log and it's still reproducible @osmaczko maybe it's because the signal wakuv2.peerstats , we could disable(Pause non-essential operations when app goes to background) it when AppStateChange to ToBackground, we might be able to disable something else when ToBackground as well

Apr 14 '25 01:04 qfrank

after disabling wakuv2.peerstats, the api.log looks like this:

2025-04-14T15:30:30.485+0800    DEBUG   RequestLogger   signal  {"type": "backup.performed", "event": {"lastBackup":1744615830}}
2025-04-14T15:30:37.333+0800    DEBUG   RequestLogger   signal  {"type": "envelope.expired", "event": {"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","ids":["0x837667bf013b38abe86ec60054361f2ab49e85c15979e699168685cb724f36d1"],"message":"envelope expired due to connectivity issues"}}
2025-04-14T15:30:37.335+0800    DEBUG   RequestLogger   signal  {"type": "envelope.expired", "event": {"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","ids":["0xd73f7f8c741476717eaf1fec1f517a01dd5b5ca0e60c812aabf1e52d58aa9c25"],"message":"envelope expired due to connectivity issues"}}
2025-04-14T15:30:37.335+0800    DEBUG   RequestLogger   signal  {"type": "envelope.expired", "event": {"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","ids":["0x6d85df5b54348edae1ef5e225a9f13372f67fcab213e98e7891e4f1511a33cf3"],"message":"envelope expired due to connectivity issues"}}
2025-04-14T15:30:37.335+0800    DEBUG   RequestLogger   signal  {"type": "envelope.expired", "event": {"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","ids":["0xc6935b5e1b09d347f48c04bc23e5323a9b247d8b8be3becd01b9053020b8a41f"],"message":"envelope expired due to connectivity issues"}}
2025-04-14T15:30:37.335+0800    DEBUG   RequestLogger   signal  {"type": "envelope.expired", "event": {"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","ids":["0x175e39f89fafbd7711fda8976964330f03dc0b7d4907ba6334d88c0339ea01e9"],"message":"envelope expired due to connectivity issues"}}
2025-04-14T15:30:37.335+0800    DEBUG   RequestLogger   signal  {"type": "envelope.expired", "event": {"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","ids":["0xe279f321bbef599145967618deb5ce6ee0d72b59720e8d9fe5b5883fc5d24d64"],"message":"envelope expired due to connectivity issues"}}
2025-04-14T15:30:37.335+0800    DEBUG   RequestLogger   signal  {"type": "envelope.expired", "event": {"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","ids":["0x5da218c0e4775ced4983b0e9b6bf9ec9b581ed063499c043811442ac92b0e28e"],"message":"envelope expired due to connectivity issues"}}
2025-04-14T15:30:37.335+0800    DEBUG   RequestLogger   signal  {"type": "envelope.expired", "event": {"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","ids":["0xa71ed5298b15df526156e862485765270e43bd2d30eac658a5c5fed0af8b6735"],"message":"envelope expired due to connectivity issues"}}
2025-04-14T15:30:37.335+0800    DEBUG   RequestLogger   signal  {"type": "envelope.expired", "event": {"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","ids":["0xad9723a39a925b7abb4079f59c015f42ee5d0688feac63050d59f7dfe7098665"],"message":"envelope expired due to connectivity issues"}}
2025-04-14T15:30:37.335+0800    DEBUG   RequestLogger   signal  {"type": "envelope.expired", "event": {"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","ids":["0x83ca522ce831f2c556d5f298a7fdb018bffc089b79f42a20f374f0659b025e01"],"message":"envelope expired due to connectivity issues"}}
2025-04-14T15:30:37.528+0800    DEBUG   RequestLogger   signal  {"type": "envelope.expired", "event": {"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","ids":["0xa32f20034e27955d46d969d1af1cb7da0e260cf983549f9b59ec11654c562b09"],"message":"envelope expired due to connectivity issues"}}
2025-04-14T15:30:37.727+0800    DEBUG   RequestLogger   signal  {"type": "envelope.expired", "event": {"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","ids":["0x8dd8806d853d2bdbe237dad44a7d0b86f5bd8d8409eeee9a9491fcc0a5d05e9c"],"message":"envelope expired due to connectivity issues"}}
2025-04-14T15:30:37.927+0800    DEBUG   RequestLogger   signal  {"type": "envelope.expired", "event": {"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","ids":["0xa5bf0a79ab95c2a74ca16236ad7ad9b7fd9ca2d0877d76645de479099c504426"],"message":"envelope expired due to connectivity issues"}}
2025-04-14T15:30:38.127+0800    DEBUG   RequestLogger   signal  {"type": "envelope.expired", "event": {"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","ids":["0x00d38126375c15e301ad70704bd3e19b3110524bcc1b121150ddf4a667c2eb68"],"message":"envelope expired due to connectivity issues"}}
2025-04-14T15:30:38.327+0800    DEBUG   RequestLogger   signal  {"type": "envelope.expired", "event": {"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","ids":["0x14f6a675a456ad1dcd1d5e0a270bd0da39480428983082136cc7e6da51d5aed2"],"message":"envelope expired due to connectivity issues"}}
2025-04-14T15:30:38.529+0800    DEBUG   RequestLogger   signal  {"type": "envelope.expired", "event": {"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","ids":["0xff3a2f28575fb142c1909b0281d9d69c720befc1da5a0a70007ef78c8699a6cc"],"message":"envelope expired due to connectivity issues"}}
2025-04-14T15:33:42.334+0800    DEBUG   RequestLogger   signal  {"type": "envelope.expired", "event": {"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","ids":["0x2c9a8f93aebb8f9737b2455a957e9dec3c4f37427fea04a706332d41f600c29a"],"message":"envelope expired due to connectivity issues"}}
2025-04-14T15:38:30.952+0800    DEBUG   RequestLogger   signal  {"type": "wallet", "event": {"EventParams":null,"accounts":null,"at":0,"blockNumber":null,"chainId":0,"message":"","type":"wallet-tick-reload"}}
2025-04-14T15:38:32.821+0800    DEBUG   RequestLogger   call    {"method": "wallet_fetchPrices", "duration": "1.767018791s", "request": {"id":1,"jsonrpc":"2.0","method":"wallet_fetchPrices","params":[["WETH9","USDC","ZEENUS","WEENUS","XEENUS","WETH","ETH","STT","EURC","UNI","YEENUS","DAI"],["usd","usd"]]}, "response": {"id":1,"jsonrpc":"2.0","result":{"DAI":{"usd":1},"ETH":{"usd":1628.32},"EURC":{"usd":1.136},"STT":{"usd":0.01877},"UNI":{"usd":5.424},"USDC":{"usd":0.9999},"WEENUS":{"usd":0},"WETH":{"usd":1399.67},"WETH9":{"usd":0},"XEENUS":{"usd":0},"YEENUS":{"usd":0},"ZEENUS":{"usd":0}}}}
2025-04-14T15:38:38.477+0800    DEBUG   RequestLogger   call    {"method": "wallet_fetchOrGetCachedWalletBalances", "duration": "7.419979333s", "request": {"id":1,"jsonrpc":"2.0","method":"wallet_fetchOrGetCachedWalletBalances","params":[["0x1d65df753f547e4d7898a65d84a3357d404bace5"],true]}, "response": {"id":1,"jsonrpc":"2.0","result":{"0x1d65df753f547e4d7898a65d84a3357d404bace5":[{"address":"0x0000000000000000000000000000000000000000","assetWebsiteUrl":"","balancesPerChain":{"11155111":{"address":"0x0000000000000000000000000000000000000000","balance":"0","balance1DayAgo":"0","chainId":11155111,"hasError":false,"rawBalance":"0"},"11155420":{"address":"0x0000000000000000000000000000000000000000","balance":"0","balance1DayAgo":"0","chainId":11155420,"hasError":false,"rawBalance":"0"},"1660990954":{"address":"0x0000000000000000000000000000000000000000","balance":"0","balance1DayAgo":"0","chainId":1660990954,"hasError":false,"rawBalance":"0"},"421614":{"address":"0x0000000000000000000000000000000000000000","balance":"0","balance1DayAgo":"0","chainId":421614,"hasError":false,"rawBalance":"0"},"84532":{"address":"0x0000000000000000000000000000000000000000","balance":"0","balance1DayAgo":"0","chainId":84532,"hasError":false,"rawBalance":"0"}},"builtOn":"","chainId":0,"decimals":18,"description":"","marketValuesPerCurrency":null,"name":"Ether","pegSymbol":"","symbol":"ETH","verified":true},{"address":"0x0000000000000000000000000000000000000000","assetWebsiteUrl":"","balancesPerChain":{"11155111":{"address":"0x3e622317f8c93f7328350cf0b56d9ed4c620c5d6","balance":"0","balance1DayAgo":"0","chainId":11155111,"hasError":false,"rawBalance":"0"}},"builtOn":"","chainId":0,"decimals":18,"description":"","marketValuesPerCurrency":null,"name":"Dai Stablecoin","pegSymbol":"USD","symbol":"DAI","verified":false},{"address":"0x0000000000000000000000000000000000000000","assetWebsiteUrl":"","balancesPerChain":{"11155111":{"address":"0x1c7d4b196cb0c7b01d743fbc6116a902379c7238","balance":"0","balance1DayAgo":"0","chainId":11155111,"hasError":false,"rawBalance":"0"},"11155420":{"address":"0x5fd84259d66cd46123540766be93dfe6d43130d7","balance":"0","balance1DayAgo":"0","chainId":11155420,"hasError":false,"rawBalance":"0"},"1660990954":{"address":"0xc445a18ca49190578dad62fba3048c07efc07ffe","balance":"0","balance1DayAgo":"0","chainId":1660990954,"hasError":false,"rawBalance":"0"},"421614":{"address":"0x75faf114eafb1bdbe2f0316df893fd58ce46aa4d","balance":"0","balance1DayAgo":"0","chainId":421614,"hasError":false,"rawBalance":"0"},"84532":{"address":"0x036cbd53842c5426634e7929541ec2318f3dcf7e","balance":"0","balance1DayAgo":"0","chainId":84532,"hasError":false,"rawBalance":"0"}},"builtOn":"","chainId":0,"decimals":6,"description":"","marketValuesPerCurrency":null,"name":"USD Coin","pegSymbol":"USD","symbol":"USDC","verified":false},{"address":"0x0000000000000000000000000000000000000000","assetWebsiteUrl":"","balancesPerChain":{"11155111":{"address":"0xe452027cdef746c7cd3db31cb700428b16cd8e51","balance":"0","balance1DayAgo":"0","chainId":11155111,"hasError":false,"rawBalance":"0"},"1660990954":{"address":"0x1c3ac2a186c6149ae7cb4d716ebbd0766e4f898a","balance":"0","balance1DayAgo":"0","chainId":1660990954,"hasError":false,"rawBalance":"0"},"84532":{"address":"0xfdb3b57944943a7724fcc0520ee2b10659969a06","balance":"0","balance1DayAgo":"0","chainId":84532,"hasError":false,"rawBalance":"0"}},"builtOn":"","chainId":0,"decimals":18,"description":"","marketValuesPerCurrency":null,"name":"Status Test Token","pegSymbol":"","symbol":"STT","verified":false}]}}}
2025-04-14T15:38:38.543+0800    DEBUG   RequestLogger   call    {"method": "wallet_getLastWalletTokenUpdate", "duration": "140.625µs", "request": {"id":1,"jsonrpc":"2.0","method":"wallet_getLastWalletTokenUpdate","params":[]}, "response": {"id":1,"jsonrpc":"2.0","result":{"0x1b1e9de2c0de2879be631857051f865d72411ecc":1744616317,"0x1d65df753f547e4d7898a65d84a3357d404bace5":1744616318}}}
2025-04-14T15:38:38.836+0800    DEBUG   RequestLogger   call    {"method": "wallet_fetchPrices", "duration": "296.235375ms", "request": {"id":1,"jsonrpc":"2.0","method":"wallet_fetchPrices","params":[["ETH","DAI","USDC","STT"],["usd","usd"]]}, "response": {"id":1,"jsonrpc":"2.0","result":{"DAI":{"usd":1},"ETH":{"usd":1628.32},"STT":{"usd":0.01877},"USDC":{"usd":0.9999}}}}
2025-04-14T15:38:39.132+0800    DEBUG   RequestLogger   call    {"method": "wallet_fetchMarketValues", "duration": "579.579291ms", "request": {"id":1,"jsonrpc":"2.0","method":"wallet_fetchMarketValues","params":[["ETH","DAI","USDC","STT"],"usd"]}, "response": {"id":1,"jsonrpc":"2.0","result":{"DAI":{"CHANGE24HOUR":0.00008325545489307196,"CHANGEPCT24HOUR":0.008326370489658024,"CHANGEPCTDAY":0.009090066997099244,"CHANGEPCTHOUR":-0.001886803300455972,"HIGHDAY":1.00003158752022,"LOWDAY":0.999744803914485,"MKTCAP":3141982656.101391},"ETH":{"CHANGE24HOUR":15.270468329489859,"CHANGEPCT24HOUR":0.9464352070010509,"CHANGEPCTDAY":1.9761306262053062,"CHANGEPCTHOUR":0.32292993757317173,"HIGHDAY":1659.4972152219,"LOWDAY":1595.15348993512,"MKTCAP":196573994251.15475},"STT":{"CHANGE24HOUR":-0.001209625999688789,"CHANGEPCT24HOUR":-6.0536036512946145,"CHANGEPCTDAY":-1.0673432635457665,"CHANGEPCTHOUR":-0.043959588298768185,"HIGHDAY":0.0195014481079833,"LOWDAY":0.01861566756923201,"MKTCAP":127742996.68734562},"USDC":{"CHANGE24HOUR":0.00009409806522309161,"CHANGEPCT24HOUR":0.009411458714875255,"CHANGEPCTDAY":0.0018086429118132513,"CHANGEPCTHOUR":-0.00002901695480245291,"HIGHDAY":1.00066454471066,"LOWDAY":0.999331699862371,"MKTCAP":60074416396.87105}}}}
2025-04-14T15:38:42.333+0800    DEBUG   RequestLogger   signal  {"type": "envelope.expired", "event": {"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","ids":["0x71328040e1aa2b1c60e55ee5efdf47ef9cf3f9874d7ef61389bfa29a456aeb91"],"message":"envelope expired due to connectivity issues"}}
2025-04-14T15:43:42.331+0800    DEBUG   RequestLogger   signal  {"type": "envelope.expired", "event": {"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","ids":["0x83a53092ea61c8c8b1eeb63fc524cf805a3ac8eec7467cb6287d53e4a1038574"],"message":"envelope expired due to connectivity issues"}}
2025-04-14T15:48:30.964+0800    DEBUG   RequestLogger   signal  {"type": "wallet", "event": {"EventParams":null,"accounts":null,"at":0,"blockNumber":null,"chainId":0,"message":"","type":"wallet-tick-reload"}}
2025-04-14T15:48:42.348+0800    DEBUG   RequestLogger   signal  {"type": "envelope.expired", "event": {"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","ids":["0x3de22503ae8205527a43255ebfd682f784d28420f265c7f3a7f92c60c9cababf"],"message":"envelope expired due to connectivity issues"}}
2025-04-14T15:53:42.351+0800    DEBUG   RequestLogger   signal  {"type": "envelope.expired", "event": {"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","ids":["0xb270baba8200f073d5efce7e4196a3bcbbe9b12b69bbe1940bfa464de140dfa3"],"message":"envelope expired due to connectivity issues"}}
2025-04-14T15:58:30.971+0800    DEBUG   RequestLogger   signal  {"type": "wallet", "event": {"EventParams":null,"accounts":null,"at":0,"blockNumber":null,"chainId":0,"message":"","type":"wallet-tick-reload"}}
2025-04-14T15:58:42.350+0800    DEBUG   RequestLogger   signal  {"type": "envelope.expired", "event": {"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","ids":["0x71dd4e9aae7cde7e6272a18eafe63507645b986d6be66ff40f179934af9a265b"],"message":"envelope expired due to connectivity issues"}}
2025-04-14T16:03:42.349+0800    DEBUG   RequestLogger   signal  {"type": "envelope.expired", "event": {"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","ids":["0x4cf61e0101c7b476d0cf0e0d493ecee3e649595bf1ad34e019d53d8aa744e6bd"],"message":"envelope expired due to connectivity issues"}}
2025-04-14T16:08:30.946+0800    DEBUG   RequestLogger   signal  {"type": "wallet", "event": {"EventParams":null,"accounts":null,"at":0,"blockNumber":null,"chainId":0,"message":"","type":"wallet-tick-reload"}}
2025-04-14T16:08:41.831+0800    DEBUG   RequestLogger   signal  {"type": "envelope.expired", "event": {"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","ids":["0x2e43897c6e69f4e56da589f3a79091cc4ade63bbeac1a250d4af3c03c15a9f27"],"message":"envelope expired due to connectivity issues"}}
2025-04-14T16:13:42.324+0800    DEBUG   RequestLogger   signal  {"type": "envelope.expired", "event": {"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","ids":["0x3143087173fd62515f378ee1d948e91b04ec6b51d5dd0494255a59ba606911df"],"message":"envelope expired due to connectivity issues"}}
2025-04-14T16:18:30.944+0800    DEBUG   RequestLogger   signal  {"type": "wallet", "event": {"EventParams":null,"accounts":null,"at":0,"blockNumber":null,"chainId":0,"message":"","type":"wallet-tick-reload"}}
2025-04-14T16:18:42.327+0800    DEBUG   RequestLogger   signal  {"type": "envelope.expired", "event": {"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","ids":["0x62eba256f0f3006a527cc1a17f557e2e6c0fbfd6c3897b7c08bc9f01815bebdf"],"message":"envelope expired due to connectivity issues"}}

and the issue excessive cpu can be still reproducible, it happens in around 20 minutes after switch Status app in background each time, I didn't find the cause, it's most proberbly relate to frontend side this time as Status Backend Server was running separately.

Apr 14 '25 13:04 qfrank

I also made the following attempts:

Set export STATUS_BACKEND_SERVER_ENABLED=1
Commented out the code for creating websocket and http requests to the Status Backend Server to rule out the possibility of issues caused by the Status Backend Server
Opened the Status App and did not perform any operations, letting the interface stay on the first initial screen
Switched the Status App to the background
After waiting for about 18 minutes, the issue excessive cpu reappeared

Apr 14 '25 14:04 qfrank

Another case I tried was installing the PR build on my physical device Redmi 14R 5G, then creating a brand new Status Profile, logging in, and switching to the background. After waiting for a while, the Status App would be killed, and the logcat logs retrieved are:

04-11 21:16:19.375  2385  3182 I ActivityManager: Killing 24166:im.status.ethereum.pr/u0a277 (adj 901): camera boost
04-11 21:16:20.038  2385  2714 W UsageStatsService: Unexpected activity event reported! (im.status.ethereum.pr/im.status.ethereum.MainActivity event : 23 instanceId : 30337734)

The battery option is set to the default, most lenient limit option.

Apr 15 '25 01:04 qfrank

Based on my previous investigation, the ultimate solution I can think of is that after the Status App is killed in the background, when the user switches back to the application, it can automatically and smoothly restore to the state before the user switched to the background. Regarding reducing memory and CPU usage, it is difficult to have significant experience improvements under the stringent limitations of mobile operating systems. I doubt pausing non-essential background operations when app goes to background will make big difference @ilmotta cc @osmaczko @jrainville

Apr 15 '25 01:04 qfrank

Interesting story @Parveshdhull shared in the meeting before and I'd like to share it here :

I also tried that on Firefox and Firefox also started to behave similarly. It also means like I was using in concrete to tab. So after two, three minutes it also got killed. Maybe all other apps also behaving similarly in Jared's mobile. He's just noticing because other apps keeps state and our apps needs to re login or something. Probably that might be issue because it's like Firefox only lose its states in Chrome Connectome board. But if I use normally it just restores after opening app. So maybe his device is killing all other apps similarly aggressive to all apps.

^ the transcript comes from Fireflies

Apr 15 '25 02:04 qfrank

Thank you @qfrank for linking the transcript. (typo - concrete tab = private tab)

Context: I was referring to my small experiment with battery restrictions setting in my Samsung S21 FE and its effect on the apps.

Setup: https://github.com/user-attachments/assets/15fcd075-02ae-4fe1-9400-f1aa36be25de (Relevant part only till 1.30)

Result: https://github.com/user-attachments/assets/07c59db1-6af3-4d7d-933d-3ea08eea5b80

Apr 15 '25 04:04 Parveshdhull

App frequently killed by Android while in background

Problem

Summary

Environment

How does the problem affect the UX?

Steps to reproduce

Expected behavior

Actual behavior

Analysis and root cause investigation

Recommendations

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