Blocking the strange problem caused by fake Telecom advertisements-Android WebView cannot load pages for a long time

It was found that it was slow to open the website using WebView In the Android App at home, and there would be a dozen or more seconds of cards.

However, opening the same web page on a computer is fast.

The process of searching for this problem is tortuous and recorded.

Capture Android Network Data

To debug this problem, we must first capture the Android Network package data. At the beginning, we wanted to use Wireshark to capture packets, but it was very troublesome. tcpdump needed the root permission on the mobile machine.

As a result, can I set a proxy on Android to capture packets?

But fiddler does not have a linux version, so it switched to BurpSuite.

Set the Android agent method:

In the Android network settings, press and hold the connection, select "modify Network", "Show advanced options", "proxy", and "Manual", and fill in the corresponding proxy address.

Hosts and vro configuration pitfalls

Capture the http request data and find that the access is faster than on the mobile phone. It is not a network problem.

After careful observation, we found the request:

GET/gngo. js HTTP/1.1
Host: x.adpro.cn

In retrospect, this was previously configured with hosts when we blocked fake advertisements inserted by China Telecom on webpages:

127.0.0.1 adpro.cn
127.0.0.1 x.adpro.cn

So I commented out the two hosts on the computer and found that the speed was a little slower, but it was not as slow as a dozen seconds on the phone.

Then try to open http://x.adpro.cn/gngo.js in the browser on the computer and find that it cannot be opened.

Ping x.adpro.cn

The returned result is 127.0.0.1.

Why did I comment out the x.adpro.cn entry in the hosts file and return 127.0.0.1?

After a while, I tried various methods to clear linux dns and found that the resolution result of x.adpro.cn is still 127.0.0.1.

I think of it again. I used to configure a firewall on the vro and configured the interception of adpro.cn as follows:

After the rule is invalidated in the vro, ping x.adpro.cn to return the correct IP address.

It turns out that the vro intercepts dns-related requests. As a result, linux cannot obtain the new dns resolution results and uses old results all the time. Therefore, it always resolves x.adpro.cn to 127.0.0.1.

After figuring out the reason, I intercepted the adpro.cn data packets in the vro and re-loaded the webpage. Then I found that the requests for http://x.adpro.cn/gngo.jswould be more than 10 seconds later:

This is why it takes more than a dozen seconds to open a webpage on a mobile phone:

The Router intercepts the data packets of adpro.cn, so that no data is returned from the socket. Therefore, the http request times out after more than a dozen seconds and Android WebView is rendered to display the page.

Why is the computer fast? Because 127.0.0.1 x.adpro.cn is configured, an error occurred while returning the http request without blocking.

Operator advertisements that affect user experience

The interception is removed from the vro, and then accessed on the mobile phone. Then there is another trap:

The WebWiew will display a rogue advertisement inserted by China Telecom, blocking most areas.

How do I filter out the operator's rogue advertisements? Blacklist or whitelist

If it is not filtered out, the user will still post ads on the website itself. So how can we filter out these rogue advertisements in the App?

Filter some URLs in WebView:

When the url contains an advertisement address, an empty response is directly returned.

Http://developer.android.com/reference/android/webkit/WebViewClient.html#shouldInterceptRequest (android. webkit. WebView, java. lang. String) http://developer.android.com/reference/android/webkit/WebViewClient.html#shouldInterceptRequest (android. webkit. WebView, java. lang. String)

webView.setWebViewClient(new WebViewClient() {public WebResourceResponse shouldInterceptRequest(WebView view, String url) {if (url.contains("adpro.cn")) {return new WebResourceResponse(null, null, null);}return null;}

Note that the above functions can be reloaded only on api level 11.

The carrier's advertising domain names are relatively fixed and can be excluded from the blacklist.

Of course, if your services are under your own domain name, you can consider using the whitelist mechanism.

The White List mechanism also has an additional benefit, which can be regarded as an effective method to prevent XSS.

Other things:

Some articles about packet capture on Android:

Http://www.trinea.cn/android/android-network-sniffer/ Android uses Fiddler for network data packet capture

Http://www.freebuf.com/articles/wireless/6517.html captures communication packets on mobile devices in real time (ADVsock2pipe + Wireshark + nc + tcpdump)