AdguardTeam / AdguardForAndroid

Open bug tracker for Android version of AdGuard.
https://adguard.com/
1.22k stars 86 forks source link

"Not routed through AdGuard" and RAM questions #5360

Closed nagae-memooff closed 5 days ago

nagae-memooff commented 2 weeks ago

Please answer the following questions for yourself before submitting a question.

Ask a question

I am using AdGuard for Android, and it works well most of the time. However, I have some technical questions that I hope can be answered. I am not a native English speaker, so please forgive my clumsy English.

  1. I want to understand the technical details of setting an app to "Not routed through AdGuard." 1.1 When this app accesses the network, does it appear to be a completely direct connection? If not, how does it differ from a true direct connection? 1.2 Can this app detect that it is behind a VPN service? 1.3 Will the app's network requests use the system-level DNS settings of Android or the DNS specified in AdGuard settings?

    The background for these questions is: I use an IM app called QQ, which is very popular in China. I have disabled battery optimization and all "restrictions" in the system for this app and adguard app. This app does not use FCM for push notifications but runs a background service to establish a long connection with the QQ server. When AdGuard is not used, it can receive messages and notify me promptly. However, if I enable AdGuard (I use the VPN service mode without root), regardless of whether I use AdGuard's built-in rules, custom rules from the internet, or even set QQ to not be routed through AdGuard, there is still a high probability that QQ will stop receiving "push" messages the next morning after running overnight. I have two phones, and I have verified this by sending messages to myself every morning. But if I completely disable AdGuard, this problem does not occur. Additionally, I have some software development skills, and when I do not receive messages, I confirmed through adb commands that QQ's service and processes is still running and has not been killed by the system. As long as I manually open the app, it will "pull" and retrieve the missed messages. After that, the push notifications work normally. But if it goes through another night, there is a high probability that the same problem will occur again. In fact, this issue does not only occur "after a night"; it can happen occasionally during the day as well. However, I do not have evidence to link this situation with AdGuard, so we will only discuss the "after a night" scenario as it has a high reproduction rate in my environment. I believe that the issue of not receiving messages might have some implicit correlation with AdGuard, so I hope to understand the principles as much as possible to accurately troubleshoot this problem. I am just a QQ user, not developer, and for some reasons, I cannot seek support from the QQ app.

  2. Is there any way to optimize AdGuard's memory usage? If I do not open AdGuard's Views and only use it quietly in the background, I find that on my Android 14 device with 6GB RAM, AdGuard eats more memory than on another Android 12 device with 8GB RAM with the same rule list. The former occupies about 270MB at startup and gradually increases to 300-500MB; the latter occupies about 170MB at startup and gradually increases to 200-400MB. If I open the view, it will occupy more RAM. I am currently using Tasker to create a task that triggers and kills AdGuard, then sends an intent to restart AdGuard when needed. This saves some memory compared to directly clicking AdGuard's icon and starting the service. But I want to know if there is a better way.

Thank you for any thoughts.

ESurina commented 6 days ago
  1. For a totally direct connection, you need to add the application to Excluded apps: then it will be excluded from the VPN tunnel, and traffic will go past the AdGuard. (Settings -> General -> Advanced -> Low-level settings -> Excluded apps) The switches in App management work like this:
    • The application traffic gets into the VPN tunnel;
    • Traffic from the VPN tunnel gets to the corlibs;
    • Corlibs, after processing a “raw” request, ask what to do with the application traffic;
    • Based on the enabled switches, we tell the corlibs what to do: connect directly / block ads /open the https tunnel

At the same time, we are not talking about DNS traffic: the UDP request belonging to some application cannot be technically recognized due to the nature of UDP, so it either goes into the VPN tunnel (by default) or does not go (if it is excluded in the low-level settings).

  1. It is unlikely that this behavior can be improved by third-party means.