Android模拟器代理设置

Question

I am trying to set up a network proxy to view emulator traffic.

Now if I make a change in network settings of emulator ( 10.0.2.2:< port >, things work fine. But if I try to set the proxy through command line using emulator -avd myAvd -http-proxy localhost:< port > , SSL traffic does not go through and I get time out errors.

Anyone has been able to get this working ?

Thanks

Answer 1

Not sure which emulator you are using, but there is an issue with new Android emulator announced with Android Studio 2 - Bug Tracker

To get a workaround, I had to do the following using the new emulator set to API 23:

1. Pass -http-proxy http://192.168.xx:yyyy as a flag when you are launching the emulator. For details how to do this, see here.
2. Configure the Access Point settings for the proxy within the emulator. To do this, you go to settings -> more -> cellular network -> access point names and edit the existing Access Point.
3. Finally, there is a setting in Developer Settings for configuring the device to use the legacy DHCP client instead of the new one. This must be configured to use the legacy one.
4. Toggle Airplane mode on and off.

Answer 2

Check out comment #6 on https://code.google.com/p/android/issues/detail?id=201402#c6 . If you use your computers LAN IP setting the proxy works using the -http-proxy command line switch and no other workarounds are necessary.

For example:

$ emulator -avd Nexus_5X_API_23 -http-proxy http://10.102.80.149:8888

Answer 3

I've recently had to set up a sniffing environment to debug some Android SSL traffic.

It seems now that you no longer need to set the proxy on the emulator's access point (steps 2-4 on @craig-russell's answer). Adding the -http-proxy launch parameter is enough. Also tried on API levels < 23 and succeeded.

My specs: Android Studio 2.3.1 Windows 10 Android emulator version 25.2.5.0

Full details: http://www.devsbedevin.net/debugging-android-ssl-traffic/

Answer 4

There's a chance that your proxy server returns some additional HTTP headers in its response to Android emulator's HTTP CONNECT request. If so, you may encountered a known issue which should've been fixed by now, but due to desync between development branches, the fix has never been released. Please see my comment for the details.

To clarify, HTTP requests are unaffected by the issue because they don't rely on connection tunneling (ie HTTP CONNECT), being delivered via HTTP Message Forwarding defined in RFC7230 instead.