Modern application development and user interface testing often require simulating real-life smartphone usage scenarios. One of the most common requests from QA engineers and novice developers is the question how to call from an Android emulator for real numbers or between virtual devices. The standard emulation environment, be it Android Studio, Genymotion or BlueStacks, initially does not provide direct access to the operator's cellular network, since it works in an isolated virtual environment of your computer.
However, the absence of a physical SIM card does not mean a complete blocking of voice calls functions. There are several proven methods to work around this limitation, from using built-in console commands to integrating third-party VoIP services. In this article we will analyze in detail technical nuances call emulation, configure traffic routing and consider tools that will turn your virtual device into a full-fledged communication node.
Virtual telephony: principles of operation of the emulator
To understand how to implement a call, you must first understand the architecture virtual network emulator. The Android emulator does not connect directly to cell towers. Instead, it creates a virtual modem that communicates with the host machine (your computer) through a special gateway. All calls within this environment are by default internal or emulated events.
The key component here is GSM emulation. The system believes that it is within network coverage even if there is no physical signal. This allows applications that depend on the network state (for example, instant messengers or banking) to function correctly. To make a real call, it is necessary to “forward” voice traffic from the virtual environment to the real Internet or public telephone network (PSTN).
⚠️ Attention: Direct access to the cellular network via a USB modem connected to a PC is often impossible in standard emulators without complex reconfiguration of drivers and the system kernel. Most solutions rely on data transmission via the host's Wi-Fi.
It is important to distinguish between two types of communication: incoming call emulation (when the system simulates a call to test the application's response) and real voice traffic (VoIP). The first type is used for debugging interfaces, the second - for testing the quality of communication and the operation of audio codecs. Android Emulator provides powerful tools for both scenarios, but they require different settings.
Emulation of incoming and outgoing calls through the console
The most reliable way to test the application's response to a call is to use the emulator console. This method does not require an Internet connection and works at the system interrupt level. You can simulate an incoming call from any fictitious number to test how your application handles the event CALL_STATE_RINGING.
To get started, you need to access the emulator console. This is usually done via telnet or the built-in console in Android Studio. The console address is formed from the prefix and port on which the emulator is running (for example, localhost:5554). After connecting, you get full control over the device’s virtual modem.
How to find the emulator port?
The port is always indicated in the title of the emulator window or in the list of ADB devices. This is usually an even number in the range 5554-5584. If you are running several emulators, their ports will differ by 2 (5554, 5556, 5558, etc.).
The command to initiate an incoming call looks extremely simple, but requires precise syntax. You indicate the number from which the call is supposedly coming. The emulator system instantly puts the virtual phone into ringing mode, displaying the standard incoming call screen.
telnet localhost 5554
gsm call 89991234567
In the same way, you can manage the connection status. If you need to test a scenario where a subscriber drops a call or, conversely, accepts it, the appropriate session management commands are used. This is critical for checking the logic of background services.
- 📞 gsm call [number] —initiates an incoming voice call from the specified number.
- 📵 gsm cancel [number] —cancels an incoming call (reset simulation).
- 📟 sms send [sender] [message] —sends a test SMS to a virtual device.
It is worth noting that these commands only work inside the emulator perimeter. You won't be able to call your real phone like that. However, for a developer, this is an ideal tool for debugging event handlers without the need to have a second physical device at hand.
Real calls via VoIP and instant messengers
If your goal is to make a real call from the emulator to a landline or mobile number, you will have to use IP telephony technologies. Since the emulator has Internet access through the host machine, you can install any calling application that supports the protocol SIP or proprietary VoIP solutions.
The most popular option is to install applications like Skype, Viber, Telegram or specialized SIP clients (for example, Linphone or Zoiper). For these applications to work inside the emulator, the network bridge must be configured correctly. Sometimes it happens that the application sees the network, but cannot capture the computer's audio device.
If the emulator microphone does not work in a VoIP application, go to the emulator settings (gear) and manually select the audio input device (Microphone) that corresponds to your physical microphone or headset.
When using SIP accounts, you get a full number or an internal an extension from which you can call anywhere, paying for traffic according to your provider’s tariffs. This turns the emulator into a softphone. The quality of communication in this case will directly depend on the bandwidth of your PC and the codec settings in the application itself.
Some corporate solutions require specific NAT settings. If you are behind a router, the emulator may not correctly determine its external IP address, which will lead to problems establishing a connection. In such cases, manually registering a server in the SIP client settings or using Bridge mode in the emulator virtual network settings helps.
| Application | Communication type | Account required | Landline calls |
|---|---|---|---|
| Skype | VoIP / PSTN | Yes | Paid (credits) |
| Telegram | P2P VoIP | Yes (phone number) | Only within the network |
| Zoiper | SIP / IAX2 | Yes (provider) | Depends on the tariff |
| Google Voice | VoIP | Yes | Free (USA/Canada) |
Network setup and port forwarding for communication
For stable operation of voice services, the correct network configuration is critical. The Android emulator uses NAT (Network Address Translation) by default, which hides it behind the host's IP address. In most cases this works transparently, but some real-time protocols (RTP) may require additional settings.
You can manage the emulator's network parameters through a configuration file or the command line at startup. For example, you can explicitly specify DNS servers if automatic detection does not work, which is often the reason for the inability to register with a SIP server. Using public DNS from Google (8.8.8.8) or Cloudflare (1.1.1.1) often solves problems with resolving telephony provider domains.
Also It's worth paying attention to your operating system's firewall. It can block outgoing UDP packets from the emulator process, resulting in no sound when the connection is successful (a "hear but not me" situation). Adding a rule for the emulator executable file to firewall exceptions is a required step when debugging VoIP.
If you are developing your own calling application, you may need to forward ports from the host to the guest system. This is done through the command redir in the emulator console. For example, to redirect traffic from port 5060 (standard SIP) to the emulator, the corresponding directive is used. This allows you to test the telephony server part deployed locally on your computer.
Integration with physical hardware and ADB
Advanced testing scenarios may require the emulator to interact with real telephony equipment connected to the PC. Although the emulator does not see USB modems as its own, you can use your computer as a gateway. Using scripts and command line utilities, you can organize a chain: Application in the emulator -> Script on a PC -> USB modem -> Operator network.
Tool ADB (Android Debug Bridge) is the connecting link in this chain. Through it you can not only send commands, but also redirect the audio stream. However, to organize a real call via a computer's GSM modem, you will need third-party software on the host machine, which will receive commands from the emulator (for example, via sockets) and initiate a call via the modem.
⚠️ Attention: Direct transmission of an audio stream from the emulator to a GSM modem is associated with high delays and synchronization difficulties. This method is recommended only for highly specialized tasks of testing IoT devices.
A simpler integration option is to use the emulator as a control panel. You can write an application that sends commands to a PC via Wi-Fi, and the PC, in turn, uses the operating system API (for example, Skype for Business API or macros) to make a call. This creates the illusion that the call is coming directly from the emulator.
☑️ Preparing for VoIP tests
Debugging audio and solving sound problems
One of the most common problems when trying to make a call from an emulator is the lack of sound or echo. Android Virtual Audio emulates the speaker and microphone, redirecting them to your computer's I/O devices. If the system has multiple audio devices (for example, a webcam with a microphone and a separate headset), the emulator may select the wrong one by default.
For diagnostics, use the built-in developer tools. Enable the Show Touches option and Network Activity Monitor to make sure packets are getting through. Check the volume levels inside the emulator itself using the volume buttons. Sometimes the Android software mixer is set to zero, even if there is sound on the computer.
If you encounter echo, try changing the audio buffer size in the emulator settings. Increasing the buffer may reduce CPU load, but will add latency. Reducing the buffer will make the connection livelier, but will require more resources. Finding balance depends on the power of your CPU and version of the emulator.
The sound quality in the emulator 90% depends on the correct choice of the recording device in the settings of the virtual device, and not on the settings of Android itself.
It is also worth checking the application permissions. In modern versions of Android, microphone access is a dangerous permission. Make sure that microphone access is granted in the application settings (App Info). Without this, any VoIP client will show the connection, but transmit silence.
Comparative analysis of calling methods
The choice of method depends on your specific tasks. If you are testing the layout of the dialer screen, emulation via the console will suffice. If you check the quality of the Opus codec in a real channel, you need VoIP. A hybrid approach is often used to automate tests.
Consider a summary table that will help you choose the optimal tool for your situation. It takes into account the complexity of setup, cost and proximity to real conditions.
| Method | Complexity | Real number | Costs | Best for |
|---|---|---|---|---|
| Console (gsm call) | Low | No | Free | UI tests, logic |
| VoIP (Skype/Zoom) | Medium | Yes | Paid/Free | Sound checks |
| SIP Client | High | Yes | Subscription fee | Corporate PBX |
| Gateway via PC | Very high | Yes | Depends on the modem | IoT specific |
Do not forget that the emulator consumes significant RAM resources. Running heavy VoIP applications with an IDE can slow down your system. Close unnecessary tabs and applications on the host machine before starting a connection testing session.
Is it possible to call from an emulator to a regular phone without the Internet?
No, this is impossible. The emulator does not have a physical GSM/LTE radio module. The only way to access an external telephone network is to use the host machine’s Internet channel and VoIP technologies or complex gateways that still require data transfer.
Why doesn’t the emulator see my USB headset?
The emulator uses the audio drivers of the host operating system. If the headset is not selected as the default playback and recording device in Windows/macOS/Linux, the emulator will use the standard speakers and microphone. Reconfigure the audio devices in the OS.
How to test call interruption?
Use the emulator console and command gsm cancel. You can also enable the “Keep active” mode in the developer settings to simulate the killing of the dialer process by the system when minimized.
Do emergency calls (112, 911) work in the emulator?
No. Emulators do not have the right or technical ability to connect with emergency services. An attempt to dial such numbers will either be blocked or emulated as a regular call without connecting to an operator.
Is it possible to record a conversation inside the emulator?
Yes, using third-party recorder applications installed inside Android, or using the screen/audio capture functions on the computer (host) itself. The emulator's internal tools do not have a built-in voice recorder for calls.