Android emulator local network

Emulator Networking

The emulator provides versatile networking capabilities that you can use to set up complex modeling and testing environments for your application. The sections below introduce the emulator’s network architecture and capabilities.

Network Address Space

Each instance of the emulator runs behind a virtual router/firewall service that isolates it from your development machine’s network interfaces and settings and from the internet. An emulated device can not see your development machine or other emulator instances on the network. Instead, it sees only that it is connected through Ethernet to a router/firewall.

The virtual router for each instance manages the 10.0.2/24 network address space — all addresses managed by the router are in the form of 10.0.2. , where is a number. Addresses within this space are pre-allocated by the emulator/router as follows:

Special alias to your host loopback interface (i.e., 127.0.0.1 on your development machine)

First DNS server

10.0.2.4 / 10.0.2.5 / 10.0.2.6

Optional second, third and fourth DNS server (if any)

The emulated device’s own network/ethernet interface

The emulated device’s own loopback interface

Note that the same address assignments are used by all running emulator instances. That means that if you have two instances running concurrently on your machine, each will have its own router and, behind that, each will have an IP address of 10.0.2.15. The instances are isolated by a router and can not see each other on the same network. For information about how to let emulator instances communicate over TCP/UDP, see Connecting Emulator Instances.

Also note that the address 127.0.0.1 on your development machine corresponds to the emulator’s own loopback interface. If you want to access services running on your development machine’s loopback interface (a.k.a. 127.0.0.1

on your machine), you should use the special address 10.0.2.2 instead.

Finally, note that each emulated device’s pre-allocated addresses are specific to the Android emulator and will probably be very different on real devices (which are also very likely to be NAT-ed, i.e., behind a router/firewall)

Local Networking Limitations

Each emulator instance runs behind a virtual router, but unlike an actual device connected to a physical router, the emulated device doesn’t have access to a physical network. Instead it runs as part of a normal application on your development machine. This means that it is subject to the same networking limitations as other applications on your machine:

• Communication with the emulated device may be blocked by a firewall program running on your machine.

• Communication with the emulated device may be blocked by another (physical) firewall/router to which your machine is connected.

The emulator’s virtual router should be able to handle all outbound TCP and UDP connections/messages on behalf of the emulated device, provided your development machine’s network environment allows it to do so. There are no built-in limitations on port numbers or ranges except the one imposed by your host operating system and network.

Depending on the environment, the emulator may not be able to support other protocols (such as ICMP, used for «ping») might not be supported. Currently, the emulator does not support IGMP or multicast.

Using Network Redirections

To communicate with an emulator instance behind its virtual router, you need to set up network redirections on the virtual router. Clients can then connect to a specified guest port on the router, while the router directs traffic to/from that port to the emulated device’s host port.

To set up the network redirections, you create a mapping of host and guest ports/addresses on the the emulator instance. There are two ways to set up network redirections: using emulator console commands and using the ADB tool, as described below.

Setting up Redirections through the Emulator Console

Each emulator instance provides a control console the you can connect to, to issue commands that are specific to that instance. You can use the redir console command to set up redirections as needed for an emulator instance.

First, determine the console port number for the target emulator instance. For example, the console port number for the first emulator instance launched is 5554. Next, connect to the console of the target emulator instance, specifying its console port number, as follows:

telnet localhost 5554

Once connected, use the redir command to work with redirections. To add a redirection, use:.

is either tcp or udp, and and sets the mapping between your own machine and the emulated system, respectively.

For example, the following command sets up a redirection that will handle all incoming TCP connections to your host (development) machine on 127.0.0.1:5000 and will pass them through to the emulated system’s 10.0.2.15:6000.:

redir add tcp:5000:6 000

To delete a redirection, you can use the redir del command. To list all redirections for a specific instance, you can use redir list. For more information about these and other console commands, see Using the Emulator Console.

Note that port numbers are restricted by your local environment. this typically means that you cannot use host port numbers under 1024 without special administrator privileges. Also, you won’t be able to set up a redirection for a host port that is already in use by another process on your machine. In that case, redir generates an error message to that effect.

