Skip to content

fix(mobile): un-hide WiFi-only message sync setting#21110

Open
xAlisher wants to merge 1 commit into
masterfrom
fix/enable-wifi-only-sync-setting
Open

fix(mobile): un-hide WiFi-only message sync setting#21110
xAlisher wants to merge 1 commit into
masterfrom
fix/enable-wifi-only-sync-setting

Conversation

@xAlisher
Copy link
Copy Markdown
Contributor

@xAlisher xAlisher commented Jun 2, 2026

Problem

The "Message syncing" setting in Profile > Messaging (allows users to restrict sync to Wi-Fi only) has been hidden behind visible: false since v2.38. The backend implementation (getSyncingOnMobileNetwork) is complete and works correctly.

Battery research (#21045) shows that on cellular (LTE), the Waku keepalive traffic makes Status the dominant battery consumer at ~144 mAh/hr (~3.2%/hr on a 4500 mAh battery) for a typical loaded account. Users who enable Wi-Fi-only syncing avoid this entirely — dropping from ~144 mAh/hr to ~1.6 mAh/hr (59.7× reduction, measured T4 vs T3 soaks).

Change

Remove visible: false from allowSyncingOnMobileNetwork in MessagingView.qml.

One line deletion. The setting, its toggle popup, and the backend save/load are all already implemented and tested.

Test plan

  • Open Profile > Messaging — "Message syncing" row is visible showing current state ("Mobile data and Wi-Fi" or "Wi-Fi only")
  • Tap row — popup appears with both options
  • Select "Wi-Fi only" — setting saves, row label updates
  • Background app on cellular — confirm no mobile data used by Status (via Settings > Network)
  • Select "Mobile data and Wi-Fi" — normal sync resumes

Related

🤖 Generated with Claude Code

The `allowSyncingOnMobileNetwork` list item in Profile > Messaging was
hidden with `visible: false` pending validation. The backend toggle
(getSyncingOnMobileNetwork) is fully implemented and working. Removing
the visibility guard exposes the setting so users can opt into Wi-Fi-only
syncing and avoid LTE radio drain from Waku keepalives.

Closes #21045

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@jrainville
Copy link
Copy Markdown
Member

I think we were waiting for new designs, because the current UX was not great

@status-im-auto
Copy link
Copy Markdown
Member

status-im-auto commented Jun 2, 2026

Jenkins Builds

Commit #️⃣ Finished (UTC) Duration Platform Result
✔️ 699ac24 1 2026-06-02 15:51:07 ~9 min tests/nim 📄log
✔️ 699ac24 1 2026-06-02 15:53:16 ~11 min android/arm64 🤖apk 📲
✔️ 699ac24 1 2026-06-02 15:55:18 ~13 min tests/ui 📄log
✔️ 699ac24 1 2026-06-02 15:57:35 ~15 min ios/aarch64 📱ipa 📲
✔️ 699ac24 1 2026-06-02 15:59:24 ~17 min linux/x86_64 📦tgz
✔️ 699ac24 1 2026-06-02 15:59:52 ~17 min macos/aarch64 🍎dmg
✔️ 699ac24 1 2026-06-02 16:22:23 ~40 min windows/x86_64 💿exe
✔️ 699ac24 11556 2026-06-02 16:26:37 ~27 min tests/e2e 📊rpt
✔️ 699ac24 3491 2026-06-02 17:04:39 ~42 min tests/e2e-windows 📊rpt

@caybro
Copy link
Copy Markdown
Member

caybro commented Jun 2, 2026

I also think the corresponding backend has been nerfed, right @noeliaSD ? SO the switch wouldn't really do anything

@glitchminer
Copy link
Copy Markdown
Contributor

The backend implementation (getSyncingOnMobileNetwork) is complete and works correctly.

@caybro is right, it did not work as expected and was rolled back, at least temporarily, here: #20469

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Mobile] Android flagged Status for high battery consumption and CPU usage

5 participants