Proxy functionality stops working soonly after the application is not in foreground on Pixel 8 Pro(Android 14)

[brlin-tw]

Hello, I am having fun using the TetherFi application, however, whenever I switch the application to background the proxy service times out soon afterward (the Wi-Fi connection is still available, but the outgoing connections will timeout after half a minute or so until I switched the application back to foreground again).

I'm reproducing this issue on the Pixel 8 Pro(Android 14, build id: UD1A.231105.004), which shouldn't have much problem regarding keeping the background app alive, most(if not all) configuration seems to be properly set as well:

• Battery optimization disabled
• Added the TetherFi application in the battery-saver Pixel feature's whitelist(which is not enabled anyway)
• Wakelocks and other in-app stay-alive tweaking settings are all set
• TetherFi notification is enabled

Another side question would be whether integrating Shizuku(allows the application to use non-root ADB permissions) would help to keep the service alive in the background. I just recently learned this solution, which seems very helpful in some cases.

[pyamsoft]

It sounds like something is still revoking the Wake lock or WiFi lock, the Broadcast part of the service is alive but it sounds like the Proxy part isn't actually operating reliably.

I'm not familiar enough with Shizuku to know if it would work. I'm thinking this may be the newer Android 14 feature of killing background threads (which is used for the proxy server, a rotating pool of threads per connection to the Internet for the most performance).

I'm sorry to say I'm not sure why this would be happening. Maybe I will need to perform some kind of "automatic restart" of the proxy server every 10 minutes or so to avoid these timeout issues from happening.

[brlin-tw]

Thanks for the prompt response, I would like to ask whether there's something I can do to help resolve this problem(I am quite acquainted with collecting logs in Android, but not in other fields of Android software development).

I think that the restart feature may be helpful, as a workaround to the problem.

In the meantime, I'll upgrade my system to the latest release and see whether the problem is still reproducible.

[pyamsoft]

If you could provide me a bit more information as I think over this

How long does it take before things get slow? Let's say you have just turned on the TetherFi hotspot. You background TetherFi and go do something else on the device. Does it get slow instantly? Or does it take 10 minutes? 30 minutes?

After you notice it is slow, you switch back to TetherFi to speed things up. How quickly does this take effect, is the speed up instant?

When the network is slow, is your screen off?

[brlin-tw]

How long does it take before things get slow?

Not sure about that as I usually notice the problem when the YouTube video pauses after the buffer runs out(about a minute or so). I'll try to do an HTTP ping test to have a better picture of this one.

How quickly does this take effect, is the speed up instant?

In less than 15 seconds, I'll try to get a more accurate duration.

When the network is slow, is your screen off?

Nope, just switching the app to the background is enough to trigger the problem.

[pyamsoft]

Thats odd if this is all happening while the device is still active and the screen is still on. I believe that suggests its not a wakelock issue, since the device is not "asleep". I'll see if I can reproduce on my device (Samsung Flip 3).

[pyamsoft]