Setting Up Redirections through ADB

The Android Debug Bridge (ADB) tool provides port forwarding, an alternate way for you to set up network redirections. For more information, see Forwarding Ports in the ADB documentation.

Note that ADB does not currently offer any way to remove a redirection, except by killing the ADB server.

Configuring the Emulator’s DNS Settings

At startup, the emulator reads the list of DNS servers that your system is currently using. It then stores the IP addresses of up to four servers on this list and sets up aliases to them on the emulated addresses 10.0.2.3, 10.0.2.4, 10.0.2.5 and 10.0.2.6 as needed.

On Linux and OS X, the emulator obtains the DNS server addresses by parsing the file /etc/resolv.conf. On Windows, the emulator obtains the addresses by calling the GetNetworkParams() API. Note that this usually means that the emulator ignores the content of your «hosts» file (/etc/hosts on Linux/OS X, %WINDOWS%/system32/HOSTS on Windows).

When starting the emulator at the command line, you can also use the -dns-server option to manually specify the addresses of DNS servers to use, where is a comma-separated list of server names or IP addresses. You might find this option useful if you encounter DNS resolution problems in the emulated network (for example, an «Unknown Host error» message that appears when using the web browser).

Using the Emulator with a Proxy

If your emulator must access the Internet through a proxy server, you can use the -http-proxy

option when starting the emulator, to set up the appropriate redirection. In this case, you specify proxy information in

in one of these formats:

The -http-proxy option forces the emulator to use the specified HTTP/HTTPS proxy for all outgoing TCP connections. Redirection for UDP is not currently supported.

Alternatively, you can define the environment variable http_proxy to the value you want to use for

. In this case, you do not need to specify a value for

in the -http-proxy command — the emulator checks the value of the http_proxy environment variable at startup and uses its value automatically, if defined.

You can use the -verbose-proxy option to diagnose proxy connection problems.

To allow one emulator instance to communicate with another, you must set up the necessary network redirections as illustrated below.

Assume that your environment is

• A is you development machine

• B is your first emulator instance, running on A

• C is your second emulator instance, running on A too and you want to run a server on B, to which C will connect, here is how you could set it up:

1. Set up the server on B, listening to 10.0.2.15:

2. On B’s console, set up a redirection from A:localhost: to B:10.0.2.15:

3. On C, have the client connect to 10.0.2.2:

For example, if you wanted to run an HTTP server, you can select as 80 and as 8080:

• On B’s console, issue redir add tcp:8080:8 0

Sending a Voice Call or SMS to Another Emulator Instance

The emulator automatically forwards simulated voice calls and SMS messages from one instance to another. To send a voice call or SMS, you use the dialer application and SMS application (if available) installed on one emulator

To initiate a simulated voice call to another emulator instance:

1. Launch the dialer application on the originating emulator instance.

