element-hq / element-hq/element-android
Battery drain caused by Element not being able to detect loss of connectivity due to using VPN
- Dominant language
- Kotlin
- Stars
- 3.7k
- Forks
- 917
- Avg merge
- 8d 20h
- Merged PRs (30d)
- 1
Description
### Steps to reproduce
Hi,
I’ve enabled background sync and I’m using a VPN for internet access. It seems that when the VPN blocks Element’s internet connection, the app still continues to perform sync attempts in the background.
Although I noticed that you’ve already implemented some backoff mechanisms for retries, the app still performs multiple continuous retries, which can lead to unnecessary battery drain.
Would it be possible to implement a customized, app-specific server reachability check before attempting synchronization? This could help prevent redundant sync attempts when the app is not actually able to reach the server through the VPN.
Some approaches can be found here:
[StackOverflow: Checking server reachability](https://stackoverflow.com/a/4009133/18154447)
[How DAVx⁵ handles server reachability with VPN](https://github.com/bitfireAT/davx5-ose/commit/318939e970297e9d491b82cbe5238adea82fd969)
Thank you!
### Outcome
#### What did you expect?
Lower battery drain when misconfigure the firewall or VPN, also server end issue could also cause this type of continuous retry.
#### What happened instead?
### Your phone model
Pixel 6
### Operating system version
Android 15
### Application version and app store
Element 1.6.34 from F-droid
### Homeserver
matrix.org
### Will you send logs?
No
### Are you willing to provide a PR?
No
Contributor guide
Research direction
Start by tracing Element’s background synchronization path, including its retry backoff and any existing server-reachability checks. Reproduce the case with background sync enabled while a VPN or firewall blocks the server, then confirm that unreachable servers no longer cause continuous sync attempts and excess battery drain.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kotlin
- Domain
- mobile-dev, networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100