Unfortunately, it sounds like the only solution at the moment is to manually go into the app to "refresh" whatever is causing it to slow down in the background. Very lame I know :(

[pyamsoft]

Do you have the TetherFi Quick Tile in your notification sheet?

Sorry for so many questions :stuck_out_tongue:

[brlin-tw]

Do you have the TetherFi Quick Tile in your notification sheet?

I do have that tile in the edit mode, but I didn't enable it (yet).

[pyamsoft]

Ok thanks!

[brlin-tw]

How long does it take before things get slow?

About 6 seconds in my httping test

How quickly does this take effect, is the speed up instant?

Less than two seconds, pretty much when I switched the app. back to the foreground the httping resumes:

$ httping -E -g https://google.com # app. is switched to the background
Auto enabling SSL due to https-URL
PING google.com:443 (/):
connected to google.com:443 (616 bytes), seq=0 time=249.56 ms 
connected to google.com:443 (616 bytes), seq=1 time=328.80 ms 
connected to google.com:443 (616 bytes), seq=2 time=244.83 ms 
connected to google.com:443 (616 bytes), seq=3 time=307.85 ms 
connected to google.com:443 (616 bytes), seq=4 time=310.96 ms 
connected to google.com:443 (616 bytes), seq=5 time=1609.90 ms 
connected to google.com:443 (616 bytes), seq=6 time=251.03 ms <-- The HTTP response stops
connected to google.com:443 (616 bytes), seq=7 time=5960.04 ms <-- Switched the app. to foreground after found out the response stops
connected to google.com:443 (616 bytes), seq=8 time=1640.77 ms 
connected to google.com:443 (616 bytes), seq=9 time=267.05 ms 
connected to google.com:443 (616 bytes), seq=10 time=350.22 ms 
connected to google.com:443 (616 bytes), seq=11 time=270.57 ms 

[pyamsoft]

Very odd

If you enable the Tile and add it to the notification shade (you don't have to use it, it just needs to be present), does the hotspot "stay alive" longer?

[brlin-tw]

If you enable the Tile and add it to the notification shade (you don't have to use it, it just needs to be present), does the hotspot "stay alive" longer?

Only for about 2 seconds, I'm pretty sure it's just in the margin of error:

$ httping -E -g https://google.com <-- Switched the app. to background
Auto enabling SSL due to https-URL
PING google.com:443 (/):
connected to google.com:443 (616 bytes), seq=0 time=234.40 ms 
connected to google.com:443 (616 bytes), seq=1 time=295.50 ms 
connected to google.com:443 (616 bytes), seq=2 time=232.89 ms 
connected to google.com:443 (616 bytes), seq=3 time=241.20 ms 
connected to google.com:443 (616 bytes), seq=4 time=228.53 ms 
connected to google.com:443 (616 bytes), seq=5 time=380.78 ms 
connected to google.com:443 (616 bytes), seq=6 time=204.03 ms 
connected to google.com:443 (616 bytes), seq=7 time=250.10 ms 
connected to google.com:443 (616 bytes), seq=8 time=251.75 ms <-- Response stops here
connected to google.com:443 (616 bytes), seq=9 time=13682.31 ms <-- Switched to foreground again
connected to google.com:443 (616 bytes), seq=10 time=282.28 ms 
^CGot signal 2
short read during receiving reply-headers from host
--- https://google.com/ ping statistics ---
12 connects, 11 ok, 8.33% failed, time 27705ms
round-trip min/avg/max = 204.0/1480.3/13682.3 ms

[pyamsoft]

Ah ok I think I've managed to reproduce your bug. Unfortunately the behavior of it is all a little strange as this is not a very documented thing exactly.

Long text - be warned.

Android 14 puts things into the background much more aggressively now as Google loves to restrict how tool apps like this one work.

When in the background, they super limit what we are able to do down to effectively nothing. However, according to documentation, adding a TileService (the quick tile) keeps the app in a "close enough to foreground" state that they allow it to have somewhat normal performance.

Our TileService is currently using a flag which makes the system only activate it for a few seconds at a time. The latest commit removes this flag, so hopefully this can lead to more performance.

---

Two things need to happen for this change to hopefully take effect

1. You must add the Tile to the quick settings (it can be in the expanded pull down, but it must be enabled not just in edit mode)
2. I have to release a new build with this 1-line change to see if things improve

notes

[brlin-tw]

I've implemented a small utility to test the problem more consistently:

TetherFi debugging utilities$ ./measure-time-between-switching-tetherfi-to-background-and-the-proxy-service-stops-working.sh 
Info: Please press the Enter key of the computer after switching the TetherFi application to foreground:
Info: Checking whether the proxy service is working in the first place...
Info: Okay, proxy seems to be working at the moment.  Please press the Enter key of the computer and switch the TetherFi application to the background AT THE SAME TIME:
Info: Recording the test start time...
Info: Detecting timeout incident..............curl: (28) Operation timed out after 3000 milliseconds with 0 bytes received
Warning: TetherFi proxy service timeout detected!
Info: Timeout duration determined to be "10" seconds.
Info: Please press the ENTER key and switch the TetherFi application back to the foreground AT THE SAME TIME:
Info: Recording the proxy functionality resume test start time...
Info: Detecting proxy service resume incident...
Info: Proxy service resume detected.
Info: Proxy service resume duration determined to be "1" seconds.
Info: Operation completed without errors.

The service seems to resume almost instantly after switching the application back to the foreground.

Another thing I noticed is that there seem to be some edge cases where the background service won't be stopped instantly, like when the home screen is returned instead of other user-installed apps:

TetherFi debugging utilities$ ./measure-time-between-switching-tetherfi-to-background-and-the-proxy-service-stops-working.sh 
Info: Please press the Enter key of the computer after switching the TetherFi application to foreground:
Info: Checking whether the proxy service is working in the first place...
Info: Okay, proxy seems to be working at the moment.  Please press the Enter key of the computer and switch the TetherFi application to the background AT THE SAME TIME:
Info: Recording the test start time...
Info: Detecting timeout incident........................................................................................................................................................curl: (28) Operation timed out after 3001 milliseconds with 0 bytes received
Warning: TetherFi proxy service timeout detected!
Info: Timeout duration determined to be "111" seconds. <-- Soonly after switching to the GitHub app, after heavily browse the launcher app for quite a long time.
Info: Please press the ENTER key and switch the TetherFi application back to the foreground AT THE SAME TIME:
Info: Recording the proxy functionality resume test start time...
Info: Detecting proxy service resume incident...
Info: Proxy service resume detected.
Info: Proxy service resume duration determined to be "0" seconds.
Info: Operation completed without errors.

I'll check whether there's any clues in the logs.

[brlin-tw]

In the meantime, I'll upgrade my system to the latest release and see whether the problem is still reproducible.

Yep, still reproducible(UQ1A.231205.015).

[pyamsoft]

As an update

I've applied to the Google Play Store to make TetherFi use a Foreground Service: Connected Devices. This should allow the Wi-Fi Direct Hotspot network to run all the time, even when the app is in the background or the screen is off. I hope this will be able to solve the performance issues you are experiencing, as long as Google approves it ( if Google does not approve it, then I don't know what else to do).

Alternatively, you can grab the APK from Izzy or the Github releases section if you don't use Google Play.

[brlin-tw]

I've sideloaded the 38 release from GitHub releases and it appears to be working. I did reproduce a timeout on the first try but after that, all seems to be good. I do hope that Google Play approves the new usage though, as I'm not fond of downloading and installing APKs manually.

You may also want to check out ThePBone/awesome-shizuku: Curated list of awesome Android apps making use of Shizuku for non-root applications that utilize Shizuku to achieve functionalities that normally isn't possible for non-rooted devices.

[pyamsoft]

Good to hear thanks, yes Google is going through the review process. I hope they will approve as well, and if they do you will be able to update from the store like usual. Thanks!

[pyamsoft]

Hello,

38 has been released to the Store and should be available in the next few hours. You can uninstall the sideloaded APK and get back on to Google Play for this and future updates.

To check the current version of the app at any time, you can look at the Show Upgrade Information dialog in settings which will include a small number at the bottom showing the build version 38

[pyamsoft]

Closing this one as original issue seems fixed with 38. Will open a new issue if I decide a Shizuku integration could be useful but still evaluating. Thanks for your report and valuable research!