2. As the number to dial, enter the console port number of the instance you’d like to call. You can determine the console port number of the target instance by checking its window title, where the console port number is reported as «Android Emulator (

3. Press «Dial». A new inbound call appears in the target emulator instance.

To send an SMS message to another emulator instance, launch the SMS application (if available). Specify the console port number of the target emulator instance as as the SMS address, enter the message text, and send the message. The message is delivered to the target emulator instance.

You can also connect to an emulator instance’s console to simulate an incoming voice call or SMS. For more information, see Telephony Emulation and SMS Emulation.

Using the Emulator Console

Each running emulator instance includes a console facility that lets you dynamically query and control the simulated device environment. For example, you can use the console to dynamically manage port redirections and network characteristics and simulate telephony events. To access the console and enter commands, you use telnet to connect to the console’s port number.

To connect to the console of any running emulator instance at any time, use this command:

An emulator instance occupies a pair of adjacent ports: a console port and an adb port. The port numbers differ by 1, with the adb port having the higher port number. The console of the first emulator instance running on a given machine uses console port 5554 and adb port 5555. Subsequent instances use port numbers increasing by two — for example, 5556/5557, 5558/5559, and so on. Up to 16 concurrent emulator instances can run a console facility.

To connect to the emulator console, you must specify a valid console port. If multiple emulator instances are running, you need to determine the console port of the emulator instance you want to connect to. You can find the instance’s console port listed in the title of the instance window. For example, here’s the window title for an instance whose console port is 5554:

Android Emulator (5554)

Alternatively, you can use the adb devices command, which prints a list of running emulator instances and their console port numbers. For more information, see Querying for Emulator/Device Instances in the adb documentation.

| Note: The emulator listens for connections on ports 5554-5587 and accepts connections only from localhost.

Once you are connected to the console, you can then enter help [command] to see a list of console commands and learn about specific commands.

To exit the console session, use quit or exit.

The sections below describe the major functional areas of the console.

Port Redirection

You can use the console to add and remove port redirections while the emulator is running. After connecting to the console, you can manage port redirections in this way:

Источник

Deep Shah’s Blog

Coding is an art. Not everyone is an Artist!

Saturday, February 19, 2011

Android — Fixing the no internet connection issue on emulator

Recently, while developing an Android Application, I was faced with a situation that wasted 2 hours of my time. The issue was simple, my app was not able to access internet from the Android Emulator.

Initially I thought fixing the issue should have been straight forward, but life is not always that simple.

So what was the real issue because of which my app was not able to access internet? There are multiple reasons because of which this issue could occur. Hence, I decided to document my findings so that other could benefit from it.

There are two main symptoms of no internet connection on android emulator

• Only your app is not able to access the internet
• None of the apps are able to access the internet

A sample AndroidManifest.xml file with the added permission would look like

Compile and re-install the app in the emulator and try to access the internet from your app. It should work!

What is the use of uses-permission tag:


Android application can request certain permissions so that they can function properly. Some examples of permissions are, get users location, make a call, access the internet etc. App has to explicitly specify this in the AndroidManifest.xml.

When end users install such an app on their device, the android OS will notify the user that, app is requesting certain permissions. If users are fine with that, then only the app will be installed. Else users can deny the permission and the app will not be installed.

Источник

Connect to local web services from iOS simulators and Android emulators

Many mobile applications consume web services. During the development phase, it’s common to deploy a web service locally and consume it from a mobile application running in the iOS simulator or Android emulator. This avoids having to deploy the web service to a hosted endpoint, and enables a straightforward debugging experience because both the mobile application and web service are running locally.

Mobile applications running in the iOS simulator or Android emulator can consume ASP.NET Core web services that are running locally, and exposed over HTTP, as follows:

Applications running in the iOS simulator can connect to local HTTP web services via your machines IP address, or via the localhost hostname. For example, given a local HTTP web service that exposes a GET operation via the /api/todoitems/ relative URI, an application running in the iOS simulator can consume the operation by sending a GET request to http://localhost:

/api/todoitems/ .
Applications running in the Android emulator can connect to local HTTP web services via the 10.0.2.2 address, which is an alias to your host loopback interface ( 127.0.0.1 on your development machine). For example, given a local HTTP web service that exposes a GET operation via the /api/todoitems/ relative URI, an application running in the Android emulator can consume the operation by sending a GET request to http://10.0.2.2:

However, additional work is necessary for an application running in the iOS simulator or Android emulator to consume a local web service that is exposed over HTTPS. For this scenario, the process is as follows:

1. Create a self-signed development certificate on your machine. For more information, see Create a development certificate.
2. Configure your project to use the appropriate HttpClient network stack for your debug build. For more information, see Configure your project.
3. Specify the address of your local machine. For more information, see Specify the local machine address.
4. Bypass the local development certificate security check. For more information, see Bypass the certificate security check.

Each item will be discussed in turn.

Create a development certificate

Installing the .NET Core SDK installs the ASP.NET Core HTTPS development certificate to the local user certificate store. However, while the certificate has been installed, it’s not trusted. To trust the certificate, perform the following one-time step to run the dotnet dev-certs tool:

The following command provides help on the dev-certs tool:

Alternatively, when you run an ASP.NET Core 2.1 project (or above), that uses HTTPS, Visual Studio will detect if the development certificate is missing and will offer to install it and trust it.

The ASP.NET Core HTTPS development certificate is self-signed.

For more information about enabling local HTTPS on your machine, see Enable local HTTPS.

Configure your project

Xamarin applications running on iOS and Android can specify which networking stack is used by the HttpClient class, with the choices being a managed network stack, or native network stacks. The managed stack provides a high level of compatibility with existing .NET code, but is limited to TLS 1.0 and can be slower and result in a larger executable size. The native stacks can be faster and provide better security, but may not provide all the functionality of the HttpClient class.

Xamarin applications running on iOS can use the managed network stack, or the native CFNetwork or NSUrlSession network stacks. By default, new iOS platform projects use the NSUrlSession network stack, to support TLS 1.2, and use native APIs for better performance and smaller executable size. For more information, see HttpClient and SSL/TLS implementation selector for iOS/macOS.

Android

Xamarin applications running on Android can use the managed HttpClient network stack, or the native AndroidClientHandler network stack. By default, new Android platform projects use the AndroidClientHandler network stack, to support TLS 1.2, and use native APIs for better performance and smaller executable size. For more information about Android network stacks, see HttpClient Stack and SSL/TLS Implementation selector for Android.

Specify the local machine address

The iOS simulator and Android emulator both provide access to secure web services running on your local machine. However, the local machine address is different for each.

The iOS simulator uses the host machine network. Therefore, applications running in the simulator can connect to web services running on your local machine via the machines IP address or via the localhost hostname. For example, given a local secure web service that exposes a GET operation via the /api/todoitems/ relative URI, an application running on the iOS simulator can consume the operation by sending a GET request to https://localhost:

When running a mobile application in the iOS simulator from Windows, the application is displayed in the remoted iOS simulator for Windows. However, the application is running on the paired Mac. Therefore, there’s no localhost access to a web service running in Windows for an iOS application running on a Mac.

Android

Each instance of the Android emulator is isolated from your development machine network interfaces, and runs behind a virtual router. Therefore, an emulated device can’t see your development machine or other emulator instances on the network.

However, the virtual router for each emulator manages a special network space that includes pre-allocated addresses, with the 10.0.2.2 address being an alias to your host loopback interface (127.0.0.1 on your development machine). Therefore, given a local secure web service that exposes a GET operation via the /api/todoitems/ relative URI, an application running on the Android emulator can consume the operation by sending a GET request to https://10.0.2.2:

Detect the operating system

The DeviceInfo class can be used to detect the platform the application is running on. The appropriate hostname, that enables access to local secure web services, can then be set as follows:

For more information about the DeviceInfo class, see Xamarin.Essentials: Device Information.

Bypass the certificate security check

Attempting to invoke a local secure web service from an application running in the iOS simulator or Android emulator will result in a HttpRequestException being thrown, even when using the managed network stack on each platform. This is because the local HTTPS development certificate is self-signed, and self-signed certificates aren’t trusted by iOS or Android. Therefore, it’s necessary to ignore SSL errors when an application consumes a local secure web service. This can be accomplished when using both the managed and native network stacks on iOS and Android, by setting the ServerCertificateCustomValidationCallback property on a HttpClientHandler object to a callback that ignores the result of the certificate security check for the local HTTPS development certificate:

In this code example, the server certificate validation result is returned when the certificate that underwent validation is not the localhost certificate. For this certificate, the validation result is ignored and true is returned, indicating that the certificate is valid. The resulting HttpClientHandler object should be passed as an argument to the HttpClient constructor for debug builds:

Enable HTTP clear-text traffic

Optionally, you can configure your iOS and Android projects to allow clear-text HTTP traffic. If the backend service is configured to allow HTTP traffic you can specify HTTP in the base URLs and then configure your projects to allow clear-text traffic:

iOS ATS opt-out

To enable clear-text local traffic on iOS you should opt-out of ATS by adding the following to your Info.plist file:

Android network security configuration

To enable clear-text local traffic on Android you should create a network security configuration by adding a new XML file named network_security_config.xml in the Resources/xml folder. The XML file should specify the following configuration:

Then, configure the networkSecurityConfig property on the application node in the Android Manifest:

Источник