Shielding the bizarre problems caused by telecom rogue ads--android WebView can't load pages in a long time

Hair now in the home with the Android app WebView Open the site is very slow, there will be more than 10 seconds or longer to get stuck.

But it's very fast to open the same page on the computer.

The process of finding this problem is more tortuous and documented.

Crawl Android Network data

To debug this problem, first crawl the Android network packet data. Start, is to use Wireshark to grab the bag, but very troublesome, tcpdump in the phone to root permissions.

So switching ideas, can you set up an agent on Android, to grab the package?

But Fiddler did not have a Linux version number, so he switched to Burpsuite.

To set the Android proxy method:

In the Android network settings, long press the connection, select "Change Network", "Show advanced Options", "Agent", "Manual", and then fill in the corresponding proxy address.

Hosts and router-configured pits

Crawl to the HTTP request data, find the interview very quickly, than on the phone more quickly. The description is not a network issue.

After careful observation, we found this request:

Get/gngo.js http/1.1
host:x.adpro.cn

Remember, this is the rogue ad that was once blocked by telecommunications on the Web page configured with the hosts:

127.0.0.1 adpro.cn
127.0.0.1 x.adpro.cn

So after staring at the two hosts on the computer, it turns out to be a little slower, but not as much as it does on a cellphone for more than 10 seconds.

Try again on the Computer browser open http://x.adpro.cn/gngo.js, found not open.

Ping x.adpro.cn

found that the returned result is 127.0.0.1

Why did the x.adpro.cn entries in the Hosts file stare out and the results returned are 127.0.0.1?

Toss for a while, try various methods to clear the Linux DNS, found that the resolution of the x.adpro.cn is 127.0.0.1.

Again, once configured on the router firewall, sure enough for example, the following are configured to intercept the adpro.cn:

After this rule is invalidated in the router, ping x.adpro.cn can return the correct IP.

It turns out that the router has also intercepted DNS-related requests, resulting in Linux not taking the new DNS resolution results, always using the old results, so always the x.adpro.cn parsing to 127.0.0.1.

After figuring out why, once again, the adpro.cn packet is intercepted in the router, and then the page is loaded again, and the http://x.adpro.cn/gngo.js request expires after more than 10 seconds:

That's why it takes more than 10 seconds to open a webpage on a phone:

The router intercepts the adpro.cn packet, so the socket has no data to return, so the HTTP request expires after more than 10 seconds, and Android WebView renders the page.

Why is the computer very fast? Due to the configuration of the 127.0.0.1 x.adpro.cn, the HTTP request returned directly and failed, not blocked.

Operator ads that are impacting the experience

On the router to remove the interception, and then visit the mobile phone, there is a pit Dad thing:

The Webwiew will show the rogue ads plugged into the telecom, blocking most of the area.

How to filter out the operator's rogue ads? Blacklist or white list?

If just filter out, users will be the site of their own play ads. So how do you filter out these rogue ads in the app?

Filter some URLs in WebView:

When the URL contains an ad address, an empty response is returned directly.

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 ability to overload the above function on API level 11 is sufficient.

Operators of advertising domain names are relatively fixed, can be used to exclude the blacklist.

Of course, assuming that their services are under their own domain name, then you can consider the use of white list mechanism.

The white list mechanism, another additional advantage, can be considered an effective way to prevent XSS.

Some of the other stuff:

Some articles on the Android grab pack:

Http://www.trinea.cn/android/android-network-sniffer/Android using fiddler for network data capture

Http://www.freebuf.com/articles/wireless/6517.html Real-time capture of communication packets on mobile devices (Advsock2pipe+wireshark+nc+tcpdump)

Blocking the bizarre problems caused by telecom rogue ads--android WebView cannot load page