Shielding the bizarre problems caused by telecom rogue ads--android WebView long time unable to load page

found that using the Android app's WebView to open the site at home is slow and will be stuck for more than 10 seconds or longer.

But it's very quick 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 want 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 and switched to Burpsuite.

To set the Android proxy method:

In the Android network settings, long press the connection, select "Modify 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 access quickly, than on the phone much faster. The description is not a network problem.

After a closer look, the request was found:

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

In retrospect, this was the last time the rogue ad that was blocked by telecommunications was inserted on the Web page, the hosts were configured:

127.0.0.1 adpro.cn
127.0.0.1 x.adpro.cn

So on the computer after the two hosts commented out, found that the speed slowed a bit, but not like the phone on the card 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 is the x.adpro.cn entry commented out in the Hosts file, and the result returned is 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, the previous configuration of the firewall on the router, sure enough, as follows has configured the interception of 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 the reason, intercept the adpro.cn packet in the router again, then reload the page, and find that the Http://x.adpro.cn/gngo.js request expires in 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 the Android WebView renders the page.

Why is the computer fast? Because 127.0.0.1 x.adpro.cn is configured, the HTTP request is returned directly and fails, and does not block.

Operator ads that affect the experience very much

On the router to remove the interception, and then access on the 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 you do not filter out, users will later be the website to play their own 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 above functions can be overloaded at API level 11.

Operators of advertising domain names are relatively fixed, you can use the blacklist to exclude.

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

The white list mechanism also has an additional benefit that can be considered as 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)